Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

Rails Cookbook 59

Posted by samzenpus from the get-cooking dept.
honestpuck writes "When reading the foreword of Rails Cookbook I felt a strong kinship with Zed Shaw, I too have fond memories of the first edition of Perl Cookbook and the way I relied on it once I'd taken the training wheels off. Since that one I have relied on several of the O'Reilly Cookbook series. It is only when I discard the early tutorial and dive in the deep end with a "cookbook" on my desk that I really start to learn proficiency." Read the rest of honestpuck's review.
Rails Cookbook
author Rob Orsini
pages 514
publisher O'Reilly
rating 7
reviewer honestpuck
ISBN 0596527314
summary for programmers who know something about web development but are early in their use of Rails,


I felt timorous and unsure when I finished Agile Web Development with Rails, a marvelous tutorial that introduced me to my first real web development framework (I must have enjoyed it, I just bought the second edition). Since I have volunteered to develop a fairly large and complex web application in Rails I awaited the arrival of my copy of Rails Cookbook with hopeful anticipation and bated breath.

Rob Orsini, his fellow contributors (15 in all) and the team at O'Reilly have once again delivered. Compared to the previous titles in the series I've owned Rails Cookbook seems to have fewer recipes but as it is tackling an entire application framework and some serious issues, some of the solutions and discussions run a lot longer. The book is targeted at programmers who know something about web development but are early in their use of Rails, though it should be helpful to all Rails developers.

The book starts with tackling issues of installation and getting development tools installed in the first two chapters. Despite already deploying a couple of simple Rails apps I found that there was the odd useful tip in these chapters. The book then covers each of the three main sections of Rails; Active Record, Action View and Action Controller. The rest of the book goes on with large chapters on testing, Javascript, debugging, performance and hosting and deployment. Along the way it also covers REST, Action Mailer, security, plug-ins and graphics.

The extremely large section on Active Record was to me the most useful. I seem to spend an inordinate percentage of my Rails coding time with Active Record and it contains a large part of Rails power so I appreciated the size of this chapter. By contrast the chapter on graphics is almost entirely unread.

It seems obvious that this book should be compared to Pragmatic's Rails Recipes. The first point of difference is that Rails Cookbook covers installation and setup. The second point is that is 'Recipes' covers Rails 1.1 while 'Cookbook' targets the brand new Rails 1.2. As a project fairly new on the scene Rails is a fast moving target so the six months between the two books makes a difference. Both books have excellent coverage of the various aspects of Rails, with a great deal of overlap. 'Recipes' has more, shorter pieces while 'Cookbook' tends towards longer pieces with more discussion. 'Cookbook' is also more general, with more recipes more likely to be useful in every Rails project you write.

The style is different between the two. Here Cookbook comes off second best, it feels as though tightly edited by a number of hands and ends up lacking personality; functional but cold compared to Recipes. The writing, however, is good. It's easily read, at times it feels like a good textbook. The layout is clean, it is easy to find the information you need from each recipe when you want.

With almost all "cookbook" style books I seem to be left feeling that a number of the recipes are just a little too obvious and covered well in beginner tutorials. There is some of this in Rails Cookbook, most notably the first two chapters, but overall the book will be useful to any beginner to intermediate Rails programmer. Personally I had a couple of moments where I read a tip and wanted to scream as it demonstrated and explained in a few short sentences and half a page of code what had taken me hours to discover for myself.

The "Cookbook" series all seem to be books worth the price and shelf space. This one is no exception. I'd give it three out of five with an extra half for its timely information on Rails 1.2 and would recommend it for all Rails programmers from the absolute beginner through to all but the most experienced. If you already have a copy of 'Recipes' and are happy with it then you might want to stick with that till either volume is updated for the next major revision of Rails, otherwise you will almost certainly appreciate a copy of Rails Cookbook.

You can purchase Rails Cookbook 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.

Rails Cookbook More

Rails Cookbook

Comments Filter:
  • I think this has been reviewed once or twice before on Slashdot... but I digress.

    I agree that this is a fantastic book, as it shows you some incredibly slick stuff you can do using Rails. But unless you already have somewhat of an understanding of Ruby then I'd strongly recommend getting a separate reference book just for Ruby by itself. O'Reilly makes one of those, too. :)

  • You can get it for more at B&N (Score:5, Funny)

    by stoolpigeon ( 454276 ) * <bittercode@gmail> on Monday February 26, 2007 @04:13PM (#18157722) Homepage Journal
    You can get it for $4 more at B&N [barnesandnoble.com]
  • I've seen so many slashdot book reviews with "rails" and "cookbook" in the title, that I could swear this book has been reviewed here already.

  • Lifted from the Better Book... (Score:4, Informative)

    by jaredbpd ( 144090 ) on Monday February 26, 2007 @04:57PM (#18158310)
    I had this book for about 26 hours before I returned it, I was deeply displeased by the repetition from the existing work, Rails Recipes. All the cookbook entries about model relationships, polymorphic associations, etc, were lifted straight from Rails Recipes, right down to using Magazines, Readers and Subscriptions as the example objects.

    And, while the book has a shiny "Rails 1.2" badge on the cover, very little of it had anything to do with Rails 1.2 whatsoever, there were only a handful of recipes in the very back which dealt with the new features.

    Plus, was it really necessary to burn 3 pages talking about how to join a discussion group of fellow Rails developers? If you're a web developer and you can't find an online community to discuss the language/framework, you need more help than Rob's book is able to offer...

    • Jaredbpd,
      I am sorry to disappoint you but nothing was lifted from Rails Recipes. I would like to find you a recipe that mixes join models and polymorphism in Rails Recipe. I wrote the last 2 recipes in that chapter and that code is taken straight out (in simplified form) from one of my applications. I actually wrote the join model and polymorphism one and then I was asked to write one just about polymorphism as introduction to the concepts. The editor thought that my recipe was a little too advanced.

      You

  • Rails is Doomed (Score:1, Flamebait)

    by Tablizer ( 95088 )
    A critique of R&R. It basically says that it will not "catch on" for the same reason that Lisp and Smalltalk never did: heavy dependence on esoteric ideas and meta programming:

    http://www.beust.com/weblog/archives/000382.html [beust.com]
         

    • Re:Rails is Doomed (Score:5, Informative)

      by swimmar132 ( 302744 ) <joe@@@pinkpucker...net> on Monday February 26, 2007 @05:15PM (#18158638) Homepage
      I think Rails has already "caught on".

      Also, that blog post has a ton of errors. Here's one: If you want to write a Web application in Ruby, there is only one solution. Only one. Ruby on Rails. Hm, about about Camping [hobix.com] or Nitro [nitroproject.org]?

      Rails scales perfectly well, just the same as any other share-nothing approach.

      Ugh, so much FUD.

      • Re: (Score:1)

        by Tablizer ( 95088 )
        Ugh, so much FUD.

        The author appears to *like* R&R. He/she is just being realistic about it going mainstream. I see no evidence he/she is out to bash R&R.

        Whether he/she knew about the Rails alternatives or not does not diminish from the main point.
             
      • Ugh, so much FUD.

        But no core UTF-8 support makes it useless to large numbers of people. The hacked support doesn't cut it. It needs to be supported right down in the core to make it fully stable and workable.

        Bob

    • Re:Rails is Doomed (Score:5, Funny)

      by Temujin_12 ( 832986 ) on Monday February 26, 2007 @05:42PM (#18159018)
      No...THIS is why Lisp never caught on:
      (defun fibonacci (nn)
        "Return 2 consecutive Fibonacci numbers."
        (declare (type (integer 0) nn))
        (case nn
          (0 (values 0 0)) (1 (values 1 0)) (2 (values 1 1)) (3 (values 2 1))
          (t (multiple-value-bind (mm rr) (floor nn 2)
               (declare (integer mm) (type (integer 0 1) rr))
               (multiple-value-bind (f0 f1) (fibonacci mm)
                 (declare (type (integer 0) f0 f1))
                 (if (zerop rr)
                     (values (* f0 (+ (* f1 2) f0))
                             (+ (* f0 f0) (* f1 f1)))
                     (values (+ (* f0 f0) (sqr (+ f0 f1)))
                             (* f0 (+ (* f1 2) f0)))))))))

      • Re: (Score:1)

        by chromatic ( 9471 )

        Everyone knows Haskell is the best language for writing a Fibonnaci generator.

        • Re: (Score:3, Funny)

          by ari_j ( 90255 )

          Everyone knows Haskell is the best language for writing a Fibonnaci generator.

          You really do just have to choose the best language based on the problem you are solving. After all, every language is good at one thing, and Fibanacci generators are Haskell's. :P

      • Re: (Score:3, Informative)

        by drix ( 4602 )
        Yes, it's easy to obfuscate almost any language. I think someone who wasn't being quite so tendentious might write:

        (defun fib (n)
        "nth element of the Fibonacci sequence"
        (check-type n (integer 0 *))
        (if (< n 2) n
        (+ (fib (1- n)) (fib (- n 2)))))
        Lisp is a pretty good language. Its reasons for not catching on have more to do with its grassroots beginnings (no M$ Visual Lisp) and the fact that GC/automatic memory management
        • You don't think the fact that people naturally think imperatively and not functionally has no bearing on the situation?

          When it's the difference between lisp, which was marginally easier to develop with once you understood it, or cobol, which was easier to understand, but harder to develop with once you knew it, which do you think people would choose?

          Cobol more than nine times out of ten...and with the increase in coders, there was an increase in available code. Pathways to solve common problems were made a

          • Re: (Score:2)

            by drix ( 4602 )
            I don't know how people "naturally" think; for me grokking functional programming was one of those eureka! moments and it really felt natural. I still write a lot of functional stuff even in procedural/OO languages; Ruby lends itself well to that. But I agree with your larger point. One of the things that really blew me away about RoR was seeing someone implement a really good declarative security mechanism [writertopia.com] in about 300 lines. The Java version (JAAS) is an entire library that I never was able to fully figur

      • Re: (Score:3, Insightful)

        by kubalaa ( 47998 )
        That's a highly optimized algorithm. If you think that looks bad, check out the equivalent C code.

        typedef struct {
        int first;
        int second;
        } intpair;

        unsigned int sqr(unsigned int x) { return x*x; }
        intpair fibonacci(unsigned int nn) {
        intpair out;
        switch (nn) {
        case 0: out.first = 0; out.second = 0; return out;
        case 1: out.first = 1; out.second = 0; return out;
        ca

        • Yes, the algorithm is confusing. However, the C version is longer, but not *that* much longer. It also doesn't have any comically-long symbol names like multiple-value-bind. Granted, that's not an intrinsic problem with Lisp, only with ANSI Common Lisp, but prefix math is also difficult for humans to deal with. I don't know if it would be any easier if we learned math that way from the start, but I suspect it's just not how the human brain works.

          I like Lisp and Paul Graham's essays almost had me won over, b
      • ;;;
        ;;; Return (fib n) and (fib (+ n 1))
        ;;;
        (define (two-fibs n)
          (two-fibs-aux 0 1 n))

        (define (two-fibs-aux m n i)
          (if (zero? i)
              (values m n)
              (two-fibs-aux n (+ m n) (- i 1))))
    • I read that almost a year ago and its a great post. I agree with most of it yet still use Rails everyday. Notice in it he's giving an opinion about the future of Rails. However right now, its an amazingly productive framework to develop in if you're targeting startup web applications.

      To me the development tools for Rails is like a holy grail. Coming from .NET and Windows, switching all mac for Rails has given me a sort of coding nirvana that I didnt think possible. Developing code, writing tests, reusing ge
    • First let me disclose I that I have worked with Java web apps
      using Kiva, JRun, ATG Dynamo, Tomcat, Websphere, Spring Framework, JSEE. I have
      also worked Perl+CGI, a smattering of cold fusion, plain old php,
      drupal, cakephp (rails like php framework).
      I am currently working on deploying a rails app.

      So what is my take on Ruby/Rails?

      Briefly here are the pros/cons as I see it:

      pros:
      1) Ruby feels good to program in. Like Perl,PHP, or LISP you can
      layout data using the language itself. S
  • Oh I tought it was about a cooking on the rails, like those things trains run on
    but it is just about some programming thing
    me sad
  • I own both titles ("Rails Recipes" by Chad Fowler) and IMO neither does a great job -- there's nothing in this book not already covered by the definitive DT/DHH Agile Rails Development book. About the only redeeming value was the information on Mongrel and the detailed instructions to get Rails installed and running on all the different platforms.

    Speaking of which, though, the devoting of a good chunk of paper real estate to installation, seems to be space better left for meatier topics. Especially on a top

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close