Over the course of a Rails project, views that started out very simple can evolve into a complex mix of HTML with complicated nested Ruby conditionals. They become hard to understand, hard to read and hard to work with. Fixing an edge case in those views may involve the painstaking process of writing of an end-to-end test to ensure the bug has been squashed. Those kind of tests have quite an impact on the overall runtime of the test suite, so typically you don’t want to write too many of them. Especially not for edge cases. The more end-to-end tests you have, the harder it becomes to make changes to your views because the tests have all kinds of expectations of them.

RSpec offers an extensive, flexible DSL to write your tests. But due to its extensive arsenal of matchers, RSpec requires some more effort to use properly than some other testing frameworks like Minitest.

Using decorators in Ruby on Rails has many benefits. Models become less fat, views less complicated, and using the procedural view helpers becomes a thing of the past.

I was recently cleaning up unused indexes and I found quite a few. These were mostly part of join models from which a reverse association wasn’t required. Consider the following example:

Let’s say you want to import all Belgian beers from a beer export CSV and then save them to your database. After some quick hacking, something like this emerges:

Query objects are a fairly well known concept in Rails these days. They’re useful to extract complex SQL queries into their own classes, which would otherwise clutter ActiveRecord models. What if you turned a complex scope which is already used all over your application into a query object? Do you have to refactor all of these occurences?

In a Ruby on Rails application, it’s not uncommon to encounter code which reaches deep into the internals and database schema of a model.

Nithin Bekal wrote an excellent post on how to use gradual engagement in Ruby on Rails for guest users by allowing them to publish posts to a site without actually registering.

Imagine we’ve got a Rails application where users can view each other’s profiles. We’d like to enable them to make their profile personal and unique by customizing the background and text colors used to display their profile. In nearby the future, there will likely be many more adjustments users can make to their profile theme. So what would be a good approach for this problem that conforms to the Rails way?

Controller filters are a common sight in Ruby on Rails controllers. The before_filter specifically can be used to halt the request cycle. This is useful to prevent unauthorized access to controller actions, but it’s also very often used to load database records.

A common practice in Ruby on Rails applications is to have a HomeController to render the homepage, which doesn’t directly translate into a resource.

Keeping Rails views DRY can sometimes be difficult when there are small differences between pages. Let’s find the best way to keep views simple and DRY.

In some cases, you want an object that behaves like an ActiveRecord relation but does not contain any objects. In Rails 4, you can call none on a relation and it returns an empty relation:

In Ruby on Rails, it’s easy to set the application-wide default to never render a layout in response to XHR requests. Just include this single line in your ApplicationController:

Kernel#Array converts an object to an Array by calling to_ary or to_a on the object passed into it. This works very well to convert most objects into an array:

Nokogiri is a full-featured XML and HTML parser and builder. It also allows you to search XML and HTML documents with CSS and XPath selectors. You can also use it to transform XML documents into some other format using XSLT templates.

ActiveModel::Dirty is responsible for tracking the changes to attributes in an active model. This often comes in handy with ActiveRecord callbacks to perform certain actions only if some attribute’s value changed.

This test configuration uses Guard with Spork for running tests fast. It generates combined Simplecov code coverage reports for RSpec and Cucumber tests. It turns off garbage collection while running RSpec examples for increased performance. It uses FactoryGirl as a fixtures replacement.

A frequent bit of code seen throughout applications looks like this:

Sometimes it’s useful to have the same route conditionally map to different controllers. To illustrate this, imagine we have a blog with categories and posts, each of which have a similar URL, /some-category for categories and /some-post for posts. Our routes.rb file looks something like this:

Haml makes it incredibly easy to render your HTML views. It’s cleaner than HTML because it relies on indentation to define the element tree structure rather than closing tags.