Slashdot Mirror
Ruby In Practice
littleidea writes "Ruby In Practice is like a sampler platter that picks up where The Ruby Way leaves off. Depending on your tastes each of the different offerings are delicious, but sometimes leave you wishing you had a whole order of just that. Then again, if you eat the whole thing, chances are you won't be hungry." Keep reading for the rest of Andrew's review.
Ruby In Practice
author
Jeremy McAnally, Assaf Arkin with Yehuda Katz, David Black, Gregory Brown, Peter Cooper and Luke Melia
pages
335
publisher
Manning
rating
8
reviewer
Andrew Clay Shafer
ISBN
1933988479
summary
A cookbook style reference with Ruby code examples for systems integration, monitoring, messaging, web development, processing documents and databases in a clear problem/solution format.
I really jumped headfirst into Ruby and the Ruby ecosystem when I started working on Puppet around Fall 2007. I had spent years writing code in compiled imperative and object oriented languages and just dabbled with interpreted languages before that. I've met Jeremy and several of the authors of Ruby In Practice at Ruby conferences since then.
I had a particularly hard time rating this book. If you have just learned the Ruby basics and you need to hook up your jabber server to a message queue that will spawn workers that interact with RESTful web services exposing indexed logs to twitter by tomorrow, then this book is a 10. If you are a hard core Rubyist plugged into the Ruby ecosystem, and 'Ruby In Practice' is what you do all the time, then this book is probably a 6, useful and enjoyable but hard to recommend. I'm somewhere in the middle, so I'm giving the book an 8.
The books starts out with the premise that the reader can read Ruby code. I wouldn't call the style 'code heavy' but this book is definitely 'code ample'. If you haven't been through the Pickaxe or at least a Ruby primer of some sort, be prepared to spend some time head scratching and googling before all the code syntax makes sense. That being said, you don't need to understand the subtleties of 'yield' or 'inject' to understand the examples and the book does a reasonably good job of walking through and explaining them. The exceptions to that are some of the examples involving Rails make the assumption that the reader is familiar with those idioms, which is probably fair statistically speaking and those bits can be filled in rather quickly with one of the many books on the topic or your search engine of choice.
The book credits a number of Rubyists with contributions for each of the sections. This makes for some noticeable variation in the stylistic presentation from topic to topic. As I alluded to earlier, each of the sections is more of a taste of a topic than a full exploration, but there are also references to the resources one would need to pursue each topic more fully.
The book starts out with chapter on 'Why Ruby' followed by an attempt to convert readers to become 'Test Infected', then the real Ruby fun begins in chapter 3. The first example is scaling images, stuffing them in Amazon S3 and printing the link to Twitter in 30 something lines of code. If you don't understand Ruby syntax and passing blocks, you will probably be a little lost here, but the good news is: if you take the time to sort out these first examples the rest of the code in the book should be relatively accessible. The application domain will vary throughout the book, but the level required to understand the ideas expressed in the code remains relatively constant. (which one might argue is one of the strengths of Ruby as well)
By this point, the rest of the book basically follows this pattern, discussion on a technology topic, gem install, code examples, links to more resources. I'm not going to list all the topics, though I alluded to many of them when I discussed the rating. (Here's the TOC to give you some idea.) The book definitely covers ground.
There is some really choice stuff in there and I definitely learned things, but there are a few things that are presented through Ruby colored glasses (as one would probably expect). The one that will always stick out is 'Say goodbye to dependency hell!' in reference to setting up a gem repository and using RubyGems (gems is Ruby's network library/package manager, similar to CPAN for perl or apt for Debian Linux) . I had a little chuckle and eye roll at that one. (Sorry Jeremy)
One quick note, and this is a comment about the Ruby ecosystem as much as anything, Ruby libraries change relatively quickly. On the one hand, gems are mostly up to date and tracking new versions of whatever they integrate with, on the other, this can sometimes break backwards compatibility. I didn't run every line of code in the book, but I played around with a good portion of it. There were a few gem updates which were not compatible with the code in the book. The twitter gem in particular had non-backward compatible changes to authentication (to support OAuth). I was able to get the example working with a few minutes of Google and looking at the code, but that might have taken longer and been frustrating if I didn't have a Ruby background. Ruby In Practice provides enough context and information that you can probably find the maintainer or community for a project without much trouble if you really get stuck.
I would strongly recommend this book to someone who has come to Ruby through Rails and is ready to learn more about what is possible with the language or someone who is coming from another language background with experience and perspective on things like stomp servers or Lucene and who's interest in dynamic languages has been piqued (if you have a background in any OO language, a simple primer is probably enough to make this book accessible. Also, you should remember irb, the interactive ruby interpreter, is your friend.) Anyone in either of those groups will get working examples and resources that could realistically be used in useful applications right away.
You can purchase Ruby In Practice from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I had a particularly hard time rating this book. If you have just learned the Ruby basics and you need to hook up your jabber server to a message queue that will spawn workers that interact with RESTful web services exposing indexed logs to twitter by tomorrow, then this book is a 10. If you are a hard core Rubyist plugged into the Ruby ecosystem, and 'Ruby In Practice' is what you do all the time, then this book is probably a 6, useful and enjoyable but hard to recommend. I'm somewhere in the middle, so I'm giving the book an 8.
The books starts out with the premise that the reader can read Ruby code. I wouldn't call the style 'code heavy' but this book is definitely 'code ample'. If you haven't been through the Pickaxe or at least a Ruby primer of some sort, be prepared to spend some time head scratching and googling before all the code syntax makes sense. That being said, you don't need to understand the subtleties of 'yield' or 'inject' to understand the examples and the book does a reasonably good job of walking through and explaining them. The exceptions to that are some of the examples involving Rails make the assumption that the reader is familiar with those idioms, which is probably fair statistically speaking and those bits can be filled in rather quickly with one of the many books on the topic or your search engine of choice.
The book credits a number of Rubyists with contributions for each of the sections. This makes for some noticeable variation in the stylistic presentation from topic to topic. As I alluded to earlier, each of the sections is more of a taste of a topic than a full exploration, but there are also references to the resources one would need to pursue each topic more fully.
The book starts out with chapter on 'Why Ruby' followed by an attempt to convert readers to become 'Test Infected', then the real Ruby fun begins in chapter 3. The first example is scaling images, stuffing them in Amazon S3 and printing the link to Twitter in 30 something lines of code. If you don't understand Ruby syntax and passing blocks, you will probably be a little lost here, but the good news is: if you take the time to sort out these first examples the rest of the code in the book should be relatively accessible. The application domain will vary throughout the book, but the level required to understand the ideas expressed in the code remains relatively constant. (which one might argue is one of the strengths of Ruby as well)
By this point, the rest of the book basically follows this pattern, discussion on a technology topic, gem install, code examples, links to more resources. I'm not going to list all the topics, though I alluded to many of them when I discussed the rating. (Here's the TOC to give you some idea.) The book definitely covers ground.
There is some really choice stuff in there and I definitely learned things, but there are a few things that are presented through Ruby colored glasses (as one would probably expect). The one that will always stick out is 'Say goodbye to dependency hell!' in reference to setting up a gem repository and using RubyGems (gems is Ruby's network library/package manager, similar to CPAN for perl or apt for Debian Linux) . I had a little chuckle and eye roll at that one. (Sorry Jeremy)
One quick note, and this is a comment about the Ruby ecosystem as much as anything, Ruby libraries change relatively quickly. On the one hand, gems are mostly up to date and tracking new versions of whatever they integrate with, on the other, this can sometimes break backwards compatibility. I didn't run every line of code in the book, but I played around with a good portion of it. There were a few gem updates which were not compatible with the code in the book. The twitter gem in particular had non-backward compatible changes to authentication (to support OAuth). I was able to get the example working with a few minutes of Google and looking at the code, but that might have taken longer and been frustrating if I didn't have a Ruby background. Ruby In Practice provides enough context and information that you can probably find the maintainer or community for a project without much trouble if you really get stuck.
I would strongly recommend this book to someone who has come to Ruby through Rails and is ready to learn more about what is possible with the language or someone who is coming from another language background with experience and perspective on things like stomp servers or Lucene and who's interest in dynamic languages has been piqued (if you have a background in any OO language, a simple primer is probably enough to make this book accessible. Also, you should remember irb, the interactive ruby interpreter, is your friend.) Anyone in either of those groups will get working examples and resources that could realistically be used in useful applications right away.
You can purchase Ruby In Practice from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Still my favorite:
why's (poignant) guide to ruby http://mislav.uniqpath.com/poignant-guide/book/
That would be Python, not Ruby... and since I have to wait for Slashdot, the book is good. So is the Well Grounded Rubyist (also by Manning).
"[If] you need to hook up your jabber server to a message queue that will spawn workers that interact with RESTful web services exposing indexed logs to twitter by tomorrow, then this book is a 10."
I think you have comprehensively explained why I don't want to read this book.
Thank you sir, for your service to humanity!
-- There are three kinds of mathematicians: those who can add and those who can't.
... Rudy, he always practiced real hard, a real die hard ... but I don't recall if he ever got to play in any actual games.
There were a few gem updates which were not compatible with the code in the book. The twitter gem in particular had non-backward compatible changes to authentication (to support OAuth). I was able to get the example working with a few minutes of Google
Time for my usual Slashdot book review rant. Why buy this book, if the review states its mostly a list of inspirational google searches?
MOST technical books are little more than edited concatenated google searches... However it is possible to write a technical book that is better than that, or at least different from that. For example, the "little schemer" series is certainly unique.
So, why buy this book?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
...Ruby libraries change relatively quickly...
[shakes head]
Before commenting, please complete this form:
Sec. 1 Ruby v Python
[ ] I am a Ruby/Python fanboy/fangirl
[ ] I already have a positive/negative entrenched opinion of Python or Ruby
[ ] I cannot tell the difference between the two languages
Sec. 2 Ruby on Rails
[ ] I assume Ruby == Ruby on Rails
Sec. 3 Other
[ ] I program in PHP for it's robust design, consistent syntax and architectural soundness
[ ] I do not understand sarcasm
Scoring: If you answered any of the above questions in the affirmative, your comments may be dismissed out of hand.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Or QBasic.
Sure! As a matter of fact I'm reply to your comment through my Ruby command-line...HTTP ERROR 408 - REQUEST TIMEOUT#$(84@...NO CARRIER
Ruby 1.9 moved to a VM architecture and with a sizable performance boost. unfortunately they also managed to break half the existing gems out there with changes to the language; slowly but surely things are moving in the right direction.
Compared to what?
C,C++, Or any lanauge that needs to be compiled to an optimized for the platform binary form to run, at the expense it only runs on type of platform.
Java, Dot Net, or any language that compiles to a byte code with is optimized for its function and memory can be preallocated.
Python, Perl or other Scripting languages where there is little optimization that can go on as the code is running as it interprets the next line of code.
Speed isn't always what makes or break a language
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Compared to what?
Basically every other language you mention in your post.
I can't believe how long the gem transition is taking either. That's been the most frustrating part of it. (I'm running 1.9 right now for just about everything though.) You'd think by the time 1.9.1 was out people would have been converting (and in many cases it's just not that hard).
The same was true for Java in its early days and now it's quite fast. I'm no Ruby fan, but I am confident that it will get over its speed issues in time. It's definitely an up-and-comer. Personally I'm pulling for Groovy and GRAILS, but I don't think it'll ever get past being a knockoff.
Check out my lame java blog at www.javachopshop.com
On top of it the patch levels for the 1.9 version break as things move along.. For example, 1.9.1p243 came along and decided that upon unlinking a file description we should close it first. This was not the previous behavior and broke Rack. I really hope the ruby community pulls together and we get to where we were 2 years ago on the upgraded platform.
The good news, is I like the topic, I have fat stacks of cash and am willing to part with it for a good book. Emphasis on the word Good. A direct pipeline into the minds of the insiders, is worth some bucks.
The book credits a number of Rubyists with contributions for each of the sections.
Ah, and then the bad news. Naughty book editor, gimme my money back.
This makes for some noticeable variation in the stylistic presentation from topic to topic.
So, Mr reviewer, what say? You described the battlefield, now which side won? Do the direct insights of the words of the prophets outweigh cruddy editing, or is it too shaky to read? I've got a pocket full of cash and like the bank robber says in the movie Dirty Harry, indecisively struggling asking himself if Harry's revolver is empty or not, "... I gots to know ..."
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I hope so. I enjoy the language immensely. I liked Python, but I LOVE Ruby and like doing my web dev there. I don't even use Rails either.
That's why most of my programs are still at the Ruby 1.8.x revision level. A lot of admin scripts and things that I can afford to take performance hits since they automatically run after hours. My Rails implementation has relatively low user load as well. If I had to upgrade to 1.9 to get that performance boost I've seen a good amount of areas in my code that would be borked. Backwards compatibility is a concern when that times comes. It's one thing deprecating and gracefully warning you. Some of my code testing proved quite _interesting_.
I'll go back even further. PERL was once touted as the newness but in the web world it had issues scaling. Most things had issues scaling back then so it wasn't a surprise. But look now, one would be hard pressed to say PERL is slow. Now that eventually went to PHP, and then to Ruby, and Python. The simple fact is it's more about handling requests, ie writing server software like fastcgi or apache mod_x modules, then the actual language implementation itself. Ruby is at this spot right now. The problem is this isn't the "good old days", like PERL in it's golden age, and there are good alternatives to Ruby so it may be losing some steam. But just like PERL it's not the language itself, but the platform it runs on ("Rails is a Ghetto").
Gotta second that. I liked Ruby but hated the speed and scalability issues. Beginning to loathe PHP because of its inconsistencies and inability to advance the language.
Groovy on the other hand has a community that is advancing (without much recognition) a rich platform with Grails (for web apps) and Griffon (for swing apps). It's amazingly fast, simple and easy and integrates with traditional Java without any additional configuration needs. This will definitely kill JRuby for the most part.
This is my sig. There are many like it but this one is mine.
Parent should be modded insightful. Mine should be modded funny.. sheesh.
Michael J. Ryan - tracker1.info
Looks like the stock is getting slim over on Amazon, so if you want to order it still and they're out, hit up the Manning site: http://manning.com/mcanally/ Thanks!
[ check out my ruby book @ http://ww
If there were a good book on how to (more easily) scale ruby/jruby on rails apps, I'd buy it. I don't think I'd buy a book on Ruby otherwise.
I really never figured out exactly who Ruby appeals to. It seems those who would be interested in Ruby would also be attracted by the more mature Python.
So what projects and for what reasons are people picking Ruby over Python? Perhaps Python isn't even in the comparison? Is it just to be different? The antithesis of the heard mentality? Some critical feature Python is missing? Superior frameworks? Why?
It doesn't sound right because its not.
Ruby is still far slower than Python on the typical basis. Jython, JRuby, and Java all perform about the same when running on the JRE, with Java still leading by a noteworthy margin; which isn't exactly surprising.
but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.
Has anyone actually proven this in practice? This is proclaimed in the theoretical sense over and over but I've never actually seen anything real to back this up.
The plural of anecdote is not data.
He never made any such claim. He was just responding to someone else's anecdote with his own.
And the co-author is Assaf Arkin, I'm afraid it doesn't get any better than this.
The plural of anecdote is not data.
Which means your entire rant is safely ignored as I clearly referred to DATA. The word idiot comes to mind.
Okay, something is entirely clear from the replies I'm getting. There is no advantage and anyone who questions is to be attacked, as that's the only recourse available to Ruby users.
That's sad.
but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.
Has anyone actually proven this in practice?
I've seen it with mathematics-heavy code written in a style that's not very idiomatic for Java (but still nicer than Fortran, which is what was used for the comparison baseline). I suspect that typical Java code does not get as good a speedup as that due to poor memory management at the user code level and fragmentation of programs into lots of little pieces scattered over a deep inheritance hierarchy (happens too often, hard to optimize very extensively).
OTOH, what a good JIT does seem to do is get rid of the penalty of using an object format that is not native code. (It could go better, but rarely does because the gains from compiling with profiling data available - the typical equivalent in C programming - are usually very small.)
"Little does he know, but there is no 'I' in 'Idiot'!"