Crafting Ruby

I'm not testing those stupid views!

Tue, 25 Oct 2016 00:00:00 +0000

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.

Keeping views as stupid as possible is important. The complicated logic in views is hard to test because you need to think a lot about things like HTML, clicking buttons and CSS selectors.

A simple solution to the problem is to move the logic into separate classes. Logic in separate classes can easily be unit tested. Unit tests run fast and are the cheapest kind of tests to write.

Consider this contrived example of a view with a bit of complex logic:

<div class="checkout">
  <% if @order.line_items.count > 0 %>
    <% if (@order.total - @order.paid) > 0 %>
      <div class="outstanding-amount"><%= number_to_currency(@order.total - @order.paid) %></div>
    <% end %>
    <div class="all-the-line-items"></div>

    <% if @order.cancelled_at.nil? && (@order.total - @order.paid) > 0 %>
      <%= link_to "Cancel your order", cancel_order_path(@order) %>
    <% end %>
  <% else %>
    Your order is empty!
  <% end %>
</div>

You need to think in order to understand what’s going on here. Especially that if condition may keep you occupied for a while.

In Rails projects the obvious candidates to move the logic to are the view decorators. Try to move only the logic and keep HTML rendering out of the decorators as much as possible. Writing tests for rendered HTML is a lot harder than writing a test for a simple return value.

One decorator doesn’t necessarily need to be the container for all the logic. You can create a decorator for only a single page or a specific section of the page. A decorator can also delegate the logic to other classes that aren’t decorators. I’ve written more about splitting up decorators in Rails Anti-Pattern: Fat Decorator.

For the above view, such a decorator may look like this:

class OrderDecorator < Draper::Decorator
  delegate_all

  def checkout_possible?
    line_items.count > 0
  end

  def can_be_cancelled?
    cancelled_at.nil? && !complete?
  end

  def complete?
    unpaid == 0
  end

  def unpaid
    total - paid
  end
end

Once the logic has been extracted into a decorator, the view became more pleasant to read:

<div class="checkout">
  <% if @order.checkout_possible? %>
    <% unless @order.complete? %>
      <div class="outstanding-amount">$ <%= number_to_currency(@order.unpaid) %></div>
    <% end %>
    <div class="all-the-line-items"></div>

    <% if @order.can_be_cancelled? %>
      <%= link_to "Cancel your order", cancel_order_path(@order) %>
    <% end %>
  <% else %>
    Your order is empty!
  <% end %>
</div>

Once the views become completely obvious there’s hardly a need to test any edge cases. Mistakes can be caught just as good by the naked eye rather. Time is saved by writing simple tests rather than complicated end-to-end tests. The test suite runs faster so your TDD cycle is hardly slowed down. Keeping your views stupid saves you some energy because you don’t have to be vigilant all the time.

Cleaner RSpec examples and failure messages

Tue, 15 Dec 2015 07:20:00 +0000

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.

Have a look at the following spec:


RSpec.describe ShoppingCart, type: :model do
  let(:shopping_cart) { subject }

  describe '#to_order' do
    let(:product1) { create(:product, price: 10) }
    let(:product2) { create(:product, price: 3) }
    let(:user) { create(:user) }

    before do
      shopping_cart.insert(product1, quantity: 2)
      shopping_cart.insert(product2)
    end

    it 'has the correct attributes' do
      order = shopping_cart.to_order(user)

      expect(order.price).to eq(23)
      expect(order.user).to eq(user)
    end

    it 'adds the products to the order' do
      line_items = shopping_cart.to_order(user).line_items

      expect(line_items[0].product).to eq(product1)
      expect(line_items[0].quantity).to eq(2)
      expect(line_items[1].product).to eq(product2)
      expect(line_items[1].quantity).to eq(1)
    end
  end
end

It kind of gets the job done, but it’s not super easy to read. It doesn’t really feel like the RSpec way of doing it, especially not with those local variable assignments. Lastly, it forces a specific sorting order of line items in the last example. I’m absolutely not a fan of enforcing unnecessary implementation details as a side-effect.

Built-in matchers

RSpec comes with a whole bunch of built-in matchers for your expectations. Its documentation extensively describes the built-in matchers and argument matchers.

These matchers can be used in a lot of different situations. One that would come in handy here is have_attributes and its alias an_object_having_attributes:


RSpec.describe ShoppingCart, type: :model do
  let(:shopping_cart) { subject }

  describe '#to_order' do
    let(:product1) { create(:product, price: 10) }
    let(:product2) { create(:product, price: 3) }
    let(:user) { create(:user) }

    before do
      shopping_cart.insert(product1, quantity: 2)
      shopping_cart.insert(product2)
    end

    it 'has the correct attributes' do
      expect(shopping_cart.to_order(user))
        .to have_attributes(price: 23, user: user)
    end

    it 'adds the products to the order' do
      expect(shopping_cart.to_order(user).line_items).to contain_exactly(
        an_object_having_attributes(product: product1, quantity: 2),
        an_object_having_attributes(product: product2, quantity: 1)
      )
    end
  end
end

Now the sort order of the line items became irrelevant thanks to contain_exactly.

Using the appropriate matchers can make a spec almost read like human language. There’s not really a lot of logic involved that needs to be understood to figure out what the examples do.

Another nice resource is this list of available matchers in RSpec 3 and their aliases.

Cleaner failure messages

A great disadvantage of using a matcher like have_attributes is that combined with ActiveRecord objects, it can easily fill your whole screen with a single failure message, printing out only a few objects:

Failures:

1) ShoppingCart#to_order adds the products to the order
   Failure/Error: expect(shopping_cart.to_order(user).line_items).to contain_exactly(
     expected collection contained:  [(an object having attributes {:product => #<Product id: 1, name: "Product #3", price: 10, created_at: "2015-12-14 22:42:05", updated_at: "2015-12-14 22:42:05">, :quantity => 2}), (an object having attributes {:product => #<Product id: 2, name: "Product #4", price: 3, created_at: "2015-12-14 22:42:05", updated_at: "2015-12-14 22:42:05">, :quantity => 1})]
     actual collection contained:    [#<LineItem id: 1, product_id: 1, order_id: 1, quantity: 1, created_at: "2015-12-14 22:42:05", updated_at: "2015-12-14 22:42:05">, #<LineItem id: 2, product_id: 2, order_id: 1, quantity: 1, created_at: "2015-12-14 22:42:05", updated_at: "2015-12-14 22:42:05">]
     the missing elements were:      [(an object having attributes {:product => #<Product id: 1, name: "Product #3", price: 10, created_at: "2015-12-14 22:42:05", updated_at: "2015-12-14 22:42:05">, :quantity => 2})]
     the extra elements were:        [#<LineItem id: 1, product_id: 1, order_id: 1, quantity: 1, created_at: "2015-12-14 22:42:05", updated_at: "2015-12-14 22:42:05">]
   # ./spec/models/shopping_cart_spec.rb:22:in `block (3 levels) in <top (required)>'

This kind of spam is ridiculous. Most of this information we don’t care about, and it’s only distracting from what does matter.

One option would be to modify the objects being checked in a way to produce simpler failure messages, such as below:


it 'adds the products to the order' do
  line_items = shopping_cart.to_order(user).line_items.map do |item|
    item.slice(:product, :quantity)
  end

  expect(line_items).to contain_exactly(
    { 'product' => product1, 'quantity' => 2 },
    { 'product' => product2, 'quantity' => 1 }
  )
end

I’m not a fan of this approach at all. It simplifies the failure message, but it complicates the spec by adding logic. Every time you read the spec, you need to wade through this logic to understand the examples.

It’s actually quite easy to customize the way objects are being printed without having to compromise conciseness of the specs. Simply by overriding the inspect method you can alter the output of objects in a failure message:

class LineItem < ActiveRecord::Base
  belongs_to :product
  belongs_to :order

  def inspect
    "#{quantity} x #{product.inspect}"
  end
end

class Product < ActiveRecord::Base
  def inspect
    name
  end
end

With the irrelevant noise removed the failure message now becomes readable:

Failures:

1) ShoppingCart#to_order adds the products to the order
 Failure/Error: expect(shopping_cart.to_order(user).line_items).to contain_exactly(
   expected collection contained:  [(an object having attributes {:product => Product #3, :quantity => 2}), (an object having attributes {:product => Product #4, :quantity => 1})]
   actual collection contained:    [1 x Product #3, 1 x Product #4]
   the missing elements were:      [(an object having attributes {:product => Product #3, :quantity => 2})]
   the extra elements were:        [1 x Product #3]
 # ./spec/models/shopping_cart_spec.rb:22:in `block (3 levels) in <top (required)>'

If you rely heavily on inspecting objects using pp, this approach might not be convenient since it will overwrite the pretty print output with the custom inspect output. For custom objects, you can easily override pretty_print to have pp print a more detailed output if you need it:

class SomeObject
  def inspect
    'Test'
  end

  def pretty_print(pp)
    pp.pp_object(self)
  end
end

For ActiveRecord objects however, this doesn’t produce great output. There’s not really a nice way around it, the best I found is to override a private method to have ActiveRecord print out the useful output it did before:

class SomeObject < ActiveRecord::Base
  def inspect
    'Test'
  end

  private

  def custom_inspect_method_defined?
    false
  end
end

Conclusion

Being more aware of the matchers RSpec offers, it allows you to write clean, concise and elegant examples. It’s worth taking a moment to browse the available matchers from time to time. After writing an example, take a step back and wonder if there’s a better way to write it. After some time you become aware of a lot more possibilities write cleaner specs, and thus reduce their complexity.

The full source project for the code above can be found on this Github repository.

What are your favourite RSpec matchers? Let me know in the comments down below!

Rails Anti-Pattern: Fat Decorator

Wed, 09 Dec 2015 07:20:57 +0000

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.

When applying decorators to your Rails project, you might be tempted to maintain a 1:1 mapping between models and decorators. All the presentation logic of a Article would go into an ArticleDecorator. While the decorators are small, this may be a valid approach.

But over time, the decorators will grow as requirements are added. They’ll collect more and more methods, get more responsibilities and slowly the decorators grow fat. Bugs will soon creep out from under the big pile of methods.

Stuffing everything inside a single decorator isn’t really a big step up from using Rails’ view helpers. If you want to get the most out of decorators, it’s important to apply the principles of object oriented programming to them as well.

Here are a couple of code smells I commonly find in decorators.

Divergent Change

Large decorators often span multiple pieces of functionality. As requirements change, one decorator finds itself changed multiple times for different requirements. This smell is called Divergent Change.

It’s an indicator that the Single Responsibility Principle is being violated. And no, “taking care of presentation logic” doesn’t count as a single responsibility here ;-) Groups of closely related methods responsible for a single part of functionality should probably be moved out into their own classes.

Feature Envy

When moving unnecessary logic out of a view, it’s often placed into the nearest possible decorator. When doing this, a decorator will start to reach deep into other objects and eventually will be more concerned with other objects rather than itself.

This this introduces a lot of coupling between objects and makes it hard to refactor. This kind of functionality needs to be moved to a more appropriate decorator.

A smelly decorator

Here’s a decorator to handle the presentation logic of a Git commit. I’ve omitted quite some parts for brevity of the example. I’m using the Draper gem, though you could go with any other solution, or even your own.

class CommitDecorator < Draper::Decorator
  delegate_all

  def author_link
    h.link_to(author.name, h.profile_path(author.username))
  end

  def parent_link
    h.link_to(parent.truncated_sha, h.project_commit_path(project, parent.sha))
  end

  def diff_stats
    h.t('commits.show.diff_stats_html',
        changed: diffs.count,
        additions: diffs.sum(&:additions),
        deletions: diffs.sum(&:deletions))
  end

  def file_changes
    diffs.map do |diff|
      DiffLine.new(
        status_class_for(diff), diff.path, diff.additions, diff.deletions)
    end
  end

  private

  DiffLine = Struct.new(:status_class, :path, :additions, :deletions)

  def status_class_for(diff)
    if diff.deleted?
      'deletion'
    elsif diff.added?
      'addition'
    else
      'change'
    end
  end
end

A commits controller may look like this:

class CommitsController < ApplicationController
  decorates_assigned :commits, :commit

  def index
    @commits = find_project.commits
  end

  def show
    @commit = find_project.find_commit_by_sha(params[:sha])
  end

  private

  def find_project
    Project.find(params[:project_id])
  end
end

There are two scenarios here:

A list of commits in the project is displayed
One commit is displayed along with its changed files

Problems

The decorator incorporates both of the smells described above.

It seems awkward to have a decorator with all these functionalities if all you want to do is to display a summarized commit with only a bit of information.

It’s reaching into the tiny little details of the other objects quite a lot. It’s very coupled to the internals of diffs especially.

Making it less envy

The most alarming issue is the reaching into diffs to gather the file changes. Let’s quickly refactor that into a DiffDecorator:

class DiffDecorator < Draper::Decorator
  delegate_all

  def status_class
    if deleted?
      'deletion'
    elsif added?
      'addition'
    else
      'change'
    end
  end
end

Note how much that already cleans up the CommitDecorator. The file_changes is now synonymous to the decorated diffs. I’ve added an alias_method to keep the same interface, though this is not strictly necessary.

class CommitDecorator < Draper::Decorator
  delegate_all
  decorates_association :diffs

  alias_method :file_changes, :diffs

  def author_link
    h.link_to(author.name, h.profile_path(author.username))
  end

  def parent_link
    h.link_to(parent.truncated_sha, h.project_commit_path(project, parent.sha))
  end

  def diff_stats
    h.t('commits.show.diff_stats_html',
        changed: diffs.count,
        additions: diffs.sum(&:additions),
        deletions: diffs.sum(&:deletions))
  end
end

The links to the author and parent commit are better off in their own decorator too. Since parent is also a commit object itself, this implies adding a link method to CommitDecorator.

class AuthorDecorator < Draper::Decorator
  delegate_all

  def link
    h.link_to(name, h.profile_path(username))
  end
end

class CommitDecorator < Draper::Decorator
  delegate_all
  decorates_association :diffs
  decorates_association :author
  decorates_association :parent

  alias_method :file_changes, :diffs

  delegate :link, to: :author, prefix: true
  delegate :link, to: :parent, prefix: true

  def link
    h.link_to(truncated_sha, h.project_commit_path(project, sha))
  end

  def diff_stats
    h.t('commits.show.diff_stats_html',
        changed: diffs.count,
        additions: diffs.sum(&:additions),
        deletions: diffs.sum(&:deletions))
  end
end

Now the CommitDecorator only has some delegations for the author_link and parent_link.

Dealing with Divergent Change

I always like to have some kind of default or base decorator for a model which defines the methods commonly used in different contexts. It makes sense for this to be called CommitDecorator. Whenever commit.decorate is called, it’s automatically decorated with the default decorator.

Some decorated functionality may only be required in a single context. I prefer to put these into their own decorator classes, so it becomes more obvious where it’s being used, and it’s not hiding in between the common functionality.

For this example, I’d consider a summarized commit sufficient to be decorated by a default decorator. But the detailed commit definitely needs its own:

module Commits
  class DetailedCommitDecorator < Draper::Decorator
    delegate_all

    def initialize(*args)
      super(CommitDecorator.new(*args))
    end

    def diff_stats
      h.t('commits.show.diff_stats_html',
          changed: diffs.count,
          additions: diffs.sum(&:additions),
          deletions: diffs.sum(&:deletions))
    end
  end
end

I always namespace these context-specific decorators by the class they’re decorating. When you’ve got many decorators, this allows you to still have an overview.

I dislike using inheritance with decorators, it feels to be against the nature of a decorator. It’s also confusing when overriding methods from the parent class. Overriding inherited methods may need another approach than overriding methods already defined on the model.

Therefore, I first wrap the original commit object into a CommitDecorator. This would be equivalent to doing something like Commits::DetailedCommitDecorator.new(CommitDecorator.new(commit)), but I don’t want to have to think about applying both decorators all the time. Note I’m using delegate_all in all of my decorators to make sure any method unknown to the decorator is being delegated to the decorated object.

Extracting the functionality of a detailed commit leaves the CommitDecorator greatly simplified:

class CommitDecorator < Draper::Decorator
  delegate_all
  decorates_association :diffs
  decorates_association :author
  decorates_association :parent

  alias_method :file_changes, :diffs

  delegate :link, to: :author, prefix: true
  delegate :link, to: :parent, prefix: true

  def link
    h.link_to(truncated_sha, h.project_commit_path(project, sha))
  end
end

The last thing to do is to make sure the controller applies the appropriate decorators:

class CommitsController < ApplicationController
  decorates_assigned :commits
  decorates_assigned :commit, with: Commits::DetailedCommitDecorator

  def index
    @commits = find_project.commits
  end

  def show
    @commit = find_project.find_commit_by_sha(params[:sha])
  end

  private

  def find_project
    Project.find(params[:project_id])
  end
end

Conclusion

Avoid turning your decorators into your view helper surrogates. Avoid creating a tangled mess of methods and responsibilities by appropriately dealing with code smells in your decorators. Don’t be afraid to introduce new decorator classes, but only do so if you can justify their existence.

What kind of code smells do you frequently encounter in your decorators? Let me know in the comments below!

Don't index the kitchen sink!

Thu, 09 Jul 2015 13:13:00 +0000

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:

class ShoppingCart < ActiveRecord::Base
  has_many :shopping_cart_products
  has_many :products, through: :shopping_cart_products
end

class ShoppingCartProduct < ActiveRecord::Base
  belongs_to :shopping_cart
  belongs_to :product
end

class Product < ActiveRecord::Base
end

A very basic design for shopping carts containing products.

The ShoppingCartProduct model has been created using Rails’ model generator, which creates the model class with associations, as well as a migration:

bin/rails g model CartProduct quantity:integer{1} user:belongs_to product:belongs_to –no-test-framework

class CreateShoppingCartProducts < ActiveRecord::Migration
  def change
    create_table :shopping_cart_products do |t|
      t.integer :quantity, limit: 1, null: false
      t.belongs_to :shopping_cart, index: true, foreign_key: true
      t.belongs_to :product, index: true, foreign_key: true

      t.timestamps null: false
    end
  end
end

As a good practice, the quantity column has been set to disallow null values. Note the two indexes on shopping_cart_products which were created by default.

It doesn’t actually make a lot of sense to ever display which shopping carts a specific product is in. That means it’s not necessary to be able to query a ShoppingCartProduct by its product_id, thus that index is unused. Since Rails generated the model and migration for us, it snuck in really quietly.

An unused index is a waste of database resources. It takes up storage space, and it slows down UPDATEs and INSERTs, in this case on the shopping_cart_products table.

Getting rid of this unused index is easy:

class RemoveIndexShoppingCartProductsOnProductId < ActiveRecord::Migration
  def up
    remove_index(:shopping_cart_products, :product_id)
  end

  def down
    add_index(:shopping_cart_products, :product_id)
  end
end

Always be conscious about adding database indexes. Only add one if you’re really sure you need it.

As application requirements may change over time, so may the need for indexes. Use database tools to regularly monitor for potentially unused indexes. Be sure to monitor it on the production environment to get the best results.

Using Enumerable as testing abstraction

Tue, 07 Jul 2015 22:14:00 +0000

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:

class BelgianBeerImport
  def initialize(io)
    @io = io
  end

  def import!
    CSV.parse(io.read, headers: true) do |row|
      next unless row[:country] == 'Belgium'

      Beer.create_from_import!(name: row[:name],
                               brewery_name: row[:brewery],
                               country_name: row[:country])
    end
  end
end

There’s even a test for this. Note how it’s cleverly using a StringIO here to get the data in there without using a file:

class BelgianBeerImportTest < ActiveSupport::TestCase
  def test_import_belgian_beers_from_csv
    io = StringIO.new(
      "name,brewery,country\n" \
      "Grimbergen Blonde,Brouwerij Alken-Maes,Belgium\n" \
      "Oatmeal Stout,Left Hand Brewing Company,United States\n" \
      "Grolsch Premium Weizen,Grolsche Bierbrouwerij,Netherlands\n" \
      "Straffe Hendrik Brugse,De Halve Maan,Belgium"
    )

    assert_difference('Beer.count', +2) do
      BelgianBeerImport.new(io).import!
    end

    # Or however something as complicated as this is tested...
    beer1, beer2 = Beer.last(2)

    assert_equal('Grimbergen Blonde', beer1.name)
    assert_equal('Brouwerij Alken-Maes', beer1.brewery_name)

    assert_equal('Straffe Hendrik Brugse', beer2.name)
    assert_equal('De Halve Maan', beer2.brewery_name)
  end
end

This looks overly complicated though. The test is not only testing the BelgianBeerImport class, but also the CSV class and ActiveRecord itself. In fact, the tests are even hitting the database to verify that the system under test works.

The class is also restricted to importing CSV data. In fact, the test is supplying CSV data, adding another layer of complexity, since you need to provide valid CSV. One typo could ruin the beerfest, making this test rather brittle.

Enumerable, the coolest Ruby module

Enumerable is awesome! I can go on about it for hours, but many others have already done it before me, so I’ll skip on its basics.

The important part is that almost every Ruby developer knows its interface. Array and Hash are enumerable. So are Set, Range, IO, StringIO, File (IO is its parent), Dir, CSV, Struct and even more.

On each of these classes you can use the greatness that Enumerable provides:

# Find all elements matching /apple/
%w(apple pear banana pineapple).grep(/apple/)

# List all file names in the current folder
Dir.new('.').to_a

# Get the longest line in a file, not counting surrounding whitespaces
File.new('Gemfile').map(&:strip).max_by(&:length)

Great, so how does this help here?

Well, CSV is enumerable too. BelgianBeerImport should be refactored to take advantage of this fact. If we can abstract away from using CSV, it opens up interesting opportunities for our test and codebase.

class BelgianBeerImport
  def initialize(io)
    @csv = CSV.new(io, headers: true)
  end

  def import!
    @csv.each do |row|
      next unless row[:country] == 'Belgium'

      Beer.create_from_import!(name: row[:name],
                               brewery_name: row[:brewery],
                               country_name: row[:country])
    end
  end
end

Now we’re creating an instance of CSV and using each to enumerate through the CSV row objects. The tests still pass so all is good!

This can be taken a lot further though. This test is still testing CSV and ActiveRecord. Let’s inject them as dependencies:

class BelgianBeerImport
  def initialize(csv, repository = Beer)
    @csv, @repository = csv, repository
  end

  def import!
    @csv.each do |row|
      next unless row[:country] == 'Belgium'

      @repository.create_from_import!(name: row[:name],
                                      brewery_name: row[:brewery],
                                      country_name: row[:country])
    end
  end
end

The test has to be adjusted accordingly to pass in the CSV object:

class BelgianBeerImportTest < ActiveSupport::TestCase
  def test_import_belgian_beers_from_csv
    io = StringIO.new(
      "name,brewery,country\n" \
      "Grimbergen Blonde,Brouwerij Alken-Maes,Belgium\n" \
      "Oatmeal Stout,Left Hand Brewing Company,United States\n" \
      "Grolsch Premium Weizen,Grolsche Bierbrouwerij,Netherlands\n" \
      "Straffe Hendrik Brugse,De Halve Maan,Belgium"
    )

    assert_difference('Beer.count', +2) do
      BelgianBeerImport.new(CSV.new(io, headers: true)).import!
    end

    # Or however something as complicated as this is tested...
    beer1, beer2 = Beer.last(2)

    assert_equal('Grimbergen Blonde', beer1.name)
    assert_equal('Brouwerij Alken-Maes', beer1.brewery_name)

    assert_equal('Straffe Hendrik Brugse', beer2.name)
    assert_equal('De Halve Maan', beer2.brewery_name)
  end
end

It’s time to have a good look at the BelgianBeerImport class and squeeze your eyes. If you stop thinking about @csv to be a CSV object and row to be a CSV row and think about it as an Enumerable, it suddenly looks an awful lot like an array containing hashes!

class BelgianBeerImport
  def initialize(beers, repository = Beer)
    @beers, @repository = beers, repository
  end

  def import!
    @beers.each do |beer|
      next unless beer[:country] == 'Belgium'

      @repository.create_from_import!(name: beer[:name],
                                      brewery_name: beer[:brewery],
                                      country_name: beer[:country])
    end
  end
end

It’s simply renaming a few variables, but the new names make it a lot easier to see everything in a more abstract fashion.

Time to simplify the test, as the whole CSV part is no longer necessary. Instead we can supply a plain array (also enumerable) with hashes:

class BelgianBeerImportTest < ActiveSupport::TestCase
  def test_import_belgian_beers_from_csv
    beers = [
      { name: 'Grimbergen Blonde', brewery: 'Brouwerij Alken-Maes',
        country: 'Belgium' },
      { name: 'Oatmeal Stout', brewery: 'Left Hand Brewing Company',
        country: 'United States' },
      { name: 'Grolsch Premium Weizen', brewery: 'Grolsche Bierbrouwerij',
        country: 'Netherlands' },
      { name: 'Straffe Hendrik Brugse', brewery: 'De Halve Maan',
        country: 'Belgium' }
    ]
    repository = mock

    repository.expects(:create_from_import!).with(name: 'Grimbergen Blonde',
      brewery_name: 'Brouwerij Alken-Maes', country_name: 'Belgium')
    repository.expects(:create_from_import!).with(name: 'Straffe Hendrik Brugse',
      brewery_name: 'De Halve Maan', country_name: 'Belgium')

    BelgianBeerImport.new(beers, repository).import!
  end
end

Note how the ActiveRecord dependency got replaced with a simple mock and expectations.

Let’s take a bit more advantage of the enumerable interface and be more explicit that we’re expecting the enumerable to contain hashes:

class BelgianBeerImport
  def initialize(beers, repository = Beer)
    @beers, @repository = beers, repository
  end

  def import!
    @beers
      .map(&:to_hash)
      .select { |beer| beer[:country] == 'Belgium' }
      .each { |beer| create_beer(beer) }
  end

  private

  def create_beer(beer)
    @repository.create_from_import!(name: beer[:name],
                                    brewery_name: beer[:brewery],
                                    country_name: beer[:country])
  end
end

A CSV row object also has a to_hash method, which converts the row to a real hash. Now it’s obvious what type of values we’re working with. It also allows the enumerable to contain objects that aren’t hashes, as long as they define the to_hash method and return the data in the required format.

Conclusion

the BelgianBeerImport class has become a lot more flexible. It doesn’t depend on CSV data alone anymore. Instead it has been abstracted into accepting any Enumerable whose values define to_hash.

The class has been completely decoupled from other dependencies. Mostly thanks to Enumerable! It’s less complex, and therefore a lot easier to test. As a bonus, the test is blazing fast. Be sure not to blink when running tests like this, otherwise you’ll think it hasn’t even run!

Combined with duck typing, Enumerable is a very powerful interface. The fact that many Ruby developers are already familiar with its interface make it the ideal candidate to use for collection interfaces.

Delegating to Query Objects through ActiveRecord scopes

Mon, 29 Jun 2015 21:10:57 +0000

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?

The following ActiveRecord model has a scope returning popular featured videos. Okay, it’s not really that complex, but this way we can keep the focus on the important parts.

class Video < ActiveRecord::Base
  scope :featured_and_popular,
        -> { where(featured: true).where('views_count > ?', 100) }
end

The scope can be easily extracted into a query object:

module Videos
  class FeaturedAndPopularQuery
    def initialize(relation = Video.all)
      @relation = relation
    end

    def featured_and_popular
      @relation.where(featured: true).where('views_count > ?', 100)
    end
  end
end

Instead of calling a scope on the model, now the query object can be called:

Videos::FeaturedAndPopularQuery.new.featured_and_popular

While it’s great to have the logic removed from the Video class, there are dozens of occurrences of Video.featured_and_popular calls scattered across the whole application. It would be great if the interface could remain unchanged, while still having the complex logic handled by the query object.

To find out how this can be done, let’s first take a look at how Rails implements the scope method. Note that this is a bit simplified, I’ve left out the irrelevant parts:

def scope(name, body, &block)
  unless body.respond_to?(:call)
    raise ArgumentError, 'The scope body needs to be callable.'
  end

  # ...

  singleton_class.send(:define_method, name) do |*args|
    scope = all.scoping { body.call(*args) }
    # ...

    scope || all
  end
end

A couple of things catch the attention:

The body (usually a proc) of the scope can be any object, as long as it responds to call.
The scoping method is used to scope the result of the body to the current scope.

So the scoping method makes sure that the relation being returned by the scope body is scoped to the relation in the current scope. Wait, that sounds confusing. Check out this example:

Video.only_cats.scoping do
  Video.featured_and_popular
end

This would return cat videos which are featured and popular. So scoping scopes the relation inside the block to the scope of Video.only_cats.

We can simply call the query object from the scope. Thanks to scoping, we don’t need to pass the current scope into the query object:

class Video < ActiveRecord::Base
  scope :featured_and_popular,
        -> { Videos::FeaturedAndPopularQuery.new.featured_and_popular }
end

But this looks quite ugly and verbose.

As we’ve seen in the implementation of scope, it expects its body to be an object which responds to call. Right now we’re passing a proc, but this can be replaced with the query object, as long as it responds to call. So we can just turn the query object into a callable object by renaming a method:

module Videos
  class FeaturedAndPopularQuery
    def initialize(relation = Video.all)
      @relation = relation
    end

    def call
      @relation.where(featured: true).where('views_count > ?', 100)
    end
  end
end

The proc can be removed from the scope declaration, and the query object itself becomes the scope body:

class Video < ActiveRecord::Base
  scope :featured_and_popular, Videos::FeaturedAndPopularQuery.new
end

We could take this even further. Since classes are also objects in Ruby, it’s possible to have a class method call, which delegates the call to a new instance of the query object:

module Videos
  class FeaturedAndPopularQuery
    class << self
      delegate :call, to: :new
    end

    def initialize(relation = Video.all)
      @relation = relation
    end

    def call
      @relation.where(featured: true).where('views_count > ?', 100)
    end
  end
end

Now only the class has to be passed in as the body of the scope. Judging by the camelcased name, it’s very obvious we’re dealing with a class here.

class Video < ActiveRecord::Base
  scope :featured_and_popular, Videos::FeaturedAndPopularQuery
end  

The logic of the query has been extracted to a query object, but the scope has been left in place so other parts of the code don’t need to be changed. The ActiveRecord model looks nice and clean, while the scope is essentially a delegation to the query object.

Say no to chained scopes!

Wed, 24 Jun 2015 22:35:57 +0000

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.

class Person < ActiveRecord::Base
  enum gender: { male: 1, female: 2 }
end

class PeopleController < ApplicationController
  def index
    @people = Person.where(gender: Person.genders[:male])
                    .where('age >= 18')
                    .where(right_handed: false)

    respond_to(:html)
  end
end

This code has a few problems:

The controller has way too much knowledge of the database structure of the model. Having these details bleeding into higher layers resists change to the underlying structure.
The chain of method calls make it incredibly hard to test if you’re using mocks.

These are implementation details which must be encapsulated within the model. ActiveRecord scopes to the rescue!

class Person < ActiveRecord::Base
  enum gender: { male: 1, female: 2 }

  scope :male,        -> { where(gender: 1) }
  scope :adult,       -> { where('age >= 18') }
  scope :left_handed, -> { where(right_handed: false) }
end

class PeopleController < ApplicationController
  def index
    @people = Person.male.adult.left_handed

    respond_to(:html)
  end
end

The raw SQL and knowledge of model attributes has been encapsulated inside the model. Problem solved … right?

The testability has been slightly improved, but there’s still a long chain of method calls to combine the different scopes. We still have to summon an army of mocks to test our controller:

class PeopleControllerTest < ActionController::TestCase
  def test_people_index
    adult_finder        = mock
    left_handed_finder  = mock

    Person.expects(:male).returns(adult_finder)
    adult_finder.expects(:adult).returns(left_handed_finder)
    left_handed_finder.expects(:left_handed)

    get :index
    assert_response :success
  end
end

Besides expectation ridden, the test is also quite brittle. If the order of scopes changes at some point, the test fails, even though the code being tested still works.

Another problem may arise with more complex scopes. Scopes can be combined freely, but not all combinations might lead to valid SQL. Testing all combinations is very cumbersome too.

I prefer to combine the scopes into a single scope or class method inside the model, rather than chaining scopes outside the model. This keeps as much internal as possible, and allows for easier database query optimizations and other changes.

class Person < ActiveRecord::Base
  enum gender: { male: 1, female: 2 }

  scope :male,        -> { where(gender: 1) }
  scope :adult,       -> { where('age >= 18') }
  scope :left_handed, -> { where(right_handed: false) }

  class << self
    def left_handed_male_adults
      left_handed.male.adult
    end
  end
end

class PeopleController < ApplicationController
  def index
    @people = Person.left_handed_male_adults

    respond_to(:html)
  end
end

The scope chain has been wrapped inside the Person.left_handed_male_adults class method. Note that the class method could also have been defined as a scope if you wanted to. The primary difference between the two is that a scope is guaranteed to return an ActiveRecord relation.

The combined scope leads to a much simpler and more robust test:

class PeopleControllerTest < ActionController::TestCase
  def test_people_index
    Person.expects(:left_handed_male_adults)

    get :index
    assert_response :success
  end
end

By avoiding the scope chains outside of the relevant models, the codebase becomes less coupled and therefore easier to maintain and refactor.

Of course it’s still possible and very to chain the scopes since all scopes are public. Resist the urge of chaining them outside of their model to keep things simple!

A cookie based approach to handling guest users

Sat, 20 Jun 2015 18:55:57 +0000

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.

This post presents a database-less approach to handling guest users in Rails. It’s not necessarily better than Nithin’s approach, but the general idea is not to bother our database with guest users’ data which eventually has to be cleaned up manually. There also should not be a special treatment for the guest users by the controllers, views and other models.

This leads to a cookie or session based approach to store a guest users’ data. A cookie based approach means they cannot access the data from different devices. This leaves an incentive for them to actually register, while it’s possible to try out the personalized functionality of the website. It’s also a good option to have an expiration date on the cookie, so guests have to come back in order to keep their data.

Basic Application Structure

The application is quite vanilla. Registered users can upload videos, and add videos to a watchlist to watch them at a later time. Watchlisted videos are represented by the SavedVideo model. Devise is used for registration and authentication.

# app/models/user.rb
class User < ActiveRecord::Base
  has_many :saved_videos

  devise :database_authenticatable, :registerable
end

# app/models/saved_video.rb
class SavedVideo < ActiveRecord::Base
  belongs_to :video
  belongs_to :user

  scope :for_video, ->(video) { where(video: video) }
end

Registered users can also view their watchlist. The SavedVideosController takes care of this and adding videos on the watchlist:

# app/controllers/saved_videos_controller.rb
class SavedVideosController < ApplicationController
  before_action :authenticate_user!

  def index
    @saved_videos = current_user.saved_videos

    respond_to(:html)
  end

  def create
    video = Video.find(params[:video_id])

    current_user.saved_videos.create!(video: video)
    flash.notice = 'Video saved for later.'

    respond_to do |format|
      format.html { redirect_to(videos_path) }
    end
  end
end

The watchlist page looks like this:

# app/views/saved_videos/index.html.slim
.row
  .cols-xs-12
    h1 Saved Videos

    table.table.table-striped
      = render(@saved_videos) || 'No videos saved for later yet'

The saved video partial simply renders the video with an additional surrounding tag for styling purposes:

# app/views/saved_videos/_saved_video.html.slim
.saved-video
  = render(saved_video.video)

The video partial also has a link to add a video to the watchlist, or shows a label if a video is already saved for later:

# app/views/videos/_video.html.slim
.video
  h2 = video.name
  - if current_user.saved_videos.for_video(video).exists?
    span.label.label-primary On Watchlist
  - else
    a href=video_saved_video_path(video) data-method="post" Watch later

The page of all available videos looks like this when adding a video to the watchlist:

Refactoring User

Before moving on to the implementation of the guest user, the interface of the User model has to be simplified. Right now it looks rather complicated:

current_user.saved_videos.for_video(video).exists?

current_user.saved_videos.create!(video: video)

current_user.saved_videos

The first two are using the ActiveRecord API. The guest user won’t be having a database backend, so the ActiveRecord specific calls should be considered an implementation detail, and need to be encapsulated.

This leads to the following structure for User:

class User < ActiveRecord::Base
  has_many :saved_videos

  devise :database_authenticatable, :registerable

  def saved_for_later?(video)
    saved_videos.for_video(video).exists?
  end

  def save_for_later(video)
    saved_videos.create!(video: video)
  end
end

Communication with the user now happens through a few simple calls:

current_user.saved_for_later?(video)

current_user.save_for_later(video)

current_user.saved_videos

Time to apply these changes to the controller:

class SavedVideosController < ApplicationController
  before_action :authenticate_user!

  # ...

  def create
    video = Video.find(params[:video_id])

    current_user.save_for_later(video)
    flash.notice = 'Video saved for later.'

    respond_to do |format|
      format.html { redirect_to(videos_path) }
    end
  end
end

And the video partial:

.video
  h2 = video.name
  - if current_user.saved_for_later?(video)
    span.label.label-primary On Watchlist
  - else
    a href=video_saved_video_path(video) data-method="post" Watch later

To make sure guest users can actually access the saved video controller, the before_action call should be removed, otherwise they’ll end up on the sign in page.

Adding the Guest

Preparations have been made for the introduction of the guest user. Let’s log out and see what happens when viewing the video listing:

ActionView::Template::Error (undefined method `saved_for_later?' for nil:NilClass):
    2:   h2
    3:     = video.name
    4:     small<
    5:       - if current_user.saved_for_later?(video)
    6:         span.label.label-primary On Watchlist
    7:       - else
    8:         a href=video_saved_video_path(video) data-method="post" Watch later
  app/views/videos/_video.html.slim:5:in `_app_views_videos__video_html_slim__3946905160582581419_70363594171520'
  app/views/videos/index.html.slim:5:in `_app_views_videos_index_html_slim___3933902596725860868_70363542529440'
  app/controllers/videos_controller.rb:7:in `index'

Devise exposes the logged in user in a controller method called current_user. If the user is not authenticated, current_user simply returns nil, leading to the error. So instead of nil, it should return the guest user object.

Let’s initially implement it as a Null Object. It won’t do anything yet, but this is a useful way to see if we haven’t missed anything else.

class Guest
  def saved_for_later?(video)
    false
  end

  def save_for_later(video)
  end

  def saved_videos
    []
  end
end

Override the current_user method in the controller to return the guest user when nil is returned:

class ApplicationController < ActionController::Base
  def current_user
    super || guest_user
  end

  private

  def guest_user
    @guest ||= Guest.new
  end
end

Let’s check out the application again. Viewing and adding saved videos should work again. Note that when saving a video, it displays the flash message, but it doesn’t actually add it to the watchlist yet.

There’s something else odd going on too. It displays the option to log out, but we’re a guest user!

The default way in Devise to check if a user is signed in is with the user_signed_in? method. It simply checks the presence of a current user, so even the guest object would make it return true. The easiest fix is to override the user_signed_in? method, like so:

class User < ActiveRecord::Base
  # ...

  def registered?
    true
  end
end

class Guest
  # ...

  def registered?
    false
  end
end

class ApplicationController < ActionController::Base
  # ...

  def user_signed_in?
    current_user.registered?
  end
end

With that out of the way, it’s time to store a guests’ saved videos in a cookie!

class Guest
  def initialize(store)
    @store = store
  end

  def registered?
    false
  end

  def saved_for_later?(video)
    saved_video_ids.include?(video.id)
  end

  def save_for_later(video)
    @store[:saved_for_later] = JSON.generate((saved_video_ids << video.id))
  end

  def saved_videos
    []
  end

  private

  def saved_video_ids
    return [] unless @store[:saved_for_later]

    JSON.parse(@store[:saved_for_later])
  end
end

The cookie store is being passed into the initializer, and the ID’s of saved videos are stored inside it in the JSON format. Since the cookie store is a very Hash-like object, the Guest actually doesn’t really have to care that it’s a cookie store, it just pretends it’s a hash! This is useful when testing Guest, an actual Hash can be used:

class GuestTest < MiniTest::Test
  def test_save_video_for_later
    store = {}
    video = mock
    guest = Guest.new(store)

    video.expects(:id).returns(23)
    guest.save_for_later(video)

    assert_equal(store, { saved_for_later: '[23]' })
  end
end

In ApplicationController, a guest should now be initialized with a cookie store:

class ApplicationController < ActionController::Base
  def user_signed_in?
    current_user.registered?
  end

  def current_user
    super || guest_user
  end

  private

  def guest_user
    @guest ||= Guest.new(cookies.signed)
  end
end

Let’s check out the changes made to the SavedVideosController:

class SavedVideosController < ApplicationController
  # ...

  def create
    video = Video.find(params[:video_id])

    current_user.save_for_later(video)
    flash.notice = 'Video saved for later.'

    respond_to do |format|
      format.html { redirect_to(videos_path) }
    end
  end
end

That’s right, nothing changed! This is polymorphism at its best! The create action doesn’t waste its time caring whether the user is a guest or not. The lack of conditionals greatly boosts the clarity of the controller action!

The only thing remaining is to display the videos on the watchlist. The saved_videos method of a user is expected to return an array-like structure with objects responding to the user and video methods. This is handled by returning a struct:

class Guest
  # ...

  def saved_videos
    saved_video = Struct.new(:user, :video) do
      def to_partial_path
        SavedVideo.new.to_partial_path
      end
    end

    Video.where(id: saved_video_ids).map do |video|
      saved_video.new(self, video)
    end
  end

  private

  def saved_video_ids
    return [] unless @store[:saved_for_later]

    JSON.parse(@store[:saved_for_later])
  end
end

Note that the struct also responds to to_partial_path, so that Rails knows which partial to render for the object. Let’s see how it works:

Way cool! A guest user save videos the exact same way registered users can. This is nice to quickly try it out, without having to create an account first. After they register, everything still works the same, familiar way.

Refactoring the Guest

Looking at the Guest class, all it really does is managing the saved videos:

class Guest
  def initialize(store)
    @store = store
  end

  def registered?
    false
  end

  def saved_for_later?(video)
    saved_video_ids.include?(video.id)
  end

  def save_for_later(video)
    @store[:saved_for_later] = JSON.generate((saved_video_ids << video.id))
  end

  def saved_videos
    saved_video = Struct.new(:user, :video) do
      def to_partial_path
        SavedVideo.new.to_partial_path
      end
    end

    Video.where(id: saved_video_ids).map do |video|
      saved_video.new(self, video)
    end
  end

  private

  def saved_video_ids
    return [] unless @store[:saved_for_later]

    JSON.parse(@store[:saved_for_later])
  end
end

If the guest were to do anything in addition, the class becomes bloated really quickly. Let’s fast-forward a couple of refactorings to see a better structure:

# app/models/guest.rb
class Guest
  attr_reader :saved_videos

  def initialize(store)
    @saved_videos = Guests::SavedVideos.new(store)
  end

  def registered?
    false
  end

  def saved_for_later?(video)
    saved_videos.include?(video)
  end

  def save_for_later(video)
    return if saved_for_later?(video)

    saved_videos << video
  end
end

SavedVideos just got its own, dedicated class. Note that it’s located inside the Guests module. Here’s the code:

# app/models/guests/saved_videos.rb
module Guests
  class SavedVideos
    include Enumerable

    delegate :each, to: :to_ary

    def initialize(store)
      @store = store
    end

    def include?(video)
      ids.include?(video.id)
    end

    def <<(video)
      @store[:saved_for_later] = JSON.generate(ids << video.id)
    end

    # Is called by ActionView when rendering a collection
    def to_ary
      Video.where(id: ids).map do |video|
        Guests::SavedVideo.new(self, video)
      end
    end

    private

    def ids
      return [] unless @store[:saved_for_later]

      JSON.parse(@store[:saved_for_later])
    end
  end
end

The low level code of storing data inside the cookie store is in here. Take note of the to_ary method. The struct has been replaced with an actual class. to_ary is also called by ActionView when passing a collection to render.

Guest can treat Guests::SavedVideos as an array like object, not having to worry about all the implementation details. Guests::SavedVideos is also Enumerable, so it actually has a lot of methods arrays do too! This makes it easy to add a little count of saved videos on the website, simply by calling current_user.saved_videos.count!

Next steps

You might want to add restrictions to the guest user, such as a maximum amount of saved videos. And when they exceed the maximum, present them with a register screen to continue saving more videos. I’ll probably cover this in a future post.

When a guest decides to actually register, it makes sense to import their already saved data into the account as a courtesy.

Since cookies are transfered with every request to the web server, you might decide to store the data inside the session store. This can be accomplished by one simple change in the controller:

class ApplicationController < ActionController::Base
  def current_user
    super || guest_user
  end

  private

  def guest_user
    @guest ||= Guest.new(session)
  end
end

And that’s where Rails shines, the session store has the same hash-like interface as a cookie store, making this change extremely simple!

You might also enable users to erase their data. On the User, it’s easy enough to call destroy or delete. It’s not too hard to implement this for the Guest too:

class Guest
  # ...

  def destroy
    saved_videos.destroy
  end

  alias_method :delete, :destroy
end

Guests::SavedVideos is then concerned with cleaning up only its own data:

module Guests
  class SavedVideos
    # ...

    def destroy
      @store[:saved_for_later] = nil
    end
  end
end

It doesn’t fully remove the cookie, but it does clear the data. For whatever reason, you cannot call delete on a chained cookie…

Conclusion

This approach works nicely when no guest user data has to be stored inside the database (and even if it does, this can work with a few adjustments!), and you’re not storing a lot of data inside the cookie.

The greatest benefit in my opinion is that the application remains pretty much unchanged and the implementation details are nicely encapsulated by the Guest class.

Check out the full source code on Github!

Resourceful custom user profile theme

Tue, 02 Jun 2015 18:10:00 +0000

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?

We’ve already got our User and Profile functionality in place, where a user can have a single profile:

# app/models/user.rb
class User
  has_one :profile
end

# app/models/profile.rb
class Profile
  belongs_to :user
end

And the controller to view other user’s public profiles is quite vanilla too:

# app/controllers/profiles_controller.rb
class ProfilesController < ApplicationController
  def show
    @profile = User.find(params[:id]).profile

    respond_to(:html) if stale?(@profile)
  end
end

And there’s of course the profile view:

<!-- app/views/profiles/show.html.erb -->
<div class="profile">
  <h1><%= @profile.name %></h1>
  <p>Location: <%= @profile.location %></p>
</div>

I won’t go into the details of the form to edit the profile settings itself, but we’ll store the color codes in two attributes on profile called foreground_color and background_color.

There are a couple of ways we can implement the profile theming:

Inline styles

This is the fastest way to get it done, and also the fastest way to turn your frontend code into a tangled mess. A definite no-go unless you really like digital spaghetti.

Including CSS in `<style>` tags

A little better, but not quite enough separated yet. Everything is still rendered within the same view. I don’t feel like this is the most logical option, especially not in the longer run when the functionality expands.

Rendering CSS in a stylesheet

This option makes the most sense to me. This keeps the data nicely separated from the styles, and doesn’t throw everything on a single pile of code.

It’s also a very resourceful approach. We’re considering the stylesheet to be the representation of a profile in CSS format. This fits in nicely with the way Rails works, our controller only needs a minor change:

class ProfilesController < ApplicationController
  def show
    @profile = User.find(params[:id]).profile

    respond_to(:html, :css) if stale?(@profile)
  end
end

Next, the CSS view needs to be implemented:

/* app/views/profiles/show.css.erb */
.profile {
  background-color: <%= @profile.background_color %>
}

.profile p {
  color: <%= @profile.foreground_color %>
}

Right now there are only two simple attributes, but when profile customization functionality extends, it might be a good idea to start using a decorator at some point.

So now that we’ve got our stylesheet done, it needs to be included in the page to see the custom theme. We’ll do this using content_for in the profile HTML view:

<!-- app/views/profiles/show.html.erb -->
<% content_for :stylesheet_includes do %>
  <%= stylesheet_link_tag(profile_path(@user, format: :css)) %>
<% end %>

<div class="profile">
  <h1><%= @profile.name %></h1>
  <p>Location: <%= @profile.location %></p>
</div>

Finally, we’ll render the stylesheet_includes content in the <head> of the page by adding a line to the application layout:

<!-- app/views/layouts/application.html.erb -->
<head>
  <%= yield :stylesheet_includes %>
</head>

And that’s it! If the user visits a profile, the stylesheet with the theme for that profile is applied to the page. This is a nice separation of concerns, made super easy by Ruby on Rails.

Don't use before_action to load data

Sun, 31 May 2015 10:45:57 +0000

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.

Take a look at this controller:

class TreesController
  before_action :authenticate_user!
  before_action :find_forest
  before_action :find_trees
  before_action :find_tree, except: [:index, :new, :create]

  def index
  end

  def show
  end

  def edit
  end

  def update
    if @tree.update(tree_params)
      redirect_to(@tree)
    else
      render('edit')
    end
  end

  private

  def find_forest
    @forest = Forest.find(params[:forest_id])
  end

  def find_trees
    @trees = @forest.trees
  end

  def find_tree
    @tree = @trees.find(params[:id])
  end
end

The before_action filters have been used to make the controller DRY. The forest and trees are loaded by the filters and assigned to instance variables.

The views for show and edit have access to the @tree instance variable, but this isn’t obvious. You have to look at the controller and connect the dots to figure out which variables are available where.

Perhaps the controller has become too DRY. The filters are coupled to the controller actions in a very weird way. In fact, the :find_trees and :find_tree filters are coupled to each other as well, because :find_tree depends on :find_trees. In terms of the problem domain, it becomes hard to see the forest through the trees (pun intended).

In other words, clarity has been sacrificed for the sake of DRY-ness. Don’t get me wrong, DRY is a great concept, but not when it turns your Rails controller into a complicated puzzle!

In my opinion, before filters should only ever be used to do what they do best: halting the request cycle. They should not be used for data loading and preparing state.

Applying that to our controller would result in something like this:

class TreesController
  before_action :authenticate_user!

  def index
    @trees = find_forest.trees
  end

  def show
    @tree = find_tree
  end

  def edit
    @tree = find_tree
  end

  def update
    @tree = find_tree

    if @tree.update(tree_params)
      redirect_to(@tree)
    else
      render('edit')
    end
  end

  private

  def find_tree
    find_forest.trees.find(params[:id])
  end

  def find_forest
    Forest.find(params[:forest_id])
  end
end

The filters which were previously loading data have been replaced with plain method calls from the controller actions. Now it’s immediately obvious which data is loaded where.

Crafting Ruby

I'm not testing those stupid views!

Cleaner RSpec examples and failure messages

Built-in matchers

Cleaner failure messages

Conclusion

Rails Anti-Pattern: Fat Decorator

Divergent Change

Feature Envy

A smelly decorator

Problems

Making it less envy

Dealing with Divergent Change

Conclusion

Don't index the kitchen sink!

Using Enumerable as testing abstraction

Enumerable, the coolest Ruby module

Conclusion

Delegating to Query Objects through ActiveRecord scopes

Say no to chained scopes!

A cookie based approach to handling guest users

Basic Application Structure

Refactoring User

Adding the Guest

Refactoring the Guest

Next steps

Conclusion

Resourceful custom user profile theme

Inline styles

Including CSS in <style> tags

Rendering CSS in a stylesheet

Don't use before_action to load data

Including CSS in `<style>` tags