This book is a classic amongst computer programmers. Well, it's a four-year old classic. It captures the, uhm, zeitg^W movement towards unit testing and refactoring. It shares a problem with other classics: you've already heard its message, heard it from other sources.

Legacy code is scary. Within it lurk strange pieces of code. You look at a piece of code, a piece of code that had a purpose once. But that code has been changed over the years; now it has three purposes, each of which it kinda half-does by working with some other pieces of code which you wouldn't expect to be related. One way to deal with this is by surrounding the strange code with unit tests. Now if someone changes some code that alters behavior, you get an early warning. Blah blah blah.

He also lists a bunch of refactorings useful for making code quickly & easily testable. The first few of these in the list--I'd already heard of them. So I kinda zoned out for the rest of this part of the book.

Correct, Beautiful, Fast (in That Order) / Elliotte Rusty Harold

Emerging from the previous essay, I saw that this essay was going to be about verifying correctness of XML. My yawning muscles tensed in anticipation. But this essay was good. If you're writing an XML validator in Java, a tricky bit is: "The Java Character.isLetterOrDigit and Character.isDigit methods aren't perfectly aligned with XML's definition of letters and digits." Is it worth the processing time to use your own character-checking function?

Framework for Integrated Test: Beauty through Fragility / Michael Feathers

This essay is about a simple program that could have been made much more complicated. In some ways software engineers are like "real" engineers; one of those ways is: we over-engineer things. It's easier to write about adding things to systems rather than to write about leaving them out. What did you add to the system? You can write about that. What did you leave out of the system? Well, you left out millions of things. How do you write about that? This essay is about a simple framework that left out a lot of cruft.

Beautiful Tests / Alberto Savoia

I've already been won over to the cult of unit testing; I didn't learn much from this essay.

On the Fly Code Generation for Image Processing / Charles Petzold

Back in the day, we wrote self modifying assembly code. And by "we", I mean "not me". I didn't learn much assembly until I emerged from university. And by then, self-modifying code wasn't such a great idea anymore.

In this essay, Petzold shows how to apply the lessons of assembly code to... C# virtual machine instructions. I don't know much about C#, but it was fun to read how some bit-twiddlers are applying old tricks in a new environment to good effect.

When people ask me what I do at work, I clam up. Most of that stuff is confidential. Like when some of us geek gamers play-tested the geek game Race for the Galaxy some evenings, we knew it was a fun game, but we were sworn to secrecy. But now it's publicly available and I can say: it's pretty fun.

Actually, I think it's been publicly available for a while. But I forgot to post about it at the time, though I meant to. Just today I realized that I never did post about it. Intentions, actions, who can tell the difference? Anyhow, fun game. You can choose which phases of the turn you want to have happen, kinda like Puerto Rico or, uhm, that one card game? With the city? That game where you can be the thief, the assassin, the wizard, the priest, the... uhm... and you're trying to buy buildings with gold pieces, and they give you gems of different colors or something?

OK, I don't have a photographic memory for every geek game I've played, but nevertheless I remember this much: I remember enjoying Race for the Galaxy. Check it out.

I wrote a little hello-world getting-started guide for programming CppUnit on Ubuntu/Debian/Linux/whatever. CppUnit comes with a couple of tutorials, but I couldn't compile the code from either. I was able to tweak the code of one of them to compile--but when you're getting started, figuring out what to tweak ain't always easy. Anyhow, when I found something that compiled, I pasted it into a web page.

In other site news, a Lowell alumna wrote in with more info for the The Basic Eight vs. Lowell High School compare & contrast wacky funfest.

Last weekend was a puzzle playtest party for BATH3. BATH is a sort of pot-luck puzzle hunt in which each team makes up one puzzle. Game Control strings all of the puzzles together and runs a game around it. Part of running the game: organizing play-tests. I went for a few hours, wrestled with a few puzzles. There were a couple which made me think "Well... that's why you playtest." E.g., the one where we commented "The puzzle activity was fun, once we figured out what we were supposed to do, ahem, 55 minutes after we received the puzzle."

But there was this one puzzle that was just so elegant it made the whole day worthwhile. I shouldn't say anything about the puzzle, of course. All these things are still secret, secret until the game happens. I shouldn't even say which team's puzzle it was. Otherwise, teams trying to solve it would have a big hint: "Hey, guys, this is Team Such-and-Such's puzzle. I read about this one in a blog. If you find yourself considering a solution that is anything less than totally elegant, you're on the wrong track." I worked on it with Justin Graham and some guy named Josh. As the puzzle unfolded, I was so overcome with joy that I came as close to hugging Justin Graham as I ever expect to in my life.

On Sunday, I worked on constructing little puzzles. The BATH3 folks could use some mini-puzzles for pre-clues and such. So I've been picking up piece-work. I've been trying to make puzzles of various standard types. Some puzzle types which I always assumed to be nigh impossible to construct are easy. At least one which I thought would be easy to construct is nigh impossible. I wasted hours on Sunday on one puzzle which was easy to construct--but nigh impossible to tweak in the elegant way that I wanted.

One of my little puzzles got rejected because it was too similar to a regular puzzle which a team had made. During the play-test, I noticed that another team-submitted puzzle used a similar pirate-y puzzle-y gimmick as one of my little puzzles. Maybe I should be sad that we won't use my ideas. But I'm happy to find out that I'm starting to think like these people do.

But just starting. That elegant puzzle? I wouldn't have thought of that in years. For that, I think I need to watch the world around me, keep my eyes open. If I'm ever going to come up with something really creative, I need to think about everything.

I have been playing with Google Page Creator, a new service which hosts web pages and gives you a WYSIWYG editor for them. It's pretty neat. My favorite part: there are pretty templates available. That is to say, I can write some words and pour them into a page designed by the UI designers at Google. These people have some ideas that have evolved past the 1980s green-screen era.