jCoverage/GPL update 1.0.5b

After a week and no real response from the jCoverage team, I’ve decided to make my patch available. I’ve called this patch 1.0.5b so that it will not conflict with the jCoverage naming if they ever decide to update the jCoverage/GPL from their website.
The patch is available here and needs to be applied to the jCoverage 1.0.5 src download.
Warning: You will need either a Unix system, or a Windows system with the patch command available, using either Cygwin, or a native Windows patch.
For those who are unsure on how to best do this follow these simple instructions:

  1. Unpack the original source into a directory. This will actually create a directory called jcoverage-1.0.5. For the sake of the example, let’s assume that it was unpacked into /usr/local/src/jcoverage-1.0.5
  2. Now change directory to the directory above jcoverage-1.0.5, in this case /usr/local/src
  3. Download the update105-105b.zip patch file from the above link to this directory and unzip it
  4. Issue the command patch -p0 < update105-105b.dif
  5. Finally, edit the build.properties file and change the product.version from 1.0.4 to 1.0.5b

If using Ant to compile, then delete 2 entries in the build.xml that are <exec dir="${build.dir}" executable="bk"> as it is likely that you don’t have the bk executable on your system.
Then compile with ant clean compile jar or use your favourite IDE. (Note, using an IDE will end up with a missing Version.java, simply copy the Version.j file in the same directory to Version.java and change the value of the string (should you care).
Enjoy the new features. This means that it works with large (at least 822) filesets of class files on Windows, and if use the <instrument> target with the following:
<instrument ignorejavabean=”true”> then jCoverage will ignore getters and setters that are considered “simple”. The algorithm for determining simplicity is by examining the number of instructions that exist in the method, according to BCEL. It turns out that a getter with only a return foo; has 6 instructions and a setter with this.foo = foo has 10 instructions. So anything less that 11 instructions is considered “simple” and not instrumented.
Enjoy, and if you’ve got any problems, leave me a comment, or send me an email. I’m still hoping that this will make it into a jCoverage/GPL release soon, otherwise I’ll fork the codebase and host it locally.

Keep it Simple, but not Stupid

Along with TDD, which I’ve ranted about previously, one of the more misunderstood development practices of XP is the approach towards simplicity. Doing the simplest thing that could possibly work is not the easiest, laziest or most stupid thing that could work. However, as it turns out, this is a relatively difficult concept to communicate as well as a fairly difficult approach to put into practise.
This blog entry has been inspired by one of the Bill Venners interviews with Ward Cunningham titled The Simplest Thing that Could Possibly Work. Bill talks to Ward about how Ward and Kent came up with this principle of doing development focusing on simplicity. However, while this is a great article, I went away thinking, “well, Ward talks about simple, but he really doesn’t help me, or others, understand how to do that”.
So, I sat and thought for a while about what simplicity means to me and how I aim for it during design and development.
For me, simplicity of implementation is closely aligned to the principles described by Mary Poppendieck in her book Lean Software Development. These are related to minimisation of waste, and delaying of decisions to the last responsible moment. Minimisation of waste in code is making sure that at any point in time, we’ve got the code only implementing the functionality that we’re promising to deliver for that iteration (or release) and no more. Delaying of decisions also assists in keeping the code and environment to a minimum. In retrospect, how many times could the software have been developed, or delivered without the database, without the “important framework”, without the application server ? Certainly I know of many occasions the choices made in those matters have meant a more complicated environment that I’ve had to keep up to date for the entirety of the project. This just adds to my “inventory” of code and contributes to waste.
I can explain to people about how excess code means more maintenance and requires more attention. I can explain to people about how implementing a database and an application server early on in the development cycle requires more care and feeding during the course of the project.
I hear the cry “But what if I’d needed those”. In hindsight (a beautiful thing) in most occasions I could have implemented them later in the project with an absolute minimum of fuss.
Now, the process that I use to keep my code simple is as follows:

  1. Write a test that would help prove that my code meets the acceptance criteria
  2. Implement just enough code to make the test pass
  3. Search my code for duplication and/or things that look yukky and when I find it, I modify it to make it less so
  4. I now think of any other tests that need writing
  5. Go to step 1

Yes, I write my code in a TDD fashion. It’s not the only way, but I have found that it’s the easiest way for me to keep my code implemented in the simplest way. It’s a hard approach to take, because at every stage I have to fight the urge to introduce more code “just in case I need it”, but as each of the steps I take is fairly small, and I can focus on just making a single test pass I find I can keep control and keep my code simple.

jCoverage 1.0.5 GPL Version

I’ve made some updates to the free version of jCoverage, mostly so that it works while doing test coverage for BouncyCastle without having to split up the <instrument> task into smaller chunks of files as it appears that it barfs (or at least it does barf under Windows) with a large number of files.
At present the entire 800+ class files can be instrumented in one statement now. Certainly cleaned up my build file.
I’ve also added some other support to ignore methods that start with “get”, “set” and “is” as part of a request from a cow-orker. I’m not sure it’s done in the best way, as I’ve hard-coded that behaviour, but I’ll see if that’s the actual results that are desired before I make it more complicated that it needs to be.
Hopefully, I’ll get these changes rolled back into the main source code, I’ve sent off and email to the jCoverage authors, so I’ll just have to wait and see what the response is.
If anybody else wants the changes in the interim, either send me an email, or leave a comment (or both) and I’ll make the updated JAR available immediately, and the source available (it is GPL after all) when I see what the results of my email to the jCoverage team is.
Update 19th Jan : Sent patch file to Peter at jCoverage. Hopefully we’ll see a jCoverage/GPL 1.0.6 version soon. The update contains a new attribute for <instrument> called ignorejavabean which will ignore getters and setters so that is now configurable. (yay!)

More TDD wrong headedness

This time from somebody who probably should know better. Hani has decided to unleash a bit of bile at “the TDD crowd” due (in part) to a comment made by Jon Tirsen in a blog entry and so it seems from a less than successful IRC session.
Now while I’m happy for CrazyBob and Hani to do their unit testing however they like, (no really), I’m not pleased that Hani has decided to drag TDD into this. If you’re going to rant, at least do it properly, and make sure your facts are straight to begin with.
Please Hani, retitle this post as “Kill the Unit Testing Weenies” or something similar, as all you do is rant on about testing and how you want to unit test however you like. Go to town, test away. That’s great. Do your Unit Testing after you’ve written your code. That’s excellent. Testing is good, the more people that test their code, the better.
Repeat after me;
TDD is an alternative design process, not an alternative testing process.
I still write integration tests, system tests and user acceptance tests, and my unit tests are probably somewhat more fine grained than yours (not better, just different). However what we do is a different way of designing our system, not a different way of testing.
Now, before you accuse me of “being snooty, getting offended, and angrily tugging at [my] unmentionables”, take a deep breath, and re-read what I’ve said. I don’t care how you develop software, provided what you develop is good. (Actually, if you develop crap and I don’t have to maintain it or use it I don’t care either). For me, developing software using a TDD methodology has meant that my designs conform to many of the OO goodness principles that I blogged previously.
As for the “TDD crowd”, I can’t (nor want to) speak for everybody who falls under this banner, but I like writing software this way, but I’m sure as hell not going to waste my time trying to convince other people that “it’s the one true path”.
I’m too busy trying to get people to understand what TDD is actually about, rather than the many-headed hydra of mistruths, half-lies and misconceptions that is rapidly popping up these days.

The long search for my RSS reader

I’m still looking for an RSS reader. I stayed with FeedReader for a while, but it’s just too buggy, and it’s been too long since it’s been updated that it looks like another OpenSource project destined to live on SourceForge forever. It’s a shame, because it had great promise, and obviously great talent behind it.
I’ve now started using NewsDesk. This is a .NET based interface so you need the .NET runtimes installed on your computer, and yes it’s a Windows only client (not that I care that much about that).
The things I like about it so far ; The configuration and installation was easy, the layout of the feeds is good, and the creation of new feeds is good. It’s a little buggy in adding new feeds, as you can supposedly just drag the XML feed icon to the application and it will install a new feed, but that just doesn’t work, it’s a little enthusiastic with the text that it looks at, and ends up with comments and other junk which prevent it from finding the URL.
I’ll keep trying this one for a while and see where it goes. At least this client has an Export facility to export the feeds so I can share with other people, and upgrade in safety. FeedReader forced me to retype/re-enter all my feeds which was a real pain.

TDD is like teenage sex

TDD has hit the mainstream and every man and his blog has some sort of article about it and how it should be done.
Sadly, it’s somewhat like teenage sex, everybody is talking about it, most are not doing it and those that are doing it, are doing it wrong.
Firstly, there is the big mistake that TDD has something to do with testing. Here’s the big clue for all you programmers out there. It’s not. It’s a different (some may say incremental) design technique that practised properly ends up with designs that conform to many of the principles that Bob “UncleBob” Martin has been talking about for ages. For some really interesting insights into building large and complex systems using OO techniques have a look at these:

These topics are also covered in Bob’s book, Agile Software Development: Principles, Patterns, and Practices in much greater detail. Don’t be fooled by the title, it does cover a bunch of the Agile practices, but it really is about building OO systems in a professional way. It is very, very good.
Now, onto my next missive, TDD is hard, but it’s hard in a good way, not hard in a bad way. Hard in the feeling of satisfaction that you get after exercising. And in many ways, that’s what it’s all about, keeping your code in good shape. There has been a thread started with this message in the Extreme Programming mailing list that really highlights doing it wrong. The best news here is that if TDD starts to feel hard in a bad way (seems messy and untidy) then you’re doing it wrong.
TDD practised correctly does produce good flow, and things come together cleanly. A part of TDD is the concept that the test code is a first class user of your production code. Purely by having “2 masters” during development goes a long way to conforming to many of the principles mentioned above. However, to prevent a number of the issues found in the TDD doubts thread above it’s almost a certainty that much of the testing code will rely on using mock implementations. However this can also go wrong.
For a bit more on the philosophy difference of mock and Mock, Marty does a great job of clarifying the difference here.
Finally, if you’re interested in learning more, read the book by Kent Beck, Test Driven Development: By Example and if you’re a Java developer JUnit in Action is also excellent.


Just found out how to use trackbacks to reference other blogs. Rather neat. Well done chaps. For those wanting to know more about it, look here
However, it does have the unfortunate aspect of linking the name of the blog, to the article (or at least where I’ve done it on the java.net weblogs). With my blog name, that may seem rather more inflammatory than I actually want, when in fact, the title refers to me.
Oh well.

Objection Mr Santos, leading the witness

I’m going to confess up front that I like checked exceptions, and I feel that the lack of checked exceptions in C# condemns the language to something that is a toy, a sham and something that should never be trusted to be used in enterprise development.

Now, some of my colleagues and friends may not agree with me, but I don’t care. This is one windmill that I’m prepared to tilt at, and keep tilting at until people get the point. Unchecked exceptions are ok if you don’t mind having to read all the code to work out what is going to happen when you miss catching something and then have it fail in a place miles away from the actual error. Checked exceptions done properly (remember, done properly) are an absolute bonus to layering, failure management and robustness. They don’t “spiral out of control” as many critics say. If you have 100’s of checked exceptions in your tiny program, then you’re doing it wrong. Having a “try/catch” block is good programming practice, and not “too much typing” as critics argue. If you can’t be bothered writing code properly, then sod off and write some crappy VB that people expect to crash. Leave me to write Java code that works properly. Don’t sully the name of the Java industry with your shitty code.

Now, back to the title. In this weblog titled, Things that could be different – Part 1: Exceptions Mr Santos waffles on about something being wrong with the Exception mechanism and tries to make the point that this block of code:

try {
} catch (Exception e) {
//do something and...
throw new BusinessException(e);

Would be better handled if we had new classification of Exception called CheckedException and UncheckedException so that it wasn’t hard to separate the two. Ahem, “Objection Mr Santos, you’re leading the witness.”

Frankly, this particular load of bollocks is only setup by doing something mind-numbingly stupid. Any developer who has the catch (Exception e) code and thinks that it’s OK should be taken out and burnt. Simple as that. Some may say my stance is too strong, but frankly, we need to be rid of those people before they can teach anybody else these sorts of things.

To people who persist in writing code that looks like this I offer this advice; do yourself a favour, and learn to program properly. That would make everybodies life easier and we wouldn’t have people wanting to change the Java syntax as their new favourite indoor sport.

Ant 1.6 is a step forward

After using Ant for many years and complaining how it’s slowly being screwed up by introduction of control structures and other such rubbish I’m pleased with the release of 1.6. 1.6 contains some much needed features for enterprise use of Ant. The most notable of these is the introduction of a macro specification via the macrodef element, and finally the inclusion of a decent import facility. These two now make it possible to create reusable sections of XML and in the case of the import have a target “overridden” by a target of the same name in the master build file.

Hooray I say. Now it’s going to be a matter of going through a bunch of my old build.xml files and extracting useful macrodef candidates (I was using antcall for this).

As an example, here are some build files that I’m currently working with.


<project name="skillsmatrix" default="compile" basedir=".">
<property name="props.POI_ROOT" value="d:/var/jakarta-poi" />
<property name="poi.root" value="${props.POI_ROOT}" />
<property name="poi.jar" location="${poi.root}/build/jakarta-poi-1.5.1.jar" />
<import file="general-macros.xml" optional="false" />
<import file="standard-targets.xml" optional="false" />
<application-property-setup root="${basedir}" name="skillsmatrix" />
<application-classpath classes="${app.classes}" >
<pathelement location="${poi.jar}" />

And the macros live in the file general-macros.xml, an extract looks like this:

<project name="general-macros" >
<macrodef name="application-compile">
<attribute name="srcdir" default="${app.src}" />
<attribute name="destdir" default="${app.classes}" />
<attribute name="classpathref" />
<attribute name="excludes" default="" />
optimize="on" >
<classpath refid="@{classpathref}" />
<macrodef name="application-classpath" >
<attribute name="classes" />
<element name="jar-files" />
<path id="app.classpath">
<pathelement location="@{classes}" />
<jar-files />

And finally the targets. Notice how the import files have a fully structured project node around them. Just like a normal build file.

<project name="standard-targets" >
<target name="init">
<tstamp />
<echo message="Checking environment" />
<echo message="     OS = ${os.name}" />
<echo message="   Home = ${user.home}" />
<echo message="Project = ${app.name}" />
<echo message="Basedir = ${app.root}" />
<echo message=" srcdir = ${app.src}" />
<property name="tmp" refid="app.classpath" />
<echo message="CLASSPTH= ${tmp}" />
<target name="mkdir" >
<mkdir dir="${app.classes}" />
<mkdir dir="${app.jdoc}" />
<target name="clean">
<delete dir="${app.classes}" />
<delete dir="${app.jdoc}"/>
<delete file="${app.jar}" />
<target name="compile" depends="mkdir" >
<application-compile classpathref="app.classpath" />

Notice how in the target include file, the use of the macro defined in the other file. As this is my first pass at getting these structures to work, I’m sure I’ll find better ways as time goes on, but the signs are good !

Removing an ex-girlfriends phone numbers from your phone

Had an interesting MTB ride yesterday with my beautiful wife Sue, and coding legend Simon Harris. Interesting in the Chinese curse sense, 3 stops due to punctures, damn the hot weather making the thorns extra spiky. As a result, the 40km ride which normally takes 2-3 hours (including lunch) took closer to 5. So, to make up for stealing all of Simons day, we invited him over for dinner (conflagrated dead animal, beer and red wine) and during the evening Simon made this comment.
“I always remove ex-girlfriends phone numbers from my phone so that in a moment of weakness (or drunkenness) I can’t call them. They’re ex-girlfriends for a reason”.
Anyway, the evening continued on, more food was eaten, and more wine was consumed and nothing more directly was said about the comment. I woke up this morning a little worse for wear but I couldn’t get the comment out of my head. There was something more fundamental about the approach than merely just saving face, avoiding a potentially difficult social situation or restraining orders.
It’s an important part of software development, the deprecation and removal of code that’s no longer used so that it’s not used by others. This is extra important with regard to API’s and follows on from a discussion I had with fellow ThoughtWorker Jason Yip.
The corollary for the software world of the insightful comment by Simon is really:
“I always remove unused code from the codebase so that in a moment of laziness (or stupidity) it can’t be used again. It’s unused for a reason”.