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.
Re:Good old RubyOnRails (Score:5, Interesting)
Re:Good old RubyOnRails (Score:3, Interesting)
Also, a friend's company now has more Rails projects coming through the door than Java ones.
Here's a nice post [pivotallabs.com] from a company doing more than just paying the bills.
Please O PLEASE stop the Ruby hype (Score:2, Interesting)
Re:Good old RubyOnRails (Score:4, Interesting)
Required reading (Score:3, Interesting)
> as to label it required reading
I've been doing Rails for about two years and still found this book to be very helpful. It should be called "Rails For Real Projects" or something, because he covers stuff you _will_ run into. The nice thing about this book is that he doesn't waste time explaining what 'puts' does and such; he gets right down to business. The section on modifications that Rails makes to the Ruby standard library is worth the price alone.
Re:Good old RubyOnRails (Score:5, Interesting)
Re:Good old RubyOnRails (Score:1, Interesting)
the best community support of *any* open source web development framework out there
I have to say that the community is by far the biggest thing that makes me run away screaming from Rails. The clue:ego ratio is dire compared with Django or TurboGears. It's like the Rails hype siphoned off all the immature assholes from surrounding platforms. Every time I read anything about Rails, I subconsciously hear it in the tone of voice teenager gamers use when flaming each other about which console is best. Other communities, on the other hand, just shut up and get it done, for the most part.
Re:Chapter 10 - Large Projects (Score:3, Interesting)
Is there any sort of evidence for this? All I'm hearing is that RoR is having a lot of trouble scaling with complexity.
Which makes sense, since it's designed to make really trivial applications really easy to write - nothing wrong with that, really, it's a useful niche.
Rails and its ilk really emphasize the start-up cost, those first couple of days that are essentially irrelevant in a large project.
Re:Chapter 10 - Large Projects (Score:4, Interesting)
> trying anything close to what I would consider 'large' projects.
I've found that Ruby has a way of making large projects into small ones. Going from 250 KLOC in Java to 10 KLOC in Ruby would not surprise me.
> RoR is not the right tool for many significant sized project, especially in the enterprise environment.
Most enterprise environments are a morass of battling departments, entrenched legacy technologies, and outdated, inefficient processes. While that significant-sized 30 person project is bogged down for two months negotiating more app server licenses, the 3 person Rails team can knock out a fully tested application that does the job.
Re:Good old RubyOnRails (Score:3, Interesting)
I find this argument amusing every time I hear it. Those in the Rails community are often called arrogant for insisting on things being done "The Rails Way", when it's often your own arrogance that won't allow you to do something any other way. In either case, it's the people you have a problem with. There are far fewer legitimate complaints about the Rails Framework than there are about Rails people. You can dissociate yourself from the people and still have a capable framework.
If you don't want to do things "The Rails Way" you're free to use whatever works for you. If you don't want to use ERB write your own template system. Don't like AR? Don't use it. Sure, it's harder to go without, but if you've got a good reason for doing things a certain way you're free to do things as you wish. It's not like DHH is going to come pounding on your door because you didn't do things his way. He's an opinionated guy -- most of us (Rails devs or not) are.
The only reason to bitch about "The Rails Way" is if you're too lazy to figure out how to do it your way.
Re:Good old RubyOnRails (Score:3, Interesting)
I agree entirely, although occasionally some of the more arrogant things that I don't agree with make it into the Rails Framework.
So far, enough people think like me that it hasn't been a problem -- there's always a plugin or set of scripts somewhere to help me out. A recent example: Schema Validations. While not all validations can be reflected in the database schema, some can, and arguably, it is a Good Thing for stuff to be validated by Rails before it hits the database. You should never have an error coming back from the database about exceeding a VARCHAR(255), but do you really want "validates_length_of :foo, 255" everywhere?
It gets even worse when your database supports real foreign keys. Sure, they'll break down with polymorphism, but won't you still have a large number of relationships for which foreign keys would make sense?
Fortunately, there's a plugin [redhillonrails.org] for that, and another [redhillonrails.org] if you use real foreign keys.
But this, combined with "Convention over Configuration", means that it is very often not possible to do what you want without either performing deep surgery on Rails (not always possible in a plugin, so expect to maintain it yourself if your patch is rejected), or, as in your example, scrapping a chunk of the framework altogether.
And if you have to scrap a large chunk of the framework, or the entire framework, is there really any point in claiming to be a Rails developer anymore? Maybe at that point, you'd be better off with a framework like Merb [merbivore.com], which, I'm told, is much more hackable than Rails. In fact, the very concept of Rails itself (stay on the rails) goes against software reusability, to some extent.
All that said, I don't have anything particularly painful right now -- I'm developing a Rails app, full-time, and I'd be lying if I said I didn't like it. But the point is, it's not always laziness -- sometimes it is the framework making a particular way of doing something as hard as possible, on purpose. (Example: Google "syntactic vinegar.") Sometimes, it's not on purpose, but it is there -- these don't bother me so much, because I can always try sending a patch. (Example: Ever try extending an AssociationProxy after it's been created? Don't. But believe it or not, there is a use for that.)
has anyone really gotten RoR to scale? (Score:1, Interesting)
Can some kind soul explain REST? (Score:3, Interesting)
But what's the excitement all about? I would think that for most site owners, this would be a disaster, not a boon.
It sounds like a graven invitation for others to do stuff with your site
Furthermore, it seems like something that makes trying to break your site much easier since crack efforts can be done using standard methods for which the weaknesses are well known. So some smart guy can find a weakness in the REST code and all of a sudden everyone who's followed the rules can be automatically exploited.
Google encourages you to use their maps, because it builds loyalty to them, and you are probably using their ad network anyway so they don't lose much revenue. But for most sites, mashups are going to virtually eliminate revenue, cost bandwidth and overall make your life miserable. They are the modern equivalent of linking to images on someone else's site
So tell me, what does REST do for me, as a site owner and developer, as opposed to what it does for others, such as people creating mashups and the like?
Are there any ways in which mashups can be made profitable or worth encouraging, for people who don't own their own ad networks?
D
Re:Good old RubyOnRails (Score:3, Interesting)
You make some good points about Rails's flaws, although I'd argue that many of them are related to ORM in general and have less to do with ActiveRecord's implementation than the concept as a whole. Your mention of "interpreted" gives me pause, as it almost sounds like you're arguing that interpreted languages are inherently flawed. I'm not say that's what you're saying, but I think you can see how that could be, well, interpreted.
Of the things you pointed out, I'll candidly say that Rails deployment is perhaps the area where it is most apparent that in the grand scheme of things Rails is still something of a baby. It has (arguably) matured fairly rapidly, but there are certainly areas where there is still room for improvement. Given the sheer bullishness of the core team I'd like to think we're going to continue to make significant progress in this regard. One of the biggest problems Rails faces today is deployment in shared hosting environments, but to say it can't scale is simply false [rubyonrails.org].
As I've noted in prior comments, your problem with Rails has far more to do with some of the people who use it and less with the code itself.
Re:Good old RubyOnRails (Score:3, Interesting)
This is where Groovy and Grails comes in. I just attended a conference with a bunch of Java developers and the Groovy/Grails sessions were all packed, and they were the talk of the show. Everyone was really excited about it.
It's amazing how two small things - making it syntactically similar to Java and making it use existing J2EE infrastructure - all of the sudden makes Java developers think it's the greatest thing in the world.