Stamford Hackathon 3.0
I attend hackathons to get out of my comfort zone from my day job as a full stack Rails developer. In much the same way I attend the Software Craftsmanship Meetup to practice new programming paradigms, I go to hackathons to learn new APIs and what is going on in the industry by meeting sponsors, other participants, build a small app, and to have fun.
The Result: TrippAR
At the end, Alex and I teamed up, stayed the whole time and we made “TrippAR” - an augmented reality app to explore a city. TrippAR was built using: Blippar, scriptr, Pitney Bowes, and uber’s APIs and tools. If you want to check it out, do this:
You can try out TrippAR by:
- Download the BlippAR App to your phone:
- Open settings in side menu
- Enter code:
- Point Blippar at this photo
This is the result you should see on BlippAR.
The rest of the article will focus on the process we took and also some other thoughts around hackathons.
Hackathon Idea Process
Alex and I teamed up but we really didn’t decide on anything to work on until it was really late, like really late. There was so much new stuff, people, possibilities and honestly, I had no idea about what to do. There were sponsors attending from:
- IBM Bluemix
- Pitney Bowes
The only thing certain was that Alex loved playing around with Blippar. I played around with scriptr and started to get a handle on its capabilities.
Meeting Other Developers
After playing around with APIs, we went around meeting other developers and seeing what they were doing. Some of the other teams there and what they built:
- Train Stream - a multi-modal transportation search engine
- City Fund - a project to get public works funded through crowd sourcing
- No app AR - a project to get augmented reality through a web browser using open tools and platforms without an app.
- MAVE - a project to augment bus stops with the current schedule
- Team AI - a project to have a chat bot which has local info
- Team of 1 - a project to use tensorflow to develop natural scenes
Staying the Night
I stay the whole time for a hackathon, even over night. It does a few things for me:
- it forces me to make something fast
- I can meet other developers who stay the whole time
The first one, as the night goes on, I get tired and cut down the scope. If I had an idea, I start to reduce it down to something I can make with what is available in the easiest way. “Just get something working!” is my mantra and for me, things become more hacky as the night goes on.
For the second one, I find the developers that stay are also the most interesting. They have something to work on or will get something done. I have met some great developers from staying overnight and also made some great friends. Developers that hack together all night can work together.
I have been really burned before when going into a hackathon with a grand idea of what to build (with no concrete method of how to build it.) At the same time, there are so many other variables at a hackathon: fun time, getting stuck, food, helping others, etc. that any plans I have, it’s changed.
Series of Challenges
Now my hackathon development style is to build an app through working on a series of challenges. No concrete idea, just a vague glimpse of something. Does one API seem more interesting than another? Start there and see what it can do.
- Solve one problem
- Explore solution
- Decide on next problem to solve.
Basically, continuously build a minimum viable product.
The series of problems we worked on for this hackathon:
- getting network request out of Blippar
- Blippar only allowing HTTPS
- header authentication for scriptr
- Sending response back that Blippar can understand/parse
- Hook into Pitney Bowes from scriptr
- Hook into Uber from scriptr
- Looping http callbacks
- Deep linking
- Watson text to speech
The only one we couldn’t solve was getting Watson reading text inside Blippar. At the beginning of the hackathon I was interested in spending time hacking on Watson. Only in the last two hours before finishing our hack that I even looked at IBM Bluemix documentation. This was really an “icing on the cake” kind of feature. We time boxed this feature and cut it when we ran out of time.
I find it is really important to find a way to also have fun in a hackathon, not just build an app (otherwise, a hackathon will be a weekend job!)
One way to have fun at a hackathon is to play with all the toys there. This hackathon had the best toys I’ve seen at a hackathon so far: HTC Vive and Microsoft Hololens.
We had a blast playing around with both. HTC vive is definitely very good. The trials of tattoonie is a game changer for VR. It really brings the Star Wars universe to life.
I am definitely impressed with hololens. It’s way better than I expected and it’s one of those things to be experienced.
Every time we got “stuck” during the hackathon, we took a VR or hololens break. We got “stuck” a lot that night…
Hackathons are really a show and tell for programmers.
- Show working tech
- Tell how tech solves a problem
One trap I have fallen for is doing too much of either one:
- Showing too much tech without explaining what problem it solves
- Telling too much about how a tech solves a problem without any solutions
The trick is to balance both in an interesting way that not only your peers would be impressed with, but your parents too.
Only two hours before we presented, we decided on a name for our “hack”: TrippAR - a play on Blippar and trip.
Instead of telling everyone about the technical problems we solved, Alex explained how TrippAR made traveling fun by having interesting data overlaid monuments around Stamford, listing interesting spots in the area from Pitney Bowes’ API, show how much an Uber would cost to goto those spots, and being able to call an Uber right from the view in Blippar to goto those spots.
Result and Code
Alex and I had a lot of fun and worked hard. Total amount of code written for TrippAR is less than 200 lines (but there was so many more in the process!)
The code can be accessed here: https://github.com/a-leung/TrippAR
Some thoughts on each tech I used:
Now I am in really sold. Scriptr provided so much standard web server features that I really didn’t need to have all the other stuff I’m used to in Rails and will use Scriptr for future hacks.
Some things I wish Scriptr had:
- I miss emacs a lot when I code. More emacs keys to navigate around text
- The Scriptr editor had a “dark mode” to code in
- Scriptr’s IDE working in safari for iPad or iPhone.
- A way to see failing requests
For the last point, we got stuck on getting an authenticated call from Blippar to scriptr. This was mostly due to how Blippar sets up the header info.
A straight forward API. One gotcha I ran into: GPS coordinates length matter! 40,-73 returned no results for a places search, but 40.12345, -73.4567 returned a list of results.
Also a straight forward API. I wished deep links worked more consistently between platforms but I understand going from a web link to the app is tricky.
Getting basic text to speech setup is very convoluted. Wish the documentation outlined an easier way to get started with the basics.
The Stamford Hackathon 3.0 was a blast. I got to work with a great developer to make a fun app, played with HTC vive and microsoft’s hololens, and get hands on with Scriptr.io, Pitney Bowes, Uber, and IBM Bluemix tools and APIs. These are tools which I will feel comfortable using on a project.
If you have a weekend, I highly recommend doing a hackathon. As a programmer, it’s another great way to stay sharp in the world we work in.