>> Using a method that is called on self in a class, don’t use self.method_name when just plain method_name will do. (loc. 1500)

I don't have the book in front of me so I don't know what the context is, but this strikes me as something as barely worth highlighting, other than to show that you grok Ruby's method chain.

Some programmers would argue that using self.method_name helps clear up ambiguity to humans who read the code, even if it is equivalent to method_name

Russ is one of the best technical writers I've read. I've only gotten through half of this book, but I've read his design patterns book cover to cover and it is fantastic.

He recently did an appearance on Ruby Rogues for their book club episode on Eloquent Ruby: http://rubyrogues.com/033-rr-book-club-eloquent-ruby/

That's definitely a good primer if you on the fence about purchasing this book.

this is not true:

    ||= expands to @variable = @variable || @other_variable

I am not sure if semantics of defined-or-assign operator changed in recent rubies, but ||= used to expand to

    foo or foo = bar.

Which is different in some edge cases, e.g.

    >> a= Hash.new(0)
    => {}
    >> a[:key] ||= :v
    => 0
    >> a
    => {}
    >> a[:key] =  a[:key] || :v
    => 0
    >> a
    => {:key=>0}

I've just bought this book as well to get a deeper understanding of Rails (and also to get a newer book on Rails, most are aged).

While the first chapters are a refreshing take on Rails and easy to understand the book is getting kind of cloudy later when covering more complex topics. Cumbersome explanations followed by wack examples give you a hard time—you cannot easily grasp basic ideas, so you constantly switch between examples and theory but you just don't get it.

Especially, chapter 13 (on Singleton methods) is miserable. Admitting Ruby's Singleton Pattern isn't the easiest thing the book totally failed from here: I read this chapter dozen times until I gave up and just googled better explanations and I am sorry to say that every blog post about the Singleton Pattern did a far, far better job than this book. And from this point I did it with all following chapters—just scanned them briefly and googled better articles for respective subjects. This book was definitely not worth the money but at least I did again some Rails theory with the book as guideline.

The suggested distinction elaborated on between {} and do/end blocks is…unfortunate.

The block types have different binding precedence, which affects their suitability for fluent (read as "DSL") interfaces. The reason that Rake tasks are defined as:

    task :foo do
      …
    end

and not

    task :foo { … }

is not just multi-line readability, it's because {} binds to :foo, but do/end binds to task.

Inasmuch as you want to make a different distinction between {} and do/end, Jim Weirich's suggested distinction is as good as any: use {} when you're going to be using the result of the block and do/end when you're not. Therefore:

    squared = (1..10).map { |i| i * i }
    (1..10).each do |i|
      puts i * i
    end

Yeah; I'll probably use {} for both because it's more readable in the simple case, but I find that I rarely use do/end when I'm using the value of the block, and I'll almost always use {}.

I've bought the book a while ago and I pick it up whenever I have time, because I know it will always provide solid and enlightening information. The quality of writing is quite superb and I have not noticed any errors at all so far.

I've learned about the ways to call a method in ruby, what private and protected means, about the hows and whys of testing, about why it's better to have more smaller, specialized methods (and what that pattern is called), and much more. And I'm not even through 1/3 of the book.

Highly recommended!

In all fairness, it makes it pretty tough to take your comment seriously when you consistently refer to Rails when you mean Ruby.

Also, I have to disagree. Like the author of the post, I found Olsen's book to be a delightful read. It is certainly not a great "first book" on Ruby, however. I think you ought to read it once you've gained a little better understanding - its wonderful for smoothing out edges and cementing some of the more advanced concepts.

Ruby's terminology is confusing here, but singleton methods have very little to do with the Singleton Pattern.

The Singleton Pattern is a way to design a class that ensures at runtime that only one instance of that class ever exists. Singleton methods are (effectively) methods defined on a particular object rather than being defined for all objects of a single class.

The terminology is actually correct, because the way singleton methods work is by generating an anonymous class to which only the object at hand belongs (thus that anonymous class is an example of the singleton pattern) and defining the method there, but if what you're interested in is how to define your own singleton classes then understanding singleton methods doesn't help you, and vice versa.