The Cafes

There are many reasons to write your tests first. An oft unmentioned benefit is that it makes the programmer stop and think about what they’re doing. More often than you’d expect, the obvious fix is not the right answer; and writing the test first can reveal that.

For example, recently Wolfgang Hoschek pointed out that in XOM the Attribute class’s setType() method was failing to check for null. Once he pointed it out, it was an obvious problem so I opened up Eclipse and got ready to fix it:
Read the rest of this entry »

In the good old days of Mac OS 6, 7, 8, and 9, it was possible to automatically mount network drives at startup. This no longer seems to work in Mac OS X. There’s no longer a little box you can check when mounting a network drive to say, “items will be opened at system startup time”. You can still do this, but it takes a little more work. Here’s how:
Read the rest of this entry »

Eclipse 3.2 is driving me nuts. For reasons I just can’t understand or debug, it keeps throwing NoClassDefFoundError when I try to run most code in my project:

Exception in thread "main" java.lang.NoClassDefFoundError: nu/xom/Element

However, it can compile the classes it complains about not finding just fine. There appears to be a disconnect between the path the compiler sees and what the interpreter sees.
Read the rest of this entry »

Long-running operations that require occasional user input should nonetheless not block while waiting for it. They need to accomplish as much as they can as quickly as they can. If necessary the problem should be divided into the pieces that require user input and pieces that don’t so that progress can be made on some pieces while waiting for input on other pieces. This was recently brought home to me while evaluating the ChronoSync file synchronization tool.
Read the rest of this entry »

In my Human Factors in API Design presentation at Architecture & Design World this past week, I claimed that classic optimization is rarely necessary. Pulling operations outside of loops or reducing the number of operations in a method rarely has any noticeable effect on performance.^* Most real performance problems come from doing too many fundamentally slow operations; for instance, writing to the disk or reading from the network.

For example, you don’t want to open and close a database connection for every operation. Even on a LAN, that can easily hit you with one or two seconds (not milliseconds but seconds) of overhead per call. Do that a few hundred times and suddenly you’ve got an unusably slow application. Instead you need to:

1. Cache and reuse the database connection(s) rather than constantly opening and closing new connections.
2. Figure out how to reduce the number of database queries your application makes.

¹

Most programmers who write database facing applications already know all this. There are numerous frameworks designed to make this sort of optimization automatically. That’s what a lot of middleware is about. Programmers who work with databases have either learned this lesson or involuntarily changed careers. It’s that important.

However, recently I’ve realized that another field has just as big a problem with network overhead as do database apps. However in this field the lesson does not seem to have been as widely learned. That field is backup software.
Read the rest of this entry »