Ask for Help

“Ever since we upgraded to RSpec 1.2.9, we haven’t seen any stack traces. What gives?”

One of our projects lost stack traces as soon as they upgraded to RSpec 1.2.9. Reverting to RSpec 1.2.8 fixed the problem. No other projects have reported the issue yet.

Interesting Things

• Working with Rails for several years means that, as Rails advances, our testing/mocking codes get stale. We just discovered that one of our old mocks for representing the ‘flash’ object no longer works as designed with the current version of Rails.

More on the FlashHash

Here’s an approach that used to work in Rails 2.1/2.2:

• Stub FlashHash.new to create a MockFlashHash rather than a real
  FlashHash object.
• MockFlashHash does nothing when sweep is called. The sweep method cleans out the flashes that have been used, and the act of rendering uses up all of the flash.now objects.
• You can enhance MockFlashHash to behave the same way that a view would use a flash, allowing your tests to assert that a response should show a particular flash, without specifying whether you used flash or flash.now to do it.

Rails 2.3 changes the Flash cycle from what earlier versions of Rails did.

In Rails 2.2 and before, calling ‘flash’ accessed a session variable directly (assuming you have a session). You would then manipulate that session variable, which was an instance of FlashHash. It was therefore fairly easy to replace FlashHash with another type of object.

In Rails 2.3, the cycle is a little bit different. Instead of manipulating the session directly, calling ‘flash’ sets an instance variable. At the end of the request, that session variable is stored to the session using a new method signature – flash.store(session). (Note that flash extends Hash, so this overrides the standard Hash.store)

This approach breaks encapsulation, forcing the FlashHash object to know about the session and forcing any mock replacements to know how to store themselves to the session.

Ask for Help

“What’s a good design for sharing a page cache across multiple servers?”

One of our clients would like to have a distributed server environment share its page cache. At this point, they’re relying on GFS to do this.. but this solution appears to have problems with reliability.

Several engineers questioned the necessity for such a thing, but memcached appeared to be the solution of choice.

“Any information on RabbitMQ?”

One of our engineers is beginning to play with RabbitMQ. Anyone who has good comments about this technology, please feel free to chime in.

Interesting Things

• load “location” and require “location” do not play nicely with Rail’s automatic class reloading.

Rails maintains an internal array of files that it ‘knows’ about for this purpose. However, load and require bypass this mechanism, and lock files into place.

If you’d like to add a require that will class-reload, use the command ‘require_dependency “location”‘. This command, added by Rails, will require the file AND add it to ActiveSupport.