On January 23rd I graduated with an MSc in Advanced Computer Science from The University of York. It was a nice occasion to get together and be merry with the family, and of course for some photos in my cap and gown — this time they were grey and blue.
My parents took my degree home with them and hung it up next to my undergraduate degree and departmental award. I think they look nice together.
For some more nice pictures you can check out my dads blog post about it.
It seems like a lifetime ago, but the first HackTrain event was actually only 9 months ago — It probably feels so long ago to me as so much has change in the interim, including me getting a job as a result of the first event.
When an opportunity came up to represent Trainline at the second HackTrain I jumped at it as I thought it would be nice to go full circle in a sense, going back with a job in the industry, and simply because I loved the friendly competitive atmosphere of the hackathon.
HackTrain 2.0 was a much larger event than the original, with 3 trains of Hackers rather than 1. I was assigned to the Big Data Train, in which participants would focus on using the APIs made available by the rail industry,
I originally thought I would be mentoring teams and helping them get set up with any RailTech APIs I knew about, however I actually ended up participating in a team consisting of myself, two Computer Science students and an engineer from french national rail operator SNCF. We worked together to build a web application called TrainGuard.
TrainGuards tagline is Calmer, Drier journeys. This is because the aim of the application, which is written in Node.js, is to allow customers to make more informed choices about their journeys. When using travel booking services that are currently available you can see what time you’ll depart from your origin and what time you’re expected to get to your destination, but nothing is said about what will happen in between.
When we were conducting market research on our South West Trains service to Bournemouth a lot of people told us they disliked being on trains which were full of football fans, or loud people coming out from a gig. The small sample we took rated those experiences as being as bad or worse than being on a delayed train, and that to avoid such circumstances they would be willing to reschedule their booking. Weather factored into peoples travel decisions less, but was still important.
On match days, or other particularly busy periods of rail travel the Train Operating Companies (TOCs) would much rather that their load of passengers was more evenly distributed throughout the days services. This is because each minute a train is delayed on the British Rail Network the train operating company gets fined, in some cases hundreds or thousands of pounds per minute — depending on where the tardiness occurs and how many other train services are affected by it.
The idea therefore occurred to me that we could aid both the traveller and the TOCs by allowing passengers who wish to avoid such events a chance to reschedule their journey and change their tickets. Initially we started out with the idea of making this an API that ticket distributors, such as Trainline, could tap into — however, we realised that at a hackathon client facing applications are more likely to do well.
As a team we implemented a subsystem that could connect to the SilverRail travel planning API, which had been specially opened up to the public for HackTrain 2.0. This subsystem would accept a journey plan in the form of an origin station code, a destination station code and a departure time and return a list of stations comprising the complete route. Using this information we then checked for events within a given distance of each station en route on Eventful, which is itself an aggregation of many other event websites — using specific filters we could find only the events that we felt could cause disruption to the end user.
In a perfect world this information would be shown to the user at or before the time of booking, or if circumstances changed their could be alerted via a notification on their phone — however, for our prototype they would have to visit a webpage hosted by us. The webpage was written using semantic HTML5 and styled using CSS3, it was designed to be responsive and as you can see above it works well on both desktop and mobile, mobile being especially important of course as the act of travelling means you’re most likely to be on a mobile rather than a desktop when you check this page.
When designing the page I wanted to make it beautiful to look at, but also really easy to grok what the page was trying to tell you — therefore I went with a design that included Bootstrap Jumbotrons with parallax scrolling high quality image backgrounds.
As with all Hackathons the most nerve-racking, but equally exciting, part of the weekend was the pitching at the end. We felt we had a good product that was mutually beneficial for both the industry and its customers but we had to convince 2 panels of judges of that. As I mentioned before, the event this time round took place on 3 different trains, so in order to get to the final we had to have one of the top 3 pitches out of the 10 teams on our train.
Excitingly we did make it to the final, in which we pitched to judges from the rail industry. There were judges from SilverRail, Trainline, Great Western Trains and The Ministry of Transport. Unfortunately we didn’t come in the top 3 teams at then end, but we had a lot of fun over the weekend and were proud that we got to the final and were given an opportunity to tell the industry how we felt they could deliver Smarter Journeys — which is something Trainline is currently focused on.
Thanks to everyone at HackPartners who made the event possible, and all of the sponsors of the event for making it so fun and giving 120 of the best hackers a chance to develop much needed improvements for the Rail industry.
Since September, Charlotte and I have lived about a minutes walk from the UK Computer Museum (which also seems to go by the name Centre for Computing History), but we’d never actually gone inside.
Today after my flying lesson we went to have a quick look. Whilst it made me feel old to see things I remember from childhood in a museum, such as a PlayStation; a Dreamcast and an Acorn PC, I really enjoyed the hour or so we spent there.
There were a few exhibits, including: the history of ARM, military computers and the history of Sinclair. The best thing about the museum was that you were encouraged to touch, and play with, any machine that was turned on. I hadn’t played on a BBC Micro before, but had heard a lot about them from lecturers and other techies from the era they were made. It was fun to figure out the classic GOTO 10 infinite loop, which you can see in the image above I put to good use informing the public of Charlotte’s lameness.
One of the nice things the Museum has is a classroom to get children interested in Computing. Its the kind of thing I know I would have enjoyed as a kid.
I recommend anyone who reads this blog to go to the museum if you’re in the Cambridge area, you’d probably enjoy it.
Trains are, in many respects, wonderful machines. They’re simultaneously both the most romantic form of travel and the most grueling way to get to work every morning. One thing trains are not however, is up-to-date with modern technology.
Whilst you can follow the course, in real time, of a plane soaring at 36,000 feet above the ground all the way from San Francisco to London you may be surprised that Train Operating Companies (TOCs) lack the ability to pinpoint the locations of their trains between stations. In other words, they may know that your train is between Cambridge and Foxton but they wont know exactly where.
Not knowing exactly where Trains are doesn’t cause any satefy issues — Block Signalling has been used to safely manage the passage of trains by identifying which “block” of track they were in, without an exact location, since the 1850s — however, it does mean that the decisions that control rooms make are being made on educated guesses of a trains exact position at any given time.
Control rooms are the brain room of the modern railway and make decisions when things go wrong. If you’ve ever been told a train cannot run due to a “lack of train crew” its unlikely the driver was off sick and instead much more likely that a delay on a train they were driving earlier has cascaded down to your service and they simply never arrived at your station to drive the train. Control rooms try to avoid this — and many other issues.
Our earlier examples of Cambridge and Foxton aren’t exactly a million miles apart, and on a normal service you would expect a train to travel between them in around 5 minutes — but as the railway gets more and more congested making real-time decisions based on a time resolution of minutes will result in more and more decisions resulting in delays and cancelations.
After having learnt about this situation, whilst onboard HackTrain 2.0, I decided to have a go at resolving it in my own time.
One constraint of working with technology for use on trains is that, for all intents and purposes, you cannot add hardware to trains. The Rail Industry in the UK is, thankfully, obsessed with safety and that means that anything added to a train has to go through rigorous Health & Safety checks. This means it can take months, or years, for anything to be installed trackside or in a vehicle.
Whilst staff who work for South West Trains (who explained the situation to HackTrain competitors) are all issued with BlackBerry devices, some companies have started issueing their Guards and Conductors with relatively modern Android devices, some of which even act as ticket printing machine for on-the-train ticket purchases.
Armed with this knowledge I decided to try and validate my idea that a train could be tracked using just the smartphone device a member of train crew is already carrying. As I didn’t know if the idea would work in reality I set about making a working prototype with the minimum possible effort.
My acceptance criteria was pretty simple: Be able to view in real time the position of a train from Cambridge to Kings Cross. This wasn’t exactly the most measurable criteria (what does “real time” mean, for example?) but it gave me something to work towards.
I walked down a few streets with my prototype client open in the Safari Browser on my iPhone and it appeared to report its location to the server as intended. So, on one of my final commutes into work before the holiday season I tested the system on a moving train on a route that includes tunnels, large areas of poor phone signal and central London; and all the different challenges these environments bring.I was pleasently suprised with the results, shown above , despite a few anomalies.
Due to the fact I was using the `watchLocation()` function the train didn’t report its location in even time periods, as it would if you were polling the location, but rather only when the trains position changed significantly. Despite this fact, the period between the train attemting to send its location whilst on the move was never more than around 10 seconds.
I say attempted because, as expected, there were some issues with mobile coverage. I had expected to have issues in tunnels, but actually only the final tunnel before Kings Cross (which goes under the Grand Union Canal) caused issues. Lack of signal otherwised occured in a few blackspots in rural Cambridgeshire. This issue could be mitigated by employing a system such as that provided by Nomad Digital which provides an internet connection to a train using multiple sim cards connected to multiple network providers.
Another issue you can see in the above screenshot is that my train appears to have left the tracks a few times. I can assure you that this didn’t actually happen, but appears to have done so due to a combination of some inaccurate GPS readings and some failed data transfer caused by the aforementioned network connectivity problems. These errors could be mitigated using a host of techniques: comparing GPS position to known track locations, buffering changes in location that seem too great and only accepting them as true if subsequent location changes appear to be in the same area.
This was a pretty interesting project to work on. It gave me an oppertunity to develop a simple solution to a real life problem in a short period of time and learn about the awesome Socket.io library. I was happy to see it work so well, and to be wrong about tunnels. I look forward to making some of the improvements I’ve mentioned in this post and making the UI prettier and data storage a little bit more resilient.
A few weeks ago I was lucky enought to be part of the team that tried, and hopefully succeeded, to entice more developers to come and work with us at Trainline at the Silicon Milkroundabout tech recruitment event.
I really enjoy talking to people about technology and it was especially nice to talk to people who were genuinly interested in what we do at Trainline. Some, who were also recent graduates were especially interested in how I got my job and what I do in my day-to-day work — I reccomended that a lot of these people try events like HackTrain.
Like all cool tech companies we had merch to give out to people. My particular favourite was a Trainline ticket holder, which replaces my standard National Rail one and looks like it will be much easier to find due to its nice bright colours!
As well as nabbing some of the march, I also managed to get my hands on a Trainline Staff Polo, as beautifully modelled below:
I’m now entering the sixth week of my time at Trainline. It’s been quite the experience, due to it being my first full-time job and it being a time of significant changes at Trainline in terms of technology, branding and even an expansion into the European rail market.
It’s been great to be in a team of people who know so much about Software Engineering and the systems in use at Trainline, and whom are so willing to pass that knowledge on. I’ve also been blessed with some really cool projects to work on at the start of my trainline career. The first thing I was tasked with doing was replacing the standalone Best Fare Finder application, with deep links to an improved Best Fare Finder experience which was already built in to the main ticket purchasing flow.
The Best Fare Finder allows you to find the cheapest tickets avaliable between two stations if you’re willing to be flexible on dates and times of travel
The Standalone BFF, pictured above, wasn’t responsive; didn’t look like the the newly rebranded trainline homepage and purchase funnel and required additional maintenence. Removing it and using the best fare functionality baked into the main purchase flow improved the experience for users and reduced the costs, both financial and of technical debt, to the company. The inline best fare finder which replaces it can be seen below:
The pictures of popular locations you can see in the screenshot of the homepage, or Roundals as I’ve started calling them (inspired by the name of the famous Tube logo which is a similar shape), had to be updated as part of this work. This was quite exciting as it meant that within a week of my first job I had pushed a change, albeit relatively minor, to the home page of a website with millions of visitors a month. The deep linking I developed for this inline BFF is now also used in Trainline emails to customers.
As part of doing this work I discovered that some parts of the Best Fare Finder backend were a bit difficult to work with and that access to useful information could be greatly simplified leading to a reduction in the number of places in which static data was manually updated by humans. I proposed that a RESTful API was developed with some easy to understand endpoints that delivered a JSON response.
My development manager and product manager were supportive of the idea and therefore I started working on a set of requirements and use-cases for the product, which I simply called BFF API (Best Fare Finder Application Programming Interface). The resulting system is written in Node.js 4 — making great use of all the new features of ES6 such as block scoping, destructuring and arrow functions — Hapi.js and an assortment of the libraries avaiable from npm.
It is unlikely that this system will be made user facing itself, but it may contribute to some of the things a user can see from the backend.
I’ve learned rather a lot in the last few weeks: including the business and technological processes involved in developing enterprise quality software, how to navigate through and modify/maintain legacy systems and some more about the Node.js ecosystem. Expect a blog post in the new few weeks about how I’ve changed the way I develop Node.js code in order to aid correctness and the ability to tests things.
Whilst some parts of the transition from academia to Real Life™ have been difficult to get used to (what is waking up at 7am and commuting?!) overall I’m enjoying the new experience and feel like I’m learning as much or more than I was at university and being paid to do so — the best of both worlds!
I will keep the blog up-to-date with my progress at Trainline.