Dr Nic

My attempt at sake task management

Sake set

I’ve used sake intermittently in my workflow. It competes against me writing helper/admin scripts in my ~/ruby/bin folder. Normally, executable Ruby scripts have won. But I think I have a new solution that could make sake a permanent winner for me.

Ruby scripts are easy to create and execute. You just open new file, change the TextMate grammar to ‘Ruby’, type ‘rb’ and press TAB and you’re off and running (the ‘rb’ snippet generates #!/usr/bin/env ruby or a variation of that). You then make the file executable and BAM! you can run the script from any folder in your environment.

Sake tasks are more annoying to write. After creating a new file, you need to create the namespace and task wrappers for your functionality, such as:

namespace 'foo' do
  namespace 'bar' do
    desc "This task ..."
    task :baz do


Your task isn’t instantly executable either. After each change, you need to uninstall the task (sake -u foo:bar:baz) and then reinstall the sake file (sake -i foo/bar/baz.sake) and then run it (sake foo:bar:baz). Perhaps there’s a way to inline edit a sake task, but I can’t see it from the help options.

But once you’ve got your script installed in sake, you get all the wonders that sake provides: a named list (with summary) of tasks (sake -T) and the ability to run those tasks anywhere. Ok, that’s really only one advantage over standard Ruby scripts. But I like it. Oh, namespacing. The baz task exists in a namespace foo:bar. That’s nice too.

So to make me happy, I need a solution to the dubious “create-install-execute” process above. I also want the raw source for all my sake tasks in one place so I can fix/add/change them, reinstall them and move on with my life. I want simple.

So I’ve forked Chris Wanstrath’s empty sake-tasks repo (mine) and added some infrastructure for managing sake tasks. Of course the repo itself is the repository for my sake tasks (which includes a lot from Luke Melia), but most importantly it has a single rake task to reinstall all the tasks without any manual fuss.

The rest of this article assumes you want to have your own repository for your own sake tasks hosted on github. This paragraph is probably unnecessary, but I don’t want to be accused of not being mildly thorough.

Fork the sake-tasks repo

For thoroughness and a chance to demonstrate some gold-medal git-fu, I’ll show two ways: fork my repo and forking the original repo from Chris and pulling my stuff into yours. It’s git, it’s distributed, you can do anything.

If you want to fork my repo and skip a nifty git lesson, go to my sake-tasks repo and click “fork”. Then follow the clone instructions as you normally do when you are blatantly, systematically duplicating someone else’s hard work, using a command that will look something like:

git clone git@github.com:your-github-username/sake-tasks.git

Now, lazy man, you can skip to the next step.

If you want to flex your git-fu, then go and fork Chris’ repo instead. Again, follow the clone instructions.

empty repo from defunkt

Now take a moment to reflect on just how empty your repository is. A fine moment in open-source where you’ve essentially cloned an empty repository. Hardly worth the effort, but since Chris is a creator of github then if he creates an empty repository then who am I to disagree. Empty it shall start.

Now let’s pull in the code and tasks from my repo. My repo could be any git repo anywhere on the tubes.

One way you could pull my code into your local repository is to add my repo as a remote and then pull in the goodness:

git remote add drnic git://github.com/drnic/sake-tasks.git
git pull drnic master

This is useful if you ever plan on re-pulling from a target repo again in the future.

If you just want to pull from someone’s repo one time only, then you can merge these two lines together:

git pull git://github.com/drnic/sake-tasks.git master

If you get occasional pull requests for your projects, then the latter option is handy to know.

Your local repo is now different to your remote repo (your fork on github) so push it back to your remote:

git push origin master

Installing the sake tasks

I originally created my sake-tasks fork so I could store a git:manpages:install task. I’ve just upgraded to git 1.6 (note to self: I want an ‘upgrade to latest git version via src’ task; UPDATE the repository now includes a git:src:install task to do this) and found some instructions for installing the pre-built manpages. Then I got over excited and refactored all of Luke Melia’s git+mysql+ssh tasks in to my repo so it looked like I’d done a lot of work.

To install all the tasks, first install sake:

sudo gem install sake

Then run the install task (check below for the list of tasks to be installed):

WARNING: This will uninstall any tasks you already have by the same name.

rake install

Now, check that your sake tasks are installed:

sake -T

Gives you:

sake git:analyze:commits:flog_frequent   # Flog the most commonly revised files in the git history
sake git:close                           # Delete the current branch and switch back to master
sake git:manpages:install                # Install man pages for current git version
sake git:open                            # Create a new branch off master
sake git:pull                            # Pull new commits from the repository
sake git:push                            # Push all changes to the repository
sake git:status                          # Show the current status of the checkout
sake git:topic                           # Create a new topic branch
sake git:update                          # Pull new commits from the repository
sake mysql:dump                          # Dump the database to FILE (depends on mysql:params)
sake mysql:load                          # Load the database from FILE (depends on mysql:params)
sake ssh:install_public_key              # Install your public key on a remote server.


Adding new recipes/tasks

The installer rake task rake install works by assuming that each .sake file contains one sake task. This allows the rake task to uninstall the tasks from sake first, and then re-install it (sake barfs if you attempt to reinstall an existing task). Without the one-task-per-file rule, the solution would be to load all the sake tasks as rake tasks into memory. But I like one-task-per-file; it seems clean.

So, to create a task foo:bar:baz, you’ll need to add a folder foo/bar and create a file baz.sake inside it. Within that file you would then specify your task using namespace and task method calls:

namespace 'foo' do
  namespace 'bar' do
    desc "This task ..."
    task :baz do


To install new tasks or reinstall modified tasks, just run the rake task (rake install or rake).

TextMate users

The latest Ruby.tmbundle on github includes a task command that generates the above namespace/task snippet based on the path + file name. That is, inside the foo/bar/baz.sake file, make sure your grammar is ‘Ruby’ or ‘Ruby on Rails’ and then type “task” and press TAB. The above snippet will be generated ready for you to specify your task.


So now I have a single place for all my original sake source and a simple rake task to re-install the tasks if I add or modify them. And because its all in one git repo, if other people fork it and add their own tasks then I can steal them.

Pastie paradise

Summary: click to select

Ever tried emailing someone a chunk of code? Some program output?

It starts in the default font, then you change it to a fix-width font, but you still don’t have any syntax highlighting; and the end user has no easy way to extract it from their email and reuse it.

Oh, how about sharing chunks of text/code/program output via Skype/GoogleTalk where the IM makes no effort what-so-ever to keep your pasted text nicely formatted.

Or, IRC, where its definitely poor form to paste in multi-line chunks of anything. Plus it looks ugly and is completely non-reusable.


The solution is to store the chunk somewhere else (website) and forward that (url) to all and sundry.

The solution is pastie (or TextMate pastie or other pastie services), by Josh Goebel

How to use?

Hands up if you’ve never driven in a car and used its seatbelts.

Ok, then why does every airline around the world show you how to use one?

Right. So, I’m not going to show you how to use pastie. Its a form and a submit button.

Moving on…

The other day, Chris Wanstrath, took another step closer to becoming a Deity for Novel Helper Apps, with the release of sake – the system-wide Rake tool. A tremendous way to access Ruby code (coded as Rake tasks) from anywhere, without polluting your path, or requiring you to bundle the code as a RubyGem to share it easily.

What does this have to do with pasties?

There is a sake task for sending anything to pastie. Cop a look…

# sake 1.0.6 available now
gem install sake -y
sake -i http://pastie.caboo.se/73801.txt
sake -T
sake pastie:send
  # Sends STDIN or FILE=file to Pastie;
  # USAGE: cat some_code.rb | sake pastie:send
  # OR:    sake pastie:send FILE=some_code.rb

On OSX, you can get the url for your new pastie in the clipboard using pbcopy:

cat some_code.rb | sake pastie:send | pbcopy

Want to send a patch to someone via pastie?

svn diff | sake pastie:send | pbcopy

and the pastie url is now in your clipboard ready to paste in trac/irc/email, etc.

Pastie-ing sake tasks

Theoretically, you could send someone your beloved sake tasks with:

sake -e my_task | sake pastie:send | pbcopy

As of sake 1.0.6, you can use the -P option instead:

sake -P my_task | pbcopy

Coming from the future

Rumour has it, (because Chris told me) that Chris and PJ are building an app to take pastie-ing to the next level.

I’m guessing the magic formula will be:

  1. Create a pastie clone
  2. Add social networking
  3. Add versioning of pasties
  4. Write wicked-cool blog post and link the whole store to a dubious personal trait, such as drinking sake and beer at the same time
  5. Watch their Working With Rails popularity rankings climb (see Chris and PJ)

Bonus – Railscast competition

I love the Railscast videos, by Ryan Bates. Short video chunks of Rails/Ruby goodness.

To motivate people to submit Rails Documentation Patches he’s now running a competition with prizes!

Capistrano variables

Here’s an example of how you can pass variables to your capistrano actions via the cap command.

So, the above action could be called as follows:

cap log
cap log -s lines=1000
cap log -s rails_env=test

For reference, you pass values to Rake tasks via environment variables:

rake db:migrate RAILS_ENV=test

Inside the db:migrate task, you’d retrieve the value ‘test’ via ENV['RAILS_ENV'].

And further more, this then compares to how you'd normally pass option values into normal command-line apps:

tail -n 1000 log/production.log

Who said the unix command line wasn't easy peasy. Bah.