Bunk and Rambling

The ctrl+F4 key combination is one of my most frequently used keyboard shortcuts on Windows XP. Today, I noticed that it was not working on my home machine. This was caused by InterVideo WinCinema Manager, which was running as a system tray application. Anyway, the solution for this was to stop WinCinema Manager from running at startup. This was achieved with a little help from my friend msconfig.exe, a simple tool that allows you to control what the system runs at startup in addition to performing a number of other troubleshooting tasks. Allowing me to test the effects of disabling this application before removing it from my startup programs for good.

If you haven’t seen this before, it is worthwhile checking out. Just go to the Start menu, click run and then execute msconfig.exe.

As to why any Windows application would override a standard Windows XP shortcut like this is beyond my comprehension.

The ONJava.com article, Top 15 Ant Best Practices, covers the use of properties for the purpose of introducing configurable settings of a build script. As stated in the article, there are two approaches to defining properties, one being the use of the property element in the build script itself and the second being a properties file that can be included by the script using the file attribute on the property element. Often in build scripts you will find a mixture of the two. For example:

  <property file="build.properties"/>  <property name="src.dir" location="src"/>

In the example given, the purpose of including the build.properties file before declaring the src.dir property is to allow the properties within the build file to be replaced by properties defined in the build.properties file. This is possible because of an Ant feature whereby a property can only be assigned a value once.

It is possible, as the aforementioned Ant Best Practices article describes, to define all of your properties within a properties file rather than the corresponding build script. It is also possible to have properties defined in either or both locations. In some of the build scripts that I have encountered over time the usage pattern has been to define all static properties, i.e. properties that are not likely to change, within the build script and all properties that are dependant upon a user’s environment within a properties file. However, I would recommend against such an approach. I find that it is important to keep the build process self documenting. I feel that this is best achieved by defining all of the properties that you require in a single location, preferably the build.xml file. This allows you to operate without a separate properties file while enabling users with different environments to customise the build without the need to modify the build script.

One of the areas that this approach encounters problems is in relation to installation paths (for example the installation path of your J2EE container for deployment within the build script). In instances such as this, I believe that it is best to define the path that shall be used by the continuous integration environment within the build script’s property definition. In the event that a user chooses to deviate from the continuous integration conventions they may override the installation location through the use of a build properties file.

To summarise, define all of your build properties in a single location. This may either be in the build script itself or from a referenced build.properties file. To enable users to override default property values, ensure that the build script references a properties file (for example user.properties) that does not exist in the project distribution and encourage them to use this file for setting custom property values.

Tonight I have decided to try and check out Flock for posting to this blog. Thanks to Typo’s support for the MovableType API it seems like this is going to be a breeze.

Most important of all, I am now spell checking my posts using an English (Australia) dictionary.

I have finally taken the time to update the navigation area of the site. The changes that have been made are intended to provide a blog roll of some of my favourite sites. This is not a comprehensive list and is likely to change quite frequently. If you are reading my site through a aggregator then you may wish to visit with a web browser to see if anything is of any value to you.

Every Java project that I have worked on over the past five or so years has been dependant upon Ant for generating distribution packages. The time spent on these projects has ranged from only a few days through to many months and in some cases more than a year. As the code base continued to grow on each of these projects, so did the reliance upon Ant to compile, test and package the project artefacts. As a result, the project build scripts become some of the most valuable lines of code in any given project. For this reason it is important to consider the Ant build.xml file as a first class citizen on all projects.

For Ant build scripts to be promoted to the level of first class citizen, it is necessary to elevate these scripts to the same level as the application code itself. What this means is that Ant build scripts are subject to the same principles as applied to application code. That is, Ant build scripts need be in a working state throughout the project lifecycle. As with application code, the build scripts should evolve through the use of testing and refactoring. It is important that the process of refactoring be applied to build scripts to help improve the quality of the build as the project team evolves.

Refactoring is performed to ensure that:

• the build script clearly documents the build process without relying on external documentation or comments
• there is a minimal amount of duplication in the build script
• the build script performs in the way that it is intended
• changes can be performed efficiently and without introducing new bugs

Build scripts also benefit from the use of consistent coding standards, subsequent strategies shall provide suggestions on how to structure a build script based upon my experience as an Ant user for more than five years.

For a while now, I have been playing with the notion of posting an article on the strategies that I use to develop and maintain Ant build scripts. The hump that I have had to get over however was the fact that I needed to sit down, structure my thoughts and write two or more thousand words on this subject. Due to other interests and obligations this is never likely to happen. Instead I have opted for writing this article incrementally with a blog entry for each strategy.

Before getting started, if you are interested in learning more about Ant prior to being influenced by my suggestions, check out the Apache Ant project home page. You may also find a recent article by Russ Olsen in addition to the Top 15 Ant Best Practices article over at OnJava to be good starting points.

I enjoy listening to the .NET ROCKS! podcasts, but I had some problems with listening to the CSLA.NET 2.0 episode today all due to what appeared to be a throwaway comment made by Richard Campbell.

Near the start of the show, a brief discussion on test driven development (TDD) took place raising a number of interesting points. One of the stand-out statements in my mind was when Richard suggested that refactoring is the “antithesis” of TDD. Stating that TDD goes against the process of refactoring as you are less likely to make changes to code when you are concerned about breaking tests. What I think was misunderstood by Richard is that this is exactly why TDD and refactoring work so well together. The tests that are generated from the process of developing tests first create an insurance policy against bugs that may be introduced when refactoring. Further, the concept behind refactoring is to perform code changes to improve code without affecting external behaviour. What this means is that if you are breaking tests while you are refactoring then there is something wrong with either your tests or your application code.

Overall, refactoring and test driven development can help you have great habits for writing robust code if you approach them in the right way.

Due to an upgrade to Rails 1.1 on my hosting provider, this site has been down for a few of days. With some help from an entry on the Nuby on Rails blog, I am now back online.