Use a different git author per project

In the .git/config of any given git repo, add any user details you wish to set, such as:

[user]
  email = lucas@groupon.com
  name = Sir Lucas T. Willett, Esq.

This will override your global user settings.

Banish your code (while keeping it close at hand)

Sometimes, I just get a flash of inspiration and need to start a project from scratch again. (Please note: my personal projects never exist for their own sake — they’re always an avenue for me to play with new stuff.) However, my git repo is set up, my aliases are set up, my Heroku is set up, so… I don’t want to do all that again!

The solution: rename your existing master branch, and start a new orphaned branch in its place. It’s so simple.

$ git branch -m master old-master
$ git checkout -- orphan master

Then remove all the files from the directory and from staged with:

$ git rm -rf .

Congratulations! You now have an orphaned branch with no history and no files.

Please note: This branch won’t formally exist as a branch until you’ve committed to it, so do an initial commit before you change to a different branch.

Thanks to Kim Lesmer for this post.

Find unique items across multiple arrays

Philip Arndt (@parndt), in what will no doubt be the first of many posts he will inspire, has devised an awesome way of finding unique items across a number of arrays.

Let’s say we have the following arrays:

>> a = [1,2,3]
>> b = [2,4,6]
>> c = [3,5,9]
>> d = [4,8,12]

We roll them up into one array:

>> arrays = [a, b, c, d]

Then we say the magic words.

>> arrays.flatten.inject(Hash.new(0)) {|y,z| y[z] += 1; y }.map{|y,z| y if z == 1}.compact
=> [1, 6, 5, 9, 8, 12]

So lets break this down:

We:

• flatten the array into a single array;
• build up a hash with each item as a key, and a counter for each item; then
• return all items in the hash with a counter of 1

Perfect. Now, go visit his website. (It’s all textual and unfinished - it’ll make him do it.)

UPDATE: Apparently, Graham at Resolve Digital has had a crack at making it better. His solution follows:

(flat = arrays.flatten).select { |i| flat.count(i) == 1 }

I like it. (brought to my attention by @parndt again)

UPDATE: Thanks Mike for pointing out that this is quite a bit less performant and that our original way is pretty great.

Interactively stage whole files with Git

When you’re refactoring huge files, Git has a tendency to break up the file quite unusually when it breaks it up into hunks – a lot of the line comparisons are bizarre. Enter git add -e:

git add -e .

will open all your unstaged modifications in one single edit buffer for you to play around with. This allows you to view your file (or files) as a whole, so that you can have the whole context available to you.

Like with -p, if you provide a single path, that will narrow down the scope of the edit buffer, like so:

git add -e Gemfile.lock

This also helps you for those tricky times when you’re refactoring code between multiple files, combining and separating, and you want to make atomic commits.

Big cheers for Odin Dutton for finding this.

Make your database.yml sexy

You’re a Rails developer, which means you care about DRY. Why do we stop caring when it comes to config files? The standard config/database.yml is full of duplication, and quite a few of us run a very close-to-standard database.yml configuration.

Make it sexy:

postgresql: &postgresql
  adapter: postgresql
  encoding: unicode
  pool: 5
  username: lucas
  password:
  host: localhost

development:
  <<: *postgresql
  database: app_name_development

test:
  <<: *postgresql
  database: app_name_test

production:
  <<: *postgresql
  database: app_name_production

I think this is actually more readable, too - it’s quite easy to distinguish between endpoints if you use proper naming conventions.

Ruby versions in your prompt (with rvm and rbenv)

Working on multiple projects using multiple versions of Ruby can be tough. Tools like RVM and rbenv make it so much easier, and I find that I like to see the current Ruby version in my prompt, just in case anything should ever go wrong.

I recently migrated from rvm, where I was able to get my Ruby version and gemset out very easily:

$ ~/.rvm/bin/rvm-prompt v p g
1.9.2-p290@app_name

where v is version, p is patch and g is gemset. (If you work with JRuby, Rubinius or others, add i for interpreter into the mix.)

Then I switched to rbenv, and I discovered:

$ rbenv version-name
1.9.2-p290

Not quite as extensible as the rvm way, but good enough for me.

(Please note: at the time of writing, the rvmI was using was version 0.0.84 and my rbenv was at 0.3.0)

Format your JSON output

As always, thanks go to Jason Weathered for this tip:

Whether you’re cURLing around with APIs, dealing with JSON logs or [insert other random usage that gives you huge JSON output], unformatted JSON is pretty much impossible to read.

If you’re on Mac OS X, there’s already a tool built in to help you!

[JSON sauce goes 'ere] | python -mjson.tool > output.json

This will linebreak and indent the JSON (albeit with some trailing whitespace - for the cure (if you are using vim), see bronson’s excellent whitespace plugin).

For colour, grab the gem coderay and pipe the json.tool output directly to coderay -json.

Hide `grep` from `ps`

When you grep for a specific process name in ps, you’ll always get back the grep process itself. If that annoys you like it annoys me, try this:

ps aux | grep -v grep | grep $1

otherwise aliased (for me) as:

psg

This post is brought to you by the letter O, the number 6 and @twe4ked.

(link to @twe4ked’s dotfiles alias)

EDIT: You can use psgrep too - that’s pretty cool… /ht @jasoncodes

Run a spec multiple times with `yes`

Ever want to run one spec file multiple times in a single test run? Perhaps want to get a quick idea of how fast your tests run without the overhead of an environment boot every time?

$ rspec $(yes spec/models/user.rb | head -5)

will run the user model specs five times. Due to rspec’s multi-file loading, you can specify the same spec file multiple times and it will run one after the other, and with yes, it doesn’t have to be a copy-paste nightmare.

Adjust the head argument value to repeat ad infinitum and presto! The perfect tool to capture heisenbugs or race conditions.

Thanks to @jasoncodes once again for looking into the shell and whipping up awesome.

Restart a Heroku worker

If your workers hang or need to be restarted, use:

heroku ps:restart PROCESS_NAME

e.g.

heroku ps:restart worker.1

List the processes running on an instance by running:

heroku ps