HackZurich 2016

So I attended Europe’s biggest hackathon, HackZurich 2016. Let me share some thoughts about this equally fun and exhausting adventure and the project that we did. Even though some of the remarks might sound negative, the whole hackathon was a lot of fun. If I get the chance to, I would gladly repeat it.

About the hackathon

HackZurich took place at Technopark (what a great name!) in Zurich (CH). Like any hackathon it was (obviously) about working on a new project for (as much as you could last of) 40 hours and meeting some companies along the way. Or at least that’s what I initially expected. In truth there were a lot of mostly awesome side-activities besides coding to recharge your batteries, relax a bit, let the mind stray off a bit and sometimes just flatly annoy anyone sitting in the front part of the hacking area (“Thanks” to randstad for that wall touching/hitting game). For the main prizes there was no preset goal or theme a project had to meet but there were several companies that provided (more or less) specific challenges.

Lessons learned for future hackathons:

  • If your group needs another person to do a specific job (like frontend work in our case) don’t take just anyone that seems friendly and wants to try. If he states that he is “mainly a web programmer” that might be a red flag!
  • If they tell you that they don’t expect you to sleep, they do mean it. Just look at my sleep times posted below. Also, be prepared to sleep in seminar rooms between chairs. So either take a camping mat and sleeping bag with you or just work till you fall asleep on the floor.

screenshot_20160919-103222

  • If a company issues a challenge they won’t really consider anything else, then a solution that exactly tailors to this specific challenge and all their mentioned wishes. Don’t try to just do something about their general business cases.
  • Leave space in luggage for the unbelievable amount of lovely and cool merchandise.
So much merchandise...
The merchandise I got to take home. And I want to stress that i was picky and didn’t took all I could get…
  • Headphones or earplugs are mandatory! Looking at you Sith guy from CSS who repeatedly played his mediocre guitar-medleys whenever he seemed to be bored.
  • Pitching things is hard (especially if you haven’t tried it before in a foreign language).
  • It is very difficult to differentiate a click dummy from a working prototype for most demos. So don’t undersell the project and don’t let the judges think that your project is just the first one (if you spend a lot of time on making it really work).
  • If your demo depends on internet access like Wi-Fi and the presentation rooms are a bit far off the main area, make sure that they rooms are covered by it!

About our project:

Our goal was to use data from the various IoT devices (especially health trackers) and Open Data to build an app that provides users with recommendations to improve themselves and in the process everybody else. Picture someone who likes jogging but is looking for an additional way of being healthy that compliments his jogging. Based on the weather forecast (e.g. rainy), the user’s previous activity data and our data model, the app would recommend that the user tries out some indoor sport like bouldering that focuses on working with arms rather than legwork. To do this, we had to pull in and parse all available data from the sources and devices (we used the Withings API for example) and stored them in a Neo4j database. Because recommendation systems are (not coincidentally) a main use case for graph databases, we could easily ask the database things like:

  • the sports that the user is actively doing
  • find a sport that compliments a user’s specific activity profile
  • what sports similar users like ours do

Example of the data model

There is much more in this data that could be queried but time is short so we focused mainly on those. Whenever I can find the time to do so, I’ll  might clean up the data model and make this into a GraphGist.

Up until the last point all of our processing could be locally in the app itself (initially intended security feature that we later had to scrap because we didn’t get Neo4j to run as embedded version on Android) but to support the last query we needed a central database to be able to find similarities between users. For example, an insurance company could provide said server and thus gain valuable insight into people’s health data. They could use this to directly market their offers to the people that actually need them. To give an example: After connecting to the server in our demo the app would not only suggest a yoga course but also offer discounts on the very same page and the direct map-based option to search and book a local course. The data could also be further used to predict demand and to find customer groups that don’t yet benefit from any current offerings and create new courses/offers tailored to them.

The following video shows a little demo of our final submission:

Thanks for reading, if you’ve got some questions let me know. For now, I’m going to catch up on some missed sleep.

Leave a Reply

Your email address will not be published. Required fields are marked *