Bunk and Rambling

After missing an important meeting on Friday I have come to the realisation that maintaining multiple calendars on multiple machines may be problematic. Come to think of it, this issue has been lurking in the dark recesses of my mind for a while now. The root of this problem is tied to my work as a development consultant and the need to maintain ThoughtWorks, customer and personal schedule items in multiple systems. The development consultant aspect of my job affects me as I am not guaranteed to be working in front of any of my machines to receive meeting reminders in a timely fashion, if at all. The only thing that seems to be always near by is my mobile phone. So I am turning to it to solve my meeting notification needs.

While I look to my mobile for notifications of meetings, I realise that this is not the right tool to manage my calendar items. This is simply due to the screen size and speed of data entry that the device permits me. For a while now I have been maintaining my contacts in Outlook and synchronising with the phone regularly on my home computer. This gets around the input issues on the device, as I obviously have a full keyboard hooked up to my desktop PC. Unfortunately, I have limited access to updating this information while I am at work, meaning that this is not the ideal solution for my maintaining my calendar.

To that end, I need an Internet-accessible calendar for managing its content from multiple locations. For this I am planning on using Google Calendar. After having moved across some appointments I can understand why it is getting so many good reviews. Being able to extract calendar information in iCalendar format is also a great feature.

Now I have a tool to manage my calendar from multiple locations, another tool to remind me of meetings while I am on the go, but there is still a missing link, some way of getting the data from Google Calendar to my Samsung D600. While I initially looked at SyncML support on the D600 (which is supported) I was unable to get this working in the hour or so that I was willing to spend on it. In the interim I have opted to go with the RemoteCalendars plug-in for Outlook. What this allows me to do is to download my iCalendar data from Google and have it added to my Outlook calendar at home. From here I can synchronise it with my phone, which has proven successful to this point. My next project will be to remove Outlook as the middle man in the synchronisation process if possible.

For the time being this appears to solve my immediate problems of not being notified of meetings in a timely fashion. I know I still have to maintain multiple calendars (in fact I now have one more to edit). If it doesn’t turn out to be a silver bullet in this instance, I think I will just write my daily appointments on index cards and discard my Google Calendar.

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.

A number of months back I announced that I was beginning the search for a new mobile phone. After researching and playing with a number of different phones, I finally decided to go with the Samsung D600. The reviews that I had read for this phone and its predecessor the D500 really set this phone apart from the field. Before this phone even hitting my radar screen, the imate SP5 was the device that I was looking to purchase. This was due to the fact that I really wanted to play with a Windows Mobile 5.0 Smartphone and hadn’t been able to get my hands on one. I am happy however that the D600 came along just in time before I made a purchase. This is not to say that the imate SP5 is not a good phone, I can’t say either way because I have not even seen it in person. The D600 however is being carried by a large number of mobile resellers and on first impressions, it’s easy to see why.

I will post a more in depth report on the D600 once I have had some more time with it. For the moment, I am having problems with the SIM card that was supplied to me mid-week that I hope to have resolved tomorrow. Then I can really start to use the phone.