Exploration Through Example

Steve’s right - this slideshow of what people are uploading to Blogger is oddly fascinating.

I’ve earlier mentioned that I’ve started using EagleFiler, an organizational/searching tool. Its author announced a bundle with Cyndicate, a newsreader, so I’ve started using that. It seems to fit my newsreading habits better than either NetNewsWire (2.x) or Safari. (Note: I haven’t used NetNewsWire 3.x).

Here’s a workflow (click for larger screen shots). I’m reading the last day’s news, and I see this:

The article describes a tool I can easily imagine using someday, so I hit F1 to save it in EagleFiler. That happens behind the scenes. Later, I might vaguely remember there was some posting somewhere about making a diagram of your model classes. In EagleFiler, I search for “model diagram rails”, and I find the saved web archive:

(I get a more exact match if I remember the article mentions ‘dot(1)‘ or OmniGraffle. I’ll also get a more exact match once I process my unfiled entries and add some tags.)

I mention this now because the promotional bundle lasts only two more days.

(I have no affiliation with either company, except that I read Michael Tsai’s blog.)

UPDATE: Judging from email, I wrote this badly. Ignore the bit about assertEquals. My point is that I want to write mock tests the way I talk, which is “when this method executes, it calls these other methods in such and so a way” rather than “expect these other methods to be called in such and so a way when this method executes”. Since, in my speech, I describe the action before its effects, I want mock tests to do that too. So I made up a notation and seek comments.

I think we all know that the order of arguments is wrong in JUnit’s assertEquals. If you talked like JUnit wants you to, you’d say things like “After the calculation I’ve just described, 23 is the resulting azimuth.”

It’s not so big a deal that your order of thinking about a truth statement doesn’t match the order in which you have to type it. Probably no more than one in a billion people is driven homicidally insane by the accumulated weight of such grating little annoyances. And there’s nothing we can do about it now.

Let’s move on to mocks. Here’s a test method (with some long lines edited to fit):

Reading that aloud would sound something like this:

“The network gets asked if some URL is OK once when…

… wait for it…

… wait for it…

… wait for it…

… the checker is invoked with that URL.”

This is, again, not the way people talk. You might not be able to do anything about the problem in Java, but in a Real Language (meaning: one with lambda), you can. So I’ve today started writing my mock tests like this:


  def test_checker_normally_checks_network_once
    checker = testable_checker
    during {
      checker.check(”url”)
    }.behold! {
      @network.should_receive(:ok?).once.
               with(”url”).
               and_return(true)
    }
  end


The “behold!” is a little hokey; I couldn’t think of a good connecting word. But I do think this reads better. Does it read better to you?

Notes:

• I don’t use mocks that much. This style may not work in complicated situations.

• Surely someone’s done this before? Who?

Jeff Patton writes an article on Slow Software and puts it in context on his blog. He asks for reactions.

My off-the-cuff reaction is that he’s letting us ignore reflexivity. “Reflexivity“: a jargon word. What does it mean? Take two statements of Jeff’s:

Before we plan and build, we should
take time to understand what value is.
Make sure the first thing we gather is
how the people paying for the software
will get value from it. […]

We also might want to understand
better the people using our software.
They’ve got goals, too, which likely are
met using other software or manual
processes today.

“What value is” and “their goals” and “their processes” ought to change when the software is injected into the mix. That change ought to reflect back on the product, which will then change its environment again, …, until eventually things settle down because further change is not worth the effort.

But I have to admit that reflexive loop is something that appeals to my personality. A perfectly valid response to the above goes like this:

• The vast majority of products don’t need any high-falutin’ reflexive loop. They’re a CRUD app attached to a database, just like a zillion others.

• I’m overly fond of this reflexive loop because I don’t have the skill to understand its value and user goals until after I dump a product on someone. If I were more skilled, I could immediately get to the same place that I today can get to only after several trips around the loop. Maybe, especially with those CRUD apps, I could even get immediately to the place where further change to decisions is not worth the effort. In that case, the main point of developing in short iterations would not be to allow discovery but to enforce discipline.

I think those are valid points. For that reason, I’ve asked Jeff to let me join him on some consulting gigs, so I can sit at his feet, watch, and learn.

Here. Silly, I thought, before I realized I do something like it.

From Keith Braithwaite: a discussion of gauges as a metaphor:

http://peripateticaxiom.blogspot.com/2007_07_01_archive.html
http://peripateticaxiom.blogspot.com/2007/09/gauges.html

It’s nice.

I still like examples as a metaphor, but if it hasn’t caught on in four years and a month, it’s not gonna.

Mishkin Berteig has a concise list of five reasons to try Agile. Could be useful as a cheat sheet when talking to business people.

Edwin Hutchins is the author of Cognition in the Wild, an influential book on how groups think. If I were closer to Chicago, I’d go. I might still go. Sounds pretty relevant to crossing the cultural divides that often separate, say, the business people from the development team.

Edwin Hutchins (UCSD) will be presenting a colloquium entitled “The multimodal production of common ground understandings” on Thursday, October 4th at 4:00pm. The colloquium will be held at Room 1-421, Frances Searle Building.

For more information on the TSB speaker series (and to sign up for announcements), visit http://tsb.northwestern.edu

THE MULTIMODAL PRODUCTION OF COMMON GROUND UNDERSTANDINGS
Edwin Hutchins

ABSTRACT:
Effective collaboration requires the creation and maintenance of common ground understandings. This is an especially interesting problem in the case of intercultural collaboration, where communicative conventions may not be shared. However, intercultural collaboration often takes place in professionally relevant material settings and among people who share professional competence. In this paper we show how Japanese airline pilots and American flight instructors overcome pronounced differences in language and culture and achieve effective collaboration. They do this by drawing on a rich body of shared professional pilot culture and by exploiting richly multimodality situated communication practices to produce common ground understandings.

A nice summary.

Breathes there the man, with soul so dead,
Who never to himself hath said,
Man, things in outer space sure are cool.

Large image

Really large image

Different pictures

Image credits: NASA / JPL / SSI / mosaic by Gordan Ugarkovic. Image taken from the Planetary Society blog. With apologies to Sir Walter Scott.