One of my common uses for version control is looking for the origin of a particular piece of code, like a function definition. Both SVN and Git have commands called blame, which lets you see who is responsible for a particular line of code at a particular time. For large, long-term projects, that might change a lot over time and make it hard to find the actual source of a particular bug/feature/oddity/etc.

Git has an amazing command called bisect, which is like blame on steroids. This post has an okay article on using bisect. The very short explanation is that bisect intelligently searches through a repository to find the exact commit that a particular thing happened — for example, when a bug was introduced. As you progress through each check, you tell Git whether the current version is good or bad, and Git searches until it finds the right commit.

You can also use git bisect run to automate the whole thing by giving git a script or command to run. Yesterday I made a very small helper which accepts a regular expression and returns 1 when it’s found and 0 when it’s not. In git bisect terminology, that means that the script “succeeds” when the regex doesn’t match and fails when it does. This might be counterintuitive, but the logic makes sense if you’re trying to find the first occurrence of something.

First, it relies on this script, which I call regex-does-not-exist.sh and saved along with my dotfiles.

#!/usr/bin/env bash

if [[ 0 -eq $(ack "$1" | wc -l) ]]; then
  exit 0
else
  exit 1
fi

Next, I added this function to my .zshrc file (the same would work in your .profile, .bash_profile, etc). Note the magic $LOCAL_DOTFILES, which is just a path to the root where this script lives. You’re on your own for producing that path and locating the file, but in my case it’s this: export LOCAL_DOTFILES="$(readlink ~/.zshrc | xargs dirname )"

git_find_source() {
  git bisect start
  git bisect bad
  git bisect good $(git log --pretty=format:%H | tail -1) # Start from the first commit
  git bisect run $LOCAL_DOTFILES/regex-does-not-exist.sh $1
  git bisect reset
}

Now, I can just the git_find_source command in my shell to find the first time a regex finds a match in a repository’s history. Let’s say I wanted to find out when the wp_remote_get() function was introduced in WordPress. I’ll truncate the output a little bit here using ack.

$ git_find_source "function wp_remote_get\(" | ack "first bad commit"
3c99cfc4f50a6b7819fb1c31e7408cf34c4c4e9f is the first bad commit

Then I can check out that commit and see that it is indeed when the function was first defined.

I am a big fan of keyboard shortcuts. I have been experimenting with customizing some browser behavior using keyboard shortcuts to trigger events and found it kind of annoying. Here is an example of binding handlers to keystrokes in JavaScript (source is in CoffeeScript here). It’s a bit of tedious work.

I looked around for a jQuery plugin to do this but didn’t find one. I’d never written one myself, and last night I decided to try. The result was jQuery.keyStroke. I’m still playing with it a bit, but so far it’s proving useful, at least for me.

Using the plugin looks something like this:

$.keyStroke( 83, function() { 'You pressed ALT + S!'; }, { modKeys: [ 'altKey' ] } );

$.keyStroke() takes two required arguments (requriedKeys and callback) and a third optional (options) argument.

Required

• requiredKeys: Array of JavaScript keyCodes for your keystroke. Can be an integer (rather than an array) if you only want to use one keyCode, not including modifier keys passed in the options argument. Order is not important, and ordered keystrokes are not supported. This page is helpful for finding keyCodes.
• callback: A function to call when your keystroke is executed.

Options

Options should be passed via an object, e.g. {arguments: ['foo', 'bar'], context: someValueForThis, modKeys: ['altKey']}

• arguments: An array of arguments to be passed to your callback when your keystroke is exectuted. The last keydown‘s event object is always passed as the first argument to callback.
• context: The value of this for your callback.
• preventDefault: Whether or not to preventDefault() on the keydown event that triggers your keystroke. Defaults to true.
• modKeys: Array of strings that match keydown event properties and can be used to include modifier keys in your keystroke. The modKeys option is only used if requiredKeys is a single (non-array) value, otherwise it is ignored. Examples: 'altKey', 'ctrlKey', 'metaKey', 'shiftKey'

That’s about it. It works like most other jQuery plugins. Load jQuery first, then load the plugin file. There’s a regular and minified version in the Github repo. If you want to take a look at how it works, you’re probably better off reading the CoffeeScript file than the JavaScript file. The JavaScript is compiled from the CoffeeScript.

Update

I added an Underscore mixin to the same repository. It offers the same API, with $.keyStroke() replaced by _.keyStroke().

A couple months ago I decided to spend a day learning CoffeeScript.

CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

– coffeescript.org

I could talk a lot about why I like CoffeeScript and how much more enjoyable it is to write than JavaScript. But earlier today I was thinking about something different — good practices I’ve learned from CoffeeScript and incorporated into work in other languages. There are three that stand out for me.

Always return something

By far my favorite CoffeeScript feature is its implicit return values. CoffeeScript functions will automatically return their final values, even without using the return keyword. If you have a function with multiple possible final values, like an if/else conditional, the CoffeeScript compiler is smart about making sure both are return’d. I consistently forgot about this feature at first, and for a while it seemed a little weird, but as I used it more I really started to love it for two reasons. First, it’s a good assumption that the last thing a function does is the best thing for it to return, and at least as good as returning undefined. Second, it means I can always assume that a function returns something.

Always be explicit

CoffeeScript automatically handles one of the most annoying parts of JavaScript, declaring local variables with the var keyword. Any variable you use in CoffeeScript is automatically declared with var at the top of its scope, which is awesome. On the other hand, that means that if you want to use non-local variables you have to explicitly declare them. This confused me a bit at first but now I really enjoy being forced to use, for example, window.foo instead of just foo. It’s much clearer than the implicit approach and reduces lots of possible confusion.

Always be defensive

I debated whether or not to include this one because I think there are some styles of defensive coding that are bad, but CoffeeScript does a great job with it. The easiest example of this is the top level closure that CoffeeScript wraps your code in by default. Most (good) JavaScript you see looks something like this: ( function() { ...some JS here... } )(). That is a closure and it contains the scope of your code so that you don’t accidentally pollute the global namespace. CoffeeScript does this for you automatically, which lets you remove a couple lines of syntactic cruft from your code. The automatic var declarations is another example of good, defensive assumptions. Another good one, which I won’t go into here, is function scope binding via the “fat arrow” syntax (=>).

So…

While all of these are things I’ve picked up or been reminded of from CoffeeScript, I’ve been applying them all to work in other languages, too. It’s reminded me how valuable it can be to explore new approaches to old ideas.

CoffeeScript is an awesome language and makes writing JavaScript a whole lot more fun. I’m trying pretty hard to not write anymore JavaScript and move everything I work on to CoffeeScript. If you want to learn more about it, the CoffeeScript homepage has a lot of good information. I also used Code School’s CoffeeScript course and can’t recommend it highly enough.

Update: This project has been completely rewritten. The Github readme is up to date and there’s a post about some of the new features here.

Meet Scatter, a handy deploy helper I wrote this weekend.

Deploying web projects can be a bit of a pain, especially when you don’t manage them all the same way. I maintain a couple of sites, like this one — which uses Capistrano — and IsValid — which uses a good old fashioned git pull. It’s also frustrating not to have a good place to keep deploy-related code for open source projects (like IsValid).

At Automattic/WordPress.com, we have an awesome-yet-simple deploy tool that our systems team maintains. From a developer’s point of view, it’s as easy as typing deploy wpcom into a terminal. If I wanted to deploy another project I just change out the argument(s). For example, if I want to deploy our internal “Mission Control” site, I would type deploy mc.

Inspired by our deploy command and Mark Jaquith’s WP Stack, I decided to write a generic command line deploy tool; thus, Scatter was born.

The idea behind Scatter is to support whatever deploy “system” I wanted to use for a project. Scatter does that by letting you define a custom script for each project, called deploy (just an executable, extension-less file) and making it easy to access the one you want with some simple git repository parsing (or explicit arguments). It also supports a fallback to a basic cap deploy if you provide a Capfile, which is what I do for this site.

Scatter is designed to keep your deploy and web code separate and make it easy to access one while developing the other. I wrote a detailed Readme for Scatter, so if you want to know more I recommend you check it out.