Slashdot Mirror


Rails Recipes

James Edward Gray II writes "If you have been swept up by the Rails craze or are even just a casual fan, you have probably been waiting for the terrific books to start rolling in. Some early entries, like Agile Web Development with Rails, were very solid but for me greatness arrived with Rails Recipes. For those who are not familiar with it, Rails is a full-stack web application framework, for quickly developing state-of-the-art web applications. Rails Recipes is the latest book on the subject from the Pragmatic Programmers." Read the rest of James's review. Rails Recipes author Recipes pages 299 publisher The Pragmatic Programmers rating Excellent reviewer James Edward Gray II ISBN 0-9776166-0-6 summary A programming cookbook for all things Rails.

Let me tell you how I discovered Rails Recipes. At the Rails shop I work for, we needed a favorites system for our latest application. When I inherited the task of implementing favorites, I had heard just enough to guess that the new polymorphic associations feature of Rails might be just what I needed. Sadly, I had never even seen an example of their usage. Before leaving work that day, I checked the table of contents to make sure a recipe for what I needed was in there and and bought a combo pack, so the PDF would be waiting for me in the morning. The next day I built the entire favorites system and integrated it into our application with only the book as my guide. Total time for implementation, from cracking the book to a complete solution: just over three hours.

Needless to say, the book had completely won me over by that point. I started sneaking in recipe reads whenever I had a free moment or two and had literally devoured the book in no time. I completely expected it to show me cute AJAX tricks and handle common issues like login code and it certainly does these things. It also covers popular plugins, including Acts as Taggable and Acts as Versioned, as it should. What I didn't expect was for the book to include so many excellent low-flash coding recommendations as well. There are terrific recipes for DRYing up your code in various circumstances, building your own output forms for views, how to use models in migrations even if the files are long gone, integration testing as a DSL, routing methods, code generation, and a whole lot more.

The book has some surprising depth to the Rails insights it provides, not because the recipes are long but more because the topics are well chosen. Even the small "Snack Recipes" generally dive right to the heart of a commonly encountered matter. You get typical solutions and often some tips on how to customize the relevant Rails behaviors. For example, the book covers how to add inflections Rails can use in its singular/plural text transformations and how to tie your own form building classes right into the standard Rails helper methods.

I'm a long time Ruby user and I consider myself fairly knowledgeable with regard to the language, but this book taught me new tricks. I've read the Pickaxe, but for some reason IRb sessions never sunk in for me until this book showed the perfect example of using the on an ActiveRecord model to create a Ruby syntax database shell. The book even taught me some great YAML tricks for use in fixtures and configuration files.

Now I realize I've been gushing a little, so let me to balance it with at least some words of caution. First, this book assumes you know Rails. You will not learn Rails here. This should not be the first Rails book you read, though it does make an ideal second read and daily reference. I should also note that the recipe sections seem pretty arbitrary to me. I expected to find the login discussion in the "Big-Picture Recipes" section and the console tips in "Database Recipes", but they are located elsewhere. This might be a minor challenge for those who try to thumb straight to a recipe, but I've found searching the PDF makes this a non-issue. (The paper version of the book does have nice tabs drawn on the edge of pages to lead you to recipe types though, unrelated to the sections.) Finally, I should note that I've gone hunting in the book for about four work projects now, and found all but one. It didn't cover Acts as Threaded usage. Obviously it is impossible for a single book to answer all your questions about Rails, but a 75% ratio seems like a great start to me!

There are 70 recipes in this book split among user interface, database, controller, testing, big-picture, and email categories. I must stress again though how well these recipes pack in the tips. Don't be at all surprised if you learn an applicable view layer or even pure Ruby trick in a database recipe.

If you are a Rails user, I must recommend you pick up this title immediately. I really believe there is something in here for all.

You can purchase Rails Recipes from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

27 of 153 comments (clear)

  1. Sounds better than most "recipe" books by Salvance · · Score: 2, Insightful

    I typically dislike the "recipe" books available, as most of them seem to only touch about 10% of what I'm actually interested in. However, this book sounds better, maybe this is because the projects I'd be interested in using Ruby on Rails for are far simpler than most projects I undertake.

    --
    Crack - Free with every butt and set of boobs
  2. It's nice for little things. by FatSean · · Score: 2, Informative

    But a serious, multi-site web-based application that spans continents is going to require something a bit more robust.

    Since I'm always being told to build big things, I just couldn't get into Ruby/Rails.

    Maybe for a personal site or something.

    --
    Blar.
    1. Re:It's nice for little things. by tcopeland · · Score: 2, Insightful

      > Because it's not compiled, it seems like it's not a
      > good idea for really large projects either.

      Hm, I think if you're doing a large site - e.g., multiple app servers - the speed at which the language's opcodes are processed won't be the bottleneck. It'll be database queries or the network connections or something like that.

      Anyhow, it's working pretty well for us so far...

    2. Re:It's nice for little things. by resonantblue · · Score: 4, Interesting

      Because it's not compiled, it seems like it's not a good idea for really large projects either. You wanna bet? Look at 37signals which successfully runs large projects on Rails. It's not compiled, but neither is PHP. Since Rails runs as a persistent app, in a production environment, it only loads most of the application into memory once. At that point, in all practicality, you will hardly ever run into performance bottlenecks that can't be fixed by scaling out.

      Admittedly, Rails debugging tools cannot compare to those of .NET or J2EE, but the issue of being compiled will hardly ever come up in practicality.

      really couldn't find any reason why I'd want to use it above PHP Cause it's a fully integrated framework. Try using plain, vanilla PHP and see how much boilerplate code you write to connect to your database, to retrieve data, to implement Ajax. Then tell me how easy it keep your code clean and modularized when you start to build up your site. And don't even get me started on building automated tests into your application. I used use PHP exclusively, but I've never looked back.

      As a side note, there are some frameworks in PHP now that can compare to the Rails way of doing things (like CakePHP or Symphony). I still prefer Ruby as a language, but those frameworks seem pretty decent. However, I don't think you can compare pure vanilla PHP to Rails.

      Here's why I didn't like it. If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing. Yeah, the whole thing about writing good, clean code is pretty annoying. If you're ok with writing shitty code, then by all means, don't ever use Rails :-)

      -Aamer
    3. Re:It's nice for little things. by smallpaul · · Score: 4, Interesting

      What makes you think that software needs to be "compiled" for large projects? Yahoo is primarily delivered with PHP. Amazon.com is largely Perl. MySpace is largely ColdFusion (migrating to .NET). Yahoo: http://www.internetnews.com/dev-news/article.php/1 491221 Amazon: http://en.wikipedia.org/wiki/Mason_(Perl) MySpace: http://www.tomasbecklin.com/cf/

    4. Re:It's nice for little things. by misleb · · Score: 3, Informative
      If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing.


      Single web page? That isn't a small project... that is a TINY project.

      Because it's not compiled, it seems like it's not a good idea for really large projects either.


      So you don't see any applications somewhere between a tiny project and a large enterprise application? Seems to me that most applications fit in this area. Blogs, forums, CMS, all kinds of things. An intranet is a great place for rails apps.

      I really couldn't find any reason why I'd want to use it above PHP,


      For one thing, PHP is an ugly language with a hacked together object system and terrible function naming. Ruby blows PHP away as far as scripting languages go. And then add Rail on top of it which totally takes advantage of Ruby's features.

      I did PHP for a while, but after writing an app in Rails for first time, I didn't want ot touch another line of PHP again. If I need to throw some simple dynamic content on a website, I'll resort to PHP because it is so readily available, but beyond that, forget it. I won't waste my time.

      and it doesn't really have the qualities needed to take on something like Java or .Net.


      You fail to see the huge space between PHP and Java.

      -matthew
      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
    5. Re:It's nice for little things. by prockcore · · Score: 2, Insightful

      "Premature optimization is the root of all evil (or at least most of it) in programming."
      -Donald Knuth


      Well I'd counter with "thinking you can always optimize later is the root of Open Office"
  3. Johnny Come Lately Books by Super+Dave+Osbourne · · Score: 2, Interesting

    Rails has been around for a while, and the books are all pretty good (bought 5, read 5, returned 5)... The only book really worth reading to any seasoned MVC or Morphic programmer is the Getting Started with Rails... The rest are really just rehash on MVC which is so dated we should all look carefully at why Rails is so special to the masses in the first place.

    1. Re:Johnny Come Lately Books by hal2814 · · Score: 4, Funny

      The late-90's called. They want their OSS-applies-to-everything philosophy back. Hold on a minute. I have another call... ...Oh, the 90's called again and they want this joke back, too. I have to go now.

  4. James' Books by Super+Dave+Osbourne · · Score: 2, Interesting

    James is a good guy, and knows his Mac crack. Guys has been alive and well in the community for 3 years, and is a great guy with the Ruby Quiz. Conflicting publisher (or not) his views are almost always well thought out and valid, regardless of how silly and useful the Quiz is :) Glad to see James has a TextMate book coming out with Oreilly. In all, the book itself (the Rails Recipes) is about a 7-8 out of 10 mac strokes.

  5. This shouldn't be your first Rails review, either by 14erCleaner · · Score: 4, Interesting
    From the review:

    Now I realize I've been gushing a little, so let me to balance it with at least some words of caution. First, this book assumes you know Rails. You will not learn Rails here.

    Actually, I could hardly read your review, since it was so crammed with non-standard jargon (at least, from my perspective as a longtime C++/Java programmer). Lighten up on the Ruby-specific buzzwords, please! "how to use models in migrations", "integration testing as a DSL", "great YAML tricks for use in fixtures", huh???? It's nice that the book taught you how to do those things, whatever they are, but maybe a review should relate these things to more normal (non-Ruby) programmers' experiences in common language somehow.

    --
    Have you read my blog lately?
  6. How is this possible? by Anonymous Coward · · Score: 5, Funny

    From the review:
    I started sneaking in recipe reads whenever I had a free moment or two and had literally devoured the book in no time.

    Okay, so what he's saying is he literally ate the book and, moreover, he ate the book in literally 0.000 seconds.

    I conclude the reviewer lacks basic literacy or vocabulary skills. Literally.

    1. Re:How is this possible? by Anonymous Coward · · Score: 2, Funny
      Okay, so what he's saying is he literally ate the book and, moreover, he ate the book in literally 0.000 seconds.

      I conclude the reviewer lacks basic literacy or vocabulary skills. Literally.


      I further conclude that the reviewer was REALLY hungry.

  7. You keep using that word... by elcid73 · · Score: 2, Informative
    ...and had literally devoured the book in no time.

    I do not think it means what you think it means.

    Sincerely
    -Inigo Montoya

    1. Re:You keep using that word... by Best+ID+Ever! · · Score: 4, Funny

      No he actually devoured it -- eating books is the latest tenet of eXtreme Programming.

  8. Equivalent framework for Python by defile · · Score: 4, Informative

    Since I'm already familiar with Python and use it on a daily basis, my experience with Ruby has been pretty limited. This puts Ruby on Rails just out of my reach for a new project.

    Thankfully, there's I guess what you'd call a rough equivalent, Django which is the first framework I've ever used that hasn't frustrated the hell out of me.

    You've got no excuses left, check it out.

    1. Re:Equivalent framework for Python by dankelley · · Score: 2, Interesting

      Well, there is an excuse left, if you're a PHP programmer looking for a replacement (be that django or rails) -- it's the issue of how to deploy the sucker.

      I might be like some others reading this thread. I'm familiar with PHP and I'd like to switch up to something more elegant.

      But there's a roadblock when it comes to deployment.

      With PHP, it's simple -- your test machine is probably set up already, and your deployment webserver almost certainly is. With Rails and Django, you're in a spot of trouble, since it's quite likely that neither your development machine nor your deployment webserver is set up. It's not trivial to just install "mod" modules to get Rails and Django to work, and you have to own root permissions to do that.

      So, a typical user can start creating PHP sites easily, but these wonderful frameworks are a bit difficult. Is it worth the effort? Well, I've only looked into Django in any detail, and I think the answer is "yes", but I'd sure love to see the folks who are writing the Django book drop whatever chapter they are writing and move on to the deployment chapter. That test server they keep talking about is just not very helpful. I need something that I can leave running (efficiently) so that I can get user feedback on my site. The little server they provide, and describe carefully in their document, it's a screwdriver and I need a hammer.

    2. Re:Equivalent framework for Python by fishbowl · · Score: 2, Insightful

      >This puts Ruby on Rails just out of my reach for a new project.

      Here is the thing you should realize: There are people out there who have never written a line of code in any language,
      who have picked up Rails and put together a webapp on day one. Within a few hours of the first tutorial.

      Lots of people who do graphics and layout, who have historically needed someone else to do the programming for them,
      seem to have discovered Rails -- and are using it rather successfully.

      I have seen this phenomenon with my own eyes. Went to a Rails convention expecting to meet programmers. Hotel was filled with creative-graphics-types, business-development types, you name it. Sure, there were programmers, but shockingly large numbers of non-programmers who were simply using Rails to make their webapps. They find it liberating.

      If you are a programmer who makes a living doing, say, Servlets and JSP work, this should scare you to death.

      It does me.

      --
      -fb Everything not expressly forbidden is now mandatory.
  9. a glossary by sammy+baby · · Score: 4, Informative
    To address your specific areas of confusion:
    • "How to use models in migrations" - Rails uses the "Model-View-Controller" structure for application architecture. It also offers scripts which automate the creation of new models: basically, you type "script/generate model modelname", and it drops in files for model code, unit tests, et cetera. Rails also offers a method for making updates to your application's database schema called "migrations." Every time you generate a new model, it will also create a dummy "migration" into which you can enter the code necessary to update your database, regardless of the specific type of database you're running (Informix, MySQL, Oracle, Postgres...).
    • "Integration testing as a DSL" - In Rails parlance, an "integration test" is a test which spans multiple models, controllers, and views. DSL, or "Domain Specific Langage," is a buzzword which basically means "a language specifically tailored to a certain task." It refers to the phenomenon some that Rails code, especially the integration test code, doesn't really scream "I am a Ruby program" to you - the method calls have evolved to the point where they look like a whole new language perfectly suited for a specific task. (That's the claim, anyhoo.)
    • "Great YAML tricks for use in fixtures - YAML stands for "YAML Ain't Markup Language." It's a very simple way of representing data structures in text. Rails uses YAML for unit test fixtures: that is, your testing database can be populated with information from YAML files. Interestingly, the test fixtures can have Ruby code embedded directly in the YAML, enabling you to do stuff like iterate over hundreds of similar items. The embedded Ruby code is what makes the "great YAML tricks" possible.


    Hope this helps.
    1. Re:a glossary by SiliconEntity · · Score: 2, Insightful

      Thanks, now please explain:

      Acts as Taggable
      Acts as Versioned
      low-flash coding
      DRYing up your code
      routing methods

    2. Re:a glossary by sammy+baby · · Score: 4, Informative
      My pleasure.

      • acts_as_taggable
      • Acts as Versioned - see above, but allows you to have multi-versioned objects, instead of tags.
      • DRYing up your code - slang. DRY stands for "Don't Repeat Yourself." DRYing up your code, therefore, is making sure that you haven't duplicated code unnecessarily.
      • routing methods - methods that govern how a Rails application will choose a controller and method based on a URL. The "default route" in most Rails applications is "controller/method/id", meaning if I were to submit a GET request for "http://railsthingy.net/photos/view/101", the application would attempt to call the "view" method from the "photos" controller, with an argument "id=101".
      • low-flash-coding - this... um. Well. You got me, dude.
    3. Re:a glossary by number6x · · Score: 3, Informative
      • low-flash coding - The 'flash' is a small area that keeps things around until the next transaction. You should use it just to pass error messages from a failure of some type. Some programmers try to get tricky and use the flash as a psuedo session. Rails supports sessions fully and you should use the session for your needs. Getting tricky is usually a sign you don't really know what your doing in Rails.
  10. Re:This shouldn't be your first Rails review, ... by aiosx · · Score: 2, Interesting

    Lighten up on the Ruby-specific buzzwords, please! "how to use models in migrations", "integration testing as a DSL", "great YAML tricks for use in fixtures", huh???? It's nice that the book taught you how to do those things, whatever they are, but maybe a review should relate these things to more normal (non-Ruby) programmers

    Most of those _are_ 'normal' terms.

    Models are a fundamental part of the MVC design pattern (which originated in 1979, so it isn't exactly a rails buzzword!), integration testing is part of general software testing, usually used in combination with unit testing, and YAML is a markup language (sort of). They aren't Ruby or Rails specific.

    Don't assume you know all the 'normal' terms simply because you don't consider yourself a newby. You sound like one of those programers who think they know it all... boy are those a pain to work with. They're almost always the ones that know the least.

  11. Re:Rails schmails by ^Case^ · · Score: 2, Insightful

    The parent is right now modded funny. Actually I believe he's right on target. Rails _is_ slow. Very slow. Compared to whatever other framework / language you might be wanting to implement your web applications in. That is executing a Rails app is slow.

    The development time on the other hand is amazingly short. You can go from zero to app in times you would only dream of coming from a PHP or Java world. I personally can only vouch for PHP, but there's plenty of Java people out there who will tell you the same.

    So the question is: Do you value execution speed or developer time more? To me developer time is more expensive than hardware so I prefer shorter developer time. And yes, Rails does scale - at least enough for my purposes.

  12. Re:Must Every Submission Read Like a Marketing Slo by chromatic · · Score: 2, Funny

    No kidding! I can't think of the last book review I read that didn't mention some sort of product for sale, usually a book!

  13. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  14. Re:Buying the PDF? by larry+bagina · · Score: 2, Informative

    Slashdot has a linking agreement with barnes & noble (check the faq, under book review guidelines). BN.com might be 5-15% more expensive than amazon or bookpool, or almost anywhere else (except a physical barnes & noble), but according to VA Software's SEC 10Q reports, they get $20k/year kickback from it.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.