Simone Carletti's Blog » ruby

Eloquent Ruby Book Review

Simone Carletti — Mon, 03 Oct 2011 09:49:25 +0000

Eloquent Ruby (US | UK) by Russ Olsen is a book about the Ruby programming language that focuses on Ruby programming style by teaching you how to write your code as a real Rubyist.

This is the second Olsen’s book about Ruby. In 2007 he published Design Patterns in Ruby, an other great example of how common programming practices like Design Patterns apply to the Ruby world.

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.

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.

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.

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 one of the reasons that convinced me to create the Rubyist.

Structure

The book is divided into 4 parts:

The Basics
Classes, Modules, and Blocks
Metaprogramming
Pulling It All Together

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

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 forth 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.

Chapters

Write Code That Looks Like Ruby
Choose the Right Control Structure
Take Advantage of Ruby’s Smart Collections
Take Advantage of Ruby’s Smart Strings
Find The Right String With Regular Expressions
Use Symbols to Stand for Something
Treat Everything Like an Object – Because Everything Is
Embrace Dynamic Typing
Write Specs!
Construct Your Classes from Short, Focused Methods
Define Operators Respectfully
Create Classes That Understand Equality
Get The Behavior You Need with Singleton and Class Methods
Use Class Instance Variables
Use Modules as Name spaces
Use Modules as Mixins
Use Blocks to Iterate
Execute Around with a Block
Save Blocks to Execute Later
Use Hooks to Keep Your Program Informed
Use method_missing for Flexible Error Handling
Use method_missing for Delegation
Use method_missing to Build Flexible APIs
Update Existing Classes with Monkey Patching
Create Self-Modifying Classes
Create Classes That Modify Their Subclasses
Invent Internal DSLs
Build External DSLs for Flexible Syntax
Package Your Programs as Gems
Know Your Ruby Implementation
Keep An Open Mind to Go With Those Open Classes

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.

Plus

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.

As as long time Ruby developer I really loved the Use Symbols to Stand for Something, object and block chapters. Some of them didn’t necessary teach anything new, but the way used to present the concepts was very helpful and understandable.

I appreciate the focus on tests and the RSpec chapter. The most part of Ruby books dedicate a specific section about tests, then seem to forget them for the rest of the chapters. This is not the case of this book, where several examples are verified by tests.

Finally, the simple colloquial tone makes the book really friendly. It seems like a person you always worked with is now teaching you programming and thinking in the Ruby way.

Minus

It’s really hard to find some real negative in this 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.

The same applies to the RubyGems sections. There have been several changes in the Gems community in the last years and the chapter appears to be slightly outdated. Again, I would have left this topic outside the book.

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

In Conclusion

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, personally 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. Also, don’t forget about the Rubyist, you’ll find several Ruby common practices and coding conventions.

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.

Where to Find Eloquent Ruby

You can get a printed or Kindle copy at Amazon.com, Amazon.co.uk, or at your other favorite book seller.

Kindle Preview

Using Sprockets without a Rails/Rack project

Simone Carletti — Thu, 22 Sep 2011 15:28:56 +0000

Sprockets is a Ruby library for compiling and serving web assets. It features declarative dependency management for JavaScript and CSS assets and a vert powerful preprocessor pipeline that allows you to write assets in languages like CoffeeScript, Sass or SCSS.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

.
├── 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

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 => :cleanup 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.

1
2
3

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

Then I append the asset paths.

1 2	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.

1	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.

1
2
3
4
5

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.

1
2
3
4

source "http://rubygems.org"

gem 'sass'
gem 'sprockets'

That’s all.

The Road to Rails 3: make your Rails 2.3 project more Rails 3 oriented

the Rubyist

Simone Carletti — Wed, 07 Sep 2011 14:42:39 +0000

Several years ago I started keeping track of Ruby coding conventions that my team and I were using in-house. The purpose was to document the most important guidelines we employ in order to keep our libraries and source code consistent, regardless the maintainer.

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.

RubyGarde 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.

No related posts.

RSpec Rails doesn’t render Rails views by default

Simone Carletti — Tue, 12 Apr 2011 07:54:23 +0000

If you are using RSpec and RSpec Rails to test your Rails application, I strongly encourage you to keep reading this post because there’s a gotcha in the default configuration you might not expect, especially if you ever used the default Rails test framework before.

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.

1
2
3

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

1	<%= 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.

1
2
3
4
5
6
7
8
9

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.

1
2
3

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”.

1
2
3
4
5
6
7

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.

Understanding Ruby and Rails: Lazy load hooks

Simone Carletti — Thu, 07 Apr 2011 08:22:54 +0000

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.

1
2
3
4
5
6
7
8
9

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

1	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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

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.

1
2
3
4
5

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

1
2
3

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

instead of

1
2
3

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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.

Whois 2.0

Simone Carletti — Thu, 17 Mar 2011 20:58:19 +0000

One year after the first major release, almost 2 years after the first commit, 1k commits and 59 versions after, I’m very proud to announce the immediate availability of Whois 2.0.

Whois is an intelligent, pure Ruby, WHOIS client and parser. It provides a flexible and programmable API to query WHOIS servers and look up IP, TLD, and domain WHOIS information. It also offers command-line interface to run WHOIS queries from the console.

This second major release, the 60th since I released the gem, is a very important milestones. I started working on this project with the idea of creating a Ruby parser for each TLD available and it took me two years and countless hours to reach this goal.

Some stats

To give you a rough idea about the complexity of this project, here’s a few numbers about Whois 2.0.

866,706 different WHOIS records (~3.3 GB of data) analyzed as of March 16th, 2011
425 RSpec test files
444 fixture files extracted from real WHOIS records
3787 RSpec examples and an unknown number of matches (sorry, I stopped keeping track of them when they reached 15k assertions) that probably makes this project one of the gems with the largest RSpec test suite
~20.000 lines of code, including the test files
168 different WHOIS parsers

Oh, man. You can’t believe the amount of work required to cover all the existing WHOIS servers, their features and especially their whims.

New and Notable

The increasing support for all existing TLD servers is probably one of the most important changes for this milestone. But the CHANGELOG is very huge and there are a few other changes that are worth a mention.

I already blogged about a few of them.

The #nameservers property now returns a Nameserver object. This change allows the parser to also extract name server IPv4 and IPv6 addresses.
A new caching mechanism reduces the number of instance variables created.
The library now supports the Gem Testers project.
You can now bind a different address or port to the WHOIS socket request.

Last but not least, the Whois::Answer class has been renamed to Whois::Record.

There are a couple of backwards-incompatible changes to the API. These changes were necessary to evolve the API to better reflect the representation of the existing WHOIS responses.

What’s Next?

The Whois library is pretty stable. It is now used in production for several big projects.

The API is mature. A few changes have been made in this major release to support additional WHOIS properties, however I don’t expect big changes in the future.

The following releases will focus on increasing the list of supported properties for each parser, as well closing some of the existing issues.

The biggest change in the API in the near future is likely to be the standardization of the status property.

In the last months I received some great feedback from people using my library with other platforms, such as Java and .NET. This is amazing.

If you have any case study, case history or feedback, please let me know. I would love to learn more about how you use the library.

How to Upgrade

To upgrade to Whois 2.0 please follow the instructions in the documentation page.

Ruby 4 Rails – Learning Ruby, with Rails in mind

Simone Carletti — Mon, 07 Mar 2011 09:47:30 +0000

A few weeks ago, a friend of mine told me he wanted to learn Rails. He asked me to prepare a private course about Rails and to teach him the basics of the framework.

After a brief discussion, we ultimately agreed that he couldn’t effectively use Rails without being a Rubyist. For this reason, I offered him to start with a Ruby concentrate, carefully prepared keeping an eye on Rails.

The presentation is called Ruby 4 Rails and is now available on GitHub. It is based on ShowOff, a Markdown-to-HTML presentation tool created by Scott Chacon. Make sure to read the README to learn how it works.

The initial part of the README is largely inspired by John’s post about Ruote.

Ruby 4 Rails is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Based on a work at github.com.

New in Whois: #nameservers are now Nameserver

Simone Carletti — Mon, 07 Mar 2011 08:58:51 +0000

It’s time for another update on Ruby Whois library. Let’s talk about name servers.

The most part of WHOIS servers follow the “convention” to include the name server list of a domain in the WHOIS record.

A name server is represented by a DNS name, which is a string.

1 2	ns1.google.com ns2.google.com

The DNS name resolves to an IPv4 IP address.

1 2	ns1.google.com => 216.239.32.10 ns2.google.com => 216.239.34.10

Optionally, the DNS name can resolve to an IPv6 IP address.git

1 2	ns1.nic.fr => 2001:660:3003:2::4:1 ns2.nic.fr => 2001:660:3005:1::1:2

Each WHOIS server arbitrary choses the amount of information to store and return in a WHOIS record. Some registries returns only the DNS name, other registries include IP addresses as well.

In the current WHOIS version, the list of name servers is accessible through the #nameservers property.

1
2
3

r = Whois.query "google.com"
r.nameservers
# => ["ns1.google.com", "ns2.google.com"]

The method returns an Array of String. This is a lossy implementation because it completely ignores the IPv4 and IPv6 details.

The new Whois version solves this problem by introducing a new Whois::Answer::Nameserver object. This object is a Struct composed by three attributes: name, ipv4 and ipv6.

1
2
3
4
5
6
7
8
9
10
11
12

ns = Nameserver.new(
:name => "ns1.nic.fr",
:ipv4 => "192.134.4.1",
:ipv6 => "2001:660:3003:2::4:1"
)

ns.name
# => "ns1.nic.fr"
ns.ipv4
# => "192.134.4.1"
ns.ipv6
# => "2001:660:3003:2::4:1"

In the new Whois version, the #nameservers implementation has been changed to return an array of Nameserver instead of a simple String.

1
2
3
4
5
6
7

r = Whois.query "nic.fr"
r.nameservers
# => [
# #,
# #,
# ...
# ]

It’s important to know that this change can break backwards compatibility. In order to minimize the impact, Nameserver#to_s returns the String value of the name attribute.

1 2	Nameserver.new(:name => "ns1.nic.fr", :ipv4 => "192.134.4.1").to_s # => "ns1.nic.fr"

New in Whois: improved caching

Simone Carletti — Tue, 15 Feb 2011 11:15:45 +0000

I’m working very hard to include some of the most important features in the new version of the Ruby Whois library.

Today, I’m very happy to report that this week I closed the issue #18 which introduces a completely new caching system for the Whois::Answer::Parser.

The way Whois parsers currently work, is to extract a property only the very first time it is requested.

1
2
3
4
5
6
7
8
9
10
11

r = Whois.query "weppos.it"

# the property has never been requested before
# the value is computed, cached and returned
r.status
# => :ok

# the property has been requested before
# the value is returned without further elaborations
r.status
# => :ok

So far, so good.

The way the system works under the hood, is to create a parser instance variable for every single requested property.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

r = Whois.query "weppos.it"

# get the first parser
# because
# r.status relies on
# a
# r.parser.parsers.first.status
p = r.parser.parsers.first

# value is not cached
p.instance_variable_get("@status")
# => nil

p.status
# => :ok

# value is cached
p.instance_variable_get("@status")
# => :ok

So far, quite good. This approach has a couple of drawbacks.

First, it creates an instance variable for every single property. Because of the large (and increasing) number of properties, the parser object space counts a large number of instance variables. This makes it hard, for instance, to sweep the cache because you have to loop through all instance variables and remove each one.

Second, there’s a small inefficiency here. Because in Ruby you don’t have to define variables, an undefined instance variable is nil. But nil is actually a value and properties can have a nil value. In this implementation, you don’t have a way to distinguish when a value is nil and when it hasn’t been elaborated yet, thus nil properties will never hit the cache.

1
2
3
4
5
6
7
8

def created_on
@created_on ||= if very_expensive_scan(/created_on/)
# ... set the value
end
end

# calling #created_on several times will continue to perform
# the very_expensive_scan as long as the value != nil.

The new approach uses a single instance variable called @cached_properties as cache. The variable contains a Hash<:key => value>, where the key is the property and the value the cached result.

If the cache doesn’t contain any key for given property, then the method hasn’t been executed yet. Cached nil properties will return nil without further elaboration.

The method #cached_properties_fetch takes care of everything.

1
2
3
4
5
6
7
8
9
10
11
12
13

def created_on
cached_properties_fetch(:created_on) do
nil
end
end

# value is cached and returned
created_on
# => nil

# the request hits the cache
created_on
# => nil

If you need to sweep the cache, reset @cached_properties to an empty Hash.

New in Whois: Gem Testers

Simone Carletti — Mon, 14 Feb 2011 16:18:37 +0000

At the beginning of February, Engine Yard announced a very interesting project called Gem Testers.

Gem Testers was built to make it easier for gem developers to write gems that run everywhere. This is split into two pieces:

rubygems-test is a Rubygems plugin which automatically runs the test suite of a specified gem on install.

Gem-testers.org is a central repository for test data. Test results are organized primarily by Ruby version and operating system.

I believe this is a wonderful project and it can have a very good impact on the quality of the available Ruby gems.

Whois currently counts 211 RSpec examples and 1899 tests with 8674 assertions. This is a very huge test suite which is able to provide an immediate feedback on existing bugs.

The new Whois version now includes support for gem test. You can decide to run the tests automatically when installing the gem or run them later by executing

1	$ gem test whois

Read rubygems-test README for further information.

Unfortunately, this feature forced me to re-include all the test fixtures and files into the packaged .gem. It means the size of .gem file will be bigger than previous releases.