Story of a hack: Bring Your Own Music!

This post is a summary of the weekend we spent at the Kings of Code 2012 Hack Battle in Amsterdam. What started as an occasion to get to know smart people doing cool things in Amsterdam (something I look for since I moved here) turned out to be one of the funniest experiences I had in a while.

After a brief presentation of the services offered by the hackathon partners ( Apigee, Esri, Spotify and Sendgrid) Diderik, Mattia, Mike and I teamed up to build the hack featured here. We started with the most obvious concept we could come up with: putting songs on a map and having people visualize them. We tried to elaborate the concept to include as many of the partners’ APIs as we could, but then we decided for something simpler, something we could build over the weekend.

It took us a couple of iterations to get to the final idea we developed: Bring Your Own Music, a toy application that allows users to control music playback through NFC-enabled objects by using an Arduino-powered NFC reader driving a Spotify app.

BYOM is based upon the idea of attaching Spotify playlists to physical objects, provided they contain an NFC tag, like many of the cards we have in our wallet. Once you have done that, you can then bring your card with you to a party, tap it on an NFC reader, and have a Jukebox Spotify app like the one we built start playing your songs automatically.

If multiple people tap their own cards, the main Spotify playlist adjusts itself according to the general preferences of the party attendees. We even kept playing with NFC-enabled objects and linked Spotify playlists to all sort of cards, like London’s Oyster cards, OV-Chipkaarts and even the disposable tram tickets you get here in Amsterdam.

As Mattia noted,

wouldn’t it be great if passengers could listen to their favorite music when they check-in on trams?

How was BYOM built?

We collected the identifiers of a bunch of NFC cards, OV-chipkaarts and tram tickets using Mike’s Arduino connected NFC reader. We then created a collection on Apigee App Services to store the card ids and URIs of the Spotify playlists we wanted to link to them.

We programmed Arduino to make a call to Apigee whenever a card is tapped on the reader, in order to store the card identifier into a Swipes collection.

At the same time, we wrote a Spotify application that periodically queried Apigee for new swipes and, as soon as a new card was detected, fetched the songs associated to it and merged them into the main playlist (the one the Spotify Jukebox app would play).

What have we learned by it?

We (I, at least) walked away with some important teachings:

• focus is more important than ever: there is no point in imagining lots of features if you are not going to finish them. Pick a small set of features and make them work (or almost work: we had the inevitable demo-time malfunctions despite having tried the full example multiple times before presenting),
• build a story: having a story (in our case, the party) around your hack helps you focus and helps you when presenting it,
• get some constraints: there are thousands of interesting APIs, devices and ideas out there, and even more ways those can be combined. Choose some constraints to ensure you don’t wander off too much (in our case, we wanted to do something with Mike’s NFC-reader)
• have fun: while these sounds like rules, they are more of an advice. Do not let them distract you from your goal: having fun.

What about the technologies?

Arduino is indeed an extremely versatile tool and the amount of sample code and libraries available out there is surprising. While it can be a pain to debug at times, the fact that it allows you to add a physical dimension to your hacks is invaluable.

Spotify‘s wise choice to build their application framework on top of Chromium means that developers can leverage the tools they already got to know by developing web applications. The actual app SDK is a JavaScript library you an include and debug using the tools in Chromium. We were able to get started in minutes and, once Andrew put us on the right track (by pointing us at the experimental but more powerful 1.0 API), never hit a wall or get stuck at all.

Apigee App Services is indeed a valuable tool: it saved us a lot of time by taking care of storing our data and, more important, exposing it over the internet with no hassle. (The fact that we were even able to interact with it through an Arduino is not trivial.) It also took away the need of building an admin interface for most basic needs. Quoting Diderik

Apigee allowed us to get so much done on the first day of the hackathon that we could go home and get some sleep for the night.

How did it go?

Not bad at all. We managed to win a couple of prizes: each of us won a 6 months premium subscription to Spotify (thanks Andrew!) and a gift certificate courtesy of Apigee (thanks Tim!). All in all, we did not build BYOM for the prizes, but we were glad to get them.

The most important thing is that we had great fun coming out with a solution that worked and thinking about how to communicate what seemed so cool to us. We had even more fun seeing what the other teams had built (there were some really brilliant hacks indeed). Isn’t that what a hackathon should be about?

Can I see it?

Sure, you can check the source code. Beware: it’s hackathon-grade code, so it probably does not look like the clean code you would normally want to write during the day. If you are curious, here is a video with Bring Your Own Music and all the other cool hacks built at Kings of Code 2012 Hack Battle. (It is a bit dark, but you get the idea.)

More from us: Follow @diderikvw Follow @nldmike Follow @raibaz Follow @abahgat

Thank you guys for the great weekend!