• 什么是消息队列（Messaging Queue）
  
  • http://en.wikipedia.org/wiki/Message_Queue
  • http://www.cnblogs.com/rickie/archive/2004/11/16/64345.aspx

• 有哪些队列服务器（Queue Server）软件
  
  • Beanstalkd
  • Starling
  • Peafowl

• 同步与异步概念
  
  • HTTP是同步的，Queue是异步的，但是目的是一样的
  • http://en.wikipedia.org/wiki/Message_Queue

• 服务器与客户端概念
  
  • 在HTTP概念中，存在浏览器（Client）与网络服务器（Server）；
  • 在Queue概念中，也存在客户端软件与服务器软件概念；

• 如何在Ruby和Rails中使用基于Beanstalk的消息队列（Messaging Queue）
  
  • Beanstalk Messaging Queue http://tinyurl.com/24zfv7
  • Ruby Beanstalkd distributed worker basics http://tinyurl.com/5nehld
  • Ruby Beanstalkd distributed worker intermediate lessons http://tinyurl.com/6hz6p3
  • http://async-observer.rubyforge.org/

• 参考资料
  
  • https://computing.llnl.gov/tutorials/parallel_comp/

• 安装说明
  
  • 点击链接： http://tinyurl.com/6g8nd9
  • 把下载的文件NetNewsWire.app移到应用软件目录下
  • 点击该文件NetNewsWire.app，就可以启动该软件
  • 注册一下用户
  • 在所有的Mac OS X机器上，只要有该软件并且有相同的用户，相互间就可以同步本地RSS信息。

Rails 2.2 is finally done after we cleared the last issues from the release candidate program. This release contains an long list of fixes, improvements, and additions that’ll make everything Rails smoother and better, but we also have a number of star player features to parade this time.

Internationalization by default
The most important is that Rails now includes a full-on internationalization framework and that it’s pre-wired from start. The work of the i18n group has been very impressive and it’s great to see that Rails finally ships with a solution in the box that’s both simple and extensible. Great job, guys!

Stronger etag and last-modified support
We’ve also added much better support for HTTP validators in the form of etag and last-modified. Making it so much easier to skip expensive procesesing if the client already has the latest stuff. This also makes it even easier to use Rails with gateway proxies.

Thread safety and a connection pool
Josh Peek has added thread safety to Rails and Nick Sieger from JRuby worked on getting Active Record a proper connection pool. So now all elements of Rails are thread safe, which is a big boon for the JRuby guys in particular. For C Ruby, we still need a bunch of dependent libraries to go non-blocking before it’ll make much of a difference, but work on that is forth coming.

Ruby 1.9 and JRuby compatibility
Jeremy Kemper has been rocking on both Ruby 1.9 and JRuby compatibility. Rails 2.2 is fully compatible with both, but again, there might be supporting libraries and gems that are not. Again, lots of work is going into making everything else fully compatible as well.

Better API docs, great guides
Finally, the last big push has been with the documentation of Rails. Pratik’s docrails project has made immense progress. Not only are the API docs much improved, but we also have a whole new guides section generated from documentation that now lives with the source. A true community project with lots of contributors. I’m sure both those new and old to Rails will greatly appreciate the strong focus on documentation.

To read about all these features and more in details, checkout the Rails 2.2 release notes—another one of those guides from the docrails project.

How to install
As always, you can install Rails 2.2 through RubyGems. We now require RubyGems 1.3.1, so be sure to update that first: gem update --system

Then you can install Rails: gem install rails

If you’re updating an existing application, you can run rake rails:update to get the latest JavaScript files and scripts.

From all of us to all of you, we hope you enjoy this release. It’s a true pleasure to see Rails make such big steps forward once again. Dig in, have fun, and we’ll be back with Rails 2.3 with even more before you know it.

• 相关链接
  
  • Ruby和Rails应用软件有多少？ http://www.railsforall.org/apps
  • Ruby和Rails资料有多少？ http://www.railsforall.org/resources

First up this week, a warning for those who don’t closely follow the state of the Rails repository – “edge” really means edge now. The bits for 2.2 are getting locked down for release, and the repository has been forked; for the moment, edge Rails is being identified as 2.3 , though that projected version number might change later. If you’re trying to install almost-released 2.2 bits on your machine, make sure you’re using the 2-2-stable branch, and not edge, which is currently seeing some major changes.

The 2-2-stable code is still seeing changes, but they’re either bug fixes or very small things. This week, that includes fixing a bug in assignment to has_one :through associations , some further tuning of CSRF protection , a fix to handling of checkboxes for Boolean attributes , updating the bundled copies of TZInfo, Prototype, and script.aculo.us, and some Ruby 1.9 compatibility work (though currently full Ruby 1.9 compatibility is targeted for Rails 2.3).

The biggest feature change in the 2.2 branch is the addition of explicit I18n support to newly-generated Rails projects, including a sample locale file, auto-loading all locales in config/locales, and sample settings in config/environment.rb. commit

Also worth noting in 2.2 is a chunk of code removal: a whole mess of special case tests for the SQL Server adapter have been chopped out of the Active Record test cases. That’s because Ken Collins has done tremendous work in making the SQL Server adapter work the way that Rails expects data adapters to work, giving us a big step in the area of backend portability. commit

On the actual edge code (the master branch in the repository), there’s a lot more action. With that branch just opened, some pent-up code has been checked in, and some big changes are being made. It’s an exciting time, and edge is definitely worth checking out. Here are some of the most notable changes in the past week.

One big set of changes has come from Jeremy Kemper, who has been overhauling the internal Rails testing to switch from Test::Unit::TestCase to ActiveSupport::TestCase. This work also includes requiring Mocha to test Rails (in the 2.2 code, some tests are skipped if you don’t have Mocha installed) and generally making the Rails testing strategy (both within core and for generated applications) more consistent moving forward.

If you’re one of the people who has always been bothered by the special-case naming of application.rb, rejoice! It’s been reworked to be application_controller.rb in the edge code. More info here and here . commit

Rails 2.3 will introduce the notion of default scopes : similar to named scopes, but applying to all named scopes or find methods within the class. For example, you can write default_scope :order => 'name ASC' and any time you retrieve records from that class they’ll come out sorted by name (unless you override the option, of course). commit

A lot of folks have adopted the notion of using try() to attempt operations on objects – Here’s Chris Wanstrath’s blog post introducing it. It’s especially helpful in views where you can avoid nil-checking by writing code like <%= @person.try(:name) %>. Well, now it’s baked right into Rails. commit

Also new on the syntactic sugar front is Enumerable#none? to check that none of the elements match the supplied block. commit

The render method has been getting smarter over the years, and it’s going to be even smarter in 2.3. If you have an object or a collection and the naming matches up, you can now just do <% render @article %> or <% render @articles %> and things will just work. Ryan Daigle has some more examples on this. commit

On a somewhat similar note, render_component goes from “deprecated” to “nonexistent” in 2.3. If you still need it, you can install the plugin . commit

The autolink helper has been refactored to make it a bit less messy and more intuitive. commit commit

There’s a fix to a memory leak connected to thread safety and asset tags, that could bite sites that were referencing a lot of external images. Aaron Batalion contributed the fix, as well as a blog post explaining the issue. commit and commit

Finally, it’s worth mentioning that some controversy has erupted over a change made to the 2.2 code five months ago – the addition of Array#second through Array#tenth as aliases for Array#[1] through Array#[9]. Without taking a stand on the controversy (I’ve done that elsewhere), I’ll just note that the most recent edge checkin as I write this trims this down to only support Array#second through Array#fifth – and uses the savings in overhead to implement Array#forty-two. commit

With king of the hill Rails chugging along, and up-and-comer Merb picking up steam, why bother with Ramaze?

The number one thing that makes Ramaze stand out from the crowd is that you write very little code and you write it all yourself. No generators.

...

Before Rails, people wrote lots and lots of code when making a web app, and they did it over and over as they did web app after web app. With each new app, they would spend time “ramping up” with just the base application before they got into the real meat of the matter, the core functionality which varied from client to client, application to application. Rails and Merb and their ilk try to make your life easier by generating this “lots and lots of code” for you, so you don’t have to spend time repeating the motions of getting the skeleton of your application coded.

Ramaze takes a different approach. It asks: How about we dump the “lots and lots of code” part altogether? This way, you get the benefit of nearly nil ramp up time, without the gaping jaw effect that hits you after you run a code generator script and sit staring at the big filetree that just sprouted out of the ground (think Jack and the Beanstalk).

Ramaze by Example

• hfsdebug: A Debugger for HFS Plus Volumes
• newLISP - Home

• 参考资料
  
  • Mootools首页 http://mootools.net
  • Mootools on Rails插件
  • MooTools Plays Well With Rails http://tinyurl.com/6pl8ql
  • Mootools插件Accordion
  • Increasing User Experience With Javascript http://tinyurl.com/5ed8tf

• 演示版本：http://lycom.de:70002/posts

rails mootools_demo && cd mootools_demo
　
git clone git://github.com/pointcom/mootools-on-rails.git vendor/plugins/mootools-on-rails
　
rake mootools_on_rails:install
　
ruby script/generate scaffold post title:string body:text published:boolean
　
vi config/routes.rb
ActionController::Routing::Routes.draw do |map|
  MootoolsOnRails.routes
　
vi app/views/layouts/posts.html.erb 
  <%= stylesheet_link_tag 'scaffold' %>
  <%= javascript_include_tag :mootools %>
　
rake db:migrate
　
vi app/views/posts/index.html.erb 
  <% add_event('link', 'click') do |page|
    page.alert('coucou div 2')
   end %>  <%= content_tag(:a, "Click My Link", :id => 'link') %>
　
ruby script/server

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.

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.

• 安装说明
  
  • 下载文件：http://www.unrarx.com/files/UnRarX_2.2.zip
  • 解压文件UnRarX_2.2.zip
  • 复制或者移动文件UnRarX.app到目录/Applications/（即：应用程序）下

Just came across this post by Lyle Johnson, where he describes his attempts to catch a talk, and subsequent video, at RubyConf.

He was, as I bet 99% of conference attendees (myself included) were, unaware that not all talks at RubyConf would be recorded. Speakers have the option of preventing their talks from being videoed. On refection this seems to make some sense; not everyone is comfortable with live recordings (ask Chris Matthieu ; he’s asked to record my presentations at the Phoenix Ruby User group a number of times, and I always decline. I ramble.)

However, it never occurred to me at this recent RubyConf that talks would not be available; I assumed all talks were recorded as a matter of agreement with being a speaker. So I felt OK with missing one or another talk on the belief that I could catch the replay.

It’s interesting to note the reason given for not allowing the recording in question. It wasn’t discomfort; it was a desire to drive traffic to a for-pay version. That’s not a bad idea, and certainly, as Lyle points out, people should be able to find compensation for their efforts. However, this leads me to two thoughts.

First, every conference that allows speakers to opt out of being recorded should have those decisions made well enough in advance that it can be clearly stated on the schedule distributed at the conference. People attending a conference should know ahead of time if a talk will be available on video or not.

Second, all speakers should give serious consideration to not allowing their talks to be recorded, and plan on making their own, more polished version. And see if they can get a few bucks for it in the process. Oh, and if you don’t tell people in advance that you’ll be making a video available later, you might be able to drive up attendance at your talk. A big win all around, no? Well, maybe for the speakers, perhaps less so for the poor schlubs paying the conference fee and struggling to catch all the talks.

So now I have a third thought: Do not make recording optional. Make it a condition of being allowed to speak. Speaking at a Ruby conference should be seen as a privilege. I understand the opportunity value for hawking one’s products or services (and JotBot was given a plug at David’s talk), but the talk itself should not be the product. BTW, this is not a matter of OSS zealotry, but a matter of deciding what conference policies work best for the communities they serve.

(Possible 4th thought: Disallow video opt-out, and ensure that all attendees get the full videos, but allow opt-out of public video distribution. When I spoke at the first MtWest RubyConf, I was asked to sign a release form for the video of my talk. The original paperwork was pretty vague, and I insisted on explicit wording saying that the video was to be released under a Creative Commons license. It might be workable to allow speakers to select among licenses for distribution outside of conference attendees such that speakers still had an opportunity to sell (or not) a version of their talk to those who did not attend the conference. Not what I’d really like to see, though.)

Addendum

I’m fortunate to be part of the MountainWest RubyConf advisory team. The issue of video recording speakers was raised for discussion, and it was agreed that all speakers, as part of accepting an invitation to present, must agree to being recorded and having that recording made freely available under a Creative Commons license. I expect that the conference Web site will be updated with this info before too long, and it will be made clear to all speakers who are selected for the conference.

我正在写的一个库，摆在我面前的是这样一段代码：

class CONSTANT_Utf8 < MyModule::String
  size :type => :u2
 
  define_type :constant_utf8
end

这里定义了一个类型，它定义了字符串类型，size的类型是u2，类型的名字叫constant_utf8。我翻遍了所有的代码，这个类型的名字（CONSTANT_Utf8）除了定义这里，根本没有人会用到。没有用的东西是否还有存在的价值，这是我面对它思考的问题，尽管这是我想当初费劲心力想出的名字。经过一番痛苦的思索，我打算把这段代码改成这样：

MyModule.Type.string(:constant_utf8, :size => {:type => :u2})

如此一来，那个完全没有必要存在的类名字便也烟消云散了。想清楚之后写代码还是容易的。

module MyModule
  class << Type
    ...

    def string(name, options)
      type(name, MyModule::String, options)
    end

    def type(name, super_type, options)
      klass = Class.new(super_type)
      options.each {|key, value| klass.send(key, *value) }
      define_type(name, klass)
    end
  end
end

于是，我兴致高昂把后面类似的代码用同样方法处理。突然，一个测试失败了，真正的问题在这段代码：

MyModule::Type.struct(:constant_long, :u4 => :high_bytes, :u4 => :low_bytes)

经过分析，让这段代码失败的理由是，后面两项居然都用:u4做键值，于是原本是两项，传进hash之后，就只有一项了。于是，我的思路开始发散，加上括号，改hash为array……

结论是，没有哪个让我满意，不是实现不了，而是着实没有美感可言。不知道大脑中的哪个弦跳动了一下，既然在这个思路下，问题没法解决，我不妨换一个方式，于是，代码被改成了这样：

MyModule::Type.struct(:constant_long) do
  u4 :high_bytes
  u4 :low_bytes
end

如此一来，hash可能带来的冲突便不再存在了，而且，这和最初的用类定义形式上也更加接近，还有，这里也不用再为symbol点那个冒号了。当然实现也是要相应调整。

module MyModule
  class << Type
    ...

    def string(name, &block)
      type(name, MyModule::String, &block)
    end

    def type(name, super_type, &block)
      klass = Class.new(super_type)
      klass.instance_eval(&block) if block_given?
      define_type(name, klass)
    end
  end
end

前两天和胡凯聊天，我们发现公司里有一些更资深的技术人员，他们解决问题并不是通过操起兵器直接上阵，而是通过分析，提出另一种解决方案，从而原本的那个问题也就不是问题了。这里，我跳了两次，躲过命名和hash的烦恼。

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 the Railscast on Time Zones.

See the Rails Myths index for more myths about Rails.

• 安装前提条件：
  
  • ruby version 1.8.6
  • gem version 1.3.1
  • rails version 2.1.2
  • git version 1.6.0.1

rails demo_vasco && cd demo_vasco
　
ruby script/plugin install git://github.com/relevance/vasco.git
或者
cd vendor/plugins/ && git clone git://github.com/relevance/vasco.git && cd ../..
　
ruby script/generate scaffold post title:string body:text published:boolean
　
rake db:migrate
　
rake vasco:explore
　
ruby script/server
　
http://localhost:3000/vasco

• 说明
  
  • 在Mac OS X上使用上面所说的方法一切正常
  • 在Debian Sarge 3.1 Server上使用上面所说的方法，在使用命令“rake vasco:explore”时，就会出现问题。
  • 在使用Mongrel服务器可以正常访问
  • 在使用Thin服务器可以访问vasco时，会出现下面错误：
    No route matches ”/vasco” with {:method=>:get}

• 演示版本：http://lycom.de:70001/vasco

• 参考资料
  
  • Introducing Vasco: A Route Explorer for Rails http://tinyurl.com/59pacg
  • Minor bug fix to Vasco http://tinyurl.com/5dk37r
  • Vasco now supports nested routes http://tinyurl.com/6n8v6y

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.

Pacman

“ The dog was created especially for children. He is the god of frolic. ”

Henry Ward Beecher

Ca Plane Pour Moi

Plastic Bertrand

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.

• 相关资料
  
  • Merb, Rails Myths, Language Popularity and other Zenbits http://tinyurl.com/6pjfrn
  • http://www.zedshaw.com/blog/2008-11-13.html
  • MythBusting — Rails is not a monolith http://tinyurl.com/6adalf