A lot of people are interested in the alleged “openness” of the Live Departure Boards data discussed in the earlier posts. Right now we have no way to know how many license applications are being submitted and what kind of reception they’re meeting, and indeed whether any licenses are being granted at all.
Thus I’ve setup http://mocko.org.uk/ldb/ldb_licenses.html
If you’ve applied to National Rail Enquiries and want to be counted, let me know and I’ll add you to the list.
On Sunday I wrote this post about how National Rail ordered me to shutdown my free train times application and intend to charge users of their UK “Live Departure Boards” data feed. Responses from readers were positive and I’ve been put in touch with a few groups who’re equally appalled. In the last couple of days I’ve been chasing up the issue.
Here are some examples of the way other railways deal with openness:
Consensus is that train times are best disseminated as widely and openly as possible. The more chance us folks have of finding a train the likelier we are to ride on it. Keeping the details of train times a secret or charging people for non-profitmaking uses is perverse and a retrograde step from when they were supplied freely to the public through an API.
About a year ago I wrote a simple web application to present UK train times in a simple format for mobile phone users.
It’s best described by the instructions. The app was deliberately spartan, really just a list of upcoming trains between a collection of stations you specified in the URL. Data came from a free API which National Rail (a body representing the UK’s train companies) has run for years. Output was presented in the cleanest way possible – people on the move don’t want to be encumbered with advertising or excessive page furniture!
One neat feature was multiple start/end points. Say you live halfway between two stations (I do) and don’t care which station you travel from. The app would look up departures from both, combine and reorder them then produce a unified table of all services you could catch. When I wrote the app none of the official train timetable sites could do this and I don’t believe any can now.
Useful, huh? And all for free. I only wrote it to scratch an itch, so that rather than wading through the cluttered National Rail site I could click a bookmark on my phone and immediately know when the next train into town was. To reiterate – I built this because it was convenient and would be useful to others. Not to make a profit.
…and today National Rail killed it.
Last week I wrote a piece called “Programmers: how to make the sysadmin love you“. The feedback has convinced me it needs a counterpart: something written from the perspective of the systems guy trying to get along with the dev team. Having offended all the programmers of the world (not to mention several Americans who don’t know what a fag packet is) it’s time to do the same for you systems folk.
Be warned this isn’t a piece on (god how I hate that word, it’s recruiter-speak) “how to be a systems guru” – there are souls far more qualified than I to teach the intricacies of UNIX. Also be aware I’m loosely defining ‘systems’ as anyone whose job is primarily to build and maintain the infrastructure upon which runs other people’s code and, hopefully, your organisation depends.
Examples are all confessions of my diverse misadventures. All sins mentioned here have been my own.
Edit: There’s now a counterpart to this entitled “Sysadmins: how to make the programmers love you“.
As a coder working for an organisation you are focused on building something to meet a defined spec. This spec will say things like “background should be blue”, “tabulated interface for user management” and “should not crash”. It may come with a set of images stitched together by a UI designer of how the site/app/thing is expected to look – either crayoned on the back of a fag packet or more likely mocked up in Photoshop so the UI programmers can pull it apart again for the logos and buttons. In a really good spec you’ll find a storyboard defining how it should behave, ready-made content and all the copy up front. We wish.
Things are not always like this. Sometimes in projects where the end result is not entirely defined (“doomed ones”) the spec may be little more than a set of wireframes and a brief hand-wavy description about what it is to do. Hmm.
But so far so good. It is positive that a spec exists at all and that we have some consensus on what we are making. From an engineer’s perspective the better defined and more rigid a spec is the better – the more agreement we can have about the location of a target, the higher our chance of hitting it.
The most common problem with specs is when they’re written by someone without an idea of the things programmers really need to know. They know what they’d like the product to do but overlook “make it robust” or “make it easy to setup on our CentOS 5.5 servers”. To non-engineers these objectives are obscure and here a problem arises – when they go unmentioned it’s easy to fulfill the specification while producing an article that’s a total pain in the butt. A project may be declared a success but still it can be excruciating for people to maintain, compile, release, troubleshoot or in any other way interact with.
Here’s how to avoid it…
Today an old friend emailed me for advice about quitting his day job and going freelance. He’s been in the business for ten years and has great wisdom in the field of C/C++ games programming. I got halfway through writing a response then realised hey, others might benefit too. It’s UK-centric but hackers elsewhere may find it interesting.
My cold, calculating side doesn’t want to post this. We work in a competitive industry and nobody likes to give the opposition a hand – indeed even my mother suggests I fill this essay with bum steers to sabotage everyone else’s career. But today I’m feeling altruistic. And besides, if someone else had told me all this when I first started out the last three years would have been a damn sight easier.
All of this is simply my own opinion and experience. I am neither a lawyer nor a trained accountant and my highest qualification is a ‘B’ in A-level computing. For the love of god don’t actually trust or follow any of my advice. Continue reading
It’s a fortnight since my Android tablet arrived. They’re growing increasingly mainstream – even the UK clothing chain Next (!) have brought out something suspiciously similar… Continue reading
Ecert omcre n a hile I bui a pircw of techjokogy…
Let’s start that again. Reviewing an ePad with itself clearly won’t work.
Every once in a while I buy a piece of technology which will, my friends warn me, be awful. Because I am an idiot I disregard this and base my decision solely upon the pretty eBay pictures and cheerful engrish item description. I wouldn’t buy a car and a house like this but what the hey, it’s £152 and I was drunk and curious. Continue reading
The final part of our mock challenge-documentary, where our eyeoreish self-absorbed hero finally makes it home. Or tries to. It’s a bit like Ulysses 31 but with public transport instead of spaceships.
If you haven’t already seen them read the rest of the series (one, two, three, four) first. Continue reading
Yesterday – battling terrific odds – your hero made it as far north as Inverness. Will his luck hold out or will he suffer a fatal beating with Irn Bru bottles? Read on… Continue reading
