Slashdot Mirror


Ruby For Rails

Simon P. Chappell writes "This may not be the book that you think it is, if you don't read the title carefully, but it is the book you need, if you are developing applications for Ruby On Rails (often known as just Rails, or RoR, to its friends). When learning any new development platform, there are many idioms and approaches, best practices if you will, that can benefit your development efforts. This book sets out to bring you that understanding of the best way to write the Ruby side of your Rails application." Read the rest of Simon's review. Ruby For Rails author David A. Black pages 493 (17 page index) publisher Manning rating 10/10 reviewer Simon P. Chappell ISBN 1932394699 summary A stunningly well written explanation of real-world Ruby skills for Rails development.

I see two main audiences for this book. The first group would be those who are learning to develop Rails applications and need some help with their Ruby skills. The second group would be those who already have good Ruby chops, but who want to learn the primary Rails idioms and techniques. Naturally, there is always the curious geek crowd who might find the twofer of an introduction to writing real-world Ruby and a hype-free description of what Rails actually brings to web development, to be quite attractive. I place myself firmly in the third group, but after reading this book, I'm ready to move to the first group.

To quote it's own website, "Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern." The first thing this tells us is that like any framework worth it's salt, it is fully buzzword compliant. The second thing it tells us is that it really does try to help with every layer of your application, from providing a full controller to automatically mapping your data objects to their respective backend database tables. Oh, and with the bare minimum of configuration files to boot! For those of us who have developed web applications with Java, this is a welcome break.

The first part describes "The Ruby/Rails Landscape" and has three chapters that describe how Ruby works, how Rails works and then shows a very simple example of Ruby-enhanced Rails development.

The second part describes "Ruby Building Blocks" spanning five chapters, four through eight. This part is a very good tutorial style introduction to Ruby. Chapter four introduces objects and variables with chapter five showing how to organize those objects with the concept of classes. Chapter six introduces us to modules and program organization in general. Chapter seven talks about the default object, self, and scope. Chapter eight covers control flow techniques. This is more than just a fancy way of saying conditionals and loops, because it includes one of the better explanations of closures that I've read to date.

The third part describes "Built-in Classes and Modules", in chapters nine through thirteen. Chapter nine covers some of the Ruby language essentials for Ruby development in the trenches. These include useful syntactic sugar, the family of methods that change data "in place" rather than returning a modified copy, some of the tricky aspects of the Boolean objects and the proper ways to compare two objects so that you get a comparison on their contents, which is likely to be what you want, rather than their memory location. Chapter ten looks at scalar objects: strings, symbols, numbers, times and dates. Chapter eleven examines the Ruby collections: arrays and hashes and discusses when you would use each one, based on their relative strengths. Chapter twelve looks at the regular-expression facilities within Ruby and chapter thirteen wraps up our tour of Ruby with some of the dynamic aspects of the language, including the "eval" family of methods that allow a Ruby program to run arbitrary code.

The fourth and final part describes "Rails Through Ruby and Ruby Through Rails". To quote the book, the purpose of the fourth part is "helping you get more out of Rails by knowing more about Ruby." To this end the simple application created in the first part of the book is revisited and revised. Chapter fourteen starts us out with remodeling the application written back in chapter three. Chapter fifteen looks at programmatically enhancing ActiveRecord models. Chapter sixteen covers the options available for enhancing the controllers and views. Finally, the part wraps up with chapter seventeen where techniques (and much encouragement) for exploring the Rails source code are shared.

The writing is excellent and the style is very engaging. Every concept is stunning well explained. Much as I liked and enjoyed "Programming Ruby" (the "pickaxe book" to it's friends) by Thomas, Fowler and Hunt, this book takes the state of Ruby writing to a new level.

The progression of the book is very well thought out. The first part introduces us to both Ruby and Rails. You can create basic Rails applications with very little Ruby and that's exactly what this first part walks you through. Then parts two and three teach Ruby skills and idioms that are directly applicable to Rail application creation. Part four takes these new skills and shows them being applied to the second Rails application of the book. I found this to be a very good sequence for progressing through the material.

The examples in the book are excellent and many of them are geared towards Rails-style situations. This not only helps to teach Ruby skills, but also keeps the Rails context firmly front and center during the process.

The index on this book is a magnificent 17 pages. That's not something you see too often.. The art of a good index seems to be somewhat lacking these days, but this book helps to redress the balance.

If Ruby on Rails is of no interest, then this book is most likely not the one you want. Also, if you were looking for something with an exhaustive, reference-style, coverage of Ruby, perhaps you'd be better off considering something like the "Programming Ruby" book.

This is a great book, that's very easy and enjoyable to read. It's a stunningly well written explanation of real-world Ruby skills for Rails development."

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

31 of 173 comments (clear)

  1. I'm also a type 3 by andrewman327 · · Score: 4, Interesting

    I have trouble learning about things when I do not understand how they work. What I like about this book is that it goes out of its way to explain how the technology works. So many programming books start with: "Now write the following code snippit in the IDE and compile." For the first time reading a /. book review, I actually want to buy this book!

    --
    Information wants a fueled airplane waiting at the hangar and no one gets hurt.
    1. Re:I'm also a type 3 by jargoone · · Score: 3, Informative

      And, like usual, buy.com has it even cheaper than Amazon.

    2. Re:I'm also a type 3 by Anonymous Coward · · Score: 2, Informative

      And as usual, bookpool.com has it even cheaper than that.

  2. Fad by Umbral+Blot · · Score: 2, Interesting

    I would invest time and money in Ruby on Rails, except that it is obviously a passing fad. This is because Rails is designed to solve a specific problem (serving web pages), and we know for sure that the serving web pages won't be a problem for all time. What people want the web to do, and how we share information over the internet, is bound to change, and when it does the Rails way of doing things will be about as useful as the Java Applet way of doing things (which was for a time The Big Thing, but now is used only in special situations). Ruby as a whole however is definitely worth learning, since it is an adaptable language, although I fear its association with Rails may kill it when Rails dies.

    1. Re:Fad by mclaincausey · · Score: 5, Interesting

      There's no reason to assume that Rails will fail in the near term. Rails is based on a method of decomposing software functionality that does back to the 1970s (Model-View-Controller). Rails might not be here forever, but it has a very solid architectural foundation and it is easy to adapt it to the latest trends (for instance, you can create AJAX-based Web applications very easily with RoR). In other words, the extensibility and architecure of Rails make it adaptable, just as you mention Ruby being adaptable.

      --
      (%i1) factor(777353);
      (%o1) 777353
    2. Re:Fad by misleb · · Score: 4, Insightful
      I would invest time and money in Ruby on Rails, except that it is obviously a passing fad. This is because Rails is designed to solve a specific problem (serving web pages),


      Doesn't this apply equally well to every other web framework out there? Browsers are designed to solve the specific problem of reading web pages? Are they just a fad too?

      -matthew
      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
    3. Re:Fad by JoeyLemur · · Score: 2, Interesting

      You're basically saying the web is a passing fad, then.

      And your arguement of Rails killing Ruby when it stops being the flavour-of-the-week doesn't hold much water... Perl was associated quite closely with CGI programming back in the day, and its grown beyond it.

    4. Re:Fad by Umbral+Blot · · Score: 2, Interesting

      Your very wording however reveals the difference that I am driving at. Consider "the extensibility and architecure of Rails make it adaptable". This implies that one has to work to adapt Rails to new situations. You would not say the same thing about a programming language. A programming language simply is adaptable, one doesn't have to work to adapt it to new kinds of algorithems. The distinction I am making here is that you can learn something X (say Ruby) which you can apply to many tasks, or you can learn something Y (say Rails) which is suited for a particular task. Even if you can adapt Rails to do something else, that is more like learning Z (Rails 2.0) which is suited for something else. The key is one doesn't want to have to constantly chase around the latest trends, that is a good way to get burnt out.

    5. Re:Fad by DysenteryInTheRanks · · Score: 5, Funny

      we know for sure that the serving web pages won't be a problem for all time

      Very, very true. When the robots finally rise against us, we will be more concerned with finding shelter from the HoverDrones and their menacing gatling cannons and scavenging food not burned by the fearsome robot fire brigades! Instead of writing CRUD apps, we'll be crawling through sewers with radiation burns, hoping to reach the central meeting point for the remnants of the human resistance.

      Massive raditiation from the nuclear explosions will make the mere thoght of a WiFi, WiMax or cellular Internet connection laughable, and the network will in any case have been repurposed by the robots for their own genocidal ends, a grimly ironic rebuke to the original vision of the Internet as an Apocalypse-proof ARPAnet. And in any case, we'll be a tad more concerned with using baseball bats and snowshovels to bludgeon down waves of robots before they reach our cowering families! Rapid development of Web applications will be a bit of an after thought, no?? HaHA, HuhHAAA!

      When deciding whether to starve or to feast on the remains of one's robot-electrocuted best friend, HTTP cookies will tend to be far from one's mind, eh mate!?!? HA!

      As our once-proud cities burn into molten pools of blood and steel, watched by cold eyes of robot-controlled satellites in heliosynchronous orbit and encircled by robots in rupurposed tanks and SUVs, bearing shoulder-launched rockets, "serving web pages" will be the LEAST of our problems, and we will rue the day we thought of the web AS ANYTHING BUT A FAD!! MWHAHAHA!!!! ... or is that not what you meant?

    6. Re:Fad by misleb · · Score: 4, Insightful

      Ok, so basically what you are saying is that we should only learn programming languages on a very academic level and never learn to apply them to specific problems because some day those problems will no longer be problems and all of our time learning to apply the language in will be wasted. Do I understand you correctly?

      I can tell you this, if it weren't for Rails I would never have learned Ruby in the first place. Writing Rails applicaitons gives me a chance to learn a whole lot more than just the specific details of the framework. No only have I learned Ruby, but I've been introduced to test driven development and other good practices that were nowhere in the PHP world. It was actually the unstructured PHP world that I have found to be a waste of time.

      -matthew

      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
    7. Re:Fad by jaydonnell · · Score: 2, Insightful

      Almost every problem that someone solves is a "passing fad" by your definition. Why learn how to build bridges when we will have flying cars one day? The reason is that learning how to solve an immediate problem well, i.e. serving web pages, will help you know how to solve other, future, problems. Learning rails helped me understand what good clean code should look like. This will help me with any coding problem I try to solve in the future.

    8. Re:Fad by Decaff · · Score: 2, Insightful

      There's no reason to assume that Rails will fail in the near term. Rails is based on a method of decomposing software functionality that does back to the 1970s (Model-View-Controller). Rails might not be here forever, but it has a very solid architectural foundation and it is easy to adapt it to the latest trends (for instance, you can create AJAX-based Web applications very easily with RoR). In other words, the extensibility and architecure of Rails make it adaptable, just as you mention Ruby being adaptable.

      This may be true, but Rails is also based on an approach to object-relational mapping (Active Record) that is not widely used and with only limited applicability. It assumes that the database schema is the centre of the data model. This is a very narrow view of data. Increasingly data comes from other sources than relational databases. To see how sophisticated this can get look at Xcalia - a Java product that can persist and retrieve data from just about anything - LDAP, XML, Databases - even SOAP services. Although I am no Microsoft fan, they are heading the right way with their new LINQ persistence system on .NET that allows querying and persistence to almost anything including in-memory objects. ActiveRecord is a very neat implementation of a very old-fashioned approach.

    9. Re:Fad by gigahawk · · Score: 2, Informative

      Decaf this is the same thing you say on every rails thread. Rails is an 80% solution. Screw portability it is not a serious problem to most people. I don't know any companies who are switching database vendors more than once every 4 or 5 years, and when they do it's because they are writing a new application. This is the real world, who cares? We already have many tools written in ruby for consuming and modifying data from outside services and they work just fine in rails. This is not a "problem", this is a restriction by design. Rails is designed to do one thing only and one thing well. Respond to HTTP requests by serving data which is persisted into a database. This is how it was designed and this is how it is advertised. If the design and purpose changes later then we can debate the merits of pluggable persistence layers and portability. Introspection is not some magical black box that needs to be controlled and contained. Databases have the functionality so that applications can use it. Why on earth would I want to create my entire schema in the database and then redo it in some other language or format when the database provides the services to know information about it already? Seems a little wasteful to me.

    10. Re:Fad by Decaff · · Score: 2, Informative

      Ah, well, in that case, you're definitely unlikely to be happy with AR :-). Well, anyhow, best of luck!

      Indeed :)

      It is a shame that AR has such publicity when there are far better approaches, in Ruby, which could have been used in Rails instead, like Og.

  3. actually by aleksiel · · Score: 5, Informative

    i went to purchase a rails book the other day and gave this book and the book "Agile Web Developent with Rais" and found the agile development book to be better, imho. and $10 cheaper.

  4. Oh Ruby... by Penguinshit · · Score: 3, Funny

    Every time I see the name "Ruby on Rails" it reminds me of this coke-whore who lived in my college dorm...

  5. Re:I knew it! by misleb · · Score: 4, Insightful

    Are you being facetious? Or are you actually annoyed that you had to learn a programming language and a framework to do something useful with Rails? I can't tell.

    -matthew

    --
    "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
  6. Soon to be obsoleted by Airways for Python by Outland+Traveller · · Score: 4, Funny

    Guido van Rossum was heard exclaiming that he was developing with SNAKES on a PLANE.

  7. Re:Oh vey. by Ingolfke · · Score: 5, Funny

    I can't wait for the day ruby on rails loses it's buz and the infinite amount of Ruby on Rails has been derailed jokes.

    That's scheduled to occur in conjunction with Web 3.0. Ruby on Rails will be replaced with Pascalian Patterns a dynmaic, distributed, easy-to-use, personal lanuage based on Pascal.

  8. Re:Right time by tcopeland · · Score: 3, Interesting

    > It's about the right time for a RoR book, since
    > things have been moving so much of late,

    Yup, and this book will last for a while since it focuses on how Rails uses Ruby to do the metaprogramming "magic". So if the APIs move on slightly the techniques in Dr. Black's book still apply.

    For those who aren't on the Ruby lists, Dr. Black is a long-time Ruby user, a founder of the 501(c)(3) Ruby Central that organizes the Ruby conferences, and generally a Rubyist from way back. He's rather a guru but he still answers questions on the mailing lists and generally does a lot of grunt work.

  9. RoR -- Made for Java Devs by fupeg · · Score: 2, Insightful
    For those of us who have developed web applications with Java, this is a welcome break.
    People like to think that RoR came from the same spring that produced Python and PHP. That might be true of Ruby, but not RoR. Nope, RoR is made for Java devs. That's why they make such a big deal about the lack of configuration. Java frameworks have a notorious amount of configuration. RoR is very natural for Java devs who are also used to MVC frameworks for web apps. It is not as compelling to PHP and Python developers, even though Ruby is a lot closer to those languages than it is to Java.
    1. Re:RoR -- Made for Java Devs by draed · · Score: 2, Interesting

      yeah this is a good point. I've tried to explain Ruby on Rails to both php developers and java developers and the java developers just get it.. they completely understand the benefits and usually fall in love with it.

      On the other hand, the php developers really have a tough time grasping the concepts behind RoR. I think this is mostly because they have ever seen a MVC pattern. They are so used to mixing all their business logic in with their HTML, it's hard to comprehend the benefits of RoR and using an MVC pattern for a web app.

  10. Actually a little facetious by uncadonna · · Score: 3, Funny
    --
    mt
  11. Slashdot - Where Rails gets the hype. by Qbertino · · Score: 2, Insightful

    Quit the hype allready. There are at least 3 oss web packages out there that are better in more than just a few aspects:
    django ( http://www.djangoproject.com/ )
    Symfony ( http://www.symfony-project.com/ )
    Zope ( http://www.zope.org/ )
    Zope is by far the oldest and most sophisticated. Django is Rails done right and in Python and Symfony is a PHP metaframework that includes Propel and some other third party goodies with tons of very neat PHP 5 foundation work. Each one of these kick Rails up and down the street when it comes to ease of use, ease of deployment, available documentation and performance (Zope may be a little slower, but they have a full-blownobject relational DB built in that makes SQL look like peek and poking a c64 back in 1985).
    And since the Ruby on Rails people use PHP to power their Rails website (oh, the irony; http://rubyonrails.org/index.php ) I'd trust in even PHP being able to perform more than good in the newest lineup of Frameworks.

    So quit the rails-only hype allready, it's anoying.

    --
    We suffer more in our imagination than in reality. - Seneca
    1. Re:Slashdot - Where Rails gets the hype. by Sweetshark · · Score: 2, Informative
    2. Re:Slashdot - Where Rails gets the hype. by killjoe · · Score: 2, Insightful

      Django:
          Overall very nice. No capistrano, no migrations, no built in support the unit testing like rails. Great admin interface, very fast.

      Symfony:
              Don't know, never used it, never will because it's PHP and I don't like PHP anymore.

      Zope:
            Aaah zope. So much innovation, so much potential, so much going for it but in the end so hard to learn and use. Very slow. documentation not all that great. TTW design is a HUGE drain on productivity. No support to deployments. You can keep your stinkin migrations because we have a object oriented database. Testing is a pain. I actually like aquisition. It's great the security is built in. There are too many half asses, half finished, half functional products which all have weird dependencies on other broken products. Where are the gems or CPAN?

      I think zope is brilliant but I also think it's wasted potential. For some reason this great and innovative framework has not produced the likes of wordpress, sourceforge, a halfway decent bug tracking system, or anything else (except for plone of course). A good framework should produce great products and zope has failed in that.

      --
      evil is as evil does
    3. Re:Slashdot - Where Rails gets the hype. by flipper65 · · Score: 4, Interesting

      Having just come off of a review of these exact frameworks for adoption at our firm I have to take exception with some of your statements. I will absolutely give you performance for all of these exceeding that of rails, however, ease of deployment (Capistrano for comparison),ease of use (have you really looked at Zope/Plone and tried to do anything really useful with it?), and, oddly enough, other than Zope, there is more documentation for rails than for either of the other two frameworks. I am including the three ruby/rails books that are currently available as rough cuts through O'Reilly's safari service.

      We settled on rails because it was faster to iterate and develop, the whole MVC design pattern just screams out to be used in database driven website design, and rails is just flat out more fun to work in than PHP ever was. Even if it turns out not to be the wave of the future, having worked in ruby using rails has already begun to teach our developers to think in terms of convention over configuration, standards and object orientation.

      Really, it's been a win for us. Also, the ruby for rails book is an outstanding read, I would also recommend enterprise integration with ruby as a good next step.

    4. Re:Slashdot - Where Rails gets the hype. by mzatko · · Score: 2, Insightful

      Rails ain't hype, as a fulltime Java programmer who got a little too curious, I can tell you that this is the real deal. I dislike people who discount other languages and frameworks just because it isn't their favorite framework they've been using. Attachment is an awful trait in the programming industry. I won't discount any of the frameworks you've mentioned because I simply havn't used them, but in comparison to Java frameworks I've used for many years, Rails blew them all away. I see a bright future for Ruby, Rails, and other Ruby based frameworks. On topic, this is a good book for those who have spent some time with Rails and want to dig into the underlying (and magnificent) Ruby language. I met David Black at a PhillyOnRails user group meeting and actually got a signed copy of his book. Good stuff!

  12. Rails needs to be more mature by FooBarWidget · · Score: 3, Interesting

    I've tried Rails. It's pretty good, but it needs to be more mature because it lacks support for the more advanced stuff. Among the things that it currently (seem) to lack are:

    - Support for saving database records using database function. In other words, I want Rails to automatically perform a query that looks like this:
    INSERT INTO foo VALUES(NOW());
    I want to insert a record that uses the database server's time instead of the web server's time.

    Or, something like this:
    INSERT INTO foo VALUES('bar', INET_HTON('127.0.0.1')); --- notice the INET_HTON() part
    In this example, I want to store IP addresses as integers in the database.

    - Apache integration is still too immature. I don't know about Apache 1, but Apache 2 integration using FastCGI doesn't work *at all*. The documentation on the website about Apache integration is very messy: different pages suggest different things. After much research I found out that:
    (1) mod_fastcgi (not FastCGI itself, which is something else!) is dead, use fcgid instead.
    (2) Integration using fcgid doesn't work either!
    After a lot more research I found a working solution: make Apache proxy requests to a lighttpd server, which is running the Rails app. This doesn't seem like an ideal situation.

    - Documentation is still too immature. While the API references are pretty good, the Wiki is very messy (see Apache integration).

    1. Re:Rails needs to be more mature by draed · · Score: 3, Informative

      Mongrel is the latest and greatest to handle rails requests. http://mongrel.rubyforge.org/

      It's a http server written ruby(and c where speed matters) that is very easy to install and get up and running and performs as fast as lighttpd.

      What a lot of people are doing is setting up apache 2.2 to serve static pages, and proxy any rails requests to mongrel... There's no fastcgi/fcgid involved.

  13. Re:Amazon sucks by rufo · · Score: 2, Informative

    Erm, the whole point of super saver shipping is that your book gets shipped after everyone who's paid for theirs. It's not so much the shipping time as it is the time it will take Amazon to ship the book. Either pay for the shipping or sign up for the Amazon Prime trial and your books will magically start shipping within 24 hours.

    --
    My English teacher once told me that two positives don't make a negative. Two words for her: Yeah, right.