Bikes and Code

A few days ago, Translink announced that they would be releasing their bus, train and seabus route information in a standard format. A list of every bus stop, route, time, etc might not seem overly exciting to most people, but I love datasets. Admittedly, I often don’t know exactly what to do with datasets, but that’s hardly the real issue here. Anyhow, this seemed like a promising thing for me to do and I downloaded it, unzipped it and spent a couple of hours prepping a Rails project to serve as a new home for it.

Roughly 500 routes, 8700 stops, 126000 trips and 3.4 million timepoints at those stops. Not a whopping amount of data, but enough to start having some fun. My initial plan was just to be able to plot the stops for a given route onto google maps. That’s done in it’s ugly glory at my stopfinder. If you want to search for a 1 or 2 digit route, put in the leading 0’s. Sorry, haven’t done that yet.

My next steps are going to be to publish a number of primitive operations on the data with results in JSON format. Things like ‘closest stop to lat,lon’, ‘how to get from stop x to stop y’, and other similar sorts of things. The idea being that if I can build up a suitable library of common operations on the dataset, any future ideas that do come to mind should be relatively easy to implement.

That and if anyone does want to do some data mining, well, this is an option. I’ll post any updates, formats and that sort of thing on this site as I work through it. In general, the services will be pretty much simply URL based and will return raw JSON. Nothing special, but fairly easy to parse and work with. I have a relatively irrational dislike of XML which I will probably get over at some point, but it will take someone making a very good argument.

I took this book out from the library and was instantly enamoured with it. So much so that it went on my wish list before I had returned it. As with Rails Recipes, this book is primarily for those who have a decent grasp of the Ruby programming language, but do not yet know all of the tricks. If you have memorized the language API, this probably is not the book for you.

As my Ruby experiences are measured in months rather than years at this point in time, more information is always better than less. And I have always been a sucker for a nice heavy book to keep beside the keyboard. 

The Ruby Way.

Basically this book is a list of common and not so common tasks and code snippets to show you how to handle them in Ruby. Another way to look at it is this book is basically the logical reverse of the language API. Rather than look up a method and find out what it does, you look up a task and it tells you the method. This can be very, very handy.

Ruby is a concise language with many excellent one liners. In the core classes, however, there are often a large number of methods. String is one good example, there is something like 100 methods in the class and I have, more than once, accidentally re-implemented one of them while trying to solve a problem. This is mainly due to simple lack of experience with the language. Now that I have a copy of this book, if I get the feeling that maybe Ruby has something built in to solve problem A, I can look up problem A and find out if there is a one liner rather than writing some custom method.

Even in my relatively small projects, this book has already saved me a handful of hours. Currently I am reading through the book, random chapters at a time. The main goal I have now is to build an internal catalogue of problems that this book solves so I can remember to reference it if those problems crop up. Shortly after I use a method a couple of times, then it is part of the repotoire and I won’t need to look it up again.

So, in a nutshell, if you need a good book to learn to make your Ruby more concise and make better use of the language, go with this one.

For the past couple of weeks, between post start-up brain resting, job searching and cover letter writing, I have been working on a little scratch the itch project.

You know, the ones that we developers have all the time. “I really want something that does X, but everything currently out there kind of sucks.” Though, recently I’ve found most of the things that I want are already out there, but they are a pain to use. I’m not sure where I read it, most likely either Steve Yegge or Joel Spolsky, but the general gist of the thing was that you could probably make a decent living taking some decent products out there and simplifying them down so that any grandmother could use them.

At about this time of year, I start to get questions about what sorts of things I would be interested in for Christmas. I generally respond with blank stares as I really can’t come up with much that I need. That said, throughout the year, I will occasionally stumble across something that might be fun or practical, but I can’t really justify purchasing it myself. What I needed was a way to list those things somehow and let my family see it online.

I took a crack at doing a wishlist a couple of years ago as a trial Ruby on Rails project, but I was pretty busy with other things at the time and while it was technically functional, it wasn’t really any easier than what was already out there. This time around, I took a look at some other wishlists on the market and while a few were good, a few were okay, none really satisfied me. This is probably due to the fact that I had been itching for a new programming project for a bit. Anyhow, I took a look at what the other sites offered and started coding. I have just put a closed beta onto a live server for friends and family and should be ready for a wider audience shortly.

Currently it’s good old fashioned HTML, no rich Javascript features or any fancy AJAX yet. That’s coming, but my goal is to make the thing work well with a simple UI, then enhance it slowly. My past couple of projects focused on building a rich web user interface first, which was followed by a half hearted attempt to bolt on a simpler version for browsers that do not have full Javascript support. This time, I am taking the opposite approach, to make a user interface that can run on any browser under the sun, then start adding features to make it more dynamic. Is this a good approach? Possibly, possibly not but I am going to go with it this time around. The only way to really learn if a strategy is a good one is to attempt to use it.

So, this is a Ruby on Rails project. I am trying to do things the Rails way as much as possible. I am using an Apache web server to serve static content and load balance between what is currently a cluster of three mongrel servers. This is massive overkill, but was fun to setup. Deployment is done with capistrano and I am developing in Netbeans, which didn’t crash as much as Aptana RadRails, so I’m using it. Netbeans is a bit uglier, but what can you do… Naturally, everything is done in Linux. Subversion for source code and I’m trying out Mantis for bug tracking and such. All in all, configuration overhead probably ate up about two days learning everything and bashing my head against various walls.

Rails has been great to learn so far. I’m only getting faster at adding new features and cranking out more appropriate testing scenarios, which is good. Not only that, but I can see a lot of things that will improve my Java coding abilities as well. I suppose that’s why side projects are generally encouraged…