Check out the incredible shortcut Lance Armstrong takes in the above clip.

As developers, we should try to shortcut as smoothly as Lance does. You might not get cheered on quite as much—but then again, you have a lot more shortcut opportunities!

Shortcuts and Development Workflow

The quicker I can go from intent to action, the happier I am with my development workflow. Below are two tools I rely on to build shortcuts as effortlessly as possible.

An Organic, Evolving .bashrc

The best general-purpose shortcut mechanism is aliases in your .bashrc. I have one- and two-letter aliases for all my common working directories, git commands, server startups, etc.

If you want to relentlessly shortcut, you need a shortcut for creating shortcuts:

alias brc='vi ~/.bashrc;. ~/.bashrc'

All this does is load up .bashrc, and re-source it when I exit out of vi. This one command has turned my .bashrc into an organic, evolving toolbox, making whatever I’m working on easier, faster, and more fun.

Thor

For more involved scripting, I’ve recently become a fan of Thor. Thor is everything you like about Rake combined with everything you used to like about Sake:

• a central place for your ad-hoc scripts
• Usable system-wide
• Write your own or install from remote repository
• Low barrier to rolling your own.
• Simple options parsing.

Here is the hello world of Thor, and here is a more advanced article to get the juices flowing.

Previously in Developer Happiness

This is Part 3 in our Developer Happiness series. See previous articles:

• Part 1: Make it Trivial to Grab Production Data
• Part 2: Speed Up Your Tests

John P. Wood of Signal, which offers a mobile customer engagement platform used by many top brands, recently created a couple of Scout Plugins for monitoring CouchDB. I’ve always been impressed by the team at Signal, so I was curious how they were using CouchDB in production. It turns out CouchDB is a huge part of their infrastructure – for example, one of their CouchDB databases is over 130GB in size.

John was kind enough to share his experiences with CouchDB below.

You use a number of different storage engines (MySQL, CouchDB, MongoDB, and Memcached) at Signal. Where does CouchDB fit in?

A couple of years ago we were running into performance issues with some very large MySQL tables. Queries against these tables were taking very long to run, and were causing page timeouts in our web application. At the advice of a friend who was helping us out as a consultant, we started looking at CouchDB. CouchDB views turned out to be a great fit for our problem.

A key component of our application is SMS messaging. The problematic MySQL queries we were running were collecting aggregate stats on these messages (how many messages did account A send in January of 2009, all of 2009, how many for all accounts, etc). Most of the queries were executing on past data, meaning the results of those queries would not change over time after that time period had past. So, it was simply a waste to re-calculate these numbers over and over. We considered using summary tables in MySQL to avoid this costly re-calculation, but saw them as being inflexible and difficult to maintain.

Seeing your tests pass is a great feeling. Waiting a long time for it—not so much. Faster tests mean a happier developer!

Use Parallel Tests

If you’re not using parallel tests by Michael Grosser, you’re wasting time. Setup is just a few simple steps. You’ll be glad you did.

Upgrade Ruby if Possible

Another way to speed up your tests is to upgrade your project to Ruby 1.9.2. Here’s my Rails on 1.9.1 in Production: Just do it post.

Test suite under Ruby 1.8.6: real 3m57.156s

Test suite under Ruby 1.9.1: real 2m42.533s

A 31% speedup is nothing to sneeze at! If you have the ability, go Ruby 1.9.2 for faster tests.

Get an SSD for Your Development Box

As I pointed out a few weeks ago, dropping an SSD in my Macbook Pro cut my test runs in half. It’s not cheap, but if you spend your day on your computer, it’s well worth it.

The New York Times ran a popular Op-Ed on Happiness last year. The Cliff Notes version?

The daily activities most associated with happiness are sex, socializing after work and having dinner with others. The daily activity most injurious to happiness is commuting.

Many software developers are fortunate to have flexible work hours that reduce (or eliminate) commute times. But what about that those times when you’re writing code and can’t have sex, socialize, or meet friends for dinner?

(1 of 5): Make it Trivial to Grab Production Data

You need to be able to troubleshoot data-specific issues in the comfort and serenity of your development environment.

So, you need an easy way to grab production data and bring it local. In the simplest case, this is just a rake task that 1) ssh’s into your production db and mysqldumps your database; 2) gzips it and scps it locally; 3) unzips and imports the dump into your development DB.

That approach doesn’t scale. As your product grows, the all-or-nothing dump won’t be enough. Your database will be too big to dump quickly, and it will take too long to transmit over the wire. This is not the way to developer happiness.

What you need is a way to export a slice of your application’s data. There is no way to generalize this; it’s totally application specific. For Scout, the most sensible partitioning approach is to download one account and all its associated data. The trick is to identify the associated data to be export as it cascades through your application. The basic recipe we use for this is:

1. a local rake task invokes a remote SelectiveExporter class, passing the account ids we wish to export.
2. the SelectiveExporter does a sequence of mysqldump calls, assembling the set of data related to the account to export.
3. we scp the result and import it locally.

The payoff is huge: we’re able to grab data needed to troubleshoot a problem in 15 seconds instead of 30 minutes. That puts a smile on our developer faces.

Last year I ponied up for a 256GB SSD for my Macbook Pro. Six months later, I can confidently give the verdict that it’s the best investment I made in my work setup. Just a few datapoints:

• Scout’s unit test suite runs in half the time: 1m34s vs. 2m58s with my old setup
• Photoshop opens in under four seconds
• XCode opens in under three seconds
• everthing else opens pretty much instantaneously—I don’t keep mental track of what’s open or not, because there’s essentially no overhead.

These little efficiencies add up over time. More importantly, though, if I know the friction is minimal, It’s much easier to do the right thing—run the test suite one more time or open up Photoshop for that final adjustment.

A quarter of returning visits to Scout are less than five minutes in length. It’s a tad longer than an elevator pitch on the high end.

Like a real-life elevator pitch, you need to make a good impression quickly for these short visits. A user that spends twenty minutes on a site may excuse a slow page load. On short visits, a single slow-loading page sticks out.

Much of our work is focused on making visits to Scout more efficient. One example: for a long time, our homepage didn’t have a login link. We didn’t think this was important as many of our customers bookmark their account url. However, we saw a couple of cancellations that mentioned the problem with this: if you forgot your account url, it’s a pain to dig back through your email inbox and find it. Taking one minute to remember how to login for a two minute visit is painful.

We added the login link: 30% of logins now start on our homepage.

Reviewing your site’s visit length data is a great reality check. Is your next big feature going to make life easier or more confusing for elevator pitch visits?