Simone Carletti's Blog » Programming

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

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.

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.

Getting Real Book Review

Simone Carletti — Tue, 01 Mar 2011 10:02:27 +0000

Getting Real (US | UK) is the first book published by 37signals, the famous company behind successful web applications such as Basecamp and Highrise, other than the company that created the Ruby on Rails framework.

Getting Real was published in 2006 but if you start reading it today, you will probably find it more relevant than several other programming and development books written in the last two months. This is because Getting Real is not about a language or technology. It isn’t about the latest cutting-edge development framework. Getting Real describes a way of thinking, describes an effective approach ideally suited to develop web based software.

To describe the book with the authors’ words

Getting Real is about skipping all the stuff that represents real and actually building the real things.

Getting Real is less. Less mass, less software, less of everything that’s not essential.

Getting Real is about iterations and lowering the cost of change.

Structure

The book is organized in 16 chapters, each one containing several essays.

Here’s the table of content:

Introduction
The Starting Line
Stay Lean
Priorities
Feature Selection
Process
The Organization
Staffing
Interface Design
Code
Words
Pricing and Signup
Promotion
Support
Post-Launch
Conclusion

If you want to get a preview of the content or read it online, the complete book is available online for free.

Essays

An essay is usually no more than 2 pages long. The essay size is one of the best aspects of the book. Keeping essays short actually make it possible to read them very quickly. You can easily schedule your reading. Do you have only 15 minutes available? Open the book, pick the next essay and changes are you will finish it in 10 minutes.

Short chapters help you to stay focused on the content. When it takes 30 minutes or longer to read a chapter, you might lose the concentration. How many times in the middle of a chapter and did you realize you didn’t remember what was written at the beginning of it?

Essays contain ideas, suggestions and examples to help you Getting Real. The book focus is on building software and web applications, but reading the book you will immediately realize that several topics are applicable to non-software activities too.

As the authors say, this book doesn’t have to be an all or nothing proposition. Even if you can’t embrace Getting Real fully, there are bound to be at least a few ideas in here you can sneak past the powers that be.

Who should read this book?

So, is Getting Real for you? For me, Getting Real is one of the best books I ever read about development methodologies since a long time. When I was reading the book, I had the same awesome feeling I first noticed when I read The Pragmatic Programmers book.

As an entrepreneur and the co-founder of RoboDomain, Getting Real has been a valuable resource. I discovered that several techniques and processes we applied to RoboDomain are proven to be successful and there’s still plenty of new things to be done to improve ourself and our product.

Getting Real is not the kind of book you can read and say “from tomorrow we have to start following all these guidelines”. You need to be ready to acknowledge the ideas it contains.

If you ever developed a web application or if you’re going to develop one. If you are an entrepreneur, designer or programmer. If concepts like versioning, agile development, iterations, continuous integration, testing and customer satisfaction mean something for you, then you will probably appreciate Getting Real.

And if you love meetings, spend several time writing specs, work several months before having a working version of your product, Getting Real might be a good book for, you provided that you read it by trying to understand why a specific approach has proven to be successful, rather than assuming this is just hot air.

In conclusion

As you might understand, I really enjoyed this book and I strongly recommend it.

I want to close this book review by quoting a couple of sentences that, in my opinion, better represent Getting Real.

Don’t be a yes-man

Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get.

Pay off your code and design “bills”

We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt. Hack together some bad code that’s functional but still a bit hairy and you’re building up debt.

The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don’t, you’ll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward).

Where to Find Getting Real

You can get a printed copy at Amazon.com, Amazon.co.uk, or at your other favorite book seller. The complete book is also available online for free.

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.

TabsOnRails 2.0.0

Simone Carletti — Tue, 08 Feb 2011 10:56:46 +0000

TabsOnRails is a simple Rails plugin for creating tabs and navigation menus. It provides helpers for generating navigation menus with a flexible interface.

Release 2.0.0 is now available. It targets Rails 3.0 and is no longer compatible con Rails 2.3.x.

You can download/install the Gem via RubyGems.

1	$ gem install tabs_on_rails

For more details please read the documentation or API.

How to restart God when you deploy a new release via Capistrano

Simone Carletti — Mon, 07 Feb 2011 12:37:15 +0000

I don’t have time to read and I want to jump immediately to the solution →.

Like the 90% of Rails developers, I use Capistrano to manage the deployment of my Rails applications. I also use God to monitor several application processes, such as DelayedJob workers.

The problem

Each time I execute a deployment, I need the restart all the Rails instances, including rake tasks and workers, otherwise they will continue to run with the previous (old) application version.

I cannot simply send a command to God via Capistrano because God is omnipotent and runs with root privileges, while Capistrano doesn’t (for security reasons I don’t deploy with a sudoer user).

Here comes the problem. How to restart God when you deploy a new release? I already discussed this problem in the past and the solution I adopted since today was to execute a command as root without using sudo. The problem with this solution, is that it requires you to type the root password each time you execute a new deploy. And this is extremely awkward.

Last week I was configuring a new Rails application and I decided to investigate a new solution. I really like the way how Phusion Passenger works: whenever you touch the /tmp/restart.txt file, Passenger restarts all the Rails processes.

Why not implementing the same behavior in God? Luckily, someone else already had the same idea before.

The solution

I found the following recipe on Gist.

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

module God
module Conditions
class RestartFileTouched < PollCondition
attr_accessor :restart_file
def initialize
super
end

def process_start_time
Time.parse(`ps -o lstart -p #{self.watch.pid} --no-heading`)
end

def restart_file_modification_time
File.mtime(self.restart_file)
end

def valid?
valid = true
valid &= complain("Attribute 'restart_file' must be specified", self) if self.restart_file.nil?
valid
end

def test
process_start_time < restart_file_modification_time
end
end
end
end

Save the code in your God application or on the server and make sure God loads it. My suggestion is to add the following line in the God configuration script (e.g. /etc/god/config)

1
2
3

# Load in all God shared configs.
# Share configs apply to all instances.
God.load "/etc/god/conf.d/*.god"

and save the file in the /etc/god/conf.d folder. In this way, when you’ll start God with

1	$ god -c /etc/god/config

all the shared recipes will be loaded.

Then, configure the monitored process to watch the restart file. The configuration is available as a state transition condition.

1
2
3
4
5
6

rails_root = "/path/to/rails"

restart.condition(:restart_file_touched) do |c|
c.interval = 5.seconds
c.restart_file = File.join(rails_root, 'tmp', 'restart.txt')
end

Taking the GitHub DelayedJob recipe as example, you should change

1
2
3
4
5
6
7

# restart if memory gets too high
w.transition(:up, :restart) do |on|
on.condition(:memory_usage) do |c|
c.above = 300.megabytes
c.times = 2
end
end

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

# restart if memory gets too high
w.transition(:up, :restart) do |on|
on.condition(:memory_usage) do |c|
c.above = 300.megabytes
c.times = 2
end

on.condition(:restart_file_touched) do |c|
c.interval = 5.seconds
c.restart_file = File.join(rails_root, 'tmp', 'restart.txt')
end
end

The restart_file can be whichever file you want. I strongly encourage to use the same /tmp/restart.txt Passenger file, in this way your processes will restart each time you restart the application.

Thanks to Amedeo for his help and thanks to Nathan Humbert for creating the original God configuration.

Get the currently described class in RSpec

Simone Carletti — Wed, 22 Dec 2010 15:18:59 +0000

If you look at my RSpec, you will probably notice a wide usage of a klass method.

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

describe Whois::Client do
context "#initialize" do
it "accepts a zero parameters" do
lambda { klass.new }.should_not raise_error
end

it "accepts a timeout setting with a value in seconds" do
client = klass.new(:timeout => 100)
client.timeout.should == 100
end
end
end

The klass method references the currently described object, in the case above Whois::Client.

Here’s the method definition.

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

# /spec/support/helpers.rb
module SupportHelpers
# Gets the currently described class.
# Conversely to +subject+, it returns the class
# instead of an instance.
def klass
described_class
end
end

RSpec.configure do |config|
config.include SupportHelpers
end

I normally save the definition in a file, and put the file into the /specs/support folder (which is automatically loaded in RSpec 2).

The klass method is very convenient helper to keep your specs cleaned and flexible, specially when using long namespaces.

Before that, I was used to define a @klass instance variable at the beginning of my specs/tests. It worked, but wasn’t really that clean.

1
2
3
4
5
6
7
8
9
10
11

describe Whois::Client do
before(:each) do
@klass = Whois::Client
end

context "#initialize" do
it "accepts a zero parameters" do
lambda { @klass.new }.should_not raise_error
end
end
end

1
2
3
4
5
6
7
8
9

class Whois::ClientTest < Test::Unit::TestCase
def setup
@klass = Whois::Client
end

def test_initialize_with_zero_parameters
assert_nothing_raised { @klass.new }
end
end

I’m very grateful to RSpec because it seems to adapt perfectly to any developers’ need.

Capistrano: Executing a command as root without using sudo

Simone Carletti — Tue, 27 Jul 2010 11:20:40 +0000

I don’t have time to read and I want to jump immediately to the solution →.

The problem

From the day I started using DelayedJob in combination with God, I faced the problem to restart the god group every time I deployed a new application release.

In fact, when a rake task (God runs DelayedJob using the rake jobs:work task, here’s the config) is started, it loads the entire Rails environment and keeps it in memory as long as the process is running. When you deploy a new version, if you don’t restart the rake task, DelayedJob continues to run with the previous Rails version environment.

To restart a task/group in God:

1	$ god restart GROUP_NAME

Speaking about my servers, the problem is that God runs as root while Capistrano deploys new releases using a not-root not-sudo user, for security purposes. In practice, it means I can’t use the Capistrano sudo command because the deploy user is not in the sudoers list. Fortunately, the solution exists and is to run the command as su -c .

The gotcha here is that when you use su you have to handle the remote server root password prompt. Thanks to Capistrano, this is as easy as pie.

Here’s the method I created to run the command.

The solution

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

# Runs +command+ as root invoking the command with su -c
# and handling the root password prompt.
#
# surun "/etc/init.d/apache reload"
# # Executes
# # su - -c '/etc/init.d/apache reload'
#
def surun(command)
password = fetch(:root_password, Capistrano::CLI.password_prompt("root password: "))
run("su - -c '#{command}'") do |channel, stream, output|
channel.send_data("#{password}n") if output
end
end

And here’s the final Capistrano/DelayedJob/Run code fragment.

1
2
3
4
5
6
7
8

namespace :god do
desc "Restart the god group 'GROUP_NAME'"
task :restart, :roles => :app do
surun "god restart GROUP_NAME"
end
end

after "deploy:restart", "delayed_job:restart"