A blog for jon@eaves.org

Menu

Monthly Archives: January 2004

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:

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

Now change directory to the directory above jcoverage-1.0.5, in this case /usr/local/src

Download the update105-105b.zip patch file from the above link to this directory and unzip it

Issue the command patch -p0 < update105-105b.dif

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.

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:

Write a test that would help prove that my code meets the acceptance criteria

Implement just enough code to make the test pass

Search my code for duplication and/or things that look yukky and when I find it, I modify it to make it less so

I now think of any other tests that need writing

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.

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!)

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.

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 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.