The right tool for your job

Ever wonder if you should use Workling or Delayed::Job? RestfulAuth or AuthLogic? Paperclip or Attachment Fu? It can be confusing to try and figure out what tool to use for the job. You have many choices for your project, but it is important to look at key elements to influence your decisions.

Project Activity

Looking at a commit log may seem like the obvious way to gauge this, and it is! A lot of people tend to overlook this simple fact. Is the project like Delayed Job where you only see a commit every 2 months and it is a documentation patch? Look yourself, compare Starling to AMQP - AMQP has updates less than a month old, Starling appears abandoned since April.

This metric is probably one of the single most important ones you can look at, and it doesn’t take that long!

Github Network

Another quick metric that can help you gauge how active a project is. The bigger the network, the more community activity there is around a project. I think the benefits of an active community are pretty obvious - Rails is a great example of this.

One gotcha to watch out for here is a “canonical master” repo that isn’t updating or taking any pull requests… Then you end up with 100 different forks of a project and no one driving the project, again like DelayedJob.

Code Cleanliness

Don’t overlook another simple metric for plugins and gems: read the code! Open up Textmate and browse the code. Browse through the tests and maybe even give them a try. If you are going to have your project rely on this functionality, isn’t it worth investing 20 minutes to really look through things?

If you aren’t 100% sure what you are looking at in the code, you have other options as well. Fire up metric_fu and run it on the project. Still daunted? Use caliper, they handle it all for you! They can take any public github repo and generate metric fu scores off of it.

Finding help

The last metric to look for when examining a gem or plugin are your help options. Here are some key questions to find answers for:

  • Do they have a google group?
  • Where do you submit issues, and are they being resolved?
  • Do they have an IRC channel? If so, go see how active it is.

A great example of a strong community would be EventMachine. They have a strong IRC channel (#eventmachine on freenode), a very active github project, and an active google group

How do you know all this?

Well, my friends, let me share a bit of growth pain I experienced in a project. When I first started tweet hopper, I decided to use Starling for queue handling. Why not, twitter used it… Everything ran great as long as I had one box with the job running daemons and the job queue. Everything fell apart slowly as I moved to two boxes, even load balancing between two starling servers didn’t help.

That is when I decided that RabbitMQ might be my best bet, I had heard great things about Erlang’s capabilities in the scaling department. After much deliberation and studying, I decided to make the leap and use AMQP and Eventmachine to interact with RabbitMQ. The choice of AMQP was a no brainer, we already used daemon-kit and it has native AMQP support. The switch took less than a weekend to get up and running!

In the end, we went from two starling queue servers and two daemon servers running 8 daemon workers each, to two queue server and two daemon servers running one daemon each. Starling was constant source of pain, the servers would just start handing out random timeouts after they were up for 24 hours or more. With RabbitMQ, I check in once a day out of habit, but I have yet to restart it in the past 6 months.

Use what works

Use the best tool for the job, don’t be afraid to look outside your main language or to push outside your comfort levels. Don’t hesitate to make a switch to another plugin or gem if the one you are using doesn’t seem to fit your needs. Most of all, just take some time to really examine what you are using - it can go a long way.

Launch it, quick!

I’ve seen some talk/posts lately of doing quick launch products. I wanted to share some thoughts here that I’ve shared before in a talk about winning Rails Rumble1 and what it takes to do it.

Flesh out your ideas

Planning is essential to anything you want to do quickly and do well. For the rumble, we choose to use Basecamp and we started compiling ideas around 5 weeks before the competition. We ended up with around 35-40 ideas to vote on, we each picked our top three votes and took the one with the most votes, then called Menu2Meals. We proceeded to explore ideas and domains over the next 3 weeks before the competition.

It is important to take care of things like naming, core ideas, major features, and nice extras before you start on your project.

Keep it simple

When you have passion about an idea, it is easy to write down a list of 15-25 feature ideas. It is important to determine the core pieces you need to have a workable product, try to get it down to 3 or 4 features. With Tastyplanner2, we had recipes, weekly menu planners, and grocery lists as our core features. Features like recipes search, grocery list sorting, recipe boxes, and others were on the list but a lower priority.

I make a list of high priority, low priority, and nice extras to have when I am working towards a product launch. Keep it simple, you can always iterate later.

Know your tools

Knowledge of the tools and code that you want to use is of paramount importance. A few weeks ago, I relearned this lesson when I wanted to launch a bunch of things in one week. I decided to give node.js and mongoDB a try, but in the end doing research and reading over other code ate up most of my time allotted.

Using new technology or code libraries always leads to some type of learning curve and most of them are steep. Don’t choose new tools when you need to get something done quick.

Timebox it

Timeboxing is a great technique to keep in mind when you are under a tight deadline. If you think something should take 1 day, don’t spend more than 1.5 days on it. If you find yourself stuck or going over, make a branch and push your code, hand it off to someone else, ask if the feature is really needed. I should have used this advice when I was doing the four bean soup launch week, but I didn’t. I lost 90% of my time working on the open source beancounter3 project, but nothing has been released still.

It is ok to take a break and work on other features or to pass the code to someone else, sometimes your brain just needs a break from the constant thought to really start to puzzle out the solution.

To what end?

In the end just remember two things: Plan, plan, plan & Do the simplest thing possible and agree to iterate later


[1] Rails Rumble Talk

[2] Tastyplanner

[3] Beancounter

1 2 3 4 5