Just another Saturday – Office Hackathon at Axiom Zen

Internal hackathon this weekend at Axiom Zen. The theme is office hacks and we’re building:

1. a ping-pong score and stats tracker (inspired by Si digital) using iBeacons for player identification and capacitive touch for scoring
2. bathroom status indicator
3. GitHub pull request tracker – determines stats for how many pull requests for a given repo were merged without review/comment

Today I worked a little bit on the ping-pong scorer, looking at the basics of the Spark – a micro-controller that works and is flashed/re-programmed over WiFi. Very cool (even for someone who doesn’t know much about hardware).

In the afternoon, I moved over to look at the GitHub pull request tracker and worked on scaffolding a basic Node.js and Express app using Mongoose and MongoDB.

Oh, and most importantly, I got to play the new Super Smash Bros. on the office Wii U. A good Saturday then.

I went to Vegas and lost (I think)

To keep up with the hackathon-ing theme, I spent the weekend before last at another hackathon – Money 20/20 – but this one was  a little different since it was open to professionals and students. Oh, and it was in Las Vegas! Talk about a great location! Money 20/20 is the biggest tech finance conference in the world(?), bringing in delegates and speakers to talk about the latest trends in the industry from Bitcoin to Apple Pay. This year they ran a hackathon the weekend before the conference and booked a fantastic space for hackers to attend at minimal cost – $10 – at the Aria hotel. Being a finance based hackathon, and in Vegas on top of that, meant that there were some crazy cash prizes up for grabs. USD 20k prizes for the top 5 teams, 5k prizes for another 5 teams after that and sponsor API prizes as well e.g. 15 Bitcoin!

The company I’m interning for, Axiom Zen, sent out an email a few weeks before the hackathon to ask if anyone was interested in attending and pretty quickly, we had a group of 10 hackers representing – one team of 5 (the max size) developing a time tracking and invoicing app for contractors (Hour Flow), a team of three developing an all-in rapid trading Bitcoin mobile app (BitBuyBit) , and a team of two (which I was in) developing an API for game developers to integrate Bitcoin powered competitions (Propane).

Axiom Zen took care of booking our flight tickets and accommodation for the night before the hackathon, and so all we had to do was plan and come up with ideas that used the sponsor APIs (a rule of the hackathon). I’d like to think the ideas above sound pretty interesting, and it definitely took some coming up with them – for the team I was in at least. My partner is one of the front-end engineers I work a lot with at Axiom Zen, which worked out well since my skills have (until recently) been focused on the back-end and with only two people and a 24 hour hackathon, there isn’t too much time to pick up new technologies!

Neither of us were super familiar with Bitcoin – which two of the sponsor APIs were based on – and the other sponsor APIs ,which were payment based, didn’t particularly inspire us since they seemed to emphasize design rather than any novel tech. But hey, Bitcoin is the topic of the moment so after at trip to a Bitcoin ATM in downtown Vancouver (Bitcoin is surprisingly hard to buy), we were good to go with our Bitcoin powered API for game competitions idea.

 

First Impressions and Tech

We turned up the night before the hackathon and spent it off the strip at a huge house that one of the founders at Axiom Zen found for us, but since it was Friday and Halloween, getting a cab back to the Strip was a little harder than we though – hour and a half wait, anyone? – and so we spent the night in and got some pizza.

And this was just the airport…

The morning of the hackathon, we all headed off to the Aria hotel and well, if you’ve never been to Vegas, it is some place. Everything is done on an excessive scale. Paris has the Eiffel Tower, well so does Vegas. Egypt has a pyramid, well so does Vegas. You get the idea. The hackathon was held in one of the conference rooms in the Aria and it was pretty epic. It was the best organized and well catered event that I’ve ever been to. Meals were buffet style and there was a range of sodas that was restocked throughout the day and night.

Who needs to travel to see the sights when you can go to Vegas

My team ended up building our app in Rails for the backend and Angular running on Node for the front-end. We had different backends since that let us keep things pretty self-contained which enabled us to work independently of each other. I used Rails for the same reason I’ve always done, it’s fast to prototype things and it’s the backend language I know best. Would another tool like Node have been more suitable – yes, and I’ve made a pact that I’m using Node for the next hackathon I go to (as I write this, I’ve now picked up enough Node skills to get by with at a hackathon). Saying that, after using Rails for the last couple of hackathons I’ve been to, building up the API for our product wasn’t too challenging. The hardest part was having the sponsor API we were using go down in the last few hours before submission and making changes to the database schema while sleep deprived.

Never mind, it was all over pretty quickly. Work had been really busy in the week leading up to the hackathon and so this was definitely the hackathon I was most tired at – I was sleep drunk by 1am. I’m still not sure if I’m glad that the clocks went back with the end of daylight saving – on one hand we got an extra hour of hacking, and on the other, well, we got another hour of hacking. It probably worked out for the best since the sponsor’s API went down towards the end and we were getting 500 errors up until the last 30 seconds before hacking finished – couldn’t figure out if it was the sponsor’s API or us for a long time. Anyway, onto the judging.

 

Judging

Judging happened in two phases. In the first phase, teams pitched to a rep – normally a CEO/CTO or some other senior officer – of the API sponsor. Two to three teams were then selected from the 9 sponsors to move onto the next round where they would have 2 minutes to pitch their product on stage to a panel of judges composed of the judges in the first phase.

Getting ready for the judging

Two of the teams from Axiom Zen team made it through to the next round – the team working on the time management/invoicing app and also the team I was on. The team building the quick buy/sell Bitcoin were really unlucky not to have made it through. The fact that they were literally the last team out of 100+ teams to pitch in the first round made it hard to make an impression when all the judges wanted to do was move onto the next phase (we were behind schedule as always seems to happen at hackathons) and also, their idea was stunningly and beautiful simple – which I think judges may have held against them. If that didn’t quite make sense, let me put it this way – although it’s not quite the same (since the Bitcoin buying/selling app was much more complex and valuable), an app like Yo would never win a hackathon and yet, everyone in the tech industry knows it!

The team that made the time management app were one of the first few finalists up on stage to pitch and they were great. It was an amazing pitch. It helped a lot that one of them was the guy who I won Hack the North with a month or two ago – he pitched then too! They definitely benefited from having finished working on their app early during the hackathon – an hour or two before the end – and were able to practice their pitch beforehand. In contrast, I ended up pitching our app on stage while trying to figure out what to say just in the moments leading up to it – and… well, I ended up fumbling on stage. It was pretty painful.

I had the first few sentences of my pitch memorized but once I deviated from those, well, I just got lost. Think long awkward pauses and the camera guy hissing at me. I guess when you memorize something, you don’t really have a train of thought and that makes it really hard to adapt to changes or a missed line/word.

 

The aftermath

It took me more than a week to finish this post because I was pretty disappointed at costing my team a prize – we didn’t place and I feel pretty confident in saying that our hack was better than some which did. But I guess that’s life. You live and learn. It was pretty cool though that the other finalist team from Axiom Zen picked up a 20k prize!

After lots of thinking this past week, the three points I’m taking away from this hackathon are:

1) Fatigue is debilitating and it can be hard for you to realize that in the moment

2) Don’t try to memorize a speech since you’re at risk of not following your own train of thought and you’ll be unable to adapt with even the slightest change in environment/presentation

3) When it comes to competitions and maybe investments, a good pitch is better than a good app. You need to communicate what you’ve done or even what you will do (some hackathon can be bits of cardboard stuck together but if you can sell that…)

Above all, is to keep on trying. What is it they say about falling down 8 times and getting up 9.

I spent a little while after the hackathon recovering and feeling sorry for myself (and for my partner too for messing things up!) but by Monday night, I figured the best way to deal with it was to get back on the horse again , and so I started learning Node. And a few days later, registered to participate at Startup Weekend Vancouver – a weekend where the idea is to create an MVP and startup in just a few days. That’s this weekend and I figure it’ll give me a chance to apply what I’ve learned about Node and maybe about delivering a good pitch as well.

So yeah, keeping busy and moving forward is probably my way of dealing with my slip up at Money 20/20. At the end of the day, my team did well to make it to the finals, and it was definitely good experience getting the chance to pitch in front of lots of people – better to lose $20k than $200k, or maybe even $2m(?). You never know where this crazy tech stuff will lead. And just like Vegas, I think that’s what keeps it exciting.

 

 

Three things I learned from DubHacks

A week ago, I participated in DubHacks, a student hackathon at the University of Washington, building a live polling app on my own. Just after the event, I was feeling pretty positive about the experience but it was probably only over the next few days, once I’d showed the app to a couple of people and paid my sleep debt, that I realized there were a couple more concrete things I’d learned from participating in the event and which are important enough to warrant a blog post:

1) I’m still not a designer – don’t use more than two fonts on a page

After showing the app to a couple of people at work, the designers pointed out quite clearly that I’d made the very obvious (to them at least) mistake of using more than two fonts. That’s a generally a design/visual faux pas, multiple fonts can work depending on the circumstances, but a good rule of thumb which I didn’t know before is to keep it to two fonts and use size and weights to add hierarchy

2) Over-optimization is just plain silly – trust the tech

In my last blog post, I said that I wanted to get some feedback from other engineers at Axiom Zen where I’m interning to find out how better to structure my database in the future. After talking to them, I realized very quickly that I most definitely over-optimized – trying to bend over backwards to structure my tables in a way which would help solve efficiency/optimization problems that didn’t exist. I made the mistake of not trusting the technology to do what it was good at – in this case, PostgreSQL, which is great at doing joins and lookups efficiently even when records go up into the thousands (or ten thousands?).

3) No one cares how you did it, just that you did

This is probably a good reminder more than anything. I went to the hackathon liking the romance of doing something completely on my own but as it turns out, no one really cares how you did it, just that you did. And by that, I mean all that users care about is what you put in their hands. They don’t care about your drama, that you lived in a jungle for a year to accomplish it or any of that jazz. Make it good and they’ll be happy.

For the most part, and definitely never in time pressure situations, going it alone is just stupid. If you’re doing it just because that’s fun and fine. If you’re trying to build a product that will have real value, go get a team.

 

 

Another weekend, another hackathon – DubHacks 2014

Coding has well and truly become a part of my life! I spend my weekdays coding at Axiom Zen as an intern and my weekends either reading up on new tech/languages or heading out to hackathons. How much has changed in a year. I think I used to watch Netflix on the weekends…

It’s Sunday morning and I’ve just gotten back from another student hackathon, DubHacks, which was hosted over 24 hours at the University of Washington in Seattle. It was their first time hosting the event and while there were some growing pains (having dinner at the same time the hacking starts is never a good idea), it was great to see how the movement for student hackers is progressing.

The event was a lot less diverse than Hack the North a month or so ago since DubHacks was a lot smaller, maybe around 300 hackers, and there was only a little money for travel reimbursements. Luckily Seattle is a lot closer to Vancouver than Waterloo, so it was just a 4 hour bus ride. That might seem long by European standards but definitely not in North America!

Hackers Representing

I went down with a couple of other students from UBC, most of whom I didn’t know before but we had a good old time. I decided to work on a project that I’d been thinking about for a long time but never gotten around to – an app for conducting live polling of an audience. The idea is to have students in a lecture/class or attendees at a conference/presentation answer questions in real-time, thereby keeping them engaged and providing valuable feedback for the speaker to respond to, perhaps diving into an area of identified misunderstanding that needs to be clarified.

If you’re thinking that this would be a problem well solved by something like Node.js which is great for real-time apps, you’d be right. Unfortunately, I’ve been a bit behind on the learning Node front since I’ve moved onto working on front-end dev at work, which meant picking up Angular over the last few weekends. But c’est la vie. I used Rails and jQuery instead since the hackathon was a short one and I wanted to be able to code as much as possible, rather than reading docs (inevitable as it is).

For the real-time functionality, I used Pusher which delivered the messages between server and client – a big thank you to them for providing me with a free upgraded account for the weekend! They made it super easy to integrate with my Rails server and JavaScript front-end.

One other thing to add is that I ended up flying solo for the event.

I decided to work on my own at DubHacks because I thought it’d be a kind of fun endurance challenge (I managed 33 hours without sleep!) to see how much I could build on my own – plus some of my friends couldn’t make the event. I figured it would be a nice change from collaborative coding which while vital to getting things done in the real world, necessarily involves not coding a lot of the time. Don’t get me wrong, working in a team is essential but there’s something fun about being the decision maker and executor. It can be fun to live and die by your own sword – or to put it another way, I just wanted to see what I was made off. Skills I need to continue working on would become more glaringly obvious and help me figure out what to concentrate on the next few months.

For the most part, I pulled it off. My main weakness in web development continues to be design and that’s ok – I’m an engineer after all – on the coding front, my front-end skills are still not at the same level as my back-end but it was nice to see that things are coming along. The app I made doesn’t look half bad at all. The downside was that spending so much time on the front-end and design meant a few bugs in the finally demo-ed app. Super frustrating since I fixed all of them this afternoon (after the hackathon) in an hour, but when you’re sleep-deprived it is hard to think of manual test cases and spot the stupid bugs. I also need to learn more about database design, I think that’s probably something that is hard to from a book and is mostly learned from experience in the real-world. I’m definitely going to ask my co-workers at Axiom Zen how they would have designed the database for my app and see what design decisions I can improve on in the future.

I didn’t win a prize at this event which was disappointing (who doesn’t like being competitive!) but not surprising now that I think about it. My app had small but obvious bugs that took away from the end-product, and wasn’t novel enough to warrant attention amongst the hardware hacks and distributed prime number finders at the event 🙂

Winners of hackathons, I’ve realized, tend to build projects that are technically novel – that would impress other hackers – and while they need to solve a problem, it is not essential to for the problem to be a particularly painful one or for the solution to be readily adoptable. It’s a hackathon not a product-thon if that makes sense. It has to have some value but building cool stuff for its own sake deserves a lot of respect as well. Some of the winners used a Myo, Google Glass and Oculus to control a robot and be able to see the visuals via Skype. Pretty cool.

One other thing I’ve been reminded of at DubHacks is that there is no need to build the core tech itself, at least not at student hackathons. For example, the grand prize winning team didn’t need to build or understand the complexities of the speed reading api that they exported to multiple clients/platforms, it was enough that they got it to work and could put something in the judges’ hands and say, hey this is some cool stuff. Winning Hack the North a month ago, was like that too. We solved a problem using a complex API that neither of us understood (hey, it’s an NP complete problem!) but still created something that was cool.

Good thing the Space Needle is tall and near the bus stop – there wouldn’t have been any sightseeing otherwise!

So what next?

Well, after building a prototype of my live polling application at DubHacks, I still think the problem it tries to solve exists and is one that needs a good/better solution, and so I’m planning to continue developing my live polling app over the next few weeks. It will need to be a complete re-write since the Rails app I made is some of the least DRY (so wet?) code I’ve written in a long time – the number of random script tags and !important CSS tags would be embarrassing in the real world, but hey it’s a hackathon app!

So yeah, definitely going to use it as an excuse, if I needed one, to learn Node and to come up with something more robust. It’s annoying to have to use a technology stack you know is ill-suited to the problem because you don’t quite yet know the alternative. Inspiration to continue learning then. Always keep on learning.

Oh, and here’s the app I built (plus an hour of post-hackathon tidying up of the most obvious styling issues and bugs).

LivePoll – I’m definitely getting better at this design thing

Hack the North

This time last weekend, I was on the other side of Canada in Waterloo, ON, hacking away. Maybe it has something to do with the distance traveled to get there, but it seems like a long time ago. I almost feel like I’m moving backward taking this weekend easy (and by easy, I mean getting more than 6 hours of sleep total from Friday to Sunday).

Hack the North is Canada’s largest student hackathon and this year’s inaugural event held last weekend had about 1000 students attending from countries all across the world. Generous sponsorship meant flight tickets were significantly reimbursed 80%+ of the cost, and so students from as far away as Amsterdam and Shanghai were in attendance.

There wasn’t any specific theme to the event, other than to build something cool that worked – no one said as much but I surmise that’s the aim of every hackathon. Lots of cool hardware was available to work on as well, from Myos to Pebbles and Oculus Rifts.

Getting to the event from Vancouver was an event in itself, a crazy early start, then waiting at the airport on the other side for the shuttle to Waterloo, and then the trip on the shuttle itself. Who knew that the traffic in Toronto, where everyone flies into, would be so bad.

There was a little dinner left when we arrived and then we got to hear some amazing speakers open the event. We had Chamath Palihapitiya who was formerly in charge of growth at Facebook and is now in VC, starting the fund The Social+Capital Partnership  He spoke about startups and gave realistic advice about what life in tech is like. Chamath was extremely confident and charismatic, and it’s easy to say that he is one of the best orators I’ve ever heard. Check out his talk here (the video is still not up but I’ll update this post when it is!).

The hacking started at midnight and my friend Daniel and I got to work building a travel optimization app. It uses Yelp’s API to get a list of attractions in a city and Routific’s routing optimization API to provide an efficient route to visit the attractions in a single day if one exists. A quick way for tourists to determine how much they can get the most bang for their buck on their vacation.

There were chips and soda aplenty to keep people powered through the event, and there was even a small sleeping area. Unfortunately the sleeping area wasn’t really too well organized, it was brightly lit and far too small so I guess they didn’t expect many hackers to sleep much during the event. Daniel and I ended up finding chairs in a random room on the Waterloo Campus on Saturday morning for a couple of hours of sleep.

Saturday night/Sunday morning was probably the most interesting. People were definitely starting to feel the burn by that point and this was the scene at 4am

Every team got a chance to pitch their app in 100 seconds in front of a selected group of the judges, so there was definitely something to aim for during the hackathon. It’s all a bit of a blur but I spent most of Sunday morning trying to finalize the general flow and look of the app – I am definitely not a designer.

In terms of the stack, we built our app using Angular and had a Rails back-end for interfacing with the various APIs. Neither of us had used Angular before so that definitely made the hackathon interesting to say the least. We figured if you can’t try out some new tech in a hackathon, when else can you!

One of the things we found is that Angular, a JavaScript front end framework, is very domineering. You either use it completely for the front end, or prepare for some unexpected behavior if you try to mix in some regular JavaScript in there. We definitely ended up finding ourselves in the latter position, as we moved to get things working even if that meant doing things in less than the Angular way.

Another thing I learned this weekend was about OAuth, an authentication protocol which we used to communicate with the Yelp API. Since it uses tokens and secret keys, it wasn’t possible to have just a front end, we needed a back-end as well to prevent exposing our keys. This is different from something like the Google Maps API which we used as a map and for geocoding in our app (since Yelp doesn’t always return an attraction’s latitude and longitude) where client exposed keys are OK.

By the time hacking stopped at 10am, I’d been up for more than 24 hours, with little sleep before that period(!), so I managed to get a quick nap before we pitched in front of the judges.

Our app lacked the design polish of other teams, but the judges found our app pretty interesting, as did the engineers from Yelp who we pitched to separately (main prize vs API specific prizes basically). I thought we did decently for a team of two who were using a different stack than normal and it was great to find out later that Yelp had awarded us the prize for best app to use their API at the event!

We are getting 4 leap motions between the two of us. I’ll make a post once those arrive in the mail! Definitely interested to see what can be done with the hardware. Hardware hacks are not something I’ve really explored before.

But yeah, what an experience. Daniel and I work at the same company as coop software engineers, Axiom Zen, and it was great that we got the Friday off to travel to the hackathon and that we got so much support from them. They were pretty stoked that we managed to bring home a prize as well, using an API from a company they are helping accelerate. It’s great to work somewhere which gets as excited about things like hackathons as you are.

So what next? Work is super busy, there’s always lots to do but I’m enjoying it – more on that soon. I saw some interesting apps built in Node.js at the hackathon so that’s on the agenda this weekend! I’ll post if I build anything half decent 🙂

And if you’re wondering how you can get involved in hackathons, ChallengePost is a great website to start off with. They list hackathons going on around the world, both offline and online.