Having written a CIF parser, TSDBExplorer, I found that although the parsing code was correct (thanks, Test Driven Development!), it’s hideously slow.
Using exactly the same set of tests and test data, I’m refactoring a chunk of the code. Whilst it’s quite demotivating to find the majority of your unit tests suddenly failing, being able to review each one and make it pass is absolutely great. I’ve definitely found the right way to code.
To anyone who isn’t a full-time programmer and who “just wants to get on and write code” – how many times have you suffered because you’ve “just got on with it” rather than writing tests and making them pass? Give Test Driven Development a try…

[Test|Behaviour] Driven Development

Whichever option you choose, I am a convert.
Previous projects of mine were met with a “*sigh* I suppose I need to write some tests, but I want to get on with the code”. TSDB Explorer is the first codebase I’ve written where the majority of code existed only after the unit tests. I have to say, it’s many times more robust, and I’m going to continue the trend in TubeHorus.
Part of me is delighted too at rcov and its “Here’s how much of your code is covered by tests”. There’s a definite warm feeling to be had when you’ve covered nearly all your code with tests, although as @bobtfish said – “That just shows you that your bugs are within your unit tests”. But I can always write more of them to make sure I don’t re-introduce bugs.

Making a bad situation worse

Last night’s attempted cable theft at Woking wasn’t a pleasant experience for the thousands of people trying to get home. An earlier signalling problem at Clapham Junction disrupted my journey out to Putney slightly, but it was utter chaos later.
My journey back home would have been a nightmare had it not been for the exceedingly convenient London Overground service from Clapham to Stratford, the only criticism of which I can make is that the 2015 departure from Clapham gets to Gospel Oak at the same time at the 2050 service to Barking departs. A minor problem though.
Some hours later after I’d returned home and had dinner, I had a friend of mine call me up for advice on which trains to get back to Winchester – he’d been trying to get back from Waterloo, was advised to travel via Reading, and thanks to one of my Open Source projects, TSDB Explorer, I could tell him which trains to get and from where – but not if they were running or where they were.
Hearing the story in the news this morning, my jaw dropped when I heard that some passengers forced open train doors and made a run for it down the track. That’s an exceedingly bad thing to do, for a number of reasons:

  • First and foremost, there’s the danger of electrocution from the conductor rail – Module DC of the Rule Book sets out the details for the technically minded. Suffice it to say that if you stepped on, or slipped over on to the conductor rail, you’re not coming out of it unscathed.
  • Second, once the driver of a train receives an alert on the train’s management system that the emergency egress handle has been used on his train, he’s going to call the electrical control room and/or signaller immediately and get the power switched off, or ‘isolated’. This can only be done in an emergency for a large area, because in an emergency, you don’t have time to work out which parts of the supply to turn off (and sometimes you just don’t have the option – imagine trying to switch off just one socket on a ring main from the consumer unit in your house). The lack of power and knowledge that there are people on the track further screws up any attempt by Network Rail and South West Trains to get trains moving, however slowly. Even if the attempted cable theft affected two out of four lines, there are still procedures that can be undertaken to move trains without the aid of normal signalling systems – they’re slow, but they exist, and they are safe. So, the result of people ‘escaping’ from trains through frustration? More trains not moving for a long time because there’s no power to any of them. Oh, and without power, the air conditioning on trains won’t work. South West Trains’ fleet doesn’t have windows that can be opened – there’s no point with air-conditioning. Everyone else gets warm and agitated.
  • Finally, trespassing on the track is just that – trespass.

So, the moral of the story? However frustrated you are, don’t take matters in to your own hands and make a difficult but manageable situation in to a potentially serious incident involving death.

Open Source, Open Data

I’ve had a rethink about source code hosting. CVS is dead in the water, Subversion requires online connectivity, and I’m starting to use git with vigour. Hey, offline commits are perfect for coding on the train! (As an aside, I gave up trying to get WiFi access on a train to Leicester on Saturday, and didn’t even bother trying on Sunday coming back). Github is where it’s at – although despite today being World IPv6 Day, they don’t appear to have access over IPv6 natively.
The code for TSDB Explorer is up and out there and being actively worked on, as is TubeHorus, which is in a lesser working state. I anticipate getting around to putting TransportHacker‘s code on Github in the next week or so.
On another note, I’d like to thank the people at Network Rail who’ve been so helpful in talking to me about some of the data sets they hold. Whilst I’m not in a position to let the cat out of the bag yet, I am pretty excited about what’s coming in the next few weeks. Time to investigate Amazon EC2 I think… this may take some horsepower.

A fellow Transport Hacker

I met up with Louise Crow after work yesterday – a great opportunity to geek at each other about NaPTAN and CIF data, amongst other things.
She reminded me about GitHub – and so I took a few minutes this morning to push TSDB Explorer up there. If you want to have a look around the code, it’s all here. I’ll try to come up with some sample data in the next week or two, and maybe a working demo if I get time.