There was yet another huge flamewar over whether or not debuggers are useful or the tools of lazy slobs. Count me in the former: I like using a debugger. Tests are great for shaking out issues with code and for maintaining confidence. However, when things get rough (and they will), it’s nice to look at exactly what’s going on inside the code.

My AGP-based, first generation Athlon 64 was getting long in the tooth, and didn’t have a lot of upgrade room. With an eye towards doing more .NET development, and…uh…Bioshock’s impending release I built a new machine.

• Athlon64×2 4000+ with stock heatsink/fan
• ASUS M2N-SLI mainboard
• 2GB of RAM (Crucial, of course)
• ATI x1950Pro video card
• PC Power & Cooling 610 power supply

I reused a SATA drive and Antec case I had already. The power supply seems like overkill but that video card (crucial for productivity), eats a lot of amps. The build went easily, and even with considerably more horsepower this PC is quieter than the old model.

I’m also trying running as a limited user under XP on this machine. I’ll fast-switch to an admin account when I need to install something. Now to get Visual Studio and…uh Bioshock installed.

I just discovered yield. Wow. After using some of the new tools languages like Ruby provided (blocks, process control), it’s been hard to go back to Java. Nice to C# is up to more than just adding syntactic sugar (cough, Java5, cough).

I’ve been coding Java for a good seven years now, ever since I walked away frustrated from writing business applications in lower level COM+, ATL, and C++. Tonight I dug into a .NET training book for the first time, as I plan on getting certified mainly as a goal for learning. It’s really hard to look at C# as a Java programmer and not see the overwhelming similarities. System.Console.Writeln isn’t fooling anyone. That said, I’m already seeing some niceties. Tonight’s example:

bool? flag = null;

The ‘?’ allows you to indicate the variable is nullable. Java is going to make you think about ints and Integers, even in the Java 5+ world.

…And I must testify. I’ve been making a conscious effort to make as much of the new logic I’m writing unit-testable, and it really makes the development process smoother. I can’t stress enough how important and comforting it is to be able to make changes to complicated logic and be able to immediately test for regressions. There are some pretty big pieces of logic in my current project just crying for unit tests. Now I just have to convince the customer it’s worth it.

When installing Boot Camp on my MacBook Pro, I received an error that files couldn’t be moved to create the Windows partition. Rather than take the Boot Camp Assistant’s advice and format the drive, I decided to enter the world of OS X Disk Defragmenting tools. I settled on iDefrag. The reviews were positive, and the bundled CD Maker app makes it a clear winner: you can build a bootable iDefrag CD that will be able to defrag your Mac’s boot drive.

After a successful defrag pass, I was able to partition my drive just fine.

I ran into this issue hard last week when I tried to install the port for rdiff-backup using MacPorts. Rdiff-backup depends on python24, and when trying to build that port I was getting this error:

make: *** [Python/mactoolboxglue.o] Error 1

Ultimately, I was bitten by being space conscious when I installed XCode on this Mac: I hadn’t installed the Quicktime, CoreAudio, or OpenGL SDKs since I had no plans to use them. The python port, however, needs them.

I was recently tasked with refactoring a mass of business logic that selected the appropriate machinery from a large group for a particular job configuration. The code as written was a huge tree of if/else statements inside a loop over the machines. Each statement would look at a particular set of job characteristics, and check if the current machine could support the job. This code was quite hard to maintain, as any several hundred lines of branching code is prone to be. What I needed was a little rules engine to evaluate my set of rules for every machine…

Rather than brush up on my LISP and Rete algorithms, I decided to use my favorite Jakarta project: Commons Collections. Given that my rules simply accepted or rejected a machine, I could implement each as an instance of the Predicate interface. Its single method boolean evaluate(Object object) is a perfect match for my needs. We can loop over each available machine, and pass it to the evaluate method. If the call returns false, the machine is not appropriate for the job. Common Collections will even take care of that loop for us with the CollectionUtils.filter method. Given a Collection and a Predicate, this removes items from the given Collection that evaluate as false to the Predicate. What’s that? It only takes a single Predicate? That’s where the PredicateUtils.allPredicate method comes in. It will allow us to evaluate a Collection of Predicates as a single unit.

Now all of these rules are extracted as small units that can easily be tested on their own. In addition, it’s very easy to manually and programmatically add and remove rules from the system.

Over at the MD blog Darren has illustrated more dangers with Hibernate setters.

This is one of the rules of thumb when implementing Serializable - you need to override hashCode and equals. I was reminded of that today, when some code wasn’t working in client-server mode, but did in a non-RMI mode.

An enumeration class (pre-Java 5) was used as the key to a *Hash*Map. The client stored a value with a key (EnumClass.AVALUE). The server wasn’t finding that value in the deserialized Map. Why? Because the default hashCodes for EnumClass.AVALUE were different in the client and server JVMs.