It seems I didn’t blog about Over the Air back in 2010, beyond referencing the phone I won for my hack. That’s pretty poor. I don’t appear to have blogged much about any of the previous events either, apart from Hack Day 2007. Decidedly lax of me. So let’s do a ‘quick’ catch-up.
For those that aren’t aware, these events are typically 24-36 hours long, including an overnight portion, and the aim of them is to learn new stuff, see cool things, and during the event to create something wonderful – typically a proof-of-concept hack of some kind. There are often prizes for different categories of hack, as well as the motivation that comes from working amongst your peers.
These events are not dissimilar to the hackathons found in many open source communities (for example the Cocoon GetTogether hackathons in 2004, 2005), but the hack days tend to be more far-ranging and technology-agnostic.
The 2007 event was an eye-opener for me, though as I wrote at the time I bailed out before the second day. Aside from the network troubles, I seem to recall one of the major frustrations for me was getting a ‘quick’ development environment up and running on my laptop in order to do a timely hack.
After 2007’s hackday the event morphed into “Over The Air“, and the 2008 event I sadly missed. It was back for 2009, and in 2010 I was determined to enter a hack of my own.
As a result of some conversations (I seem to recall a chat with Thibaut resulted in the Plaxo bit), I created a hashblue/Plaxo mashup, which took the o2 #blue APIs and plaxo APIs to automagically match text messages to people in your address book. I used PHP and Postgres for this, and was later able to pretty much design-out the RDBMS bit since most of the data was in Plaxo. I was then only using the DB to store details of avatars, to make the page look fancier. It worked pretty well, until the #blue API was changed earlier this year (such is the fate of apps using beta APIs). Even better, I won an Android phone as a result, which was awesome. What’s left of the hack is still online at OTA 2010 #blue hack, and I may resurrect it if I ever find a use for it.
~
This year’s idea was to be a mashup of competition categories as well as APIs. I wanted to update my knowledge of the BlueVia APIs after my #blue experiences, and the Pearson APIs seemed to have some compelling content. Given last year’s prize was a Sony Ericsson phone, I also wanted to use the Ericsson Labs APIs to say ‘thank you’. Finally, the Met Theft Challenge tickled me, and although I didn’t attend the stolen phones session, I thought it would be a fun problem to tackle.
The idea I came up with was this: if your phone is stolen and was not locked with a PIN, there’s a good chance the thief is going to look at your apps and your data. Bear in mind here that not all phones have a ‘find me’ feature yet. It seemed plausible to use social engineering to trick the thief into telling you where he is. So, I would prominently place a banking app on the phone’s home screen, which when launched would fire up a realistic (and customisable) dummy copy of an online banking website. The website that would actually be loaded would use the BlueVia APIs to send a message to the phone’s owner, containing the device location. Of course, “your phone is at latitude 51.507071, longitude -0.036241″ does not mean much to most people, so I would use the Pearson APIs to search the Eyewitness Travel Guides for places near that location. “Your phone is near St James’s Palace” being theoretically more human (or tourist) friendly. Finally, with the magic of the Ericsson Mobile Maps API, I would deliver a friendly web page to alternate phones (for example nearby friends), plotting the stolen phone and all those nearby tourist locations.
This year I cheated a bit, in that I spent time ensuring I was pre-registered with most of the Over The Air API providers in advance, to ensure optimum hacking time (rather than waiting for API keys etc). I’d also picked the development environment I wanted to use, and got everything up and running. Sadly, the best-laid schemes o’ mice an’ men…
For this hack, I decided I would use HTML5/JS/CSS and node.js on the back-end. This was before all the controversy kicked off around the use of Node (node.js is a cancer), but frankly I would still have used it as it’s a simple solution to prototyping hacks.
What I did get working:
- Geolocation through the BlueVia API, using the BlueVia node.js example to take the pain out of the oAuth part. I had some help from the BlueVia guys when the Location API kept failing; the trick was to use the sandbox environment until the servers came back.
- Lookup of the points of interest nearby through the Pearson API. This caused some n00b problems for me where node was complaining during parsing the data – turns out https.get fires data events for response chunks, not for the whole response. Oops.
- The map view, with all the points of interest plotted. Except I ended up using the Google Maps API due to time constraints, and because the Sony Ericsson APIs are aimed at Android/J2ME devices.
What didn’t work so well:
- The idea of the app on the phone. It turns out you don’t really need this bit, since the BlueVia APIs will give your phone’s location via any web app that’s suitably-authorised, it doesn’t need to launch from the phone itself. So I scrapped that bit.
- The network. The very same thing that bit me at the 2007 HackDay came back to haunt me: sadly, the Over The Air wifi had some problems, so I ended up tethering my laptop to my mobile for most of Friday. Quite literally, with a USB cable to keep the phone charged while I punished the 3G connection.
- The data. Using APIs for purposes other than their expected use isn’t necessarily going to win. In this case, the “points of interest” data from Pearson tends to be clustered towards central London; if your phone is located away from those points, there’s not much point plotting it on a map or referencing the points. Nice idea, fails in implementation.
- Time. Although 3G is good for big chunks of data, it sucks for multiple small requests due to the latency/setup overhead lag. I also lost an embarrassing amount of time to the http chunks problem.
- Tube trains. I headed home Friday night to get some good network connection and then some sleep and a shower (seriously OTA organisers: next year, make it a venue with showers. Please!) But the Northern Line was closed on Saturday, making it a pain to get back to Euston and thence to Bletchley Park.
- The weather. Although it was awesome being at OTA on Friday and hacking on a bench in the sunshine, and the best bit of OTA is the hack demos, I decided to throw out the nightmare transport problems on Saturday in favour of a trip to Greenwich.
So the final hack is rather more rough and unfinished than even I expected. You can see a static copy of the output at OTA 2011 BlueVia Pearson Google Hack; if I get time I’ll set up a proper proxy of the node.js version so you can try out the locator bit yourself (assuming you’re signed up to BlueVia).
Lessons learned from this year? Don’t trust the network. Don’t be ambitious with your hacks if the sun is shining. If the forecast is good, take a tent. And always, always go to Over The Air: it’s both a learning experience and an inspiration. If you’re in IT, and do (or have done) development, make sure you’re there next year.