Sunday, 5 October 2014

Unhacked

I took way too long to write this. This really should've been written the Monday or Tuesday after, but apparently I get swamped. No, swamped doesn't include getting in any byke rides other than the usual commuting/transport purposes.

After attending three hackathons previously, it was time to Unhack for hackathon #4.

If you were at Unhackathon and currently reading this, yes I was the guy with the green Penn State shirt, monitor rotated vertically, a buckling spring keyboard, stayed up all night but had to leave right at the end of the demos to catch the bus back to Penn State.

First, some credits. Have to give Hanne and the organising team and volunteers a major one for putting on a smooth-running event despite all the setbacks that occurred, ranging from the move from the Stony Brook University campus to AlleyNYC to finding that no buses were available to charter for the weekend. The fact that this was Unhackathon's first run is just icing on the cake. Had to be my favourite hackathon out of my four participated.

Also shoutout to my Carnegie Mellon peeps Alex, Brandon, (I'm gonna butcher your name spelling) and Kevin who I met first thing upon arrival and sat next to for the entire time. I think I'll have to consider getting an Oculus Rift now.

Anyway, enough of the credits. We made something like this:
Before I go into any implementation details and what purpose it serves, here's some background. Sometimes I pre-plan long road rides, so that includes at least one food/drink stop. Sometimes finding the right place(s) to stop is extremely tedious.

I didn't come into Unhackathon with any ideas on what to build; coming up with ideas isn't something I'm good at unless I have some problem that needs immediate fixing. However, during the opening, we got a demonstration/explanation of ordr.in and their API, so combine that with stuff sneaky bastards do and Coffeestop is born.
So I found Amy and Raymond from Columbia right after opening ended and got to work. We did some design and workflow diagrams to determine the best course of action afterward. Based on our diagramming, we decided on Flask (my third time in a row using this microframework in a hackathon) as the backend.
We originally wanted to use the Strava API to get the GPS route files from, but we quickly realised that just working with the raw .gpx files was easier when the final product is just a prototype.

Clearly we need a large enough dataset of coffee shops, caf├ęs, etc to populate the results based on route, and we eventually found the Yelp API to be good enough for that purpose. It also helped that the API was able to return results based on a radius from a given geographic coordinate, which was gotten from the .gpx files.

And finally, we used the Google Maps JavaScript API to draw the damn map!

Now, the ordr.in integration wasn't as much fun as we thought. Since ordr.in's core service is in food delivery, not also just-in-time pickup, we had to plan on setting the delivery destination to the originating establishment. Okay. But in the end, we ran out of time and sanity to really get that capability even visible alongside the Yelp results.

While we are on the Yelp results, we also ended up with multiples of the same result(s) based on our coordinate-based searching. Since the coordinates that we fed into the Yelp API were relatively near one another, it is expected that in the aggregate results array there exist multiples of the same result. Again, we ran out of time and sanity to fix that, but then again doing the cleansing would have added to the processing time…

Other items claimed by erosion of time and sanity were map markers and info windows of each result, stuff relatively easy to implement. And, thinking about it post-hackathon, this would have allowed us to store the results in a Python Set data structure instead of a List.

All coding, designing, development work aside, I think the last-minute move to AlleyNYC was really for the better. I wouldn't have been able to work with my two Columbia teammates otherwise (they said they wouldn't have came if Unhackathon were still held on Stony Brook University campus), and the relevant, intimate feel of working in a rather small tech co-working space really made this my favourite hackathon yet.

But this hackathon's main purpose of existence wasn't so much to create the coolest, fanciest hack ever (though there certainly were cool ones there), but to encourage creation of brilliant code and helping one another out. And with that, it's been fun Unhacking. Now onto YHack in a few weeks!