Factory Girls secret savings

We like to use FactoryGirl for our test setup. Unlike Rails’ fixtures, it will give you an individual setup for each tests, and thus preventing that tests have side effects on other tests. However, saving objects on each tests comes with a performance penalty.

For your specs, however, you’ll only need to call Factory.build in many cases, creating an new object without saving it to the database. Only that if you have a factory like the following, the associated objects will always be saved:

Factory.define :project do |f|
  f.association :carrier, :factory => :organisation

That is, even if you call Factory.build(:project), Factory Girl will internally call Factory.create(:organisation), saving the associated object. If you don’t want that behaviour in your tests, build your objects “manually” in the tests.

Rails forms and params

Another not to self: Rails has the cool feature that you it will map all the values from your submitted forms into the params hash. And, if you create input fields that are named “something[bla]“, it will automatically create a nested hash so that you will be able to access params[:thingyform][:something].

But what if you just have a list of things that you need to submit? In this case, just name multiple form fields something[], and the params will contain an array.

Firefox caches

Note to self: Pressing the reload button in Firefox causes the browser to always connect to the server, even for cached items that are still valid. It will, however, only check if the resource is still valid, accepting the “304 not changed” response.

Clicking normally will not connect to the server, while shift+reload will force a re-download in all cases.

Getting rid of Google Update

Important note: If you use Chrome, and you follow these instructions you will prevent Chrome from automatically updating. Given the state of the Internet, you don’t want to do that.

I wanted to use Google Earth again, after a while and accidentally installed a new version. Unfortunately, Google had this bright idea of forcing you to install a permanent background task (as root) for it’s “update engine”. That is for a software that I use like 1 time a year.

Luckily, someone already posted on how to weed out this crap, and prevent Google Earth from ever reinstalling it…

Building Mac Packages

Since we’ll need to deploy our application soon in a Mac environment, I’m in the process of building an installer package that our partner’s local staff will be able to handle.

Usually the preferred installation (and deinstallation) method on the Mac is drag-and-drop, which is really the best method I’ve ever encountered on any operating system. But for packages that need to be integrated into the system, such as ours, Apple has a built-in-installer package mechanism.

The installer itself is not too bad, although it doesn’t even consider that you might want to uninstall anything. But the worst part is definitively the “PackageMaker” application that comes with Apples developers’ tools.

I’ve seldom seen such a sorry excuse for a tool – it will actually loose settings if you uncheck a certain box in the UI, and more fun like that.

Fortunately, I found a nifty tool called Iceberg, which let’s you build Apple-compatible installer packages. Though it’s still a bit rough in some places, it’s already richer in features and works much better than the default Apple solution. Check it out if you need to create any Mac installer package.

A little routing trickery

Documentation in Rails seems notoriously bad – the documentation appears to be painfully incomplete. Anyway, all the cool kiddies will tell you how to do resource routing; but I wanted a bit more. In particular, i wanted to have URLs that work like http://xxx/things//. Where is the id of the thing you’re watching, and is an additonal identifier that is passed to the controller. For example, you could have a rout that let’s you do http://xxx/cars/bug/green, to show you the green version of the bug.

After a little trial and error, I found that this will be possible using a route like this:

map.resources :cars do |cars|
  cars.connect ':colour', :controller => 'cars',
    :action => 'car_with_colour'

Which defines this in a much nicer fashion than matching the route “manually”.

Debugger messes up rdoc

Sometimes it seems that ruby still has a way to go in terms of maturity. Today I got a strange error message when trying to build the rdoc files:

uninitialized constant RubyToken::AlreadyDefinedToken (NameError)

Any idea what it means? It turns out that I forgot to remove a require 'ruby-debug' somewhere in the code, which in turn includes some files from irb, which in turn is incompatible with rdoc. Duh…

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: