I stumbled across, in the course of my customary World Wide Web Woolgathering this afternoon, upon these crib notes for all 253 of the patterns in
Christopher Alexander's
A Pattern Language...
More woolgathering: A City is Not a Tree, by Christopher Alexander. I'd never seen it until today, but it covers some of the same turf we'd attempted to cover in our paean to
Piecemeal Growth a few years back. Alexander's treatment is, of course, considerably more elegant and comprehensive that ours. (Seriously, there is no comparison.)
One of the overarching themes of Catfish in the Memepool has always been intended to be the futility of the pursuit of classical originality in the twenty-first century. Catfish are, after all, the quintessential bottom feeders. So I checked, and discovered that A-List techie meme arbitrageur Clay Shirkey (a fellow whose compilations I enjoy, but am evidently behind on) had already raided this tomb. I learned this, in turn, here. I chased down Clay's citation, only to find him, in essence, briefly lamenting the same thing before embarking on his discourse on the content of this Johnson Administration Era (1965) gem. (This paper will be forty years old in May.)
A City is not a Tree (Alternate Source)
Nobody asked, but I gather this is something of a weblogging right-of-passage. In any case, I knew I'd started this list somewhere, and figured this is as good a place as any to keep it
A few honorable mentions, in no particular order:
I'll undoutedly think of more. Ranking these is reminiscent of any peer reviewed process / process involving grading or ranking : broadly accurate, but fickle at the margins...
Our patterns reading group here at UIUC has been looking at a collection of patterns on Testing Automation by Gerard Meszaros. Today, several of the students who usually attend these workshops are absent, because they are home in bed instead, following marathon efforts to turn in machine problems for their operating systems course.
I’d been looking in on their progress for the last few days with the sort of avuncular amusement typically reserved for watching young bucks nurse their first hangovers. Having waited until the last forty-eight hours or so before their deadlines to finish, sleepless nights and a mad dash to the finish line were all too inevitably in their immediate futures.
Amazingly, this ritual has changed little in almost thirty years. I recall, perhaps with more pride than fondness, ultimately prevailing over almost identical assignments. In my case it was during the last days of the Ford Administration, in the old Digital Computer Laboratory across the street. These pups work in the fancy new Siebel Center for Computer Science, and even from home. Then, they were virtual memory system simulations. Today, they were file system simulations. The more things change…
If anything, the target programming languages today are worse. Pascal, despite, or more to the point because, of its limitations, exposed few pointer- and destructor- hell pitfalls than does C++. The debuggers and programming environments have improved, but less dramatically than some might think.
And yet, there was one major, glaring difference between then and now. And that is the use of test cases, and automated testing. Students now are provided with a set of tests, that, when passed, indicate that the machine problem is complete. Students are encouraged to write their own unit tests as well.
In thirty years, this is the one innovation that has changed this biannual ritual for the better. The amazing this is that it took no particular technical breakthrough to enable this to happen. We could have systematically written unit tests thirty years ago, had we thought of it.
I’d guess that automated testing cut at least a day off of the student's pain and suffering time for this machine problem (to say nothing of that for the graders).
The more things change … the more important it is to test them…
--BF, in a retrospective, though not particularly nostalgic mood…
Photograph (C) 2004, The Laputan Press, Ltd.
In nuclear engineering, a moderator is a medium that reduces the velocity of fast neutrons, thereby turning them into thermal neutrons capable of sustaining a chain reaction.
--The Free Dictionary
I couldn't have described the moderator's role better myself.
Danny Dig and I recently moderated a writer's workshop for a set of patterns written for Ralph Johnson's graduate software engineering course. We opened the workshop with the quip above.
Levity is, of course, an end in itself. But moreover, it serves several additional functions. It relaxed the authors, in this case, first timers all, and, more importantly helped to melt down any "stature gaps" that may exist among participants. Its very introduction sets a more informal tone, and offers the expectation that any attempts at posturing and pretense will be similarly dealt with.
Whether you are a student whose advisor wrote the book on patterns, an academic shopping his or her work before the best-known luminaries in his field, or a domain expert trotting out his or her first serious attempt at writing since high school, a writers workshop can be a genuinely intimidating experience.
A certain degree of irreverence is a great equalizer. I shudder to think of the alternative.
I'm mentioning this because disciples of Richard Gabriel's more aggressive, more didadic writer's workshop moderation style have made his approach all-the-rage on the patterns circuit of late.
Gabriel often turns the usually perfunctory pattern summary section of his writer's workshops into a quest for "the heart of the pattern". I can tell when a moderator has been drinking Gabriel's Socratic hemlock when he or she begins by demanding that I rip the pattern's beating heart from its chest and hold it high above the altar for all to see. Dick, by dint of meticulous preparation, experience, and raw animal magnetism can pull off the high priest pose; I'm not sure it's the best persona for most of the rest of us.
I've seen a variety of workshop moderation styles work. In a workshop where everyone is prepared, the moderator need do little more than direct traffic, the didactic functions being spread among elders and well-prepared rookies alike. Thoughtful color commentary is easier to come up with when you aren't calling the game.
It's possible to "teach" from any chair in the room, not just the moderators, moreover, not all of us ought to presume to be in the education business.
I like what Ralph has said about Dick's example having given us all license to do it our OWN ways. That's the example we should be emulating. We can't all Be Like Dick, though surely we can learn from him, but most of us could still do a better job of being ourselves.
There are a lot of ways to run a workshop that work. Moderation in all things is a virtue...
--BF, ...humor included. (drawn from a mailto:members@hillside.net submission...)