Battlehack Raleigh

This last weekend, I was fortunate enough to be part of a team that competed in Battlehack, a world-wide hackathon sponsored by Paypal. The premise of the hackathon is that you are coding an application that uses Paypal and is for social good.

My team met one week before and decided that the social problem that the application should address is how to make teenage driving safer. This topic was inspired by this heat map that shows that there is a statistically significant increase of car crashes around certain local high schools. The common theme of these high schools is that they are over capacity

This is also a personal issue for my daughter, whose was friendly with a girl who died in an accident last year near Panther Creek High School. In fact, she still wears a bracelet with the victims name on it. Unfortunately, she could not come b/c of school and sports commitments that weekend.

The team approached safe driving as a “carrot/stick” issue with kids. The phone app will capture the speed at which they are driving. If they stay within a safe range for the week, they will receive a cash payment. If they engage in risky behavior (speeding, fast stops, etc..), they will have some money charged to them. We used the hackathon’s sponsors Braintree’s for payment and SendGrid for email.

We divided the application into a couple major sections and the division of labor along each component. I really wanted to use Azure EventHubs and Stream Analytics but the Api developer was not familiar with that and a hackathon is defiantly not a place where you want to learn a new technology.

We set to work

Here is the part of the solution that I worked on:

The Api is a typical boiler plate MVC5/Web Api2 application and the Data Model holds all of the server data structures and Interfaces. C# was the right choice there as the Api developer was a C# web dev and the C# data structures serialize nicely to Json.

I did all of the Poc in the F# REPL and then moved the code into a compliable assembly. The Braintree code was easy with their Nuget package:

There were 19 teams in Raleigh’s hackathon and my team placed 3rd. I think the general consensus of our team (and the teams around us) is that we should have won with the idea but our presentation was very weak (the problem with coders presenting to non-coders). We had 2 minutes to present and 1 minute for QA. We packed our 2 minutes with technical details when we should have been spinning the ideas. Also, I completely blew the QA piece.

Question #1

Q: “How did you Integration IBM Watson?”

A: “We used it for the language translation service”

A I Wished I Said: “We baked machine learning into the app. Do you know how Uber does surge pricing? We tried a series of models that forecast a person’s driving based on their recent history. If we see someone creeping up the danger scale, we increase the reward payout for them for the week. The winning model was a linear regression, it had the best false-positive rate. It is machine learning because we continually train our model as new data comes in.

Question #2

Q: “How will you make money on this?”

A: “Since we are taking money from poor drivers and giving it to good drivers, presumably we could keep a part for the company”

A I Wished I Said: “Making is money is so far from our minds. Right now, there are too many kids driving around over capacity schools and after talking to the chief of police, they are looking for some good ideas. This application is about social good first and foremost.”

Lesson learned –> I hate to say it, but if you are in a hack-a-thon, you need to know the judge’s background. There was not an obvious coder on the panel, so we should have gone with more high level stuff and answered technical details in the QA. Unfortunately, the coaches at Battlehack said it was the other way around (technical details 1st) in our dry-run. In fact, we ditched the slide that showed a picture of the car crash at Panther Creek High School that started this app as well as the heat map. That would have been much more effective in hindsight.