Writing software since 1932


Phonebook.js – Managing Your jQuery Ajax Soup

With the onset of modern web technologies and the advent of the "MV*" wars, it was pretty much forgotten that a lot of projects aren't in the right place to use these new "auto-ajax" toolsets.  Perhaps they're legacy projects, or maybe they're being built by people who either don't understand or like the MV* approach.  In either case, projets that are just using standard "$.ajax" calls can quickly turn into "soup".  The code becomes bloated and hard to follow, and it's not immediately apparent what's happening when you look at it.

Phonebook.js fixes this by providing a lightweight (1.33kb minified) wrapper around your AJAX calls, allowing you to define a manageable "API consumer" which you can use throughout your project.

// Turn this:
var request = $.ajax({
    url: "/api/users/all",
    type: "get",
    dataType: "json",
    data: {
        "active": true

// Into this:
var request = API.users.all();

You can view the project on github.


Rails Setup in 9 Steps

I've been getting back into the Rails scene recently, and got a little bit tired with the boilerplate process that you had to do to install your favourite gems.  Since is a little bit out of date, I decided to roll my own setup script that could be used for each of my projects.  If anyone wants to give it a try, just run the following command:

rails new <dir> -m

It will ask you if you want to install some popular gems, and complete most of the setup process for you.  Enjoy!


Project, Process, Profit?

For the past several weeks, there has been a lot of discussion both online and in my office about the "ideal" practices when it comes to software development.  What steps should be taken before you start coding?  How much planning should you do?  How do you eliminated scope creep?  Around the same time we were holding these discussions at work, someone asked on Reddit.  While I was a little bit late to the game, my comment received a fair amount of traction, and even generated some direct messages with questions and comments.  I thought the ideas worked well, and decided to post them here as well.

The following are the steps that I try to follow when starting up a new project, whether it's going to be a web application, a useful library, or anything in between.

1. Basic Idea
I usually start by getting some idea stuck in my head. It'll come to me while on the train, maybe laying in bed, or while watching TV. If it's a good idea, I'll think about it a bit more, and start to think about features. At this point, it's all in my head.

2. Features and User Stories
Once I've rolled an idea around in my head for a while, it starts to evolve and get uniquely defined features. At this point, I'll start by writing the features out in a notebook somewhere (for me, hard copy helps my ideas flow better than using a computer). After a rough point-form list of features is done, I make them more details as "User Stories", which look like this:

As A User:
  I want to be able to register for an account by entering my email
  and password.

  I want to be able to post notifications and have them automatically
  be emailed to all of my subscribers

As A Subscriber:
  I want to automatically receive emails whenever one of the users
  I follow submits a notification.

You'll notice these are basically lists of "Wants". Also notice that the list is fairly fine grained, and can be quite long. Once you know what you want, you can go a step further.

3. Mockups
If my application is going to have a user interface (like a desktop or web application), I'll draw a few sketches in a notebook. I am not a designer, artist, or User Experience professional, so these sketches always look terrible and never stick, but they help me to find the rough "look and feel" that I'm going for.

If you're more technically inclined, you can get Balsamiq Mockups and create interactive mockups on the computer. I highly recommend this product.

4. Deciding on Tools
Ok, so now I know exactly what I want to build, from features to (rough) design. The next step is to decide on my toolset. I'm familiar with many different languages, libraries, and frameworks, so I sit down and do a bit of research to find the best one(s) for this project.

For example, if I'm creating a real-time, auto-updating web application, I'll do some research to find out which web servers I'm familiar with have the best support for WebSockets, and might find out that I can integrate my HTTP and WebSocket server if I use Tornado and SockJS.

5. Planning
Once the tools are decided upon, I plan the project out. I rarely need to come up with my own directory structure, as whatever framework I'm using will dictate one for me, whether it's Ruby on Rails or Django.

To start my planning, I create a new board on Trello, and give it four columns, labelled "To Do", "In Process", "To Verify", and "Done". I convert each user story from Step 2 into a task in my "To Do" list. I also add a few other tasks that relate to the general "start up" process for a project, such as setting up a Github repository, etc.

6. Development
Ok, I know what all my features are. I know what tools I will use to build the site. I know what all my tasks are. I'm ready to start. I go through the tasks in whatever order I feel makes sense (keep in mind, some tasks will require others to be completed first), and add those features to my program. When I start a task, I move it to the "In Process" list in Trello, and when I'm done it, it goes into "To Verify". It does not go in "Done"!

After about a week has passed, I'll go back to the "To Verify" task in Trello and read the user story I put together. I then try to do what it says in my application, and ensure it works. If you have two or more developers on a team, it is good practice to only verify someone elses work. The reason I wait a week is so that I "forget" some of the "quick tricks" you learn while repeatedly trying/testing during development. Being stuck in this routine while verifying can cause you to miss things.

Once a task is verified, it goes into the "Done" column. Once all tasks are in the Done column, the project is "complete". Many times, I'll do a project over multiple iterations, so this set of steps will happen once or twice, with a different starting point each time.


The Log Cabin

I'm pretty sure every programmer, at one point or another, puts headphones on and tries to forget the real world so he (or she) can get things done.  I'm also sure that every developer has gotten sick of the music once or twice.

After looking around online, I came across three things I've been using recently to help me "zone out" when I've got some important tasks to get done.  Follow the steps below and enter the log cabin.

  1. Go to
  2. Go to
  3. Go to

Ahh, that's better.  Now, just tinker with the volume on all three until you get where you want to go.  Personally I have the following setup:

  1. Set RainyMood to the "middle" volume (You can change it by clicking the volume icon on the bottom)
  2. Set the Fireplace to max volume
  3. Set SimplyNoise to 9%

And that's it.  Enjoy your vacation.

Filed under: Uncategorized 1 Comment

PathJS: Status Update

PathJS has gotten a little bit more popular since I last wrote about it - just recently passing 300 followers on Github.  With the newfound popularity come the obvious - new bugs, and feature requests.  While I've been extremely busy recently getting accustomed to both my new job and my new commute, I've started work on what can only be described as a "ground up" rewrite of PathJS.  With it, I aim to close every open issue on the Github page (which has grown to be about 5 now), as well as add a few features that have been requested.  Here's what's happening now:

  • I'm changing the system to generate all possible routes for a Path when it's defined, rather than doing it during dispatch.  This should make things even faster than they already are
  • I'm going to rewrite the test suite to be more comprehensive, easier to extend, and prettier to look at
  • I'm looking into ways to integrate PathJS with other libraries.  I'm not sure what that means yet, but I'm experimenting!

So, that's the plan.  Things aren't going as quickly as I'd like, but they're coming along.  Right now I'm running into an issue finding an efficient way to calculate all the possible route combinations for complicated optional routes (such as "/path(/to(/something))(/or(/something))(/else)").  I'll give it some thought over the next few days and hammer it out.


Time to put my Top Hat on!

After just over three years of work at Fluid Media Inc, I've thrown in my hat in exchange for a new one.  Starting tomorrow, I'll be spending my days working for Top hat Monocle.  I'll be spending most of my time writing Python and JavaScript, which will be a nice change of pace from the world of Ruby I've grown accustomed to over the past several years.  I look forward to working with my new team, and I've been told that there is a Bulk Barn near the new office, so absurd quantities of candy will be had by all.

Wish me luck!

Filed under: Personal 1 Comment


My life is like a snowball rolling down a (very) snowy hill.  Every step of the way, it picks up something new.  I'm finding that my days are going by faster and faster, yes I've always got more and more to do.  I've got three unfinished Open Source projects I want to get out the door.  I've got work, evening classes, and a (moderately) strict running schedule as I prepare for a few Half Marathons in the fall.  In the middle of this massive snowball lies my profoundly informative blog - which has been neglected for the past few months.  Well, no more!

Rather than only making posts about finished projects, point releases to existing projects, tips and tricks, and other day-to-day happenings of my outrageously interesting life, I'll be posting the problems I'm having with my software.  I'll be posting the ideas I have for new projects, most of which will never see the light of day.  I'm going to try to be more informative with not only the technical aspect of my projects (by releasing code on Github), but to also show some of the thought process that goes into designing a piece of software with the intention of having somebody else use it.

This should be interesting...

Filed under: Personal 2 Comments

DemoCamp Hamilton 5

I've been invited to speak at DemoCamp Hamilton 5, on February 9th this year.  I'll be giving a brief demo of PathJS, a client-side routing library I wrote last year.  The reason I decided to demo PathJS was because of the high abundance of web-based technology at previous DemoCamps.  Nearly every demo thus far has either been primary web-based, or had some web-based component.  The problem is that the software I've seen thus far is treating their content as "web pages" and not "web applications".  In order for the web to move forward as the base for an application environment rather than a simple series of pages, companies and organizations are going to have to start working towards m


Around the Bay: 30K

I've been thinking about doing an "official" run for a while now. There are some small 5k and 10k runs in towns, suburbs, and cities nearby, but nothing I found in time that's right here at home.  Then I decided, "Who needs to 'warm up' with a 5 or 10 kilometer run?  Why not just go for broke and put my body through the meat grinder with a mean 30k?"  Then I signed up, saw the map, and immediately realized just how far 30k actually is.

While I know the masses are just frothing at the mouth to throw their money at me, I urge anyone with a few spare dollars and a few spare moments to donate to the cause instead.  Your donation will help the new St. Josephs Surgical Center, the redevelopment of their new Mental Health facility, and zombie research.

Filed under: Personal No Comments

Bug Fixes for the Holidays

With the holidays just finished, I've finally got some time to peer into the dank and dusty crypts that are the Github Issues pages on my projects and try to clear out some of the skeletons in those particular closets.  For anyone who has been using PathJS or PollJS, I've fixed all bugs that I could reproduce.  This includes:

PathJS:  Doesn't work in IE7

This ended up being a bug with Internet Explorer 8 or 9 in either Compatibility Mode or Quirks Mode.  IE8+ supports the "onhashchange" event, which PathJS binds to.  Unfortunately, when in Quirks Mode or IE7 Compatibility Mode, this event never gets fired.  The problem?  It's still reported as being supported.  I've added some secondary checks for IE to ensure that the proper methods get fired when in Quirks/Compatibility Mode.

PathJS: "Root Route" doesn't get executed on Android

This was just a condition of certain pieces of code being called in the wrong order.  A simple re-arrangement fixed the problem, and now it works and is tested on Android 2.3.5.

PollJS: Minified file is not up to date

When I fixed the "overwrite" bug in late Novemeber, I neglected to update the minified version of the file.  I've updated the minified file, and it can now be pulled into your projects to fix that bug.

In addition to fixing the issues and bugs on my existing projects, I've also been working on a project that aims to make client-side javascript logging and debugging a lot more powerful.  Expect a release of Lumberjack.js sometime in the very near future.