It has long been of interest to me how reticent people can be when it comes to understanding computing. Despite its utterly pervasive role in society and its march from darkened corners into people’s living rooms and pockets, it is still seen as a wholly technical and complicated area. Those of us in the know, know different. We see a world within the world, populated with interesting characters and a rich history of success, failure and even tragedy. We see the philosophical, sociological and political ramifications of technological advancement that others don’t. In the end, this will present itself as a problem as we struggle to bridge the divide and realise the field’s fullest potential.
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.
Things are really starting to move with the project now. We have continuous integration in the Apache zone now, and the there’s finally a (partial) website in place. With the application itself, there are some nice changes.
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!
Deft has been accepted into the Apache Incubator, as per a recent vote. Exciting news for all concerned, and will certainly change a few things.
As a relatively new project, Deft has a small code base and only a few developers. This provides the perfect opportunity to implement a decent build environment, before things become too involved and problems ingrained. To my own mind, any team-oriented development environment needs to cover the single developer onward to the final deliverable and I see three key requirements: continuous integration; continued feedback; continual imposition.
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.
Having not particularly enjoyed rambling occasionally on this and that over the last couple of years, I gave the old blog the heave-ho. It’s archived here, although only a few pages seem to have survived. Still it was pretty crappy and so no great loss, although it is a shame about the book reviews…
From now on I’ll just concentrate on my work with Deft, an asynchronous web server for the JVM. Let the good times roll!