Become a fan of Slashdot on Facebook


Forgot your password?

Advanced Rails 170

yukster writes "As Ruby on Rails rocketed into the development community's hearts and minds a few years ago, the number of books on the subject climbed with it. However, a lot of these books were introductory in nature (Agile Web Development with Rails, Beginning Rails, Build Your Own Rails Applications, etc.). What's a budding Rails-head to do once they've gotten the basics down? Books like Advanced Rails, which was released late last year by O'Reilly, aim to fill this void." Keep reading below for the rest of Ben's review.
Advanced Rails
author Brad Ediger
pages 357
publisher O'Reilly
rating 10
reviewer Ben Munat
ISBN 0596510322
summary Extensive reference for advanced topics in Ruby on Rails development
Author Brad Ediger has been kicking around the Rails scene since the pre-1.0 days. Though not a Rails "luminary" necessarily, he certainly qualifies as an advanced user. He is CTO for a Real Estate tech company called Tasman Labs and runs a web design (and Rails consulting) firm called Madriska Media Group. He seems like a sharp cookie and a decent writer.

Advanced Rails covers quite a bit of territory, going for breadth rather than depth most of the time. Each chapter covers a classic, pivotal development concern... well, at least most of them do. The chapters are as follows:

1. Foundational Techniques
2. ActiveSupport and RailTies
3. Rails Plugins
4. Database
5. Security
6. Performance
7. REST, Resources, and Web Services
8. i18n and L10n
9. Incorporating and Extending Rails
10. Large Projects

By "Foundational Techniques", Ediger is referring to Ruby and Rails techniques, principals and patterns like Metaprogramming, Don't Repeat Yourself, and Functional Programming techniques. The chapter also goes into a fair amount detail about the Object/Class/Module relationship. A bunch of this may not be particularly new material for most Rails users who've been at it for at least a few months. However, it's still nice to have all this stuff in one forty page chapter... good to have handy to refer to. Also, there are some nice nuggets in there that could save you some head-scratching. For example, what's the difference between Kernel#lambda and The answer is that, if you *return* a value from the block passed to, the calling method is exited as well, abandoning any code that you might have after it.

If the first chapter feels like it's leaning towards a reference work, the second chapter — which digs into all the goodies offered by ActiveSupport and RailTies — pretty much falls over right into reference-land, complete with a method-by-method listing of features added to standard library classes. This may seem even more like just putting api docs available online into print, but Eidger definitely adds a bit more explanation. And, I haven't really seen anyone give a rundown of just what the heck RailTies does. That's the library that provides the glue to pull together the more famous Rails libraries to make it all work together as rails: generators, initializers, etc. There is definitely some interesting and not necessarily readily available information here.

Chapter three covers Rails Plugins, and is quick and painless. It explains the common files and directory structure in a plugin and talks about how Rails loads them. It also talks about using Piston instead of svn:externals to manage plugins and show some example plugins.

The following three chapters cover more of the classic eternal problems faced in running high-traffic sites: databases, security, and performance. These really make the most sense in an "advanced" book; they are the "brass tacks" that everyone must get down too if they go beyond the "toy app" stage. Ediger talks about the strengths and weaknesses of the various popular database systems. He also goes into the benefits of using the filesystem to store data, which is largely because web servers can make use of fast system calls to dump files straight into the TCP socket. He also covers some advanced db features like composite keys, stored procedures and clustering.

The security chapter isn't all that long and a lot of the info it covers can be found in beginner Rails books... SQL injection, cross-site scripting etc. However, the book would be remiss to not include this material and it is presented in a concise and complete manner. This would be good to refer back to now and then to make sure you haven't slipped in your security awareness. Ediger also doesn't hesitate to make specific recommendations, like "whitelist rather than blacklist".

He also jumps right into recommendations while writing about performance optimization in the next chapter: "Algorithmic improvements always beat code tweaks", "As a general rule, maintainability beats performance", "Only optimize what matters", "Measure twice, cut once". He then goes on to cover specific tools and techniques for uncovering your bottlenecks, from a quick explanation of basic statistics to using httpperf, benchmark, and Rails Analyzer Tools, improving database calls (using indexes and "include" on finders), and the various caching solutions. There is plenty of good information in this chapter; also a good bit of reference next time you need to track down a logjam.

Chapter seven covers RESTful Rails, from the very basic theory as outlined by Roy Fielding to exactly how Rails has chosen to use these concepts, and is the longest chapter in the book. The amount of coverage REST gets seems questionable since Rails has been very heavily into the RESTful approach for over a year and embraced the philosophy so thoroughly that it's hard to imagine anyone using Rails today without being exposed to the concepts.

On the other hand, one can still wire up verb-oriented actions in routes.rb and might be able to get away with ignoring all the RESTful goodness. So maybe there are some out there that can benefit from this chapter. Plus, having such thorough, theory-to-practice coverage allows the chapter to stand on its own as a solid reference to the whys and hows of RESTful Rails. It also has one of the better sections on RESTful routing that I have seen (routes being one of the more mysterious and sometimes frustrating pieces of Rails).

Rails has gotten plenty of grief for its lack of official support for Internationalization and Localization, but in Chapter eight, Ediger lays out the options, such as gettext, Gibberish, and Globalize. He is most enthusiastic about this last library and it does appear to be quite powerful, including support for translating strings, translating model fields, localizing numbers and dates, and even recording what needs to be translated by saving them in the database. Creating multi-lingual websites is a hard problem in any web-development framework and most other frameworks have plenty of head start. However, Ruby and Rails certainly isn't without options and it will only get better.

The next to last chapter of Advanced Rails runs through a number of alternatives to the standard components of the Rails framework. On the database end, it covers DataMapper, Ambition, and Og, giving this last one the most attention. For alternatives to ERB templates, Ediger talks about Markaby, Liquid and Haml, all in a very brisk fashion. He also talks about using traditional Rails components — like ActiveRecord and ActionMailer — outside of Rails applications. The chapter closes with a discussion of how to contribute to Rails (hint: submit a patch... don't just bitch!).

The last chapter is called "Large Projects" and covers some useful information about working on a Rails project with a team, beginning with version control (though anyone who is writing code that covers more than a single file and *not* using version control is just plain insane). This starts with a quick overview of Subversion, however this feels like it is really a set up for making a case for "decentralized version control". Ediger does a good job of explaining these concepts, using Mercurial for his examples. This seems a bit unfortunate, since many people on the Rails core team have embraced Git and it is looking like Rails will eventually move its repository to Git. However, Mercurial has a reputation of being more user-friendly, so that may have influenced his decision. And it's useful information regardless.

Chapter ten continues on to discuss avoiding migration numbering collisions, issue tracking, keeping Rails and required gems within a project, web servers, load balancers, production architecture and deployment tools like Capistrano. This is all covered in a fairly quick fashion so don't expect a lot of depth.

That last sentiment came up often while reading this book. It often felt like Ediger was trying to get every possible Rails-related topic into the book that he could, but didn't want to come out with some 1000-page behemoth. Plenty of the topics mentioned don't have much more coverage than you could get with a quick "googling". However, there is something to be said for being exposed to a lot of tools, projects and concepts in one go, even if the exposure is sometimes superficial. I definitely found reading this book worthwhile and will keep it around to refer back to now and then. I don't know if I'd go so far as to label it required reading, but then again books on web frameworks rarely are.

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

Advanced Rails

Comments Filter:
  • by moore.dustin ( 942289 ) on Monday March 17, 2008 @04:28PM (#22777034) Homepage
    The summary of the last chapter titled 'Large Projects' only adds to my worry about using RoR for a large project. Horror stories, these are the only stories I have heard from anyone trying anything close to what I would consider 'large' projects. Glancing over the Contents I was hoping that the last chapter would provide some insight into overcoming the pitfalls RoR has with larger project. It does not really sound like the author recognizes what many others have already found; RoR is not the right tool for many significant sized project, especially in the enterprise environment.

    Perhaps the fellow readers can give some more insight into this?
  • by Anonymous Coward on Monday March 17, 2008 @04:28PM (#22777044)
    I picked up this book a couple of months ago when it was first released. Although a J2EE and .NET developer by trade, I do try to keep abreast of new technologies. I must say, I was quite disappointed by this book.

    The book isn't poorly written, and the information it conveys is useful to some people, I'm sure. But I don't consider the topics it covers to be "advanced" by any means.

    Using triggers and rules, for instance, are not really advanced concepts. Nor are plugin-based architectures. REST techniques are pretty basic, as well.

    I was hoping for this book to really discuss pushing RoR to the max, allowing us to do what we can't currently do easily with J2EE or .NET. But that didn't happen, thus leaving me disappointed.

  • by DJ Jones ( 997846 ) on Monday March 17, 2008 @04:41PM (#22777164) Homepage
    Everyone is always quick to bash RoR but I have honestly never heard a well crafted explanation as to why it's an inferior language / framework. I personally use Java, but that's only because I was raised on it.

    So I ask: Why the bashing?
  • by Standard User 79 ( 1209050 ) on Monday March 17, 2008 @05:17PM (#22777492)
    Not a well crafted explanation but: 1. Can't use threads, framework is not thread safe. This opens up all sorts of problems. i.e. uploading,persistent connections,complex webservices, etc.. 2. Difficult to administrate. Compared to other frameworks, Rails requires a lot more work to set up/administer and seems to crash a lot. 3. Per #1 and #2: Doesn't scale well. It's still a nice solution for a lot of things. But I imagine most of the bashers are developers who got burned when they found out rails develops well but administrates poorly.
  • by devjj ( 956776 ) on Monday March 17, 2008 @05:18PM (#22777500)

    There's a simpler reason for bashing Rails: it's a threat. It's just that simple. Any time something comes along that can feasibly put market pressure on existing technologies, there's going to be bashing.

    Rails pays my bills. I honestly don't give a damn what anyone else thinks if it's meeting my clients' needs. Simple as that.

  • I was hoping for this book to really discuss pushing RoR to the max, allowing us to do what we can't currently do easily with J2EE or .NET.

    From what I can say, there's still some things that RoR routinely does more easily than J2EE or .NET -- it's just that good ideas tend to propagate, so I suspect it's not as dramatic a difference anymore.

  • by glwtta ( 532858 ) on Monday March 17, 2008 @05:23PM (#22777554) Homepage
    Why is that spamming, really? I mean, he did make a detailed recommendation, if people choose to buy it based on that recommendation, isn't that the point of the system?

    The price is the same for those buying it. I don't see what the problem is.
  • by SanityInAnarchy ( 655584 ) <> on Monday March 17, 2008 @05:23PM (#22777564) Journal
    This is one book review. In what way is it hype?

    I'm seeing more Anti-Ruby/Rails FUD here than pro-Ruby/Rails hype.

    Would you say the same thing if it was a .NET book being reviewed?
  • by Sancho ( 17056 ) on Monday March 17, 2008 @05:38PM (#22777708) Homepage
    Never underestimate the power of buzzwords and glitzy technology? Managers love shiny things!
  • by Anonymous Coward on Monday March 17, 2008 @06:14PM (#22778068)

    Yawn. Humorless idiot.

    There was nothing whatsoever in the original post to suggest that it was supposed to be humorous. Being funny is more than just saying something false and flaming anyone who calls you out on it.
  • by Anonymous Coward on Monday March 17, 2008 @06:29PM (#22778212)

    There's a simpler reason for bashing Rails: it's a threat. It's just that simple.

    There's an element of truth here, just not the one you think there is. I don't want to lose work because some naive client buys into the unfounded bullshit surrounding RAILS. My apps will take twice as long to develop but will be cleaner, tighter, scale better and I probably won't be that much more expensive either. I can't go insulting clients by saying that straight out, not after they swallowed the horseshit you and other RAILS fanbois manage to spout at every possible opportunity!

    So the threat is that we (established freelance developers) may be forced to learn this cookie-cutter, paint-by-numbers framework to keep clients happy. That hurts when we understand full well that the better engineered solution would have been courtesy of Java, ASP.NET or even PHP.

    Small shops offering RAD are not the sole preserve of RoR fans and honestly if the community cut the hype and bullshit they wouldn't be getting called on it. Oh and fuck DH too, initial programming work is a more or less sunk cost but hardware, connectivity, and power [] are not (AKA: DH, meet inflation you fool!).

  • by devjj ( 956776 ) on Monday March 17, 2008 @06:59PM (#22778412)

    You honestly think that any app you write is going to be better than its analog built in Rails? That you are a better developer in your chosen language/framework than every other Rails developer on the planet?

    And you call Rails guys arrogant?

  • by devjj ( 956776 ) on Monday March 17, 2008 @07:25PM (#22778610)

    And upon what do you base this claim? The fact you're directly comparing Rails (a framework) to PHP (a language) is telling. It'd make a lot more sense to say "I think any app written in Rails could be written better in CakePHP" although that claim is obviously rather dubious, as well. To be truly appropriate, you ought to talk Ruby vs PHP. And if you get to that point you're going to have to justify what "better" actually means. What it means to you isn't what it's going to mean to anybody else and vice versa.

    In the end, this debate ends up being Mac vs PC vs Linux vs Whatever. Everyone's got their opinions. What works for you is the right solution for you.

  • by TimHunter ( 174406 ) on Monday March 17, 2008 @08:48PM (#22779166)
    Here's a thought: Don't like what other people are submitting? Take the time to review a book about your favorite tech and submit it.

Adapt. Enjoy. Survive.