Categories
thetrainline

On-boarding at Trainline

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

Trainline Standalone BFF
Trainline Standalone BFF

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:

Trainline Inline BFF
Trainline Inline BFF

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.

Danny

Categories
Blogging

Computer Science Blogs Beta

Rob and I have both been doing a lot of work on CS Blogs since the last time I blogged about it. Its now in a usable state, and the public is now welcome to sign up and use the service, as long as they are aware there may be some bugs and changes to public interfaces at any time.

The service has been split up into 4 main areas, which will be discussed below:

csblogs.com – The CS Blogs Web App

CSBlogs.com provides the HTML5 website interface to Computer Science Blogs. The website itself is HTML5 and CSS 3 compliant, supports all screen sizes through responsive web design and supports high and low DPI devices through its use of scalable vector graphics for iconography.

Through the web app a user can read all blog posts on the homepage, select a blogger from a list and view their profile — including links to their social media, github and cv — or sign up for the service themselves.

One of the major flaws with the hullcompsciblogs system was that to sign up a user had to email the administrator and be added to a database manually. Updating a profile happened in the same way. CSBlogs.com times to entirely remove that pain point by providing a secure, easy way to get involved. Users are prompted to sign in with a service — either GitHub, WordPress or StackExchange — and then register. This use of OAuth services means that we never know a users password (meaning we can’t lose it) and that we can auto-fill some of their information upon sign in, such as email address and name, saving them precious time.

As with every part of the site a user can sign up, register manage and update their profile entirely from a mobile device.

api.csblogs.com – The CS Blogs Application Programming Interface

Everything that can be viewed and edited on the web application can be viewed and edited from any application which can interact with a RESTful JSON API. The web application itself is actually built onto of the same API functions.

We think making our data and functions available for use outside of our system will allow people to come up with some interesting applications for a multitude of platforms that we couldn’t support on our own. Alex Pringle has already started writing an Android App.

docs.csblogs.com – The CS Blogs Documentation Website

docs.csblogs.com is the source of information for all users, from application developers consuming the API to potential web app and feed aggregator developers. Alongside pages of documentation on functions and developer workflows there are live API docs and support forums.

In the screenshot below you can see a screenshot of a docs.csblogs.com page which shows a developer the expected outcome of an API call and actually allows them to test it, in a similar way to the Facebook graph explorer, live on the documentation page.

CS Blogs API Documentation
CS Blogs API Documentation

Thanks to readme.io for providing our documentation website for free due to us being an open source project they are interested in!

The CS Blogs Feed Aggregator

The feed aggregator is a node.js application which, every five minutes, requests the RSS/ATOM feed of each blogger and adds any new blogs to the CSBlogs database.

The job is triggered using a Microsoft Azure WebJob, however it is written so that it could also be triggered by a standard UNIX chronjob.

Whilst much of the actual RSS/ATOM parsing is provided by libraries it has been interesting to see inconsistencies between different platforms handling of syndication feeds. Some give you links to images used in blog posts, some don’t, some give you “Read more here” links, some don’t. A reasonable amount of code was written to ensure that all blog posts appear the same to end-users, no matter their original source.

Try it!

I welcome anyone who wants to to try to service now at http://csblogs.com. We would also love any help, whether that be submitting bugs via GitHub issues or writing code over at our public repository.

Danny

Categories
University

Mobile Devices and Applications Coursework Result – 100%

On Monday 12th May our Mobile Devices and Applications coursework was due in at 9am and I had to demonstrate mine at 1:30pm, which was a very quick turn-around! At the demonstration I received my grade of 100%, which I was of course very happy with.

The coursework this year was to develop an Android Application called AMULET –  “An m-health (mobile health) tool for the valid self-assessment of alcohol-induced impairment” for a real-world research project in the University of Hull’s Social Sciences Department. In this post I will briefly outline the functions of the application.

User Management

 

All users of the service had to sign up to use the AMULET service, which keeps track of all their data. They could do this inside the application itself, and information could be synced with however many devices they decide to use. The interaction with the AMULET web service is via a RESTful JSON API. The user could also manage their account from within the application including deleting it and changing its password.

The Tasks

 

The main point of the application was for users to be able to self-test various attributes and skills whilst sober, as a calibration, and then compare this score with their current score at the time of intoxication. Users were asked to input details of their current drinking session before taking a test, and shown results afterward.

The Inspection Task measures the users speed of information intake. It does this by showing the user 8 sheep and changing one of them to be a wolf for a small period of time — 100ms — the wolf then changes back to being a sheep and the user has to select the correct sheep. If the user selects the correct sheep then they complete the same task again, this time with less time — it goes down in 10ms increments. When they eventually fail this is their recorded score. A sober person should manage a time around 60ms.

The Sequence Task measures the users ability to locate information. It does this by asking them to tap every number, in order, from highest to lowest. The users score is the number of seconds it takes for the user to complete the task.

Finally, the Pilot Task measures the users ability to split their attention between multiple objects. In this task the user has to drag around the white square and keep it away from the red enemy squares. The recorded score is the amount of time in seconds the user avoids the enemies.

In my implementation each task had 3 different difficulty settings; easy, medium and hard.

In the inspection task on easy mode the sheep would change to a wolf (which was both a different shape and colour), on medium mode the sheep would change to a purple sheep, (which was the same shape but a different colour) and on hard mode the sheep colour would change only slightly.

In the sequence task easy mode makes the user count to 9, medium mode makes the user count to 16 and hard mode makes the user count to 28.

In the pilot task the enemies move faster at the higher difficulty settings, and believe me it gets rather tough. Different calibration scores and results are stored for each setting, meaning users can’t calibrate on hard and then compare that score to an easy result when drunk — because that would be cheating!

 

Before each task the user was shown the task brief, which allowed them to access instructions for the particular task they were about to start. At the end they were shown the task finished screen, which compared their results to a calibration or prompted them to make one. At any time the user could go to the home screen and tap “task history” to see their results from the past.

Drink Diary & Unit Calculator

 

As well as keeping track of the users abilities at times of sobriety and intoxication the application also kept track of the users drinking habits through a “drink diary”. This diary allowed users to enter information about a particular brand of drink including the brand name, alcoholic % and portion size, and then store how many they had drank along with a timestamp.

A unit calculator was also included for the users convince. The user could input the number of drinks they had consumed, the class of drink (e.g. Red Wine, White Wine, Average Strength Beer), and the portion size and be given a reasonable estimate of the number of units consumed. This functionality was also called when the user input drinks for the drink diary, to make data entry easier.

RESTful Server Interaction

One of the most interesting parts of the coursework was ensuring we stuck to the standard required by our lecturers server to send and receive data. This server allowed for research to take place on the information submitted by users, backed the data up and allowed users to carry information from one device to another.

All drink diary entries and task results were synced.

User Interface

Though the design of the application was very “windows phone-eseque” it was somewhat unique and supported many of the android features users have become familiar with; such as landscape and portrait support, different screen resolution support (from 3 inch phones to 12″ tablets and above) and notifications for long running processes such as data upload.

Thoughts on Developing for Android

I thought this coursework was a really nice way to pick up the programming language Java which, until now, I hadn’t needed to use. It’s similar to C# in a lot of ways with a few of its own idiosyncrasies, but a lot of the industry (and The University of York) use it extensively, so its a good thing to have learnt.

It was also interesting to have developed an application which worked across mobile phones, from small 3 inch screen devices, to much larger 12 inch tablets. This made me really think about the best way to develop the user interface, and I think I found a good compromise — it was certainly at least usable on all of these devices.

The main issue a lot of people had, including myself, wasn’t with Android itself, or indeed Java but rather the Eclipse IDE which most android developers use when writing applications. We all know that Visual Studio is in a class of its own, but it was a bit of a culture shock to change to an IDE that didn’t support debugging in quite the same way for example. Having said this I think this ability to switch between development environments is a good skill to have picked up. The other issue was just how slow the default andoird emulator is on a non-intel PC — but this can be solved through the use of Genymotion.

I will be getting my results for the module as a whole, along with my final university grade itself on the 2nd of July. I will of course update the blog then!

Danny