This past January, I and 1000 other hackers from all over the United States converged at the University of Michigan for the fifth occurrence of their biannual hackathon. The experience was truly incredible. I met so many awesome people with a one common goal in mind: To hack the weekend away, building what could be the next Snapchat, Uber, or Tinder for Cats.
I am truly blown away by this. This is less of a hackathon and more of a rock concert.
Jahan Khanna, MHacks V Keynote Speaker
I came to the hackathon with not much more than a laptop, a backpack with some extra clothes in it, and an open mind. I was excited for the next 36 hours, and knew that it would be tiring, yet a lot of fun. My team, which consisted of one other high school hacker, had some ideas in mind, but were not entirely sure how to execute them. We decided to settle on a simple idea where a user could listen to audio files without the need for a cellular or Wifi connection. Basically, we were trying to find a way to send the audio file’s data via SMS. Our plan was rock solid. I would work on the mobile app frontend, which would parse the SMS data and convert it back into an audio file, while my teammate would work on the server-side backend, deconstructing the audio file and turning its data into a format that could be sent via SMS.
Early on, we realized some flaws with our idea. The University of Michigan EECS building had no AT&T coverage inside, meaning each time we wanted to test the mobile app frontend, I would have to run outside into the blistering sub-zero weather with my phone and test it there. But that was more of an inconvenience more than anything else, and it was definitely not going to stop us from building our hack.
Audio files are just way too big to send in 1600 character chunks. We estimated that with audio compression, the largest song anyone would probably request would be around 5MB, or around 6 minutes in length. Doesn't sound like much to send, right? Wrong. Very, very wrong. A 5MB file is around 6.8 million characters when encoded in a single base64 string. Twilio, the SMS API we decided use, could send up to 1600 characters per SMS. We realized that Twilio would have to send 4,250 individual SMS messages just so the user could listen to a song equal in length to Bohemian Rhapsody. This was clearly not going to work. Given that Twilio could only send one SMS per second using their regular phone numbers, and three SMSs per second using their toll-free, slightly more expensive phone numbers, this process would also take an extremely long time. We estimated it would take around 25 minutes for a song to be sent and processed before the user could actually listen to their song of choice. Of course, if the song requested had been shorter in length, the user would be able to listen to it sooner, but given that nobody really wants to wait more than thirty seconds for their song to load made this idea even less feasible.
Despite the challenges, we still decided to try and hack our way around these issues, which (you guessed it) did not work. We ended up spending a lot of the hackathon trying to work around these issues and build something functional yet the issues only continued to worsen. However, these kinds of problems happen at hackathons all the time, and is part of the experience. Having your project idea pivot less than hours 12 hours before the hackathon ends is not always the best thing to do, but in our case, we had no other options. We decided to revisit the overall problem we were trying to solve, which was to allow those without a strong Wifi or cellular data connection listen to music. Then, probably out of sleep deprivation, it hit us. We realized that probably the simplest and fastest method of solving this problem was to have our app dial the user and play the song over the call. Seemed simple enough, plus we could reuse more than 80% of the backend we had written for our original idea. The unfortunate part was that our mobile app frontend was now rendered useless, as the user could now just send and SMS to our server with a song name and the server would call the user back. But that was apart from the point. We decided to start hacking away at our new idea almost instantly, and had a functional prototype within 20 minutes.
Over the course of the following few hours, we spent time implementing additional features such as a way for the user to get the weather forecast, Google Maps driving directions, and much more, all through simple SMS commands. We even threw in some natural language processing magic, making the the final product much more intuitive to use.
What was even better was that we still had a couple of hours left before the project submission deadline, meaning we had time to check our product for any bugs that could jeopardize the demo. We also got a chance to check out some of the other engineering buildings and spend time networking with other hackers.
When it was finally time to submit our hack, we realized we needed a cool, spiffy, name. We decided to translate the word “everyone” to Latin.
We decided to translate “everyone”, mainly because we hoped that our app would empower anyone who had a phone, regardless of whether their phone had a data connection or not, to listen to music. We decided to translate to Latin mainly because we were extremely sleep deprived, and at the time it seemed cool. We also modified the word “omnes” a bit, and changed it to “omnus”, as we thought it sounded and looked cooler.
After an exhausting, yet inspiring 36 hours of non-stop hacking, it was finally time to show off our hack to the judges. It was a great experience, as we got to tell people our story about what had happened the past 36 hours: Our failures, our successes, and our learning experiences. Personally, I feel that the story of why a hack is made and how it was made is just as important when demoing the hack itself.
I also learned something very important while presenting at the expo:
Anything that can go wrong, will go wrong.
As you have probably already noticed, this has been apparent throughout the hackathon. We had some major pitfalls throughout the event, and even when we thought we had battle-tested our hack, something still went wrong. In our case, our weather API started to fail. Luckily, it failed silently, and did not spit out any large error messages that the person looking at our hack could see. Also, we realized that the API we were using to handle the natural language processing side of things occasionally failed, however, we were able to fix these problems without the user knowing by restarting the server while they were asking questions.
I also learned that freaking out about things breaking is not going to help your case. Freaking out just makes whoever is looking at your hack more aware that there is something wrong with your code. This was especially apparent with the team of hackers demoing next to our booth, as their virtual reality headset suddenly lost power and would not turn back on.
All in all, we were proud of our hack, but we were certain that it wasn’t the next Spotify, WhatsApp, or Flappy Bird. Despite the fact that it wasn’t going to be the next multibillion dollar invention, it was definitely a great learning experience. We even open sourced the project so other people could check out what we had built: https://github.com/tejasmanohar/omnus
Overall, the MHacks experience was amazing. It gave me a bigger picture of what the collegiate hackathon scene looks like, and really proved to me that anyone, regardless of their coding experience, can build something awesome, or at the very least, leave with a great story to tell.