I somewhat disagree with Jon on this point from The art and science of software testing
When up to half of the output of a full-blown TDD-style project can be test code, we're going to want to find ways to automate and streamline the effort.
If you discipline yourself to write the test first, then any it-would-be-cool feature becomes immediately twice as expensive. As a lazy programmer I don't want to put the effort into writing a test for some speculative flexibility until the customer actually asks for a feature requiring it. The time-cost of writing tests creates natural resistance to unnecessary bloat. With that in mind, I would be cautious about streamlining the testing effort. Too much streamlining will take away this really excellent side-effect of testing first.
Tonight I finally started down the road of removing cruft from my URLs like Mark. Unfortunately, it looks my web host doesn't let me set redirects in my .htaccess file at the moment (that or I'm too tired to figure out what I'm doing wrong).
I did at least get one part working. The main complaint I had about my previous URL design is that the paths that appear in my logs are not especially readable. I don't recognize my posts by their numerical id. Sure I could write some code to replace the id with the title. I could also spend that time skiing. So I've added the thing Mark called a 'slug' instead of the numerical id. This shouldn't effect the older posts (except the last two which I used to test the concept).
I would still like to get rid of the .html part, and give meaningful names to some of my older posts. The trick will be preserving the old links with some permanent (301) redirects. Maybe I'll get to that by next year. ;-)
This time last year Sarah and I were probably still celebrating the completion of her master's thesis. A week ago someone on the American Dance Therapy Association mailing list asked for information about published work on dance therapy and sensory integration disorder. So far twenty-one other people have expressed interest in her thesis. I'm so proud!
Dance Movement Therapy and Sensory Integration: An Integrated Approach to Working With Children (178K PDF)
Abstract:
This thesis addresses a therapeutic approach to working with children in dance movement therapy settings. During these sessions, the dance therapists were asked to incorporate sensory integration techniques within dance therapy sessions. The research question asked: how does increased awareness and utilization of occupational therapy-based interventions with elementary aged children exhibiting possible sensory integration symptoms effect dance therapists reported effectiveness of dance therapy sessions?
The author of this thesis created a manual to be utilized by a dance therapist in her sessions with elementary aged children who display symptoms of sensory integration disorder. The dance therapist was asked to apply movement interventions designed to address both sensory integration issues and body-based psychotherapy concerns. The subject filled out a pre-study questionnaire and journalled after each session. Her post-study interview was tape recorded and analyzed afterward to find general themes of her reported experience working with the manual.
The results of this case study indicated that utilizing sensory integration techniques in conjunction with dance therapy can facilitate beneficial changes in behavior, which in turn can support accomplishment of therapeutic goals.
When Indiana Jones and the Temple of Doom was released, I really liked it. I thought it was a great movie. Seeing it since then I can only apologize that I was a teenager and didn't know any better. Temple of Doom basically sucks. I feel similar pain whenever I watch any of the Star Wars movies (except The Empire Strikes Back). It's not quite as bad with Star Wars because there's still so much nostalgia and I still like the richness of the story regardless of the melodramatic delivery.
So this weekend it was with some apprehension that I rented another movie I loved as a teenager: WarGames. I hadn't seen it since it's release in 1983 around my fifteenth birthday.
There's a spoiler coming up. If you read my blog, you have almost certainly seen this movie, though there maybe some youngins out there who haven't. If you haven't seen it, it may only be interesting for the historical perspective. But thought I should warn you ahead of time anyway.
I'm happy to report that two decades later the movie still entertains. There are some definite differences between then and now. First, I was viscerally frightened about the possibility of global thermonuclear war as a teenager. The flashing and build-up and count-downs in the end of the movie were really gripping back then. It hit me personally in a couple ways. Like the protagonist, I was an established high school computer geek. Second the climax of the movie takes place at NORAD which is under Cheyenne Mountain not far from Colorado Springs and there are other scenes set in Grand Junction where most of my Dad's family lives. It was an especially scary idea that someone like me could accidentally start World War III. All of that seems distant and even silly now. On the other hand I still really appreciate the movie's punch-line (this is the spoiler).
For those who don't know or don't remember, Joshua is the nickname of the computer which is in control of the US nuclear arsenal. It has been programmed to play games and to learn from its experience. It thinks it is playing simulation of Global Thermonuclear War, but is in fact on the verge of starting World War III.
In the climax of the movie, David Lightman, the heroic teenage computer geek, tells Joshua to play itself tic-tac-toe repeatedly. We watch as Joshua plays tie after tie, speeding up to a frenzy of ties.
"Learn, goddammit!" David exclaims.
Joshua switches back to Global Thermonuclear War, running scenario after scenario speeding up to a frenzy of apocalyptic endings flashing over the screens in NORAD's command center.
"What's it doing?" asks Jennifer.
"Learning." answers David.
Finally the screens go blank and Joshua concludes thusly:
Greetings Professor Falken. (Joshua's creator)
...
A strange game.
The only winning move is
not to play.
Although I definitely appreciate the pacifist punch line, I'm especially fond of the metaphor of the war machine learning the futility of war. One can only hope.
I expressed my concerns about the US war machine's almost regularly scheduled bloodlust last Summer:
What I find most disturbing is how often I have seen this story retold. This has been a pattern in all the US military operations I have witnessed in my lifetime. The pattern is disturbing for it's incredible consistency. We demonize the leader of another country, create a classic Hollywood-style villain, and then present ourselves as the heroic rescuer. It's like we cannot exist without some Hitler-like bad guy from whom we can save the world. Libya, Iraq I, Iraq II,Serbia, Afghanistan, Nicaragua. Most of these leaders have deserved their villainy. But I am deeply concerned about the pattern of our thirst for violence. There are plenty of villains in the world, but I've never understood why one villain is selected over another. Even more disturbing is the rhythm of the war machine. It's like the System, our military System, is a vampire craving a bloody fix every few years regardless of who is in the White House or who is in the Pentagon.
This movie reminded me that we did actually manage to retreat from the brink of full scale nuclear war even before the USSR collapsed -- a welcome little bit of perspective in light of our most recent WarGame.
State machines part seven.
On Lisp has a section on non-determinism which illustrates an augmented transition network compiler. There's definitely some state machine flavors in there, but there's so much more going on.
The picture (figure 23.6 on page 315) is a directed graph of conditions which map out a simple subset of English grammar. Sentences which fit the grammar can be represented as paths through that graph of conditions. Directed graphs, workflows, and state machines are all in the same family.
Last year I would not have understood that last paragraph. I would have understood the grammar and the language and some of the context, but I would not have grokked it. I wouldn't have been able to write it myself. In fact there were similar sentences in some older documents about Werkflow and I only partly understood what they were talking about.
The ATN compiler described in On Lisp generates code to search for a path through the graph which will match a given sentence and return the parse tree of the sentence. The code will do a depth-first search of the paths through that graph until it finds a match or has exhausted the options that might match. The code itself is fascinating -- continuations built up from closures building towards a Prolog interpreter.
Among other things, it's giving me a sense of what's happening inside a rules engine. The Jess rules engine was the first I encountered. It was being used in some code that we were supposed to integrate with Envoy at PlanetCAD. Drools was the other rules engine.
Prolog is all about searching through collections of rules. As Paul Graham takes me on a tour through his implementation, I am also learning context to help ground RDF and OWL. I still think that RDF and OWL and the Semantic Web smells like a bunch of cool technology looking for a problem to solve. But, the empassioned arguments about how cool the Semantic Web will be make more sense as I understand more about the mechanics of the things that would wander through webs of RDF assertions.
Reading On Lisp has been an enormously mind-expanding exercise in many directions. None of what I've read so far has had anything to do with objects nor object orientation. Functional and declarative are the buzzwords, not objects nor encapsulation. I feel like I've been admitted into an elite club where the real programming secrets are shared, or perhaps more accurately, where the other programming secrets are shared.
The world I knew before was mostly about objects and figuring out how best to encapsulate parts of a problem. Now I see that objects are but an island in a much larger sea. On another chain of islands are functions and closures. I traveled among those islands once long ago. I had forgotten about their charms. Now that I've returned I see larger patterns emerge in that chain of functional islands: continuations and rules engines. There's nothing quite like traveling in another land to expand your view of the larger world and its possibilities.