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:

This entry was posted on Tuesday, August 22nd, 2006 at 6:18 am and is filed under Blogroll, Testing. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.

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:

This entry was posted on Monday, August 21st, 2006 at 12:52 pm and is filed under Macs. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.

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.

This entry was posted on Wednesday, August 16th, 2006 at 7:56 am and is filed under Blogroll. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.

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.

This entry was posted on Tuesday, August 15th, 2006 at 7:20 am and is filed under User Interface. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.