Hackathon 2017

Hackathon 2017

It’s Hackathon 2017! At the very least, that’s what we’re calling it. For the uninitiated, Hackathon is an event where programmers, designers and project managers come together to develop a software in a day or week. The main purpose of this event is to create a working model, though Hackathons have been known to take place as an educational tool or for researching and developing new ideas or concepts. Google is known for this, a practice known as the ‘20% time’. This is where Google News, Adsense and Gmail saw the light of day.


Mobi Move likes to innovate, and an internal hackathon sounds like a fun way to adopt new ideas and practices. While a day every week like Google was known to do is a bit extreme, we strive to have one of those ‘20% Time’ events bi-monthly, if the circumstances allow it.

In the past, we’ve done something similar by putting time aside for some RnD. Our very own Promo King was actually born from that, though it was nothing more than a fledgeling idea at the time. Eventually, this concept grew and took a form of it’s own. It was our hope that we would be able to replicate something similar, or, if not, maybe open the door on some new ideas.

So what was the plan on that day of sprint-coding and ideas flying left, right and center? For starters, breakfast! It’s not wise to code on an empty stomach, so it was croissants for everybody, either regular or chocolate. While the breakfast was underway, teams were assigned, tasks were delegated, and teas and coffees were drunk. Having eaten our fill of french pastries, it was time to get the ball rolling.

Our focus this ‘Hackathon’ was on bluetooth beacons. What are those, you might ask? They’re small little devices that can be attached to almost any surface that broadcast their identifier to nearby smartphones or tablets. This allows compatible portable electronics to do a number of things, like reveal the physical location of the beacon so you can tell where you are in a building. It can also be used to display unique messages or track customers in a store. For example, beacons could be used in museums to display information about a piece that would normally not fit on a plaque.

The office was split into three teams, each with their own project. One was charged with figuring out an algorithm that would enable us to use beacons to tell the approximate queue time when waiting in line. Another team was tasked with finding a way to properly distribute the beacons around the office so that a person will know what room they just entered thanks to the beacon in it. The last team had to make the beacons send a push notification once a device was in range.

The idea behind this exercise was to explore ideas one might not be comfortable working with, and right off the bat, team Algorithm had to figure out a formula that could handle the calculations required. Thankfully, there are some pretty brainy people at Mobi Move, and they found something called the Pollaczek-Khinchin (PK) Formula. Here’s how it works:

“The PK Formula averages the wait time in a queue by taking an average service time, the utilisation factor (which is essentially how fast the queue moves over time over the average number of people in the queue in at all operating hours) and potential variables, and crunching these numbers together.”

Beacons can be used to detect the movement of people in a line and provide the necessary data to feed into the formula. The waiting time is averaged and a person with the corresponding app will be able to know for how long he or she will have to wait. You can find more information of the Pollaczek-Khinchin Formula here.
On to team Distribution, they started by designing an approximate blueprint of the office so that the beacons could be mapped to it. Afterwards it was a matter of identifying what room which beacon was in and voila! This feature is helpful to identify locations that may not be very obvious to those unfamiliar with it, or even to give directions.

“We made an app which detects nearby beacons configured to work with it and display info to users based on the beacon ID. The app can run in both foreground and background. When a user device is in range the app gets notified and displays a pre-configured message.”

Team Push Notification had to create an app that needed permission from the user to change certain settings. For example, once in range of the beacon, the app would ask the user whether they wanted to access the office’s WiFi network. Tapping ‘yes’ would then request the password of the office WiFi from a server and connect automatically. Nifty, isn’t it?

Come noon, food was back on people’s mind. To quell rumbling bellies and help with the distracting thought of lunch, we had some KFC chicken, but mostly as a starter. Pizzas were on the way. We ate our share, and it was back to the Hackathon.

Several hours later, it was time for some beer! Before you ask, no one got drunk. We’re responsible drinkers here at Mobi Move. At the end of the day, there was a brief presentation to showcase the projects and it all worked as expected, save for a few snags here and there. After all, no programmer has ever coded something to perfection on their first try.

All in all, this internal hackathon was a great opportunity to test new things. We had not worked with beacons before and seeing them in action with apps we made ourselves was a very satisfying experience. We look forward to the next one!