So, you want to win a hackathon?

In the past 3 years I’ve taken part in 11 hackathons. Of these, I’ve won 4 and have reached the finals in 2. Here are a few things that I’ve observed that I feel should increase your chances of winning a hackathon:

Cool tech does not always equate to a cool product: Regardless of how awesome your tech is, if you don’t have a great product you’re probably not going to win. Use the clever algorithm you came up with or the sweet new tech stack you’ve invented in a product or application that other people can use and love. For example:

DON’T do this: We solved the P v.s. NP problem and then solved the graph coloring problem.

DO this: We solved the P v.s. NP problem and used that to create an application that determines which of your friends you are most likely to start a company with by finding a solution to the graph coloring problem.

That was a pretty bad example, but hopefully I was able to get my point across.

Respect the demo: The demo is the most important part of a hackathon. This is where you convince the judges, in 2 or 3 minutes, that you spent the last 18 to 24 hours creating a product that is the best thing since sliced bread. Make sure you practice what you’re going to be showing the judges! Having a well thought out demo is key to winning a hackathon. Focus on the main features of your product, why it is awesome and why people would want to use it. Since time is limited try to show the most important and/or impressive features of your application.

Did I mention you should PRACTICE, PRACTICE, PRACTICE your demo?

Don’t be afraid to ask for help: Most hackathons have employees (of the company organizing the hackathon) being present during the event as mentors for the competing teams. Don’t be afraid to ask them for help. These employees are an excellent source of knowledge and you should always reach out to them anytime you’re stuck on a nasty bug, can’t figure out how to use a new technology or library etc. Since hackathons give you limited time to work on your product it makes sense to get rid of roadblocks quickly. Of course, make sure you spend some time trying to solve your problem on your own first before turning to the mentors for help.

Try to make your product look pretty: Having a product that is polished and looks good is key to winning a hackathon in my opinion. Make sure you allocate some time to work on the UI and UX of your product. If your team lacks someone with design skills, or you’re simply running short on time, use something like Twitter Bootstrap or jQuery UI to add polish to your application.

Again, these are just my personal observations and opinions. Adhering to them in no way guarantees you a win.

Testing Async Functions with Jasmine

Sam and I have been using Jasmine as our Javascript testing library for our Software Engineering project, mainly because I’ve used QUnit in the past and wanted to try something new. It also makes the tests in our group seem “uniform” in that Jasmine tests look a lot like RSpec, which is what the Rails team on our project is using. Our application has a RESTful Rails backend and a frontend written in Backbone.

We have a function in our Backbone view that calls a function on our Backbone model. The Backbone model talks to our RESTful backend and based on the response triggers the “success” or “error” callback functions provided by the view. Here is the pattern that we used to test this function:

 

Running Fabric tasks in parallel based on roles

We’ve been using Fabric to set up and build Gelato on AWS. Each time I use it I’m left with this sense of awe at how amazing it is. Going from having to manually SSH into each machine to do anything to have Fabric build your code on 15 machines in parallel is indescribable.

One thing that we were having trouble with was having Fabric run a task on specific host roles in parallel. To run tasks in parallel you use the @parallel decorator, while to run tasks on hosts by roles you use the @roles decorator. If you want to run tasks in parallel on specific hosts you have to be careful of the order in which you apply these decorators. Here is what worked for us:

P.S. make sure you set the correct Bubble Size if you have a large number of hosts!

Gelato Tech Stack

For our Advanced Distributed Systems (CS 525) final project Onur and I are working on a system we’ve named Gelato. I will have more details about it in a month when we (hopefully) open source our code. Our tech stack for Gelato looks something like this:

We were deciding between Cassandra and HBase and decided to use HBase because HBase has a native Java API and is pretty easy to use on AWS thanks to AWS EMR.

The languages we are using are:

  • Java for the core Gelato system
  • Python to gather performance metrics

Gelato is pretty the most complex system I’ve built during college and I’m really excited to see how it finally turns out.

2012: Year in review

2012 was a great year for me for 3 reasons:

  1. The world didn’t end.
  2. 4 Hackathon victories: 3rd prize at Greylock, an award at an internal hackday at LinkedIn, 1st prize at the Facebook Hackathon at UIUC and 2nd prize at the Facebook Hackathon finals. We were also one of the finalists for the LinkedIn Intern Hackday 2012.I worked with Sam and Onur on all the hackathons apart from the LinkedIn internal hackday for which I worked with my awesome mentor Jim.I also love how our Computer Vision technology evolved over time for each hack: we started with object tracking using colors (we wore  colored socks on our hands for dance()), next we were able to pull of object tracking within a bounded region (we were able to track a finger in ABSees) and finally for StreetCoders we were able to have a system that didn’t require colored socks or a bounded region!

    I’m extremely proud of what Sam, Onur and I achieved and it was great working with them.

    What didn’t improve though was the quality of our Javascript code :( . Each of our hackathon projects started with us working on the computer vision first. This usually took the most time. Once we were pretty confident that our computer vision components worked locally (no images coming over the network), we started working on the Javascript portions of the code that actually talked to the computer vision servers. It was also at this point that we used to realize that we have 10-12 hours to build a majority of our application. This scramble to the finish line usually ended up with us having Javascript code that is functional but littered with code smells. Our overall tiredness towards the end didn’t help either. Oh well.

  3. I got an opportunity to intern at an awesome company. My Summer at LinkedIn was phenomenal.
  4. There was a new addition to my family.my dog

Looking forward to a great 2013.

Ciao!

I realized that I haven’t blogged in quite some time. My blog posts on Summer 12, which were to be a two part post, stands with only one part on my blog and the other part in my head. I’ll get to it eventually, maybe during Thanksgiving Break.

I think the main reason I haven’t had the time to blog is because of my 18 credit hours workload this semester. The last time I’d taken 18 hours was during first semester freshman year and the classes were nowhere near as hard :)

I’m not complaining though: the level of the classes I’m in this semester is absolutely fantastic. I think my favorite class right now is Distributed Systems (CS 425). It’s something that I’ve been interested in for quite some time and learning about the various algorithms, concepts and existing systems has been excellent. The coding assignments in this class are great too. So far I’ve worked on a distributed log querying system and a group membership system with failure detection and no SPOF. I’m pretty excited for my next assignment which involves building a simplified version of HDFS. My Java skills improved by leaps and bounds this Summer at LinkedIn, and this class is only making me better. I’ve had a chance to work with Futures, Timers and lots of Threads. Designing a system from the ground up and having it work is an extremely rewarding experience. 

Natural Language Processing (CS 498) is pretty awesome too. All the concepts I’ve learnt in that class so far seem intuitive and the math seen so far (mostly probability) isn’t too bad. Plus, the coding assignments are in Python :D .

Machine Learning (CS 446) is definitely my hardest class. The concepts are much more involved than my other classes and the math is much harder. But the feeling you get when you tweak a few parameters of your algorithm and watch the accuracy jump up 10% cannot be described. Even though it’s a really hard class, it’s also a great class and I would recommend anyone to take it. We’ve gone over some really interesting stuff so far (Perceptrons, PAC, SGD, Kernels etc.) and there’s a lot more cool stuff left for the rest of the semester. 

My other classes, namely Ethics, Software Engineering and Italian are also really good. 

Overall though, with all the work from these classes, I really don’t have time for anything else apart from school work. In other (maybe related) news, coffee is now my new best friend.