Just yesterday, at work, I caught more code using java.util.DateFormat in a non-safe way, so today I looked through old mail and the like trying to find one of the better summaries of the DateFormat situation I’d read. I found this one :


I mentions the non thread-safety of the DateFormat class (something that ought to be well known by now!), and lightly discusses ideas for working around the problem.

What’s missing from the post above, however, is any discussion of how developers might find and correct all of their existing DateFormat usage after learning about this problem, and how they might prevent further incorrect usage in the future.

This is where static analysis comes in. PMD, a popular Java-language static analysis tool, already has a rule relating to thread-safe DateFormat usage. This page :


mentions the below rule :

UnsynchronizedStaticDateFormatter: SimpleDateFormat is not synchronized. Sun recommends separate format instances for each thread. If multiple threads must access a static formatter, the formatter must be synchronized either on method or block level.

This rule likely would have caught the above mentioned problem at Atlassian, and certainly would have prevented the similar problem in my company’s code (I checked).

Overall, I’m surprised to see development teams doing very little with static analysis, as there is quite a bit of low-hanging-fruit to be gained from tools such as PMD and FindBugs.


Over the last year, I’ve been reading a lot of DIY electronics sites: Make Magazine’s Blog, www.hackaday.com, www.uchobby.com, and quite a few others. I’ve read through many project descriptions, and through many, many project parts lists.

Something has been missing from nearly all of the parts lists I’ve read, however. Nearly none of the projects provide “kits” to build the project, and surprisingly few projects even provide links to links to individual part sources. Many provide only a simple plain text list of parts, perhaps including Jameco or Digikey parts numbers.

This startled me, simply because I’m so accustomed to the ubiquitous ‘Amazon’ links at the end of every book review, and nearly every CD and DVD review, I read.

I’ve looked around the web some, and there doesn’t seem to be a seem to be a way to create an “Instant Kit”, to add a shopping list of items to your cart, at any shopping site I’ve seen, even non-electronics sites such as Amazon. Such an “Instant Kit” creator seems like the perfect thing for Amazon or Google-Shopping to create, or for DIY sites like Instructables to integrate into their project instructions.

If this really doesn’t exist, then I think it’s time for someone to write one. Maybe me.

To be at all useful, I believe an “Instant Kit” creator would need to deal with two questions fundamental to shopping from an ingredients list, the questions I ask myself every time I go to the grocery store with a shopping list in hand:

  • Which of the item on the list do I already have?
  • Which items on my shopping list should I buy at store A, and which at store B? This encompasses a lot of smaller questions about item availability at particular store, price comparisons between stores, store minimum orders.

Sometimes a dead-simple feature hides from me for exactly that reason, because the feature is so dead simple.

Such was the case of Eclipse being able to pop out various parts of its view into multiple separate windows, something I just recently learned from this Adrian Coyler posting from well over a year ago, the English original of this article he wrote for the German-language “Eclipse Magazin”.

To pop all or part of an Eclipse view into its own window, just DRAG the view outside of the main window. That’s it. See that ‘Problems’ tab? Drag it to its own window. The ‘Package Explorer’ tab? Another window. At last, my Eclipse can take advantage of my nice multi-monitor setup.

“The Pragmatic Programmer” : Andrew Hunt / David Thomas

The more I work as a mentor with junior developers, the more I quote parts of “The Pragmatic Programmer” to others.

The more I find myself quoting parts of the book to others, the more I find myself quoting it to myself as I maintain code and review project specifications.

Over time, for both myself and the people I mentor, I’ve noticed fewer of the book’s big no-nos creeping into projects as a result of such quoting and re-quoting. Very nice.

The books sub-title, “From journeyman to master”, is key to understanding its audience : the skilled, mid-level programmer who needs the occasional reminder of programming’s big don’ts, as in “The Evils of Duplication” (part of Chapter 2), or who needs a quick explanation of the strange “power of text” (chapter 4). The last part of the subtitle is important too, seasoned programmers do well to refresh themselves with a quick of read or re-read of a section.

The topics in the book cover (most) all the problems I’ve had myself while helping mentor junior programmers, and cover many of the problems I hear in stories of senior developer’s working with their teams. For a relatively short book, 300 pages of easy free-flowing prose, the book is surprisingly complete.

Good book. High recommended.

A Mock’s Not A Stub

February 5, 2007

I read Martin Fowler’s site pretty regularly, and while I typically enjoy the writing there, this article really stood out for me when I read it this week.

It explains the differences between mocks, stubs, and other testing lingo, and it cleared a lot of things up for me that have been muddied for a good time now.

I was asked for Eclipse plugin recommendations last month, by someone who’d just started doing Java development again after quite a bit of time doing .Net development. I wrote down a short list of the common settings, plugins, ans so forth I recommend to the developers I work with.

While writing the list, I realized I can babble about Eclipse setup for far longer than anyone cares to listen, so I’ve pared things down to five initial setup recommendations:

  1. Download an Eclipse milestone. Their usually stable enough for day-to-day use.
  2. Edit the Java compiler settings, turning all the warnings on. Turn off the ones that completely bug you after a few hours.
  3. Set up an extension location to install any plugins into. You’ll be glad you did. Lots of sites discuss this idea; I often point folks here for details.
  4. Install some plugins. I recommend the Web Tools Platform for web developers, PMD for developers who need to review more other’s projects, and the Freemarker plugin for anyone working with Freemarker templates.
  5. Look around on the web any time you wish Eclipse did something it doesn’t. There are plugins and setup options to match all sorts of situation.