Forum: Ruby on Rails Review of Ruby For Rails Chapter 3

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Ken K. (Guest)
on 2006-02-20 18:34
(Received via mailing list)
Here's my review of Chapter 3:

As the author says, this is a transitional chapter.  The first chapter
an introduction to Ruby, and the second was a similar introduction to
Now we begin the real purpose of the book, which is to dig into the Ruby
behind the Rails.

Periodically the question arises on this list about how much Ruby you
to know in order to do Rails.  Chapter 3 provides an elegant answer to
question, which boils down to four main issues:

1. Knowing Ruby helps you understand how Rails is handling your
behind the scenes

2. If you know Ruby, you can go beyond the common Rails idioms and

3. The Rails source code is written in Ruby, so you can dig into the
framework and possibly revise and extend it

4. Ruby applications integrate naturally with Rails, so you can write
programs that incorporate Rails functionality.

For me at least, this isn't a hard sell.  I teach software development
training courses for a living, and that means I always need to be
to answer questions about how the technologies actually work under the
To pick a simple example, many times I've encountered page designers
little real programming experience who want to know if they can learn
JavaServer Pages without knowing any Java.  The answer is "yes, but
no".  In other words, you might get away with it for a while, but you're
going to be very limited in what you can do.  Plus, you won't really
understand how JSPs work unless you've learned about servlets, and so

The author frames this issue very elegantly by pointing out two things:

1. Rails feels like a domain-specific language (DSL), so much so that
can forget there's a powerful programming language behind it, and

2. Rails coding often feels like you're simply doing configuration.  It
looks like you're simply setting the values of some variables, when in
you're invoking Ruby methods in a transparent way.

As a simple example, the author discusses "has_many :editions".  To
developers without a Ruby background, this looks like you're simply
a variable.  Rubyists (how do you spell that, anyway?) know that in fact
you're invoking the has_many method in the super class with the
symbol as an argument.  It's a good point - I rarely think about that
it is pointed out to me.

The DSL that is Rails comes with many common conventions which in fact
simplify Ruby considerably.  I have to admit that when I first dove into
this field and started reading the pickaxe book (Programming Ruby by
Thomas for those who don't know - get thee to
<>  and buy it if you don't have
it), I
didn't find Ruby nearly as "simple" as everyone says.  In fact, compared
Java, Ruby is actually much more complicated!  I know that sounds
but note that the criticisms of Java on this list often come down to the
explosion of libraries, frameworks, and supporting technologies in the
world, not the language itself.  The basic language is in fact pretty
simple, certainly much simpler than its C++ predecessor.  When I teach
to new developers I only have to help them get over the object-oriented
hurdle and then they're okay.  The syntax and idioms are actually pretty
intuitive.  I rarely hear anyone talking about an "obfuscated Java"

Ruby, on the other hand, gives you dozens of different ways of doing the
same things.  Its Perl heritage throws a huge legacy of regular
and metaphors at a nuby.  Ruby also adds concepts like blocks, lambda
functions, mixins, and more.  All of that makes Ruby extremely powerful,
IMHO give it quite a learning curve.  Rails helps that whole process by
establishing a small set of simple conventions that help a newcomer get
going quickly.  Simply the fact that because the Rails community has
that you'll never see "has_many(:editions)" or its even more explicit
"send("has_many", "editions".intern)", everything becomes much clearer

I often compare this to the fact that writing free verse is
easy, so there's a lot of it and most of it is appallingly bad.  On the
other hand, too many conventions can be overly constricting - even
can write fugues, and only they would bother doing so any more.

The author uses the example of YAML to illustrate that Rails feels like
configuration rather than programming.  I wondered about that myself -
introduce a completely separate technology in the midst of Rails?  The
answer apparently comes back to the Ruby YAML library, which sees a YAML
file as a nested Ruby hash and can convert between those formats easily.

The next section illustrates some of what this knowledge buys you.  A
theme is that its Ruby heritage implies that Rails does not intend for a
developer to confine themselves to already-developed Rails tags, but in
encourages expansion.  DHH himself has said as much on many occasions,
stating the normal open source argument that if you see a problem or
something you want to improve, go ahead and do it; you've got the source
code, so take advantage of it.  What I hadn't realized is how much the
basis makes that easy and natural to do so.

The author illustrates this idea in several ways.  The first area is
functionality to a controller.  To do so, he shows a sample from a live
Rails application, the Ruby Change Request site (
<> ).  There he points out that the site authors
were able to achieve easy sorting capabilities in the displayed table by
adding a short, relatively simple Ruby function.  He then writes a
"link_to_order" method on top of the normal Rails "link_to" method as an
example of an application helper for the view.

Moving to adding functionality to models, the author starts by
the "before_create" method in a model class.  This is a classic example
the Template Method design pattern (in its "hook" variant) from the
so-called Gang-of-Four, which I'm sure the author knows but doesn't
explicitly.  Then he points out that you can add new functions to the
classes and invoke them as you please.  I suppose the Java analog would
to talk about overriding callback methods in Struts, and adding methods
other than getters and setters to JavaBeans.

I should mention that here is where I had my one problem with this
On page 83 of the book (page 21 of 29 in my PDF file), the author
parenthetically remarks that you can try out the new "before_create"
by changing the description of one of the records to NULL,
the database with it, and noticing that the description field now says
"standard".  When I did that the description stayed NULL, puzzling me
for a
while until I realized I'd re-run the SQL script directly and therefore
bypassed all the added Rails functionality. :-)  When I did the console
at the end of the chapter (and therefore used the framework to do the
inserts), it worked as advertised.

Finally the author writes a Ruby application to convert legacy data (in
format, of all things) into saved data in a database that follows Rails
conventions.  It's an interesting application, which uses Rails by
objects of the proper type and invoking their save method.

This last demo provides the needed segue to talk about the Rails
invoked by "ruby script/console".  Though I'd used that script once or
twice, I hadn't realized that it was simply an irb session with the
components preloaded.  While that is seriously cool, I imagine it means
can't invoke controller methods there.  Still, it's a great tool to have

In summary, for me at least this was the best chapter of the book so far
also showed how this book is different from all the other Rails books
currently available.  I can't wait to see the next chapters.

Ken K.


Kenneth A. Kousen, Ph.D.


Kousen IT, Inc.


This topic is locked and can not be replied to.