Crap4j 1.1.6 is out. The new version features historical trends of CRAP metrics, and comparison by similarly tagged projects. Exciting!

Configuring CruiseControl the CruiseControl way from ThoughtWorks Studios presents what should be a standard practice. Checking your cruisecontrol configurations into version control and having cruisecontrol bootstrap with them.

Now I could see it getting tricky if you have multiple build machines, but it seems like that would be pretty easy to handle as well by using different config files for different machines, or something similar. That might violate the DRY principle, so it would be good to think a little more about it. How do others deal with this?

Like the title says.

This is particularly exciting because now it can be included in continuous integration setups.

One natural next step would be to set a threshold value so that crap4j would throw an error that would fail the build. I would be curious to hear comments on how people would like that to work.

Anyway, find out how to get the latest version at the blog.

A new version of crap4j has been uploaded to it's new home at http://www.crap4j.org/!

Please check it out and give us your feedback!

Tonight I'll be presenting a modified version of my upcoming Agile 2007 talk, To Catch A Bug, You Have to Think Like a Bug at the BayXP meeting hosted at Google in Mountain View.

I might also show off the new crap4j tool that we have been working on lately.

Tomorrow night, I will be giving a talk at the Association of C and C++ Users in Silicon Valley entitled, "To Catch a Bug, You have to Think Like a Bug". This is a new and improved version of a talk I gave at SD West, so if you didn't get to go there, you get another opportunity to check it out. I hope to see some Agitator's there. You can find out more of the details at the ACCU's website.

I am going to be attending sessions at JavaOne this week, and would be happy to meet with any Agitators or testing enthusiasts at the conference, according to Sun's Event Connect tool, I can paste this code and you can link to me in their event tool to set up a meeting.

I also set up a topic proposal for the JavaCamp, unconference that is happening Tuesday and Wednesday nights, on Adding JUnit to the Java Platform.

Here's the blurb for anyone interested:

Many language platforms, like Ruby and Microsoft .NET ship with a unit testing framework as part of the platform. Why not include JUnit in the Java Platform, or at least include it in the JDK? Code quality is a constant sore spot for commercial applications, so it seems like making the tools that contribute to higher quality more widely available will encourage better code. While we're at it, lets put in a code coverage tool as well, so we can see how well we're testing. We already have some profiling and management tools built in, so this seems like a missing piece of the puzzle.

I'd like to discuss this idea, and concerns around improving code quality with developer testing in general.

Tomorrow morning, I'll be giving a talk at SD West 2007 on developer testing. It is a a very opinionated look at how to test your code. It should be fun and useful. If any Agitators or other test afficionados are going to SD West, it would be great to see you at the talk, or afterwards as well.

Here are the details:

To Catch a Bug, You Have to Think Like a Bug

Mocks Aren't Stubs by Martin Fowler, is a very comprehensive look at two pairs of issues in testing: state-based verification vs behavior verification, and classical TDD vs Mockist TDD.

In light of the recent conversations about the adoption of developer testing on the junit list and Artima, this Turing Award lecture by Robert Floyd seems particularly appropriate. There's a particularly good quote where he is discussing a quote from Thomas Kuhn in "The Structure of Scientific Revolutions."

"Again from Kuhn:

"The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work."

In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development. "

Last night I needed to categorize all of the JVM opcodes according to their effect on the stack. Since there are around 200 of them, it seemed like it would be a tedious task. Fortunately, the JVM spec is online in an editable format. I thought, "Maybe I can parse the opcodes out of the spec and then put them into a format that I can use to build my categorization automatically."

Tom Ball has an interesting blog entry on a good use for finalizers. Library designers can use it to let users of their library know when they have not cleaned up a resource.

The comments on the entry are enlightening. One comments that this could slow down garbage collection. Another comments that they always make sure that any code in their library that has system resource handles manages the closing of that code. I have used this approach in the past, but it was somewhat ugly.

Late followup, but JavaOne was a lot of fun. My sessions went well and I got to attend several enjoyable sessions as well. Thanks to everyone who came to my talks.

For the talk about plugin writing, you can download the slides here

Read the original blog entry

I would like to introduce myself as a new Agitator. I am Bob Evans and I am working on some of the next product features for the Agitator.