Essentially, if your column is an enum, then indexing it could actually cause MySQL to do more work. Why? Because the data set is so large, the MySQL ends up doing a full scan. So things like keeping track if something is active (1 or 0) then you can expect indexing to hurt.

So how does this effect ActiveRecord? Well, if you’re keeping track of whether a user is active or not you would not want to index that column alone. Nor would you want to index a type column if you were using single table inheritance, again, because there isn’t a lot of variance in the type.

So make sure that you index the right things, like IDs and leave the enum-like columns alone.

So if you have some free time, please take the survey to help this project turn into something that you actually want to use :)

Running rake test:functionals:rcov, my report shows me a long list of items, some of which I don’t want to see. I don’t want to see the coverage of my models in the report. I should get that report by running rake test:units:rcov. Luckily, the plugin allows for me to set arguments like SHOW_ONLY="app/models". But get this, I’m lazy and I don’t want to type that argument let alone remember it every time I want to run the rcov tests. What to do?

Rake It Up

The options are simply environment variables. By using rake, we can create some tasks that set these environment variables. So here’s what mine looks like:

task :default_rcov_params_for_units do
  RCOV_PARAMS = ENV['RCOV_PARAMS'] = "--sort=coverage"
  SHOW_ONLY = ENV['SHOW_ONLY'] = "app/models|lib|app/concerns|app/helpers"
end

task :default_rcov_params_for_functionals do
  RCOV_PARAMS = ENV['RCOV_PARAMS'] = "--sort=coverage"
  SHOW_ONLY = ENV['SHOW_ONLY'] = "app/controllers"
end

That means now I can do something like rake default_rcov_params_for_units test:units:rcov. Good, but there is better. We can have default_rcov_params_for_units become a prerequisite for test:units:rcov. That will make it happen automagically.

namespace :test do
  namespace :units do
    desc 'With RCOV_PARAMS="--sort=coverage" SHOW_ONLY="app/models|lib|app/concerns|app/helpers"'
    task :rcov => [:default_rcov_params_for_units]
  end

  desc 'With RCOV_PARAMS="--sort=coverage" SHOW_ONLY="app/controllers"'
  namespace :functionals do
    task :rcov => [:default_rcov_params_for_functionals]
  end
end

Follow Up

Tada! That was easy. This is one example of customizing your rake profile. Don’t be afraid to try other methods as well.

Sometimes, a design requires a little extra markup, perhaps something to get that rounded corner to work or what-have you. Now let’s say this piece of code requires certain classes, a certain kind of structure, including a tile, and has to be used in many places, something like a sidebar piece. Instead of copying and pasting this structure over and over, you can use a helper to make you life easier, and if you combine it with a block, it will just feel even more painless.

The Setup

<div class="sidebar">
  <div class="bottom">
    <h3>Title</h3>
    <div class="body">
      <p>Some Content</p>
    </div>
  </div>
</div>

There are two elements which must change; the title and the contents of the body. The title should simply be just some text that goes in between the h3 tag. The contents of the body could be anything, in this case, it is the paragraph tag and everything inside.

Creating a Helper without a Block

Since we have these two varying things, we could create a helper method to encapsulate our structure. The first parameter of the helper will be the title while the second parameter will be the contents of the body.

def sidebar(title, body)
  content_tag(
    'div',
    content_tag(
      'div',
      content_tag('h3', title) + content_tag('div', body, :class => 'body'),
      :class => 'bottom'
    ),
    :class => 'sidebar'
  )
end

That looks pretty easy. Now let’s look at the interface for this helper

<%= sidebar('Hello World',
  '<p>It is one of these "Hello World" things again.</p>') %>

Not too shabby, but what if we wanted to do an unordered list?

<%= sidebar(
  'Hello World',
  '<ul>' +
    '<li>Item</li>' +
    '<li>Item</li>' +
    '<li>Item</li>' +
  '</ul>'
) %>

This feels pretty clunky and ERB is completely ignored. Instead of this procedural way of thinking, why not see what a block can do for us?

Creating a Helper +with+ a Block

For this to work, we will still need the first parameter to be the title, but the body will be passed in as a block to be processed from within our helper. The block we create will be ERB code, this will feel more natural to the person who has to implement the code. The magic to get this done comes from the concat method of ActionView::Helpers::TextHelper module.

def sidebar(title, &block)
  raise ArgumentError, "Missing block" unless block_given?

  start = <<-END
    <div class="sidebar">
      <div class="bottom">
        <h3>#{title}</h3>
        <div class="body">
  END
  concat(start, block.binding)

  block.call

  end = <<-END
        </div>
      </div>
    </div>
  END
  concat(end, block.binding)

end

This may look slightly odd, but I assure you, the interface makes up for it.

<% sidebar('Hello World') do %>
  <p>And now back to the way I was doing things before</p>
  <ul>
    <li>Item</li>
    <li>Item</li>
    <li>Item</li>
  </ul>
<% end %>

The Benefits

• The implementation code is more readable
• It gives you one place to make your common edits
• It keeps your code DRY(don’t repeat yourself)

Take this bit of ruby code in a rails controller as an example:

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])
  end
end

That’s pretty solid, but what happens if someone passes in an ID that does not exist? Well in rails’ production mode, it would return a 404 error

Makes sense! That article doesn’t exist, so it can’t be found. I have dabbled with a little SEO(Search Engine Optimization) and usability and just a 404 isn’t cutting it for me. I think we can redirect our user back on a right track. For one, we know the user is trying to read an article, so why not redirect the user to a list of all the articles and give them a little warning?

Solution One

First check that the article exists, and if not, redirect the user to the index page.

def show
  if Article.exists?(params[:id])
    @article = Article.find(params[:id])
  else
    flash[:error] = 'That article does not exist'
    redirect_to :action => 'index'
  end
end

While this works, this requires two queries to our database; one to check it’s existence and one to load it. I think there is a better way, and its secret is to go with the flow of the code.

Solution Two

One thing
ActiveRecord::Base#find does do is raise an exception when it cannot find anything, an ActiveRecord::RecordNotFound exception. We can use this bit of knowledge to re-write that method to something a little simpler by trusting it to throw an exception and then for us to rescue it.

def show
  @article = Article.find(params[:id])
rescue ActiveRecord::RecordNotFound
  flash[:error] = 'That article does not exist'
  redirect_to :action => 'index'
end

One call to the database and fewer lines of code (not a lot, but still). This time, that nasty little error has been used in our favor; but one mustn’t get lazy when using rescue statements.

Don’t Get Lazy

Notice that I used the constant ActiveRecord::RecordNotFound with the statement. Sure, I could have just written rescue, but that hurts us in two ways. First, it becomes less readable without it. Having the RecordNotFound is pretty obvious as to the reason we are executing that statement. Secondly, it can introduce unwanted side effects.

def show
  @article = Article.find(params[:id])
  some_illegal_operation
rescue
  flash[:error] = 'That article does not exist'
  redirect_to :action => 'index'
end

Whenever that method is called, it will always redirect the user to the index page with that error message. Because we’ve rescued all errors, we’re not getting any notice about how our some_illegal_operation has caused us grief. This makes debugging and management harder.

The lesson being, don’t be lazy in those rescues. Try to avoid a blanket rescue statement if you can.

def index
  @articles = Article.find(:all)
  respond_to do |format|
    format.html
    format.xml { render :xml => @articles.to_xml }
  end
end

def show
  @article = Article.find(params[:id])
  respond_to do |format|
    format.html
    format.xml { render :xml => @article.to_xml }
  end
end

If we want to use the respond_to, we have to make sure it’s in all of our methods. Wouldn’t it be easier to just do something like this?

def index
  @articles = Article.find(:all)
  format.html
  format.xml { render :xml => @articles.to_xml }
end

Doing it this way, we don’t have to write 2 extra lines per method, and we don’t increase our indentation. While that’s not a huge thing, I still just don’t like to constantly write out those lines when I don’t have to when I think we can build something a little trickier.

The Breakdown

In the simplified example I gave above, we have several things that we need to accomplish. One is to wrap our methods with a respond_to by using alias_method Well, it’s actually not that simple because respond_to is a block and we will need to do some trickery there. Another task is we need to create a format method. Since we won’t be calling format with a block parameter, we need to make a method which will do the dirty work for us. Finally, we need to make a tweak to ActionController::MimeResponders::Respond#respond for some of the other things that we are doing.

Adding wrap_respond_to_in to our ApplicationController

To start things off, we need to make a class method, which I have dubbed wrap_respond_to_in (I would love suggestions for names here).

class << self
  def wrap_respond_to_in(*actions)
    if actions.include?(:all)
      # Also remove #rescue_action because this gets set in tests. Also include some of my friendly #find methods.
      actions = actions + self.public_instance_methods - ApplicationController.public_instance_methods - ['rescue_action'] - [:all]
      [:find_collection, :find_new, :find_member].each do |finder|
        actions << finder if method_defined?(finder)
      end
    end

    # Returns the appropriate Responder format based on the action.
    define_method(:format) do
      @format.last rescue nil
    end

    for action in actions
      action = action.to_sym

      module_eval <<-END
        alias_method(:__#{action.to_i}__, :#{action.to_s})
        private :__#{action.to_i}__

        def #{action.to_s}(*args)
          result = nil      # This is the result of whatever method this wraps
          respond_to do |format|
            @format ||= []
            @format.push(format)
            result = __#{action.to_i}__(*args)
            @format.pop
          end
          return result
        end
      END
    end
  end
end

Let’s break this down by section. First things first, the method’s arguments should be a list of symbols for the names of the methods we would like to use our respond_to shorthand. Because I would like to use this shorthand for all of my action methods, I have included the notion of sending :all as a parameter. This will make sure that all of the public methods and some protected methods that I use (find_member, find_collection, and find_new). Again, I like to keep things DRY(Don’t Repeat Yourself). Next we define a method called format. This will be an accessor to the last element of our format instance variable array. More on this later. After we have defined that, we need to loop through all of our methods that we want to use respond_to. In each loop, we need to make an alias for our methods. This is so that we can re-write the method, yet still keep a copy of the original code. Next we overwrite the method. As you can see here, this is where we put the respond_to block. Now in this block, we have access to the format variable. Next we push this value into our format instance variable. The reasoning for using an array is to accommodate for a nested set of calls. After we push format onto format, we then call our original method, which uses the shorthand and save that to to a variable. Once that is done, we pop off the last value we put into the format@ variable, since we are done with it. Finally, return the result of our original method. This is the backbone for what we need to do. Now we need to implement it.

Tweaking ActionController::MimeResponds::Responder

Because we now have assumed that all of our methods are going to use respond_to, we need to make a way out if for some reason we don’t need to use said method. This would mean that our method exists without calling the format method. In order to do that, we can use the following code:

module ActionController #:nodoc:
  module MimeResponds #:nodoc:
    class Responder
      alias_method :__respond_without_check_for_empty_order__, :respond
      private :__respond_without_check_for_empty_order__

      def respond
        return if @order.empty?
        __respond_and_check_for_empty_order__
      end
    end
  end
end

We simply do a check to see if order is empty. If so, that means our format method was never called, so we just simply need to exit out of the respond method. I put this in my lib directory and make sure that my app requires this after rails has been loaded.

Using wrap_respond_to_in

Quite simply all we need to do to use it is to call it, but we must do so after we have defined all of our methods for which we want to use this technique

.

class Articles < ApplicationController
  before_filter :find_member, :only => [:show]

  def show
    format.html
    format.xml { render :xml => @article.to_xml }
  end

  protected
    def find_member
      @article = Article.find(params[:id])
    rescue ActiveRecord::RecordNotFound
      format.html do
        flash[:error] = "Article was not found"
        redirect_to articles_url
      end
      format.xml { head :status => 404 }
    end

    wrap_respond_to_in :all
end

While this is not a complete controller, it does show you how to use it.

Final Words

There’s no reason to put a respond_to call in all of the methods when there is a way around it. Once I figure out how to get SVN(subversion) working with Dreamhost I am going to put this into a plugin for all to use.

.

class Comment < ActiveRecord::Base
  belongs_to :article

  validates_presence_of :article
end

If you instantiate a new Comment, and don’t assign an Article to the comment instance, the record won’t save. I have to say, that seemed pretty obvious. But there is another interesting piece to this. Say I passed the article_id in the params and tried to assign that to our instance

comment = Comment.new
comment.article_id = params[:article_id]

If article_id corresponds to a real article in our database, then comment.article will have be assigned an Article with that id. Now if params[:article_id] happens to be some id which doesn’t exist, like 99999999999, then comment.article will be nil and thus the record fails validation. This means that you don’t have to test for the existence of the Article against your records because rails will do this for you when it checks to see if comment.article is nil or not.

If you want to do the latter, then there are two lines you my want to put at the top of your script.

ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || 'development'
require File.expand_path(File.dirname(__FILE__) + "/../config/environment")

The first line allows us to supply which environment we would like to run the script in. Say the script is called process.rb, we could call the script like ./process.rb production and now the environment is set to production.

The second line loads the environment file. Now all of rails, your models, libraries, and plugins are available to you.

Sometimes I find that I want pre-load my database with some data, like categories that I have. For testing purposes, I have already created this data in my fixture; now I just want to load that fixture into my database from a migration call.

I know that there is a rake task for this, so I looked into that code and came up with a little something.

require 'active_record/fixtures'

class CreateCategories < ActiveRecord::Migration
  def self.up
    create_table :categories do |t|
      t.column :name, :string
    end

    Fixtures.create_fixtures('test/fixtures', File.basename("categories.yml", '.*'))
  end

  def self.down
    drop_table :categories
  end
end

First I had to require active_record/fixtures. This allows me to call the Fixtures#create_fixtures method, which load my data. Now I can gaurantee that my fixture data will be loaded for any environment.

That sets of the paranoia level up because who knows, I may need 1001 migrations! So to settle this once and for all, I wrote a script that would generate 999 migrations for me. I ran the 1000 migration and then it created 1001_test1001.rb.

Good news! Rails doesn’t constrain its migrations to a 3 decimal place prefix. So pointless…