Exploration Through Example

If you create a subclass C inside a module M, the result is two distinct classes: M::C (as expected) and OSX::C (an unpleasant surprise):

require ‘osx/cocoa‘
puts OSX.const_defined?(’Squiggle‘)    # => false

module M
  class Squiggle <  OSX::NSObject
  end
end

puts OSX.const_defined?(’Squiggle‘)    # => true ?!
puts M.const_get(’Squiggle‘)           # => M::Squiggle
puts OSX.const_get(’Squiggle‘)         # => OSX::Squiggle
puts M::Squiggle == OSX::Squiggle      # => false
puts M::Squiggle.object_id
puts OSX::Squiggle.object_id

RubyCocoa 0.13.1, OSX 10.5.5

I believe this is because Objective-C doesn’t “get” separate namespaces - all classes are in the same namespace, which is why you can’t do this:

irb(main):001:0> module Second; class Quux < OSX::NSObject; end; end
=> nil
irb(main):002:0> module Second; class Quux < OSX::NSObject; end; end
/System/Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/
objc/oc_import.rb:266: warning: Cannot create Objective-C class for
Ruby class `Quux', because another class is already registered in
Objective-C with the same name. Using the existing class instead for
the Ruby class representation.
objc[12661]: objc_registerClassPair: class 'Quux' was already registered!

As part of his programming tour, Corey Haines is interviewing the people he pairs with. He’s posted part 1 of his interview with me. If you’re interested in my life story—and who wouldn’t be?—start at the beginning. If you only want to hear about problems with automated acceptance testing (of the FIT sort) and the solution I’d like to explore, start at 5:54.

One note: my explanation of the solution isn’t clear enough about the role of unit tests. What I want to explore is:

good automated unit tests + good exploratory testing - automated acceptance tests.

(In later parts of the interview, I believe I qualify that to be:

… - most automated acceptance tests.

There’s still a role for sanity-checking tests, for example.)

The whole thing is about 24 minutes long.

Corey Haines is making a tour of the US Midwest, pairing with people. I was happy to host him for the past two days. He introduced me to a style of pairing I’d never done before. What you see on the right is how we worked the whole time, each with our laptop, sharing the screen (via iChat).

I found myself preferring this style to pairing side-by-side in front of a screen. I even prefer it to sitting in front of two side-by-side screens with two keyboards. The work is more free-flowing and conversational. It’s easier to note the other person’s body language. It’s easier to stop coding, look up, and talk to each other. I found the switching between people more fluid, with fewer episodes where we were both going for the cursor at the same time.

On the downside: it may be a little harder to make sure that one one of you is filling the “navigator” role—stepping back and keeping track of the big picture. But I find that’s hard to ensure in any case.

I recommend you give it a try.

(The chair on the left, by the way, is where I do most all of my work. I recommend big bay windows with smallish panes for all kinds of hands-at-keyboard work, especially if you live on a nice old brick street with big trees.)

The recording of my keynote is now available. The real meat starts about 8′ 30″.