Exploration Through Example

Some people, including Alexey Krivitsky and Declan Whelan, have been talking about an #agilecoachtour. When I heard of it, I thought of the Festival Express train trip, jam session, and concerts.

I’ve also long been thinking about a talk Alistair Cockburn gave a zillion years ago about how high-performance individuals are good at a large number of “micro-techniques”. It’s not [just] brainpower or hedgehog-style great ideas: it’s excess skill at a vast number of tricks of the trade. Someone (Jeffrey Fredrick?) was telling me it’s something like that for elite swimmers: you learn to do many things better than the competition, even though none of them is in itself more than a slight improvement.

I also have an increasing desire for speakers to speak about what newly excites them, rather than reiterate their safe, well-worn conclusions. Related to that: I’d like to see speakers more directly serve their audience. (For example, for my Ágiles 2009 keynote, I’m asking the audience to tell me—in advance—the questions and topics they’d like me to speak on.) But I don’t much care for straight question-and-answer sessions, since those don’t “build” to a conclusion and tend not to surface much novelty.

So here are some vague thoughts:

• The structure of the trip would be long train rides, including overnight travel, that allow the riders to work/jam together. When the trip stops in a city, it’d be for a one-day conference.

• People would work together actively to learn things they’d present at one of the stops. So, for example, I might present “Thoughts on Mocks collected by talking and working with Freeman, Feathers, etc.” And many of the thoughts would not be of the form “The difference between mocks and stubs is…” but things like “when using mocks to TDD a UI, have mock objects just accept setters and return values with getters, which makes for more concise tests.”¹

• I’ve favor one-on-one work over group discussions. Two people talking or working together are more likely to get down-and-dirty than a group. (That’s part of the appeal of a train—it favors micro-groups.) I can see a person pursuing a particular topic working in a series of “sequentially monogamous” relationships.

• I can also imagine “customers”—non-coaches with problems—joining the trip for a day or so to serve as audience proxies to champion particular topics and shepherd creation of something useful. (This is maybe a little like my idea for an AR⊗TA conference.)

¹ That’s not actually an idea I got from either of those people, so don’t blame them. It’s just that I’ve been noticing that this test:

     [sut disappear];

     [self assertTrue: [sut.pageView hidden]];

is clearer than a version that’s explicit about expectations:

   during: function() {
     [sut disappear];
   }
   expect: function() {
     [sut.pageView shouldReceive: @selector(setHidden) with: YES];
   }];

And it’s not just the whacky syntax in the latter. It has more to do that a GUI framework (at least Cocoa and its Javascript version) tends to have GUI objects that rely heavily on setters and getters. Maybe you would follow tell-not-ask when designing your own framework, but the people who designed those didn’t. So deal.

I did talk with Steve Freeman about it last week, and at least he didn’t recoil in horror.

Here’s a test for the Cappuccino app I’m working on. It’s about what happens when, for example, you click on “blood collection for transfusion” in the right table here:

- (void)testPutBackAProcedure
{
  [scenario
   previousAction: function() {
      [self procedure: “Betical“
            hasBeenSelectedFrom: [”alpha“, “Betical“, “order“]];
    }
  during: function() {
      [self putBackProcedure: “Betical“];
    }
  behold: function() {
      [self listenersWillReceiveNotification: ProcedureUpdateNews
            containingObject: []];
      [self tablesWillReloadData];
    }
  andSo: function() {
      [self unchosenProcedureTableWillContain: [”alpha“, “Betical“, “order“]];
      [self chosenProcedureTableWillContain: []];
    }
   ];
}

Here’s the code to pass the test (after inlining one method):

- (void)unchooseProcedure: (id) sender
{
  [self moveProcedureAtIndex: [chosenProcedureTable clickedRow]
                        from: chosenProcedures
                          to: unchosenProcedures];

  [NotificationCenter postNotificationName: ProcedureUpdateNews
                                    object: chosenProcedures];
  [chosenProcedureTable reloadData];
  [unchosenProcedureTable reloadData];
}

Did the test clarify my design thinking? No, not really. Will it be useful for regression? I doubt it. Is it good documentation for the app’s UI behavior? No.

Something seems wrong here.

You can get it from the publisher, from Amazon, from Powell’s, from O’Reilly …

The publisher, by the way, says that probably the best marketing for the book is getting reviews up on Amazon.

Cappuccino’s table views aren’t fully finished, so—in version 0.7.1—you can’t just add radio buttons to a table column and have them work. Nevertheless, I wanted something like this:

Since I spent some time figuring out a workaround, I thought I’d save someone some time and write it up.

The workaround used subclasses of CPCheckbox and CPTableColumn. Those were used in the normal way when laying out the window:

  var checkColumn = [[CheckboxTableColumn alloc] initWithIdentifier:@“checks“];
  // …
  var checkButton = [[CritterCheckBox alloc] init];
  [checkButton setTarget: animalController];
  [checkButton setAction: @selector(toggleAnimal:)];
  [checkColumn setDataCell: checkButton]

(nib2cib doesn’t work yet for my application.)

The controller needs to know which checkbox got clicked. I decided to put an index in each checkbox and implement clickedRow on it. (That allowed the action method to ignore whether it was invoked by the checkbox or by selecting a table row, which turns out to be convenient for this application.) The table column’s dataViewForRow: method returns a numbered checkbox. So far, that looks like this:

@implementation CritterCheckBox : CPCheckBox
{
  (CPInteger) index;
}

- (CPInteger) clickedRow
{
  return index;
}

// …
@end

@implementation CheckboxTableColumn : CPTableColumn
{
}

- (id) dataViewForRow: (CPInteger) row
{
  var retval = [[CritterCheckBox alloc] init];
  var target = [[self dataCell] target];
  [retval setTarget: target];
  [retval setAction: [[self dataCell] action]];
  retval.index = row;
  // ..
  return retval;
}

@end

It turns out that CPTableView makes copies of the cells it gets from the CPTableColumn. It uses CPKeyedArchiver/CPKeyedUnarchiver to do that, so those have to be implemented:

@implementation CritterCheckBox : CPCheckBox
//… 

- (void) encodeWithCoder: (CPCoder)aCoder
{
  [super encodeWithCoder:aCoder];
  [aCoder encodeObject: index forKey: @“critter row index“];
}

- (void) initWithCoder: (CPCoder)aCoder
{
  self = [super initWithCoder:aCoder];
  index = [aCoder decodeObjectForKey: @“critter row index“];
  [self setTarget: GlobalCheckboxTarget];   // < <<<<<<<<<<<<<<<<
  return self;
}

@end

The line marked with arrows is a gross hack. CPControls will archive and unarchive actions, but not targets. I decided to fake that by stuffing the target in a global variable and reassigning it on every unarchiving.

When the column is displayed, some of the checkboxes should start off checked. So when a checkbox is created, it asks its target for the appropriate value in the normal tableView:objectValueForTableColumn:row: way:

- (id) dataViewForRow: (CPInteger) row
{
  // …
  checked = [target tableView: nil
                    objectValueForTableColumn: target.checkColumn
                    row: row];
  if (checked) [retval setState: CPOnState];
  return retval;
}

I know a lot of this is stylistically crummy Objective-J. Part of the reason is that I haven’t figured out an Objective-J style yet.

Suggestions about better approaches welcome.

The CheckboxHacks.j source is available on github. So is the whole tree.