The Ruby Compendium has been updated, and it now lists the most up-to-date versions of various Ruby implementatios, even more web sites, books, podcasts, and Rubyists. In addition to the PDF version, the book can now be read online here on H3RALD.com.

Overall, this is a relatively minor update; however, I felt it was a good time to release it to keep the book up-to-date.

The Ruby Compendium is available free of charge, under the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported License, and you can help improving it! It was written using my very own Glyph Framework, and the entire source code is available on GitHub, for anyone to fork.

Obie did it, again. With the second edition of his former masterpiece, The Rails Way, he managed to outdo himself delivering a new, even more useful, Rails Bible. Wether you’re a Ruby on Rails professional like him or just an enthusiast, this book is pretty much everything you need to learn how to master the third release of DHH’s Ruby web framework.

The Rails 3 Way is no ordinary second edition. If you already own The Rails Way, you’ll be pleasantly surprised that this is a different, more polished book. While something had to remain the same, there’s a lot of new content in its 708 pages, and even the old content has been rewritten or at least revised.

It doesn’t matter whether you already know Rails 2.x or you’re jumping straight into the Rails 3 world, if you use Rails, you can’t miss this book.

I started the review of the first edition with a quote from my fiancée (now wife) on how pointless programming books are, especially those dealing with newish technologies: they tend to go out of date fairly quickly. While this still holds true, there’s not much you can do about it, except maybe purchasing a digital edition of the book instead. However, if you want to keep a good Rails reference book by your side, this has to be the one.

What's New

If you put The Rails 3 Way and the original The Rails Way one next to the other, you can see that the new book is considerably shorter: about 200 pages less. This doesn’t mean it contains less information, quite the opposite: the new book contains a lot more stuff with less fluff. Obie managed to reduce digressions to a bare minimum and focus on providing more informative content to the readers using less text. Think of it as a fat-free book.

While no What’s new in Rails 3 section is included in the book, Obie points out the new stuff when needed (but not always). An example is chapter 12, Ajax on Rails, in which changes introduced by Rails 3 clearly stand out, especially the section on Unobtrusive JavaScript (UJS).

Although the book is divided into chapters, it can also be divided into parts (each dealing with a specific theme) simply by looking at the front edge. According to this theme-based partitioning, Active Record makes up for nearly a quarter of the book (173 pages), followed by Active Support API appendix and the All About Helpers chapter.

Another nice addition that can really make the difference when you’re in a hurry is the Method Index, which is separate from the main Index. It seems to account for all the methods in all (or at least the most important) classes in Rails. I didn’t check method by method, but it is pretty comprehensive nonetheless, based on some quick spot checking.

Contents

The first thing you notice once you read the first few pages, is that this book is even more opinioned than its predecessor.

Even though Rails 3 is less opinionated than early versions, in that it allows for easy reconfiguration of Rails assumptions, this book is more opinionated than ever.

– Obie Fernandez, Introduction to The Rails Way

In other words, you won’t find an ERb view in the whole book (Haml rulez!) and if you don’t like RSpec… well, you’d better skip Chapter 18 altogether.

The other big difference with traditional Ruby and Rails books is the amount of reference to third-party code, mainly rubygems. Rails comes with no authentication functionality? So what: Authlogic and Devise are great for the job, go check them out! Do you need to test your Active Mailer emails? email-spec is all you need.

I was actually surprised to find so much content not strictly related to Rails in this book: the first chapter starts off with Bundler (now a Rails dependency, however), Chapter 2 (Routes) mentions Rack, and so does Chapter 4 (Controllers). If you want a nice and to-the-point practical introduction to RSpec, the first part of Chapter 18 covers that.

Then there’s reference material. Plenty of it, a good 40% I daresay. The good thing is that (unlike the first edition) it won’t bore you to death: take Chapter 5 (Working with Active Record) for example, you’ll fly through find-related methods so swiftly you’ll regret when it’s over. Active Support? I didn’t read every line of Appendix B, but when I want to know something about inflection methods I will know exactly where to find them, and what to expect: the method signature, a few lines of text, and a short example at most.

My only regret? Cheat sheets. Or better, the lack of them. More tables, please! Granted, the web is full of Rails cheat sheets, but a few of them at the end of the book or even in a separate foldable add-on like in the Pragmatic Programmer can’t hurt.

Finally, some words about the code examples. The code/text ratio is almost 1:1, but Obie’s choice of not turning this book into a huge tutorial by implementing a single example application was absolutely right: The code snippets used in throughout the book are concise and relevant to the text around them and won’t distrupt your reading. If you want to play with them, they’re even on GitHub for you to clone and fork.

Organization and Writing Style

The Rails 3 Way is a book for Rails professionals. If you don’t know Ruby or if you never heard of Ruby on Rails, this book is not for you. It won’t teach you what MVC is, it won’t waste time on explaining convention over configuration, it won’t even describe the structure of a Rails app! If you’re newcomer to Rails… well, that’s what The Rails Tutorial is for.

To be honest, I’m with Obie on this. If this book had been beginner-friendly, it would have been even longer than the previous edition, and probably more boring. Instead, by assuming that the reader has been already initiated to the world of Ruby and Rails, the author can dive into the framework straight away. Moreover, chapters are not ordered by difficulty: they don’t need to be, they need to be ordered in a way that makes sense for a Rails developer.

Once again, this book includes personal sidebars used to voice the opinion of one of the co-authors or Rails gurus: there are plenty of “Yehuda says”, “Xavier says”, “Durran says”, and so on. Nothing new there, it’s just a nice way to provide the reader with authoritative opinions on some matters.

As I progressed through the book, I started noticing how Obie anticipated my questions and doubts: I found this to be a remarkable feature of this book, and an excellent way to make the readers feel they are on the same page with the author. If something should not be done because it may cause you problems, the author won’t hold back. See page 214, “Extra Columns on has_and_belongs_to_many Join Tables”, for example: it’s a cool feature, but it can cause all sort of annoyances, and the bottom line is: use has_many :through instead, if you need extra columns on join tables.

When I was offered to review this book, I was a bit skeptical: a book on management? I normally read and review books on programming and software development methodologies. However, I work as a Documentation Technical Leader, and while I don’t technically manage a whole team yet (damn economic crisis!), someday I may end up doing just that, so I gave Reflections on Management a try.

It’s short, after all, I’ll probably read it in a couple of weeks and move on — I thought. Well, beware of short books: I thought exactly the same thing when I picked up The Elements of Style, and it still follows me around everywhere, so that I can re-read bits of it whenever I need to.

This short but dense masterpiece by Watts S. Humphrey and William R. Thomas is one those books you always end up carrying around in your pocket (or stored in your favorite ebook reader). It’s a short but very dense collection of tips and tricks to succeed as a leader and a manager — of anything: Your Software Projects, Your Teams, Your Boss, and Yourself, as the book subtitle says. It doesn’t “just” help forging great managers and leaders, it also explains, with practical examples and no-nonsense explanations, how to deal with those annoying people in suits who constantly keep asking you for impossible things…

Learning a programming language can be hard and time consuming. You normally have to go through a bunch of tutorials, ask questions, read books… Ruby is no exception: there are plenty of resources out there about it, but it is often hard to find what you’re looking for. So, as a weekend project, I decided to create a Ruby Compendium, a short book about the Ruby Ecosystem.

I guarantee that you will not be able to code in Ruby after reading this book. Yes, you read it right, this book is not about coding, it’s about learning what’s out there for you that can help you to learn how to program in Ruby. Information on Ruby implementations, versions, web sites, books, podcasts, a handful of Ruby gems to solve common problems… it’s all in there.

The Ruby Compendium is available free of charge, under the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported License, and you can help improving it! It was written using my very own Glyph Framework, and the entire source code is available on GitHub, for anyone to fork.

If you already heard the names Mary and Tom Poppendieck, chances are that you already know what Lean Software Development is. If you don’t, start from this Wikipedia page. Mary and Tom coined this term with their first book on the subject Lean Software Development: An Agile Toolkit, that was followed three years later by Implementing Lean Software Development: From Concept to Cash, and finally by this book: Leading Lean Software Development: Results Are not the Point.

Unlike the two other books, this one is focused about making lean software practices succeed. In some way, it can be compared to Succeeding with Agile, but while Mike Cohn’s book focuses entirely on Scrum, this book has a much broader scope. Moreover, the book contains a lot of digressions and stories —even not directly related to software development— aimed at understanding particular aspects of Lean Software Development and the Lean movement in general.

The focus is, as the title suggests, on leadership: how can you be a good leader in these difficult, ever-changing times? How can you be agile without loosing your team? How can you improve the existing processes so that they can help you achieve your goals? If you ever asked yourself these questions, this is the right book for you…

When this book came out, it was immediately followed by a lot of buzz. Positive reviews started popping up almost instantly, a lot of people blogged about it, it was surrended by a lot of… what’s that word again? Oh yes, hype. The title pissed me off really: who on Earth wants to title his book Making it Big in Software? Steve Jobs? Bill Gates?

No, just a guy named Sam Lightstone. When I was offered a review copy, I was a bit reluctant to even bother: I thought it was one of those overly-hyped titles that claim to make you famous and successful, but all they do stating the obvious: work hard, be innovative, use your money wisely, etc. Well, this book is not one of them.

When I got my copy, I immediately read the author’s bio on the second-last page of the book: Sam Lightstone runs a site called Making it Big Careers (again, I got instantly worried by this), but also happens to be one of the brightest minds in IBM, a IBM Master Inventor, author and co-author of 30+ patents.

The 17 exclusive interviews with software gurus, visionaries, minor and major deities of the IT world are definitely worth the 24.99$ this book costs on their own. This was one of the major selling points of the book itself (as the merry-looking pictures of Marissa Mayer, James Gosling, Steve Wozniak and John Schwarz on the cover suggest), but far from being the only one. The interviews are strategically placed throughout the book, as supporting material for the author’s advice: if you don’t believe him, you will believe those who made it. Anyhow, let’s say something about the book itself, shall we?

Making it Big with Software is divided into three parts:

• Part I: Fundamentals — all you need to know to get hired. Finish school, learn new things, and get a job in the Software industry.
• Part II: Leadership — tips on what to do to start climbing the corporate ladder, from junior to senior manager.
• Part III: Greatness — go beyond a successful career and become a luminary in IT, an example for future generations (and earn the big bucks).

Back when I read Programming Ruby for the first time, I distinctly remember a short reference to dRb, the Distributed Ruby library included in the Standard Library.

“Cool!” — I thought

…and that was pretty much it. The documentation for DRb was pretty much nonexistent (at the time), I didn’t need it, so I pretty much forgot about it altogether until this book came out.

Distributed Programming with Ruby fills a very particular niche of the Ruby programming world: distributed programming. Moreover, this book is somehow justified by the scarce documentation on the subject:

Although these libraries [DRb and rinda] have been included with Ruby for many years now, they have received little or no attention (or documentation). This has led to a lot of FUD (fear, uncertainty, and doubt) about what these libraries can and cannot do, and when they are appropriate to use (if at all).

— Mark Bates, Distributed Programming with Ruby

But there’s more. This book gives the reader a complete overview of what’s out there, in the Ruby world, to support distributed programming. This includes quite a few gems and libraries besides the ones provided in the standard library.

Overview

The book is organized into four parts, each dealing with a particular set of Ruby libraries related to distributed programming.

The author, Mark Bates, does a good job maintaining a sort of continuity in the examples throughout the book: you’ll get accustomed to a Logger class of some kind being punctually re-implemented more or less once per chapter, using a different library.

Additionally, the libraries described in the book are ordered by “reverse preference” in each part of the book, so normally the libraries described later on in a part fix some of the shortcomings of the preceding ones.

Part I: Standard Library

This part is the most important of all: it gives you the very basics about Distributed Programming and it describes the “building blocks” (DRb and Rinda) used in nearly all the other libraries described in the book. If you want you can skip some chapters in the other parts of the book, but make sure this part is crystal clear in your head before proceeding any further.

Part II: Third-Party Frameworks and Libraries

If you read part I, you’re probably a bit disappointed by DRb and Rinda and the amount of code you have to write to make simple things work in a distributed environment. The good news is that there are some Ruby gems out there that can make life simpler:

• RingyDingy
• Starfish
• Distribunaut
• Politics

Part III: Distributed Message Queues

In this part, the author introduces more in detail the concept of distribute message queues, and also the technologies and protocols available not only in the Ruby world but elsewhere. It focuses on two libraries:

• Starling, originally used by Twitter.
• AMQP, an implementation of the AMQP protocol in Ruby, that can be used in conjunction with RabbitMQ, an Erlang-based messaging system.

Part IV: Distributed Programming with Ruby on Rails

The book ends somewhat abruptly with this last part that deals with distributed programming in the Rails world. It feels a bit like a last-minute addendum that I would have left for an appendix, nevertheless it briefly introduces BackgrounDRb and Delayed Job.

Refactoring: Ruby Edition is actually a rewrite of the more revolutionary — at the time — Refactoring: Improving the Design of Existing Code, written by Martin Fowler & others to teach Java programmers about refactoring. Jay Fields and others decided to port this historical title to Ruby to fill a gap: there was no authoritative book about refactoring for this language, so what’s better than translating the Bible on the subject?

If you already own the Java book you shouldn’t buy this one. This is not my personal opinion (I never read the original), it’s actually written in the Preface of the book itself. I really like honest authors, and luckily this seems to have become a trend, lately: programmers don’t like reading bullshit after all. By the authors’ own admission, this book contains roughly the same material and the same examples of the original Java book, plus some slightly more Ruby-specific content.

Getting started

The first chapter, Refactoring, a first example, is not a first chapter. Well, it is in a literal sense, but it doesn’t look like one: no theory, no padding, you’re immediately thrown in the middle of the battle, dealing with a small program in desperate need of refactoring. It literally contains quite a lot of code: the same program is rewritten over and over with changes in bold to teach you what refactoring means. The most intimidating thing is reading names of refactoring techniques capitalized and used in a natural way, like if the reader was supposed to know them already. In all fairness though, they are self-explanatory most of the time, e.g. Replace Array with Object.

What makes this chapter even more unusual is the clever usage of white space: before and after code snippets are shown on separate page, which makes it much more immediate to see the changes in code (but it won’t work very well if you bought the ebook instead of the hardback).

By contrast, the second chapter Principles in Refactoring is all about theory: it should have been the first chapter, but it’s better this way. Here you’ll learn the basics: a bit of history, when to refactor and when not to, and so on. I bet it was taken almost verbatim from the Java book; see for example: “[…] If your building APIs for outsid consumption, as Sun does […]”.

Chapter 3, Bad Smells in Code, is probably the most important and useful chapter in the entire book. It’s somethig you should read over and over until you can spot a code smell right after coding.

“You should use this chapter and the table on the inside back cover as a way to give you inspiration whn you’re not sure what refactorings to do.”

Precisely what you have to do. Except that there is no table on the inside back cover, so I guess this one will have to do. Pity.

Chapter 4, Building Tests, is the usual, compulsory chapter about unit testing, i.e. the usual intro to Test::Unit. As I said, it’s essential for the book to make sense, but you can safely skip it if you know how to test already.

Finally, chapter 5 (Toward a Catalog of Refactoring) is a 2.5 page intro to the bulk of the book, nothing more than glue to ease the transition. I would have removed it completely, but that’s because I’m a merciless technical writer I guess.

Diving in

From chapter 6 onwards, specific refactoring techniques are described. Each chapter starts with a brief overview of the following sections (which should have been a list, but I’m just being pedantic now), so you know what to expect.

Each technique described has a very meaningful and immediate name that reflects its purpose, like Extract Method or Split Temporary Variable. A code example introduces the code smell and the proposed refactoring, followed by a Mechanics section with a list of actions to perform and an explanatory Motivation section.

Tipically, each refactoring has its own, self-contained code snippets. Depending on the complexity of the refactoring technique examined, the authors may spend half to five or six pages just to show all code iterations to get to the result. When things get too complicated, UML diagrams are used to make the technique easier to understand, but only when it’s strictly necessary.

Even if the original techniques were though for Java, the authors (in particlar Jay Fields, I guess) do a great job making sure that the Ruby code doensn’t look like Java code in disguise: the result of the refactoring always follows Ruby’s philosophy and idioms. I particularly liked the following:

• Replace Dynamic Receptor with Dynamic Method Definition (Chapter 6), a nice example of metaprogramming.
• Decompose Conditional/Recompose Conditional (Chapter 9), very useful and very common
• Replace Nested Conditional with Guard Clause (Chapter 9), another way to deal with a very common problem with conditionals
• Extract Module (Chapter 11), very Rubyesque way to tidy up busy classes

This doesn’t mean that every refactoring described in the book is a programmer’s epiphany, some of the techniques are indeed pretty obvious and some portion of code in need of refactoring indeed smell very, very bad! E.g.:

• Inline Class (Chapter 7): Who on Earth would ever create a class containing a single method returning a telephone number?
• Replace Magic Number with Symbolic Constant (Chapter 8): Why would you use integers for constants? Didn’t Matz give us Symbols to avoid just that?

The big picture

By the end of chapter 11 you should be familiar with nearly all the best possible way to get rid of code smells. That’s all good, but what happens if the entire program stinks? Chapter 12 (Big Refactorings) claims to have some answers to some common pitfalls. The techniques defined in this chapter are by no means sufficient to solve all problems caused by bad design, but they can help especially to rewrite legacy code, or programs developed by Ruby newbies:

• Tease Apart Inheritance
• Convert procedural design to objects
• Separate domain from presentation
• Extract hierarchy

They are basically all about reducing bloat and unnecessary complexity, and — to me, that is — they all sounded pretty obvious. Of course I’m going to separate domain from presentation! Didn’t Rails teach us anything at all? I must say I was somehow disappointed by this chapter. I was going to bet there was something slightly more advanced, maybe something about replacing traditional object instantiation with an internal DSL? Nope, sorry.

Chapter 13, on the other hand, is an excellent conclusion to the book: it really helps the reader to understand when to refactor and how to do so, depending on the situation.

Conclusion

This and Design Patterns in Ruby are now my favorite Ruby books. I believe they complete each other: Russ Olsen’s book is more about designing your programs properly from the start, while Refactoring: Ruby Edition can help to make things better at a lower level.
Ruby developers don’t need to refactor as much as Java developers, mainly because of Ruby itself, nevertheless, this is an excellent read for anyone who wants to get serious about programming in Ruby, and is determined to do so by following the Ruby Way.

I’ll definitely keep this book near me when I’m coding: I do believe it is much more helpful when you start using it as a reference, when you already read about all the refactoring techniques and want to put them in practice. Also, I’ll probably re-read chapter 3 on a regular basis, to get accustomed to recognize code smells, and deal with them accordingly.

Apparently it only takes 300 pages to describe a web framework nowadays! I couldn’t help but feeling a bit skeptical at first. Even in the foreword, Obie Fernandez presents the book – and the whole Merb framework – with some initial skepticism: isn’t Ruby on Rails enough? Why do we need yet another Ruby web framework? And above all, seeing that Merb is going to eventually be merged into Rails 3, why on Earth do we need a book about Merb, now?

Needless to say, Foy Savas proved that both Merb and its book cannot be dismissed just like that.

Getting started

The book starts with the original Merb Pastie, a single page of Ruby code able to sort out HTTP requests, dispatch them to the appropriate controllers and render a web page. This piece of code is enough to convey what Merb is: a new breed of web framework, almost as simple as it can get but very poweful and flexible at the same time.

As you start diving in through the first chapter, you realize you’re reading about a Hacker’s Web Framework. That’s precisely what Merb is: a very versatile tool to get the job done, in the simplest way possible. Similarly, The Merb Way immediately feels like a Hacker’s Handbook rather than an ordinary guide on how to develop web applications. You won’t learn what MVC is by reading this book, and don’t expect to be taught what a mixin is; you are reading a book about a Ruby web framework that was born after the Rails Revolution, so it is safe (for the author) to assume that:

• You know the Ruby programming language
• You know what Ruby on Rails is and you tried it out, at the very least

The first few chapters are about the core functionalities provided by an an MVC framework: after a comprehensive first chapter about Merb’s fundamentals (from the layout of a Merb application to an overview of Merb internals) you are quite abruptly “introduced” to routing, controllers, views and models. These chapters do not aim to provide a comprehensive description of each component, they simply tell you: here’s how Merb does this.

Out of the first five chapters, favorite is definitely the one about Models. Although Merb is ORM-agnostic, DataMapper is the de facto standard for Merb applications, and it fully embrace the framework’s design and extreme flexibility without being in the way of your code.
Foy does an excellent job in this chapter by strategically describing DataMapper’s code from the top to the very bottom, from the highest abstractions to raw SQL code, using a plethora of snippets taken from the actual Merb code.

It’s about how Merb works, not how to work with Merb

After reading the Models chapter I decided to go back and re-examine the previous chapters. I didn’t notice until then, but the author sneakily smuggled a consistent amount of Merb source code into this book. This is rather unusual for books about web frameworks: they normally tell you how to use the framework, not how it was built! While this can be disappointing for people used to read Rails books, it came as a very pleasant surprise to me.

About 40-50% of this entire book (and I’m not exaggerating) is Ruby source code. In a good way, it feels like a collection of strategically-positioned code snippets glued together with explanations of the most tricky bits and digressions on how the framework was designed. In other words, it probably contains just enough text to make sure that the average reader understands the code, but remember that the average reader of this book must know Ruby failry well.

There is no pointless prose in this book, no explanations of obvious methods, no fancy words, no useless boasting on how cool the framework is: just an objective description of how Merb works and of the key design decisions behind it. If I may, the only thing that doesn’t feel quite right with this book is its title: Merb Internals would have been a better choice. Once you realize this, the book suddenly makes sense, and can even make you a better Ruby programmer.

The Merb Way does an excellent job in describing how to design a web framework, or any real-world Ruby application for that matter. It teaches you that modularity is the key to flexibility by showing how the Merb stack is organized. Sure, it doesn’t teach you how to create a blog in five minutes, but perhaps a thorough explanation of how anthentication is implemented (Chapter 9) will actually be useful in two months time, when you’ll have to create your own Merb plugin from scratch.

Some constructive criticism

The idea behind this book is clever but a bit dangerous. I flipped through the pages in front of my wife and asked her what was wrong with it. “There’s too much code!” she said, without hesitation. Precisely.

It is damn good Ruby code, but sometimes you wish there was more text describing how to use it in practice. Or maybe some code examples on using the framework on a real-world application. Not a chance. Of all that holy code, there’s not much featuring something other than Merb itself. Basically the exact opposite of all the other books about Rails or other web frameworks!

Even accepting the fact that you are not reading a book about developing web applications, there are two more things which could be improved:

• Merb’s design is very intriguing, and you grasp the essentials by reading this book, but a few diagrams here and there and more in-depth digressions on the subjects would have been nice.
• Besides DataMapper, what I really wanted to read about were Slices and Parts – unfortunately the chapters about them are far too short and shallow. The reasoning behind this is that their future may be uncertain due to the Rails 3 merge. Pity.

Conclusion

The death of Merb has been greatly exaggerated. Too bad I gave up web frameworks altogether for my site, because after reading this book I would have gone for Merb today rather than waiting to see the wonders of Rails 3 tomorrow. Even a book with this title could have been written in a very different way, I would still recommend it if you want to become a better Ruby programmer by learning from the best: Merb code really stands out, even compared to Rails, and Foy Savas does a great job presenting and describing it.

"Programming books are pointless: you buy them, you read them and you chuck them because they're already out-of-date!"

This is a quote from my fiancée, who always pointed out the ephemeral nature of programming books and therefore highly discouraged me from buying any more. The sad thing is that this is partly true: if you buy a new programming book it will eventually become outdated pretty quickly, especially if it's about newish technologies like Ruby on Rails.

The Rails Way is no exception: Rails 2.2 has been out for a while and introduced a few new features – most notably Internationalization support – which are not mentioned neither in this book nor in others.

That being said, The Rails Way by Obie Fernandez is still the best and most comprehensive book on Rails v2 currently on the market. It's the book you simply cannot afford to ignore, if you are using (or are planning to use) this popular Ruby web framework.

Contents

Before proceeding any further, I'd like to point out that is probably one of the longest programming books I've ever come across. With its 910 pages, The Rails Way definitely cannot fit in your pocket and you cannot take it around with you easily. It's a book made to sit on your desk constantly and remain there, ready to be accessed at the right time, when needed. Unlike with other books I reviewed, this time I won't even attempt to go through every chapter and every section: it would not be meaningful for the review and it will probably bore you to death. For completeness' sake, however, here's a very trimmed-down table of contents listing only the first level headings:

• Introduction
• Chapter 1 - Rails Environment and Configurations
• Chapter 2 - Working with Controllers
• Chapter 3 - Routing
• Chapter 4 - REST, Resources, and Rails
• Chapter 5 - Reflecting on Rails Routing
• Chapter 6 - Working with ActiveRecord
• Chapter 7 - ActiveRecord Associations
• Chapter 8 - ActiveRecord Validations
• Chapter 9 - Advanced ActiveRecord
• Chapter 10 - ActionView
• Chapter 11 - All About Helpers
• Chapter 12 - Ajax on Rails
• Chapter 13 - Session Management
• Chapter 14 - Login and Authentication
• Chapter 15 - XML and ActiveResource
• Chapter 16 - ActionMailer
• Chapter 17 - Testing
• Chapter 18 - RSpec on Rails
• Chapter 19 - Extending Rails with Plugins
• Chapter 20 - Rails Production Configurations
• Chapter 21 - Capistrano
• Chapter 22 - Background Processing
• Appendix A ActiveSupport API Reference
• Appendix B Rails Essentials
• Afterword What Is the Rails Way (To You)?

If you already know Rails, these titles will be self-explanatory to you. If not, you'll just have to trust my words when I say that this book covers every possible aspect of the framework, and 99% of the notions you need to know to start developing almost any Rails-powered web application.

What really pleased me were chapters 17 through 22, i.e. something not strictly related to Rails Core. Normally, books about Ruby and Ruby on Rails don't deal with anything even a little bit outside their scope: as a result, topics such as Rubygems, RSpec and Capistrano are often not mentioned at all, or if they are, they are relegated to one or two pages at maximum, leaving the reader to look on the Internet for more information. By contrast, The Rails Way covers these ancillary but still very important topics very in-depth. Sure, you won't know the inside-out of RSpec after reading this book (although a whole chapter is devoted to it), but you will certanly know your way around it enough to use it properly.

What's missing in this book then? Maybe a Chapter 0 to guide the absolute beginner through the very basics of Rails and Ruby. Probably this goes beyond the scope of the book though, as the author clearly states that the book _"[...] is not a tutorial or basic introduction to Ruby or Rails. It is meant as a day-to-day reference for the full-time Rails developer. "_. Still, 100 pages about the Magic of Scaffolding & other tricks to astonish the children wouldn't have damaged the book, especially considering that Chapter 1 starts at page 60 after a lot of pages intentionally left blank, Introduction, Foreward, Acknowledgements and similar padding material.

Organization and writing style

"Before going on, I should mention that part of what makes Rails exceptional is that it is opinionated software, written by opinionated programmers. Likewise, this is an opinionated book, written by opinionated writers."

This sentence in the Introduction sounded very familiar. Almost an echo of Zed Shaw's own words in the Mongrel Digital Shortcut. After all this book is part of the Addison-Wesley Professional Ruby Series, of which Obie is the Series Editor. Like the other books in the series, this book contains all the stylistic conventions and distinctive features which make them very enjoyable to read:

• Informal, almost personal style – reading this book is almost like hearing Obie telling you what he thinks about Rails, and sharing with you his own tips and tricks.
• Honest, even humble at times – This book doesn't glorify Rails or Ruby: on the contrary, pitfalls are acknowledged and dealt with. Rails lacks an inbuilt authentication system? No problem, a whole chapter is devoted to the act_as_authenticated plugin. You almost feel it's part of the core itself.
• "[Person] says" sidebars – The book's co-authors occasionally have their saying in special sidebars, all throughout the book. A way to evaluate different opinions and take a break from the book's main flow.
• Code snippets – Not too many, not too few, just about the right amount. Granted, you won't find any sample application in this book, but the snippets provided are more than enough to get to the point.

Although this book is meant to be a reference, this doesn't mean it only contains reference material, it means that if you don't know about a particular feature of Rails or its satellites (Capistrano, RSpec, testing in general, etc.) you can open the book at any chapter and read through an in-depth discussion which will, most likely, answer all your questions.

Even if what you're looking for is not strictly related to Rails but can just be used with it, you'll find it in the book. Some examples include a 23-page-long exhaustive dissertation on Prototype, a whole Chapter on RSpec, another on Capistrano and even information on XML parsing through REXML.

What you won't find in the book, unfortunately, is how to get something which was not meant to be seamless integrated with Rails to work, like JQuery, for example. But again, this is understandable, as such topics would have made the book three times longer, at least.

Some constructive criticism

As a technical writer, I was somehow unhappy of the way reference material was presented in the book, i.e. more or less as ordinary chunks of text:

execute(sql_statement)
Executes the SQL statement provided in the context of this connection. This method is abstract in the DatabaseStatements module and is overridden by specific database adapter implementations. As such, the return type is a result set object cor- responding to the adapter in use.

insert(sql_statement)
Executes an SQL INSERT statement and returns the last autogenerated ID from the affected table.

You'll find plenty of pages like this in the book. Although all essential the information about each specific method is there, it is not organized properly. When I'm coding and I want to look up something quick, chances are that I can just hop over to APIdock or other similar services and query Rails documentation in a much more efficient way.
On the other end, if reference material was added for completeness' sake, it would have been much better included at the end of the book, more succinctly, through some carefully constructed reference tables. If the aim was instead to help the reader memorize all the method he must know to work productively with Rails everyday, the author should have included some diagrams or any other type of visual aid.

Similarly, the Stack Checklist included in Chapter 20 is not actually a list at all, but rather a sequence of titled paragraphs which is definitely a good read the first time, but it won't be as useful when you need to just refresh your memory.

I admit, I noticed these things because part of my daily job as Technical Writer consists in making sure that reference material is well presented in the most minimalist, direct and useful way to the reader. Maybe a year ago I wouldn't have thought anything of it, but now I felt compelled to point this out hoping the next edition of the book will deal also with this aspect of the book.

Since the book came out in 2007, the organization and presentation of Rails Documentation has been significantly improved by third-party services: I hope the authors and editors will try to make sure, next time, that the reference material is more usable by the readers.

Conclusion

Overall, the book is a good read. It's even possible to read it sequentially (even if the author discourages this practice) and still get the most out of it – a rare trait in programming books nowadays.
No other book will go so in-depth about Rails or about everything you need to know to get your site up and running in areal production environment. That's the reason why The Rails Wayis the perfect companion for web development professionals who must ensure their applications are tuned up to perform and scale well.

This doesn't mean that beginners should be discouraged from reading this book, quite the opposite. This is actually the only book newcomers to Rails need once they are done reading all those awesome beginner-oriented tutorials freely available on the Internet. Everyone interested in Rails, at some point, has to follow The Rails Way.

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 @methodmissing@ 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 Rubyblog.

⁶ See Russ Olsen Interview, On Rubyblog.

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

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!

“Yes, there is a Chapter 0. There is a little bit of introductory stuff we need to talk about before
we set you loose on Ruby. You wouldn’t want to get psyched about a new gadget, get it home,
and then figure out you need batteries, a grapefruit, and the ability to speak three languages to
even open the box would you?”

That reminded me immediately of Why’s Poignant Guide to Ruby. without a doubt. I don’t know how it is possible that two witty, crazy, and very inventive guys grew fond of the same programming language. Anyhow, to reassure a few of you, you won’t find any foxes or chunky bacon cartoons in HLRB, just some very well made (although still pretty unconventional) diagrams like this one:

Got the picture? Good. Let’s move on…h3. Chapter 0: What’chu talkin’ ’bout, mister?

Chapter 0 is like an introduction to the book and a place to put all the boring stuff you have to talk about in a book about a programming language:

• What is Ruby?
• Installation procedure (on Windows, Mac OS X and Linux)
• Hello, World!

Yes, you can skip this one safely without losing too much, unless of course you still need to install Ruby on your machine.

Chapter 1: Welcome to Ruby.

“This section aims to introduce the syntactic sugar and linguistic misfortunes of Ruby in the
quickest manner that will still allow for a full education on the subject.”

As the first two lines of this chapter say, it’s time to learn the basics of Ruby. You’ll be quickly guided through strings, numbers, collections and variables. Every section with tons of code examples for your to play with. You won’t find a full list of all the 876 methods of the String class, but you’ll certainly learn the 10 most common ones at least (numbers are random, so no, don’t count them).
Sure, yes, right, whatever… if you really want you can skip this chapter too, but if you are already a Ruby Guru there’s probably no need for you to read books about Ruby, right? Beginners need to read this chapter. It’s compulsory, really, and pretty enjoyable, too.

Chapter 2: Break it down now!

Or “learn how to segment your code” using methods, and… blocks & Proc objects! Gosh. Our poor newbies will probably have a heart attack if they never heard about blocks and closures before. I almost got scared myself, because this is normally regarded as a pretty tough topic. Despite, at page 25 of the book you’ll have to face your fears and dive into it. You’ll survive, anyway.

Purist Warning: Please be aware that sometimes the author may decide to use certain terms and construct which may not sound 100% right to your ears. Just move on, beginners will understand more things like “Think of Proc objects as blocks that are pushed into variables.” than anything else, guaranteed.

After this section you’ll finally be introduced to Ruby classes. Now, this can piss someone off, no doubt. Ruby is a fully OO language, so people must learn about classes before anything else. I must admit I was a bit confused by the ordering of the topics at first, but if someone comes from a non-OO background he’ll probably find this particular order more suitable.
This section will cover class and object basics in Ruby like defining classes, instantiating objects, access control, methods, attributes, scope, duck typing. Finally, you’ll briefly look into modules as well.

Chapter 3: Hustle and flow (control)

Finally, the author will deal with flow control. So things like if, case, conditional operators, loops and statement modifiers. In my opinion this section is truly excellent: it introduces all the control structures in a very simple and crystal clear way, often using flowcharts. A great chance even for absolute beginners to understand these basic but powerful concepts.
Towards the end of the chapter, you’ll also learn how exceptions work: a clever way to tell people “you have to learn how to use exceptions from the very beginning”. Really nicely done.

Chapter 4: The system beneath…

Here comes the juicy stuff. Up to now you learnt the usual boring things you need to know when learning a new programming language, now finally you learn how to do real things. The chapter is full of complete and meaningful code snippets which will answer nearly all the questions you may have (at this time):

• How do I read and write to a file?
• How do I handle threads and processes?
• How do command-line parameters and environment variables work?
• How can I perform specific Windows-only operations, like reading and writing to the Registry? What about OLE automation?

Some of the big books out there will not spend too much time talking about Windows-only libraries, but I found HLRB gives quite a comprehensive introduction about them.

Chapter 5: Looking beyond home

More juicy stuff. If you are looking for a tutorial to learn the basics about networking, from from sockets to FTP to POP and web services, look no further: this chapter does a very remarkable job introducing various network-related libraries, with the usual well written code examples.
If that’s still not enough, you’ll also have a chance to explore the wonderful world of distributed Ruby and of databases. Granted, this chapter won’t tell you about the 1567 methods available in ActiveRecord (buy a copy of Agile Web Development with Rails for this), but will tell you enough to get started.

Chapter 6: It’s a Library!

The final chapter will go more in depth on some more advanced topics, like:

• Strings
• Regexp
• Date & Time
• Hashing and Cryptography
• Unit Testing

Everything with more and more useful code snippets.

The Appendices

Last but not least, a HUGE collection of links and resources to learn more about Ruby, and a quick digression on C/C++ extensions… not much, but enough to wet your appetite.

The bottom line

HLRB is not the only book you need to read about Ruby. It’s better to make this clear otherwise I’ll be hunted forever by Dave Thomas, Chad Fowler, DHH and all the other excellent Ruby hackers who also wrote very successful books (which I bought as well). HLRB is LITTLE and HUMBLE, after all: it doesn’t aim at becoming the official Ruby Bible anytime soon (although a bird told me it may get updated someday and include more stuff), but it is still a worthwhile reading.

And of course I came to the very end of this review without mentioning the most important thing: this little wonder is free. All you need is to register to InfoQ (for free) and grab your free copy. If you want you can buy a printed copy for just $9.95, if you feel in a good mood (please do).

The most obvious strengths of this book are the abundance of code examples and very useful working snippets, and the unconventional style which makes it very readable and not boring at all. If I were to name some of its weaknesses (but only if you force me to), I’d say some parts should be expanded and more info on other libraries should be provided… but you never know what the future will bring us!

Well done, Mr. Neighborly!