I've just come across a very odd error while configuring one of our Hudson builds to publish cobertura metrics.

 The build failed, and the console log contained many, many errors a bit like this one:

FATAL: Unable to parse /var/lib/hudson/jobs/blah/builds/2009-11-27_13-37-31/coverage1986.xml
hudson.util.IOException2: Cannot parse coverage results
	at hudson.plugins.cobertura.CoberturaCoverageParser.parse(CoberturaCoverageParser.java:85)
	at hudson.plugins.cobertura.CoberturaCoverageParser.parse(CoberturaCoverageParser.java:48)
	at hudson.plugins.cobertura.CoberturaPublisher.perform(CoberturaPublisher.java:258)

Now I hadn't generated these coverage[nnnn].xml files, and nor did my build (at least, not when I ran it on my development machine). Inspection of the files on the hudson server revealed that they contained varying content, but each looked suspiciously like one of the files from my project.

Our hosted server recently ran out of disk space - an awkward situation. A little research revealed that /var/lib contained quite a lot of data - about 33GB more than we were expecting, most of it in /var/lib/psa/dumps/tmp.

Turns out that this is where Plesk puts its temporary files when doing backups, and for some reason they weren't getting removed, and in our case, they totalled 33GB. So... first of all we removed them, and then set about making sure the situation didn't happen again.

Chris Meller notes that sometimes the permissions on the directory get broken (such as when you restore from a backup), so I made sure that it was owner/group psaadm:psaadm and then, just to be sure, added a quick nightly cron job for root that runs the following script to remove any temporary files older than 90 days.  Job done. 

#!/bin/sh
#
# Delete backup more than 90 days old.
#
backupDir="/var/lib/psa/dumps/tmp"
#
daysToKeep=90

echo "Checking for files older than $daysToKeep days in $backupDir"
listOfFiles=`find $backupDir -mtime +$daysToKeep`
if [ ! -z $listOfFiles ]
then
      echo "Found [$listOfFiles]"
else
      echo "None found."
fi
for toDelete in $listOfFiles
do
      echo "Deleting $toDelete"
      rm -rf $toDelete
done
echo "Done."

This morning got off to a slightly shaky start with Lars Bak's presentation about the V8 JavaScript VM that's in Google Chrome not being visible on the screen for about ten minutes while they struggled with the technology. When he eventually got going, it was worth it, and very interesting to hear about some of the challenges in representing JavaScript classes within the VM. They ran some benchmarks - a browser race animating a circling spinner and some more conventional comparisons - between Firefox and Chrome. While I do tend to take these things with a pinch of salt, Chrome was genuinely around ten times faster than Firefox, which is at least enough to make one want to try it out. Now all we need to do is wait for the Linux and OS X ports which, Lars assured us, aren't waiting on V8 - that's done. The graphics is taking a little longer...

The highlight of the day was definitely Michael Nygard's long talk (the JAOO term for two back-to-back sessions) on failure. He presented some great war stories and examples of the kinds of failure that developers can generate with consummate ease when deploying applications to large-scale production environments. He expressed them as anti-patterns in the first session, and then spent the second offering some suggested patterns to be applied to counteract, or rather, prevent them occurring. He's an entertaining speaker, and I'm sure has sold quite a few copies of his book,
Release It!, as a result. I ordered a couple of copies for the office pretty much straight away.

In other news, Jim Coplien didn't shy away from insulting his audience and provoking controversy (as usual, some might say) in taking architecture into an agile world. I'm not sure that he actually ended up talking about architecture as such, but then it's one of those terms that can be used to mean many different things depending on the context. The other sessions of the afternoon were less spectacular - the ones on REST blogged about by Badger covered a lot of the ground that we've been looking at in the office recently, and which will, I'm sure, be covered by other Black Pepper blogs to come.

Just back at the hotel after a fairly long day and some interesting sessions. There seem to be a few very popular phrases here this year. People are talking about the differences between declarative and imperative programming languages - a great session by Anders Hejlsberg this morning on programming languages and the fact that we should perhaps be focusing more on the 'what' of programming rather than the 'how', with examples from C#, Linq and F#. Since we're reaching the limits of Moore's Law, it'll enable language systems to have more control of the 'how', and perhaps more importantly, the 'where', making systems more easily parallelisable and thus distributable.

Then I found out about Gant. It's Ant, but with build files written in Groovy rather than XML. There we go, the declarative/imperative comparison again. All the usual Ant tasks are available and accessible with syntax that looks very much like the original XML but translated directly to Groovy. If your build files are trivial, then it doesn't really gain you much, but if you're finding that your build.xml isn't very DRY, or you're ending up using a lot, then it's probably worth giving it a try. And if you're finding that you have lots of cause to use ..., then you probably ought to look at gant. If there are tasks that you find you can only achieve by calling out to external scripts (such as the example that we were talking to Martin Fowler about over lunch then there's no question. There's even a nice tool to convert your existing build.xml, ant2gant and a gant ant task so that you can write a 3-line build.xml to integrate it with your favourite CI tool. Nice.

After lunch there were a couple of interesting-looking talks on cloud computing, but one tried to pack waaay too much information in to the available time and so ended up going too fast; the other overran wildly and was a bit too much of a product pitch for VMWare (as I had feared from the abstract) for my liking.

As you may gather from other entries in this blog, we've been working on a customer project which uses Flex for the client and Java for the server, with SOAP over HTTP in between. It worked well for us as a combination, because it minimised the number of new things to be learned - helpful when you're dealing with, er, aggressive delivery timescale aspirations. I've been having a few doubts about its long-term viability, though. SOAP's pretty verbose, and I'm not sure how quick the marshalling to/from XML is in ActionScript. Anyway, I was lucky enough to have a bit of spare time to investigate BlazeDS as an alternative, and thought I'd share some of the experience.

I downloaded BlazeDS and the sample applications to use as a guide in converting my existing web application. I'm not going to go into all the details here since that's not really the focus of this article - the Adobe BlazeDS Developer's Guide is well worth reading. Our server side code is a Spring application, so some extra work was required to make Blaze and Spring work together. Fortunately, Christophe Conraets has written an excellent article on the subject, along with some very handy sample code, which I have made use of.

Our server-side code is a Spring application, but there are a few minor peculiarities in the way it uses Spring 2 Security. The server is completely stateless, so the Flex client has to authenticate each request. For the SOAP version, we pass an authentication token in a custom HTTP header (Flex prevents you from accessing certain HTTP headers, the Authorization header included). In the BlazeDS version, I had to find another way of authenticating, since I couldn't see a way of getting access to the HTTP request that it uses to send the request to the server, so no way of adding my custom header.

When you set up a new Flex Project in Eclipse (either FlexBuilder 3 or the plugin), the new project wizard asks you if you want to use a remote object access service, such as LiveCycle Data Services (LCDS). You can use the same option to access BlazeDS services running in a J2EE server. It requires that you have your BlazeDS server running, because the next step asks you to enter the root folder and root URL of your server.

If you want to be able to compile your Flex project without the server running, you can get around this.

If you look at the documentation for the mxmlc compiler, you'll see that the context root and the location of the services definition file, services-config.xml (which are the two things the wizard is really after), can be specified as command line arguments. SilentWalker talks about using this with the Flex Ant tasks in his blog.