I just read Thread Signaling from Jacob Jenkov. It is fine as far as it goes to introduce the reader to Object.wait() and Object.notify().

But it has one fatal flaw: it uses a literal java.lang.String for coordinating between threads. Why is this wrong?

Strings are interned by the compiler. To quote the javadocs: All literal strings and string-valued constant expressions are interned. Using a literal string means that any other code anywhere in the JVM, even in other libraries, which use the same String literal value all share the same object for wait() and notify(). This code:

public void dastardly() {
    "".notify();  
}

will wake up a thread waiting on empty string, including one in utterly unrelated code.

Don't do that. Instead, create a fresh Object for coordinating threads. This age-worn advice for lock objects (synchronize(lock)) applies just as much to objects used to coordinate threads.

• Thoughts in the Wilderness: How building a bridge is the same as building software
  I was about to scream: "the civil engineering metaphor is not appropriate for software engineering"!. But that would just make me sound shrill, and the man does have a point about the deployment being where the rubber hits the road.
• Git - coming to a Windows computer near you?
  The skinny is that there's a Google Summer of Code project to implement (i read that this meant, not port) Git to C# to support windows and mono. sweet.

• 11 MORE VISUAL STUDIO SHORTCUTS YOU SHOULD KNOW | Dev102.com
• LogicielMac Update
  Nice auto-update mac app

Jean-Marie Dautelle on Realistically real-time, or getting real-time-like behavior from the non-real-time JVM.

• Gojko Adzic » DbFit: Test-driven database development
  Got a testing framework that's all row and column oriented? Got sprocs that are hard to test? You need this.
• TSQLUnit testing framework
  How to unit tests sprocs in SQL Server.

• Mac 101: use a tab to navigate dialogs - The Unofficial Apple Weblog (TUAW)
  GREAT tip! Been looking for this for a long time.
• Information Design Patterns

• Ant Best Practices: Define and Reuse Paths
  #7 of 15. Kinda what it says on the tin.

• Data Mining and Predictive Analytics: Data Mining Data Sets
• StatSoft Electronic Textbook

One of the most common causes of sporadic bugs in swing applications is doing things on the wrong thread. Most common of these is when a thread that is not the Event Dispatch Thread does something that updates the gui. Its very easy to do accidentally as seemingly innocent operations done on a background thread can fire off event listeners and end up inside code it shouldn't as a result.

CheckThreadViolationRepaintManager from the SwingHelper project is a very useful class that can be easily plumbed into a Swing application to report any wayward threads getting into gui code.

Also from the same stable is the EventDispatchThreadHangMonitor which can report when the Event Dispatch Thread spends too long outside its main loop (which will result in a sluggish and unresponsive gui).

So I was all fired up about migrating to wordpress, due to the rot this blog has suffered over time. (The category links have been broken for nearly 2 years now I think). I got as far as the following line in the (ahem) 5 minute install guide:

Create a database for WordPress on your web server, as well as a MySQL user who has all privileges for accessing and modifying it.

And now it all seems like way too much effort. I'm incredibly lazy when it comes to blog tools. Gone are the days when I would happily spend half a day tinkering with the tool prior to writing a 10 minute post. And I'm sick of blasted relational databases. A blog is just a bunch of text snippets with a few bits of metadata around the edges. Why not use a perfectly good filesystem for storing what is so easily represented as a bunch of files? It might even stand a chance of holding my attention long enough for me to finish installing it.

I really want to blog more, but I need the feedback of comments to help keep me going. Every time I've tried tinkering with movable type comments to allow me to turn them back on its been buried in spam within seconds, and I can't be bothered figuring out which magic combination of plugins, captchas, blacklists and runic inscriptions I need to make it work.

I'm off to find some incredibly tedious housework to do that might make farting about with MySql seem like a reward and a treat.

One of my most visited posts is this one written in 2003 about a couple of little known classes in the JDK for generating unique identifiers, also known as GUID's or UUID's. Java 5 and later now also has the UUID class. Universally unique identifiers for everyone!

Agile is dead. The word is too easy to slap onto any old thing in an attempt to jazz it up. It's also pretty easy to use as a pejorative term by those who have no interest in improving. Let's take a typical interaction:

"We're doing agile development. By using agile techniques we can work more effectively and our software is easier to change, with fewer bugs. The agile approach lets our customers steer the project while it's running to maximise return on investment."

"Agile techniques? I've heard about them. Isn't agile software development just an excuse not to spend time doing design and analysis? How can you run a project without nailing down all the requirements and design in advance? Agile approach? No thanks!"

In my head, I like to replace the word 'agile' with 'professional' and 'modern'. To me the above conversation thus sounds a bit like this:

"We're doing professional development. By using modern techniques we can work more effectively and our software is easier to change, with fewer bugs. The professional approach lets our customers steer the project while it's running to maximise return on investment."

"Modern techniques? I've heard about them. Isn't professional software development just an excuse not to spend time doing design and analysis? How can you run a project without nailing down all the requirements and design in advance? Professional approach? No thanks!"

It also works when talking about software frameworks.

"We've built a software framework to enforce a standard approach to all applications and maximise reuse of common components. All a project team has to do is work to the common interface and conform their design to the framework. Sharing common software components maximises standardisation between projects."

I hear:

"We've built a software nightmare to enforce a mediocre approach to all applications and maximise reuse of inappropriate components. All a project team has to do is work to an inappropriate interface and conform their design to the nightmare. Sharing inappropriate software components maximises mediocrity between projects."

(Just to clarify, I'm a big fan of libraries. A library is something that you use. java.util.collections for example. A framework is something that (ab)uses you.)

After almost 5 years, I find myself no longer working for ThoughtWorks. Moving on was a hard decision but it was time for a change. I'm looking forward to my new job, but I'll miss being '@thoughtworks.com'.

I won't miss Lotus Notes.

Nobody who can spell HTML would be surprised if you launched a Web 2.0 company and chose to use Rails to build your site. On the other hand, one of the ways startups beat the competition is by taking the road less travelled, by using a language considered wierd or niche by everyone else. Success can lead to the language being noticed and becoming more widely accepted.

I was pleased to discover that Slideaware have migrated from Rails to Erlang for their online powerpoint collaboration application. Not because I don't like Rails, but because I really like Erlang.

It's not friendly and it makes it really hard to pay for stuff.

Has anyone ever actually had a smooth user experience with Paypal? Every single time I've tried to use it I've had problems.

The new credit card loop of death. A particular favourite. This is where paypal keeps insisting that 'this card has already been registered' while steadfastly refusing to let me actually use it to pay for stuff, eventually looping back to the 'add card' screen for another fun go around.

Amnesia. Several times paypal has let me go all the way through adding a new card, accepted it and then just forgotten all about it, forcing me to add the card again. Often leads to another free trip to the loop of death above.

Insisting that a payment has already been made (for an item on ebay) and refusing to let me continue, despite ebay having precisely the opposite opinion. Makes the whole cute 'an ebay company' logo look like some kind of ironic joke.

Workflow bugs in little-used ancillary features are one thing but... this is paypal. One might consider the workflow around, you know, 'paying for stuff' to be something of a core function?

There's a pattern I've used with great success a couple of times now that tends to provoke strong reactions in developers when they first see it. I've had comments along the lines of "that's horrible!", "ugh" and "that's way too much work". The pattern is this: the encapsulation of simple built-in types within domain specific classes. Sounds simple and it is.

Lets take a concrete example:

public class Customer {
    private final String firstName;
    private final String familyName;
    private final int ageInYears;
    private final int heightInCentimetres;

    public Customer(String firstName, String familyName, int ageInYears, int heightInCentimetres) {
        this.firstName = firstName;
        this.familyName = familyName;
        this.ageInYears = ageInYears;
        this.heightInCentimetres = heightInCentimetres;
    }
}

Fairly standard stuff. But note the constructor signature: string, string, int, int. Not really very expressive and exceedingly easy to get the parameters out of order. But who would get someone's first and last names mixed up? Ask any Chinese person how often that happens. They place their family name before their given name. Also, strings and integers are not usually domain concepts unless you are writing a compiler. Someone's first name is not interchangeable with their last name the way two strings are. So how about this:

public class Customer {
    private final FirstName firstName;
    private final FamilyName familyName;
    private final Age age;
    private final Height height;

    public Customer(FirstName firstName, FamilyName familyName, Age age, Height height) {
        this.familyName = familyName;
        this.firstName = firstName;
        this.age = age;
        this.height = height;
    }
}

It is at this point that most developers recoil. No way do I have time to add an entire class just to wrap a string! Or two entire classes in this case! Actually, it's four new classes. All of which I wrote while writing this post. There is a reasonable amount of boilerplate. Including toString, equals, hashCode and a getter makes for about 40 lines per tiny type, almost all of which can be condensed into an IDEA template. And most systems have a finite number of domain concepts so the rate of adding these tiny types isn't very high and drops off fairly quickly.

But why do this? I consider it playing to the strengths of a statically typed language. Java will never be as Ruby as Ruby, but it can be much more Java than Ruby ever will. All sorts of useful things start to happen when the library types and primitives have been banished from your api. Now the compiler can spot transposition errors. Equals and hashCode can be implemented with domain specific semantics. It's much harder to accidentally pass dollars into a method that was expecting pounds sterling (but actually took a double so it could have been anything). Readability is greatly improved. Automated refactoring, code completion and code navigation all gain a new level of power. 'Find usages' on the FirstName class produces far more useful results than doing it on the String class.

You probably still don't fully believe me if you haven't tried it, but this is one of those times where cognitive dissonance has got it wrong. It really is an exceedingly useful approach.

Almost without fail I see certain errors repeated on every single software project I come across. The projects that successfully dodge these pitfalls almost always do so because someone on the team fell into them once before and swore they wouldn't do so again. Those of you who haven't yet been burned by this class of error will almost certainly protest about complexity or wierd design choices in the code made by those who have.

Who are these heinous kingpins of crime in the bug ghettos of the software world? Its a work in progress, but the initial contenders are:

• Dates and times
• Money
• Concatenated strings as identifiers

Those of you who've been beset in the past are nodding right now, those who haven't are probably saying, "they don't seem very complicated."

Which is exactly why they'll get you sooner or later. Then you'll remember this post, and you'll nod.

It's been kindly pointed out that my feeds and half my category links are broken and have been for a while. Probably nobody is left who still actually uses a browser to read blogs, but, as this dovetails rather precisely with my assumptions about readership size; and faffing with moveable type templates rates somewhat lower than not, it may take a while before it all gets sorted. Apologies to anyone who's still committed enough to make the effort, I'll try and get round to sorting it.

The sounds of New Years in London: 10 minutes of fireworks, followed by several hours of sirens. Have a safe celebration everyone.

During a recent discussion with some colleagues about which technology to choose for a project I mentioned the importance of tool support, particularly around the IDE. I found myself surprised by the wide range of opinions about the importance of tools. Not about the specifics of whether IDEA was better than Eclipse or VS2005 with Resharper, but about how much importance should be given to tool consideration when choosing a development technology.

Let's say the team has free reign about language choice and has narrowed the decision to Java or Ruby. Both languages are known to the majority of the team. At this point, for a modern project process (lightweight / agile) I would factor in the team size and strongly advocate Java if the team had more than about 3 to 4 developers, justified purely by the superior team support capabilities of IntelliJ IDEA and Eclipse. By which I mean their code exploration and refactoring capabilities.

This is where the arguments start. Er. This is where this particular argument starts.

A typical response might be, "as an experienced developer, while I find automated refactorings useful, I don't need them and certainly wouldn't let my technology decision be swayed by whether a flashy IDE exists. That's just laziness. Developers were refactoring by hand years before refactoring IDEs existed. The improved productivity and less lines of code required with Ruby outweighs any time saved from a few keyboard shortcuts."

This isn't a bad counter-argument. For an individual developer working alone.

With sole access to a codebase that I wrote entirely myself, I'd generally agree. I might disagree with the implication that the time saved by the keyboard shortcuts isn't that significant. I'd love to see a study done where a team had to refactor a codebase and add a feature with a modern IDE compared to another team doing the same thing with Emacs. Moving on - the point that this response misses is that there is a team working on the code not just one developer. I believe the value of automated code modification and exploration increases as a function of team size.

Why should this be? With increasing team size there is an increase in communication overhead and achieving a shared understanding becomes harder and takes longer. Each new member added to a team has an exponential effect on the number of lines of communication.

What does this mean? It becomes increasingly likely that decisions and assumptions made in the early stages will be found to be sub-optimal as the project progresses and the team learns. Code won't be in quite the right shape or quite the right place. The domain model will need to evolve