Battling it out for glory at Battlehack

Battling it out for glory at Battlehack


WHAT A WEEKEND! I’m still recovering from the 24 hours of coding and the unhealthy amount of coffee and snacks I’ve ingested during this hackathon.

Two weeks ago, Melbourne was host to the first Battlehack of 2015. “What’s a Battlehack?” I hear you ask. Well Battlehacks are competitions sponsored by Braintree (a Paypal company) where teams of developers face off over 24 hours to create the most creative hack that benefits the local or global community. The venue, which was the Plaza Ballroom on Collins St was well worth a mention. The vast ballroom was decked out with food stations, sleep and massage stations, and most importantly, our hacking stations, or tables of 4 for the long night ahead.

Over the weekend, I developed a very close bond with two bean bags strategically positioned to form a comfy coding chair. This competition is well known for its gourmet food and you can rest assured they lived up to our expectations. We were treated to pastries, ice popsicles, paella, zonuts, pulled pork sliders, you name it!

Now to the competition! There are not many rules governing the choice of hack other than making use of one of the sponsor’s APIs: Paypal, Braintree, Bluecats, Localz or JustGiving. Paypal and Braintree provide APIs to process all sorts of payments like credit cards, bitcoin, etc. Bluecats and Localz are devices which allow developers to push location specific content to their application. JustGiving is a platform for making donations to well-known charities. The competition overall was really well organised, the doors opened at 10am followed by some presentations and lunch. Participants gathered their troops, grabbed a few cups of coffee and got settled in for the 24 hour hackfest.

Four of us took part in the hackaton: Dmitry, Arthur, Shane and myself. We decided to make the world a better and healthier place by encouraging people to run by making donations on their behalf if they didn’t meet their fitness goals. It would work by having users create challenges for themselves by specifying the distance they would run, in what time period, and the amount of money they would pledge to donate if they didn’t meet their goal. Honesty is policy! So in order to keep people honest about the distance they ran, we decided to integrate our application with Fitbit to retrieve daily statistics on users. After deliberating for an hour and hashing out our game plan, we were set with our idea and got down to business.


For us all, this was our first hackathon nevertheless one thing we knew for sure was that we had to make the most of every hour if we wanted to complete our application. With that in mind, we quickly setup a Github repository to host our code and used JHipster to scaffold our application. We used JHipster because it provided us with a stack that we are all comfortable with. We get AngularJS goodness on the front-end, a powerful Spring REST backend and awesome Bootstrap components and grid system. All this tied together via Maven for packaging the application and Grunt performing optimization of resources for production (amongst other things). Grunt was executed using a Maven plugin so there was also no need for separate build/release processes. Great!

After that we organized ourselves so that one person was doing a specific thing as to avoid stepping on each other’s toes. Shane started working on setting up a web server hosted on Amazon Web Services and we needed a database so he worked on setting up an RDS instance to go with it. Dmitry started working on the core functionalities of the application (being able to create challenges, users, etc.). Arthur started perusing the API documentations of Braintree and JustGiving to see how we could use their APIs to process donations. Meanwhile, I got started on the Fitbit integration (it was a good thing Arthur brought his Fitbit to the hackathon!). I looked up at the big countdown clock on the screens and I swear I had never experienced time moving quicker than this.

Before we knew it, we were 4 hours into our hack but we were making descent progress. Shane had the servers setup in a flash so he proceeded to getting us set up with our own domain name so we could host our application for people to access. We settled for (not the most clever, we know). At this point I was hating on Fitbit pretty bad. The API uses OAuth 1.0a, which is an outdated version of the protocol so documentation was a bit scarce and the Fitbit4J library was deprecated (ouch!). I ended up writing the handshake code using a helpful library called Google OAuth Client. After hours of trial and error, I managed to retrieve statistics from Arthur’s Fitbit device. I loved Fitbit again!

Meanwhile, Dmitry had been smashing the Angular side of things and was successfully creating users and challenges. Arthur had some issues with the beast that are payments so we got a Braintree developer to helps us out. After dinner, I moved on to the front-end side of things and put my designer hat on to make the default JHipster pages look a little more professional. As the sun was rising, we had all the core functionality down. We were registering users, linking Fitbits, creating challenges and processing donations using a scheduled job every 5 minutes. In the last three hours, I don’t recall much code being written, we were simply in overtired mode, and laughing hysterically from the lack of sleep.

However, we did have one deployment issue an hour or so before the end, which brought us back to reality. The web server couldn’t connect to the RDS instance so we decided to go ahead and use a local instance of PostgreSQL instead (not the most elegant solution but it did the job). The problem was fixed and FitDonate was now live!


From left to right: Dmitry, Shane, Arthur and myself

We got the opportunity to present our application during rehearsals in the morning and the main feedback we got was that our application was good but we needed to focus on the aspect that would differentiate ourselves from our competitors. This came as a bit of a surprise to us as we didn’t realize we had to pitch our idea (almost in the hopes of getting funding for it).

At 1pm sharp, the gong was struck, along with cheering developers counting down the last seconds of the Battlehack. We got the opportunity to freshen up and final presentations were then under way. 23 teams participated in this hackathon and 23 brilliant ideas were demonstrated on stage. The winning team was last year’s Sydney Battlehack winners, who developed a jacket for cyclists to ride safer at night – called NightRider. The jacket uses motion sensors to detect when a cyclist raises their arm to indicate their turn, causing LEDs sown onto the jacket to illuminate, warning motorists. The jacket also had a built-in accelerometer to sense when the cyclist slows down, which illuminates a brake light on the back of the jacket. In case you’re wondering, their use of the Paypal API was for people to purchase the jacket online.

Despite the fact we didn’t take out the top prize, it was an amazing experience. I feel like all of us challenged ourselves and learned a lot in the process. With that in mind, I’d like to give some advise to anyone thinking of entering hacking competitions:

  1. Prepare thoroughly. Make sure you and your team have prepared well in advance. This means researching frameworks, the APIs that you may need to use, write sample projects that use these APIs and think of an idea well ahead of time so you can plan your execution.
  2. Hardware! Hardware! Hardware! The hardware hacks were crowd favorites so I highly recommend you give Arduino’s or Raspberry Pi’s a go. Even better, make a hardware hack augmented by software in some way.
  3. Know how to pitch it. The presentation of your hack is probably the most important thing as this can make or break your project. If it can be sold well, marketed well, pitched well, the judges will respond favorably. Even if your application is not 100% up to scratch when the time’s up, the presentation can win the judges over as they don’t delve into the technicalities of your coding. Make sure you get your design right, make a power point presentation, or even better make a video! I also highly recommend getting a designer on your team so you can nail the UX/design aspect of your application.

Consultant at Shine Solutions and Adobe Certified AEM Lead Developer

1 Comment
  • PuZZleDucK
    Posted at 15:05h, 10 April Reply

    Couldn’t agree more on the importance of the presentation. Some of the winners had relatively simple tech, but great “user stories” or presentation.
    Getting in a team before the night is a good call too… tried to form a team on the night. Result: three mostly incompatible tech stacks!

Leave a Reply

%d bloggers like this: