Launchpad

Branching is a great way to play with your code without risking the quality of your code. Many times when doing Rails development, I end up with branches that have slightly unique database schemas between them. This introduces a problem when you’re actively switching between branches and your development database is constantly out-of-sync. The best way that I’ve found to combat this problem is by creating a dynamic database configuration.

The Gem specification provides information about a Ruby Gem library, including title, description, author, and author email address, among many other things. The email address is an optional value, according to the specification, but most gem builders add it by default.

In my case, I generally do provide an email address in those specs which point to an inbox used solely for gems – which is to say, never used. Today, I’m happy to announce that I received my first spam message to it. I’ve been wondering just how long it would take for someone to start harvesting those specs for spam… and now I have my answer.

Often times when I come into an existing project, or even come back to a project I’ve been maintaining for a long time, I’m reminded of the importance of third party abstraction.

This type of abstraction provides your application with an insulation layer, a warm blanket if you will, against uncontrollable changes within the code which you do not directly maintain.

Phusion Passenger version 2.0.x and under are incompatible with Rails 2.3.×. This is a public service announcement to remind you to upgrade your application server in the event of a Rails upgrade.

Ruby on Rails gives you the ability to customize your page cache directory by specifying a config.action_controller.page_cache_directory in your environment configuration. For the purpose of this example, I’ll set mine to File.join(RAILS_ROOT, '/public/cache/'). It is in this directory that a new file will be created for each cached action request. Subsequently – only if your web server is configured properly – these static files will be served thereafter for each request. Page caching represents the best and fastest cache mechanism available in Rails since once the cache is created, Rails is no longer used at all.

There is however a catch with the page_cache_directory. It is a static class-level variable. That means, you cannot have it act dynamically based on any individual user or client request. So, if you’re building a multi-tenant application, where the content is unique to each subdomain requested, how do you properly separate (or segregate or silo) those cached files?

The Google hosted JavaScript libraries is a great service and another wonderful idea by the people at Google. Sharing large framework code between multiple sites not only makes your visitors happy – because they now only need to cache a potentially large library once – but also removes the burden of hosting and even updating that library, yourself.

That being said however, it is often necessary to extend the basic AJAX frameworks (jQuery, Prototype, Scriptaculous, etc.) with 3rd party or custom plugins. When using the Google hosted AJAX libraries, properly loading those plugins isn’t as straightforward as it used to be.

Shoulda is an excellent bit of icing for writing and maintaining your Ruby Test::Unit tests. The library is written and maintained by the great guys over at Thoughtbot. Shoulda comes with dozens of macros (which run several several specific tests in one line of code), custom assertions, and general features allowing you to write your tests in a far more easily understood format.

Now, just some of those custom assertions that I find myself using quite a bit are the assert_sent_email and assert_did_not_send_email. Actually, I pretty much use them all and then some. Anyway, getting back to the email assertions, the two don’t act the same out of the box. assert_sent_email can take a block which allows you to test for specific email criteria. assert_did_not_send_email, however, does not.