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:

1 type BrainTreeDebitService() = 2 interface IDebitService with 3 member this.DebitAccount(customerId, token, amount) = 4 let gateway = new BraintreeGateway() 5 gateway.Environment <- Environment.SANDBOX 6 gateway.MerchantId <- "aaaa" 7 gateway.PublicKey <- "bbbbb" 8 gateway.PrivateKey <- "cccc" 9 10 let transaction = new TransactionRequest() 11 transaction.Amount <- amount 12 transaction.CustomerId <- customerId 13 transaction.PaymentMethodToken <- token 14 gateway.Transaction.Sale(transaction) |> ignore

The Google Maps Api does have a nice set of methods for calculating Speed Limit.  Since I didn’t have the right account, I only had some demo Json –> enter the F# Type Provider:

1 type SpeedLimit = JsonProvider<"../Data/GoogleSpeedLimit.json"> 2 3 type GoogleMapsSpeedLimitProvider() = 4 interface ISpeedLimitProvider with 5 member this.GetSpeedLimit(latitude, longitude) = 6 let speedLimits = SpeedLimit.Load("../Data/GoogleSpeedLimit.json"); 7 let lastSpeedLimit = speedLimits.SpeedLimits |> Seq.head 8 lastSpeedLimit.SpeedLimit

Finally, we used MongoDb for our data store:

1 2 type MongoDataProvider() = 3 member this.GetLatestDriverData(driverId) = 4 let connectionString = "aaa" 5 let client = MongoDB.Driver.MongoClient(connectionString) 6 let server = client.GetServer() 7 let database = server.GetDatabase("battlehackraleigh"); 8 let collection = database.GetCollection<DriverPosition>("driverpositions"); 9 let collection' = collection.AsQueryable() 10 let records = collection'.Where(fun x -> x.DriverId = driverId) 11 records |> Seq.head 12 13 member this.GetCustomerData(customerId)= 14 let connectionString = "aaa" 15 let client = MongoDB.Driver.MongoClient(connectionString) 16 let server = client.GetServer() 17 let database = server.GetDatabase("battlehackraleigh"); 18 let collection = database.GetCollection<Customer>("customers"); 19 let collection' = collection.AsQueryable() 20 let records = collection'.Where(fun x -> x.Id = customerId) 21 records |> Seq.head 22 23 member this.GetCustomerDataFromDriverId(driverId)= 24 let connectionString = "aaa" 25 let client = MongoDB.Driver.MongoClient(connectionString) 26 let server = client.GetServer() 27 let database = server.GetDatabase("battlehackraleigh"); 28 let collection = database.GetCollection<Customer>("customers"); 29 let collection' = collection.AsQueryable() 30 let records = collection'.Where(fun x -> x.Number = driverId) 31 records |> Seq.head

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.

Tech Jam and Team Islington Green



So a couple of friends from TRINUG – Ian Cillay and David Green – invited me to join them at a 36 hour continuous code fest called Tech Jam. Tech Jam was put on Met Life and the Department of Veterans Affairs on Nov 1 and 2 in RTP. This team of 3 developers was joined by Ian Henshaw who helped with some primary data provision and much of the user story development. David handled the MongoDB part, Ian took care of the UI (Bootstrap and Knockout), and I did the analytics (F# and R) and security piece.

The problem domain was that the Veterans Administration has this format of medical records called Blue Button. Blue Button is an unstructured format which make typical parsing and analysis very difficult. Here is a sample:


Also, the VA wanted some kind of mutli-platform solution that a vet can use that can make sense of this data and allow him/her to provide it to a care giver when needed.

Some random thoughts about the contest:

  • MongoDB makes a lot of sense for the data because of it being so unstructured. Note that the VA has now introduced BlueButton+, which is XML format – so that is a step in the right direction. I was impressed how easy Mongo was to use and how powerful it is to tackle unstructured data – but note that even MongoDb still needs some kind of structure – just not xNF relational…
  • Bootstrap was awesome – we used an out of the box template and it was great to knock out an easy design.
  • F# made analytics and predictive analysis a snap. 
  • There were 15 teams registered, 10 actually presented at the end. There were 2 community teams (us and another), 1 high school team (awesome), and a bunch of corporate teams (Deutsche Bank, IBM, Tata(X3!), etc…).
  • One of the teams (Infusion) was a vendor for Met Life already (they worked on the wall project and the infinity project). Unsurprisingly, they won the grand prize.  My only comment on that is that civic/community hackers already view events like this with a skeptical eye – and this did nothing to help MetLife in the eyes of those kind of people – in fact probably did the opposite.
  • I was amazed by how many teams did not actually address the primary problems that the VA needed fixed.  The problems were taming unstructured data and presenting it in a platform-agnostic way.  Most teams used HTML5/Phonegap for req #2 – which is the easier one.  I think only 3 teams actually addressed requirement #1?
  • I am proud to say that my team did address both requirements.  As I sometimes say “I listen to two things in life: my wife and the requirements.  It goes better for me if I do that.”
  • Another team was from a company where the boss showed up on Saturday to present the team’s work. I guess that is the difference with a corporate hack-a-thon.  Also, you can tell the corporate teams because they had more powerpoint and less code in their final presentation.  Not that there is anything wrong with that….
  • The best line this weekend was when I asked a D level person at Metlife why no one at Metlife was retweeting my tweets with their hashtags (#techjam) and he said "we have a guy for that." Sure enough, they had 1 person who was their tweet guy.
  • MetLife really know how to put on a contest. The MC for this – Gary Hoberman – was awesome – a V-Level techie that really could communicate with the coders. The food was good (they took into account different dietary needs), the working space was good and the swag was useable.  Also, they had dev mentors circulating around the room, though they seemed to spend their time with other teams – so we didn’t interact with them.  They also had reps from MongoDB and MSFT helping out – which is great because we leaned on them for specific problems.

The problem with a code contest is that you have little time to learn from your fellow devs – it is pretty much heads down and check-in. In any event, the best part was hanging out great developers like Ian and David and working on a worthwhile project for our country’s vets.  At the end, it was a fun time and my team delivered that the VA can use to springboard into a real application.