Matthew Bass

Andy Hunt will be speaking at the Raleigh-area Ruby Brigade meetup tonight. It’s sure to be a good show, so grab a fellow geek and head on down to Red Hat headquarters at 7 PM. Signs will direct you to the correct room. Also, if you want an even bigger helping of Ruby tonight, join us at 5:30 PM at Baja Burrito for our traditional round of pre-meeting chow and conversation.

Getting Things Done is a book by David Allen. The methodology from the book, commonly referred to as GTD, has become quite popular inside certain tech circles. I’ve been using GTD for roughly a year now. I can’t claim to be an expert at it, but it’s helped me stay organized during a period of my life that would otherwise have been extremely unorganized.

There are many tools out there that make implementing GTD on your computer fairly painless. For you fellow Mac cultists, Actiontastic does the job nicely with a clean, minimalist interface. There is also Tracks, a Rails-based web application that you can install… well, pretty much wherever. What I’d like to introduce in this post, though, is a unique Firefox extension called GTDGmail.

I’ve been using GTDGmail for a few months now. Once installed, it integrates with Gmail and modifies your view slightly. Among other things, it divides your tags into four categories: projects, contexts, statuses, and references. As e-mail messages come in, you can categorize them as actions by tagging them with the “Action” status. If an e-mail contains important information you’d like to keep for future reference, tag it with a “Reference” and a “Project.” As you tag your e-mail, it becomes available under GTDGmail’s pre-built search links that appear above your tags.

You can also send yourself actions and references. This is where the famous GTD practice of “capturing” comes into play. The idea is to get all that stuff floating around in your head out and organized into action items. Sending yourself an action or a reference results in a new e-mail message in your inbox, automatically tagges as an action or a reference and ready to be organized further into projects and contexts.

GTDGmail also has some handy non-GTD uses. For example, it makes regular tagging much easier by placing links at the top of each e-mail, one link for each tag. Simply click on a link to add that tag to the e-mail you’re currently viewing. Click the red X next to the tag to remove it from the e-mail. This is much faster than scrolling through a drop-down to find the tag you want to add or remove.

The only downside to GTDGmail is that it does make Gmail less responsive. Since GTDGmail has to overlay Gmail’s existing layout with additional information, it can get bogged down at times. However, the upside of being able to immediately categorize your incoming e-mail into action items more than makes up for this. GTDGmail is not for everyone, but I encourage you to try it out to see if it fits your own organizational style.

Something I frequently need to do when deploying a Rails application is determine the current migration version of a database. In the past, I’ve done this by bringing up mySQL and typing:

SELECT version FROM schema_info

Well, I’m finally tired of doing that so I cooked up this Rake task:

namespace :db do
  desc "Print current database migration version to the console"
  task :version => :environment do
    puts "VERSION=#{ActiveRecord::Migrator.current_version}"
  end
end

To install, copy and paste into lib/tasks/common.rake (or wherever you store your custom Rake tasks). Then fire up a terminal window and feel the power:

$ rake db:version
(in /Users/matt/project)
VERSION=125

I’m surprised this isn’t already in Rails. Sure, there’s script/about, but I always forget to use it. It also spits out other information I don’t typically need to know.

Why care about the migration version in the first place? When you’re on a project with multiple Rails deployments (dev/test/prod) and multiple developers creating migrations in multiple branches, it comes in quite handy.

I’m proud to announce that Teascript went live early last week. It’s been a long several months since originally conceiving the idea, building the app, beta testing, and deploying but now it’s finally ready for prime time.

Teascript is a Rails application that makes it easy to design and build professional high school transcripts. It’s mainly targeted towards home school parents and students, however, I’ve received interest from several public and private schools who are looking for a transcript generation package they can install locally so the potential for this product seems huge.

For those interested in how Teascript was deployed, the application runs on Apache 2.2 with mod_proxy_balancer and a cluster of Mongrels. I’m using a VPS provided by Slicehost. This setup has been rock solid so far.

My talk at RailsConf this year will focus on the development of Teascript: how the target niche was chosen, how the application was marketed, and so on. My goal is to demonstrate how the principles outlined in 37 Signals’ book Getting Real and the homesteading concepts put forth by Nathaniel Talbott at last year’s RailsConf were combined to produce a web product that is self-maintaining, sustainable, and capable of generating passive income.

So please, check out Teascript and let me know what you think.

I’ve been writing Ruby code for over four years now. I’ve been getting paid to do so for about two years. Prior to that, the bacon I brought home came mainly through the careful crafting of lines of Java, PHP, and C# code. Matz spoiled the party for me in the mid-90s, however, by releasing such a wonderfully beautiful language that it made Java tedious and uninteresting in comparison.

Ruby is a fantastic tool. But it’s not just a tool, it’s also an art medium. I had never truly seen beautiful code until I met Ruby. All that being said, when I was first introduced to the language it was a lot like trying to breathe while standing under Niagara Falls. The “wow-that’s-cool-but-I-don’t-quite-grok-it” moments came fast and furious. Ruby was blowing my mind on a daily basis.

It doesn’t anymore. At least, not every day. But at least once a month, I see a code snippet or read a blog post or hear about a new way to do something and… well, there goes my mind again. For example…

Read the rest of this entry »

RailsConf registration is open. Time to scramble! From what I understand one-third of the seats are already taken. I’ll be speaking at the conference this year. Should be more fun than a barrel of monkeys. See you there.

Mike Clark made a recent post on his blog about how to handle Rails versions with Capistrano. Very nice stuff. I’ve put his code samples to immediate use with an app I’m preparing to convert to Rails 1.2.1.

I’ve run into some trouble this week, though, as I want to update one of my client projects that still runs version 1.1.6 of Rails. Mike’s Capistrano task takes a revision number so checking out a fresh copy with his script looks something like this.

rake deploy_edge REVISION=5990 RAILS_PATH=/path/to/shared/rails

This checks out 1.2.1 into the specified directory. After spending a few minutes trying to find the revision number for 1.1.6 (and chatting briefly with my Campfire peeps about the best way to proceed) I’ve decided that it’s safer to use tags instead of revisions. Deploys now look like this:

rake deploy_edge TAG=rel_1-1-6 RAILS_PATH=/path/to/shared/rails

Much more readable. The only downside, of course, is losing revision granularity. I’m essentially tied to the whim of the Core team as to when they decide to create new tags. But on the other hand, most of my projects aren’t currently running on Edge so this is suitable for my needs at the moment.

I’ve included my rewrite of the task below. Just drop it in common.rake or wherever you prefer to put your custom tasks. Reading Mike’s post would be a good idea too since he explains how to get this working with a remotely deployed Rails application.

Read the rest of this entry »