A couple of years ago I read the excellent book Ship It, published by The Pragmatic Bookshelf. One of the items which stuck in my mind at the time was the suggestion of using lava lamps connected to an X10 module to monitor the status of your CI system. “When I’ve got my own company”, I thought, “that’s the first thing I’m going to do”.
Move forward a year or so. We’ve started Open Planet Software and are ready for the lava lamps. So where to start?
The obvious place to start looking was Mike Clark’s blog. The suggestion here was to use a FireCracker kit via a USB serial adapter, but this all seemed a little untidy. I was also a little scared to click on anything on the X10.com website. What if my wife caught me looking at it...?
The second stop was Mike Swanson’s blog. He suggests the Ambient Orb™ which, to be honest, does look really neat. However, the price tag of $150 plus another $20 per quarter to be able to control it was a little steep for a start-up on a tight budget. All we really wanted was the ability to switch a light on and off via a computer; wireless, web-based control, while pretty cool, was also overkill. In fact, really all that we needed was a relay switch which could be controlled via the USB port.
After a bit of searching I settled on a 4 channel relay switch, the USB4PRSMx, produced by EasyDAQ. The nice thing about this controller was that it came with a it’s own protective Perspex cover. All in the control cost around £53 ($75). A little DIY saw the relay neatly installed in a self contained box.
I’d never had cause to talk directly to a USB port before so I was pleased to discover that communicating with the device was remarkably simple. After downloading and installing the necessary drivers the relay appeared in the /dev folder (in our case /dev/cu.usbserial-0000105D) and control was simply a case of streaming the appropriate command.
The next step was to hook-up the lights. For this we splashed out on a couple of FADO table lamps from Ikea and two light bulbs; one red and one green. Once I had these connected to the box I could switch between a red and green light by typing commands into a terminal window. I wasted a lot of time just doing this...
The final step in the process was to control the lights based on the result of our automated builds. To do this I modified Erik Doernenburg’s CCMenu. Actually, I implemented a basic plug-in architecture. One day I’ll get round to tidying this up and submitting it...
We mostly use CruiseControl.rb for our builds. However, using CCMenu means that the same method could be used to monitor builds run with CruiseControl.NET (although the machine with CCMenu will need to be a Mac).
So the question is: was it all worth it in the end? Absolutely. The project started out as a way to add a little fun into monitoring our builds, but it has turned into an invaluable tool. The globes sit in a prominent position within the office and every now and then (probably more often than we’d care to admit) there is a loud intake of breath as someone notices that the build has broken. Because the status of their code is on such public display our developers will try to fix the code then and there, rather than being tempted to put it off until later. And as talking point it’s great being able to explain to customers how we use them to help ensure the quality of code we’re developing for them...
A Good Day!
A Bad Day!
I’ve glossed over a lot of the details here, but if you are reading this, thinking of doing something similar and would like some more details please feel free to get in touch.
