Intel SSD Toolbox on WinXP x64

If you use an Intel x25-m (G2) on Windows XP, then you've probably been eagerly awaiting the Intel SSD Toolbox now that both the TRIM-capable firmware and new toolbox are released. I was too, so I downloaded it today.

I just installed it on a 64-bit XP box, only to see this screen when I tried to run it:

Having no idea what this means, I googled it. (which quickly pointed me to the readme, which is linked on the download page for the toolbox itself. Silly me, I should have read it first. The readme document used a very wild font, but it boils down to this:

Without a hotfix, the toolbox does not work correctly on Windows XP 64-bit. The hotfix you need is supplied on this page (also linked in the readme). The details don't look related to shadow copying, and you have to jump through a couple of hoops to get it.

After you 'View and request hotfix download', give Microsoft an email address, and submit a form...you will get an email with a link to the hotfix, and the password for the password-protected zip file it contains with a password that changes weekly! I have never before had to 'request' a hotfix file, let alone enter a password - I completed the process diligently though, as a secret agent might do, and now the Intel SSD Toolbox is working on my Windows XP x64 machine.

NOTE: The reason it's so much work to download the hotfix is probably because, as of this writing, the hotfix has not undergone full testing. Also, it is a very specific hotfix for Windows 2003/XP x64*.  It recommends staging (i.e. non-production upgrade first). You should backup your files and perform this on a non-critical machine first, or update at your own risk.

* windows XP x64 is based on Windows 2003, so it is distinct from 32-bit XP.

This post is for personal reference, as well as for the 10 seconds it might save someone else out there. It seems like kind of a strange edge case...

Summary on My Month of Writing

Writing (and clicking submit) every day for a month has been an interesting experience. It's been fun, exciting, frustrating, and time consuming. With this post I can say that I have met my goal to post every day for a month. I have a new appreciation for people who can write in serious quantity - because it's a lot of work. The quality of my posts so far has been so-so on my personal rating scale, but with a few notable good ones.

I noticed that past the half-way part, it became difficult to have enough complete content to write about. I had plenty of ideas, but many of them weren't really refined or complete enough to make a good post about without further effort. I can see how writer's block could really suck.

Of the topic ideas I listed in my October post, I covered most of them to varying degrees. There are some that I have not yet written about, though:

• More on SSDs

Specifically, I want to showcase my build server results with SSDs. It really makes a difference for us, and I want to get some good numbers and real details.

• Java 7 feature (my thoughts)
• Test ownership
• Notable programming books in the last 1-2 years

There are other things I wrote about, that I want to get into better detail on, such as:

• More on build tools (Maven 3 and Gradle, specifically)
• My Erlang experiences, as I learn it
• Solving my Apache/HTTPS/TortoiseSVN authentication issues
• What are some notable programming books in the last 1-2 years?

And some topics I hadn't really gotten into that I'd also like to write about.

• Guice, and other dependency injection frameworks (I have not used Spring or Guice)
  
• Taking Linux Mint for a spin (version 8 just came out)
  
• Experimenting with Saros, the Eclipse Distributed Pair Programming plugin (I've yet to try it - but I am enthused!)

There are also some topics I'll keep a surprise, for when I'm better prepared :) I won't be rushing to post by midnight from here on in, so my focus will be on fewer (1-2 a week), far more detailed posts. It seems like at least a couple people have read some of these posts - I hope you'll continue reading and commenting.

Goals for the week starting 11/30

Results from last week:

• I finished reading 'The Tipping Point', and started my next book
• I did poorly on the Erlang front - I only read a few pages and installed the Erlang package for Windows. I need to do better next week.
• I did finish Java Puzzlers
• I did NOT experiment with any more new build tools. I fail on this one. 

I did ok - but overally I need renewed effort on my more involved goals this coming week, as I didn't tackle anything meaty.

Goals for the week starting 11/30/09:

• Continue reading 'Pragmatic Thinking & Learning'
• Get through the first 2 chapters of 'Programming Erlang', and if possible, code a Project Euler problem solution in Erlang.
• Practice my TDD more
• Post on Monday, completing my 1 post a day for a month goal as part of NanoWrimo

After Monday, I will start aiming for 1-2 hearty posts a week, with gradual cleanup of my existing posts.

Next in my reading list

The next book in my reading list is:

Pragmatic Thinking & Learning: Refactor Your Wetware, by Andy Hunt.

I started reading it early in the week, and it will be part of my nightly reading until I finish. I'm always interested in better ways to learn - and I saw Andy Hunt's talk on this prior to it becoming a book. I'm not sure why it took me so long to get around to it - but it's finally in my goals and I'm reading away :)


In the queue after this is:
- Peoplware
- Java Concurrency In Practice
- Filthy Rich Clients

What are people reading these days? It's been a few years since I've looked at a recommended reading list.

Programming Puzzlers, Reading, and Practice

I've had Java Puzzlers for a long time. I kept it on my desk at work, and sometimes during a full rebuild, I would read and try to figure out the next puzzler. I'd usually drag a coworker into it, too, which added to the fun. Slowly (quite slowly - over a year at least!) I've made my way through the book, and I'm down to the last 3 puzzlers - which I intend to finish tonight or over the weekend.

If you're not familiar with the book - most of the puzzles showcase a smallish snippit of code, with the question of 'what does it print' (or does it even compile). These puzzles are fun to think about, but most of them don't involve writing any code. (Some of them DO ask you how to write code that accomplishes some strange behavior, though - but only a few).

I'm looking for, or rather I suppose I'm writing about what I will do next. I have a couple of ideas - one being to finally march my way through Programming Pearls. The favorite book of one of my favorite professors in college. It provides ample coding exercises - many of which involve low level tricks.

Another idea that didn't occur to me until I started writing this entry is Project Euler. It's a great source of coding problems. I've done maybe a dozen previously, but as of this writing there are 265 of them. What's great is these are the type of problems that are useful to repeat again in different programming languages.

What's got me focusing on this is some recent posts I've read about Coda Katas. In particular I read this post on the Object Mentor blog tonight. There are a lot of links to other material there.

One further idea is to look up problems from the ACM's International Collegiate Programming Competition Problem Set Archive. There are countless good programming problems on that page.


There is definitely value in practicing what we do. This applies to any craft - but it seems to be sometimes neglected in ours. I think some kind of coding practice (in addition to testing practice) will be in my goals for next week. In particular to solve a new Project Euler problem or two, and to maybe do one from Programming Pearls as well.


What resources do you know of for good programming problems?

Technology I'm Thankful For

As it is Thanksgiving, I think I will write about what technology I am thankful for.

I'm really glad MySQL exists. It's just really pleasant to develop against.  It couldn't be simpler (well, maybe it could be - but I challenge someone to provide me with an existing example) I've developed both Java and C++ applications with Microsoft SQL Server and Oracle, and while I think there are good tools in both of those realms (especially in the case of SQL Server), MySQL is just so light weight and easy to develop against by comparison. It just rocks. As with anything, it isn't perfect - but I am thankful I get to use MySQL.

I'm thankful for the great variety of virtualization software that is available today. VMWare and VirtualPC have been around for a long time, but now there's also Virtualbox, and on my Mac I use Parallels. I can virtualize on any machine I use. Hardware CPU support makes it even better. Virtualization rocks as a tool for experimentation, and it has plenty of other uses.  For instance, we currently do our WAN testing by using VMware server and a WANem Linux ISO

I'm thankful for the abundance of operating systems I get to use these days. I'm not just a windows guy - I have a Macbook Pro, so I use OS X regularly, and I  have for a long time used Linux from time to time. I keep meaning to explore Solaris more - as I have a fascination with ZFS that just won't go away. I am keeping tabs on the current legal issues, though - and I wish the ZFS team the best.

I'm thankful that fast internet is now fairly ubiquitous in the states. I can't fathom what it would be like if I still had a 33.6K modem.

I'm thankful for Eclipse. It's such a powerful and flexible IDE. I don't use it because it's free - I use it because it KICKS ASS. It helps my productivity and doesn't get in the way. There are tons of plugins, great keyboard shortcuts, and it is just very solid all around. Even after using it for 4+ years, I still learn new things that make it even better.

I'm thankful for how far hardware as come, but I can't even begin to estimate where we will be in another 10 years. I've had my hands on a keyboard for at least 15 years (maybe longer), and there is no doubt an interesting road ahead. SSDs, multi core processors, and high performance video cards. It's an exciting time in hardware.

I'm thankful for the intense browser competition these days. It seems like every single vendor has rewritten their Javascript engines entirely in the last year or 2, and it still continues. Chrome, Firefox, Safari, Opera - they all have strong points. I continue to favor Opera, and I can't wait to see Carakan and Vega come out. Opera knows where it's at - referring to ECMAScript by its real name. It's the only browser that comes with everything I want, with no customizing rquired. That said, I do also use Firefox, Chrome, and Safari. IE8 isn't bad, either.  Even the IE9 team is creating a new Javascript engine. It's an exciting moment in browser history, and I can't wait to see what happens next.

These same Javascript engine extreme performance improvements give me hope for other languages. I've  liked Ruby for quite some time - but there's no denying performance can be an issue. It looks like 2010 will be the year of Ruby VMs. I am curious where things will go.

A note to readers - I am participating n National Novel Writing Month, in particular it is spurred by the Pragmatic Life entries. My participation is by posting a blog entry every day - most years, I don't even think I'd be on a computer on Thanksgiving - but I must write something every day this month - so there's my post. I hope everyone had a great thanksgiving.

Eclipse Plugins Galore

I saw  link entitled 30 Best Eclipse Plugins on dzone today and thought it merited sharing. I've been a long time Eclipse user, but most of these plugins are new to me. There's all kinds of plugins for doing web development and things, but in particular I am interested in these:

• Mouse Gesture plugin
• Eclipse SQL Explorer
• Saros - distributed pair programming in eclipse

I am particularly curious about the distributed pair programming plugin. I've always wondered what other ways there are to pair program besides sharing 1 keyboard. It seems like it could be a good productivity tool even if you're in the same office. 

I'll also list my favorite Eclipse plugins, prior to reading the above. I'm somewhat surprised none of them are on the list.

• Findbugs plugin (less useful once you have Continuous Integration that reports this, but still cool)
• EclEmma (Code coverage  highlighting in Eclipse with an Emma junit test runner)
• SwingExplorer - very sweet way to delve through swing code and familiarize yourself with the GUI code in a project

For more plugin ideas, you may want to read this StackOverflow question.

What Eclipse plugins do you use?

From XP to Windows 7

I've been using Windows 7 at home since the public beta came out in January, followed by RC1. I recently transitioned two of my home PCs to the retail Windows 7 Home Premium a couple weekends ago. I made the transition on my workstation at work last week.

So far I'm very pleased with the transition, and I haven't had any major issues. A few applications had issues installing explorer context menus, but that wasn't a perfect situation even on XP 64-bit, and I've mostly sorted it out at this point. Every Windows 7 machine I currently use is a 64-bit install. For the last year I've been 64-bit  (XP) on my work machine, so I am already familiar with any platform differences there.

UAC doesn't bother me - I'll most likely dial up the setting a bit, as the default isn't strong enough protection.

One thing that currently gets me is I can open my.ini (MySQL configuration file) in notepad (from explorer), but then I don't have permission to save the file once I edit it. It would be nice if it prompted me, instead of just failing. I do not see a right click menu option for "open as admin", but running notepad from an admin console solves the problem.

I tried "Windows XP Mode" for the first time today at work (it being Professional - which is a requirement). I was unimpressed with the performance of the installation of our app (4GB install and tens of thousands of files), but the actual execution speed of running applications in it was fine. I'll probably use it occasionally, but I don't think there are a whole lot of cases where I will need it.

What transition issues are people hitting? I'm curious how many people are trying it, and more curious when business roll outs will start in earnest.

Goals for the week starting 11/23

Results from last week:

• My emphasis on fast tests has gained some stickyness in the office. I have a way to go personally, but progress is being observed.
  
• Read another 50-60 pages of 'The Tipping Point'
• Did 2-3 more Java Puzzlers (in the last, 'advanced' section)
• Made daily blog entries - one week and one day left to achievement of my larger goal

With Thanksgiving, it is a short work week. This will give me extra time to experiment and soak in some new knowledge. I still need to practice my TDD more, and I want to really get in-depth with some build tools.

Goals for the week starting 11/23/09:

• Finish reading 'The Tipping Point'
  
• Get through the first 2 chapters of 'Programming Erlang'
• Finish the remaining Java Puzzlers
• Experiment more with new build tools

Make Your Brain Hurt With a LOTY

I believe it is The Pragmatic Programmer that recommends learning a new language every year. With an emphasis on something that will make you think in a different way.different. If you're in Java, moving to C# is not a big enough switch to make your brain hurt.

It's been 4 years since I read Pragmatic Programmer, but I haven't really put serious effort into any completely different languages. I'm going to make it a goal to start learning Erlang for my LOTY, learning something new each week. Fortunately, I already have Programming Erlang, so I should have some good material to guide me.

If you are in the Java world - there are some great candidate languages that can run on the JVM. Meaning you can start  playing with them right now in a Java environment. Scala and Clojure are probably the most frequently mentioned, but I believe there are over 200. This makes it really convenient to try new languages, as if you want to showcase any projects to friends, all they need is Java.

To sum up - there are less excuses to NOT try a new language these days. There are a ton of options out there, so try one and have some fun. I'd love to hear some suggestions.

Practice your TDD

Misko Hevery made a great blog entry Tuesday. He posted a sample project for practicing TDD. We know that Beginners Need Steps, and that's exactly what he provided. Testing is a skill that is not innate - we as developers need somewhere to start.

In his post, he provides a starter project that can be grabbed from a Mercurial repository and used to practice TDD. The basic code is already layed out, including the first few tests. He even describes how to turn on a setting in Eclipse that will run your tests every file save. Slick - I didn't even know that was possible. That is serious TDD.

I consider this a personal testing homework assignment - I encourage anyone reading to do the same.

I will try to remember to post my resulting source & test code when I finish.

Silent JDK Deployment on Windows

It's pretty easy to find documentation on how to silent install JREs, but for some reason it's hard to find a full example for silently deploying recent JDKs. Today I needed to deploy 20 JDKs or so, so I decided to tackle this. I needed to deploy JDK 1.6.0_17 (both 32-bit and 64-bit varieties). Since they're build machines, I don't really want the public JRE installed, which may have auto update notifications.

Doesn't Hudson know how to automatically install JDKs now, you ask? Why yes, it does, but it doesn't always have the latest JDK updates. Apparently update 18 fixes some obscure issue that one of our customers has, and according to Ninite it is already out, but I can't yet find it on java.sun.com.(Apparently snapshot releases can be found here.)

After deducing the JDKs use an MSI installer (although packaged within an exe), I enabled verbose logging and found out the names of the feature groups:

• PublicjreFeature
• JavaDBFeature
  
• DemosFeature
• SourceFeature
• ToolsFeature

These are the important part, as they are what you specify using ADDLOCAL=list,of,features to determine which features are selected during silent install. To find any other general install options, all you need to do is run "msiexec" at a command prompt and it will pop up a dialog of options. Thanks to AppDeploy's page on the JDK I also found out some other info (like where the JDK .msi gets extracted to - you can use Orca to examine the MSI file if you're really curious).

On to the point, to perform a silent installation (in this case jdk 1.6.0_17), simply do:

jdk-6u17-windows-i586.exe /qn ADDLOCAL=ToolsFeature,SourceFeature,JavaDBFeature INSTALLDIR=c:\jdk1.6.0_17 REBOOT=ReallySuppress

• /qn means "No UI"
• INSTALLDIR is self explanatory
• REBOOT has a few options, I chose ReallySuppress
• ADDLOCAL - Specify a comma-separated list of features you want from the list shown earlier, or you can use ADDALL
  

I saw a lot of examples listing: /s /v"/qn ADDLOCAL=ALL ... ...", this seems to spring from the Java 5 JRE silent deployment guide, but it really need not be that specific. Maybe /s and /v provide some value if an error occurs, but the  /v"/qn OPTIONS..." seems a bit silly, and I am surprised it even works that way.

At last, I have my auto install script that I can remotely run on a bunch of machines with PsExec.

A Quick Look At Gradle

I'd say up until a month or so ago, I knew about Gradle but I had no real idea what it offered. I knew it was more elaborate than Gant, but that was all.

It's about time I took a closer look at Gradle. The most obvious cool feature is that you can write your build scripts using Groovy. This is sweet. Beyond that, it is probably easiest to list Gradle's own summary, as of this writing:

• A very flexible general purpose build tool like Ant.
• Switchable, build-by-convention frameworks a la Maven, for Java, Groovy and Scala projects. But we never lock you in!
• Groovy build scripts.
• Powerful support for multi-project builds.
• Powerful dependency management (based on Apache Ivy).
• Full support for your existing Maven or Ivy repository infrastructure.
• Support for transitive dependency management without the need for remote repositories and pom.xml or ivy.xml files (optional).
• Ant tasks and builds as first class citizens.

So... dependency management? check. multi project builds? check. Easy to write general purpose scripts? check.

What I think has extremely high potential is the idea of pluggable build frameworks, a la maven support. Use all of the best pieces of tools from one - Gradle. I think they could go a really long way with this, and it will remain a strong contender as I also take a closer look at some of the new Maven 3 features.

Downloading and extracting gradle-0.8-all.zip, one thing is immediately obvious. Comprehensive documentation and examples FOR THE WIN!

I can't even describe how frustrating playing with maven 2 was three years ago. Documentation was hard to understand, and the basic example tutorials just didn't cover my needs. I ended up banging my head a lot, when all I really needed was some good sample poms illustrating all of the tool's features. Gradle provides this out of the box and scores major points for it. I haven't even looked at the website docs in detail yet, but they seem easy to follow.

Some Maven 3.0 Info

I do intend to investigate Gradle, but I can't shake the feeling that Maven 3 will really rock. On that note, about all I have time for tonight is to pull together a few links. Nothing a couple minutes of searching couldn't accomplish, but hopefully it is of value.

Here's a presentation that happened all the way back in April. I'm sure there are more recent ones, so I'll try to update with additional links. There are (not surprisingly) quite a lot of good posts on the Sonatype blog. In particular, there is a series of posts titled "Paving the desire lines". It's very satisfying reading a developer talk about the small finishing touches to a project with real passion. I haven't read the whole post yet (and I spot 2 parts so far), but it has my appetite whet.

Maven 3.0 alphas have been coming out recently, with Alpha 3 coming out last Friday. I just grabbed it tonight (seems to be alpha 4 now) and took it for a quick spin. To test it, I built Hudson/main, which has 4.0.0 POMs.

This merits close following...

UPDATE: Walter linked a more recent video+slide presentation by Jason van Zyl

Java Build Tools

There are a lot of build tools for Java. More than I have seen for any other language I've used. When working with Java, I've used Ant, Maven 1, and Maven 2. I know of at least a few more, and I recently found this post with a link to a poll on what build tools people are using this year (for Java).

If you navigate to the 'What Build Tool are you using in 2009?' poll (I can't post a direct link, sorry, but there are only 3 polls to choose from), you will see quite a selection of tools.

Unfortunately, right now I'm that single Maven 1.x user (along with some Ant). It's tough - things work well enough, but there is no direct path to Maven 2.x for us (oh maven.xml, you looked so helpful, but you've trapped us!). In its defense, this project was using Maven 1 back in 2004. It's not surprising that in 5 years some cruft has accumulated.

I am fed up with having to write build scripts in XML, so even if a Maven 2 migration path was simple, I'm not sure it's desired. Gant would get rid of the XML while keeping familiar territory - but I feel like I need something richer than basic Ant. Gradle looks very promising, and I've been meaning to read up on some of the threads on where Gant and Gradle are going to get a better idea of things, but I haven't yet.

Lo and Behold, while pulling up links for this blog post... I stumbled upon a post about Maven 3.

Support for several build script file formats? YAML, Groovy? Hell yeah! I am going to have to do my research on this one.

I wasn't quite sure where I was going with this post, but I think I'll sample some of the build tools I've mentioned (including early maven 3 builds) and report in on them. If I'm motivated, maybe I will do a 'Hello World' project in each build tool. Gant, Gradle, and Maven 3.

Goals for the week starting 11/16

Results from last week:

• Much of my week was reactionary, so I didn't write much new code and I fail on the 'test more' front.
• I read another 100 pages of The Tipping Point
• I did a couple more Java Puzzlers (on 83 or 84 of 95?)
• I wrote and posted my book review
  
• Updated Hudson on latest build server to use 1.333

Goals for the week starting 11/16/09:

• Continue emphasis on testing
• Continue reading 'The Tipping Point'
• Continue doing Java Puzzlers
• Keep posting daily

My week will be quite busy again, so I'm taking it a bit easy.

Using a Vertical Mouse - 4 Months In

Earlier this year, I started experiencing frequent and worsening wrist pain in my mouse hand. It seems to be a result of keeping pressure on my wrist when using a mouse. I bought some wrist straps, and decided to invest in a vertical mouse.

What's a vertical mouse, you say? Mine looks like this:

The concept is that by keeping the hand in a neutral position, wrist pain will be alleviated - and it does.This mouse is amazing. It has basically eliminated my wrist pain. There's just one problem, well, two.

1. They're hard to find (the website looks somewhat abandoned)
   
2. They're expensive for what they are 

Even so, this single device keeps my life in computing comfortable. There is a learning period - wherein you are nowhere near as accurate as with a normal mouse. 4 months in, I find its use very natural.

Now this is a mouse made to address a specific problem. I'm not advocating widespread use (but maybe I should? It would make my life easier...). I literally do not travel without one when I know significant computer use will be in order.

What, if any, special input (or other devices) do you rely on for PC use? Have you taken the time to find a good keyboard (and normal mouse)? If not, why not??? If you spend half of your day using something, it should be as comfortable as possible.

TortoiseSVN no longer remembers password

In my workplace, we've been plagued with this issue since switching from http to https (maybe a year ago). At least, I think that's when it started. Whatever the reason, TortoiseSVN constantly forgets my svn credentials. I want to get to the bottom of why.

Here is the interesting bit - it can't really be tortoise' fault, as it clearly still knows the password based on the following behavior:

After it prompts you for the password that you had it remembering (that you had told it to remember previously), if you hit cancel and try your commit again, it won't prompt and it will work. Clearly the credentials remain stored, but some client/server interaction causes it to fail to authenticate sometimes. This happens very frequently. Most of us don't even bother checking the box anymore. (which would be a better practice from a security standpoint, but we all have our faults)

The moving parts:

• Subversion 1.5.x Server
• Apache 2.x
  
• TortoiseSVN (1.5.x)
• Active Directory (our authentication is against our standard AD credentials)
• HTTPS

I am sure there is a solution out there. I will keep this post updated as I progress...

Book Review: Career 2.0

It's about time I posted a review of Career 2.0 - by Jared Richardson and Matthew Bass. In particular, I purchased the print version of the book. There is also a digital version, and the distinction may become important later on.

Inspiration and General Value

I got the book after attending the 'Career 2.0' talk at NEJUG. Like the talk, the book ranks very high on the inspiration front. After all, the talk is why I started this blog. If you're looking for ideas and a general kick in the butt, this is a good book for you. I enjoyed reading it, and I feel I got a good value out of it. As a direct result of reading it, I've been actively working on my career, setting goals, and generally doing more good things.

I even credit the book with successful weight loss. In it, there is a very profound statement regarding goals. If you don't break them down into steps you do today, they don't get done. I can't eat dessert tonight if I want to lose weight. "I'll start dieting next week" does not work. Neither does I'll write tests tomorrow, or I'll learn a new language next year. This applies to everything in life.


Polish, Quality, and Nitpicking

Now that I've talked about how motivational the content is, I have to take a step back and report in some unfortunate quality issues. To be frank, there are a lot of editing errors, as well as some print errors that  detract from an otherwise good experience. I find it really distracting when I read a sentence that has extra words that don't belong, or that are in the wrong order. As below:

...it's possible for you to be unexpectedly job hunting at the time same as hundreds... 

Now I can forgive an error or two, but there are a lot of what I would deem trivial wording issues that caused me to re-read sentences 2 or 3 times. These should have been caught prior to print, and hopefully these were fixed in the digital version, or in future print versions. Mine, however, has some serious issues. There are grey box side stories in various parts of the book. There were 2 instances where a sentence was cut off by a grey box (or a sentence in a grey box abruptly ended) and never finished. Content is missing. I also assume that in a digital version this would not have happened, and it is some artifact of things getting cropped badly in print only. Either way, I have the print version and this really bummed me out.

Final Conclusion

I enjoyed the book, errors aside, and there are some good stories and good advice in it. There are hand-drawn sketches throughout the book, which I found a refreshing change from the usual. I will certain be referring to the book in the future, and will be re-reading certain portions. Were it not for the print issues, it would get a strong recommendation. As it stands - I would say try the digital version if you want to read the book. There is definite value, there are just a few distractions as well.

Hidden Eclipse Search Feature

Eclipse has some really handy search options when you right click on member variables, but for some reason they are disabled by default.

You can enable the extra options by unchecking the checkbox for:

Preferences -> Java -> Use Reduced Search Options

Here's the before (with appropriate part of right click menu cropped in each version):

And here is after:

It's incredibly useful to be able to do easy searches for read and write access on your variables, so hopefully someone out there sees this for the first time. Hats off to my boss for sharing this knowledge with the rest of us today - he has used it for a long time.

Afterthoughts on Upgrading My PC

When I was younger, it seemed like I needed to upgrade my computer constantly. Before college, and before my professional career started, the only aspect of my computing experience was at home. It makes sense that it was more important then. For a time, every year or two it seemed like it was a must. (From the 486 (DX4 baby!) to Pentium 166 to Pentium II to PIII to Pentium IV days).

I'm not sure if it just felt like it happened quickly, or if it really did. At the moment I'm not feeling like firing up wikipedia.

After a certain point, it seems like it became less important. Once I spent 8-10 hours a day on a PC at work, I no longer needed to do this at home. Somewhere along the line, though, something was lost. It's hard to be enthusiastic about a work machine. Sure, you want it to be fast and not get in your way, but at the end of the day, it's just not the same.

I went from 1-2 years between machine upgrades to 4 years - and I barely cared. There's still something special about doing it yourself, though, so this summer I finally upgraded from an Athlon X2 4200+ to a Core i5. That's not the whole story, but it will suffice for now.

The point is - building out a new PC, finding out all of the various motherboard pros and cons (and quirks!), selecting the other components, building it - it's been invigorating. The experience has really renewed my interest in experimentation at home. I want to try new operating systems again. I want to try X, Y, etc. It's interesting to see how things have changed, and how they haven't (You STILL end up staying up all night to setup that new machine - something ALWAYS doesn't go right). That Is The Law.

I actually enjoy using a desktop again. With Windows 7, I'll actually reinstall my OS again for the first time in a long while. (well, I've been reinstalling since Beta 1 came out) The list goes on.

I find myself reading articles late into the night, reading books, feverishly seeking more knowledge. I am excited about computers at home again.

You don't need to splurge for the latest - nowadays, hardware is cheaper than it has ever been. When I got my first 4 megs of RAM, it was $32 a megabyte! Now 4GB of DDR3 is $100. Dual and quad core CPUs are more affordable than ever. I am amazed at how lucky we as enthusiasts are these days :)

When's the last time you've upgraded? When's the last time you built a machine yourself? You may find it's a very rewarding experience. Build a file server. Build a box just to experiment with spare parts on ebay. Or use a virtual machine with a new operating system. Experiment!

Shout Out to Model View Presenter and Passive View

I mentioned last week that I'd talk about GUI testing, so I suppose I should. GUI testing is generally regarded as hard. In my case, I've mostly had to deal with Java GUI code. There are a few things I can think of to aid in testing GUI code (there may be further ways or angles, too, which I'd love to see discussed if so)

1) Keeping code modular and well encapsulated

The usual good coding habits help a lot here. This is mostly the obvious splitting the duties of code (a la various MVC inspired patterns). There are some improvements over standard MVC, though. Model View Presenter, for instance, is really sweet. Currently one in-house favorite is to have a PresentationModel / View, which is a variation of that.

2) Minimize the amount of GUI code to test (make a view that doesn't have any real logic to test)

This is where Passive View comes in. Passive View is pure awesomeness. (why did I ever write views any other way...) There's very little to test if your view doesn't DO anything but display GUI components and have action handler calls. In Passive View, it's illegal for the view to ask for anything. All data is pushed to the view, it does not 'request' anything. The only permitted calls are action handler methods for when GUI components are interacted with. This action handling can even be turned into an interface, so that the view doesn't even have a real reference to the presenter/controller/etc (pattern-dependent).

Your 'OK' button not doing anything is very rapidly found even without automated tests, so as long as the real logic (which is completely absent from the view) is well tested, you are in good shape.

3) Using GUI testing frameworks (like Abbot) that simulate a user. There are similar frameworks for testing webpages...

It is possible to do automated testing of GUIs even if the first 2 items need work or are deemed insufficient. We use Abbot to automate GUI testing of important parts of our application. The tests run the same way other JUnit tests run. Most would deem these functional (not unit) tests, and I agree, because the time impact of powering up a real GUI (especially one you can't disconnect from your system) and physically typing input and clicking buttons is very noticeable.

Generally, lack of encapsulation and too many dependencies are again a real hinderance and bog down GUI testing. If you can mock out or easily disconnect the GUI from the usual, live system, then speed should be less of an issue. So with proper effort invested in 1&2, I aim to get #3 in the general ballpark of unit test times. I don't think that, following 1&2 strictly, I would write a large amount of abbot tests, but I want to try proving it's possible to have nice, isolated and relatively fast GUI tests if you want them. Maybe I'll do some speed/effort analysis on this at some point - because I'm that much of a geek.

Goals for the week starting 11/9

Results from last week:

• My test-writing improved, but still isn't where I want it to be. I did write some tests, but not enough.
  
• I didn't get around to trying Guice
• I finished reading the Career 2.0 appendix, so now it is officially complete
  
• I read the first 50 pages of The Tipping Point
• I did a few more Java Puzzlers (on Puzzle 81 of 95?)
• Grabbed latest Hudson, but time was an issue so it isn't staged yet.
  

Goals for the week starting 11/9/09:

• Continue to focus on test-first and writing fast tests. Test more than I did last week.
  
• Continue reading 'The Tipping Point'
• Continue doing Java Puzzlers (aim for 2-3 more)
  
• Use Mockito more, and prepare to give a demo to coworkers
• Write a book review on 'Career 2.0' and post it

I see a busy week happening, so I'll shoot for using Guice next week.

The Hunt for a Good LCD

After keyboard and mouse, the next most important important part of a computing experience for me is monitor. I've been a dual monitor user since 2002, when I bought a Viewsonic P95f 19" CAD-quality CRT. This CRT pushes unbelievable refresh and resolution for it's time. My former CRT became a secondary, and since then I've never used less than 2.
 
In 2005 my primary display became a Dell 2001FP (20" LCD, 1600x1200), and my P95f became my secondary. For around a year I've wanted to find a new primary display, and I searched for several months before I settled on one.

It's 2009 - LCD technology should have advanced quite a bit since my last purchase, and you can buy more, larger, and cheaper displays than ever. Why is it so hard to find a display with good all-around characteristics?  I'm apparently not the only one with this problem.

I care about:

• Color accuracy
  
• Response time
  
• Input lag
• Resolution
• Warranty, dead pixel replacement policy
• Adjustable stand (height, swivel, and ability to invert display vertically)
  
• Viewing Angle
• Menus and general configuration ability
  
• Inputs

Not All LCD Panels are Created Equal, as Jeff Atwood posted a couple years ago. He listed a nice summary on TN, PVA, and IPS display pros and cons.

My search was for a 22-25" display with a resolution of 1920x1200 or higher. Being used to 1600x1200, I wanted to maintain at least the same vertical resolution. I also wanted IPS, as it seems to have the best characteristics of the three (best color, low input lag (though more than TN), good response time). In the $350-750 range, I wanted a display that fit my needs.Good IPS displays before the $1000+ range seem quite hard to find.

One of the biggest challenges is where to BUY an LCD from. You want absolute certainty you will be happy with the color, and you want to be safe from dead pixels. Big box stores typically don't carry higher quality LCDs, since most people just want something cheap. I ruled out Newegg, as they have an 8 dead pixel policy before a display is eligible for return. No thanks - I do other shopping there, but not for an LCD.

Along the way, I've found a great LCD review site: TFT Central. After reviews ruled out some of my other choices, I noticed a new display that just got release:  The Dell Ultrasharp U2410. This is a 24", 1920x1200 H-IPS display.

After getting past some sore spots with Dell's panel lottery in the past, I came full circle back to Dell. Why? They have VERY good guarantees on their displays.

- Zero dead pixel guarantee
- 3 year advance exchange program if the LCD ever has any issues.

It's a no-brainer. I don't want to buy a display I'll rely on for many years without assurance that the beginning of the experience will be problem-free.

It's been a month since I got it, and I am very pleased with it :) If you're an enthusiast - treat yourself to a nice display. It will last you a lot longer, and be far more satisfying than a new videocard, cpu, or any other piece of hardware that will get out of date in a year. Those are nice to have too, but are best enjoyed with a good display.

More on testing (part II)

In my latest push to test more, I've been learning some things. Namely, just how much testing can show you. Testing really illuminates bad code. Bad code is hard to test. It might not have been that bad, but just some slight rule bending is enough to make code really hard to test.

So, getting back to the Law of Demeter. It's most easily summarized as:

“Only talk to your immediate friends”

It is also summarized as don't use too many dots. i.e. foo.getBar().getSomethingElse(), but dot counting isn't really what it 's about...

At the end of the day, it's just about proper encapsulation if you ask me. Friends to me are direct dependencies, i.e. objects that are relied or operated on.

When a class A needs another object B (or is made to operate on object B), it should need it because of object B, not because of something in another object C that's in B. That violates encapsulation and exposes the internals of B. B then can't be refactored, because A relies on C.

Now, it's reasonable for A to operate on things inside B, as long as that is where they live and they art a part of B. Testing makes the distinction obvious, because if the access is proper, then exercising and testing the code is simple. If the access is stretching further than it should, then testing will be noticeably more work.

Mocking frameworks can make testing easier in these situations, but refactoring is probably still necessary. I found it necessary in some code I was working on this week, though I would call it gentle refactoring. It felt natural, and really wasn't a lot of work. I am still finding the tests hard to write, but I will keep at it.

I'm one day away from surviving writing daily for my first week of National Writing month. It's been a learning process so far. I'm rambling and not really cleaning up my writing yet - it's intentional so I can just focus on writing regularly. Hopefully at some point it will sound interesting.

I am noticing I have a lot to learn, and a lot to write about testing. I will continue to do so, but I think on the weekend I will sidetrack to some general computer stuff. Most notably I want to talk about my latest PC building escapades, and how much it has really restored my enjoyment of computer use in my spare time.

Szczepan Faber is my bartender

I've known about Mockito for a little while, but I've only just now officially tried it today, and Sczepan Faber (and friends) are now my bartenders, and when it comes to mocking, a nice cold mockito is my new drink of choice.

Wow. Seriously, wow.

The syntax is exceptionally sweet, and additionally quite clever. A coworker and I dived into how it figures out what method to stub today and that alone was enjoyable.

Mockito will definitely be a valuable tool to have in the testing toolbox.

Windows file path FAIL

I'm going to take a break on testability to talk about file paths - specifically long file paths, and the care one must take when dealing with them on Windows.

Now, while quite a lot of technologies are involved in development, for me (right now), the most important to mention when dealing with files are: Java, Subversion, Windows, and Tortoise SVN. I'll throw in one more - the filesystem (NTFS).

Using the command line is part of my nature, so when I get into the office in the morning one of the first things I do is open up a command prompt and 'svn update' my working copy.

Imagine my surprise one day when I couldn't update, because Subversion claimed one of its .svn/... files was corrupt or missing. Cleanup didn't help - it wasn't actually a Subversion problem. It was a file path problem. The svn FAQ actually has great information on this.

Enter the windows API maxium file path limitation of 260 characters. What's annoying is that it isn't ALWAYS the limit, in fact the unicode version of the API has a much more flexible limit (thousands of characters). Why then, does Windows Explorer, even in Windows 7, still use the API that has the 260 character limit? *

I deal with this issue again and again. I generally don't create file paths this long, but it doesn't matter - because I work as part of a team. I think it's reasonable for people to have descriptive, rich naming for their stuff - I just wish it wasn't so painful. Once files are in version control, then build tools, installers, and all kinds of things MIGHT have an issue depending on where the files are checked out and what file API they use. It's just not an issue I should have to deal with.

I don't want to worry about long file paths - this is a simple request. Of course, simple problems for computers aren't always simple. In fact, they usually aren't, but the fact that the API exists but that it isn't already the defacto, default API used by Windows itself frustrates me.

I want to be clear - this isn't a limitation of NTFS, Java, or Subversion. They are all quite happy to deal with long filepaths. It's the Windows file API. It's just easier than normal to get into bad situations when you have tools that will very happily (as they should!) create and deal with long filepaths, only to have your operating system tell you the file doesn't exist or can't be accessed.

* Probably backwards compatibility

That's my rant for the day.

More on Testable Code, and the Law of Demeter

I started looking at a simple enhancement task today. Like many simple sounding tasks, when you peer at the 
system and look at what is actually involved, there may be ugly parts. Especially in ensuring testability, as I am committed to unit testing this code.

In my quest to test more (and test FIRST), I looked at what would be required to add the functionality, and specifically, how to test what I was adding.

Here are the issues with testability and excuses I came up with:

• No unit test exists for the immediate classes in question (shame on me - it's my code) 
• The code has a GUI - this usually makes testing harder
  
• Too many external dependencies!
  
• I haven't tested this exact type of code before (aka: I don't know how)
  

Tonight I'm going to focus on the dependency issue.

Taking a look at my model, it already relied on more external objects than it needed to for the required functionality. The requested enhancement would (if the pattern continued) require further addition of some heavy weight dependencies. Bye bye testability!

Fortunately, I had both the testability presentations still in my mind, and a coworker who had already solved this problem.

The feature in question is for administering users in a system. Among the things being manipulated are name, manager, credential reset, licensed features, and now - a user's preferred currency code (at the end of the day - a String). Great - slap in a few getters and setters, and we're done! Well not quite - currency code lives on a currency unit which is supplied by a unit system, well, which comes from this other big thing. You get the point. If I was lazy, I'd just pass this big other thing to my model so it could do its job. I'm not going to be lazy - I'm going to pay attention to the Law of Demeter.

This model don't really care about the 'other big thing', or the 'unit system', or anything other than that being able to set a user's preferred currency to Australian Dollars, therefore they have no place in this particular model.

Instead of that, my model will take a data source that can give it valid currency codes and set a user's currency code. Just a simple interface with a couple of methods that will be easily mockable for testing. While I'm at it, I'm going to pull out the existing extra dependencies (there was fortunately just one) that weren't needed. Now my interface has four methods, and I don't need any hulking database-requiring objects to get my model moving. A little shuffling here and there, and very little additional code, and my model is now much more easily tested. Suddenly the "I don't know how to test this" feeling has weakened a bit now that my class is simpler.

I want to write further on my take on the Law of Demeter, but it's 11:45PM and I need to submit an entry daily so I'll have to wrap this up tomorrow.

Afterwards, I plan to cover making testing the GUI easier.

Goals for the week starting 11/2

Goals for the week starting 11/2/09:

• Test first. Write unit tests before, or alongside any new code I write this week.
• Try out Guice
• Finish reading the Appendix of Career 2.0 (I've been slacking!)
  
• Begin reading 'The Tipping Point" by Malcom Gladwell
• Continue doing Java Puzzlers (I am on Puzzle 78 of 95)
• Start staging an upgrade to the latest version of Hudson
  

I'll report in with how I've done at the end of the week.

Writing Testable Code

One of the things I struggle with sometimes is how to write testable code. Especially in an existing system that has lots of established code that is difficult to test. The code may have existing tests, but they are heavy, system tests not quick and speedy unit tests. Eventually, writing more tests in the same style just makes the builds take too long to run, and eventually that one new test may requires several minutes of waiting. Tests that make you wait are not productive, and should not be the norm.

This week I found not one, but two good presentations regarding testable code. Firstly (seen @ the UCOSP blog) was a link to the slides for a presentation done by Misko Hevery & Cory Smith at OOPSLA '09, entitled: "Tutorial: How to Write Hard to Test Code" (PDF Google Docs link). There are quite a few slides, and in addition to illustrating bad practices, there are plenty of examples of writing more testable code as well. Highly recommended, entertaining and educational slides.

The second is a project I already knew about, but never got around to trying. Guice. If you haven't used it (or another Dependency Injection library), I encourage you to watch the youtube video on the main Guice page. The presentation itself has general tips on writing more testable code, and towards the end gets into more advanced examples using Guice. The general principles apply whether or not you use it.

I'll post again with further thoughts once I've had a chance to play around with Guice.

Writing Month Starts November 1

I just got a newsletter the other day about Prag Pro Wri Mo. I think I'll need to give this a shot in November - which is only a few days away.

My goal will be to write a blog post every day. Short or long, every day. Starting Sunday. Formatting cleanup to come later, the emphasis is purely on WRITING. The actual idea is from National Novel Writing Month. This will only serve to further the motivation and push I got from reading Career 2.0

I need to start ramping up ideas and topics now, so I'll jot down a few.

• Test ownership - how do you solve the 'nobody owns this unit test failure' problem
• Build scripts (Ant, Maven, Gant, Gradle, Etc) - where are we today, and what makes sense to move to in the future, various pains, etc
• Java 7 features - I've meant to post about these for a while. Which ones are interesting and still being included...
• New languages to try - I need to pick a new language to learn this year. I think I have an Erlang book kicking around that I need to read...
• Notable programming books in the last 1-2 years?
• Ergonomics in computing (wrist pain is becoming a real issue for me)

updated to add more topics:

• Apache+HTTPS+SVN authentication issues (TortoiseSVN cannot remember password)
  
• More on SSDs
• The search for a quality LCD Display
• Report in on my recent PC upgrade
• Talk about Windows 7 in the context of both home and work
• at least one Book Review
  

Useful Regular Expression Site

Whenever I use Regular Expressions, my memory is always a little foggy. I usually make a couple of newbie syntax mistakes which waste some time. Now in Java (or in today's case: Ant), I don't want to edit, save (and/or compile), then run every time I alter my regular expression when first building it only to find out 10 (or more) seconds later that it doesn't match what I want or doesn't even compile.

The feedback cycle is simply too long.

After 5-10 minutes of frustration I usually seek out an online regular expression tester to ease my pain. Today I found Regex Tester and it rocks.

With instant as-I-typed feedback on my regular expressions (valid, what matches were produced for the sample string, etc) I completed the regular expressions I needed very quickly.

From now on, this site will be my first step in creating regular expressions.

Development Practices That I'm Passionate About

In response to Jared's blog entry: 'What Are You Passionate About?':

The list was already fairly comprehensive, and I generally agree strongly with all of the points.

Daily meetings are a tough one for me - I agree in principle, but I've yet to get down a daily meeting practice that doesn't occupy at least 20-30 minutes of my time. I've been in a SCRUM situation (as a remote user) for several months before, and that may have only taken 10 minutes. I enjoyed the urgency of wanting to have good progress to report each day, but the meeting always seemed to collide with my lunch time due to timezone differences, so that has probably predisposed me to negative associations. I want to believe in daily status though, even if it is a limited to myself and my direct superior. I think I'll put it down as a goal to establish as routine within the next couple of weeks.

Weekly status meetings is the absolute longest time period that I think a group of several small dev teams can go between syncing.

One point I would expand on - test automation - is that I'm passionate about automation in all forms. While I think 'test automation' definitely deserves it's own bullet, general purpose automation of daily tasks for developers and non-developers alike ALSO deserves mention.

As an example, our Hudson builds push an installer and database dump to a share location with enough information that new builds of our software can be automatically installed by a simple script that QA and other non-devs can run. (Yes, QA also tests our installer manually of course) This is just one example, but it applies everywhere. Just about any repetitive task that can be automated should be automated. I do think instructions for how to do automated tasks without the automation should be well documented, though.

I love having peer reviews for all code check-ins. Having had this as standard practice for the last 2 years, I will not be satisfied with any work environment where this is not mandatory. I believe it is an essential part of delivering quality software.

I may need to update this from time to time, as I haven't really declared a list of my own - this is more of a commentary, but at least it's a start.

Results for the week starting 9/28

I will experiment with whether a second post, or updating the original post, works better.

Last week I completed 3 Java Puzzlers and read Career 2.0 each night. I have continued to read nightly, and will finish the book this week.

I didn't get around to spending much time on Stack Overflow, but the goal was mostly to throw in something programming-related last week.

Java path mystery...solved

For ages, I've wondered how in most cases, java will mysteriously be in your path in windows, even though there is no Java install directory in the path. (it will certainly be a version that was installed with a proper installer, at some prior point, but not necessarily the most recent version you've installed) To fix this, I generally put %JAVA_HOME%\bin; at the front of my PATH environment variable after defining JAVA_HOME to point to the Java install I care about (something Ant, Maven, and other dev tools often care about having defined...).

I've always wished I had the 'which' command in Windows, so I could locate which Java executable was in the path. Finally, by chance, a coworker was debugging an OpenGL crash with an Intel GMA graphics card and substituting DLLs in what he thought was the 'run' directory, and he realized that it wasn't picking it up when he put it in the directory of the JDK bin he thought it was using... When he checked process explorer, lo and behold... C:\WINDOWS\SYSTEM32\java.exe is what was running. What the heck??? I find this strange, yet there it is.

I have always thought it was registry magic, or some other trick that caused Java to end up in the system path unless you put it as the FIRST path entry. Instead, FIRST just means AHEAD of the System32 folder. (Several apps likely to be in a dev environment often put themselves at the front of the path, subversion, oracle, etc...so I never noticed that the usual first entry in the PATH is this...and I typically put entries at the END of the path except when I know there will be other entries fighting for this position)

It's funny how sometimes mysteries like this go on for many years - maybe it's a simple Eclipse feature nobody knows about, or some maven quirk, that we never take the time to fully investigate and understand...we just come up with the rule and follow it - at least it's what I've observed.

If anyone can shed some light on this, I'd love to hear it. Is this practice generally acceptable to pollute the SYSTEM32 folder with executables? For now, I am satisfied to now know why I need to put my java/bin at the front of my path...

Goals for this week (starting 9/28)

This week won't have much coding in my forecast (and is approaching half over), but I think it's important to set some goals anyway.

- Continue doing 1 Java Puzzler a day
- Read a few pages of Career 2.0 each night
- Answer one StackOverflow question this week.

My testing and metric related goals aren't gone, but are on hold this week.

First week's goals (results a month later) - Poor

Well, change isn't always easy, even if you believe in it. I'd say I did fairly poorly on my first week (now a month ago) and those since, though I was on the vacation a decent portion of the time after. Still - that's no excuse not to blog results. I currently have a more pressing side project at work, so I won't get to focus on code much in the next week or two, but I will come up with a new list of goals for next week regardless.

I was pretty faithful to the puzzler a day (as it's a fun break from the normal day), and probably did 1 puzzler a day. I can't emphasize enough how useful (and satisfying!) it is to learn the quirks of a language that you use day-to-day (in this case, Java). It's good knowledge, and 'Java Puzzlers' presents it in an entertaining fashion.

On the unit test front, I probably updated or added a unit test one day of the week, in a section of code I already had pretty good coverage with. I did not get around to writing my first Abbot test. My issue has always been writing the first test - it's easy (and enjoyable) to follow in the footsteps, once they are there, but it seems like a pretty solid trend that untested code stays as untested code - there is an initial barrier of resistance still (maybe the code is hard to test, maybe the coder is lazy, or maybe test-driven just isn't strongly enough part of the mindset to jump-start things)

On the findbugs section I'd say I failed - there's no lack of warnings to fix, but they are often in a foreign area of the codebase. I did examine our warnings reports in Hudson, but didn't fix any.
I find that sometimes I'm hesitant to perform an obvious fix in a section of the codebase most requently updated/maintained by another developer. Prior history (just google Debian SSH) dictates that sometimes applying fixes that a code metric suggests in code you aren't familiar with is a bad idea. The code I'm looking at isn't as delicate, but it still deters me somewhat. We'll see how I cope with this as I really want to better embrace Findbugs.

On the Hudson front, I frequently spend an hour or two getting everything building (especially tricky in Eclipse at times, as the heavy generics often confuse Eclipse's compiler, since it does not use javac). Afterwards, I don't know what I should work on and it is late at night. Time dicates I should probably find a bug to fix, but it's often hard to find a good starter. I think I will keep this goal of contribution, with a renewed focus or speaking with the devs that hangout in #hudson on IRC. I'll just ask if there's an area I could help with in a small way. Hudson remains the single most useful bit of Java software I've ever used - the benefit the project has given our team is tremendous.

I'll have to come up with a list of follow-up goals and any strategies for better accomplishing them

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.

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:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295

Release notes for 1.6.0_16:

http://java.sun.com/javase/6/webnotes/6u16.html

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

JDK 1.6.0_16 download

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

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.

Cheers