Something just clicked – To “new” or not to “new”

I finally caught up a bit on Miško Hevery’s blog posts. (Miško is one of the main developers behind Testability Explorer that we use to help guide our refactoring internally.)

This post (To “new” or not to “new”…) finally helped me figure out how to effectively use a Dependency Injection tool. As an important corollary, it helped cement in my mind the proper lines between a Value Object and a Service-y sort of class.

I hope you all enjoy it too.

YUI AJAX tries to get along, but sometimes that’s a bad thing. In particular when it comes to € (Euro) symbols.

At youDevise, we currently have our TIM pages encoded to the charset of ‘ISO-8859-15’ as opposed to the largely adopted and recommended ‘UTF-8’. This has allowed us to keep certain parts of our application compatible with some older systems still in use at our clients. Despite staying old-school in our page encoding, our systems have been working just fine with submitting extended charset characters such as the Euro symbol.

More recently however, we’ve introduced some new functionality which we’ve enabled using the excellent Yahoo User Interface javascript library, in particular we’ve been using it for AJAX calls.

Unfortunately, over AJAX the rules are a bit different, and those extended characters that played so well over a normal POST method were becoming garbled over an AJAX submit. After a bit of digging I determined that what was going on was that the YUI Connection Manager was simply being too nice for our own good and adopting the same ISO-8859-15 encoding for its submissions to the server that our normal pages use.

I’m afraid the normally quite excellent documentation on the YUI let me down a bit this time, but I was able to find a simple fix to make our AJAX calls use the UTF-8 encoding. Using the Connection Manager’s initHeader method I can set the encoding to UTF-8, avoiding the garbling!

YAHOO.util.Connect.initHeader("Content-Type","application/x-www-form-urlencoded; charset=UTF-8");

London Python Meetup

Ryan and I went to the London Python Meetup last week. In addition to a talk by the creator of Pinax, there were also a series of lightning talks. I’ve never been to an event where they did this before, and I find the format to be really wonderful. Basically, each person is given a short, set amount of time (usually five minutes) in which to give their talk.

The effect of this is that the person has to really distill down what they are going to talk about, which can give it a lot of focus. Also, the listener doesn’t have the same expectations they might have from a longer presentation (at least I didn’t), which (presumably) takes off some of the pressure from the presenter. Finally, you get to see a lot of different things with no danger of becoming bored, because even if you weren’t interested in something, a new thing is just a few minutes away. Shiny!

Continuous Integration – a new hope?

To say we’ve customised CruiseControl for our continuous integration process is an understatement. And to say that keeping our CruiseControl scheme running smoothly is a tiring endeavor is a major understatement. To be fair, CC enabled us to grow as we needed, so we kept tweaking and adding new stuff. However, as with any software development process, we’ve reached a point where it is healthy to look at the broad picture and refactor our continuous integration process.

CruiseControl is a 1st generation continuous integration tool. It is not bad, but there is newer stuff around. So, after a lunch with the build doctor I’ve started to investigate some 2nd generation tools, mainly TeamCity and Hudson, in search for the one that suits us.

We certainly customised CC quite a bit in order to get there, so our needs might be tricky to satisfy. But our hope is that next generation tools could provide a better/easier way of replacing our customisations with something more maintainable.

Our setup

We have 3 main projects, all having similar requirements from the continuous integration process. Our build pipeline consists of a ‘master’ build (executing unit tests, code checks and test coverage) and several ‘functional test’ builds (browser tests on IE6, IE7 and Firefox, REST and calculation tests), where the functional tests only deploy and execute on successful master builds.

Both the master and functional test builds are split into master and slaves machines (e.g. the browser tests on IE6 run concurrently on three slave machines). There is a lot of custom communication and synchronization going on to ensure that builds are triggered at appropriate times and the master and slave are on the same page, and it can be quite a pain to maintain.

TeamCity (

TeamCity is a commercial product with some very interesting features: you can have pre-tested commits and it uses a ‘build grid‘ to run the tests.

The pre-tested commits means, instead of commiting directly to the source control the code goes first to the TeamCity server, which runs a pre-commit test suite. If the tests pass the code is commited to the source control, but if they fail the developer is notified of the failure and the offending code is prevented from reaching the repository. The build grid idea also seems like a natural way of splitting our many builds into specific agents without requiring custom scripting. For a comparison between TeamCity and CruiseControl, look at:

TeamCity definetly seems cool, but there are downsides. It is quite pricy and I am unsure how customisable it is. Don’t get me wrong, we want to move away from our super-custom scripts. But what happens when something goes terribly wrong, or we want to add an unsupported code checker? It may be very easy to do, but I need to do a more in-depth investigation.

Hudson (

Hudson is an Open Source project, much like CruiseControl. However, it does have some rather nice features , such as support for distributing builds across machines and mechanisms for pinpointing when a given unit test started to fail. It does also have an extensive list of plugins, and some are immediately useful for us, which could make a switch easier.

So, if it is similar to CC, why make the switch? To me, the best reason would be to more naturally support the distribution of builds (and the whole master/slaves thing). This seems like one of our maintenance bottlenecks, and if the promise of easy configuration is true it could make our build pipeline saner. This could also mean we could have an easier time scaling our build infrastructure. But, as with TeamCity, further investigation is still required.