Interview with Next Bus creator Gavin Schulz
Gavin Schulz (@GSMaverick) has developed a new app called Bus Ticker that solves the problem of conveniently figuring out when your next bus is coming using your smartphone. Gavin will launch Next Bus at DemoCampHamilton9 which is taking place tomorrow Tuesday November 20th from 6:30pm – 9:00pm in the Twelve Eighty pub, you can sign-up to attend free here. I interviewed Gavin about his Next Bus project, check it out below:
Tell me about yourself.
I’m a 4th year¬†Economics and Computer Science¬†student at McMaster University with a passion for¬†building great software (and startups!). ¬†I’ve built a number of open data applications in the past including SkateHamilton and Dowsing. ¬†I’m a life-long Hamilton resident and I mostly focus on building applications which make city services easier to access and use.
What is Next Bus?
Next Bus is the easiest way to get bus times in Hamilton on your smartphone. ¬†It aims to do one thing well: tell you how long until the next bus comes by.
Why did you decide to build Next Bus?
Mostly out of personal frustration. ¬†Being a frequent HSR passenger I’ve always found it a pain to find out when the next bus is coming by the stop I’m waiting at; from calling the HSR’s phone service to creating fake trips in Google Maps I always imagined there must be an quicker, easier way to accomplish the task. ¬†It took me quite a few years of thinking about it to finally turn my imagination into a real live, usable application. ¬†Aside from that I wanted to build another mobile web application to apply some new design ideas and programming techniques I’ve been developing in the last few months.
What tools did you use to build Next Bus?
Quite a few, what you imagine will be a pretty simple application ends up turning into a much larger project with more moving pieces than you thought. ¬†On the front-end I’m using Zepto.js (http://zeptojs.com/), a jQuery equivalent for¬†mobile browsers, Backbone.js (http://backbonejs.org/), my favourite front-end framework, SASS (http://sass-lang.com/) and Mixpanel (http://mixpanel.com/), to get deep insights into how users are using Next Bus. ¬†On the server I’m using Flask (http://flask.pocoo.org/), a Python microframework that gets out of your way, PostgreSQL (http://www.postgresql.org/), which I’m talking to via SQLAlchemy (http://www.sqlalchemy.org/) and Twilio (http://www.twilio.com/), to power the “Send to Phone” button on the homepage. ¬†All this is deployed on Heroku!
What challenges have you faced?
The first challenge was designing the application in a way that made stop times easy to digest and quick to find. ¬†My goal was to be faster than the HSR’s phone service and Google Maps so I had to come up with interesting ways to present the stop times and bus routes in order to meet this goal. ¬†Another challenge I faced was representing the data set in such a way that it was easy to query and quick to return a result. ¬†There are more than 2000 stops in Hamilton and combine that with different schedules for different days and you end up with a set of 250k+ possible stop times. ¬†I ended up doing a fair amount of pre-processing to get the data into a format that was optimized for answering the style of queries Next Bus uses. ¬†One more challenge that I’ll touch on was deployment. ¬†This is the first project I’ve used a niche framework for and this led to a lot of issues that wouldn’t normally arise if I was using Rails or Django. ¬†Since using the big frameworks is the common case the process is optimized and works very flawlessly but with more niche frameworks, like Flask, you have to do more of the work yourself. ¬†I chose Flask mostly because I liked its ideas about how to build a web application but in return I had to do a little more work on deployment. ¬†If you follow the Next Bus blog (http://blog.bustickerapp.com ) you can get more in-depth details about these challenges over the next few weeks.
What future plans do you have for Next Bus?
I have a bunch of ideas about structuring the data in a way that makes finding stop times quicker that I just haven’t had time to fully explore. ¬†That is just one of a number of backend changes I have in mind to make responses more helpful and response times faster. ¬†From the perspective of what users will see I don’t have a big list of new features at the moment, instead I’m waiting to see how people use it and gather feedback from them about where they want to see Next Bus go next. ¬†Overall I hope that Next Bus will be a useful app for many HSR commuters and make someone’s life just a little bit better!
What advice would you give developers looking to build similar projects?
Start small. ¬†I’ve had a lot of great ideas for applications that were pretty complicated and quite grand but it turns out the applications that I actually see all the way through to completion were simple, well executed ideas instead of some grand vision. ¬†Building small applications lets you get the reward of creation and the feeling of being done something much quicker which can motivate you to continue to building and even take on bigger projects. ¬†Starting with big projects can lead to disappointment and a feeling of being overwhelmed by the amount of work ahead of you.
Solve a problem. ¬†I’ve never had much luck building an open-source library mostly because I don’t ever have a need for another library in my programming experience, it’s very hard to build something (especially as a side project) for someone else or to solve a problem you can’t relate to. ¬†Instead I’ve found that my best apps are those that solve a personal need or problem, I can relate very well to what a user wants out of the application and how well it is serving the user’s need. ¬†It’s also awesome to spot a problem, build your own app to solve that problem and then get the satisfaction of using your app every day; maybe you’ll even share it with others!