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:
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:
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.
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.
Shoulda gem is great not only because it provides you with a very clean and natural way of organizing tests with
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.
This is my list of TextMate‘s keyboard shortcuts that are very useful for Ruby and Rails developers, but are not used as widely as they should (according to my very scientific observation on a very representative sample, i.e. my colleagues). I skipped all the obvious ones (like “open file”, “save file”, “go to next window”, “close window” etc.) that most people use anyway. My list includes shortcuts that are very useful but sometimes might be hard to grasp at first or might require a little explanation.
I18n layer, introduced in Rails 2.2, is said to be “the simplest thing that ever could work”. Too bad they didn’t go for “the simplest thing that could be practical to use”. These two can be very far apart. I have a hard time imagining a real-world app using only bare Rails’ I18n engine.
Another unpleasant thing is that Rails 2.2 broke GetText compatibility, which prevents many projects from migrating to Rails 2.2 or later versions.
Well, not anymore. Thanks to clever guys Masao Mutoh and Michael Grosser, it’s finally possible to get Rails 2.2 running with GetText. Read on for details.
Small tip: when you happen to be running Rails in a console that doesn’t understand ANSI codes (those pesky
←[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
Put this in
config/environments/development.rb and restart
Took me a while to find it, so I thought I’d post it for posterity :)
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:
By turning off the
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.
…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.
Rails plugins are cool. Installing them as
svn:externals is cool (mostly). What is not so cool is that some plugins have
svn:externals incompatible URLs. In my current project there are two such plugins:
When you install them with
script/plugin install -x, they are installed as
trunk, respectively. This is because Rails’ plugin installer takes the final part of a URL as the plugin name and apparently there is no way to change it.
Of course, names like
trunk are not very good. In bigger projects with several plugins it may be difficult to remember which name points to which plugin. It’s also easy to imagine that someday we might want to use another plugin that has a URL ending with
You cannot change names of external directories with
svn move and
mv tool also doesn’t seem to work. Fortunately, I found other ways to fix this situation.
The scaffold_resource generator is quite cool, but lacks one feature that my team found quite useful. Sometimes we want to generate RESTful scaffold with different names for model and controller.
Why would we want that? Well, mostly because in some cases we want to have two separate controllers for one model. The ﬁrst controller contains ordinary functionality and the second — stuff only an admin can use. We feel that this separation is helpful for maintenance.
For example, we want to have
User model class,
UsersController accessed as
/users/... with methods for signup, user proﬁle edition etc. and
AdminUsersController accessed as
/admin_users/... with administrative functionality like deleting, granting or revoking access rights etc.
Unfortunately, Rails’ standard
scaffold_resource generator only accepts model name and derives all other names from that. So it’s either
AdminUsersController. One possible solution is to generate it both ways, then delete
AdminUser and manually change
AdminUserController and its views to use
User instead. This requires editing several ﬁles which is tedious and error-prone.
‘There must be a better way’ we said to ourselves and indeed there is: write your own
One of the many cool things of Ruby on Rails are magic ﬁnders, or Dynamic attribute-based ﬁnders as the documentation calls them. Thanks to them we can write:
User.find(:first, ['login = ? and status = ?', some_login, 1])
The ﬁrst form is shorter and easier for human to parse.
Unfortunately, we can only combine attributes using
and operator, but the possibility to use
not operators would also be nice. And, as always when using Ruby on Rails, when we ﬁnd that library is lacking some feature, we can easily add it. Let’s see how to do it.
…or is my friend’s friend my friend too?
Recently I tried to implement a feature that is commonly used in social sites like Xing or Linked-in: a friends list, also known as buddy list or contacts list. Basically this means that a user can link to any other user to indicate that they are friends or know each other. Normally, the other party has to conﬁrm the link proposition for the link to be established. Having a contact network, the site can implement various cool features, like ﬁnding the shortest path between two random users or telling you that there are ’820 contacts of your contacts’.
Implementing this proved not to be that easy in Ruby on Rails, partly because of lack of documentation and mostly because of my poor knowledge of Rails, so here’s a solution that works for me. It should be noted that this is rather a story of trial and error (although I will spare you visiting all the blind alleys with me) than an emanation of guru-like knowledge, so if anyone knows a better way, I’ll be glad to hear about it.