Following the completion of the development phase of a recent project, we needed to handover the project's source code to the client as part of the project delivery process.

We wanted to capture the project's history, so this would be available to the client's support and maintenance team. Fortunately, subversion provides a dump facility to do just that. Unfortunately, the dump process can produce huge volumes of data, and in our case, the output data was much bigger than the disc space available on the server!

The svnadmin dump command extracts all the data from each checkin and writes it in a fairly verbose format. We use a single repository for all our projects, and always have done, but we may have been better prepared for this delivery if we'd created a separate repository for this particular project.

In a former life, as a BEA Weblogic consultant, I'm sure I would have sorted this problem out so much sooner!

 We're using Apache's JackRabbit to provide a document repository and the configuration is done using and XML config file. Windows users appear to work fine, but on my Linux (Ubuntu) machine, the server reports problems reading the config:

org.apache.jackrabbit.core.config.ConfigurationException: Configuration file could not be read.: jackrabbit.apache.org: jackrabbit.apache.org
at org.apache.jackrabbit.core.config.ConfigurationParser.parseXML(ConfigurationParser.java:202)
at org.apache.jackrabbit.core.config.RepositoryConfigurationParser.parseRepositoryConfig(RepositoryConfigurationParser.java:181)
 

Tuesday

(Late Monday evening) Chatting with Martin Fowler and ThoughtWorks founder Roy Singham, I was asked to compare JAOO with other conferences that Black Pepper employees attend. The only real comparison for me was with JavaOne because that's the only other conference I've been to in recent years. But the difference is clear and JAOO wins by a Danish Mile.

The quality of the speakers, the material they cover, the ease of access from Europe, the focus on development and developers and the non-partisan context all make JAOO a much more exciting and rewarding conference for me. I still love JavaOne, but JAOO as something special for developers seeking to do better.

Google Analytics provides an easy to use interface that tells you which pages on your website are being accessed, how often they are accessed, and lots of other useful information about how your website is used. The problem for me on a recent project was to collect usage statistics for a Flex application. To use Google analytics you simply include a small javascript element in each page that's served. When the browser executes the javascript a small message is sent to google recording the page URL that was accessed and some other details about the client.

The first problem with a Flex application is that it's really just a single big(ish) download of the swf (Flash) file, so all that will get recorded is the fact that someone accessed your application. If the Flex application has several different views within a view stack none of the navigation between those views will be recorded. In addition, if the Flex application is using web services to communicate to a backend server, these requests wont be recorded either. Here's how I got my Flex application to record statistics of the navigation within the application and the web service calls made to a backend server.

When you register your website with Google analytics you're given a javascript element to include in your pages. Start by adding this javascript to your html file that loads the Flex application. It should look something like this:

The idea of a continuous integration deployment pipeline has been around for several years and is described in detail by Dave Farley and others in this ThoughtWorks paper. Following my recent experience with Hudson, I thought I'd show how to create a CI pipeline using Hudson instead of Cruise Control.

There are 2 aspects of the CI deployment pipeline that Hudson can most easily help with:

1. Managing binaries
2. Process Gates

The ThoughtWorks paper describes a binary repository as a shared file system where release candidates are stored. A key feature of the process is to promote the compiled binary artefacts through each stage of the pipeline without needing to re-build them. Each time a developer makes a checkin the system builds a new release candidate and stores it in the binary repository ready for subsequent stages to use. Each stage in the pipeline performs a series of tests (acceptance, performance etc.) against the same set of binary artefacts. A consequence of this approach is that the binary artefacts must be configurable for each target environment.

On a recent project we developed a comprehensive set of acceptance tests driven by Selenium RC. The UI acceptance tests were written using JUnit which meant we could easily run them as single tests directly from our IDE. In addition, because our build and deploy processes were driven entirely by ant, it made sence to use an ant task to run the acceptance tests too, and this was where I ran into a annoying little problem with Selenium RC on Linux.

The problem

When tests are executed a browser window will automatically open and close during setup and tear down of each JUnit test. When there are a large set of tests that take more than a few minutes to run, the opening and closing of the browser window can be very distracting!