In general, my experience of programming is that the real benefit of automated refactoring tools is most fully realised when working in teams. When programming on a personal project (or as a single pair), there is less conceptual drift, and its easier to make design changes without trampling on other people. Its also okay for design changes to take a while without risk of confusion.

This may be why the Ruby/Rails community don’t (at present) find the lack of a strong IDE for ruby to be a big impediment. I think that when larger teams (6+ devs) starting developing significant projects in Ruby, the lack of tool support will begin to be felt, particularly by those who have become used to the refactoring style of working, where its okay to defer decisions like what to call methods, parameters, classes etc.

You know two developers having an argument about technology are suffering from a certain lack of common ground when one says, ‘But it’s XML!’, to which the riposte is, ‘But it’s XML!’.

This is one of those products that seems obvious in retrospect. Tesla Motors, a silicon valley startup, has developed an electric car with not just real-world performance, but real world Sportscar performance. Capable of 0-60 in 4 seconds, a top speed of 130 mph, and a range of 250 mph, Porsche should be scared. And it runs on laptop batteries. That’s right, this thing’s electric. Quite literally.

Designed with silicon valley smarts, styled and built by Lotus. Not only is it fast and environmentally friendly, it looks gorgeous! The future of cars might have just arrived. And I want one. Hurry up and bring it to the UK!

Buildix has been released. Some of the build experts from ThoughtWorks have put together a linux distro with a bunch of our favourite open-source tools for source code management, issue tracking and continuous integration, all plumbed together with some handy scripts. Its available either as a Knoppix live-cd or a VMWare image, so getting up and running should be a breeze. I’ve been waiting for this for a while. The barrier to getting an agile project up and running has just got lower. Check it out.

As someone who tends towards overdoing it, I have found the Cool Running couch-to-5k plan exceedingly helpful and would recommend it to anyone who’s feeling the urge to get off the settee and hit the tarmac. My usual running sprints (hah) tend to end up with me slogging to hit an impossible target followed by nearly a week of silly walks as my muscles unstiffen. So far I’ve had no post-training side effects, and every session leaves me hankering to get out there and do the next one. This is an addiction I could get used to.

Seems a bit messed up when Scoble leaving Microsoft rates a mention in the UK breakfast news headlines, right next to a slot describing the concern about the state of the US economy. ‘One of the world’s most famous bloggers’? For a definition of ‘world’ that only includes software geeks perhaps.

Those who do not pay attention to politics shall be at the mercy of those who do.

The fallout from having to cancel all my credit cards continues. Huge thanks to my hosting provider, JohnCompanies for not deleting my account after an unfortunate confluence of events involving them not being able to bill me for 2 months, and me not checking the email account that they were trying to contact me on. It might take a while for DNS to propagate, but the site is more or less back.

What I really really want…

I’d love to see EAR files made more useful by allowing them to be run from the command line. ‘java -ear MyApplication.ear -cp library1.ear;library2.ear’. Even more useful would be to make the default classloader understand EAR files as complete units of deployment, and allow different versions of the same jars to exist within different ear files. Borrowing from J2EE, it should be possible to have a classloader to look inside the local EAR when trying to load a class, and then look in the rest of the classpath. So if MyApplication.ear contains version 1.0.4 of commons-logging.jar and library1.ear contains version 1.0.2, any classes within MyApplication.ear would see 1.0.4, and those in library1.ear would see 1.0.2.

This does mean that if MyApplication was interacting with a class in library1, and tried to reference an instance of a class that was defined in both ear files, a ClassCastException would result, but in my opinion that is not particularly a limitation. If I need to use an API from a library, I should not be concerned with the libraries (or versions thereof) that it chooses to use internally. The present jar based paradigm simply does not allow me that encapsulation.

In my experience there are almost no situations where a setter method is a good idea. The wholesale replacement of a piece of an object’s internal state at arbitrary times leads to a class of interaction defects that are horribly difficult to track down. Most of the time solving them involves hooking up the debugger and stepping through going, ‘its fine here. Its fine here. Its still fine here. Its not fine here. Who called setName with an invalid value?’ and then debugging the call history of the method that made the bad call. Or alternatively, knowing that you have to call something like ‘accountService.updateBalance(account)’ before you can say ‘account.getBalance()’ or you’ll get a null back.

A class with all fields marked as final and initialized through its constructor is robust and easier to use than one with setter methods. You know that any time you have a reference to an instance of it, it’s ready to use and you can call methods without worrying about random fields not being set.

Note that just because all the fields are final and there are no setters, this doesn’t mean that the object is immutable. It just means that its behaviour more closely models reality, and your interactions with it will be far more meaningful. account.credit(amount) and account.debit(amount) instead of account.setBalance(amount). The balance is the sum of all the credits and debits, not something anyone can arbitrarily change (although I’d love it if I could just call my bank and say ‘please set my account balance to 1 million pounds’).

Which brings me on to my next point. I often see setters used where information relating to an object is not known at construction time, and needs to be added later. This is usually a symptom of choosing the wrong class to store that data. To continue the bank account example, a bank account (at least here in the UK) has certain properties. It has a sortcode and an account number, and probably an account name. These properties are pretty much fixed for the life of the account. (Sometimes they do change, but that is often dealt with as an account closure and opening of a new account with the funds transferred). There are certain things that an account does not have, which may surprise you.

A bank account does not have a balance. Not in the same way it has an account number. What an account does have is a series of credits and debits over time. When I call up my bank and ask for my account balance, what I’m really asking for is ‘the balance as of right now’. The snapshot of money in and money out since the account was opened that adds up to what is in it today.

Now lets say we want to encapsulate the concept of a balance instead of having to calculate the value from the list of credits and debits. I need the account it relates to, the point in time I’m interested in and, of course, the balance of the account at that time. A Balance class might therefore be constructed as ‘new Balance(Account account, Date asOf, Money amount)’. Those 3 pieces of information combined are immutable. They will never change. No matter how often I check my balance from the 10th of April it will always have the same value.

Thus its fine for a Balance to have an Account (and in fact completely meaningless for a Balance not to have an Account), but an Account does not have a Balance. Getting this kind of relationship right is at the heart of OO design.