Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Image

Ruby In Practice 104

Posted by samzenpus from the read-all-about-it dept.
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.

*

This discussion has been archived. No new comments can be posted.

Ruby In Practice More

Ruby In Practice

Comments Filter:

  • But is it (poignant)? (Score:4, Interesting)

    by Picass0 ( 147474 ) on Monday December 28, 2009 @01:47PM (#30574020) Homepage Journal

    Still my favorite:
    why's (poignant) guide to ruby http://mislav.uniqpath.com/poignant-guide/book/ [uniqpath.com]

  • Ringing Endorsement (Score:5, Insightful)

    by daceaser ( 239083 ) on Monday December 28, 2009 @02:11PM (#30574338) Homepage

    "[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!

    • > message queue that will spawn workers

      You have no idea of my level of disappointment when I realized that the above didn't say "message queue that will spawn hookers".

  • Yeah, I remember ... (Score:4, Funny)

    by neonprimetime ( 528653 ) on Monday December 28, 2009 @02:12PM (#30574346)
    ... Rudy [imdb.com], 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?

  • ...Ruby libraries change relatively quickly...

    [shakes head]

  • Before commenting, please complete this form (Score:5, Insightful)

    by Xunker ( 6905 ) on Monday December 28, 2009 @02:28PM (#30574540) Homepage Journal

    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.

  • 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

    • Re: (Score:2)

      by emj ( 15659 )
      Well what he does mention seems like they have the same style all over (lots of code).. You can read more than just the TOC [safaribooksonline.com] (1/3 of every page), at the site..

  • Hi, the author here... (Score:2, Informative)

    by graznar ( 537071 )
    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/ [manning.com] Thanks!
  • 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?

    • Re: (Score:3, Interesting)

      by Lord Ender ( 156273 )

      Python is more mature than Ruby. But that's Python's only advantage. Overall, Ruby is simply a more elegant and powerful language. It is a dream to program in. This is why you find people migrating from Python to Ruby, but very few going in the other direction. And the maturity disparity is only a matter of time...

      Also, JRuby is much more mature than Jython. If you want to work with Java libraries while still using a dynamic language, JRuby is the way to go.

      • Python is more mature than Ruby.

        Much more....and it shows in the library from all accounts I've read.

        But that's Python's only advantage.

        Clearly not just from reading the comments left here. Clearly Python's maturity provides for code stability and far easier migrations to receive the performance benefits of newer VMs. I suspect, but don't know, the list is actually far, far longer, all of which to be attributed to Python's maturity.

        Overall, Ruby is simply a more elegant and powerful language.

        That's extremely subjective. The same can be said for Perl (and yes, I've done large Perl projects too), but at the end of the day, Perl is Per

        • Re: (Score:3, Insightful)

          by Lord Ender ( 156273 )

          Clearly...clearly...much, much...drastically...drastically...

          Wow, you're trying so hard to stress your opinion, it's as if you feel... threatened?

          I've coded quite a deal in Python before switching to Ruby. As I said, Python is currently more mature. I like Python. It's my second favorite language. But the syntax? Metaprogramming? Python is chore to use by comparison. You are out of the loop, as evidenced by your errant performance claims. Ruby 1.9 is much faster than previous versions, and JRuby is faster t

          • Wow, you're trying so hard to stress your opinion, it's as if you feel... threatened?

            Hmmm... seems you're clearly projecting here. I'm asking questions to learn and to understand the attraction vs python and the only way to do so is by comparison. In return you attack? Why are *you* so threatened? Clear and expressive communication is entirely the point of communicating; and especially so in written form. If effective communication is threatening to you, you should seriously take time to re-evaluate your position.

            JRuby is faster than Python

            Pretty strong proof you're extremely threatened...which is absolutely not my i

            • clearly...

              Oh geeze, not this shit again. Moving on:

              That may be elegant but its equally useless and slow.

              Wow. Really? It's like you're trying to miss the point. No sense wasting my time trying to communicating with someone like that; I've got code to write!

              • I think you pretty well summed up; there is no advantage.

                I didn't even address the fact that there is a big difference between elegance and terseness. What you provided isn't event elegant, its terse. Elegance is a simple solution to a [often complex] problem where a non-obvious solution exists. What you provided is a terse, meaningless example of rails. Big difference. Compared to your example, a static page is elegant.

                In a nut shell, you really need to stop projecting your own inadequacies and fears onto

              • In case you wanted to know what everything points to as the real answer to my questions. [slashdot.org]

                That way, in case you run into such questions in the future, you'll have what appears to be a legitimate answer rather than the clearly bullshit and incendiary reply you gave me. Also notice the difference in tone and quality of exchange. Please note the difference between your bullshit and a meaningful effort to effectively communicate.

                Happy Holidays!

                • No matter how many times you use the word "clearly," your uninformed opinion becomes no less invalid. The fact that you dismiss a general example of web app syntax with "you could do that with just html" shows that you either have no idea what you are talking about (still in school?) or you're just a troll.

                  Either way, I'm not wasting my time on you. Good day.

                  • The fact you refuse to answer any of the questions offered in rebuttal, are easily confused by the words, "clearly", and, "elegant", and readily resort to projection and attacking can only be interpreted as biased fanaticism without nothing to contribute whatsoever, followed by accusations of trolling. The word, "clearly", is completely obvious to anyone with a smidgen of IQ. Made worse, your entire straw man argument hinges on a useless example whereby its entirely best to replace it with a static page; de

            • Jython exists for the very same reasons jRuby does. Anyone not threatened by Python, as you clearly are, is going to compare Jython to RJuby and nothing else. You don't see other people running around making such odd claims. When people say Ruby they mean Ruby. And when people say Python, they mean Python.

              Ruby and Python are languages. MRI, JRuby, IronRuby, Rubinius, Ruby Enterprise Edition, etc., and CPython, Jython, IronPython, etc. are implementations. If you want to compare language-to-language on imp

              • Ruby and Python are languages.

                With defacto reference implementations whereby when someone mentions that language they specifically mean the reference implementation. I guess since Ruby is coming from such a performance deficit that general rule is thrown out the window; but that's news to the world. Made yet odder is the fact you specifically compared JRuby to CPython to claim superiority. Again, something is amiss. But then again, I previously explained all this.

                Jython is one of the slower Python implementation

                I decided to look based on your insistence. It does appear I may have had

                • But, I did find something which is very contrary to your other assertions and my own expectations.

                  Where does anything in your long rambling recitation of results of the "Computer Language Benchmarks Game" contradict anything I've said?

                  • That was actually to Lord Ender - didn't pay attention to whom I was replying.

                    And summarization to make a clear point is far from rambling. Seems rudeness goes hand and hand with most Ruby guys. Wow.

                    • And summarization to make a clear point is far from rambling.

                      Yes, properly done, a summarization to make a clear point is far from rambling. That doesn't affect my characterization of GGGP, though.

                      Seems rudeness goes hand and hand with most Ruby guys.

                      This is amusing coming when you -- by your own admission in the same post containing this accusation of rudeness -- just posted a "response" to someone claiming that their claims are contradicted by empirical testing, when no such claims were contained either i

        • That doesn't really carry much weight. In fact, from what I've seen, those that have migrated to Ruby from Python have largely migrated back - viewing Ruby as an interesting experiment

          The plural of anecdote is not data.

          While I don't have direct experience, Jython is very mature. ... I suspect, Jython is as mature as JRuby.

          Wow, I'd love to hear your opinion about things you have no experience with and have strong suspicious about.

          How do you expect to be seriously talking about stuff you claim to not really know about?

          I suspect you could benefit by taking a step back, re-reading your post, and spending some time reflecting on your own biases.

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

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

        • Re: (Score:2)

          by rtb61 ( 674572 )

          Simpler to say Ruby is more compact, easier to read and understand. More compact you can see more code on screen especially when using an IDE, often a complete function, sometimes a complete module. Easier to read and understand has two benefits, less documenting required and, heh, of course poorly documented code is easier to understand. From this comes all the other benefits, like a large function library etc.

          • First, let me say thank you for responding in a coherent, non-threatened manner. Seriously and sincerely.

            More compact you can see more code on screen especially when using

            So why not use Perl over Ruby if terseness is such a significant factor? You'd be hard pressed to be more compact than Perl.

            From one rant I received, some seem to confuse terseness with elegance. Once again I find I'm thanking you for for not being so easily confused.

            I do agree, from what little Ruby I've seen, terseness is a clear attribute of Ruby and seems completely contrary to the Python approach, w

            • Re: (Score:2)

              by rtb61 ( 674572 )

              I suppose you have to allow that I am not heavily into coding, as such, I have very little personal investment in it. Simply I like the language that's the easiest to code and debug. I forgot to mention another big plus for me, http://en.wikipedia.org/wiki/Interactive_Ruby_Shell [wikipedia.org], nothing like being able to run and test a single line of code to see what is not working and to check for undesired output.

              It just seems a very flexible easy language that can be used in a lot of different environments, so it ge

              • I didn't know Ruby had an interactive shell. Thanks.

                In case you're curious, if a script is not provided to python it goes into an interactive mode, allowing for much the same thing. And if you want such python interaction on steriods, you can always checkout ipython [scipy.org], which is actually a complete command line shell replacement (as in replacement for bash, ksh, cmd, etc), in addition to its interactive python capabilities.

        • Furthermore, those that did migrate largely did so because of rails. Now that Python has a huge bucket of competing solutions, some arguably superior, especially in ORMs, the draw of Ruby vs Python seems to have been drastically reduced.

          I'm not really sure that's all that true: even if Python frameworks caught up with where Rails was, there are lots of Ruby frameworks -- inspired by people hitting places where Rails wasn't ideal -- that are better than Rails for lots of things (including Merb, which is mer

          • You mean 2.5/2.6, instead of 1.5/1.6, right?

            Err, yes...sorry...too many version numbers being tossed around.

            Even so, JRuby -- which supports essentially all of Ruby 1.8 except Continuations, and has a 1.9 mode that is close on the heels of the mainline Ruby 1.9 -- is a more current Ruby than Jython is for Python.

            I concede that now.

            I'm not really sure that's all that true

            Something I wish I had previously offered is, much of the modern Python web frameworks got much of their inspiration and direction directly from Rails; no bones about it. As a result, many of those same projects worked to implement a wanna-be rails equivalent.These first generation wanna-be frameworks fell short on many fronts. Regardless, various framework projects followed and all seemingly suffered the same issues as Rails

            • I believe it is fair to say parity exists and that SQLAlchemy likely even provides a superior ORM than ActiveRecord.

              Sure, as you point out Rails isn't exactly standing still, just the same I don't have a problem offering Python has reached web framework parity with Rails.

              Perhaps, but there are other, arguably better, Ruby ORMs (Sequel, DataMapper) -- which can be used with Rails, and some of which are the preferred ORMs on other Ruby web frameworks -- than ActiveRecord. ActiveRecord is dominant because it c

    • Re: (Score:2)

      by jjohnson ( 62583 )

      The only meaningful distinction I've seen after spending time investigating the two and why some choose one over the other, is the underlying philosophy of each. With Python, there's almost always a "right" way to do a particular thing, an attitude of choosing the best practice summed up in the adjective "pythonic". Ruby follows Perl's TIMTOWTDI line, with a very flexible syntax that allows for a variety of ways to accomplish a particular end. So mainly, it's a temperament thing: coders who like a flexi

      • First, let me say thank you for responding in a coherent, non-threatened manner. Seriously and sincerely. Your reply seems well thought out and also seems to support much of what I suspected; though not to the level of detail you provide.

        It appears it boils down to personal preference in that the language and underlying philosophy simply speaks to a developer. I can absolutely respect that. Not everyone thinks the same way and not everyone goes about solving problems the same way. So while Rubyists may be "

      • Re: (Score:2)

        by mcvos ( 645701 )

        The only meaningful distinction I've seen after spending time investigating the two and why some choose one over the other, is the underlying philosophy of each. With Python, there's almost always a "right" way to do a particular thing, an attitude of choosing the best practice summed up in the adjective "pythonic". Ruby follows Perl's TIMTOWTDI line, with a very flexible syntax that allows for a variety of ways to accomplish a particular end. So mainly, it's a temperament thing: coders who like a flexible tool that allows them to find 'clever' solutions prefer Ruby; coders (like me) who like for there to be a best practice, and don't break the rules without a decent reason to do so, prefer python.

        This is a very good point. This also shines through in the culture of the communities. I've read from several people that they got annoyed by the Python community's rigid stance. Often someone would find an odd quirk (arguably even a bug) in Python and ask why it was like that. Instead of responding with possible fixes, the responses often amounted to "that's the only right way to do it, and if you disagree, you're wrong" (though probably phrased more diplomatically). In many other communities (including Ru

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

      Lots of Rubyists are also attracted by Python, though even many of those that like Python in general often dislike particular aspects of Python (the whitespace handling is a big one.) Also, lots of people prefer Ruby because they like particular Ruby frameworks (Rails, of course, is a big one) or because they found it an easier transition from Perl. And lot

    • true, but python is far from perfect..........
    • Who like ruby? Those that get frustrated by Python and think that it is way too high level.

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close