2Paths Team Blog

In April, 2008, I attended the “No Fluff, Just Stuff” in the guise of the North West Software Symposium, in Seattle, Washington, USA. For those not in the know, the NFJS series is aimed at tech savvy developers interested in expanding their knowledge and exposure to interesting developments in the land of Agile/Java (predominantly). With another symposium coming up in September, I thought I would pen some thoughts from my attendance of the April event to encourage others who may be interested in attending this series.

The welcome from Scott Davis was a fun introduction to the spirit of the conference. His jovial nature and passion for all things agile and groovy was instantly infectious and a great ice breaker to the weekend.

Here is my take on some of the sessions I was fortunate enough to attend.

groovy is groovy, yeah
Scott Davis, being a very groovy evangelist, sparked my interest in this not so new, yet very groovy dynamic language which is really Java by another name. The underlying take away from his Blue Pill talk was that Groovy can be useful even for those who do not totally drink the coolaid of hoopy dynamic possibilities afforded by all the runtime hackery allowed via groovy. The terse syntax and ability to obviate the need for boiler plate code in tests and domain models was very appealing.

Subversive agility and Test Driven Design
Neil Ford gave a rousing keynote which outlined his philosophy on agile and how to ensure naysayers are converted to the way of agile. In essence, if you can’t use subversion, use subversion!

Neil also gave an interesting talk on test driven design. This was intentionally not about test driven development as he focussed on the different way of thinking which is engendered by adhered to a test driven approach. As developers we often get caught up in following the path well worn which can be limiting when it comes to solving problems. By adopting a test driven approach, one’s ability to think different (to steal Steves bad english) is developed as we start thinking of solutions in a top down, loosely coupled approach which definitely helps design.

Metrics are bad mmm … Kay
Neil also gave an interesting talk on metrics. He covered many things including burndown accuracy, code coverage and performance. Whilst many people get caught up in the game of numbers he made a very good point - that its the trending of metrics that are more important than the absolute numbers. As a project progresses, it is more important to have improving metrics (code coverage, and better accuracy of burndown estimates) than it is to have good numbers. He also made a bold statement in saying that code coverage should always strive to 100% - one does not want to have code going into production if it has NEVER been executed in your test environment. A very poignant point indeed.

Business driven development
Venkat Subramaniam gave a number of talks on agility and dynamic languages (groovy once again). He is a very interesting speaker with a dry wit and sharp mind. It was quite entertaining listening to him speak. One of his talks was on business driven design and he outlined a number of techniques for rapid prototyping of tests and business requirements using FIT and BDD. It was a great introduction to some very customer focused ways of developing agile solutions.

In all I found the conference extremely enjoyable and very enlightening. Most of all it was great to get to interact with other dev-heads and to hear form some talented folks out there. It was very heart warming to see that in most of the straw polls on agile methodology usage and implementation, the 2Pathians were able to raise their hands and say “we do that” whilst many others were left in the “we want to be able to do that but …..” camp.

I would highly recommend the NFJS series to other folks out there.

Scott, Ted, Venkat, Neil Ford

Good to see we are using lots of tech that is interesting - need to add groovy to it

Continuous integration is a lovely thing. Automated testing is also lovely as you can see where things work or not almost instantly in different environments and scenarios.

Over the years I have used a few CI servers and tools - most notably, CruiseControl (Java and .NET) and Continuum (from the Maven crew). These systems, whilst useful, cam e with a few annoyances, most notably their slight fiddliness in getting up and running. Whislt they worked, it seemed that there were always tweaks required here and there to get things running smoothly and when things went wrong they we not that easy to correct.

After chatting with a few friends, I thought I would give Hudson a try as it seems like a new contender for CI server of the month. Spurned on by glowing feedback from said friends I though I would see how easy it would be to try and aggregate our disparate CI servers (For Java and .NET) into a single hudson installation - something advertised to be easy on the tin.

Here are the steps I followed:
- download WAR, runit
- config master/slave
- config maven app
- config .NET app
- force some builds
- too easy

A simple distributed build system that works cross platform sounded too good to be true, however it seems that hudson is well on the way to being just that. I couldn’t believe how easy it was to get a distributed build/CI system up and running and building/testing our Java and .NET apps with all reports and config managed centrally. I especially like the simple reports on build trends and the weather paradigm used for displaying build stability.

After this simple proof of concept, we moved the setup to a cluster of VMWare instances (Linux and windows) so we can now build multi-platform apps and manage things centrally for all projects. This is now our main CI platform and seems to be working well.

Hurray for progress!

One of our recent projects has a .NET backend (with a JavaScript frontend). As we use macs for our dev platform, this means dual booting or using parallels in order to fire up Visual Studio to work on and debug the backend using the embedded ASP.NET server … until now.

The other day, out of curiosity, I downloaded Mono for Mac OSX to see how it works and if it would be at all viable to use as a development tool for .NET projects. With the installation came a Mac version of the MonoDevelop IDE which supports Visual Studio 2005 solution and project file support. I thought it sounded too good to be true but decided to give it the five minute test to see what might happen. I did a fresh checkout of the codebase, fired up MonoDevelop, opened the projects solution file and unsurprisingly some things did not function. For one, we use an add-in for Web Deployment Projects which wasn’t recognized. Additionally there seemed to be some build issues when trying to locate our logging DLL. With a bit of poking (literally a few minutes) I had found that all we needed was a hint in the project file to point to our DLL and the project built - very scary. Next thing was seeing if it would run.

As it turns out, Mono comes with an ASP.NET server called xsp2. Even more interestingly, editing the properties of the web Cleint project in MonoDevelop reveals very simple integration with xsp2 as an embedded server. This was all looking too good to be true. A simple config change (ports) and then I hit run for the client project and was amazed that the thing actually came to life and seemed functional. Very shocked was I!

There was a minor problem in that our configuration service was reading files and serving them to the client but had issues with line endings given the difference between windows and mac platforms and their ideas of what a line ending should be (for the record its \n!). That was swiftly fixed and the app not only came to life but was fully functional.

Admittedly, MonoDevelop is a pretty rough IDE but the fact that it took less than 30 minutes and not much tweaking to get things working was quite a lovely surprise!

With great vigor and a sense of wonder we headed into the great wide open that is Whistler Mountain. It’s not often that one can enjoy a day (or weekend even) on the slopes thanks to one’s workplace yet that is indeed what we were able to do as our work Christmas do.

Most of us stayed together within the confines of a lovely condo within Whistler Village itself. This allowed for some more relaxed socialising and a distinct family feel to the weekend as we all got to know each other better. The weather was fabulous and the snow was in immaculate condition, being so early in the season. As a group, those of us more comfortable with the terrain managed to stay together and enjoy the skiing/boarding together which is sometimes rare with larger groups as the more hardcore lose patience and trail off to find their own powder moments.

The thing that struck me most of all, apart from the great conversation, excellent skiing and riding and all round good times, was the fact that in two days of constant interaction, we all managed to NOT talk shop. This indeed is something that I think highlights our abilities to gel as a team (and as people) in that it shows we can actually have interesting and constructive interactions which do not necessarily bare any relation to our work selves.

Most Java applications will need some context specific configuration when deploying to a certain environment. This configuration could be username, password and JDBC URL for a specific database configuration or the details of an SMTP server for java mail deployments amongst others.

There are many ways to to provide runtime configurations for Java applications. For web applications, two popular mechanisms are the use JNDI configurations managers and using properties files. Both mechanisms have their limitations and caveats.

When using The Spring Framework, we are presented with a few more options to enable configuring web app projects.

The traditional approach involves using property placeholders which are then munged at runtime with a specific properties file to ensure the placeholders have valid values before executing the application. Another approach is using the newer (Spring 2.0) PropertOverrideConfigurer to override pbean definition properties at application startup. This approach allows the default spring config file to be usuable w/out needing a valid property file as no placeholders exist in the config itself but properties are merely overridden at runtime if need be. This is slightly nicer as it means that a default spring context XML config file will run w/out needing any special property merging. This allows for projects to be run within an IDE (like Eclipse) without having to jump through hoops or run special ant/maven targets to stick the correct properties file in the classpath when wanting to run your app embedded in Eclipse.

Essentially, the default Spring context configuration will work out of the box but can be overridden at runtime with other property file based properties to ensure things run properly at deployment. It’s not that dissimilar to the PropertPlaceholderConfigurer but allows for an easier workflow when wishing to work seamlessly with an IDE.

Not sure if any of this makes sense but there is more info out on the InterWeb:

• PropertyOverrideConfigurer
• configuration-management-with-spring

Finally google have implemented IMAP for GMail. I set it up and it works quite nicely. Your ‘labels’, if you have any, are top level folders in IMAP and the google list of categories (All Mail, Drafts, Sent Mail, Spam, Starred, Trash) are all listed as folders within the [GMail] folder. Nice.

There are however a few things to note especially is using Thunderbird which has some interesting quirks when setting up IMAP accounts. Once you setup a new account (and before you login) its best to make the following changes to ensure smooth operation of your IMAP accoutn at gMail.

Server Settings

• Security Settings
  You need to ensure you use SSL (port 993) when setting up your account connection in Thunderbird (and any other mail client I guess) as thats the default for gmail IMAP. Thunderbird does not allow you to specify this during the wizard account creation (as far as I am aware) but you can access it from the Server settings panel in the account configuration dialog box.
• Server Settings
  Instead of storing deleted messages in the trach, its best to mark them as deleted this allowing gmail to manage the trash for you.

Copies and Folders

• Deleted items
  The nice thing about gmail is that if you send using googles SMTP server, your mail will automatically be saved in your gmail ‘Sent Mail’ category. As such its kind of redundant to get Thunderbird to also store the mail in the Sent Items (either locally or on gmail) so you may like to disable this.
• Drafts and Tempaltes
  Thunderbird by default stores Drafts and Templates (has anyone ever used these?) - to avoid these being created unnecessarily, you can select which folders to use or just set it to or store locally if you wish.

Once these things are setup you should be good to go. It is quite nice to have IMAP access to gmail as it means you can access your IMAPed gmail from other machines (and of course the web interface) and you have a consistent email experience. It seems to work much nicer than their POP access which was always a bit flakey - message status are nicely synchronized and centralised.

g.