Marty Andrews

artful code

Friday, April 20, 2007

Aggregated blogs for Cogent Consulting

I've just finished putting together an aggregated blogs site for Cogent Consulting. It includes blog entries from all Cogent staff and associates. Its also the first Ruby app that I've written which has gone 'live'. The code was much simpler than I expected it to be. It's less than 50 lines of code, and about half of that is the declarations of all of the bloggers on the site.

Check out

Friday, April 13, 2007

Changing static factories to a testable design.

One of the attendees of the recent design improvement workshop that I ran sent me a question today. I've taken the liberty of changing the code a bit to demonstrate the example, but the intent is basically the same.

When we did the design improvement workshop we discussed how static methods can be a code smell. I'm wondering if you think this holds true for static factories since I don't feel right about creating a new instance of a factory just to ask it for an object ?

For example, I would normally have a factory like this:

public class ThingFactory {public static Thing create() {// ...}}

So the calling code would look like this:

public class ThingProcessor {public void process() {Thing myThing = ThingFactory.create();// ...}}

I'm a little anxious about code that looks like this:

public class ThingProcessor {public void process() {Thing myThing = new ThingFactory().create();// ...}}

Since we create two object's and only one is kept.

The problem with static methods is that they make unit testing harder. You can't override them in a subclass, and you can't mock them out. So the implementation you've got is the only one that can be called. Here's how I would implement the factory from the example above:

public interface ThingFactory {public Thing create();}public class DefaultThingFactory implements ThingFactory {public Thing create() {// ...}}

Now that I have an interface, I've got a mechanism that allows me to mock a method call. A useful trick to use in conjunction with that is to allow the actual implementation to be used by default in production code. You can do that with a combination of constructors like this:

public class ThingProcessor {private final ThingFactory _factory;// This constructor lets you inject a mock for testing.public ThingProcessor(ThingFactory factory) {_factory = factory;}// This constructor can be used by production code that just wants the default factory.public ThingProcessor() {this(new DefaultThingFactory());}public void process() {Thing myThing = _factory.create();// ...}}

The second design is much easier to test, yet the API for users of the ThingProcessor is exactly the same.

Screencast - software complexity on agile projects

About a week ago, I did a presentation to the Melbourne XP Enthusiasts Group about software complexity. I recorded the presentation as a screencast. The audio is a recording of me presenting to the live audience, so it hasn't been created specifically for viewing on video. It is still quite watchable though.

If you're interested in seeing it, it is now available for viewing on the Cogent Consulting web site.

Wednesday, April 4, 2007

Why aren't you changing your desk layout?

It seems that almost every place I go and consult at, developers are stuck in cubes with corner desks. You've got to be kidding me people! You all seem to know that software is about collaboration. You even laugh at the antics of Dilbert and his cube farm life. Yet you don't seem to be doing anything about it.

When you go home tonight, grab yourself a phillips head screwdriver. Bring it in to work tomorrow and make some adjustments. If you have some draws on your desk, take them off. If you have a return, take that off too. Put the draws somewhere nearby so you can still use them, but not under your desk. Now, take your monitor out of the corner, and move it to the square part of your desk.

Those simple modifications should mean that you now have enough room at your desk for two people to sit side by side and work at the same machine. Try asking a colleague to come over and give you some feedback on a bit of work you've just done. If she makes a suggestion, slide the keyboard over and ask her to show you a quick example of what she means. Amazing isn't it! Who would've thought that for no cost at all, you could get such a quick and noticeable improvement in the way you collaborate with people at work.