Working As Intended

It appears that Firefox 3.5.2 broke XMLHttpRequest.setRequestHeader(). According to the W3C docs, in giant bold green type:

The setRequestHeader() method appends a value if the HTTP header given as argument is already part of the list of request headers.

Rather than appending, it’s overwriting the existing value entirely.

The particular case where I ran into this was when using jQuery to send a remote form request. My setup code includes the following line.

  jQuery.ajaxSetup({
    'beforeSend': function(xhr) {xhr.setRequestHeader("Accept", "text/javascript")}
  });

When firing off an Ajax remote form request with Safari or older (pre-3.5) versions of Firefox, the header would contain the following.

Accept: application/javascript, */*, text/javascript

Or, if the browser had already decided that it was going to accept text/javascript, at worst I’d get a duplicate.

Accept: text/javascript, application/javascript, */*, text/javascript

With Firefox 3.5.2 I see this instead.

Accept: text/javascript

And the HTTP error returned from the server.

406 Not Acceptable

The workaround is simple.

xhr.setRequestHeader("Accept", "text/javascript,application/javascript,text/html")

I have to set that header parameter with all of the types that should be accepted as a response to a remote form request.

The downside to this is that non-broken browsers almost defintely include duplicate values, but at least it still works.

Ex.: Safari with the workaround in place.

Accept: text/javascript, application/javascript, */*, text/javascript,application/javascript,text/html

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.

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.

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.