Ghosts Calendars And Cucumbers

Stuart Harrison

The ODI’s new membership programme, launched last month, offersa whole range of benefitstobusinesses whichwork with open data,publish it or just want to get to grips with it.One of these memberbenefits is the optiontouse our space for meetings-so if you don’t have a permanent base in London, or just fancy a change of scene, you can use one of our hot desks, pods or meeting rooms.

Obviously, if you’re a member planning on using our space for a specific day or time, then you’ll want to be able to guarantee that there will be space available for you. This is where the tech team comes in.As part of sprint #4we were tasked with building an app to allow members to see, at a glance, what spaces were booked, and for how long.

On the surface, this looked like a simple task. We use Google Apps for all our internal email and calendaring, so it should have just been a case of pulling an iCal feed out of Google Calendar, andinto the app.

However, a bug in Google Calendar meant that we couldn’t get public iCal feeds for the pods and meeting rooms (called ‘resources’ in Google Apps), and time being of the essence, we couldn’t wait for it to be fixed.

Another problem was testing our code - in my previous role, I worked on my own and checked my code by literally testing anapp in my browser before I pushed it to live. However, as we are starting to move towards continuous deployment at the ODI (that is, our code gets tested and pushed to live every time we push it to Github), we need to make sure we write tests for our code.

Ordinarily, this isn’t a problem. We use Cucumber to write a load of expectations and then test these expectationsby querying the database, spinning up a virtual browser, or recording a HTTP interaction. If the tests pass, the code gets deployed. However, as the plugin we wanted to use was javascript-based itcausedus problems running automated tests inJenkins(normally, if we want to test Javascript, we have to spin up a real browser,like Chrome or Firefox.)

These obstacles meant that, as is often the case in software development, what looked like a simple task actually became a bit more complex.

The first thing I had to do was look at the Google Apps API. The normal process for connecting to the API (and most of the examples I saw), involved a user authenticating against their account in a web browser and then the app pulling out their data. As we only wanted to pull data out of the ODI account, and there was no front end user interaction, the use case was rather different.

I eventually found the solution, and with bookings being pulled into my app quite happily, I got onto testing my code.

In my former job, I’d played a bit with Phantom.js, which is a fully functional web browser, without one crucial thing - a window. This is immensely powerful stuff, and means you can do anything you can do in a normal browser by issuing a few Javascript commands. It’s great for web scraping, automating things like form submissions (I used it in my old job to automatically upload reports submitted in Ratemyplace to the Food Standards Agency ratings site), and yes, testing!

I blogged about this in more detail on my personal blog, but suffice to say, it worked perfectly, and I’m hoping to find more excuses to use this technology in the future.

You can see the final results at and see the source code here. At the moment, you can only view bookings, but we’ll be looking at allowing members to book space online.

Crucially, we’ll also be using the data generated by the app to build awesome dashboards for our Commercial Team to see how the space is being used. In the coming weeks, we’ll be using a lot more of the data generated by our external and internal apps, and publishing more data on things like our members and events, so watch this space!