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.
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 | |
| 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 |
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 Proc.new? The answer is that, if you *return* a value from the block passed to Proc.new, 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 amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'd recommend the Rails Cookbox instead (Score:4, Informative)
Re:I'd recommend the Rails Cookbox instead (Score:2, Informative)
Re:Good old RubyOnRails (Score:4, Informative)
But just look at a couple [rubyhitsquad.com] examples [robbyonrails.com] of why people run away from the community. (For those who don't know, the second example is DHH, creator of Rails.)
Re:Good old RubyOnRails (Score:3, Informative)
Rails is *nice*. I like it. I just don't get the obsession with it. And, let's be honest, it's not in widespread use. From a purely *financial* perspective, you're much better of learning the in-and-outs of something like ASP.net or PHP. Or, hell, even Perl. Those are all more widely used, and better supported.
Re:Good old RubyOnRails (Score:3, Informative)
Rails has paid my bills since 9/2005. And I'm a lot happier than I was coding Java.
It would pay the bills for two other people too, but we can't find anyone to take a full-time job in it. It seems that anyone who knows Rails right now in SF is contracting at $125/hr.
Not to say Rails doesn't have its problems as a technology and a community...
Re:Good old RubyOnRails (Score:3, Informative)
Also, I was a full-time rails developer for nine months.
Re:Good old RubyOnRails (Score:4, Informative)
Yeah. Those few lines of code that load the actual framework really muddy the waters. The fact that you're talking about "framework specific handlers" as an attempt to criticize a framework is a good indication to me that you've never tried Rails at all and just assume you're right about everything. If you never use any framework in any language, congratulations. On the other hand there are those of us who think a couple hundred K of memory used by persistent processes is worth significantly (by your own admission, perhaps 50%) reduced development time and thus cost.
As far as "indirection" via AR, if you don't want it you're free to not use it. It's one of the truly magnificent things about Rails. On the other hand if there's a particularly cumbersome query you're quite free to write it in raw SQL. There's a performance boost to be had there, yes. To the vast majority of web applications it's negligible, and that means that its benefits again outweigh its drawbacks. Rails isn't the perfect solution for EVERY project, but a handful of exceptions doesn't make it a bad rule.
Yet another irrefutable clue you made up your mind without ever bothering to try anything yourself. Or that you're a pompous ass, either way. Comparisons of scalability are ABSOLUTELY MEANINGLESS if you only provide one of the two items to be compared. Thus your statement is absolutely meaningless. Given the rest of your post, and your previous ones, that seems to be par for the course.
Rails handles scaling well. It probably handles less before it NEEDS to scale in MOST cases, particularly when it is (unfairly) compared to languages rather than other frameworks. If you really are on the border where Rails means you need an extra machine and (say) PHP doesn't, then maybe this is one of those areas where Rails isn't your solution. If you're already into the realm of needing to add hardware to handle load, Rails provides a lot of great solutions for doing that. And once again, it's going to be simple to implement.
I'm not simply talking out of my ass. I've worked on some projects for major clients including ESPN that were done in Rails and are humming along beautifully. Worse yet, some of these projects were extremely time-sensitive, by which I mean that most of the day they do very little work but when the work comes it comes in a huge swarm in a short time window. IE, the worst-case scenario as far as loading servers. It's still working fine, and we got to charge ESPN half as much as we would have for development of a PHP solution. They're already sending us more business, so I guess evil, evil Rails didn't destroy their company too badly. There are obviously many similar stories of huge sites working just fine on Rails, such as yellowpages.com.
To sum it up: Yes, a framework has some additional overhead compared to a simple language such as PHP. An interpreted language won't run as fast as a compiled language like Java or .NET (to bytecode). These are facts. What's in dispute is whether this makes a significant difference, and my experience with popular projects for major clients is that a well-coded Rails solution holds up fine.
You're right that development cost is sunk and electricity (and similar) costs are ongoing, but before that matters you have to be talking about MAJOR projects that are very probably billed minimum in the tens of thousands of dollars range and, realistically, probably over the hundred thousand dollar threshhold. At this point, your 100% more development time is a significant cost that is likely to take many years to balance. Even a $5,000 a year difference in marginal cost if you're talking a $25,000 or $50,000 difference in developemnt cost is
Threads workaround (Score:3, Informative)
Yes, it takes more effort to set up, but that also makes it really easy to scale since the component parts of a Rails deployment (Load Balancer / Web Server / App Server / DB Server) are each very scalable as isolated parts.
Really boring example of Rails money $100/hr (Score:4, Informative)
Could I have written it in PHP? Sure. Could I have done it as quickly? Probably not. The problem screams Rails Me -- little application, not all that much complexity (probably under 500 LOC outside of the view templates, which are 99% HTML), and its performance requirements are quite modest. (It typically deals with about a thousand visitors a day, although the application could chug through that in about 10 seconds in my tests, with caching turned off.) As for the exhorbitant hardware costs of the system, I was forced to move up from $7 shared hosting to a $20 VPS so that I could continue doing $1,500 in sales every month. Oh noes.
Anyhow, like I said, pretty boring. I anticipate, on the basis of the increase in traffic and trial downloads that I've had since launching, that the rewrite will be worth about $100 in additional profits for every hour I worked within the first two months. I keep adding new little features, too -- spent an hour yesterday adding Javascript graphs on the back end -- and it is some of the easiest web programming I've ever done. (I do Big Freaking Enterprise Apps in Java by day.)
Incidentally, a big "Heck yes" to parent when they said "The real money, however, is in developing your own stuff and then selling it on as a going concern." Why take a fraction of the revenue of your client's website once when you can operate the website yourself and take all of it on an ongoing basis. (And if it gets to be too much work, you hire out the boring stuff to folks who think $10, $50, or $100 an hour is a lot of money.)