Sunday, August 23, 2009

This week's goals

Although it took me a week to jumpstart myself after the Career 2.0 talk, I'm setting a set of public goals for this week.

Each day, I need to do at least 1 of the following, and each must be done at least once by the end of the week:
  • Write a new JUnit test. In particular I'd like to write my first test that uses Abbot *
  • Read a new puzzler from the Java Puzzlers book I keep at my desk
  • Fix a Findbugs warning
* Abbot is a framework for writing tests that exercise your GUI components directly, as if the user is using a keyboard and mouse.

For my weekly goal, I want to contribute a patch to Hudson. Even if it's something very minor or just documentation.

I'll check back at the end of the week to report on how I've done.

Saturday, August 22, 2009

SSDs for developers - my experience so far

I'm sure a lot of people have read the Anandtech articles on Solid State Drives by now, and maybe even Joel Spolsky's story (the combination of the two is what convinced me, after all). Just how big of an impact will an SSD have on your day to day development performance? I can't answer the general case, but I can at least share my personal experience.

I've been using an 80GB Intel x25-m SSD for the last 4 months, and everything about my workflow is faster. The main tools I currently use daily: Eclipse, Maven, and Subversion, on Windows XP 64-bit.

building our full app with Maven (javac, lots of file copies, jar creation, and other related actions - a lot more than just compile):
500GB x 2 (RAID 1): 10 min 45 secs
80 GB SSD (after filling it up): 3 min 25 secs

full build w/o clean:
500GB x 2 (RAID 1): 8 min 32 secs
80 GB SSD (after filling it up): 1 min 42 secs

We're talking 3-4x faster, after the drive is full and at the reduced performance level it will remain at. If TRIM were present, this would be an even wider lead. Initially a full clean build took just under 2 minutes, as compared to 3 min 25 secs now.

Aside from rebooting to ensure nothing was cached and disabling antivirus scan, I took no special effort to make this a 'real' benchmark. It is only what I've observed, but is in no way scientific.

For Subversion I do not have any way to measure time, suffice to say - if you are familiar with opening a commit window in TortoiseSVN only to wait minutes while it calculates differences followed by finally listing your modified files, that is mostly a thing of a past with an SSD. 10-20 seconds is the usual max wait. For reference, this is on a 3GB workspace with 30,000 files. Note that the .svn directories double amt of files and size due to storing a 'pristine copy' of each file. The workspace, if exported, has 15,000 files.

Similarly with Eclipse, if refresh/clean/autocompile seemed to take a really long time - it is also a night and day difference on an SSD. Rarely am I waiting for Eclipse to finish now.

Having an SSD eliminates a lot of time I'd otherwise have to waste waiting for something to finish. I think they are a worthy investment, and they are getting cheaper every month. I bought mine only 4 months ago, and the price has dropped from $400 to $229 for an 80GB Intel SSD. There are also a lot of competitive drives in similar price ranges now.

Here are a couple of things to check when looking into an SSD:

Make sure your motherboard's SATA controller is modern enough and supports AHCI mode. The original, older machine I tried it in (it was a 3 1/2 to 4 yrs old Athlon X2) could not see the real benefits of the SSD. I think any Core 2 Duo/Quad or more recent motherboard will be fine.

Buy a drive with a firmware that supports TRIM, or from a vendor that has released a manual TRIM utility. I would not trust any vendor that promises to deliver TRIM firmware or a utility after-the-fact. I had the impression TRIM was coming with my drive, and it looks like I'm out of luck with my first gen Intel drive. Who knows what the timeline is for TRIM on the second gen Intel drives. I believe all recent drives w/ an Indillix controller are fine, and I believe OCZ is even working on a background-TRIM firmware that works in XP. (It will be some time before my work environment is Windows 7...). Also, if you are a non-windows user, pay special attention to the TRIM firmwares. I believe a lot of them may only support TRIM on NTFS.

Avoid JDK 1.6.0_14 for development (missed breakpoints while debugging)

I've occasionally had some debugging pains with Eclipse recently - I've been using JDK 1.6.0_14 for a while. As it turns out, there is a bug in the JDK that causes breakpoints to be missed when debugging.

If you are using JDK 1.6.0_14 to develop, upgrade to JDK 1.6.0_16 - it was released to fix this single bug. (you also as a benefit get 1.6.0_15's security updates)

This caused me some headaches, as it didn't always miss my breakpoints in the debugger, only occasionally... I didn't realize the core problem until a coworker informed me.

Here's a link to the bug:

Release notes for 1.6.0_16:

Download links to the JDK are somewhat cryptic looking, but here goes:

If that fails for any reason, just go to, click on Java SE on the right, and there should be a JDK 1.6.0_16 (non EE) link on the page.

Thursday, August 13, 2009

A great night (went to Career 2.0 talk!)

I just had the fine privilege of attending Jared Richardson's "Career 2.0" talk at my local java user group. The talk is based on his book (with Matthew Bass).

One of the things he recommended we all do is create a blog account to write about problems we encounter and solve in development. One attendee created one during a break at the meeting - I settled for after I got home. I already have a personal blog, but I wanted to dedicate one to coding.