Jim Weirich was awesome.I had a discussion with a coworker today where he openly asked if rake tasks can take arguments… and if they can, can the task’s arguments have default values set.

Passing defaulted arguments to a rake task is actually super easy and I can definitely empathize with people who ask have no idea this is possible.  If you look over a typical unparameterized rake file the DSL looks SORTA like methods but sorta not and it can be a little confusing. This post aims to serve as an example of how to pass arguments to your rake tasks and more importantly, how to set default values.

Here’s an example rake task with sole purpose of yelling your arguments into your face:

namespace :arg_yellifier do
  desc 'Yells your argument directly into your face'
  task :yell, [:phrase] do |t, args|
    args.with_defaults(phrase: "don't tell anyone but... yolo")
    puts args[:phrase].upcase + '!'

The way you call :yell is like this:

➜ projects rake arg_yellifier:yell[quietness]

As you can see, this task takes in an argument called `:phrase` that is set to the value of “quietness” then uppercases it and finally adds a bang to the end.

When you use a block in conjunction with `task` it exposes two variables. The first, which I’ve called `t`, is the task object and the second, `args` is set of arguments passed in by the user.  For this rake task args has one item named `:phrase` and it can be accessed via `args.phrase` or `args[:phrase]`.

The interesting thing here is that `args` is not some kind of hybrid hash. It’s actually an instance of the Rake::TaskArguments class. This is awesome because we can call methods on it such as `with_defaults`.  `with_defaults` simply takes a list of key: value pairs where the key is the arg name and the value is it’s default value.

Check it out in action:

➜ projects rake arg_yellifier:yell


Dear Users of zsh:

If you’re calling rake tasks with arguments and have problems running rake tasks with arguments… such as..

➜ projects rake arg_yellifier:yell[quietness]
zsh: no matches found: arg_yellifier:yell[quietness]

You need to escape the `[` and `]` like this:

➜ projects rake arg_yellifier:yell\[muhahahah\]


I use Postgres.app to run a local Postgres server while doing development work and it’s great. Postgres.app basically provides a completely contained pg server that’s ready to go out of the box — just launch the app and you’re good to go.

Unfortunately because it’s a self contained app things are installed in non-standard places.

More specifically, while installing the `pg` gem on a system I recently had it fail with this error:Continue reading

For some reason my brain has defected and has chosen a life of NEVER being able to recall basically anything related to Ruby’s % notation. After seeing this list on a recent Arkency blog post (an awesome blog) I’ve decided to steal repost it here for my own personal reference.


%q[ ] # Non-interpolated String (except for \\ \[ and \])
%Q[ ] # Interpolated String (default)
%r[ ] # Interpolated Regexp (flags can appear after the closing delimiter)
%i[ ] # Non-interpolated Array of symbols, separated by whitespace
%I[ ] # Interpolated Array of symbols, separated by whitespace
%w[ ] # Non-interpolated Array of words, separated by whitespace
%W[ ] # Interpolated Array of words, separated by whitespace
%x[ ] # Interpolated shell command

barely-wait-credit-great-workplaceSometimes you accidentally commit code under the wrong author or committer credentials.  This has happened to me a few times while writing code from computers with global git settings.  By using `git filter-branch` it is possible to rewrite history… muhahahah!

This snippet will run through your branch’s historical commits and rename the author and committer attributes.

It basically looks for all commits containing a given `$OLD_EMAIL` and resets the following properties:


The code:

This code is an updated version of the “nuclear option” code provided in the ProGit book.

Finally just push:

git push --force --tags origin 'refs/heads/*'

There’s an amazing quote I see floating around the Internet sometimes…

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

The quote is sometimes mistakenly credited to Martin Golding in 1994.

The reality is that in 1991 John F. Woods authored it in a post to the comp.lang.c++ newsgroup.  The body of his message follows:

>Mark>I was wondering why it seems that the comma operator is so rarely used.
>Mark>The only time I ever see it is in ‘for’ loops. Is it really considered
>Mark>*that* bad by the programming public at large? Any comments?
>Rob>Well, I hadn’t seen it used much either outside of the for loop, but
>Rob>in Plaugher’s latest book I discovered quite a few of the following
>Rob> if (condition)
>Rob> var = value, anothervar = anothervalue;
>Rob>This does away with the need for braces. I am tempted to use this myself
>Rob>unless someone has a good point agains using this style. Opinions anyone?
>Consider this:
> if (condition)
> var = value; anothervar = anothervalue;
>Only one little dot is changed, but the meaning is quite different. In other
>words, using the comma operator like that makes it harder to read:

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. Code for readability.


Amazingly, thanks to Google’s mirror of the comp.lang.c++ newsgroup, you can actually view John F. Woods’ post.