

Wisdom I picked up from Eloquent Ruby, Chapters 1-9 - philaquilina
http://www.philaquilina.com/2012/04/04/wisdom-from-eloquent-ruby-from-oh-to-oh-yeah-part-1/

======
bstar77
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.

~~~
rlander
I agree.

I don't particularly care for Ruby nor OOP since I mostly use functional
languages nowadays.

With that said, I read both books and they're among the best technical books
I've ever read. Even I if never have to implement a pattern in Ruby in my
life, the level of insight into the language is sky-high.

I just wish he would write Eloquent Clojure.

------
riffraff
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}

~~~
halostatue
As far as I know, this behaviour is still the same; changing it would be a
breaking change for those edge cases.

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

~~~
prsimp
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.

~~~
tferris
Good point with 'Rails'—my mistake—and I understand that now my competence
could be questioned. I meant Ruby of course (which is Rails' core and if you
got Ruby well you are a much better Rails dev and I think that's the #1 reason
when reading Ruby books => Rails).

I appreciate the author and his work but frankly: I got so frustrated with the
style. Go and read chapter 13 and compare all the blog posts about Singleton
out there (it's a huge difference). Reading one chapter again and again just
to see that someone on StackOverflow drew a far better picture doesn't make
you happy. Or take the next chapter 14 about class instance variables: this
topic is brought to the reader in a very verbose style and again, the net full
of blogs and Q&As deliver better much results. People there even discuss and
question the benefit or real-world usage of class instance variables which is
fully omitted in the book.

>> its wonderful for smoothing out edges and cementing some of the more
advanced concepts

Sorry, I totally disagree, especially the advanced stuff is delivered in
better quality in the net. Don't get me wrong but your words sound like the
typical not-helpful Amazon reviews (which made me buying this book). BTW,
there more annoying parts like squeezing every subject at the end of a chapter
in a monotone structure ("Staying out of trouble", "In the wild", etc.) which
is getting boring quickly, doesn't give one a better understanding and feels
like the author going through his checklist for every chapter.

------
halostatue
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 {}.

------
juretriglav
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!

------
danso
>> _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_

~~~
tptacek
Especially because some bare method calls will produce syntax errors ('class'
being the obvious example).

I think there's no good rule of thumb to be had here; use whichever style
makes the code clearer.

~~~
halostatue
That's _exactly_ the rule of thumb that makes for good Ruby: use _whatever_
style makes the code _clearest_. Over the last ten years, my Ruby has evolved
as I've come to understand this (and it's affected the code I write in every
other programming language I know, including bash scripts).

At times, this means I have to skip a one-liner because it's not as clear as
expanding it out; at other times, it means _using_ a one-liner because it's
clearer than an expanded form. Sometimes it means using #length on a String or
Array, sometimes it means using #size. They do the same thing (much to the
annoyance of some folks), but the fact that both work means I can think about
how my code reads.

