Monkeypatching for cleaner code

Recently, after reading Object on Rails, I started thinking and experimenting with various ideas of making Rails applications code cleaner. Here’s one of these ideas.

Let’s imagine we have two model classes, connected with a has-many/belongs-to relation, e.g.:

# file user.rb
class User < ActiveRecord::Base
  has_many :posts, dependent: :destroy
  # ...
  # rest of the user stuff
  # ...
end

# file post.rb
class Post < ActiveRecord::Base
  belongs_to :author, class: "User"
end

The above code is probably how most of Rails programmers would go about implementing a “user has many posts/post belongs to its author” scenario. It’s the tutorials-approved way. But when you look at it from a architectonic point of view, you have just created a circular dependency.

Introducing Rails Routes TextMate bundle

I always have a problem parsing Rails‘ named routes in my head. It usually takes me a lot of time and effort to decide which controller action or view file is responsible for given path. Of course, it’s easy to tell when you look at:

edit_user_path(@user)

that you probably should go to users_controller.rb and find edit action and views/users/edit.html.haml is the right view file. But when nested routes, prefixes and non-RESTful actions all come to play, you might end up with a monster like:

precreate_new_employer_employer_account_path

Don’t laugh, this is real. So, what’s going on here? What is the action name? Are those “employer” things prefixes or nested routes? Where do I find the view? To answer all these questions, the Rails Routes TextMate bundle was born.

Using assert’s message to boost your unit testing productivity

Here’s a quick tip for enhancing your test writing productivity: use assert‘s last parameter, the message. Virtually all assert_... methods accept it. You may have noticed in the docs that the last parameter is always message = nil or message = "". Too bad the docs don’t give examples on how to use this message. So, let me fix that.

Custom Shoulda macros — a tutorial

Shoulda gem is great not only because it provides you with a very clean and natural way of organizing tests with context and should building blocks, but it also comes with quite a large set of predefined macros that mirror Rails’ validations, relations etc. What’s even better — it’s very easy to create your own macros to further speed up test writing. Modern versions of Shoulda gem allow to do it in a clean and modular way. That’s great news if you are serious about TDD because for every substantial codebase you will end up with even bigger pile of testing code, so any tool helping in encapsulating common test logic or patterns is priceless.

This article is a tutorial on writing custom Shoulda macros: from very simple to quite complex.

How to: turn off ANSI codes in Rails console

Small tip: when you happen to be running Rails in a console that doesn’t understand ANSI codes (those pesky ←[4;36;1m and ←[0;1m that clutter your display), like for example Windows’ cmd, you can turn them off with:

if RUBY_PLATFORM =~ /mswin32/
  ActiveRecord::Base.colorize_logging = false
end

Put this in config/environments/development.rb and restart script/server.

Took me a while to find it, so I thought I’d post it for posterity :)

Breadcrumbs II: the Internationalization

This is a quick followup to my breadcrumb solution. If your application is internationalized, I think you might be interested in the code presented below. If not, stick with the original version.

Easy and flexible breadcrumbs for Rails

Most projects I work on require some implementation of breadcrumbs. Unfortunately most solutions that I found take the very simplistic approach: they split the URL and present each part as a link. I really have a hard time imagining that this can be sufficient for any non-trivial app.

I also found session-based implementation, but according to the above mentioned Wikipedia article classification these are path-style breadcrumbs, while I need location-style with a little bit of attribute-style mixed in where needed. That is, the breadcrumbs should normally reflect the page’s location in some (virtual) website hierarchy. Sometimes, while browsing things that are naturally hierarchical (like forum threads/posts, category trees and so on), the breadcrumb trail should also reflect this hierarchy. Read on to see my take on this problem.

Multilingual page caching in Ruby on Rails

There is plenty of stuff written about caching in Ruby on Rails. You can easily cache anything from objects returned by a query to fragments or even whole pages. Especially storing full pages (known as page caching) in a directory when Apache¹ can grab them is really efficient. And there are quite decent tutorials about it.

Sadly, most of the tutorials assume that you live in a small, cozy, speak-english-or-die type of world and your only contact with foreign languages is when you order “pommes frites” at MacDonald’s.² The rest of us, working on multilingual applications, might have a lot of problems with implementing page caching. Fortunately, it’s not that difficult. Read on to see for yourself.

Cookie handling in multi-domain applications in Ruby on Rails

My team is working on a multilingual multinational application in Rails (I know this sounds incredibly pushy but bear with me). The application is at susuh.de if you want to have a look at it, but it’s still alpha version.

In practice, this multi-multi-blah-blah means that we want to use both various national domains (like susuh.at, susuh.pl — those links don’t function yet, they are only examples) and various subdomains (like pl.susuh.de or en.susuh.pl). The national domains will filter content only to respective country (so susuh.de will only have content from Germany) and the subdomains will be used to change the default language for the national domain (so if you are an English-speaking person living in Germany, en.susuh.de is your place to go). The subdomain will also be important in multilingual countries like Switzerland.

Trying to implement this scheme we’ve run into problems with cookie domain handling in Rails. And cookie problems lead to session problems for users, like being erroneously logged out or loosing other settings.

Mandatory Cookie-monster reference (you wouldn’t believe how many hits from Google this provides).

It seems that there are two official (normal) ways of handling this — at least that’s what Google says. Either you set your default session options in environment.rb like this:

ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:session_domain] = 
  '.susuh.de'

Or you don’t set it at all.

The former lets you set cookies for any subdomain of susuh.de, like pl.susuh.de, but no other domain. The latter sets cookie independently for each subdomain, causing different cookies for pl.susuh.de, en.susuh.de and susuh.pl. Neither is what we really want.

So tell me what you want, what you really really want?

What we really want is to have the same cookie for any subdomain of susuh.eu and a different one for any subdomain of susuh.pl and so on. Nota bene, I’m not talking about a Single Sign-On problem, this is on much more basic level. We tried experimenting with setting DEFAULT_SESSION_OPTIONS “on the fly” in before_filter, but found out that this is too late (basically, this sets cookie domain for next request).

Fortunately, all is not lost. If all else fails, start reading code. And that’s what I did. The “entry point” for Rails is defined in dispatcher.rb file. Glancing over the code, I noticed something new for me: a before_dispatch callback. Google agreed that this may be a way to go, giving us link to http://m.onkey.org/2007/10/16/dispatcher-callbacks, among others.

Here’s our solution:

require 'dispatcher'
module ActionController
  class Dispatcher
    def set_session_domain
      ApplicationController.session_options.update(
        :session_domain => "#{@request.host.gsub(/^[^.]*/, '')}"
      )
    end
    
    before_dispatch :set_session_domain
  end
end

Does stubbing make your tests brittle?

Stubbing and mocking in unit tests is generally considered a Good Thing. It can make your tests run faster, it helps you not to cross boundaries. But it also makes your tests more brittle.

The reason for this is simple. If you want to stub out some method, you have to do it very precisely. You have to know the underlying implementation and choose a very concrete instance and method for stubbing. This makes your test very tightly coupled to the implementation details of tested class. And tightly coupled is brittle. Let’s look at some trivial example:

Make your tests run 25% faster

How?

By turning off the use_instantiated_fixtures feature.

But why?

Because they’re slow! Didn’t you read the comment in your test_helper.rb? Yes, this one:

# Instantiated fixtures are slow, but give you @david where otherwise you 
# would need people(:david).  If you don't want to migrate your existing 
# test cases which use the @david style and don't mind the speed hit (each 
# instantiated fixtures translates to a database query per test method), 
# then set this back to true.

But what about those nice @david variables?

They must be gone. Sorry. The tests are slow because of them. The above comment explains why.

Looping in a no man’s land

…or: how to put class scope to use

The class scope, i.e. the space inside class declaration, but outside method definitions, is a no man’s land in many languages (particularly in Java). By this I mean that you can define methods, variables, and other classes there and you can even execute some code (in variable initializations) but nothing more. Fortunately, in Ruby empty space between method definitions can be filled with all kinds of useful, executable code. Let’s check a few examples.