Exploration Through Example

On October 11th and 12th, I’ll be at RubyDCamp, an Open Space / FooCamp style workshop near Washington, D.C. It’s USD100 until October 6.

I won’t be going to Agile Open California, an Open Space style conference on October 6th and 7th in San Bruno. I went to the first Agile Open in Portland, and it was definitely worth the USD250. That’s where I got the first whiff of Arlo Belshee’s ideas about estimating and iterations, so I was prepped for Kanban, which is quite the rage these days. I think it was also there that I took notes that became the Agile Alliance’s position on certification. So: a happening place.

This may be of use someday to someone trying to figure out their Cocoa bindings problem.

Summary: Do not bind some columns in a table to one array controller, others to another.

I’m using RubyCocoa 0.13.1. I had an NSTable bound to an NSArrayController (bound in turn to preferences). I wanted to replace that NSArrayController with an NSArrayController subclass. I proceeded in small steps. Here’s step 1:

* I made an empty subclass of NSArrayController, PreferencesController.
* I created an object of that subclass in Interface Builder by dragging in an NSArrayController (<== very important; don’t try using an NSObject) and changing its class.
* I changed the binding of one of my table columns from the NSArrayController to my new PreferencesController. Specifically, the keypath was “arrangedObjects.display_name”. I left the other columns bound to the original NSArrayController.

To my surprise, each cell in the rebound column was not the display_name string. Instead, each cell contained an array with all the display names. That is, rather than the column looking like this:

Dawn
Paul
Sophie

It looked like this:

(Dawn, Paul, Sophie)
(Dawn, Paul, Sophie)
(Dawn, Paul, Sophie)

The other columns displayed correctly.

(Note: this was the leftmost column. When I made the change to the rightmost column, all of them were messed up.)

The solution was to switch all the bindings to PreferencesController. Then all the columns behaved correctly.

I haven’t tried doing this with two pure NSArrayControllers, rather than one pure and one subclass.

Here’s a style of development I once proposed. I was reminded of it at SDTConf.

The project was to allow scientists to ask questions of a big database. There was a product owner who understood the scientific domain and - importantly - could have used the database to answer the questions (either by constructing SQL queries or by walking someone who knew SQL through query construction - I forget which). There were programmers who knew SQL and Java but were ignorant of the domain.

I proposed that the scientists not worry about programs. They should instead ask their questions of the product owner. They could either email them to her or talk to her on the phone. It would be her job to respond to the scientists with the data they needed.

At the beginning, I envisioned her doing one of two things. If the questions were dirt simple, she could pass them off to the programmers, who would build the queries, run them, and email back the results. Otherwise, she’d have to do that work herself.

So the programmers would be barraged with simple questions that would turn into simple SQL. Being lazy, they’d soon write code to automate query construction.

As the project continued, the product owner would hand off more and more complicated questions to the programmers, who would construct more and more complicated queries. They’d improve their programmatic interface to the database. Who knows? - they might find a need for an object model.

At some point, the programmers would be capable of answering most any query. They would have improved their interface to the point that it would make common queries easy and uncommon queries possible. Except… the user interface would be lousy, suitable only for programmers.

At this moment, the scientists are happy in one sense and sad in another. They’re happy because they can ask questions of an intelligent interface (a human being, rather than a program) - after all, their goal is not to use a program but to effortlessly get their questions answered. But they’re unhappy because the results don’t come fast enough. They have to wait for some human (programmer) to type at a program.

The programmers have become bored entering queries for the scientists. They’ve mastered the domain (of scientifically-relevant query construction) and want to move on.

So now the project becomes one where the programmers try to create a good enough user interface that the scientists will prefer the instant gratification of using it to the pleasantness of interfacing with a smart human instead of a dumb computer.

—-

I liked this approach because it front-loads the important bit — capturing the domain, representing it in code — but it still starts providing value to the end-users really, really early.

Unfortunately, I discovered once again how politically inept I am, so I got tossed off the project without ever trying this scheme. I’ve wanted to ever since.