In early September I decided I wanted to find a new role in which I could make more of an impact than at my previous jobs. After having spoken to the very enthusiastic CTO of PepperHQ, Andrew Hawkins, about a role as the Senior Software Engineer of the Pepper Platform I decided it would be the perfect place for me to make a mark.
Pepper build a series of iPhone and Android applications for resturants, retail and hospitality — primarily Coffee Shops at the moment — which allow users to pay for products and recieve awards for being a loyal customer.
In my mind the coolest use case of the Pepper Apps is CheckIn/Pay by balance. Imagine you work in Canary Wharf and visit the same Coffee Shop every morning to get your caffeine hit. Without Pepper you would have to go in, order your drink, wait for it to be made and then pay for it using cash or a credit card and, if you wanted to earn loyalty rewards, you would have to carry a flimsy bit of paper with you and get it stamped every morning — assuming you don’t lose it before you’ve collected enough stamps for a drink.
With Pepper you can automatically be “Checked in” to a location as soon as you are within a given distance of the store, perhaps just as you come out of the tube station. You can then make your order from your phone and have it ready for you as you get to the counter. Here’s the cool bit, you can just pick up your coffee and walk off. Checking in to the location earlier made your profile picture show up on the till in the store so the Baristas know that it’s your coffee. The payment is taken from your in app wallet (which can, optionally, be auto-topped up from your credit card, meaning you never have to think about it again). Your loyalty is also managed in-app.
Pepper is really one of those applications that makes the most sense when you see it in action and realise just how much time it would save someone who buys two or three coffees a week.
My role at the company is to be in charge of the pepper platform — all of the backend services, primarily Node.js, that manage the interaction of the applications and point of sales systems.
I’ve been at the company for 3 months now and am really enjoying my time here. It’s pretty neat to build a product people can see the value in, and that is available for use with companies that are household names.
So far in my time at Pepper I’ve added “Pseudo Currency” as a type of loyalty scheme, improved the development process by introducing Continuous Integreation, Linting and a Pull Request merge model using protected branches and started work on a series of improvements to the loyalty reward process.
I plan to keep the blog up-to-date with any developments at the new job.
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.
I started us off by managing to throw together a few slides, and talk for a few minutes, about entering the world of open source for the first time. If you found yourself inspired by that you should check out my blog post on the same subject here.
Once I’d finished my bit and introduced the prizes, generously provided by Microsoft, fellow MSP Merrick Sapsford, took the floor to talk about why developing for charities can be a worthwhile endeavour. Merrick develops applications to support a charity which maintains and flies the last XH558 Vulcan Bomber.
Through this work he has managed to make connections with other aviation companies that are giving him paid work, has managed to get into a list of some of the top grossing apps on the iPhone Store and has even managed to get a few free iPhones in the process. You can check out his app here.
Dr. David Grey — who you may remember from such introductory lectures as… — had the unenviable task of following Rob. Dr. Grey spoke about FoodCloud — a multi-platform augmented reality application the university is developing as part of its research into teaching people about how their food is grown and produced. The app seemed like a really cool idea and the implementation was obviously really smooth! It’s a shame we don’t hear more about research within the department (until recently I was under the impression the department did very little)
To finish things up Simon Grey, without the use of even the 4 slides he was allowed, invited everyone to sign up for Global Game Jam 2014. GGJ is a games development competition over 48 hours, like a double length Three Thing Game, which takes place all across the world, starting at 5pm in each time zone. This year Hull will be hosting the biggest individual event in the UK, in a collaboration between The University of Hull, Hull College and the Grimsby Institute. Simons put a lot of work in so if you’re interested you should sign up here.
Overall the event was a success, a lot of people heard and learnt about a lot of cool stuff. Hopefully people were inspired to do something new, and if not at least there was pizza afterwards… 😉 I hope anyone who nabbed a prize enjoyed what they got. The Microsoft-branded lip balm seemed to be a crowd pleaser at any rate. Hopefully we will take what we learnt from this event and try something similar again next semester!
I’ve found that for projects like this is useful to have a Facebook group as most people at uni check Facebook more often than their Email Inbox
You may recall that earlier this year I started work on a Windows Phone 7 application for HullCompSciBlogs.com, this quickly progressed into a full scale project to make sure that the 3 smartphone operating systems with the highest market share had an application available. So far we already have a Windows Phone 7 app available on the Windows Phone Marketplace and an Android App available on Google Play.
Cameron is still working hard on the iOS application and expects that it will be available through iTunes in the very near future! When we were discussing this we both agreed that the back end system needed a complete revamp.
When I was designing the Windows Phone 7 application I decided on using XML as the data interchange format, mainly because I was getting used to using LINQ which means that an XML based solution is very easy to implement in C# for Windows Phone. I never expected that it would turn into a full scale project and instead expected that it would remain my own personal project. Probably a silly idea in hindsight considering that the Hull CS Blogs very fundamental idea is that of a community. Not only is XML not as well supported out-of-the-box on certain other fruity platforms, its not the best format for the job. In my opinion JSON is much better because it provides the same data in a much smaller file due to its simpler syntax.
The Data Interchange Format is just one niggle with the system, the other is that it is at the moment a bit of a pain to update. I have to manually edit an XML file to create, edit or update information on featured applications and contributors — which is based on my portion of Freeside, so no one else has access rights in order to update it themselves. There’s also currently no system for someone to submit their blog to our system and have it reviewed before becoming publically viewable. So the addition, removal and editing of contributor profiles and blog feeds isn’t exactly the perfect solution at the moment.
The final big issue with the system is that we simply don’t keep enough data on our contributors. The system we are currently proposing will keep the following details for contributors:
A display picture
Their full name
URL’s for both their website and blog RSS feed
Date they joined HCSB
Whereas at the moment we only keep their Name, Twitter username and Blog RSS url. We’ll also keep information on applications developed by students and lecturers who attend the university including:
At this point we need to think about security because we carry a lot of information. It then becomes a bit more of a project that needs to be handled by more than one person, and instead handled by a team of competent computer scientists, and wheres better to source them than from the list of contributors itself? Therefore yesterday I put together the Hull CS Blogs Workgroup consisting of the current mobile application developers, John Van Rij — who set HCSB up initially — and a few people I thought would be helpful in producing a back end.
The basic aims of The HCSBW is to create a community based around Computer Science at the University of Hull based on an open JSON api that can be expanded on and improved by University students for years to come (one of the reasons why the whole system will only be written in language formally taught within the university itself) allowing students to improve their career prospects by getting their story out there for employers to see.
It will all begin properly in freshers week where the team and I will be presenting to the new first year computer scientists in an attempt to get them interested in Hull Comp Sci Blogs and indeed blogging itself. I’ll be sure to write about how our software project and social project of getting people on board works.
Friday night the Hull Computer Science app for Windows Phone 7 finally got certified and accepted onto the marketplace. I say finally but it has to be said that this is the quickest an app of mine has passed through the process — taking just 3 days as opposed to the normal 5.
It’s also the first time I have passed certification first time, which can’t be a bad time. It’s safe to say that the beta I mentioned in my previous blog post definitely helped, as well as me being more stringent about having built in error checking around methods that could fail (for example a network request or file I/O operation).
If you want to download the application you can do so by clicking here.
Again a special thanks to the following people:
John Van Rij for his help with the back end of Hull Comp Sci Blogs.com
Rob Crocombe for general support throughout the process and the icon design
Rob Miles for the photography used in the application
In other exciting news fellow blogger and Hull Computer Scientist, Cameron Wilby, is porting my application to iOS, the operating system which runs both iPhones and iPads. You can see some very early builds of this in the images below:
As you can see its a direct port, with all the same features as the Windows Phone 7 application. I’ll start work on the Android version soon, and then we’ll have total Smartphone coverage across the 3 main platforms! Good stuff!