Jim Weirich has written up an excellent compilation of what Javaheads should know about Ruby. I wish he had written up 2 years ago when I started to play with Ruby.

Java has been my language of choice for many years. Learning Ruby has opened up my eyes about what OO, agile development and extreme productivity should be like.

I'm not "converting" from Ruby to Java - I always try to use the best tool for the job at hand. Sometimes it's Java, sometimes it's .NET, sometimes it's Excel or PHP. More often than anything else it's not even about programming. But when it is, Ruby turns out to be the best choice for me more often than any other language. Probably because I'm an XP head. (And because I still don't know Objective-C or Smalltalk - it's on this year's TODO list).

Ruby - because I can get the job done fast and end up with super readable and maintainable code. And I'm worth it.

Now if those big corps that I tend to consult for would dare to do more things in Ruby... I reckon it will take a few years before we see them changing.

Last year, right after joining ThoughtWorks, my colleague Chris Stevenson bounced off an idea to me during a Geek Night:

"How about a tool that deletes all code that isn't tested?".

I am still not sure whether Chris was entirely serious or not, but it was an intriguing idea that I have been thinking about quite often since then.

Now, the idea has been materialised in a new little tool in the Extreme XP Tools family: Guantanamo!

Guantanamo is eating its own dog food, and as a result, it has 100% coverage. I still haven't tried to run it over any other codebases, so it remains to see whether it is useful or not. -And whether it is something anyone would actually want to use.

I'll give it a try at work :-)

After a longish session pairing with Paul we finally released PicoContainer 1.0 today.

This has been a great journey so far. Paul and I started it right after I moved to London to start working for ThoughtWorks. It all started when I asked Paul one night whether he had heard of Inversion of Control. He got this weird expression on his face when I asked, and I couldn't quite figure out whether he was excited or depressed.

"It's my favourite pattern dood." (Dood pronounced in his native British)

So he got all excited and told me everything about IoC (I didn't have that much of a clue), and about Avalon - a project Paul had been with for a while, but was drifting away from.

My initial reaction (a couple of hours later when Paul didn't have any more breath) was:

"Why does it have to be that complicated?"

We quickly decided to do a spike on a simple piece of code that could do IoC style dependency management via constructors rather than via setters and ugly container lookups from within the components. It's kind of blurry to me how we decided to go for constructors, as we were both drunk when we started TDDing the first lines. I think it was some kind of eureka moment where Paul was thinking about a comment made by Rachel Davies while she was reviewing our colleague Joe Walnes et al's Java Open Source Programming, and I was just being new to this and thought about simplicity. The way I remeber it we unisonely burst out:

"Let's do it with constructors!" (Me left, Paul right)

This was also my first real journey into TDD land. I had known about TDD for a couple of years, but hadn't yet had that epiphany where it fundamentally changed the way I think about code - and religiously follow the practice. I think the first test looked something like this:

public class ContainerTestCase extends junit.framework.TestCase {
     public static class Fred {
          private final Wilma wilma;
  
          public Fred(Wilma wilma) {
               this.wilma = wilma;
           }
  
          public Wilma getWilma() {
               return wilma;
           }
      }
 
     public static class Wilma {}
     
     public void testShouldInstantiateClassesAndPassDependencies() {
          Container container = new Container();
          container.registerComponent(Wilma.class);
          container.registerComponent(Fred.class);
          Fred fred = (Fred) container.getComponent(Fred.class);
          assertNotNull(fred.getWilma());
      }
}

This was our first requirement - a container that can instantiate classes and understand what arguments to pass to the constructors. We alternated the keyboard rapidly and made the test pass. This involved some simple reflection logic and was implemented in a couple of classes.

The following days we added more features. Occasionally I would happily try to implement code without writing the test (requirement) first. It always resulted in a slap from Paul and a

"You're doing up-front design again. How do you know whether that is needed or even if it's going to work?"

So I gradually got the hang of TDD, thanks to Paul. (A couple of months later I was greatful for that. I was ruthelessly refactoring the entire codebase to improve the design. That would have been absolutely impossible without the extensive test suite we had built up by then.)

This was back in the days when Codehaus was a small place only hosting a handful of projects. About a week after we started Bob was kind enough to lend us a space for our new little baby, and that's when we named it PicoContainer.

PicoContainer quickly got Jon Tirsén's attention (who I didn't know back then - he has later become a good friend and also a colleague). Jon quickly joined the project and has since been an important contributor. Much of the nice modular design we have today is owed to him. Several other people (Joe Walnes, Chris Stevenson and Mike Hogan to name a few) also helped us in the early days, and Rickard Öberg blogged about it. PicoContainer was now a well-established project. This was late June 2003.

Half a year later my colleague Martin Fowler wrote an article about the concepts behind IoC and PicoContainer, and this is how the term "Dependency Injection" was introduced. (Martin initially coined it "Service Injection", but Rod Johnson refined the term during a Geek Night in the ThoughtWorks offices in London).

Lately we have invited some carefully selected contributors, and we will hopefully invite more in the future.

PicoContainer now has pretty good documentation, we have fixed some 180 feature requests and bugs. It's simple to use, and the jar is no more than 50kb with no external dependencies. There is a .NET and a Ruby port, and more in the pipe. NanoContainer is also an interesting sister project that adds scripted configuration using a multitude of script languages, as well as integration with WebWork, Hibernate and much more. (It's not that well documented yet, but we'll get there).

The best part of this story isn't PicoContainer itself. It is how many people have learned about dependency injection as a way to decouple their code (both internally and from the container itself) and make it testable and mockable. At the end of the day that will bring us code that is easier to maintain. It's your code that counts, and you should be able to choose what container you want to deploy it in - if you need a container at all!

Can't wait for attributes? Need them now? Check out QDox Attributes! http://cvs.codehaus.org/viewcvs.cgi/qdox-attributes/?root=qdox

Piotr JFDI'ed the long-awaited thing. An easy to use and powerful attributes package for the Java platofrm.

It draws the best from Ara's XRAI, Mark's Attrib4J, Jon's Nanning and Jakarta's Commons-Attributes. All of which failed to deliver a usable product, but (tribute) all contributed to Piotr's new brainchild via their ideas and code.

And if you don't care about attributes - just read the code and doco. It's nice. Very nice. The package scope is even com.thoughtworks even if Piotr is not a Thoughtworker.

This begs for an interview :-)

I'm writing an IDEA plugin. Ignorant of any other way to test it (yes, I have JUnit) than closing IDEA, reinstalling the plugin, reopening. Then HumanTesting.

IntelliBrains: Can you write an IdeaMock for us? So we can mock IDEA in IDEA? Or is there a way to launch IDEA from IDEA?

Puleeese!

:-)

PicoContainer needs a better logo. Get your brushes and submit your art! http://wiki.codehaus.org/picocontainer/LogoContest

I have been a hausmate for
a while now, so I am moving as much as possible of my OSS projects to
Codehaus. Then what's more natural than moving the blog too?

My old blogs were at freeroller and blog-city. Rest in peace.

I needed a more challenging job. So I started in ThoughtWorks UK a month ago. I'm glad I did.

A couple of weeks ago a colleague at work pointed me to a tool called Simian (Similarity Analyser). It works very much in the same way as PMD's subproject CPD (Copy Paste Detector).

I've written a Maven plugin for it. Have a look at a sample report.

With a tool like this, you quickly see candidates for refactoring.