Let’s keep this announcement short and simple: Ruby Whois 3.0 has been released today!

Developers tend to assign fancy names to major releases, so I will. For the purpose of this article, I’ll call this release Whois 3.

Changes

Whois 3 is the result of about 6 month of work. It contains several improvements in addition to an incredible amount of tweaks and updates. If you don’t believe me, you can have a look at the CHANGELOG and you’ll immediately realize that the Release 3.0 counts more than 50 entries.

The most notable change that will probably affect a few users is the minimum Ruby requirement. Whois 3 no longer supports Ruby 1.8.7 and the minumum Ruby version is now Ruby 1.9.2. With Ruby 2.0 released, it’s time to move forward.

Query Handler

One of the most important features is the introduction of the query handler.

Whois::Server::Adapters::Base.query_handler.class
# => Whois::Server::SocketHandler

The query handler is responsible for the low-level connection between the library and the external WHOIS source. The default query handler, as the class name suggests, is a socket-based handler. It opens a connection to the specified server, writes a query and reads a response that in most cases is the final WHOIS record.

So far so good. But what if you want to use a proxy? Or if you want to be able to use an async socket connection? Before Whois 3 the only way was to monkey patch the library. Today, you simply need to write your own handler and configure the library to use it.

class MyHandler
  def call(query, *args)
  # ...
  end
end

Whois::Server::Adapters::Base.query_handler = MyHandler

# This request will use your custom handler
Whois.whois "..."

Another good case is a Test handler to be used in a test environment. A Test handler would be a simple and effective replacement for all the stubs and mocks across our application spec suite. Also, it will ensure no real socket connection is performed outside our application when our test suite is running.

Non-Deep querying

The support for Non-Deep queries is another long awaited feature. You can now skip deep queries for thin providers passing the `:referral => false` option.

c = Whois::Client.new(referral: false)
c.lookup "google.com"

The option also works in the command line.

$ ruby-whois google.com --no-referral

Aknowledgements

Whois 3 was made possible by the contributions of several committers and reporters. I would also thank you DNSimple for sponsoring the development of the library.

Created in the 1980s, WHOIS began as a service used by Internet operators to identify individuals or entities responsible for the operation of a network resource on the Internet. The WHOIS service has since evolved into a tool used for many purposes.

Nowadays the WHOIS protocol is primarily used by registrants and users to query domain registrar databases to obtain domain name information and check domain name availability.

Specification

The NICNAME/WHOIS protocol was first described in RFC 812 in 1982 by Ken Harrenstien and Vic White of the Network Information Center at SRI International, and subsequently updated 3 years later in RFC 954.

The RFC 3912, published in 2004, is the latest and most significant update to the WHOIS protocol as of today. It renamed the NICNAME/WHOIS to WHOIS and introduced several updates intended to remove the information no longer applicable to the state of the Internet in 2004.

The RFC 3912 contains the essence of the WHOIS protocol specification.

A WHOIS server listens on TCP port 43 for requests from WHOIS clients. The WHOIS client makes a text request to the WHOIS server, then the WHOIS server replies with text content. All requests are terminated with ASCII CR and then ASCII LF. The response might contain more than one line of text, so the presence of ASCII CR or ASCII LF characters does not indicate the end of the response. The WHOIS server closes its connection as soon as the output is finished. The closed TCP connection is the indication to the client that the response has been received.

Whilst the RFC 3912 provides (very little) information about how a WHOIS query should work, it doesn’t say anything at all about the content of a WHOIS server response. What about the syntax or the encoding?

Also, the WHOIS protocol lacks mechanisms for access control, integrity, and confidentiality.

As a result, in the years providers designed their own WHOIS server implementation. The proliferation of customized WHOIS protocols makes almost impossible the creation of an unique, standardized interface to query WHOIS servers and consume WHOIS responses.

Standardization

ICANN recently started a project that would eventually end up with the creation of a standardized WHOIS as a replacement for the current WHOIS protocol. This is an extremely ambitious project that unfortunately has a huge chance of failure due to the large adoption of the WHOIS protocol.

Replacing all existing WHOIS servers would requires an incredible effort and this is one of the reasons why similar projects such as RWhois and Whois++ have failed in the past.

ICANN is probably the only organization capable of start such kind of reorganization of the WHOIS protocol.

Current State

As of today, the WHOIS protocol is the de-facto “standard” for querying domain name information. The decision to expose or not a public WHOIS interface is completely up to the TLD maintainer.

For instance, the .COM and .DE TLDs provides a public WHOIS interface, the .ES TLD provides a private WHOIS interface while the .VA TLD doesn’t provide any WHOIS interface. It means there’s no way to get information about a .VA domain.

The WHOIS protocol is a TCP-based protocol designed to work on the port 43. This makes extremely difficult to perform a WHOIS query from a browser without relying on a server-side third party tool. In fact, client side JavaScript is not able to perform socket requests on port 43.

Because of this, every hosting company provides a custom web-based WHOIS tool to query WHOIS information. The majority of these tools is implemented using a WHOIS API service such as RoboWhois (*) or DomainTools or using a WHOIS client. There are WHOIS clients in almost every programming language. (*) Disclaimer: I’m the author of RoboWhois.

Also, it’s not unusual to find a WHOIS form directly on registry websites. This is the case, for example, of Denic.de for the .DE tld or Registro.it for the .IT tld. In several cases, the web-based registry form provides private information normally hidden in the public WHOIS interface, such as contact details.

This is an example of a GoDaddy WHOIS response using the TCP WHOIS interface. Notice the link to the web-based WHOIS interface.

Please note: the registrant of the domain name is specified
in the "registrant" field.  In most cases, GoDaddy.com, LLC
is not the registrant of domain names listed in this database.

Registrant:
   Simone Carletti

   Registered through: GoDaddy.com, LLC (http://www.godaddy.com)
   Domain Name: WEPPOS.COM

   Domain servers in listed order:
      NS1.DREAMHOST.COM
      NS2.DREAMHOST.COM
      NS3.DREAMHOST.COM

   For complete domain details go to:

http://who.godaddy.com/whoischeck.aspx?Domain=WEPPOS.COM

There is also a plethora of web-based services that provide WHOIS information, normally mixed with other domain-related and networking details such as IP address, server location and reverse lookup. A large number of these services intentionally re-publishes WHOIS responses as web pages in order to gain visitors from search engines and promote affiliations or products.

For example, here’s the result page for whois expedia.

Search results for whois expedia.com.

In most cases, web-based WHOIS interfaces have been accused of front running domains. The best way to avoid your domain being registered by one of these services is to run WHOIS queries using the socket based WHOIS interface, use the maintainer web-based WHOIS service or make sure the service you want to use contains explicit information about domain name front running in the privacy policy or terms of service.

Resources

Despite WHOIS is a very simple protocol, the lack of a well-structured specification transforms it to one of the most complex and unforeseeing protocol to work with. It’s impossible to cover all WHOIS topics into a single article and I will probably publish more posts in the future.

The following resources can help you to learn more about the WHOIS protocol, query a WHOIS server and consume WHOIS responses.

• Wikipedia – the Wikipedia WHOIS article.
• Whois – the most popular WHOIS commandline client.
• Ruby Whois – a WHOIS client and parser in Ruby.
• RoboWhois – a cloud-based web service that provides a RESTful API to access WHOIS records.

This article targets Rails >= 3.2

The article was written as of Rails 3.2. The information contained in this page might not apply to different versions.

I have a very simple Rails 3.1 application, deployed on Heroku. Just after upgrading it to Rails 3.2, the deploy to Heroku stopped working properly.

More specifically, the rake asset:precompile task was failing during slug compilation.

       Your bundle is complete! It was installed into ./vendor/bundle
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       rake aborted!
       could not connect to server: Connection refused
       Is the server running on host "127.0.0.1" and accepting
       TCP/IP connections on port 5432?

       Tasks: TOP => environment
       (See full trace by running task with --trace)
       Precompiling assets failed, enabling runtime asset compilation
       Injecting rails31_enable_runtime_asset_compilation
       Please see this article for troubleshooting help:

http://devcenter.heroku.com/articles/rails31_heroku_cedar#troubleshooting

The Heroku assets:precompile toubleshooting page contains several explanations, but none of these was my case. In fact, my application was working properly with Rails 3.1.

It turns out there are some changes in the Rails 3.2 initialization process that conflicts with Heroku slug compilation. The solution is very simple. All you have to do is to set the Rails 3.2 initialize_on_precompile configuration to false in your application.rb file.

config.assets.initialize_on_precompile = false

This option is new in Rails 3.2 and prevents the Rails environment to be loaded when the assets:precompile task is executed. Because Heroku precompile assets before setting the database configuration, you need to set this configuration to false or you Rails application will try to connect to an unexisting database.

       Your bundle is complete! It was installed into ./vendor/bundle
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
-----> Rails plugin injection
       Injecting rails_log_stdout
       Injecting rails3_serve_static_assets
...

This configuration is also documented in the Precompiling Assets section of the new Rails 3.2 asset pipeline guide.

Be prepared, this is an unconventional Ruby book. To use author’s words

This is a book about making that final leap, about absorbing the Ruby programming culture, about becoming truly fluent in Ruby.

A formal understanding of the mechanics of Ruby isn’t the same as really looking at the programming world through Ruby-colored glasses. You need to absorb the cultural part of Ruby, to see how real Rubyist use the language to solve problems.

This is something I have been claiming for the last 5 years. Learning Ruby is not difficult, start thinking in Ruby and becoming a Rubyist is the real challenge.

Structure

The book is divided into 4 parts. Each part is divided into chapters. The book counts 31 chapters and about 400 pages.

1. The Basics
2. Classes, Modules, and Blocks
3. Metaprogramming
4. Pulling It All Together

The first part covers some basic Ruby features in a way you normally won’t read in any other Ruby reference. Ah, if I only had the Symbol chapter available when I started learning Ruby!

The second part covers Classes, Modules and Blocks and it explains how to use modules successfully, how to deal with inheritance, equality and operators. This is by far my most favorite section.

The third part is about Metaprogramming. Whilst the name of the section is technically correct, it can be misleading. If you are looking for a complete Ruby and Metaprogramming course, check out Metaprogramming Ruby (US | UK). This section covers common Ruby metaprogramming topic such as hooks, method_missing (a must read!) and monkey patching.

The fourth part wraps several topics all together and talks about creating and implementing a DSL in Ruby.

The book ends with a rich list of books about Ruby and programming in general. The list contains amazing Ruby titles like Ruby Best Practices (US | UK) or The Ruby Way Second Edition (US | UK), as well programming masterpieces like The Elements of Programming Style (US | UK). If you are looking for some inspiration about your next reading, you might probably find some there.

Requirements

This book assumes that you have a basic knowledge of the Ruby language. You don’t need to be a Ruby master, but some advanced sections such as Metaprogramming and DSL may require you to stop for a moment and refresh or improve your specific knowledge of Ruby on that topic.

Don’t expect this book to explain you the basic details of Ruby or its syntax, this is behind the scope of this publication. There are plenty of commented examples, but if you want to learn about a specific Ruby feature make sure you keep a reference like Programming Ruby (US | UK) or The Ruby Way (US | UK) handy.

Another requirement is that you must be ready to read printed source code: this book is full or Ruby code. At least the 50% of the pages contain code, making this book a valuable practical reference.

How was it?

Eloquent Ruby is a very lightweight and pleasant reading. The colloquial tone is friendly and engrossing. The books has plenty of code snippets and it requires only a few days to read it from start to end.

Aside from being an excellent resource to help you thinking Ruby and programming in the Ruby way, this book constantly adopts a practical approach providing tons of examples to read. Every chapter ends with an In the Wild section containing examples extracted from real Ruby libraries, and a Wrapping up section that helps you to fix the concepts in mind.

I appreciated the focus on tests and the RSpec chapter. The most part of the examples are verified by tests, and the tests are also available in the book.

I found the Regular Expression chapter pretty boring and misplaced. In fact, it was the only chapter in the book where the main focus was teaching Regular Expression basics, instead of focusing on using Regular Expressions in the right way.

I would have left the RubyGems section outside the book. There have been several changes in the Gems community in the last years and the chapter appears to be slightly outdated. I would have left this topic outside the book.

As a side note, I would have appreciated a wider usage of Ruby 1.9 over 1.8 in order to discourage the adoption of Ruby 1.8.

Who should read it?

If you are a beginner to intermediate level Ruby programmer, this book is a must read that it’s likely to help you improving your Ruby skill and writing code in the Ruby way.

If you are completely new to Ruby, I don’t recommend this book as a first reading. You might want to start with a Ruby reference to learn how programming in Ruby, then read Eloquent Ruby to learn how programming in the Ruby way.

If you are a Ruby expert and you have been writing Ruby for the last 5 years, don’t be too self-confident. I’m quite sure the book will be able to provide you some valuable advice more than once.

Sprockets is now integrated in Rails 3.1 and is the core library behind the new Rails 3.1 asset pipeline. What about if you want to use Sprockets outside a Rails project?

Sprockets exposes a very powerful Rack interface to serve assets over HTTP. Integrating Sprockets in a Rack application, such as a Sinatra project, turns out to be a very straightforward task.

But in my case, I wanted to use Sprockets preprocessing and bundling feature outside an HTTP application. And it turned out Sprockets is very good at doing this as well.

I have a custom shared template I created several months ago called docss. I use this for several projects such as Ruby Whois and RoboWhois. The template is composed of several CSS files. I have a Ruby rake script that merges these files and packages them into a single asset, then compress it and publish the result to Amazon CloudFront.

Instead of processing and merging the files using file system tasks I’m now delegating this task to Sprockets. The project directory structure looks like this

.
├── Gemfile
├── Gemfile.lock
├── Rakefile
├── build
│   ├── javascripts
│   │   └── all.js
│   └── stylesheets
│       ├── 960.css
│       ├── alignments.css
│       ├── all.css
│       ├── reset.css
│       ├── screen.css
│       └── syntax.css
├── lib
│   └── yuicompressor-2.4.2.jar
└── src
    ├── javascripts
    │   └── all.js
    └── stylesheets
        ├── 960.css
        ├── alignments.css
        ├── all.css
        ├── reset.css
        ├── screen.css.scss
        └── syntax.css

And here’s my compile task

require 'rubygems'
require 'bundler'
require 'pathname'
require 'logger'
require 'fileutils'

Bundler.require

ROOT        = Pathname(File.dirname(__FILE__))
LOGGER      = Logger.new(STDOUT)
BUNDLES     = %w( all.css all.js )
BUILD_DIR   = ROOT.join("build")
SOURCE_DIR  = ROOT.join("src")

task :compile do
  sprockets = Sprockets::Environment.new(ROOT) do |env|
    env.logger = LOGGER
  end

  sprockets.append_path(SOURCE_DIR.join('javascripts').to_s)
  sprockets.append_path(SOURCE_DIR.join('stylesheets').to_s)

  BUNDLES.each do |bundle|
    assets = sprockets.find_asset(bundle)
    prefix, basename = assets.pathname.to_s.split('/')[-2..-1]
    FileUtils.mkpath BUILD_DIR.join(prefix)

    assets.write_to(BUILD_DIR.join(prefix, basename))
    assets.to_a.each do |asset|
      # strip filename.css.foo.bar.css multiple extensions
      realname = asset.pathname.basename.to_s.split(".")[0..1].join(".")
      asset.write_to(BUILD_DIR.join(prefix, realname))
    end
  end
end

First I create a new Sprockets::Environment instance passing some configurations, such as a custom logger.

sprockets = Sprockets::Environment.new(ROOT) do |env|
  env.logger = LOGGER
end

Then I append the asset paths.

sprockets.append_path(SOURCE_DIR.join('javascripts').to_s)
sprockets.append_path(SOURCE_DIR.join('stylesheets').to_s)

Finally, I process and package the assets to the build directory.

assets.write_to(BUILD_DIR.join(prefix, basename))

Because sometimes I need to reference a single CSS file (e.g. alignments.css) instead of the entire bundle, I also build a standalone package for each CSS source. You might not want to do that.

assets.to_a.each do |asset|
  # strip filename.css.foo.bar.css multiple extensions
  realname = asset.pathname.basename.to_s.split(".")[0..1].join(".")
  asset.write_to(BUILD_DIR.join(prefix, realname))
end

Please keep in mind that if you want to use processors you must include the corresponding libraries. For example, if you want to support SASS processor you need to add the sass gem.

Here’s my Gemfile.

source "http://rubygems.org"

gem 'sass'
gem 'sprockets'

That’s all.

The result of this effort is the Rubyist, a collection of conventions and standards for Ruby programmers. The project is now open source, you can fork it and contribute.

the Rubyist Homepage

When I first started learning Ruby, several years ago, there was a very nice project called RubyGarden. This project was a real treasure for those learning Ruby because it was full of resources and information about the Ruby world. If you have been developing in Ruby for a long time, I’m sure you’ll remember it.

But most of all, the RubyGarden has been extremely helpful to me (and many others) in learning about Ruby conventions and the most notable Ruby best practices. One page in particular, the RubyStyleGuide, was a collection of Ruby coding standard and naming conventions that every Ruby developer ought to have been familiar with.

RubyGarden Ruby Style Guide

A lot has changed since then.

The RubyGarden project was shut down a few years ago. As far I remember, the wiki was invaded by spam and the www.rubygarden.org domain has now been hijacked.

The Ruby language has evolved. Ruby 1.8 and Ruby 1.9 have introduced several new syntax changes and conventions. Moreover, the adoption of the Ruby programming language has increased over the years and several new common programming patterns have arisen.

GitHub was born. If you are in the habit of read the source code, GitHub is like a chocolate factory for a child. You can find an countless number of Ruby projects, filter them, sort them and read the source code to learn from it. Just pick some random accounts owned by notable Ruby developers, explore their programming habits and learn new exciting best practices and patterns.

Even with these newly available resources, there are many times when an quick reference can come in most handy.

Whether you are a Ruby master or a newbie, I hope you’ll find the Rubyist to be a source of inspiration.

This article targets Rails 3 and Rails 3.1.

The information contained in this page might not apply to different versions.

There are several ways to force your Rails application to use SSL and the HTTPS protocol.

Rails >= 3.1

If you are using Rails 3.1 (currently available in beta1) or greater, this commit makes it incredibly easy to switch from HTTP/HTTPS and vice-versa.

Simply use config.force_ssl = true in your environment configuration.

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.force_ssl = true
  end
end

You can also selectively enable https depending on the current Rails environment. For example, you might want to keep HTTPS turned off on development, and enable it on staging/production.

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.force_ssl = false
  end
end

# config/environments/production.rb
MyApp::Application.configure do
  config.force_ssl = true
end

Behind the scenes, Rails adds the awesome Rack::SSL Rack middleware to your application middleware stack. Rack::SSL automatically filters the request, redirects not-HTTPS requests to the corresponding HTTPS path and applies some additional improvements to make sure your HTTPS request is secure.

Rails < 3.1

If you’re not using Rails 3.1 don’t worry. Enabling HTTPS is as easy as adding the following line to your environment configuration.

config.middleware.insert_before ActionDispatch::Static, "Rack::SSL"

Note that I’m passing Rack::SSL as string to delegate the loading of the class at the end of the Rails application initialization. Also note the middleware must be inserted in a specific position in the stack, at least before ActionDispatch::Static and ActionDispatch::Cookies.

Don’t forget to define Rack::SSL dependency in your Gemfile.

# Gemfile
gem 'rack-ssl', :require => 'rack/ssl'

Enabling HTTPS and HTTP in parallel

Transitioning an HTTP-based application to HTTPS might not be as easy as you think, especially if your application embeds assets from third-party hosts.

There are cases where you want to make your application available using both HTTP and HTTPS. For instance, we adopted this strategy in RoboDomain for a while when we moved the application to HTTPS.

Rack::SSL has a very interesting and undocumented feature. You can pass an :exclude option to determine when to enable/disable the use of HTTPS.

The following code enables Rack::SSL and all its filters only in case the request comes from a HTTPS connection.

config.middleware.insert_before ActionDispatch::Static, Rack::SSL, :exclude => proc { |env| env['HTTPS'] != 'on' }

Both the following URLs will continue to work, but the first one will trigger the Rack::SSL filters.

https://example.com

http://example.com

This solution also works very well for cloud providers like Heroku and completely replaces home-made solutions like the one I posted in this StackOverflow answer months ago, also featured here and here.

If you want to use SSL on Heroku and redirect the HTTP traffic to HTTPS, my suggestion is to go with Rack::SSL.

Today, Google is changing this limit again to 10 users. Here’s the content of the email.

Hello,

We recently announced upcoming changes to the maximum number of users for Google Apps. We want to let you know that, as a current customer, the changes will not affect you.

As of May 10, any organization that signs up for a new account will be required to use the paid Google Apps for Business product in order to create more than 10 users. We honor our commitment to all existing customers and will allow you to add more than 10 users to your account for DOMAIN at no additional charge, based on the limit in place when you joined us.

Sincerely,

The Google Apps Team

Starting from 10 May 2011, the new maximum number of users for a Google Apps for free account will be set to 10.

A couple of days ago I was notified about a but in a Rails application. The application crashed when trying to create a new record.

I changed the new action the day before, but I was sure all the tests passed and the action was covered with a pretty reasonable RSpec test suite. Moreover, the action method was one of the most simplest methods I have ever written.

def new
  @record = Model.new
end

I run the test suite, all green. I executed the page in the browser, it crashed.

My face when I discovered all tests passed but the action kept crashing.

After several minutes of debugging I discovered the culprit: RSpec (actually the RSpec Rails gem) doesn’t render the content of the action by default, like the common Rails functional tests do. In fact, @response.body always resulted in an empty string.

The view contained a statement like the following

<%= f.collection_select Model.all, :id, :name %>

that was misspelled and crashed when the template was rendered. But because RSpec doesn’t render the Rails views, the view was not covered by the tests at all.

The solution is simple and is called render_views.

To tell a controller to render the content of the view, simply call render_views.

require "spec_helper"

describe RecordsController do
  render_views

  describe "GET index" do
    # ...
  end
end

You can also enable render_views globally, in your spec_helper.rb file.

RSpec.configure do |config|
  config.render_views
end

The reason behind this choice is because RSpec Rails actually provides a special RSpec group called “view specs”.

describe "events/index.html.erb" do
  it "renders _event partial for each event" do
    assign(:events, [stub_model(Event), stub_model(Event)])
    render
    view.should render_template(:partial => "_event", :count => 2)
  end
end

According to the documentation, this is the right way to test Rails templates in RSpec. Honestly, I never really liked this feature and I tend to keep using controller specs — the RSpec equivalent of functional tests — (or alternative test tools) to test the views.

This article targets Rails 3. The information contained in this page might not apply to different versions.

This is article is part of my series Understanding Ruby and Rails. Please see the table of contents for the series to view the list of all posts.

A small-but-interesting feature introduced in Rails 3 is the built-in support for lazy loading.

Lazy loading is a very common design pattern. The concept is to defer initialization of an object until the point at which it is needed. This design pattern decreases the time required by an application to boot by distributing the computation cost during the execution. Also, if a specific feature is never used, the computation won’t be executed at all.

With Rails 3 you can now register specific hooks to be lazy-executed when the corresponding library is loaded.

class ApplicationController < ActionController::Base

  initializer "active_record.include_plugins" do
    ActiveSupport.on_load(:active_record) do
      include MyApp::ActivePlugins
    end
  end

end

In this case we register the block to be executed when the ActiveRecord library is loaded. If you read the ActiveRecord::Base source code, the very last line is a call to

ActiveSupport.run_load_hooks(:active_record, ActiveRecord::Base)

This line of code executes all the hooks previously registered for ActiveRecord.

lazy-load hooks in the wild

Perhaps one of the most frequent usage of the lazy-load hooks is in Rails plugins.

For example, if your plugin needs to register some helpers, you can write a hook to include the helpers in ActionView only when ActionView is loaded. If the environment is loaded from a rake task (which doesn’t necessary need ActionView), then your plugin hook won’t be executed and the Rails application will boot faster.

Here’s an example from the will_paginate gem.

require 'will_paginate'
require 'will_paginate/collection'

module WillPaginate
  class Railtie < Rails::Railtie
    initializer "will_paginate.active_record" do |app|
      ActiveSupport.on_load :active_record do
        require 'will_paginate/finders/active_record'
        WillPaginate::Finders::ActiveRecord.enable!
      end
    end

    initializer "will_paginate.action_dispatch" do |app|
      ActiveSupport.on_load :action_controller do
        ActionDispatch::ShowExceptions.rescue_responses['WillPaginate::InvalidPage'] = :not_found
      end
    end

    initializer "will_paginate.action_view" do |app|
      ActiveSupport.on_load :action_view do
        require 'will_paginate/view_helpers/action_view'
        include WillPaginate::ViewHelpers::ActionView
      end
    end
  end
end

Using lazy load in your libraries

So far, we only discussed about using lazy-loading to hook Rails core library. Because lazy-loading is an ActiveSupport feature, you can use it in your Rails applications but also in your own Ruby classes.

First, make sure to add a call to ActiveSupport.run_load_hooks at the end of your Ruby class.

class HttpClient
  # ...

  ActiveSupport.run_load_hooks(:http_client, self)
end

Now you can register on_load hooks everywhere passing the name of the library used in run_load_hooks.

class Request
  # ...

  ActiveSupport.on_load :http_client do
    # do something
  end
end

class Response
  # ...

  ActiveSupport.on_load :http_client do
    # do something
  end
end

Hook context

The run_load_hooks method takes a second parameter representing the context within the hook will be executed. It’s a common pattern to pass the class/instance the hooks refer to.

For instance, the ActiveRecord library mentioned at the beginning of the article passes self. In that context, self references the ActiveRecord::Base class.

This is useful because, if you want to include some custom methods into ActiveRecord, you can use the following block

ActiveSupport.on_load :active_record do
  include MyPlugin::Extensions
end

instead of

ActiveSupport.on_load :active_record do
  ActiveRecord::Base.send :include, MyPlugin::Extensions
end

There’s also an other interesting use case for this feature. If you want to perform some kind of lazy-initialization when an instance of a class is created, just pass the instance itself.

class Color
  def initialize(name)
    @name = name

    ActiveSupport.run_load_hooks(:instance_of_color, self)
  end
end

ActiveSupport.on_load :instance_of_color do
  puts "The color is #{@name}"
end

Color.new("yellow")
# => "The color is yellow"

Source Code

The source code of the lazy-loading feature is available in the lazy_load_hooks.rb file.