Planet RubyOnRails

wnoronha: Fun with Google Video Chat

wnoronha — Wed, 19 Nov 2008 22:01:48 -0600

daniel: Delayed Gratification with Rails

daniel — Wed, 19 Nov 2008 20:35:00 -0600

In which Daniel Morrison covers how to install and use delayed job, a rails plugin that encapsulates the common pattern of executing longer tasks in the background.

pelle: Agree2 is now officially launched

pelle — Wed, 19 Nov 2008 20:29:16 -0600

Goodbye Fax, Goodbye Fedex, Goodbye Mont Blanc pens… Hello Agree2.

What started as a proof of concept prototype in creating agreements roughly 2 years ago is now officially launched. We have been in beta for a long time, but now we feel the time is right to lift the beta tag and introduce our commercial plans.

But first let me explain what Agree2 is all about. Plain and simple we are all about helping you reach agreement.

See the Agree2 launch Post for more information or go straight to Agree2 to sign up.

Create, negotiate and accept legally binding contracts for free with our Agree2 service.

wnoronha: Butane Lighter and Cigarette Case

wnoronha — Wed, 19 Nov 2008 08:25:47 -0600

ryan: What's New in Edge Rails: Application.rb Duality is no More

ryan — Wed, 19 Nov 2008 01:36:00 -0600

Ever wonder why your ArticlesController has to live in a file called articles_controller.rb but that special ApplicationController gets to hang out in application.rb? Well no more.. That snooty little controller will now live in application_controller.rb and abide by the same naming restrictions that the rest of us do.

As you can see by the comments, by the time this is in a stable Rails release there will be upgrade help. However, for those of you on Edge Rails, you’ll need to make this change yourself.

tags: ruby, rubyonrails

brian: Rubinius is a community project

brian — Tue, 18 Nov 2008 22:03:00 -0600

Yesterday was a tough day. You can read the details and Evan’s thoughts about it.

It was especially hard for me because Wilson was a mentor of sorts and the first person I talked to when I dropped into the #rubinius channel nearly two years ago. He allayed any fear I had that Rubinius would fragment the Ruby community and helped me get started contributing.

And Eero, among many other things, jumped on board right away and toiled for many hours on the early specs, putting up with my dead ends when the project that is now RubySpec was merely an expedient to fast-track Rubinius development.

So, I want to express my thanks to my teammates and wish them the best in their next endeavors. And I want to emphasize something that is well known to those of us who have worked hard on Rubinius from long before Engine Yard began to support the project: Rubinius is a community project.

Evan’s free-flowing commit bit, the early adoption of Git, and the emphasis on writing specs while developing are just a few aspects that have helped propel Rubinius very quickly in its couple year history. And there is still plenty of exciting and interesting work to be done. We are all very grateful for Engine Yard’s support of the project, and that support remains strong and dedicated.

But the key to Rubinius’ success is the community. In the past year, I feel we have to some extent let you, the community, down. We need to make Rubinius even easier to try out, understand, and contribute to. And we need your feedback on ways we can do this. The recent VM rewrite has been a huge step forward in this regard. But have you opened up the code, poked around, asked us about stuff that doesn’t make sense? If you haven’t, let us know why not. Have you taken a look at a failing spec for the core library? There’s tons of beautiful Ruby code just begging for some love. Let us know what barriers prevent you from spending some free time in there.

If you’re worried that development on Rubinius will slow down, I would challenge you to not let that happen. Evan produces prodigious amounts of code and has a terrific mix of genius and pragmatism. I will certainly not be working any less hard than I have for the past two years. So if you, like me, believe that Rubinius can be a terrific platform for Ruby, jump in. No contribution is too small. And we’re building on a solid foundation of past success.

ryan: What's New in Edge Rails: Default Scoping

ryan — Tue, 18 Nov 2008 21:51:00 -0600

It’s pretty common to want SQL queries against a particular table to always be sorted the same way, and is one of the reasons why I added the ordered scope to the utility scopes gem. For instance, when dealing with collections of articles it is reasonable to expect that the default ordering be most recent first, i.e. created_at DESC. Well now you can specify default ordering, and other scopes, in edge rails directly in your ActiveRecord model.

Taking our Article example let’s specify the aforementioned default ordering:

123	class Article < ActiveRecord::Base default_scope :order => 'created_at DESC'end

Now, when any find method or named_scope is executed the default ordering comes along for the ride:

Article.find(:all) #=> "SELECT * FROM `articles` ORDER BY created_at DESC"

The same holds true for any named scopes you might have:

class Article < ActiveRecord::Base
  default_scope :order => 'created_at DESC'
  named_scope :published, :conditions => { :published => true }
end

Article.published #=> "SELECT * FROM `articles` WHERE published = true ORDER BY created_at DESC"

There are some things to keep in mind, however. First is that scopes like :join, :offset, :limit and :order will get clobbered by the innermost rule. For example, here the default scope ordering loses out to the named_scope ordering.

class Article < ActiveRecord::Base
  default_scope :order => 'created_at DESC'
  named_scope :published, :conditions => { :published => true },
                          :order => 'published_at DESC'
end

# published_at DESC clobbers default scope
Article.published
    #=> "SELECT * FROM `articles` WHERE published = true ORDER BY published_at DESC"

Also keep in mind that the default scoping is inherited, so child-classes of Article will have the same default scoping.

And for those occasions when you want to override or remove your default scope, just use with_exclusive_scope:

class Article < ActiveRecord::Base
  default_scope :order => 'created_at DESC'
end

# Ignore other scoping within this block
Article.with_exclusive_scope { find(:all) }  #=> "SELECT * FROM `articles`

default_scope is a great way to specify reasonable query defaults and relieve yourself of having to create your own named_scopes for that purpose or specify such conditions at every invocation. Yes, I just said ‘relieve yourself’... giggity giggity

tags: ruby, rubyonrails

michael: Potential Circumvention of CSRF Protection in Rails 2.1

michael — Tue, 18 Nov 2008 18:13:00 -0600

There is a bug in all 2.1.x versions of Ruby on Rails which affects the effectiveness of the CSRF protection given by protect_from_forgery.

By design rails does not perform token verification on requests with certain content types not typically generated by browsers. Unfortunately this list also included ‘text/plain’ which can be generated by browsers.

Impact

Requests can be crafted which will circumvent the CSRF protection entirely. Rails does not parse the parameters provided with these requests, but that may not be enough to protect your application.

Affected Versions

All releases in the 2.1 series
All 2.2 Pre Releases

Fixes

The upcoming 2.1.3 and 2.2.2 releases will contain a fix for this issue.

Interim Workarounds

Users of 2.1.x releases are advised to insert the following code into a file in config/initializers/

Mime::Type.unverifiable_types.delete(:text)

Users of Edge Rails after 2.2.1, should upgrade to the latest code in 2-2-stable.

The patch for the 2.1.x series is available on github. This will also apply cleanly to 2.2 pre-releases prior to this changeset released on Thursday November 13th at 11:19:53 2008 CET. Users with edge-rails checkouts after that date, are advised to upgrade to the latest code in 2-2-stable.

bsag: Shadow sister

bsag — Tue, 18 Nov 2008 18:10:06 -0600

[Something I wrote in my head at the end of last week, cycling home.]

The bright full moon is floating down the river, trembling and fractured by the breeze. A rider's lamp behind me spawns my shadow sister, moving in front of me, solid and hunched against the chill. She weaves left and right, now skimming across the grass, now sliding over the gravel path. I'm fascinated by my projected self, encountering the future ahead of me, but keeping me company on this cold, dark night.

Eventually, the rider passes me. My shadow sister slows then disappears, and I feel a sudden ridiculous pang of loss for something which was just a trick of the light. Despite knowing how she was born, I find myself looking for her for the rest of the journey, wondering if she's around the next corner, or waiting for me in the trees.

Gilbert Guttmann: My ideal Spaces setup

Gilbert Guttmann — Tue, 18 Nov 2008 17:49:58 -0600

When Apple announced Spaces for Leopard, I was not that excited. I've never been a fan of Virtual Desktops because I thought they would just distract rather than offer any use. You know, another one of these neat looking toy features. I was so wrong.

David: New Rails 2.2 i18n defaults

David — Tue, 18 Nov 2008 13:44:00 -0600

I just reduced the housework needed to setup a new Rails application with i18n. All new applications will ship with a config/locales directory that’s automatically wired up in the load path for i18n. So you can just drop .yml or .rb locale files in there and they’ll be instantly available for translation.

There’s also a sample config/locales/en.yml file in there to give you a starting point. In addition, the initializer is now wired up through the Rails config. The new default environment.rb provides these pointers:

# The internationalization framework can be changed 
# to have another default locale (standard is :en) or more load paths.
# All files from config/locales/*.rb,yml are added automatically.
# config.i18n.load_path << Dir[File.join(RAILS_ROOT, 'my', 'locales', '*.{rb,yml}')]
# config.i18n.default_locale = :de

So on a fresh Rails 2.2 application, you’ll be able to do see it all wired up out of the box (the :hello key is from the config/locales/en.yml demo file):

$ ./script/console
>> I18n.t :hello
=> "Hello world"

Rails 2.2 final is just around the corner. We’ve been ironing out the last bugs and added the last amount of polish to make this a kick ass release. Also, work on 2.3 / 3.0 has already begun in master as well since we’ve branched for 2.2 a while back.

Graeme Mathieson: Rubaidh’s new office sign

Graeme Mathieson — Tue, 18 Nov 2008 11:55:27 -0600

Rubaidh Ltd has recently moved in to new offices in Musselburgh, and this morning I came in to discover that the folks who run the building have put up a sign for our office. Shiny, eh? While I’m posting, I’d like to welcome Mark Connell, the newest member of Rubaidh’s team. He is a [...]

chad: Scotland on Rails Call for Proposals

chad — Tue, 18 Nov 2008 04:51:00 -0600

Being an organizers of Ruby conferences myself, I always enjoy going to the regional conferences. I’ve been to the Mountain West RubyConf, Ruby Hoedown and Rails Summit Latin America. Each was excellent in its own unique way. It’s also a great pleasure for me to attend a conference I’m not organizing.

So I’m looking forward to the upcoming Scotland on Rails in March. Marcel and I will be presenting a tutorial for charity at this year’s conference.

I’ve heard great things about last year’s Scotland on Rails, and I trust my friends in Scotland to put on an excellent show. If you haven’t been to Edinburgh, you owe yourself a trip. It’s an incredibly beautiful city.

What better way to explore new lands than to do it by invitation as a speaker? Scotland on Rails has opened its Call for Proposals (it’s been open for a while, but I’m slow). The CFP closes in 2 weeks (December 1st), so if you’re interested in speaking don’t be late. From what Alan tells me, they are especially interested in hearing how to do BIG projects with Ruby and Rails.

Hope to see you there.

Jamis: Vim Follow-up

Jamis — Mon, 17 Nov 2008 19:09:00 -0600

So, it’s been over a month and a half since I switched back to Vim, and I figured I’d post a bit about how things are going.

I love it. Though the future is notoriously difficult to foretell, I think it’s safe to say that I won’t be switching editors again anytime soon. Vim is where it’s at, for me.

Here’s the combination of plugins and such that I’ve found work best for me.

dhh: Myth #6: Rails only speaks English

dhh — Mon, 17 Nov 2008 11:35:00 -0600

It used to be somewhat inconvenient to deal with UTF-8 in Rails because Ruby's primary method of dealing with them was through regular expressions. If you just did a naïve string operation, you'd often be surprised by results and think that Ruby was somehow fundamentally unable to deal with UTF-8.

Take the string "Iñtërnâtiônàlizætiøn". If you were to do a string[0,2] operation and expected to get the two first characters back, you'd get "I\303" because Ruby operated on the byte level, not the character level. And UTF-8 characters can be multibyte, so you'd only get 1.5 characters back. Yikes!

Rails dealt with this long ago by introducing a character proxy on top of strings that is UTF-8 safe. Now you can just do s.first(2) and you'll get the two first characters back. No surprises. Everything inside of Rails uses this, so validations, truncating, and what have you is all UTF-8 safe.

Not only that, but we actually assume that all operations are going to happen with UTF-8. The default charset for responses sent with Rails is UTF-8. The default charset for database operations is UTF-8. So Rails assumes that everything coming in, everything going out, and all that's being manipulated is UTF-8.

This is a long way of saying that Rails is perfectly capable of dealing with all kinds of international texts that can be described in UTF-8. The early inconveniences of Ruby's regular expression-based approach has long been superseded. You need no longer worry that Rails doesn't speak your language. Basecamp, for example, has content in some 70+ languages at least. It works very well.

But what about translations and locales?
It was long a point of contention that Rails didn't ship with a internationalization framework in the box. There has, however, long been a wide variety of plugins that added this support. There was localize, globalize, and many others. Each with their own strengths and tailored to different situations.

All these plugins have powered Rails applications in other languages than English for a long time. Some made it possible to translate strings to multiple languages, others just made Rails work well for one other given language. But whatever your translation need was, there was probably a plugin out there that did it.

But obviously things could be better and with Rails 2.2 we've made them a whole lot more so. Rails 2.2 ships with a simple internationalization framework that makes it silly easy to do translations and locales. There's a dedicated discussion group, wiki, and website for getting familiar with this work. I've been using it in a test with translating Basecamp to Danish and really like what I'm seeing.

So in summary, Rails is very capable of making sites that need to be translated into many different locales. Before Rails 2.2, you'd have to use one of the many plugins. After Rails 2.2, you can use what's in the box for most cases (or add additional plugins for more exotic support).

Don't forget about time zones!
Dealing well with content in UTF-8 and translating your application into many languages goes a long way to make your application ready for the world, but most sites also need to deal with time. When you deal with time in a global setting, you also need to deal with time zones.

I'm incredibly proud of the outstanding work that Geoff Buesing lead for the implementation of time zones in Rails 2.1. It's amazing how Geoff and team were able to reduce something so complex to something so simple. And it shows the great power of being an full-stack framework. Geoff was able to make changes to Rails, Action Pack, and Active Record to make the entire experience seamless.

To lean more about time zones in Rails, see Geoff's tutorial or watch <a href=http://railscasts.com/episodes/106"">the Railscast on Time Zones.

See the Rails Myths index for more myths about Rails.

jnunemaker: HappyMapper, Making XML Fun Again

jnunemaker — Mon, 17 Nov 2008 07:10:00 -0600

In which I show that XML does not have to suck—instead you can just HappyMap it!

ben: The New(ish) Bleything.net

ben — Mon, 17 Nov 2008 06:16:00 -0600

While I’m completely sure that nobody ever goes to bleything.net, I have nevertheless put far more time than is necessary or reasonable into it over the past couple of weeks.

Inspired by my former LiveJournal coworker David Recordon, I added “recent activity” updates to bleything.net. It now shows you my recent tweets (with @s filtered out), my recent FireEagle updates, and GitHub activity.

There’s more coming, but I’ll save that for when I actually release it. I’m still working on the relaunch of this blog, but I’ve gotten sidetracked in javascript wankery. Once everything’s done and the dust has settled, I’ll be doing a series on all the code I wrote for this round of site updates… there’s some fun stuff involved.

As a preview, here’s a snippet of the script that fetches updates from GitHub:

when /CommitEvent/
  update_hash[ :type      ] = 'GitHubCommit'
  update_hash[ :commit_id ] = update.links.first.href.split( '/' ).last
  update_hash[ :target    ] = update.title.txt.match( /\w+\/\w+/ )[0]
  update_hash[ :text      ] = Hpricot( update.content ).at( '//p[2]' ).inner_html.strip
when /DeleteEvent/
  update_hash[ :type   ] = 'GitHubDelete'
  update_hash[ :target ] = update.title.txt.match( /\w+$/ )[0]
when /ForkEvent/
  update_hash[ :type   ] = 'GitHubFork'
  update_hash[ :target ] = update.title.txt.match( /\w+\/\w+/ )[0]
when /FollowEvent/
  username     = update.title.txt.match( /\w+$/ )[0]
  profile_page = Hpricot( open("http://github.com/#{username}") )
  realname     = profile_page.at( "span#profile_name" ).inner_html.strip

  update_hash[ :type   ] = 'GitHubFollow'
  update_hash[ :target ] = username
  update_hash[ :text   ] = realname
when /WatchEvent/
  update_hash[ :type   ] = 'GitHubWatch'
  update_hash[ :target ] = Hpricot( update.content ).at( '//a' ).inner_html.strip

Look for more soon!

dhh: Myth #5: Rails is hard because of Ruby

dhh — Sat, 15 Nov 2008 20:10:00 -0600

I've talked to lots of PHP and Java programmers who love the idea and concept of Rails, but are afraid of stepping in because of Ruby. The argument goes that since they already know PHP or Java, that it would be less work to just pick one of the Rails knockoffs in those languages. I really don't think so.

Ruby is actually an amazingly simple language to pickup the basics on. Yes, there's a lot of depth in the meta programming corners, but you really don't need to go there to get stuff done. Certainly not to get going. The base mechanics of getting productive takes much shorter than you likely think.

After all, Ruby is neither LISP nor Smalltalk. It's not a completely new and alien world if you're coming from PHP or Java. Lots of concepts and constructs are the same. The code even looks similar in many cases, just stated more succinctly.

Learn Ruby in the time it would take to learn a framework
I'd argue that most programmers could get up and running in Ruby in about the same time it would take them to learn another framework in their current language anyway. I know it sounds a lot more scary to learn a whole new language rather than just another framework, but it really isn't.

The number one piece of feedback I get from people who dreaded the jump but did it anyway is: Why didn't I do this sooner?

Learn while doing something real that matters to you
Also, speaking from my own experience learning Ruby, I'd actually recommend trying to do something real. Don't just start with the basics of the language in a vacuum. Pick something you actually want done and just start doing it one step of the time. You'll learn as you go along and you'll have to motivation to keep it up because stuff is coming alive.

So don't write off Rails because you don't know Ruby. Your fears of starting from scratch again will quickly make way for the joy of the new language and you'll get to use the real Rails as a reward. Come on in, the water is fine!

See the Rails Myths index for more myths about Rails.

tobi: Passenger

tobi — Sat, 15 Nov 2008 18:14:00 -0600

So there is a lot of talk about Phusion Passenger lately and I feel the need to chime in here. David pointed out that Shopify is running on passenger which is something I announced on Twitter a few months ago.

Some context on Shopify’s installation: We launched Shopify originally on Lighttpd with FastCGI and later migrated to nginx with mongrels. Obviously we had to use HAProxy between Nginx and mongrels to avoid the dreaded “queue behind long running process” problem. We also added Monit to the mix which observed all mongrels to make sure that everything is running according to plan. After a process reaches 260 mb of memory we signal it to shut down after the next request so that a new one can start out with less memory. For this we added runit to the mix which supervises the mongrels and starts them up quickly once they hit the ground.

It’s important to note that we are not talking about a memory leak here. The reason for the 260mb ceiling comes from two issues with Ruby’s garbage collector:

It allocates memory in very large chunks once the available memory gets low. This means a 140mb process increases to 260mb in a single go. It also never gives memory back to the operating system because Ruby’s GC is not able to move objects. Once it adds an object into the newly allocated space and that object remains alive, it cannot yield memory back to the OS.
Because Ruby’s garbage collector uses mark and sweep it has to traverse the entire memory space in search of pointers. There are no generations that help with that. It means that GC cycles become longer and longer the more memory is available. ~~-Rails mitigates these issues by moving a full GC run behind a HTTP response, into the time period when the process is waiting for a new request~~ (Update: Rails doesn’t do this anymore) but performance monitoring tools such as NewRelic clearly show that average response times is directly correlated with the amount of memory used across the server farm.

Now why did we switch to Passenger? Simple: the keyword is remove moving parts.

Every additional tool you add will come with it’s own bugs. Many people I talked to over the past years considered haproxy to be the most solid piece of infrastructure in their stack but even there was a really nasty bug recently (search for request queue handling).

We treat our server farm very similar to Shopify’s codebase. We are in this for the long haul and we cannot accept complex solutions when simple ones present themselves. Maintainability of our code and servers is paramount to the long term success of our product. Yes the Mongrel setup worked very well but Passenger allowed us to remove: Nginx, Haproxy, Runit and Monit. That’s a nice refactoring!

At the same time Passenger introduced some tangible improvements. We switched to enterprise ruby to get the full benefit of the COW memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices. We allow Passenger to adaptively spawn more processes with demand but most of the time our application servers are running about 40 processes to handle more than a million dynamic requests a day. However, because passenger constantly despawns and respawns rails processes they always stay fresh, run short GC cycles and are generally a lot more responsive. All this means that the total amount of memory that is used by Shopify during normal operations went from average of 9GB to an average of 5GB. We evenly distributed the savings amongst more Shopify processes and more memcached space which moved our average response time from 210ms to 130ms while traffic grew 30% in the last few months.

In conclusion: I cannot see any reason to choose a different deployment strategy at this point. Its simple, complete, fast and well documented.

dhh: Myth #4: Rails is a monolith

dhh — Sat, 15 Nov 2008 15:11:00 -0600

Rails is often accused of being a big monolithic framework. The charges usually contend that its intense mass makes it hard for people to understand the inner workings, thus making it hard to patch the framework, and that it results in slow running applications. Oy, let's start at the beginning.

Measuring lines of code is used to gauge the rough complexity of software. It's an easy but also incredibly crude way of measuring that rarely yields anything meaningful unless you apply intense rigor to the specifics. Most measurements of LOCs apply hardly any rigor and reduces what could otherwise be a somewhat useful indicator to an inverse dick measurement match.

Applying rigor to measuring LOCs in Rails
The measurements of LOC in Rails have not failed to live up to the low standards traditionally set for these pull-down-your-pants experiments. Let's look at a few common mistakes people commit when trying to measure the LOCs in Rails:

They count all lines including comments and whitespace in Ruby files, thus punishing well-documented and formatted code
They count tests, thus punishing well-tested code
They count bundled dependencies, thus punishing dependency-free code

Now let's take a simple example of committing all these mistakes against a part of Rails and see how misleading the results turn out to be. I'm going to use Action Mailer as an example here:

12,406 lines including comments, whitespace, tests, and dependencies
7,912 lines including tests and dependencies
6,409 lines including dependencies (t-mail and text-format)
667 lines with none of the above

So the difference between committing all the mistakes and reality is a factor of 20. Even just the difference between committing the dependency mistake and reality is a factor of 10! In reality, if you were to work on Action Mailer for a patch, you would only have to comprehend a framework of 667 lines. A much less challenging task than digging into 12,406 lines.

Rails measured with all it's six major components without the mistakes is 34,097 lines divided across Action Mailer at 667, Active Resource at 878, Active Support at 6,684, Active Record at 9,295, Action Pack at 11,117 (the single piece most web frameworks should be comparing themselves to unless they also ship as a full stack), and Rail Ties at 5,447.

Looking at the monolithic charge
That Rails is big in terms of lines of code is just one of the charges, though. More vague and insidious is the charge that Rails is monolithic. That is one giant mass where all the pieces depend on each other and are intertwined in hard-to-understand ways. That it lacks coherence and cohesion.

First, Rails can include almost as much or as little of the six major pieces as you prefer. If you're making an application that doesn't need Action Mailer, Active Resource, or Active Record, you can swiftly cut them out of your runtime by uncommenting the following statement in config/environment.rb:

# config.frameworks -= [ :active_record, :active_resource, :action_mailer ]

Now you've reduced your reliance on Rails to the 23,248 lines in Action Pack, Active Support, and Rail Ties. But let's dig deeper and look at the inner workings of Action Pack and how much of that fits the monolithic charge.

Taking out the optional parts
The Action Controller part of Action Pack consists of 8,282 lines which breaks down into two major halves. The essential, stuff that's needed to run the bare minimum of controllers, and the optional that adds specific features, which you could do without.

First the essentials of which there are 3,797 lines spread across these files and directories: base.rb, cgi_ext, cgi_ext.rb, cgi_process.rb, cookies.rb, dispatcher.rb, headers.rb, layout.rb, mime_type.rb, mime_types.rb, request.rb, response.rb, routing, routing.rb, session, session_management.rb, status_codes.rb, url_rewriter.rb.

The more interesting part is the optional parts of which there are 3,481 lines spread across these files and directories: assertions, assertions.rb, benchmarking.rb, caching, caching.rb, components.rb, filters.rb, flash.rb, helpers.rb, http_authentication.rb, integration.rb, mime_responds.rb, performance_test.rb, polymorphic_routes.rb, rack_process.rb, record_identifier.rb, request_forgery_protection.rb, request_profiler.rb, rescue.rb, resources.rb, streaming.rb, test_case.rb, test_process.rb, translation.rb, verification.rb.

All these optional parts can actually very easily be turned off as well, if you so please. If you look at actionpack/lib/action_controller.rb, you'll see something like the following:

ActionController::Base.class_eval do

  include ActionController::Flash

  include ActionController::Benchmarking

  include ActionController::Caching

  ...

This is where all the optional bits are being mixed into Action Pack. But they didn't need to be. If you really wanted to, you could just edit this 1 file and remove the optional bits you didn't need and you'd have some 3,500 lines of optional goodies to pick from.

For example, let's say you didn't need caching in your application. You comment the include ActionController::Caching line out and delete the associated files and that's 349 lines for the savings there. Or let's say that you don't like the flash, that's another 96 lines.

The reason many of these pieces can be optional is because of a wonderful part of Active Support called alias_method_chain. With alias_method_chain, you can latch on to a method to embellish it with more stuff. For example, the Benchmarking module uses alias_method_chain like this to hook into perform_action and render:


module Benchmarking

  def self.included(base)

    base.extend(ClassMethods)

 

    base.class_eval do

      alias_method_chain :perform_action, :benchmark

      alias_method_chain :render, :benchmark

    end

  end

ActionController::Base declares render and perform_action, but doesn't know anything about benchmarking (why should it?). The Benchmarking modules adds in these concerns when it's included similar to how aspects work. So as you can see, alias_method_chain is a great enabler for clearly defined modules in Rails.

All the other frameworks in Rails works in a similar fashion. There's a handful of essential parts and then a handful of optional parts, which can use alias_method_chain if they need to decorate some of the essential pieces. This means that the code is very well defined and you can look at just a single piece in isolation.

But why on earth would you bother?
The analysis above of how you can bring Action Controller down to some 3,500 lines carefully side-stepped one important question: Why would you bother? And that's an answer I don't quite have for you.

The important part about being modular is that the pieces are understandable in isolation. That the individual modules have coherence and cohesion. Not that they're actually handed to you as a puzzle for you to figure out how to put together.

I'd much rather give someone a complete picture, which they can then turn into a puzzle if they're so inclined. As I've shown you above, it's actually really simple to deconstruct the frameworks in Rails and you can make them much smaller really easily if you decide that's a good use of your time and energy.

See the Rails Myths index for more myths about Rails.