10 Jun 2016, 16:45 Projects

Helping a blind athlete run four marathons, without a guide

Our mission in the Garage is to do innovative and exciting projects, so we were thrilled to help Simon Wheatcroft in his bid to be the first blind runner to complete the 4 Deserts Namibia race solo. We wrote a native iOS app for Simon which is pre-loaded with routes (such as Simon’s training route near his house, the Boston Marathon, and the 4 deserts stages). If Simon goes more than ten metres off course, the app beeps to let him know that he needs to veer left or right. The app does a low beep for left, and a higher beep for right, and a bit like a car reversing sensor, the more frantic the beeping, the further off course Simon is.

Simon Wheatcroft looking determined

One of the underpinnings of the Bluemix Garage Method is that you don’t know everything at the beginning of a project. The aim of development is to reduce uncertainty about the business problem, while minimising risk. We had a concrete example of “incomplete knowledge” with Simon’s app, because it turns out the pre-plotted race route didn’t end up being the actual race route. For example, one part of the run is along a beach, and the course was about 100 metres to the right of our coordinates. Because of how we’d designed the app, Simon was able to cope with the change - he just had to keep to a path which kept the app beeping at a “medium frantic” level. It can’t have been very relaxing, but it worked. We also made assumptions that the desert would be pretty flat and obstacle-free, so when we prioritised our user stories, things like “obstacle detection” were at the bottom of the backlog. It turns out that parts of the desert are rocky. Because he couldn’t see what kind of surface he was putting his feet on, Simon hurt his feet and legs trying to race over the rock fields - he was badly enough injured that he had to withdraw from the race after running only (!) three and three quarter marathons.

Another aspect of the Garage method is responding quickly to change, both in terms of our planning, and also our implementation. Normally we bake devops into our development so that it’s a matter of minutes to get updates out to users. In the area of the Namib desert where Simon was running, there was no data coverage, so once he landed there, we couldn’t make any more improvements to the app. In other words, there’s no devops in the desert.

The most important part of the Garage method is the user. We were lucky that we were able to work closely with Simon through the whole project, from the ideas stage to inception to after the event. We hope our applications delight users, but with Simon we knew it did; all of us in the Garage were moved when Simon came back and told us how he’d found himself in tears halfway through the first leg of the race, from exhilaration at having achieved his dream of racing solo.

Further reading

A lot has been written about Simon and the app we wrote for him. I can’t even link to a fraction of it, but here are some of my favourites:

24 Apr 2015, 11:45 Projects IBM Design Thinking

Connecting low power Things to Bluemix

We have been working with IBM Research Zurich on integrating their Long-Range Signaling and Control (LRSC) platform into Bluemix. Based on the LoRa technology, LRSC allows very low power devices to communicate wirelessly over a range of several miles.

Sensors connect to a physical gateway device, which bridges between the LoRa wireless technology and standard IP networking. The gateway then connects to a centralised LRSC server, which manages the network. The server connects to our bridge, which then passes messages to the IBM Internet of Things Foundation (IoTF) service on Bluemix.

Messages appearing in IoTF from LRSC

IoTF makes it easy to access the sensor data from custom applications running on Bluemix. It provides an MQTT interface that allows a developer to subscribe to updates from any LRSC device, as well as to publish control messages down to the end device.

The Lamplighter demo application

To help us demonstrate the bridge, we have created a mobile web application that allows a street light installer to easily test a new street light in the field.

We used IBM’s Design Thinking process to create the following Minimum Viable Product:

As a Device Installer, I can test the end-to-end bi-directional operation of a newly installed device within a minute of installing it and without leaving its location.

We worked with our designers through a series of storyboards and low fidelity prototypes, which led to the following design for the user interface:

The Lamplighter User Interface

The sidebar is dynamically updated with any new devices that connect to LRSC. The device installer can then select the new device, send a test command to the device, and finally confirm its location on the map.

The application is deployed on Bluemix using the Ionic Framework for the front end, and Express.js running in the nodejs buildpack for the back end.

We use the IMST SK-iM880A kit for our test devices and the Kerlink LoRa IoT Station for our gateway.

Using the Bridge

The bridge code is available as a sample on github.

20 Mar 2015, 16:45 XP Projects

Garden Bridge

In 2014 IBM UKI General Manager David Stokes made the offer to the Garden Bridge Trust for IBM to do the development and initial hosting of the gardenbridge.london website. The London Bluemix Garage has set up the various apps that are behind the website on IBM Bluemix and has developed the integration with the payment gateway run by Elavon for processing donations.

The gardenbridge.london website is made up of three apps:

1. Donate app

It handles all the communication with the payment gateway, triggers the correct e-mails to be sent based on the donation journey that a visitor takes and gracefully handles payment gateway unavailability.

This was developed by the London Bluemix Garage using eXtreme Programming practices including pairing, test-driven development, continuous delivery and blue-green deployment. All Garden Bridge apps are continuously delivered using blue-green deployment.

From the Bluemix service catalog, we’ve chosen SendGrid for all outgoing e-mails. Load Impact proved highly efficient and nice to work with when load testing all Garden Bridge apps. Monitoring & Analytics gives us sufficient insight into historical app availability and response timings.

As for the code stack, we’ve chosen Mocha, Chai & Sinon.js for the test suite, Express for the web server and couple of Node.js modules for integrating with third parties.

2. CMS app

It provides a UI for Garden Bridge Trust employees running the website to make content changes & maintain a newsletter without needing to involve an IT person. This piece, and the beautiful website design, was largely done by Wilson Fletcher, GBT’s chosen design agency.

This app is powered by Keystone.js, an open source framework built on Express (Node.js), and uses the Bluemix MongoDB service for persistence. As this service was still in the experimental phase, automated MongoDB database backups that we’ve previously talked about came in handy.

3. Web app

This app proxies requests to the previous 2 apps, handles URL rewrites and redirects, and provides a static page caching layer for the rare situations when the CMS app is unavailable.

Behind the scenes, this is powered by nginx, a most capable reverse proxy server, via the staticfile-buildpack CloudFoundry buildpack.

XP in action

With no estimates or scoping exercises, the donate app was delivered ahead of schedule. All apps were live, in production, weeks ahead of the public launch of the website. Even though Garden Bridge Trust has not yet launched their public fundraising campaign, all apps are meeting production requirements including high availability, horizontal scalability and fault tolerance.

While the CMS and web app were developed by a third party, Bluemix allowed us to collaborate on the different Garden Bridge components seamlessly and effortlessly. The deployment pipelines ensured that business value was continuously delivered, without any downtime, by separate teams.

Focusing on outcomes

XP is an agile development methodology which is focussed on business outcomes. Every story delivered should add business value, and all code is developed test driven. By adopting this approach, the Garage team is able to satisfy the business requirements with a code base that is bug-free, and deliver working code to the user in super quick time.