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 + '!' end end
The way you call :yell is like this:
➜ projects rake arg_yellifier:yell[quietness] 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 DON'T TELL ANYONE BUT... YOLO!
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\] 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
Sometimes 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:
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?
> 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.
- You finish writing some awesome code. You’re a bad ass and you know it.
- You hit the command line, because you stopped creating GUI interfaces using visual basic a long time ago.
- Issue a little “git add” here and there, add some broth, a potato. Baby, you’ve got a stew going… So you commit!
- You do the habitual post-commit “git status” for no good reason and there it is, the file you friggen forgot to add to the commit you already committed to.
Fortunately git has a really convenient way to amend to your last commit! Just simply stage the file(s) you missed and run:
git commit --amend
For anyone who’s just starting to get into YDD (YOLO Driven Development), here are some good guidelines put together by GitHub user Todor Grudev (tagrudev):
ps. this is a joke, don’t do any of this stuff… or do it! YOLO!
Lately I’ve been writing a TON of tests using RSpec and Capybara. The syntax keeps slipping my mind so here’s a cheat sheet I keep coming back to…
Today at AppAcademy we have gone through almost all of Michael Hartl’s rails tutorial. I just wanted to quote Hartl explanation of what a database index is and how it works. I love the analogy because it’s probably the most simplistic examples I’ve probably ever seen:
Putting an index on the email column fixes the problem. To understand a database index, it’s helpful to consider the analogy of a book index. In a book, to find all the occurrences of a given string, say “foobar”, you would have to scan each page for “foobar”. With a book index, on the other hand, you can just look up “foobar” in the index to see all the pages containing “foobar”. A database index works essentially the same way.