In a recent article on TechRepublic, Ilya Bogorad reminded me how the mere possession of an IT buzzword does not make for good practice. In this instance, the topic of discussion was ITIL, the increasingly popular IT Service Management approach, or a "framework of common sense" for IT service providers, as some analysts point out.

The same cautionary tale is true for Agile, which as a buzzword is currently on the ascendancy, but as a practice has been around for as long as anyone capable of remembering can recall, albeit in different guises: RAD/JAD, Scrum, and DSDM set the scene for what is now roundly known as Agile close to 20 years ago. So why the current hype?

Traditionally, hype is fuelled by a promise of something new or better than before. That's true for Agile methodologies - done correctly, they can deliver successful software projects faster, cheaper, and to a greater degree of quality than traditional lifecycles.

I've come across an oddity in my functional tests for a GWT application I am working on.

The Selenium RC test I have should simulate a user clicking on a button, implemented as a GWT PushButton (com.google.gwt.user.client.ui.PushButton). The problem is that the click on the button never seemed to work using the following code

 
selenium.click(BUTTON_ID);
 

A GWT PushButton is not a standard HTML <input type="submit" ...> or a <button ...> rather it is a styled button constructed from DIV and other HTML tags.

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.

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.

When using Tomcat 5.5 for either development or production it is sometimes useful to have multiple instances of Tomcat running at the same time.

The instructions below allow you to set up the minimum tomcat configuration to run multiple Tomcat instances.

1. Install a Tomcat 5.5 distribution. The CATALINA_HOME environment variable will point to this location.
2. Create a directory that will be your Catalina base, identified by the environment variable CATALINA_BASE
3. Within this directory create the following directories
   • logs
   • conf
   • webapps
4. From your base Tomcat 5.5 distribution copy the following files from $CATALINA_HOME/conf to the conf directory that you have just created:
   • catalina.properties
   • context.xml
   • server.xml
   • tomcat-users.xml
   • web.xml

With this structure one can now run Tomcat. Open a terminal, ensure that the environment variable CATALINA_HOME is set to point at the directory created in (1) above, set the environment variable CATALINA_BASE to point at the directory created in (2) above.

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!

Agile development processes provide several core disciplines that affect the overall quality of the system under construction. One of the fundamental disciplines in agile development is that of pair programming (“pairing”).