One of the nicest things about Cocoa is the user preferences architecture. It provides a nice way to store explicit user preferences, as well as implicit things like window placement. And what I discovered today is that Cocoa has very nice hooks to make that easy. For example, to make a window remember its last position, you just have to add one line to the awakeFromNib method:

[self setWindowFrameAutosaveName: @"LinkWindow"];

It’s so simple that there’s no reason not to do it. It took just a couple of minutes to add that to Blapp.

Last night I gave a talk on Extreme Programming and the principles of agile development to the Fort Worth IEEE/CS. It went very well—the attendance was good, there was a lot of interest, and there were many good questions at the end. I was filling in for Dave Thomas, who couldn’t make it due to a death in the family, so I was very glad it went so well. (I didn’t want them to be disappointed with the second-stringer!)

The first question after I concluded was from a TCU Computer Science professor who said, “As an academic, what can I do to prepare my students for environments like this?” My first answer was, “Can we have lunch? Because the answer to your question is long.” But then I gave her a short answer: teach your students not just to write code, but to read it, and read code written by other people, and then to add features to it to test whether they’ve understood it. She seemed happy with that (I gather she’s already doing a lot of that, as well). But there is more to it than that. Here are some things I’ve thought of:

• Teach the students the principles of emergent behavior, so they’ll be comfortable with the ideas of evolutionary design.
• Teach them about refactoring and the ways in which software is malleable. Teach them how this can be used as a feedback mechanism to incorporate what you learn into the design.
• Teach them the history of engineering, and encourage discussion about where software development currently sits on the path to maturity that the other engineering disciplines have gone through.
• Discuss the ways in which software development is similar to other engineering disciplines, and how it differs. Likewise, discuss similarities with art, craft, and science.
• Teach them skepticism about tools, and explain how the state of the software development art (in terms of platforms, techniques, and paradigms) always runs slightly ahead of tool support, so those who aren’t dependent on fancy tools have an advantage.
• Teach students that we don’t really understand software development that well, and the techniques they are learning today aren’t necessarily the best way to do things.
• You won’t have time to teach them everything about computer science, but at least give them glimpses of the many things they don’t know.

If anybody has any more ideas, please let me know. (Also let me know if you disagree with any of the ones I listed.) She’s hip, she gets it, and we certainly need computer science professors who genuinely want to know the answer to the question she asked. I want to give her great answers.

I’m sitting in Erik Hatcher’s JUnit talk at the Lone Star Software Symposium. Via Rendezvous and iChat, Daniel Steinberg messages me from the other side of the room: “Have you worked with CruiseControl?”

I sent back that Mike Clark had written about CruiseControl and an alternative, AntHill, earlier in the week. “I’m on it,” Daniel replied. As I was looking up Mike’s blog entry, I noticed that Erik was the one who told Mike about AntHill.

What I didn’t know was that AntHill was written by another guy we know, Maciej Zawadzki. Also unbeknownst to me, Maciej was sitting behind me. And later in the talk, Erik got around to mentioning both CruiseControl and AntHill. Fun.

Last night during the panel session at the Lone Star Software Symposium, nobody was surprised that an audience member brought up the infamous Pet Store benchmark. None of the panelists thought much of it as a useful or accurate benchmark, for a lot of good reasons.

One part of the discussion centered on the decision to build each version of the pet store according to the vendor’s recommended “best practices”. This resulted is that neither version of the app has an architecture I would recommend to clients—but more importantly, the .NET application is optimized for raw performance, while the J2EE application is aimed more at flexibility, maintainability, and robustness.

Jason Hunter had a really nice suggestion for the next round: instead of measuring the performance of the things, let’s set up two development teams, one for each version of the application, neither of them having seen the code before. Give them new features to implement, and see how long it takes. Given the existing code quality (poor) and some of the choices made in the J2EE version, it still wouldn’t be a really representative test. But it would at least be interesting, which is more than you can say about the original.

I’m a blissful Mac OS X user when I have my way, but I have a Windows 2000 machine on my desk at my current client, and they use Outlook for email.

A few minutes ago, I heard the voice of a coworker over the cubicle wall: “You’ll love this picture I just sent you.” I kept typing away on the document I was writing, and about 10 seconds later Outlook—sitting quietly in the background, behind Word—crashed. I didn’t open the message, or even click on Outlook. Fetching the message from the server was enough to make it crash.

Restart Outlook. Now I can’t log into the Exchange server. No more mail for me!

(And of course, the answer to all mysterious problems on Windows is to reboot, which is why I have time to write this blog entry.)