A major part of this problem is of course how computing is presented, which is why I was excited to hear of Grady Booch‘s new project and attempt to change this. Grady writes:

“I need your help in telling a story, the story of the technology that has changed humanity: computing.”

His goal is to produce a television series that does for computing what Sagan’s “Cosmos” did for astronomy and science in general, but he is also intending to use other more inclusive media forms along the way. Given the man’s credentials, this is a very exciting proposition.

Rather than just reword what’s already been written, I’ll point you here.

We have a cookie implementation in place, the configuration of request handlers is now by annotation rather than in code blocks and there are more examples available. The package name has also changed to “org.apache.deft” (which was a strangely satisfying thing to handle), and the source has been formatted to something approximating a standard.

There’s really no excuse now not to come along, take a look and get involved!

Possibly the simplest of these to get right is continuous integration, by which I mean that all developer changes merged into a given branch are built as part of the whole with minimal delay and alongside all automated tests. At the core of this process is the build server, and we chose to use Jenkins (née Hudson) as it is breeze to install and – either internally or through available plug-ins -  provides all the functionality a development team could need, up to and including Chuck Norris. Nice features for example include automatic installation of Java and Maven as needed by the build, and specific to that build task to facilitate isolation from the server on which it is running. Installing Github connectivity through a plug-in was essential, and handled like all plug-ins through the application with nothing more than a couple of clicks and a restart. Following this I considered necessary only EMail-Ext, which helps ensure that notification emails sent contain useful information other than “the build is broken; fix it”, and Sonar*.

If you are unfamiliar with Sonar then I would urge you to follow the link at take a look. This platform collects varying metrics from the build and provides analysis on a per-build and continuing basis, and is highly extensible in the information that can be produced with everything from total lines of code to estimated cost of current technical debt. With Jenkins feeding data to this application every time the Sonar-specific build is successfully run, the second criterion of continued feedback is satisfied. All developers can see at a glance what state the application is in, and how that compares to any other build in the history. As the number of developers grows, and the code base with it, this kind of analysis can prove invaluable in identifying problem areas be they current or upcoming and in helping keep a steady hand on progress. One of the many metrics available is an analysis of violations based on the results of Checkstyle, and it is this tool that provides the primary satisfaction of the third requirement – continual imposition.

Whilst Checkstyle will report violations during the build as configured, it can also be applied directly within many popular build environments to ensure that developers are informed that their code is in violation of standards before they commit. Of course, Checkstyle is not the only useful tool here and in any case the standards need to be firstly developed… but that can wait a little while yet.

The build server is here, although there’s not much to see for the tourist at time of writing.

* Actually, Jim Petersson was unhappy with Jenkins’ blue balls (who is happy with blue balls?) and considered the Green Balls plug-in essential.

From now on I’ll just concentrate on my work with Deft, an asynchronous web server for the JVM. Let the good times roll!