It's Groovy.

Yes, but what's it called?

It's Groovy.

I've been working on a small application to help automate application deployments. We have some existing infrastructure built with Ant, but it's rather a but clunky, some of how it works is non-obvious, and it still requires more manual intervention that I'd like.

For some time, my friend Russel has been extrolling the virtures of Gant as a build tool. Gant is a wrapper, written in Groovy, for Ant which allows Ant tasks and Groovy scripts to be combined together in one big happy build script. I'd never really understood why you'd want access to a general purpose language in your build scripts, largely because I'd never needed to. Now that I was thinking as deployments as a 'build-like' operation (even though it really isn't), the appeal was obvious. I grabbed Gant and used it to bootstrap my application.

Groovy is a dynamic language for the JVM. Unlike many other dynamic languages on the JVM, especially those that originated elsewhere, Groovy takes a 'Java+' approach. Groovy looks like Java with extra bits, which makes it very approachable. You can start quite gently, writing code that looks just like Java and become groovier over time - looser typing, list and map literals, fewer semicolons, closures, and so on. Groovy does all the normal things you'd expect from a modern dynamic language (REPL available but can also be compiled, metaobject protocol, closures, duck typing, and so on). In addition, it operates seamlessly with Java code and libraries, in both directions. Seamless is a much overused term, but here it is entirely accurate. Groovy can freely use Java classes, and Groovy can be compiled to classes which can be called from Java.

It's pretty good fun, and I'm enjoying working with it. Right now, having previously used Jython and Javascript, Groovy would be my first-choice for a dynamic language on the JVM.

Like many of my programming chums, I believe in the importance of the build. Breaking the build is a bad thing. Knowingly breaking the build is, well I'm not a religious man, but it's a sin.

Sometimes the build goes wonky or tests start failing because of mishap or misfortune. Someone makes a change to one place in the code, somebody else makes a change in another part, something goes awry and oopsy. Of course, tools can help us here. If you've got something that regularly checks your source code repository for changes and rebuilds everything as soon as it does, then you can find out if there's a problem sooner rather than later.

These tools have a name, continuous integration servers, and are so called because they automate the process of continuous integration as described by Martin Fowler. You can put something together yourself pretty easily, but there are a ton of them available. We've been using CruiseControl, one of the more widely used CI servers, to reasonable effect over the past few months of pretty intense a development.

We want to push our automated build a little bit further. For various reasons that I haven't the energy to go into here, our environment is awkward. Putting a release up into the test servers is complex and still involves a certain amount of time and a degree of manual intervention. Consequently, it prob baly doesn't happen as often as it should. We're in a quieter period at the moment, but when things kick off again it's going to be a problem. What we'd like to do is finish automating that process, and having done that get our CI server to build and deploy nightly into our test environment. With that complete, we're going to try and kick off the gui testing scripts as well. Our testers can spend more time with their feet on the desk drinking tea, while the developers can be secure that yesterday's work does actually work.

Anyway, it's fallen to me to actually do this. One of the things I need to do was spent a bit of time fiddling with the build server. CruiseControl, while a sound piece of kit, doesn't lend itself to easy fiddling. It's driven by configuration files and every time you change the configuration you need to bounce the server, if you get something wrong it's not necessarily obvious why, and that just a faff and a time consuming one. By coincidence, several people on the accu-general mailing list had been discussing the Hudson build server. One thing that stuck in my mind was that Hudson could be configured entirely though its GUI. And so I gave it a try. I'm slightly ashamed to say that's the reason why, but I'm glad I did. Hudson is extremely easy to fiddle with - setting up builds, chaining different builds together, tool integration, and so on, are all straightforward and can be done via a web browser. I doubt there's anything it can do that can't be done with CruiseControl, but for exploratory work it's streets ahead.

Because I was in a poking about mode, I installed Hudson on the my own server. Working against the machine sitting on the floor by my right ankle was just easier than working against a machine several steps away on the other side of a Citrix connection that isn't exactly snappy and which occasionally slows to a treacly crawl. So I had Hudson and I needed some code. Fortunately, I had some. From installation to building the Mango library and running its tests, via installing a plugin to pull code from Bazaar repositories, took about five minutes.

I poked around Hudson a bit more and found a setting to draw a chart of test results. I can see why such a thing is useful in a team situation, but Mango is one man project. I build it and run the tests whenever I work on it. Poking some more, I found another setting that drew a chart of compiler warnings. That's when I had a little revelation.

Continuous integration servers are touted because they'll let you know, and know quickly when the build has broken. And that's true and it's a real benefit. But it doesn't apply for a one man project. In fact, I'm not even sure it's true for most multi-person projects either. What CI servers can do for the one man project is remember. Remember your test results. Keeping track of build times. Remember your compiler warnings. Stuff you wouldn't yourself record unless you were an outrageously meticulous record keeper.

As it happened, Mango hasd no compiler warnings in the build. However I had other code that did. Written in Java several years ago, I hadn't had reason to work on it for quite some time. Building with a modern Java compiler produced a slew of warnings, which I'd not had the inclination to fix. Hooking up Hudson to build it, within moments I had a chart telling me exactly how many warnings I had - seventy - together with breakdowns of warnings by type and class name, hyperlinked into the source.

As I explored the warnings report, some of them looked very simple to fix. So I fixed them and committed the changes. So Hudson rebuild the code and sent me an email telling me it had. That prompted me to look at the Hudson build console, where I saw the warnings graph had gone down a little. Which prompted me to fix another warning. You can probably fill in the rest.

By remembering what had happened in previous builds and then telling me in an easy to understand way, Hudson prompted me to fix a codebase that had languished for years. The second spike on the chart above is where, having sorted out everything in the main code, I turned on warnings in the test code.

The psychological effect of that graph was really remarkable. I decided to make deliberate use of it. When building Arabica I use GCC's default warnings. Recently I've been exchanging emails with Ash Berlin, who's using Arabica to provide XML support for the Flusspferd Javascript project. Flusspferd build at a higher warning level than I do and Ash had sent me a few patches to silence various things he was seeing. Setting up Hudson to build Arabica took, again, only a couple of minutes even though it's a C++ project using Autotools rather than a Java project using Ant. I cranked up the warning level. 600 hundred warnings! Blimey!

I suspect that Hudson's GCC warnings parser isn't quite as refined as the Java warnings parser, so I don't believe that was the true number. Neverhteless it was still a lot and rather more that I was expecting. They were gone in 15 builds. All of them, gone. I didn't have to make 600 individual fixes - a change in an include file can wipe out several warning messages at a stroke - but I think that's pretty quick. And I know I'll keep those warnings at zero too.

When I started looking at Hudson, I was just after something I could easily fiddle around with while working on our build and deploy. I didn't expect that it would creep into my brain and change the way I worked on my individual projects.

The viewer is available for download from Mozilla Add-ons. It's currently marked as experimental, which is Mozilla Add-on speak for newly released, rather than a warning it might trash your machine. It won't, and there are people who've been running it for several weeks without issue. It is, after all, just a bit of Javascript.

• Jeff Sutherland, creator of Scrum
• James Bach, testing big brain
• Dan North, inventor of Behaviour Driven Development
• Russel Winder, author, professor, raconteur, multi-core expert, and all around groovy guy

The pre-conference tutorials are

• A two-day certified Scrum master course run by Jeff Sutherland and Gabrielle Benefield. Sutherland doesn't come to the UK that often, I think, so if Scrum certification is on your list of things to do you might want to get in early.
• A course on testing session run by James Bach.
• An introduction to the D programming language by Walter Bright and Andrei Alexandrescu. Have to stay I'm not sure of the immediate utility of this (at least to me), but I can see this being a pretty intense session that would take months or even years to properly digest. That's good, by the way. Both Walter and Andrei are extremely smart and funny guys, and I bet you'd come out of this with a brain stuffed to the gunwhales. Quite tempted.

No official news on the rest of the programme, but it can't be long now. Reading the smoke signals suggest James' and my proposal didn't quite make the cut. I'm a wee bit disappointed because I think it would have been a pretty lively session. Still, have to wait for the thanks/no thanks email to be certain. Fingers still crossed.

Recently, we (that's the corporate we) have replaced a large web application developed in-house over many years with an equivalent system developed atop a 3rd-party content management system of precisely the category described above. The project went live on 6 September, having slipped 5 weeks on a 9 month plan.

This talk is not about how wonderful our CMS is or how wonderful we are. Nor can it examine the reasons why the previous application was obsoleted, or how the substrate for the new development was chosen. Instead, we want to look at the obstacles presented by our content management system and of our own devising, and how we overcame them. From that we'll try to draw lessons that implementors on and (this may be wishful thinking) vendors of large software systems might do well to learn.

The "we" doing the presenting here is myself and m'water-polo-playing colleague James. The "we" who actually did stuff is everyone we work with. Working with large lumps of other people's code is something that lots of programmers have to deal with at some point in their career. After a bit of a wobbly start, we did eventually start to motor, and our new system did go live pretty much on time. We learned stuff. Lots of stuff. Hopefully we'll get a chance to describe and discuss some of it at the ACCU Conference 2010 next April.

Confirmed speakers (alphabetical order) include:

• Tony Sale, lead on the working reconstruction of 'Colossus', the world's first digital computer. The original was used to break the German 'Lorenz' code, and played a vital role in the the run up to the Allied invasion of Europe. Personal web site at http://www.codesandciphers.org.uk/
• Simon Singh, author, journalist and TV producer, specialising in science and mathematics, and author of 'The Code Book', a history of codes and code breaking from Ancient Egypt to the Internet. Personal web site at http://www.simonsingh.net/
• Phil Zimmermann, the original creator of the PGP e-mail encryption package, which despite three years of government persecution became the most widely used e-mail encryption software in the world. Personal web site at http://www.philzimmermann.com/EN/background/index.html

The Conference will be held in the elegant Victorian Bletchley Park Mansion, at the centre of Bletchley Park itself, allowing conference attendees the opportunity to visit the exhibits on show at the National Museum of Computing and the rest of Bletchley Park. Bletchley Park is home to a number of unique artifacts, including the Colossus, the Bombe (including the mock-up that featured in the film 'Enigma'), original Enigma machines, and a Lorenz coding machine. The Bletchley Park web site is at http://www.bletchleypark.org.uk/. The National Museum of Computing web site is at http://www.tnmoc.org/

The conference is organised by the ACCU. The ACCU is an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming. The proceeds of the conference will go to the Bletchley Park Trust to help with the upkeep of Bletchley Park. Conference rates have not yet been finalised, but will be in the region of £95/person. The ACCU web site is at http://accu.org/. A full schedule will be available on the ACCU web site shortly.

For further information contact: Astrid Byro, or Alan Lenton