H3RALD

Book Review: Design Patterns in Ruby

h3rald — Fri, 11 Apr 2008 05:41:00 -0600

I finally got my hands on a shiny new copy of Design Patterns in Ruby¹. The book itself is not brand new and it was already widely praised by many different people online, so I wanted to take a look for myself.

To my surprise, the book is a hardcover edition, which makes it look more professional and more durable than the average programming book². It’s also smaller and shorter than the average programming book² (340 pages), which makes it much easier to carry around and less intimidating to read. It’s also not meant to be a reference book, so it is actually pleasant an easy to read all in one go, as you’ll soon find out.

What is it about? — well, design patters in the Ruby language of course. But it’s not the usual brainwash of programming theory you would expect by a typical book on patters, it has plenty of examples of real code. When I say real code I don’t mean the usual Dog/Cat/Horse/<insert animal here> classes or juke-box simulations which don’t work at all etc. etc., I mean actual snippets from well known Ruby applications, like RubyGems, FXRuby and, of course, Rails. OK well, there’s an exception perhaps: Russ did include a few wild life simulations (ponds with frogs and similar), but it’s only for your own good, and for the sake of tradition.

Anyhow, let’s start from the beginning…

Part I: Patters and Ruby

The first part of the book serves as a general introduction to the other two parts. If you know the basics of both design patterns and Ruby, you can safely skip this as you won’t find anything of overwhelming interest here.

Personally I really liked Chapter 1 though, “Building better Programs with Patterns”, in which Russ does a great job in summarizing the original GoF book³ into four points::

Separate our the things that change from those that stay the same.
Program to an interface, not an implementation.
Prefer composition over inheritance.
Delegate, delegate, delegate.

Also, although it does not come from the Design Patterns book but from building real systems, the author adds the YAGNI (You Ain’t Gonna Need It) principle⁴ as a reminder to resist the temptation of implementing things which may be needed later on, even if they are not needed right now. The chapter ends with an outline of the patterns which will be presented throughout the book: 14 out of the original 23 patterns by the Gand of Four will be discussed in Part II and 3 bonus “Ruby-only” patterns will be examined in Part III, as a special treat.

Chapter 2 (Getting started with Ruby) feels perhaps a bit out of place. As others pointed out⁵, why does a book on advanced Ruby programming techniques include a 35-page-long introduction on the Ruby language? The answer was given by Russ himself in an interview⁶:

“The reason that I included the introductory chapter about Ruby in there was to make the book accessible to folks with little or no Ruby background. Now honestly, I don’t think that you could come to my book with no background in Ruby and walk away from it an expert Ruby programmer — it’s not really that kind of introductory book. But I do think that someone with experience in other languages could read my book and come away knowing about Ruby, understanding what all the shouting is about.”

I admit, I skipped this chapter during my first reading because I was eager to move on to the main part of the book, but I did read it afterwards (I had to write this review after all!). It’s quite a nice introduction aimed at the average .NET/Java developer: Russ provides a step-by-step presentation of the main features of the language while holding the reader by hand when something weird or scary comes about:

The slightly strange-looking syntax in this code is actually a tip-off something deep and important: In Ruby, everythng — and I mean everything — is an object.

Of course Chapter 2 won’t turn you into a Ruby guru, but it definitely fulfills one of the author’s goals: bringing developers of other languages closer to Ruby, and give them a tiny taste of how Ruby can be wickedly powerful.

Part II: Patterns in Ruby

Part II constitutes the bulk of the book, describing 14 GoF patterns in 220 pages. The patterns covered are the following:

Template Method
Strategy
Observer
Composite
Iterator
Command
Adapter
Proxy
Decorator
Singleton
Factory Method
Abstract Factory Method
Builder
Interpreter

Why not covering all 23? Well, because to be honest, they are rarely used in Ruby. Furthermore, in some cases some of the ones examined in the book may feel a bit unnatural to the average Rubyist: how many times did you ever think about using an External Iterator when each is normally available as default internal iterator for any Array-like class?

Each chapter in this part is devoted to a particular pattern and it is organized in more or less the same way, as outlined in the following sections.

Introduction and Personal Anecdotes

Most chapters start with a personal anecdote involving the author: it may be a memory related to his first job at the local grocery store (Chapter 8), or about the day he decided to buy his son a bike (Chapter 14):

“I remember the day we bought my son his first bike.” […] I spent hours trying to pull together a minor junkiard of parts according to instructions that would have baffled the entire National Security Agency. As it turned out, picking the bike was the easy part: putting it together was the real challenge.

This was used to introduce the Builder pattern, and how to use it to configure objects which include different logical parts. Personally I find this technique particularly useful to introduce a particular problem from a different, more mundane prospective instead of starting off with an abstract theorethical description of the pattern itself. The anecdote is then followed by the description of the actual programming problem for which the specific pattern will be used.

Description of the Pattern and Initial Implementation

An initial implementation of the pattern in Ruby will be provided more or less immediately after the introduction of each chapter, often accompanied by a simple UML diagram. This implementation normally has quite a few conceptual flaws, which are then examined and corrected step-by-step the chapter to obtain a more “Ruby-friendly” solution.

A More Rubyfied Version of the Pattern

The final implementation of each pattern is often very different from the initial attempt, and it may contain quite a lot of Ruby-specific code. The author does an excellent job in suggesting pattern implementations which often use blocks, Proc objects or method redefinitions when needed, to make the code more succint and more readable at the same time, as all Ruby code should be.

By doing so, even people who are still learning Ruby will understand how to use some very useful Ruby idioms which can be a bit difficult to grasp otherwise.

Using and Abusing <Pattern>

Patterns are often overused and misused, and some people normally end up wondering if they should be used at all, after all. This section (present as a matter of fact in every chapter of part II an III) examines the pitfalls of the pattern and the most common mistakes developer make when applying it. It is by far the most useful section of each chapter, and that’s what I’ll be reading and re-reading every time I’m thinking about using a particular pattern in my code. As a matter of fact, these sections make you realize that every pattern has its own inherent flaws and dangers, and that it is far from being a Silver Bullet. Even when you’re supposed to use a pattern to accomplish something, be aware that something nasty can happen unless you’re extra careful: this, perhaps, is the true Golden Rule conveyed throughout the whole book.

<Pattern>s in the Wild

This is another very interesting section which is included in every chapter of part II and III. After describing what a pattern does, how it can be used and how it should be used, you’ll finally find some interesting examples taken from real world applications. By “real world application” I mean something like ActiveRecord⁷ (Observer, Command, Adapter, …), DRb⁸ (Proxy) or FXRuby⁹ (Composite), for example, i.e. important programs and libraries which are used in production environments. Personally, I was really glad to find such examples in this book: it definitely helps you feeling design patterns as something more practical and useful than pure software architecture theories.

Wrapping it Up

“Wrapping it Up” is the title of the last section of each chapter of Part II and III. It’s basically a summary of the whole chapter and thus a useful way to recap the most important concepts. I found this section particularly useful when using the book as a design pattern reference, after reading it for the first time: this section provides a quick and essential overview of each pattern—and the most important DOs and DON’Ts, too.

Part III: Patterns for Ruby

By the time you get to Part III you’ll definitely feel that Ruby can do more. Some of the Ruby implementation of certain patterns described in the book make extensive use of blocks and Proc objects, and the method_missing method (although potentially dangerous unless extra care is taken) gives us a more immediate way to obtain delegation, for example when creating Proxies. Also the fact that objects can be modified at runtime by adding and removing methods “as needed” seems quite an underused feature in traditional patterns, simply because those patterns were first conceived for languages which are very different from Ruby and are perhaps less liberal than Ruby when it comes to dynamic features¹⁰.

These particular Ruby features can be used (and abused, of course) to implement more Ruby-esque patterns, such as the ones included in this part of the book:

Internal Domain-Specific Languages
Meta-Programming
Convention Over Configuration

These are just examples, of course some may complain because the Active Record or ORM pattern are missing, but this is understandable as it may be considered too specific compared to the others. Each pattern is examined in detail, and I particularly like way the DSL pattern was described: Chapter 16 explains how to develop a simple but effective Ruby DSL from scratch for creating file backups. This can be particularly useful for people who never tried creating DSLs before, but also for developers who tried, but want to improve their skills.

Chapter 18 (Convention Over Configuration) is sufficiently clear and detailed, perhaps even too much if you already know how Rails was developed (and all the hype which follwed).

On the other hand, I was a bit disappointed by Chapter 17 (Meta-Programming). Maybe it’s because I built up extremely high expectations about it while reading the rest of the book, but it just felt too short and not detailed enough for my liking. If I had to write such a chapter (which would have been actually very hard), I would have started from an excellent post by Ola Bini¹¹ which introduces eleven meta-programming techniques, and built up content and examples from there. The only reason why ~~- I think -~~ Russ didn’t do it in his book was length/balance constraint: a properly detailed chapter about meta-programming in Ruby could easily take up over forty pages!

The Verdict

As I said in the beginning: this is not meant to be a complete, in-depth, reference book on everything you may want to know about design patterns in Ruby. That’s why, as a matter of fact, you can actually read this book all the way through without getting utterly bored. Russ uses an informal, yet appropriate style to turn potentially complex, theorethical computer science principles into easy-to-understand, useful tools which can truly improve the way you code.

The whole book flows very very nicely. I actually recommend reading this book in sequence, without skipping chapters, because each pattern is described in a way that is somehow linked to the following ones, so that you can understand and learn about the pros and cons of each one in a more natural and useful way.

OK, I would have loved to see Part III as long as Part II, probably, but overall I’m very, very satisfied of what the book taught me. The only problem is that it also made me suddenly realize all the naive design mistakes I’ve been making when coding in Ruby, so I’ll now feel compelled to fix at least some of them…

Definitely a worthwhile read, I just hope to see more books like this, or even a second edition of this one soon!

Notes

¹ Design Patterns in Ruby by Russ Olsen, Addison Wesley Professional, 2007.

² Think of Programming Ruby: The Pragmatic Programmer’s Guide, 2nd Ed. by Dave Thomas with Chad Fowler and Andy Hunt, Pragmatic Programmers, 2004.

³ Design Patterns: Elements of Reusable Object-Oriented Software, by By Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides (a.k.a. the Gang of Four), Addison Wesley Professional, 1994.

⁴ For more information on the YAGNI principle, visit You’re NOT gonna need it, Ronald E Jeffries.

⁵ See Design Patterns in Ruby, a review, _On Ruby_blog.

⁶ See Russ Olsen Interview, _On Ruby_blog.

⁷ ActiveRecord is an implementation of the Object-Relational Mapping (ORM) pattern used by the Ruby on Rails framework.

⁸ Distributed Ruby, see Intro to DRb by Chad Fowler.

⁹ FXRuby, a graphical toolkit written in Ruby.

¹⁰ This can be a good or bad thing depending on the way you look at it, and what you want to use the language for. The fact that Ruby is dynamically typed makes it easier to do things which are totally impossible in C++ or Java, but it also introduces a whole new set of potential dangers.

¹¹ Ruby Metaprogramming Techniques, Ola Bini: Programming Language Synchronicity.

New Release: RawLine 0.2.0

h3rald — Wed, 02 Apr 2008 05:33:00 -0600

~~InLine~~ RawLine 0.2.0 is out!

RawLine is the new name for InLine, in case you didn’t guess. The name was changed to avoid name collision problems with the RubyInline project.

Here’s what’s new:

Added /examples and /test directory to gem.
Escape codes can now be used in prompt.
It is now possible to use bind(key, &block) with a String as key, even if the corresponding escape sequence is not defined.
Added Editor#write_line(string) to print a any string (and “hit return”).
Library name changed to “RawLine” to avoid name collision issues (Bug 18879).
Provided alternative implementation for left and right arrows if terminal supports escape sequences (on Windows, it requires the Win32Console gem).

In particular, I decided to provide an “optimized implementation” for the left and right arrows using escape sequences rather than shameful hacks. This is now possible because the Win32Console gem now enables ANSI escape sequences on Windows as well (weehee!).

So:

If you’re on *nix all good, your terminal is smart and can understand escape sequences => the new implementation will be used.
If you’re on Windows and you installed Win32Console, your termnal is smart and can understand escape sequences => the new implementation will be used.
If you’re on Windows and you didn’t install Win32Console, then your terminal is stupid and it doesn’t understand escape sequences, so the old implementation will be used.

The new implementation is significantly faster than the old one, on Windows at least, and the cursor now blinks properly when left or right arrows are pressed.

I re-emplemented only cursor movement because I’m still having some problems in getting the delete/insert escapes to work properly (or better: how I want them to work!).

InLine name change: what's your opinion?

h3rald — Thu, 27 Mar 2008 06:30:00 -0600

I’ve been kindly asked by the lead developer of RubyInLine to change the name of my InLine project, due to potential confusion and conflicts.

This makes sense, and I’m ready to change the name of my project, although I’m not that good at choosing original and smart names, so well, any suggestion is more than welcome!

I was thinking of something like:

RawLine
EditLine
RawInput
RubyInput
RubyLine

I personally think that RawLine is probably the best option, but please, if have any better idea just speak up!

P.S.: “RedLine” is taken, unfortunately, otherwise it would have been my first choice since the beginning.

RawLine - a 100% Ruby solution for console inline editing

h3rald — Mon, 10 Mar 2008 06:59:00 -0600

One of the many things I like about Ruby is its cross-platform nature: as a general rule, Ruby code runs on everything which supports Ruby, regardless of its architecture and platform (yes, there are quite a few exceptions, but let’s accept this generalization for now).

More specifically, I liked the fact that I could use the GNU Readline library with Ruby seamlessly on both Windows and Linux. Readline offers quite a lot of features which are useful for those people like me who enjoy creating command-line scripts, in a nutshell, it provides:

File/Word completion
History support
Custom key bindings which can be modified via .inputrc
Emacs and Vi edit modes

Basically it makes your command-line interface fast and powerful, and that’s not an overstatement. Ruby’s own IRB can be enhanced by enabling readline and completion, and it works great—at least on *nix systems.

For some weird reason, some people had problems with Readline on Windows: in particular, things get nasty when you start editing long lines. Text gets garbled, the cursor goes up one or two lines and doesn’t come back, and other similar leprechaun’s tricks, which are not that funny after a while.

Apparently there’s no alternative to Readline in the Ruby world. If you wan’t tab completion that’s it, you’re stuck. Would it be difficult to implement some of Readline functionality natively in Ruby? Maybe, but the problem is that for some reason the Ruby Standard Library doesn’t have low level methods to operate on keystrokes…

…but luckily, the HighLine gem does! James Edward Gray II keeps pointing out here and here that HighLine’s own get_character method does just that: it returns the corresponding character code(s) right when a key is pressed, unlike IO#gets() which waits for the user to press ENTER.

Believe it or not, that tiny method can do wonders…

Reverse-engineering escape codes

So here’s a little script which uses get_character() in an endless loop, diligently printing the character codes corresponding to a keystroke:

#!/usr/local/bin/ruby -w

require 'rubygems'
require 'highline/system_extensions'

include HighLine::SystemExtensions

puts "Press a key to view the corresponding ASCII code(s) (or CTRL-X to exit)."

loop do

    print "=> "
    char = get_character
    case char
    when ?\C-x: print "Exiting..."; exit;
    else puts "#{char.chr} [#{char}] (hex: #{char.to_s(16)})";
    end

end

A pretty harmless little thing. Try to run it and press some keys, and see what you get:

Press a key to view the corresponding ASCII code(s) (or CTRL-X to exit).

	=> a [96] (hex: 61)
=> 1 [49] (hex: 31)
=> Q [81] (hex: 51)
=> α [224] (hex: e0)
=> K [75] (hex: 4b)

Hang on, what are the last two codes? A left arrow key on Windows, apparently.

Welcome to the wonderful world of input escape sequences!

To cut a long story short, both Windows and *nix system “terminals” translate special keystrokes into sequences of two or more codes. This applies to things like DEL, INSERT, arrows, etc. etc. For some ideas, check out:

Windows Scancodes (Thanks Huff)
VT220 Terminal Input Sequences (Thanks James)

Let’s now assume that we’re smart and we can write a program which can parse keystroke properly, including handling different input escape sequences according to the OS, what can it be used for? Well:

For normal characters, just print them back to the screen (get_character doesn’t print anything, it “steals” the keystroke)
For special characters, do something nice!

We could setup TAB to auto-complete the current word according to an array of matches, or bind the up arrow to load the last line typed in by the user, for example, that’s basically something Readline does, right?

RawLine: how it works and what it does

I created a small project on RubyForge called RawLine (not to be confused with RubyInline, a completely different thing altogether, sorry about that) to play around with the possibilities offered by the get_character method. The library is just a preview of things which can be done, but it’s already usable, provided that you’re brave enough to try it out, that is.

The basic idea behind RawLine is to be able to parse keystrokes properly on different platforms and re-bind them to a set of predefined, cross-platform actions or a user-defined code block.

Basic line-editing operations

The first challenge was to re-invent the wheel, i.e. re-bind keystrokes to their typical actions: a left arrow moves the cursor left, a backspace deletes the character at the left of the cursor and so on. Yes, because get_characters gives you the right character codes at the price of cancelling their normal effects, which is a great thing, as you’ll soon find out.

Printing a character on the screen was one of the easiest tasks (at first). IO#putc does the job pretty well: it prints a character out. What about moving left? Easy: print a non-descructive backspace (\b) and hope it is really not destructive. I did some tests and it seems to do as it’s told and move the cursor back by one position.

Moving right was a little trickier: the easiest thing I found was to re-print the character under the cursor, which will then move the cursor forward (as naive as it may seem, it does the job!). If there’s nothing under the cursor, then we must be at the end of the line and it shouldn’t move anywhere, so there we go.

What if I move left a bit and then start typing normal characters? Well, everything is rewritten of course: this will be our “character replace mode”. Unfortunately users don’t like this behavior that much, so what I did was this:

Copy all characters from the one at the left of the cursor till the end of the line
Print the character to be inserted
Re-print the previously-copied characters
Move the cursor back at the right place

Again, a primitive solution which works seamlessly on all platforms, and yes, it’s fast enough that you don’t notice the difference.

As you may have guessed, this of course means that I always had to keep track of:

The cursor position within the line
The text currently printed to the screen

Backspace and delete were implemented in a similar way, you can figure it out yourself or look at the source code: I won’t bore you any further!

History management

The next step was to implement a history for both the characters inputted by the user (to allow undoing and redoing operations) and for the whole lines. This was just an ordinary programming exercise: a simple buffer with some extra controls here and there, nothing too scary.

So every “modification” to the current line being typed is saved in a line history buffer and all the lines entered are saved in another history buffer. All is left is to allow users to navigate through these buffers back and forth. Nothing impossible: all I had to do was keeping track of the current element of the history being retrieved and then overwrite the current line with a new line stored in the buffer? How’s this line overwriting done? Same old:

Move the cursor to the beginnig of the line
Print X spaces, where X is the line length, so that the characters are no longer displayed in the console
Move the cursor back to the beginning of the line
Print the new line.

Easy and naive, as usual. But again, it works well enough.

Word completion

The other challange was word completion. The current implementation can be summarized as follows:

If TAB (or another character, if you wish) is pressed, call a user-defined completion_proc method which returns an array and show the first element of the array (in this case I actually used a cyclic RawLine::HistoryBuffer, not an array)
If the user presses TAB again, show another match, and so ad infinitum if the user keeps pressing TAB.
If the user presses another key, accept the default completion and move on.

Obviously this means that:

RawLine has to keep track of the current “word”. A word is everything separated by a user defined word_separator, which can obviously modified at runtime, with care.
Regarding the completion_proc, typically you may want to return only the elements matching the word which is currently being written, so that’s given as default parameter for your proc. Exactly like with ReadLine, the only difference is that you can access other things like the whole line and the whole history in real time, which can be really handy at times!

Here’s a simple example:

editor.completion_proc = lambda do |word|
    if word
        ['select', 'update', 'delete', 'debug', 'destroy'].find_all    { |e| e.match(/^#{Regexp.escape(word)}/) }
    end
end

Custom key bindings

All these pretty things are obviously bound to some keystrokes. If the key corresponds to only one code, everything is fine, but because special keys typically aren’t so it was necessary to implement a mechanism to track an escape key (e.g. 0xE0 and 0 on Windows and \e on Linux) and listen to further characters, in case a known sequence is found. Anyhow, the final result of the method used for character binding is the following:

bind(key, &block)

Where key can be:

A Fixnum corresponding to a single character code
An Array of one or more character codes
A String corresponding to an escape sequence
A Symbol corresponding to a known escape sequence or key
A Hash to define a new key or escape sequences

So, in the end you can do things like this:

editor.bind(:left_arrow) { editor.move_left }
editor.bind("\etest") { editor.overwrite_line("Test!!") }
editor.bind(?\C-z) { editor.undo }
editor.bind([24]) { exit }

Which, for Rubyists, it’s far sexier and more flexible than editing an .inputrc file.

How do I use it, anyway?

A code example is better than a thousand words, right? So here you are:

#!/usr/local/bin/ruby -w

require 'rubygems'
require 'rawline'

puts "*** Inline Editor Test Shell ***"
puts " * Press CTRL+X to exit"
puts " * Press CTRL+C to clear command history"
puts " * Press CTRL+D for line-related information"
puts " * Press CTRL+E to view command history"

editor = RawLine::Editor.new

editor.bind(:ctrl_c) { editor.clear_history }
editor.bind(:ctrl_d) { editor.debug_line }
editor.bind(:ctrl_e) { editor.show_history }
editor.bind(:ctrl_x) { puts; puts "Exiting..."; exit }

editor.completion_proc = lambda do |word|
    if word
        ['select', 'update', 'delete', 'debug', 'destroy'].find_all    { |e| e.match(/^#{Regexp.escape(word)}/) }
    end
end

loop do
    puts "You typed: [#{editor.read("=> ").chomp!}]"
end

This example can be found in examples/rawline_shell.rb within the RawLine source code or gem package.

Current status and availability

I currently released RawLine 0.1.0 on SourceForge, and it can be installed via:

gem install -r rawline

The RDoc documentation is available here.

Feel free to try it out. First of all try the rawline_shell.rb example, and see if it works on your machine. If it doesn’t than maybe you try re-binding some keys (use key_tester.rb to “reverse-engineer” your terminal’s input escape sequences), and let me know!

Status information and limitations:

It has been tested on Windows (XP, using the usual command prompt) and on Linux (ZenWalk, using XFCE Terminal).
It can handle lines no longer than the maximum terminal width – 2. This is to ensure that the cursor never “falls down” to the next line.
On Windows, the cursor doesn’t blink immedialy when moving left, but it moves, don’t worry.
On Linux, you should really consider installing the Termios library for a faster experience (otherwise get_character won’t parse characters correctly if you press and hold a key, and that, trust me, is a real mess!).
RawLine is very far from being a complete replacement for the ReadLine library, and it is currently in alpha stage.
Release 0.1.0 has been created after 2 weeks of sporadic coding during lunch breaks and week-ends.

For any ideas on where to go from here, comments and feedback, just reply below or send an email to my usual email address.

Book Review: Writing Efficient Ruby Code

h3rald — Mon, 21 Jan 2008 05:47:00 -0700

The second shortcut from Addison-Wesley Professional series I’m going to review is called Writing Efficient Ruby Code. A very promising title, especially considering that this book is only 50 pages long.

As usual, this shortcut can be intended as a sort of programmer-friendly detailed cheatsheet: like the other ones in this series it sports a monitor-friendly landscape layout and does not go to deep into the details unless strictly necessary to understand a particular concept.

The Author

Dr. Stefan Kaes, the author, contributed a lot to improve Ruby on Rails’ performance by refactoring portions of its core and try to “get maximum speed out of performance-critical sections of code”. This short but interesting shortcut groups together a lot of performance tweaks, tips and tricks but also some “anti-patterns” Kaes was able to identify through his career as programming teacher Ruby software consultant and key Rails contributor.

The Contents

Like with the previously-covered Mongrel shortcut, Writing Efficient Ruby Code always goes straight to the point when it comes to identify problems. The first one mentioned is of course that the Ruby Interpreter is Slow, most people are aware of that, due to their direct experience or because this argument is normally used by non-Rubyists to argue the language’s usability in commercial projects. What you may not know is why that is so, and that’s where the first part of this book comes into play.

“Ruby is a highly dynamic language: Almost all language entities are first-class citizens in that they can be created, changed, and destroyed at runtime. This comprises classes, modules, methods, constants, and class and instance variables. Only local variables are second-class citizens in Ruby: Whether a name refers to a local variable is determined at parse time.

This makes Ruby extremely flexible, but also more complex. Whever you use a name to refer to an object, Ruby has to search for the object it refers to, and this costs in terms of processing time.

As a matter of fact, one of the most recurring tips in the book to improve code performance is the following:

Method calls are expensive, use variables directly when possible.

Keep this in mind: self.something is not the same as @something. The end result is the same, but the first way costs more in terms of performance because Ruby has to look up the method name. Similarly, local variables should be introduced as a way to “cache” the result of method calls. Often you may feel “guilty” to introduce a new variable and keep calling the same method over and over: this should definitely be avoided.

Other useful tips include, for example:

Use syntax constructs (e.g. assignments) as expressinons. Use evaluation precedences.
Use interpolated strings "... #{string_variable}" (there’s also no performance difference if constant strings are used between " or ')
Use operators which update the data structure without copying it (when possible). Use update or merge to update hashes.
Iterating using for a in A is slightly faster than performing the same iteration using each, (it is the opposite in Ruby 1.9 though)
do not use return unless you have to
test in order of expected case frequency
Use parallel assignment (a, b = 5, 6) where applicable
If a module gets included in only one other class (or module), it’s preferable to open the class instead.

I deliberately chose not to elaborate any further on the tips listed above because otherwise I’ll give a big chunk of the contents of the book itself. If you know Ruby enough, you may already know why such reccommendations make sense, but if you don’t, Writing Efficient Ruby Code can be a short but very interesting read.

The Good

For each of the 30 “coding patterns” (and consequent anti-patterns) described in the book, the author does a great job explaining the reasons of doing something in a particular way, also through examples and benchmarks, where possible.

Furthermore, this shortcut can really be useful to grasp a few difference between Ruby 1.8.5, 1.8.6 and 1.9 in terms of performance: not all the patters apply to all Ruby implementations, and when that’s the case it is clearly stated.

The Bad

My only complaint about the book is probably the lack of details and more “specialized” patterns. Everything (except for a few Rails-specific tips) normally apply to Ruby as a whole, without going deeply to analyze specific libraries or third-party gems. As a result, once you get the general idea, some of the patters may seem pretty obvious or a logic consequence of others.

It is also true that this is meant to be a shortcut, not a comprehensive analysis on code optimization techniques which can be applied to specific cases: something like this would require much more than 50 pages!

The Bottom Line

Read it, re-read a few bits of it to make sure you grasp the most important concepts, and keep its table of contents in front of you as a reminder when refactoring your code!

A Firefox Lover's Guide to Opera

h3rald — Fri, 28 Dec 2007 14:19:00 -0700

Note: This article can be considered a sequel for An IE Lover’s Guide to Firefox, which described Firefox through the eyes of an Internet Explorer fan. Similarly, this article describes Opera’s features from the point of view of a user – myself – who has been using Firefox for years and is now considering another browser switch.

I am a Firefox fan. I’ve been using Firefox since it was named “Firebird” and calling it “stable” was a big overstatement. Firefox dragged me out of Internet Explorer, and that was definitely one of its biggest achievements.

Because I’m addicted to trying out new tools, however, I always kept testing new browsers I discovered here and there. K-Meleon, Flock, Sleipnir… When Safari came out for Windows I immediately installed it and used it for about 2 hours, only to realize that it wasn’t – and it still isn’t – usable at all, mainly due to sporadic crashes.

Similarly, I’ve been trying out Opera periodically, as new releases came out, but again it didn’t seem to work for me. The biggest complaint I had was its inability to render heavily-ajaxified web sites properly. However, now it seems that the Opera Development Team made a big effort to improve the browser, and I was pleased to notice that Opera 9.5b (“Kestrel”) doesn’t seem to have this sort of problems at all.

Planning the Switch

Firefox has extensions. Plenty of them actually. Some are useful, like the newish Del.icio.us one made by Yahoo, and also crappy ones you’ll never use unless you want to have a fancy button on one of your over-cluttered toolbars which enables you to interface more easily with X or Y web services you hardly ever use.

By contrast, Opera never attempted to add full-blown extension support to its venerable and yet very powerful browser. Instead, they kept building more and more features right into its core, being careful not to undermine the browser’s two proverbial qualities: speed and stability. What seemed a doomed philosophy at first turned out to be a good thingin the long run. More and more people are getting more and more worried about Firefox’s memory issues and begin to wander off to explore new things, exactly like I did.

The first step to switch from Firefox to Opera is to reduce the number of Firefox extensions to the bare minimum you need:

Colorzilla
Web Developer
MeasureIt
Search Status
Gmail Manager
Secure Login
Del.icio.us
How many extensions do you actually use? Here’s a short analysis for the ones above:

The first three are related to Web Development only, which means that I don’t need them unless I’m doing some web-development tests during which I’m always going to have more than one browser open anyway. UPDATE: there are a few Ruler widget which can be used instead of MeasureIt (thanks Ameer).
SearchStatus gives me Alexa Rank and Google Pagerank: I think I can survive without those for a while. UPDATE: if not, there’s always SEObar (thanks Ameer).
I use Gmail Manager because my girlfriend uses Gmail on the same computer. I’m switching to Opera and she’ll stick with Firefox, so no problem there…
Secure Login? It’s called Wand and it has been built-in into Opera for the last decade or so.
Del.icio.us – OK, I won’t be able to access my favorite tags as quickly, but someone already came out with a few handy buttons for a better integration with the popular social bookmarking service.

UPDATE: For a list of the features provided by Firefox extensions which are included in Opera, see Rijk’s Top 150 Popular Firefox Extensions and Opera

Because I’m addicted to betas, I immediately downloaded Opera Kestrel, i.e. Opera 9.50 beta 1. I never actually liked Opera’s default theme, so I started looking around for new skins (yes, eye-candy matters sometimes) and came across the Ximple series by serafins. In particular, 2nd thought – Jimple quickly became my favorite.

Tabs

“Opera is the Web pioneer that delivered tabbed browsing in 2000 […]”

Opera tabs feel stable and mature. Why? Probably because tabs are used more consistently to open not only web pages but also:

Downloads (“Transfers”)
RSS feeds
Notes
Emails
Bookmarks
Widget Management
Contacts
History
Page Links

I think this is a great feature and Firefox should definitely consider it: v3.0 comes with new download and bookmark managers, but they’re still dialogs. Yes, I know, there’s probably some extension which allows you to display them in the sidebar, but that’s not the point: Opera brings more consistency to the overall browsing experience by using tabs wherever they should be used.

Additionally, Opera tabs…

Can be rearranged, exactly like Firefox tabs
Can be restored, if closed accidently, by re-opening them from the Trash can
Can be locked, meaning that they can’t be closed accidently
Can be duplicated
Can be saved in groups (sessions) and re-opened later on
Can be restored if Opera crashes

Speed Dial

When you open Opera for the first time, and whenever you open a new empty tab the Speed Dial is displayed. What I originally thought it was one of the most annoying things introduced by Opera 9 turned out to be actually useful and very addictive.

The idea behind it is simple:

Show a default page with 9 slots
Allow users to drag links to those slots
Display preview of each slot (which is cached and can be updated by refreshing the page)
Allow users to quickly access pages saved in the Speed Dial via CTRL+1 .. CTRL+9 or simply by clicking them.
Simple and effective. Once you get going with it, you’ll overcome the initial feeling of imposition and you’ll use it more and more: I literally can’t live without it now!

Right-click goodies

While I was testing Opera, my girlfriend came along and asked me to look something up on IMDB. I normally had IMDB as custom search engine in Firefox, but unfortunately Opera didn’t seem to allow users to customize their search engines…

Totally wrong. Not only Opera lets you add any search engine to the search bar, it also does it with style and in the easiest way possible:

Go to your search engine or any website with a search form
Right click the search field
Click Create Search…
Specify a name and a keyword for your search engine

Done. You’ll now be able to search that particular site directly from the search bar. As you can see, I added Wikipedia, IMDB and even the Unofficial Elder Scrolls Pages in this way.

Besides creating searches, Opera lets you do a lot by right-clicking anywhere on a page:

Block Content: Right-click an empty area of any webpage and select Block Content to select which ads, scripts and images will be blocked from now on.
Validate: Validate the HTML source code of the current page.
Translate: Translate the current page into a foreign language with just two clicks.
Open With: Open the current page in another browser installed on your system.
Edit Site Preferences…: Choose to block/allow cookies and popups, identify Opera as another browser, set a different encoding, enable/disable scripts, images, flash, etc. These setting apply to the current web site only.
View source, reload page every X seconds/minutes, send by email, etc.

Widgets

Opera Widgets must not be considered as Opera’s counterpart to Firefox extensions. Instead, Opera Widgets can be used as poor man’s Vista Gadgets on Windows XP, and they do their job most remarkably.

I’m personally very fond of these ones:

They all have a common trait: they all behave as standalone programs, as they should be. The Wikipedia one, for example, can display Wikipedia entries directly inside the widget, unlike some others which just take you to Wikipedia, which is rather pointless.

Although widgets live within Opera, they can be displayed “always behind”, which means they’ll be glued to your desktop and therefore will be visible whenever Opera and other applications are minimized.

Needless to say that anyone brave enough can make widgets for Opera by following a simple Widget Specification.

Everything you can do on the Internet

The term browser applied to Opera is somehow misleading. Personally I would have called it something like “Internet Suite”, because that would be a better choice due to the features it offers and the things it can do.

Traditionally speaking, a web browser can be used to browse web pages, read feeds (sometimes) and navigate through FTP directories. Here’s what Opera can handle:

Web Pages – No need of explanations here.
FTP – FTP directories are listed very clearly, overriding server’s settings with a more user-friendly layout.
Local Files – This was a surprise for me. Typing file:// will automatically load a list of the drives currently available on your machine. Similarly, auto-completion for directory and file names is supported! I almost started using Opera as my everyday’s file manager (almost).
Feeds – An embedded feed reader can be used to subscribe to RSS/Atom feeds and view them… in a tab, of course.
E-mails – Opera is also a pretty decent email client. As of version 9.5 full IMAP support has been added, which definitely makes the difference.
IRC – Opera can be used as an client, which works pretty well. Who needs ChatZilla anymore?
News – Opera can be used to signup and retrieve news from newsgroups.
Gopher/WAIS – Although not used everyday, Opera can handle these old protocols as well.
BitTorrent Files – By default, Opera can act as a BitTorrent client as well, so you can just open .torrent files through the program and then monitor the download progress in the Transfers window, like with any other normal download. While this feature is indeed useful, it is also possible to disable it and still use your favorite BitTorrent client.

Portability and Synchronization

Let’s spend some words about portability. Sure, there are two “Portable Opera” apps out there, and they work well enough, but one thing I’d like about a web browser is the ability to synchronize my preferences, customizations, themes, passwords etc. etc. across multiple computers. Firefox is getting there, although the technology is still at a very early stage. Opera is doing something similar through Opera Link, which allows you to synchronize automatically your Bookmarks, your Personal Bar and your Speed Dial. All you need is to get a (free) Opera account, login to Opera Link and enable the synchronization feature from the File menu. From now on every time you’ll modify your Speed Dial or Bookmarks, the changes will be sent to your Opera Link page. Similarly, whenever you start using opera somewhere else, if you login to your Opera Account you should be able to synchronize your Bookmarks and Speed Dial.

Here are some thoughts on this type of technology:

It’s not totally private yet. While it’s great to be able to sync bookmarks and speed dial, the problems arise when you finish using your friend’s computer for example… what happens to the bookmarks you just sync’ed? The only way to delete them would be to have your friend to log in to his Opera account and re-sync them. Not enough privacy for my liking.
Your passwords, notes, widgets, etc. etc. cannot be synchronized yet, but that will hopefully be possible in near future.
Sync’ing bookmarks is pointless for me. Although Opera still hopes to compete with Del.icio.us & Co., that will be very hard to achieve. I stopped using in-browser bookmarks long ago.
Link seems and interesting feature considering that Opera is available on virtually any operating system and a lot of different devices (mobile phones, Nintendo DS & Wii, …).

At any rate, it is still possible to “carry around” your personal opera settings by following the instructions provided on this page which explains pretty much everything you need to know aboud Opera files and local storage.

Advanced Features

Opera looks more “polished up” than Firefox in most cases. The superb usage of tabs for nearly everything is one example, and another one is the possibility to apply skins (themes) on-the-fly, without having to restart the browser. Firefox can do this via the Personas extension, but Opera had this built-in for a long time.

To apply a new skin:

Go to the Skins Directory
Download a skin you like
Opera will download and apply the skin immediately, and it will ask you whether you want to keep it or not. If you choose not to, it won’t save it in your profile (very useful for quick previews). Neat.

Another quality opera always excelled to is accessibility. Besides using the interface in the traditional way, it is also possible to:

Use mouse gestures – I wasn’t a big fan of this until I bothered reading the excellent documentation Opera provided for them (which is significantly better than the Firefox’s equivalent). It can be quite useful at times.
Use keyboard shortcuts – Believe it or not, you can literally use Opera without a mouse.
Speak to it – Opera’s voice integration is getting better and better. Not only you can effectively tell your browser what to do, you can also use the built-in text-to-speech function (Windows only) to have it read entire pages for you. It actually works quite well and it can parse punctuation well enough to apply the right intonation. Just for fun, I had it read it an Italian page… and it actually worked as expected: it was like listening to an American reading an Italian text using US pronuntiation!

Finally, power users will be delighted of the way opera lets you hack the program settings, as you can:

Use Tools > Quick Preferences to block/unblock popups, cookies, Java applets, images, etc.
Use Tools > Advanced to access detailed information concerning cookies, cache (it lists every image/object cached!), plug-ins, Wand passwords, etc.
Use Tools > Appearence… to access and manage appearance-related settings, like skins, toolbars, buttons and panels
Use Tools > Preferences… to access general preferences (all the rest)
Type in opera:config to view and tweak Opera’s internal settings, somehow like Firefox’s about:config, but much cleaner and easier to use.
Download the Developer Console to have a simpler alternative to Firefox’s Web Developer Toolbar extension, to view DOM elements, CSS and Javascript information.

Annoyances

After using as main browser for a few weeks now, I can say that it’s great but not perfect yet. It’s very advanced, faster and more mature than any other browser, of course,but there are a few things which should be fixed or improved.

In particular:

It’s not open source – This may not matter to someone, but some people consider this an essential requirement for their browser, and that’s why Firefox is their most obvious choice. Although Opera is free, it is proprietary software after all, which means is definitely not as open as you may want it to be. Personally I’m not too bothered, as I’m starting to think that too much openness may lead to too many unuseful and bloated extensions and make the program somehow “unpredictable” and heavy.
No address bar search – Amazingly, only Firefox seems to have this feature built-in. I’m referring to the ability to type whatever in the address bar to be redirected to the site returned by a Google’s I’m feeling lucky search. It is possible to emulate this feature in Opera by creating a custom search for I’m Feeling Lucky and assign it a short keyword like “l”. In this way, for example, typing in l h3rald should lead you to this website. Not quite as immediate as in Firefox though.
No find as you type – Another big disappointment for who comes from Firefox or Safari: Opera still uses a dialog box to perform page searches.
No spell clecking – Again, both Firefox and Safari now offer text fields spell checking. Opera doesn’t yet.
No HTML mail composer – Opera’s built-in mail client can display HTML emails but doesn’t yet allow users to create them.
Auto-start widgets? – This is a feature enhancement Opera Dev Team should consider: allow users to configure certain widgets to start automatically when Opera starts.
Google Reader + Flash problems – Sometimes I experiences some scrolling problems when reading news which contain embedded flash movies on Google Reader.
Corporate Sites – Unfortunately some corporate web site do not support Opera or are not displayed correctly in Opera. Unfortunately there’s nothing much we can do about it but trying to “mask” Opera as another browser (via right-click > Edit Site Preferences…)
Default Browser Problems – Setting Opera as default browser on Windows doesn’t seem to set the file icons accordingly (or worse, it resets them to the default file icon).

ERRATA:

It is possible to have Opera to redirect you to the right after typing a few words in thr address bar by setting Google’s “I’m feeling lucky” as default search engine (thanks EJ902).
Spell Checking is supported via GNU Aspell Ospell for inline spell checking _(thanks Dava).
Find as you type can be triggered by pressing . and typing (thanks cvm).
It is possible to auto-start widgets by saving a session with all your widget open and reloading it at every startup [CTRL+F12 > General > Startup > Continue saved sessions] (thanks Tamil & Ameer).
As of the latest snapshot, setting Opera as default browser and handler for HTML files doesn’t cause any problems thanks Ayush).

Conclusion

Despite the few annoyances listed in the previous section, Opera 9.5 beta 1 truly impressed me. I was waiting for Opera to get better before switching and now I’ve not been using Firefox for a few weeks. Although Opera offers a lot of features, there’s still room for improvements, especially for what concerns integration with third party services: I would really like to see some sort of integration with del.icio.us, and that could be possible via widgets at least. Regarding the new Opera Link feature, it looks very promising and a potential competitor for Mozilla Weave even though it will be used mainly to get more and more users to register to the Opera community (I did, at least), which is indeed very active any way.

To conclude this article, which still barely scratches the surface of this very powerful application, I’d like to praise two more things about Opera:

Their website network, and in particular their truly excellent documentation knowledge base, which is very comprehensive of references, tutorials and interesting articles. I am a full time technical writer myself, and I’ve hardly ever come across better documentation.
Their extensive support and compliance to web standards, which makes Opera the most advanced browser ever made.

If you’ve not tried Opera before, or if you’ve always dismissed it because “X browser is better”, you may want to give it another shot: for me it was definitely worthwhile!

Beware of sudden upgrades!

h3rald — Thu, 20 Dec 2007 07:41:00 -0700

Yesterday I got a rather annoying early Christmas present: when visiting my site, I noticed that the raw source code of my dispatch.fcgi file (yes, I’m on shared hosting with FastCGI, for now) was displayed “as it is” instead of being interpreted.

After the initial moment of anger and stress (I immediately realized it was BlueHost’s fault, not mine), I opened two tickets and went to bed, hoping to see everything solved in the morning.

Unluckily it wasn’t the case, so I posted on BlueHost forum trying to be as polite as possible complaining because the issue wasn’t being dealt with. It turns out that for such issues you’re supposed to use the “Live Chat” feature instead of the tickets, so that’s what I did.

After a quick chat with “Christian”, it turns out that BlueHost decided to perform a server upgrade “silently” upgrading to Apache2, PHP5, MySQL4.1, etc. etc. Cool, pity that nobody told me that!

I was expecting some sort of PHP upgrade (not that I care like that), which was supposed to happen according to the last BlueHost newsletter:

“To alleviate any issues in the future with certain scripts that only run on one version of PHP we have developed the ability to run PHP4 and PHP5 on the same server simultaneously. This will be rolled out to all users in the next couple of weeks. Some servers already have this ability while most will see it in the next two weeks.”

But… hang on? Does it say anything about migrating to Apache2? I don’t think so! What’s worse, is that quite a few things changed with Apache2, in particular the way FastCGI handlers are declared:

# Apache 1.3:
AddHandler fastcgi-script .fcgi

# Apache 2:
AddHandler fcgid-script .fcgi

See? Different. This is due to the fact that mod_fcgid is used instead of mod_fastcgi on Apache 2.

The fix was easy, of course, and now my site is up and running again (and actually running faster)… but, I wonder, why the hell wasn’t I informed? Is it acceptable? It sounds like I might end up on a VPS sooner than expected, unless BlueHost doesn’t roll out some new exciting feature soon, as I think it might…

Announcement: RedBook v0.5.0 released

h3rald — Sun, 16 Dec 2007 08:07:00 -0700

This new beta release of RedBook introduces quite a few changes when it comes to configuration and setup. Here’s some highlights…

Regexp changes

It is now necessary to enter “proper” regular expressions for :select. Proper means between slashes, like the following:

/Work Day/
/mail/i

I changed this in order to support case-insensitive searches using the i switch. This makes queries much more powerful.

Variables

A new, interesting feature I decided to introduce in this release is variables. For now you define them inside your rbconfig.yml file, like this:

:var_monday_morning: "monday at 8 am"

:var_friday_evening: "friday at 8 pm"

:var_week_report: ":select :duration :from :%monday_morning :to :%friday_evening"

In this way, every time you type in :%week_report in RedBook, it will expand to: :select :duration :from monday at 8 am :to friday at 8 pm. By the way, completion is supported, so you’ll only have to type in something like :%we and hit .

It is possible to define variables as :var_<something> in the rbconfig.yml file and then used them inside RedBook as :%<something>.

New Operations

Five new operations have been added:

:blank

This will blank your current log after asking you if you really want to do so.

:restore

This operation will overwrite your current log with the last saved backup. Like with the :blank operation, you’re asked if you really want to proceed or not.

:archive

By typing :archive, the current log file will be archived to your :archives_folder: directory specified in the rbconfig.yml file (similarly, it is now possible to specify a :backups_folder: for your logs’ backup files).

:dataset

A simple operation to display the messages inthe current dataset.

:dump

This operation will dump the output of the last :select operation to a text file. Useful for saving the average, total time and duration of a set of activities.

Portable edition

Some Windows users will definitely love this. I finally found an easy way to run RedBook confined within the current directory, by using a simple start.bat batch file to set the INPUTRC and HOME variables temporarily to the path to the .inputrc file and the directory of RedBook executable. This makes RedBook 100% portable and suitable to be used on USB sticks &similar.

Get RedBook Portable

New Development Page

I decided to move the primary RedBook repository from Assembla to Google Code. Why? Well, nothing wrong with Assembla per se, I still think it’s an excellent free service to host your public and private projects, but Google Code is faster and offers only the features I need:

Public SVN repository access
Simple-to-use issue tracker
Very nicely developed downloads section, with download counts, and “normal” filenames.

So here’s the new RedBook Development Home:

http://code.google.com/p/redbook/

Additionally I also setup a RedBook Support Google Group, so if you have any question concerning the program, you know where to go!

Book Review: Mongrel Digital Shortcut

h3rald — Sat, 15 Dec 2007 03:42:00 -0700

If you ever considered about developing an deploying a Rails application in the last year or so, you must have heard of Mongrel before. If you didn’t, I’d recommend you learn more about it because up to now it proved to be one of the few essential ingredients for deploying scalable Rails applications.

Mongrel is a creation of Zed Shaw who started writing a replacement for FastCGI to use with Rails, and ended up creating a brand new, HTTP web server who turned out to be one of the best things the Rails community ever saw happening.

It was created to be simple to use and configure, nevertheless it does require some skill to set it up and tune it. Documentation is there, along with plenty of blog posts, but there’s also an interesting book from Addison Wesley Professional which is definetely worth a read.

“Mongrel: Serving, Deploying, and Extending Your Ruby Applications” – that’s the title of the book. A Digital Shortcut, 100-odd pages long, in landscape format to make it easier to read on a computer, straight to the point with no added sugar for just 15$ (PDF only). I must say Addison Wesley got it right: the book’s format is, as a matter of fact, optimized for web developers, especially those who can’t afford to read a 500-pages book covering everything about a subject just to find that one thing they don’t know about. This shortcut can be seen, essentially, as an expanded cheatsheet which will teach you the basics about Mongrel and also give you plenty of advice on how to learn more about it.

Let’s have a closer look at it.

Overview, Introduction & Getting Started

The first three ~~chapters~~ sections (there are no chapters, just sections) of the book are meant to be a gentle introduction to Mongrel and its world. The main author is Matt Pelletier, but Zed Show’s contributions are definitely one of the book’s best selling points. Zed’s thoughts are scattered here and there in many sidebars throughout the book (there’s at least one in each section): you’ll see an odd-looking face (Zed’s self-caricature) with some text next to it; when you read it, you’ll notice that they are actually Zed’s own thoughts, straight from his mind, with no editorial filter whatsoever in-between. Be warned: the text included within the Zed Sez sidebars is highly opinionated, that’s precisely what Zed feels to say about something, and he’ll just say it: just the plain, simple thoughts of an experienced programmer. As the author explains in Section 1: “[…] You may not agree with everything he says, but you probably should.”

Section 2 is a general introduction about Mongrel. It explains what it is, when and why it was made, and how it works. There’s nothing new to learn if you already used Mongrel before, probably, but it’s definitely the first thing to show to someone who’s new to Mongrel and its world, and possibly a bit skeptical about it. The last subsection “What can Mongrel do for me” is an attempt to ~~brainwash~~ persuade you to fully embrace Mongrel and its philosophy, whether you are a developer, a sysadmin or even a manager: assertions like “Mongrel is pretty damned secure.” and “Mongrel’s license is capitalist-friendly.” will definitaly make some of you (managers) happy.

Section 3 is slightly more juicy than the previous one, as it explains how to install and use Mongrel. Basically that’s what everyone who ever used it already knows, but it’s still necessary for the book’s consistency, after all. After reading this section, you’ll probably have your first Mongrel up and running and serving your little Rails application’s pages, and you’ll begin to wonder why the hell you need to keep reading this book now that everything seems to work already…

Section 4: Configurations

…aka “a truly useful Mongrel cheatsheet”. This section dives deep(er) into Mongrel’s configuration by explaining what each start parameter does in detail. The parameters are presented in tabular form in a very well-organized way. As you would expect from an high-quality cheatsheet.

Then the author will explore a few commonly used deployment scenarios, in particular:

Standalone – The simplest configuration possible, with just one Mongrel instance serving both static and dynamic pages.
mongrel_cluster – How to use “a pack of mongrels” together to handle more traffic.
Behind a static web server – The most common (and most scalable) option, used to serve static content faster using a front-end server and use Mongrel only to handle Ruby pages.

Towards the end of the section, for the developer’s delight, the author will discuss two common, useful scenarios where Mongrel can be used:

Apache 2 + mod_proxy_balancer + mongrel_cluster
Nginx + mongrel_cluster

The difference here is that detailed instructions are provided on how to setup and configure each server, including example file sources. This can be particularly useful for the Nginx example, as most of the documentation for this fantastic, lightweight Mongrel fron-end is scattered around the web (or written in Russian in a well known place).

Section 5: Production Deployment

This section introduces one of the most important part of the life cycle of a Rails application: the deployment on a production server. The author is pretty honest about the whole subject:

“You will not do this in a day. If you are expecting to code until 1 minute before your deadline and then simply point and click and have an instant server then you need to take some kind of medication because you are violently hallucinating. You will need at least a week of 8 hours days to make sure your first deployment works and to have the time to do it right.”

Sounds terribly true. Especially for larger projects demanding good performance under heavy traffic. Scared? Probably, if you never deployed a Rails application “properly” before, but at least the book comes to the rescue by providing an overview of what you need to perform a deployment and why it is such a complex and delicate process.

Not only this, but also a “Best Practices Rubric” is also provided for the developer’s own private enjoyement. It’s written as a list of questions like:

11. Do you have a shared location where you can document the deployment, such as a Wiki or CMS? 12. Do you know how to use httperf or ab and know what the statistics mean?

After these 13 questions, the author provides the key to give a meaning to your answers:

“For each question you answer with “NO”, add 10 hours to your time estimate for completion. This may seem unrealistic, since saying “NO” to everything means it’ll take 190 hours (about one month), but this estimate is actually low according to most first deployment experiences.”

If you answered “NO” too many times to these questions, you may want to read on through the next subsection which states 17 “worst practices”: an invaluable read for beginners!

But after all this section is not only about stating the obvious (…right?): a full example scenario is describedand examined throughly to give you an idea of how a deployment should be made, using three different machines:

One for Apache (as a front-end to Mongrel)
One for the Mongrel cluster and the Rails application
One for the database

Maybe something you’ll never do if you just want to run your grandma’s site on Rails, but certainly something you may want to start looking at if your grandma becomes really popular and your small server gets grounded by several thousands of visitors per day.

The last part of the section will give you a brief introduction on monitoring your applications and on which tools you should be using, although it does not discuss the subject in detail at all, it’s just meant to point you to the right direction.

Section 6: Extending Mongrel

This section digs deeper into the software code internals and describes how to teach new tricks to your Mongrel, i.e. how to extend its functionality.

Before you begin, though, don’t forget what Zed himself has to say about Mongrel’s simplicity:

“I’ve always had a different aesthetic sense when I write my software. I value simplicity and directness and try to write software that follows this approach. I jokingly call it the Shibumi School of Software Structure. All I do is apply this rule: When given two possible designs with equal end results, pick the simpler one. I then ruthlessly strip the solution down to its finest elements, but no more.”

Mongrel’s architecture is not that complex, and this section is sufficient to get you started by providing an overview of the main classes involved (HttpServer, HttpRequest, HttpResponse, HttpHandler, URIClassifier), and how they work together. Note that the book won’t describe anything about the APIs of these classes. but after all, the project’s RDoc documentation should cover all the details you need.

The rest of the section focuses on how to extend Mongrel, by:

Writing custom handlers in Ruby
Creating custom filters to perform security checks, clean up requests and preliminary file processing
Creating plugins and distributing them as rubygems

Two working examples are also provided:

An example handler to deflate content (if the browser supports deflate)
An example “duck” plugin, to make Mongrel quack like a duck when it’s started (not the most useful thing in the world, but serves the purpose)

Debugging, Performance & Security

The last three sections deals with other important aspects concerning the deployment of your application, how to debug, how to improve performance and how to secure your application.

Section 7 introduces two debugging modes:

Dash-Bee logging (-B)
USR1 logging (lighter)

And also gives you an idea on what to look for when debugging an application. Nothing too detailed, granted, but enough to make sure you are pointed in the right direction.

Again, Zed’s wisdom and wit are remarkable:

“These people’s problem is they suffer from Potpourri Turd Syndrome—a belief that their you-know-what don’t stink and smells like fine dew on freshly cut grass. Whenever there’s a bug, they go running like kids in a candy store to other people’s code trying to find fault and just assume that it’s nothing they wrote. […] When you run into a problem with your application, always assume it’s your fault first. Mongrel’s not perfect, but its code is minuscule compared to the size of Rails and most likely even your own appli-cation code. Mongrel also powers many large and medium deployments without any problems. If there’s an error, the evidence already says it’s in your code, so bite the bullet and start investigating it as if it’s your problem.”

Similarly, Section 8 is a short but useful overview on performance tips and tricks and deployment tuning. The most useful thing is probably the checklist of the “tuning process”, which illustrates the simple steps to take to tune your application.

Finally, Section 9 addresses some common security concerns and clarifies how Mongrel deals with them. The answer is normally “Mongrel strictly does this” or “Mongrel doesn’t support this feature”. After all, you should have understood by now that Mongrel is an example of simplicity and that it deliberately does not aim to offer all the feature you’d expect by a server like Apache:

“As you probably see, Mongrel say, “No” in many places where most Web servers say, “Yes, OK.” Sometimes this is because no one using Mongrel has needed it yet, sometimes it’s because there’s a better, simpler way to accomplish the same goal. Mongrel is a different kind of Web server, and frequently you can solve your problem with a different solution.”

Conclusion

If Mongrel is opinionated software, this is definitely an opinionated book which fully embraces the project’s philosopy of simplicity above everything else. It’s an interesting read and it won’t bore you to death by deliberately skipping long and potentially tedious subjects and adding interesting insights instead (like the Zed Sez sidebars). Perhaps it is a bit too direct towards certain people, who may get even get offended (as planned) by some of the author’s assertions.

Despite being a 100-pages book, this shortcut covers pretty much everything you need to know about Mongrel. It will not teach you everything about deployment, security, performance tweaks and debugging though: as the authors often state throughout the book, a lot of (big) books are available on those subject, and it wouldn’t make sense to even attempt to discuss them in this shortcut.

Similarly, you won’t find complex examples either, but that’s acceptable because simple examples are often the only thing you need to grasp the basics of a concept or feature, and then use them as a “scaffold” for your own code.

Globally, the book is well balanced and optimized for its size: lightweight introductory sections at first, then the “real juice” in the middle, and a few overview sections on advanced topics towards the end. You can read it easily in a few hours, perhaps less, and whenever you need to look something up in a hurry it will be fairly easy to locate.

A good read, and a must for everyone who wants to learn more about Mongrel or Rails deployment.

Review Services

h3rald — Fri, 14 Dec 2007 12:24:00 -0700

When it comes to software, I definitely like to try out new things. My collegues takes the piss out of me because every ~~week~~ day I come up with “some new tool they have to start using” and so on. As a matter of fact, I like reviewing software as well. I enjoy writing and analyzing new things, evaluating all the new possibilities they may offer, and I also tend to have a rather critical eye for what doesn’t feel right. I’ll use a tool for months but still try out new ones which claim to do the same thing — but better — as they come out. Unfortunately — or fortunately, depends how you look at it — when it comes to software, there are very few silver bullets, and things keep changing: that’s the way it is and the way it will be.

I must try to write up a page (and ideally update it regularly, that’s the hard part) listing all the tools I use, at some point… but at any rate, if you coded some new app you think kicks ass or you found a hidden jewel in the labyrinth of freeware, just let me know: I’ll definitely try it out, and if it’s worth a post I’ll blog about it.

The same applies to books, actually, as I like reading, especially those which are related to Ruby or programming, nowadays.

The cost of such reviews and articles? Depends! Certainly I wouldn’t mind donations or some compensation of some form, especially from publishers or software companies. It may be money, books, software or even nothing: it really depends on what I have to review. Please be aware that I am not doing this full time, and I already have a job and a fiancée to look after, but I’ll do my best to publish as much as I can on my site or even elsewhere elsewhere [Note: on e-zines, magazines & similar, not on your brother’s friend’s mother-in-law’s crappy blog!].

For any inquiries, contact me (h3rald [—at—] h3rald.com).