Sometimes I want to make assertions about the content of an array when the order of its content is not guaranteed:

nums = [1,2,3].shuffle
nums.length.should == 3
nums.should include 1
nums.should include 2
nums.should include 3

(Of course this is a contrived example, and we could just write nums.sort.should == [1,2,3]. But sometimes we are working with objects that aren't already sortable.)

I recently found out that RSpec has an array matcher that is specifically intended for this use case, via the =~ operator:

[1,2,3].shuffle.should =~ [1,2,3]

Carrierwave has an RMagick module that offers a handy manipulate! method that takes a block where you can modify the image, and then it saves the changes to the image.

But sometimes you only want to interrogate the image, and there's no need to save any changes.

After spending probably 30-45 minutes trying to figure out how to read an image that may not necessarily exist on your local disk, the simplest solution we found was to call uploader#read to get the contents of the file as a string, and then pass that into Magick::Image.from_blob.

When generating sprites with Compass (which is extremely easy), we found that the default output directory for your sprites is the same as the root images directory. This is annoying because we would have to add a line line app/assets/images/icons-*.png to our .gitignore, repeated for each sprite file.

We wanted to put all our sprites in a single folder to be put in .gitignore -- this was easy to find, by adding config.compass.generated_images_dir = 'public/sprites' to our config/application.rb. The next problem was that while the sprite file was correctly being saved to e.g. public/sprites/icons-xxx.png, the client-facing path to the sprite file was still /assets/icons-xxx.png which was always 404ing.

The final answer came from an open pull request on compass-rails which clearly explains that you need to add the output path to the assets path, e.g. config.assets.paths << Rails.root.join('public', 'sprites'). Finally, we can easily add public/sprites to our .gitignore.

The other gotcha we encountered today is that compass-rails only regenerates the sprite file when the sprites CSS file changes, not when you add or remove files from the globbed path.

If you ever spot room for improvement or an error in the Rails documentation -- and that includes the Rails Guides and the API docs -- they've made the process extremely easy. If you've been waiting for "the right moment" to start contributing to open-source software, this might be it.

In Rails 3.1 and newer, when you write a migration by hand, you can (usually) just define a change method instead of an up and a down method.

Jasmine environments have a default updateInterval value of 250 that determines how often, in milliseconds, execution of the next spec will be deferred so that the screen can be updated.

    var now = new Date().getTime();
    if (self.env.updateInterval && now - self.env.lastUpdate > self.env.updateInterval) {
      self.env.lastUpdate = now;
      self.env.setTimeout(function() {
        self.next_();
      }, 0);
    } else {
      if (jasmine.Queue.LOOP_DONT_RECURSE && completedSynchronously) {
        goAgain = true;
      } else {
        self.next_();
      }
    }

Both Chrome and Firefox now require a minimum value of one second for setTimeout in a background tab. This basically means that for every 250ms of work that we do, we end up sleeping for 1000ms.

This gist shows one way to tell Jasmine to not even bother trying to update the screen when running in the background.

var foregroundScreenRefreshRate = 1500;
var backgroundScreenRefreshRate = 9000;

jasmine.getEnv().updateInterval = foregroundScreenRefreshRate;

$(window).focus(function() {
    jasmine.getEnv().updateInterval = foregroundScreenRefreshRate;
});

$(window).blur(function() {
    jasmine.getEnv().updateInterval = backgroundScreenRefreshRate;
});

(Please refer to the gist for the most up-to-date code.)

This code makes Jasmine run at full-speed in a background tab in Chrome, but continue to be updated about once every 2.5 seconds when in a foreground tab. However, using this as-is in Firefox will result in a warning about an unresponsive script, if the tab is inactive. Luckily, you can continue to run Firefox in the foreground fine with this script (good for CI perhaps), or you can just override the dom.max_script_run_time variable to never get that warning, or you can set updateInterval to something less than the default 10 second max script run time.

Do your Jasmine tests (or anything else) seem to lock up when they aren't the active tab in your browser?

Unfortunately, your new and modern browser is to blame. There are a few workarounds, but none of them are ideal in my opinion.

We recently came across a situation in our markup where we wanted whitespace in the markup for readability, but we didn't want that whitespace represented between the elements.

We found a fix that suggested using font-size: 0 in CSS to eliminate the whitespace. That worked fine in Chrome, but we found that in Firefox, the containing element no longer scrolled with the mouse wheel or arrow keys! Apparently Firefox's scroll speed is proportional to font-size.

Dennis Ritchie, a name familiar to many programmers, passed away this week (Wednesday, October 12, 2011).

If you aren't familiar with what Dennis Ritchie contributed to programming, you can certainly search Google for the full list; but he is probably best known for being one of the people who designed both the C programming language and the original Unix operating system.