Codeulate.

Curious about Rails’ internals? In the screencast below, I take you on a 5-minute tour of the OrderedOptions and InheritedOptions classes in ActiveSupport. Check it out for a code-level tour of an interesting bit of Rails.

By the way, this is an excerpt of a longer screencast I’m creating of guided tour through the best parts of the Rails source. If you’d like to be notified when the full screencast is released, drop your email in this form. (One email, ever.)

UPDATE: Youtube’s compression isn’t looking so hot, so if you prefer, you can download the high quality version here. (43MB)

Summary: an anonymous survey with 50 responses indicates that the average salary for full-time, Boston-based Rails developers is $99,646

Several weeks ago I posted to the Boston Ruby Group mailing list asking people how much money they made. I asked people for their annual salary (including bonuses), how they’d rate their Rails skills from 1-10, whether they managed other developers, and whether they were freelancers.

See the original survey.

Results:
Average salary (non-freelancers): $99,646

Average salary (freelancers): $114,000

Average salary (no management of other devs): $88,340

Average salary (with management of other devs): $113,040

Average self-rating of Rails ability (1-10): 7

Raw data, and the brutally-complicated code I wrote for averaging a handful of numbers lives on github.

Thoughts on the results:
Based on conversations with those familiar with the local market and my own experience, these numbers seem a bit high. I have a hunch there is selection bias at work: perhaps developers that are proud of their salaries are more likely to respond. Additionally, I’d guess there’s a tendency for people to exaggerate slightly on these sorts of surveys. Naturally, you should treat these numbers as you would any drawn from an anonymous survey sent to a public mailing list.

Well, technically got it’s got POSIX-compliant-fu. But that’s even better; so no worries.

Check out this line from bundler’s gemspec. The goal of this line is to set s.test_files to an array of file located in testing-related directories:

There are a couple interesting things going on in this line:

• git ls-files: by default, this command outputs all the files in the index, but we’re going to constrain it with a path supplied by…
• {test,spec,features}: this is a “curly brace expansion”. In bash (and other POSIX shells), this will expand to “test spec features”, however notice that we’ve got a trailing…
• /*: when you’ve got leading or trailing characters around expansions, they are included in the expansion. So the full command of {test,spec,features}/* expands to “test/* spec/* features/*”
• Finally, git ls-files outputs the names of all the files in those directories, and we split them on newlines to get our array.

Finally, if you like the idea of curly brace expansions, but prefer to stay in Ruby-land, you can have the best of both worlds: