Working As Intended

If you edit with TextMate, but you haven’t yet installed Ack in Project, you’re missing out. It’s much faster than TextMate’s built-in search. My preferred fork of this bundle is David Lynch’s, which adds a pull down menu of file types to focus your search on.

Uploaded with plasq’s Skitch!

One of the cool things about file types in Ack is that they’re more like buckets of types. Looking in ack-standalone.sh, this is the default mapping for “Ruby” files.

ruby => [qw( rb rhtml rjs rxml erb )]

I wanted to include Haml in that list, so I edited the .sh file and issued a pull request for the change. David wrote back, informing me that these mappings can be modified on the command line so I dug into that a bit deeper.

It turns out that you can modify an existing mapping with Ack’s --type-add switch. In this example, I wanted to include both .haml and .rake files to my “ruby” searches.

--type-add=ruby=.haml,.rake

You can also add a completely new type with --type-set.

--type-set=haml=.haml

Put these in ~/.ackrc with each switch on its own line.

The Ack docs don’t use the equal sign after the switch name, but I found that it’s needed for OS X. No idea why that is, but it seems to work.

Ack in Project will automatically pick up these changes, because it builds the pull-down menu by parsing the output of ack --help=types. This also makes it convenient to see if you’ve set up your .ackrc file properly.

$ ack --help=types
...
    --[no]ruby         .rb .rhtml .rjs .rxml .erb .haml .rake
...

Yay.

Out of the blue I started getting the following error from TextMate’s test runner for Rails tests.

Rails requires RubyGems >= 1.1.1 (you have 1.0.1). Please `gem update --system` and try again.

On the command line, I’d see the following:

jdl ~ $ which gem
/opt/local/bin/gem
jdl ~ $ which ruby
/opt/local/bin/ruby
jdl ~ $ gem -v
1.3.1
jdl ~ $ ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.3.0]

Pretty clearly, TextMate was picking up the wrong Ruby installation on my system. With JRuby and at least one other “normal” Ruby installed, it didn’t seem impossible. But why now? I still don’t know the answer to that question, but I did fix the problem.

Digging through the TextMate Ruby bundles, I kept seeing a reference to “TM_RUBY”. In the advanced preferences I set this to have a value of my desired Ruby install, and everything was happy again.

Setting the TextMate TM_RUBY variable in advanced preferences

Every time I switch to a new branch in git, I ask the question, “Are my dev and test databases in a state that works with this branch?”  Rarely being able to remember the answer, I go through the ritual of dropping the tables, migrating, loading fixtures, and prepping the test database.  Annoying at best.

I hacked together a potential solution.  This is intended for your dev and test databases only.  This looks like an outstandingly stupid thing to do on your production server.  Although, who deploys their database.yml file from git anyway?

For months, I’ve been using this great shell hack that puts your current branch in your command line.  Thanks github.

jdl ~/hm(master) $ git co foo
Switched to branch "foo"
jdl ~/hm(foo) $

It finally dawned on me that my database.yml file could also use a similar treatment. Modifying the system call a bit, I ended up with this. Notice that I’m using an absolute path to git. That’s because the TextMate test runner wasn’t able to find git in whatever PATH it was picking up. If you’re just using rake or autotest, then you can simply specify ‘git’ there.

local_db: &local_db
  adapter: mysql
  username: root
  password: 
  host: localhost

<% branch_name = `/usr/local/git/bin/git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'`.strip.gsub(/[* ]/, '') %>

development:
  <<: *local_db
  database: <%= "project_dev_#{branch_name} "%>

test:
  <<: *local_db
  database: <%= "project_test_#{branch_name} "%>

Creating a new branch takes a bit more effort, but switching is now faster.

jdl ~/hm(master) $ git co -b foo
Switched to a new branch "foo"
jdl ~/hm(foo) $ rake db:create:all; rake db:migrate; rake db:fixtures:load; rake db:test:prepare

The downside to this is that it’s overkill when creating a branch that has no migrations in it. I’m going to try it for a while and see how it goes.

Update: After a week of using this, I have to say that it’s neither terrible nor great. I still think that there is a good idea buried in there, but it needs to be integrated with the git branch hooks to ease the pain a bit. Specifically, I need to figure out the following.

• Deleting a branch should automatically clean up the databases that were created.
• It would be great to have this be optional when creating a new branch. If I could decide to just use my base dev db on a branch, or to create a whole new set of local db’s at the time of branch creation that would be the killer feature for this idea.

Not dead, but back to the drawing board.