Archive for August, 2012

postgresql rails and rake db:test:prepare

August 23rd, 2012

I am very new to postgresql.  Lots of folks use it and swear by it.  I have no complaints with it as a database and query engine.  I struggle with the administrative aspects of it.

A rails project I’m working on uses postgresql and uses databases with UTF8 encoding.  Well, if you’ve ever dived into what rake db:test:prepare does, you’ll know that along the chain it drops and recreates your databases.  That, of cource, necessitates that your user have sufficient privileges to create databases.  Straightforward stuff.

Well, today when trying to run my tests I was getting the generic error:

Couldn’t create database for {“adapter”=>”postgresql”, “database”=>”ha_ya_right”, “password”=>”nopes”, “pool”=>5, “timeout”=>5000, “username”=>”uh_uh”}

That was at the end of the reams of backtrace.  The magic was at the top of those reams:

PG::Error: ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)

HINT:  Use the same encoding as in the template database, or use template0 as template.

Yeah, templates.  I missed that error and ended up using ruby-debug (best. gem. ever.) and breaking right in the postgresql connection adapter.  I’ll have to remember to remove that line.

Anyway, my system is running Ubuntu 12.04, PostgreSQL 9.1.4, Ruby 1.9.2, and Rails 3.2.3.  I had to get the database connection to use template0.  It’s quite easy:

test:
  adapter: postgresql
  database: ha_ya_right
  password: nopes
  pool: 5
  timeout: 5000
  username: uh_uh
  template: template0

That last line is the money line. I mentioned all my environment specs, because some folks in the blogs I came across said that solution didn’t work for them. Hopefully this can save you some time.
HT: http://stackoverflow.com/questions/5821238/rake-dbcreate-encoding-error-with-postgresql

tmux and bash tab completion

August 14th, 2012

In a move of wt[h], somewhere along the Ubuntu 12.04 LTS, tmux, bash development chain someone decided to add this little gem of a key binding:

bind-key -n     Tab clear-history

I found this using tmux list-keys from the command line.  You have to have a running tmux session for that command to give you non-error output. I digress.

SERIOUSLY?!?!?!?!? I mean, the tab key.  You know, the one you hit at least 1 gajillion times per terminal session.  When you’re typing in your editor.  When you’re CDing around the filesystem.  When you’re <insert favorite command-line activity>.  You probably hit Tab without the command modifier in front.

They mapped that to clear the history, shutting down whatever else it may have done.  This one is SO ODD, that I can only imagine there was some really good and crazy reason for it.  I can’t imagine what that is, but perhaps someone could enlighten me.

To overcome this “feature” add the following to your .tmux.conf.  I did.

unbind -n Tab

Dealing with @font-face

August 4th, 2012

Lame post. Just a link to someone else’s post. Paul Irish on @font-face. Some useful info in here just saved my bacon because of @font-face problems I was having with IE*. That bacon may need saving again sometime, so for my future reference:

http://paulirish.com/2009/bulletproof-font-face-implementation-syntax/

* – Problems with IE? Nooooooooo….

Testing ActiveResource::HttpMock with basic auth

August 3rd, 2012

ActiveResource::HttpMock is somewhat of a lesser-known part of Rails testing.  If you use ActiveResource, it can be your friend.

At least until you try testing against an API that requires Basic Authentication.  As the docs illustrate, you use HttpMock by explicitly declaring what I’ll call a request signature for every request that your software will make.  That signature request includes the path, HTTP verb, and request headers.  Basic Authentication is sent in the request headers, but the API docs do not show how to do that.

So here’s how you do that:

encoded_vals = Base64.encode64("#{<basic auth username>}:#{<basic auth password>}").gsub("\n",'')

auth_headers = {
  'Authorization' => "Basic #{encoded_vals}",
  'Accept'        => 'application/json'
}

ActiveResource::HttpMock.respond_to do |mock|
  mock.get "/awesome_api/users/1.json", auth_headers, <expected results and so forth>
end

1/2 of the magic is on the line where we set encoded_vals.  The credentials need to be Base64 encoded.  The one trick is to remember to remove the newline characters encode64 will insert.  The other 1/2 is constructinga hash with appropriate keys and values, which we do with the auth_headers hash.

Lastly, we make the actual call to set up our mock.  You include your path and verb, include the headers, and then include your other arguments.  In this particular example, we’d probably expect a JSON blob back, so we’d want to have a valid JSON string.  You can further include status codes and so forth as the documentation describes.

Happy coding!

Rake running tests in development mode

August 2nd, 2012

This issue is well-known, but the solution doesn’t show up in google searches very easily.

Rails 3.2.7 introduced a change which loads the Rails config as part of the rake bootup process (ht: GitHub user krsmurata).  This means that by the time rspec runs, the Rails environment is already set to development, meaning your tests attempt to run in development.  This means that you could see some neat failures and that your development database may get blown away.

The core team is currently rushing Rails 3.2.8 out the door to address this problem and remove a number of deprecation warnings that 3.2.7 added.  The RC was put out this morning, I believe, and the release is scheduled for this Friday (tomorrow 3 August 2012).

In the meantime, if you’re using RSpec, you can change a line in your spec_helper to get you through this.  Change the line which reads:

ENV["RAILS_ENV"] ||= ‘test’

to

ENV["RAILS_ENV"] = ‘test’

Alternatively you can just go back to Rails 3.2.6.(ht: https://github.com/rails/rails/issues/7227#issuecomment-7433610).