We sat down with Kieran Huggins, Rails junkie and coder extraordinaire to talk about MyTTC.
Refresh Events: Hey Kieran, thanks for sitting down with us. Tell us a bit more about MyTTC and why it’s so awesome.
Kieran Huggins: Hey, thanks for having us (again)! MyTTC is both a public transit trip planner, and an open repository of schedules, stop, station & route information for the TTC. The public website is aimed at transit riders who either want to find out how to get somewhere, or want to find a better alternative to their daily commutes.
You can use it to plan a trip between any two points in the city at any given time, and we’ll calculate what we determine to be your best route. The planner takes into account every vehicle in service, as well as every stop it makes along its route, and tries to give you the most balanced result in terms of travel time and the number of transfers you have to make. For instance, we assume you’d prefer taking one 40 minute bus ride than 3 separate buses that get you there in only 36 minutes. We call that the “pain-in-the-ass factor”, and try our best to keep yours to a minimum.
We provide directions as both plain English instructions and an interactive map. Each one has links to the key routes, stops, and stations in your journey to a page where you can find out more about your waypoints. Finch Station, for example, can be found here: http://myttc.ca/finch_station
We tried our best to make the site as easy to use as possible. For instance, all the URLs on the site are completely human-readable. There’s no funny characters or ID numbers, and no bizarre extensions. Whenever possible, we try to make the URLs guessable as well; if you wanted to find the page for the 97 Yonge, you could just type in myttc.ca/97_yonge – in fact, you could also use our secret “lazy version” and just type myttc.ca/97 – we’ll figure out what you mean.
Trip URLs are also fairly straight-forward: /travel/from/Dundas_and_Elizabeth/to/The_Drake_Hotel
If you plan a trip for a specific time, the URL reflects it thusly: /travel(...)/at/1:00pm or /travel(...)/by/8:45am/on/August_20_2009
If you leave out the time, every visit to that page will assume you plan to leave immediately. That way, you can bookmark trips you take often for easy, one-click reference.
You can also save your frequently used stops on your own custom front page – each saved stop will show you the next 3 departure times for every vehicle at that stop. I have one saved for home and another saved for work, so whenever I load myTTC it tells me how quickly I need to run out the door.
In addition to the public website, we also offer free, unlimited access to the data we’ve generated in one of three popular formats: The Google Transit Feed Specification (which many tools now read and write), SQL tables (for easy importing into your own application), and a web API that speaks both XML and JSON. With these, anyone can get started developing their own TTC-based application with right away, no matter what type of app they’re building nor which language or framework they happen to use.
In fact, we’ve already witnessed a series of projects and applications built with our data! The most notable of which is Red Rocket, an iPhone application that includes TTC schedules in a handy, user-friendly package.
RE: Why did you decide to create this?
KH: As with most software, it began as an exercise in laziness. I remember it was sometime in January of 2007, and I didn’t want to wait at the cold outdoor stop for the bus.
After the (then 9 year-old) TTC website had crashed my browser for the umpteenth time (it used lots of buggy Java code to play a door chime), I decided that I could write a cleaner, simpler website that displayed their schedules more succinctly. I thought to myself “probably wouldn’t take long… maybe a week?”. I’m optimistic like that.
A few weeks later I showed up in time (well, a little late) for the first TransitCamp at the Gladstone Hotel where I showed off the very little I’d managed to hack together to other transit-minded folks. I managed to pique a bit of interest among the crowd, and (fortunately) among them was Kevin Branigan.
Kevin and I proceeded to work on the application in our spare time over the next year, always upping the ante with new feature ideas and better, faster code. Kevin almost single-handedly went through millions of rows of data; mostly by writing software to do it on his behalf, but he also waded through a significant chunk by hand. Finally we had managed to build a complete, coherent dataset.
After all that pain, we made the decision to open-source the data so nobody would ever have to duplicate that tedious effort. Programmers have a particular distaste for repetition.
RE: Which language(s)/framework(s) were used to build this application, and why did you choose them?
KH: MyTTC is actually a collection of many languages and platforms. We’re big believers in using the right tool for the right job, and that often translates into many tools.
The website is almost entirely built with Ruby on the excellent Merb framework. We heart Ruby in a big way, and Merb spoke to us as developers for it’s straight-forward, stay-out-of-your-way philosophy. “All you need, nil you don’t.” Merb is every bit as succinct as its motto.
MyTTC was actually our first experience with Ruby, and we chose it in part out of curiosity, in part by recommendation, and finally, just to take Ruby for a spin. Regardless of the reasons, Ruby turned out to be a great decision in retrospect. Ruby’s elegance and simplicity really won us over.
We chose HAML and SASS for templates and stylesheets (respectively). Admittedly, we were initially a little biased (they were written by friends of ours) we found ourselves completely and impartially sold in about 5 minutes. So much so, we’ve since used both HAML and SASS in every project we’ve started; I never want to write plain old xhtml or css ever again.
On the back-end we went with MySQL behind DataMapper. We were both comfortable with MySQL (Kevin distinctly more-so than I), and DataMapper was an up-and-coming ORM at the time with an interesting approach which really appealed to me. In retrospect, DataMapper might have been a tad too young at the time. We ran into more than our share of buggy code, but as we matured as Rubyists so did it mature as an ORM. It’s now arguably one of the best ORMs out there, and we continue to prefer it as our weapon of choice for most apps.
It ended up being MySQL, which has been quite mature for a very long time, that became a serious performance bottleneck for us as the data increased in size. Eventually, we were forced to replace it with a custom daemon which Kevin wrote in C. Once that was in place, data-access performance ceased to be an issue altogether.
The current trip planner is also written in C as part of the Graphserver library by Brandon Martin-Anderson. Brandon was exceptionally helpful and patient with us as we integrated the then-new library into the site. Graphserver, while written in C, came with both Ruby and Python bindings. We opted for the Ruby bindings and it currently runs behind Webrick in an Ubuntu virtual machine, since it requires a almost prohibitively large amount of memory (in our case).
As excellent as Graphserver is, we eventually decided that we wanted to write our own engine that would support a broader feature set. Over the last year or so, we’ve been developing a new planning engine in a mixture of C, C++, and Objective C that will soon take the place of Graphserver in our little “digital menagerie”. The new planner (which we’ve dubbed “Iroquois”) is a fundamental re-imagining of conventional trip planning wisdom. Powered by a brand-new, self-conceived algorithm (k*), it’s rooted firmly in the “anti-pain-in-the-ass” philosophy while designed to find you the best few distinct paths to your destination. It’s in testing now, and will soon be pushed onto the live site for everyone to play with.
Another honourable mention should be given to jQuery, which is used extensively throughout the user interface. I’ve been known to border on “zealot” status, and I’ve yet to be made embarrassed by this.
RE: Tell us about the business model (if there is one).
KH: MyTTC was never built with revenue in mind. We refuse to put up advertising (who likes seeing advertising, anyway?) and instead opted to fund it privately. George Talusan and Hilary Street (authors of Red Rocket) were also kind enough to help out with some of our hosting costs from the proceeds from their iPhone app.
After years of development, we’ve now decided to start licensing the service to other agencies as well. We came to feel that most similar services are either unreasonably costly or too difficult to use (for web authors and users alike). Sadly, in most cases, both are true. We’re hoping to be able to make our service accessible to all transit agencies and riders, regardless of their size. Also, with the “open access to data” philosophy baked right in, we’re confident more agencies will be encouraged to open their data to third-party developers.
Ultimately, we plan for MyTTC (the website, API, & data) to remain ad & cost free for as long as it’s useful.
RE: What’s the coolest or most useful feature of your application?
KH: While the most useful feature is arguably the trip planner, we’ve had an enormously positive reaction to some of the tools we’ve built along the way.
When you’re dealing with millions of rows of data, you can’t just stare at pages upon pages of numbers to see if they make sense. So to help us troubleshoot our timetables we wrote a series of algorithms that produced videos of the data “in action”. The latest video, a simulation of weekday transit vehicle traffic, is viewable in HD on Vimeo: http://vimeo.com/1865789 This video is also available as a screensaver for Windows on our website: http://myttc.ca/screensaver
Another popular thing at parties (I wish I were kidding) is the graphical front-end of our new trip planner. We hooked it up to OpenGL so we could literally watch the algorithm work, albeit slowed waaaaay down so we could see it – it’s FAST That way, we could actually see it doing something wrong, and know immediately once we’d fixed it. The graph of possible trips builds itself right on the screen, allowing you to rotate it in three dimensions, zoom in and out, and jump forward by 10 seconds so we can see which decisions it would make differently at that time. I can’t lie; It’s kind of hypnotic, and one epic time killer.
RE: What are your goals and plans for the future of this application?
KH: As I mentioned earlier, we plan to keep MyTTC on the web for as long as people use it. Both as a service for the transit riders in Toronto, and a proving ground for new ideas and features. It’s an excellent choice for testing, since the TTC is both very familiar to us (we’re both frequent riders) and is also North America’s third-largest transit agency. Scaling down is a much easier thing to do than scaling up!
I also want to mention that our users have been incredibly valuable in helping us identify problems, as well as suggesting cool new features. It’s a lot of fun building an application that people choose to use, and it’s always educational when feedback emails come in. We find it more than a little inspiring that so many people care enough to write us, and we truly believe they’ve earned every hour of work we’ve put in. To all our crazy-awesome users: THANK YOU!!!
RE: What advice would you give to someone who is thinking of creating application/software for the web?
KH: This is a really big question, so much so that many really excellent books have been written on the subject. I guess if I had to pick a few highlights, they’d be as follows:
One oft-given tip that I feel the need to recount is to collect as much feedback as possible. Collect it programatically when you can (notify yourself of exceptions and failures), but most of all solicit as much feedback form your users as they’re willing to provide. We put a feedback box on every page of our site, and the quality & quantity of messages we’ve received is simply overwhelming. As a programmer, you’ll often have a set of use-cases, features and test cases in mind, and if you’re very lucky they’ll cover 80 percent of how people actually want to use your app. That last 20 percent is your opportunity to turn a good application into a great one.
In the spirit of “real artists ship” (http://www.folklore.org/StoryView.py?story=Real_Artists_Ship.txt), it’s important to stay the course after all the interesting problems have been solved. Personally, I’m notorious for losing interest once I’ve seen the finish line. Fortunately, Kevin is equally as notorious for his need get things finished There’s an old programming aphorism “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” In practice, I realize this has a hidden implication: once you’ve solved all the interesting problems, there are still plenty more to go. Don’t rob yourself by ignoring them – after all, isn’t that why we program in the first place?
Probably the best advice I could give would be refactory’s motto (if we had one): Find good problems you’re passionate about, and solve the f*@& out of them.
RE: And finally, for the bacon-loving community, how much bacon is there in the application?
KH: More than a streetcar, but less than a subway. So…. 42?
RE: Awesome. Thank you very much for your time, Kieran.
KH: Thank you!
===
For more information about myTTC, check out:
Website: myttc.ca
Kieran’s Twitter: twitter.com/kieran
Kevin’s Twitter: twitter.com/kbranigan
Possibly Related Posts:
If you enjoyed this post, please leave a comment or subscribe to our RSS feed to have future articles delivered to your feed reader.
