Joe's Jelly

QDox moved to codehaus

Mon, 21 Apr 2003 10:24:20 GMT

QDox has moved to qdox.codehaus.org

JUnit integration in IDEA

Sat, 15 Mar 2003 17:38:39 GMT

My colleagues pointed me to the latest IntelliJ IDEA EAP.

It has awesome JUnit integration. Nice work boys.

Screenshots for the curious:

Life without Google

Wed, 05 Mar 2003 20:27:46 GMT

Last week I couldn't contact Google. I could get to other sites but not Google. Couldn't even ping it.

My lifeline had been cut. The internet was still there and so were other search engines but the power I take for granted had gone. I actually started to panic and began thinking - how would I continue without Google? Google returned after about twenty seconds but it seemed an eternity.

Information access is an addictive habit - easy to get hooked and hard to kick.

Stop for a moment and imagine what would happen if Google went offline tomorrow.

NMock - dynamic mock objects for .NET

Mon, 17 Feb 2003 21:32:21 GMT

Time to plug NMock. It's a dynamic mock object library for .NET based on work Nat Pryce did in the Java MockObjects project.

It's one of those things that we wrote very quickly (completely test first, of course) in hardly any time at all. It was written last October and I've been using it on a number of projects (as have other people) with no problems - it just, like, works.

All you need to do is supply it with a class or interface that needs to be mocked and it will dynamically create a new class on the fly (by emitting .NET bytecode) that acts as a mock object. This mock can be setup with return values and expectations. Expectations can be simple things (such as equality checks) or custom constraints (such as a regular expression).

What's great is that a bug was found (well, an unimplemented feature) by Jeremy Stell-Smith last week. And he went about reporting it in the most ideal way possible. He supplied a failing unit test. So we added it to the suite and fixed it (with one line of code) and everything was green again. It took less than a minute to fix a bug I knew nothing about. In the words of Mr Stell-Smith - Sweeeeet.

Why can't all oss projects work like that?

Go look at a simple example

Eclipse shortcut keys

Mon, 17 Feb 2003 21:20:32 GMT

As a recent convertee from IDEA to Eclipse, it's very hard to get your bearings unless you know the shortcut keys.

So here's a list of the most useful keys. Print them out and stick to your monitor - you'll never have to touch your mouse again and you'll fly.

http://wiki.truemesh.com/joe/EclipseKeys

XPDay 2

Mon, 17 Feb 2003 20:53:37 GMT

Some photos of the Agile Tools for .NET presentation Owen and I did at XPDay. What am I doing with my hand? Oh and here's the slides from the presentation.

Test coverage tools and mutation testing.

Wed, 05 Feb 2003 06:07:20 GMT

We first set off by requiring a 95% coverage before commit. This was a bit a pain in the ass but it was basically doable. This made sure all features in the system had tests, it's simple not possible to commit anything without tests when you set the bar as high as this. But this is doesn't necessarily it's test-first development, it's just tested development. [jutopia]

I love test coverage tools. Another team at work was working on deciphering and robustifying a hairball project by slowly retrofitting tests and refactoring. Each day they managed to push the Clover bar a tiny bit higher and it served as a goal. Today we'll get it to 20%, 30%, 90%....

Unfortunately coverage tools can also be misleading. It's easy to write code that covers the lines of code but doesn't actually test them. A complementary approach is to use code mutation tools such as Jester - The Test Tester.

Jester takes a class and a testcase and runs the tests to check they all pass. It then makes tiny changes to the class under test, one by one, and reruns the tests each time. If the lines of code are tested properly, every little change should cause at least one test to fail. If the tests still pass it notifies you that you are not testing that line properly.

Although it's harder to use Jester and not typically something I'd do everyday, it has told me some very interesting things no other tool has pointed out about my code. Aside from pointing out lines of code that my tests execute but don't actually test, it has also pointed me to flawed algorithms that can be greatly simplified.

Ivan Moore has written some good stuff on the subject here and here.

JDO, or O/R

Mon, 03 Feb 2003 22:08:21 GMT

JDO, or O/R

So somebody pointed me to JDO. It seems to be a good replacement for our DAO layer. Map your objects to a DB without too much complexity. But I'm quite hesitant: will it solve our performance problems? Will it be as easy to convert our application as it looks? Even worse: if we decide to go for JDO, do we need Sun's JDO spec, or is Castor's better? Sun's spec doesn't seem to have a free implementation, which makes it riskier to invest in that option. I've heard a lot of good of Castor, but it was about it's XML serialization. Are they as good in O/R mapping? I'm looking into it, but real-life experience would be very welcome. I'm kind of searching around in the dark, with a flashlight that only reveals positive points.[Feelings and Thoughts]

Despite the contravercy, JDO is actually a really awesome spec. If you can live with having to incorporate a byte code enhancer into your build process it offers a very clean and elegant solution with very minimal overhead on your code. If you are going for JDO it's best to hide all the javax.jdo stuff behind a simple facade as it's a bit convulated to get started with.

The downside (and upside) to JDO is it's only good as the vendor implementation you choose to use. Unfortunately, most are no good - including the reference implementation.

I can vouch for KODO though as it's a truely AWESOME implementation (the finest O/R tool I've ever come across). It's a commercial implementation that's licensed quite reasonably on a per developer basis with a royalty free runtime. My favourite feature of KODO is the sensible defaults. In almost most cases all I need do to a class to make it persistent (and ensure the database schema is setup correctly) is add the @persist JavaDoc tag. KODO is very robust and scales wells (even in clusters).

If you want an opensource tool, Hibernate is also a fine choice. Featureswise it matches KODO and is very flexible to work in a way that suits you best. The main drawback is that it is a bit more work to persist an object.

Of course, life is simpler still if you avoid the relational database altogether :).

Language of the year

Thu, 30 Jan 2003 21:11:46 GMT

The Pragmatic Programmer suggests learning a new programming language (at least) once per year. Specifically, you should learn a language that changes the way you think about things - learning C# if you know Java doesn't count.

Last year I decided to learn Ruby - a lot of people told me how great it is. At first I thought it was pointless, but I eventually dived in. Man, I'm glad I did! I've since fallen in love with language.

Ruby is an incredibly clean and concise loosly typed OO language - a much purer OO than Java as everything is an object. It has some very nice features such as blocks/closures and the ability to create new types on the fly. But what it really taught me was the power of simplicity. Using Ruby I could solve problems quicker, with far less code which was easier to maintain and well designed. And the code looks so good to - zero fluff. Learning about simplicity was very much a theme for me last year.

On top of that I had to get to grips with maintaining loosly typed code. I never really mastered this in my Perl hacking days which is probably why I love Java so much. However, I've since become test-infected and cannot write a line of code that isn't test first (seriously - I can't - it's annoying sometimes!). The great thing about becoming test-infected is you end up with very very strongly typed code. Effective unit tests show many more problems than the compiler as they actually test the code does the right thing rather than just if it's syntacticly correct. And the tests provide an excellent reference manual for your objects.

So anyway, Ruby has changed the way I think and I really would write business applications in this language (if I could convince the clients I work for).

But it's a new year now and I'm looking for a new language. So what do I learn?

Smalltalk has been recommended but I think I may have already learned some of it's most important lessons through Ruby.

From chatting to colleagues, I've narrowed the list down to:

LISP (with CLOS and MOP)
Scheme
Haskall
Self

So, which one should it be? How will they change the way I think? What will you be learning this year?