Merge remote branch 'rails/master' into identity_map

Conflicts:
	activerecord/lib/active_record/associations/association_proxy.rb
	activerecord/lib/active_record/autosave_association.rb
	activerecord/lib/active_record/base.rb
	activerecord/lib/active_record/persistence.rb

21 files changed, 1256 insertions, 453 deletions

diff --git a/railties/guides/source/3_0_release_notes.textile b/railties/guides/source/3_0_release_notes.textile
index 9c08c9fa0a..adb1c755df 100644
--- a/railties/guides/source/3_0_release_notes.textile
+++ b/railties/guides/source/3_0_release_notes.textile
@@ -271,10 +271,10 @@ end
 
 <ruby>
 scope 'es' do
-  resources :projects, :path_names => { :edit => 'cambiar' }, :path => 'projeto'
+  resources :projects, :path_names => { :edit => 'cambiar' }, :path => 'proyecto'
 end
 
-# Gives you the edit action with /es/projeto/1/cambiar
+# Gives you the edit action with /es/proyecto/1/cambiar
 </ruby>
 
 * Added +root+ method to the router as a short cut for <tt>match '/', :to => path</tt>.
diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index 0d6c66f168..0d6919a205 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -478,8 +478,6 @@ end
 
 Again, this is not an ideal example for this filter, because it's not run in the scope of the controller but gets the controller passed as an argument. The filter class has a class method +filter+ which gets run before or after the action, depending on if it's a before or after filter. Classes used as around filters can also use the same +filter+ method, which will get run in the same way. The method must +yield+ to execute the action. Alternatively, it can have both a +before+ and an +after+ method that are run before and after the action.
 
-The Rails API documentation has "more information on using filters":http://ap.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html.
-
 h3. Verification
 
 Verifications make sure certain criteria are met in order for a controller or action to run. They can specify that a certain key (or several keys in the form of an array) is present in the +params+, +session+ or +flash+ hashes or that a certain HTTP method was used or that the request was made using +XMLHttpRequest+ (Ajax). The default action taken when these criteria are not met is to render a 400 Bad Request response, but you can customize this by specifying a redirect URL or rendering something else and you can also add flash messages and HTTP headers to the response. It is described in the "API documentation":http://ap.rubyonrails.org/classes/ActionController/Verification/ClassMethods.html as "essentially a special kind of before_filter".
diff --git a/railties/guides/source/action_mailer_basics.textile b/railties/guides/source/action_mailer_basics.textile
index b75c528a33..b77a0be37b 100644
--- a/railties/guides/source/action_mailer_basics.textile
+++ b/railties/guides/source/action_mailer_basics.textile
@@ -144,7 +144,7 @@ This provides a much simpler implementation that does not require the registerin
 
 The method +welcome_email+ returns a Mail::Message object which can then just be told +deliver+ to send itself out.
 
-NOTE: In previous versions of Rails, you would call +deliver_welcome_email+ or +create_welcome_email+ however in Rails 3.0 this has been deprecated in favour of just calling the method name itself.
+NOTE: In previous versions of Rails, you would call +deliver_welcome_email+ or +create_welcome_email+. This has been deprecated in Rails 3.0 in favour of just calling the method name itself.
 
 WARNING: Sending out one email should only take a fraction of a second, if you are planning on sending out many emails, or you have a slow domain resolution service, you might want to investigate using a background process like delayed job.
 
@@ -154,7 +154,7 @@ Action Mailer now handles the auto encoding of multibyte characters inside of he
 
 If you are using UTF-8 as your character set, you do not have to do anything special, just go ahead and send in UTF-8 data to the address fields, subject, keywords, filenames or body of the email and ActionMailer will auto encode it into quoted printable for you in the case of a header field or Base64 encode any body parts that are non US-ASCII.
 
-For more complex examples, such as defining alternate character sets or self encoding text first, please refer to the Mail library.
+For more complex examples such as defining alternate character sets or self encoding text first, please refer to the Mail library.
 
 h4. Complete List of Action Mailer Methods
 
@@ -213,9 +213,7 @@ NOTE: If you specify an encoding, Mail will assume that your content is already
 
 h5. Making Inline Attachments
 
-Inline attachments are now possible in ActionMailer.  While previously in the pre 3.0 version of Rails, you could do inline attachments, it involved a lot of hacking and determination to pull it off.
-
-ActionMailer now makes inline attachments as trivial as they should be.
+ActionMailer 3.0 makes inline attachments, which involved a lot of hacking in pre 3.0 versions, much simpler and trivial as they should be.
 
 * Firstly, to tell Mail to turn an attachment into an inline attachment, you just call <tt>#inline</tt> on the attachments method within your Mailer:
 
@@ -274,7 +272,7 @@ to format the email address in the format <tt>"Name &lt;email&gt;"</tt>.
 
 h4. Mailer Views
 
-Mailer views are located in the +app/views/name_of_mailer_class+ directory. The specific mailer view is known to the class because it's name is the same as the mailer method. So for example, in our example from above, our mailer view for the +welcome_email+ method will be in +app/views/user_mailer/welcome_email.html.erb+ for the HTML version and +welcome_email.text.erb+ for the plain text version.
+Mailer views are located in the +app/views/name_of_mailer_class+ directory. The specific mailer view is known to the class because its name is the same as the mailer method. In our example from above, our mailer view for the +welcome_email+ method will be in +app/views/user_mailer/welcome_email.html.erb+ for the HTML version and +welcome_email.text.erb+ for the plain text version.
 
 To change the default mailer view for your action you do something like:
 
@@ -441,7 +439,7 @@ h3. Action Mailer Configuration
 The following configuration options are best made in one of the environment files (environment.rb, production.rb, etc...)
 
 |template_root|Determines the base from which template references will be made.|
-|logger|The logger is used for generating information on the mailing run if available. Can be set to nil for no logging. Compatible with both Ruby's own Logger and Log4r loggers.|
+|logger|Generates information on the mailing run if available. Can be set to nil for no logging. Compatible with both Ruby's own Logger and Log4r loggers.|
 |smtp_settings|Allows detailed configuration for :smtp delivery method:<ul><li>:address - Allows you to use a remote mail server. Just change it from its default "localhost" setting.</li><li>:port  - On the off chance that your mail server doesn't run on port 25, you can change it.</li><li>:domain - If you need to specify a HELO domain, you can do it here.</li><li>:user_name - If your mail server requires authentication, set the username in this setting.</li><li>:password - If your mail server requires authentication, set the password in this setting.</li><li>:authentication - If your mail server requires authentication, you need to specify the authentication type here. This is a symbol and one of :plain, :login, :cram_md5.</li></ul>|
 |sendmail_settings|Allows you to override options for the :sendmail delivery method.<ul><li>:location - The location of the sendmail executable. Defaults to /usr/sbin/sendmail.</li><li>:arguments - The command line arguments to be passed to sendmail. Defaults to -i -t.</li></ul>|
 |raise_delivery_errors|Whether or not errors should be raised if the email fails to be delivered.|
@@ -504,7 +502,7 @@ class UserMailerTest < ActionMailer::TestCase
 end
 </ruby>
 
-In the test we send the email and store the returned object in the +email+ variable. We then ensure that it was sent (the first assert), then, in the second batch of assertions, we ensure that the email does indeed contain the what we expect.
+In the test we send the email and store the returned object in the +email+ variable. We then ensure that it was sent (the first assert), then, in the second batch of assertions, we ensure that the email does indeed contain what we expect.
 
 h3. Changelog
 
diff --git a/railties/guides/source/active_record_querying.textile b/railties/guides/source/active_record_querying.textile
index 328439fdb8..b9ad7ccbd2 100644
--- a/railties/guides/source/active_record_querying.textile
+++ b/railties/guides/source/active_record_querying.textile
@@ -65,6 +65,7 @@ The methods are:
 * +lock+
 * +readonly+
 * +from+
+* +having+
 
 All of the above methods return an instance of <tt>ActiveRecord::Relation</tt>.
 
@@ -103,7 +104,7 @@ h5. +first+
 
 <ruby>
 client = Client.first
-=> #<Client id: 1, first_name: => "Lifo">
+=> #<Client id: 1, first_name: "Lifo">
 </ruby>
 
 SQL equivalent of the above is:
@@ -120,7 +121,7 @@ h5. +last+
 
 <ruby>
 client = Client.last
-=> #<Client id: 221, first_name: => "Russel">
+=> #<Client id: 221, first_name: "Russel">
 </ruby>
 
 SQL equivalent of the above is:
@@ -231,7 +232,7 @@ WARNING: Building your own conditions as pure strings can leave you vulnerable t
 
 h4. Array Conditions
 
-Now what if that number could vary, say as an argument from somewhere, or perhaps from the user's level status somewhere? The find then becomes something like:
+Now what if that number could vary, say as an argument from somewhere? The find then becomes something like:
 
 <ruby>
 Client.where("orders_count = ?", params[:orders])
@@ -279,62 +280,15 @@ h5(#array-range_conditions). Range Conditions
 If you're looking for a range inside of a table (for example, users created in a certain timeframe) you can use the conditions option coupled with the +IN+ SQL statement for this. If you had two dates coming in from a controller you could do something like this to look for a range:
 
 <ruby>
-Client.where("created_at IN (?)",
-  (params[:start_date].to_date)..(params[:end_date].to_date))
+Client.where(:created_at => (params[:start_date].to_date)..(params[:end_date].to_date))
 </ruby>
 
-This would generate the proper query which is great for small ranges but not so good for larger ranges. For example if you pass in a range of date objects spanning a year that's 365 (or possibly 366, depending on the year) strings it will attempt to match your field against.
+This query will generate something similar to the following SQL:
 
 <sql>
-SELECT * FROM users WHERE (created_at IN
-  ('2007-12-31','2008-01-01','2008-01-02','2008-01-03','2008-01-04','2008-01-05',
-  '2008-01-06','2008-01-07','2008-01-08','2008-01-09','2008-01-10','2008-01-11',
-  '2008-01-12','2008-01-13','2008-01-14','2008-01-15','2008-01-16','2008-01-17',
-  '2008-01-18','2008-01-19','2008-01-20','2008-01-21','2008-01-22','2008-01-23',...
-  ‘2008-12-15','2008-12-16','2008-12-17','2008-12-18','2008-12-19','2008-12-20',
-  '2008-12-21','2008-12-22','2008-12-23','2008-12-24','2008-12-25','2008-12-26',
-  '2008-12-27','2008-12-28','2008-12-29','2008-12-30','2008-12-31'))
+  SELECT "clients".* FROM "clients" WHERE ("clients"."created_at" BETWEEN '2010-09-29' AND '2010-11-30')
 </sql>
 
-h5. Time and Date Conditions
-
-Things can get *really* messy if you pass in Time objects as it will attempt to compare your field to *every second* in that range:
-
-<ruby>
-Client.where("created_at IN (?)",
-  (params[:start_date].to_date.to_time)..(params[:end_date].to_date.to_time))
-</ruby>
-
-<sql>
-SELECT * FROM users WHERE (created_at IN
-  ('2007-12-01 00:00:00', '2007-12-01 00:00:01' ...
-  '2007-12-01 23:59:59', '2007-12-02 00:00:00'))
-</sql>
-
-This could possibly cause your database server to raise an unexpected error, for example MySQL will throw back this error:
-
-<shell>
-Got a packet bigger than 'max_allowed_packet' bytes: _query_
-</shell>
-
-Where _query_ is the actual query used to get that error.
-
-In this example it would be better to use greater-than and less-than operators in SQL, like so:
-
-<ruby>
-Client.where(
-  "created_at > ? AND created_at < ?", params[:start_date], params[:end_date])
-</ruby>
-
-You can also use the greater-than-or-equal-to and less-than-or-equal-to like this:
-
-<ruby>
-Client.where(
-  "created_at >= ? AND created_at <= ?", params[:start_date], params[:end_date])
-</ruby>
-
-Just like in Ruby. If you want a shorter syntax be sure to check out the "Hash Conditions":#hash-conditions section later on in the guide.
-
 h4. Hash Conditions
 
 Active Record also allows you to pass in hash conditions which can increase the readability of your conditions syntax. With hash conditions, you pass in a hash with keys of the fields you want conditionalised and the values of how you want to conditionalise them:
@@ -385,7 +339,7 @@ SELECT * FROM clients WHERE (clients.orders_count IN (1,3,5))
 
 h4. Ordering
 
-To retrieve records from the database in a specific order, you can specify the +:order+ option to the +find+ call.
+To retrieve records from the database in a specific order, you can use the +order+ method.
 
 For example, if you're getting a set of records and want to order them in ascending order by the +created_at+ field in your table:
 
@@ -496,7 +450,7 @@ SQL uses the +HAVING+ clause to specify conditions on the +GROUP BY+ fields. You
 For example:
 
 <ruby>
-Order.group("date(created_at)".having("created_at > ?", 1.month.ago)
+Order.group("date(created_at)").having("created_at > ?", 1.month.ago)
 </ruby>
 
 The SQL that would be executed would be something like this:
diff --git a/railties/guides/source/active_record_validations_callbacks.textile b/railties/guides/source/active_record_validations_callbacks.textile
index f7ef33bc1f..a15571fe58 100644
--- a/railties/guides/source/active_record_validations_callbacks.textile
+++ b/railties/guides/source/active_record_validations_callbacks.textile
@@ -96,7 +96,7 @@ To verify whether or not an object is valid, Rails uses the +valid?+ method. You
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
 end
 
 Person.create(:name => "John Doe").valid? # => true
@@ -109,7 +109,7 @@ Note that an object instantiated with +new+ will not report errors even if it's
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
 end
 
 >> p = Person.new
@@ -141,13 +141,13 @@ end
 
 h4(#validations_overview-errors). +errors[]+
 
-To verify whether or not a particular attribute of an object is valid, you can use +errors[:attribute]+ that returns an array with all attribute errors, when there are no errors on the specified attribute, an empty array is returned.
+To verify whether or not a particular attribute of an object is valid, you can use +errors[:attribute]+. It returns an array of all the errors for +:attribute+. If there are no errors on the specified attribute, an empty array is returned.
 
 This method is only useful _after_ validations have been run, because it only inspects the errors collection and does not trigger validations itself. It's different from the +ActiveRecord::Base#invalid?+ method explained above because it doesn't verify the validity of the object as a whole. It only checks to see whether there are errors found on an individual attribute of the object.
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
 end
 
 >> Person.new.errors[:name].any? # => false
@@ -355,7 +355,7 @@ This helper validates that the specified attributes are not empty. It uses the +
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name, :login, :email
+  validates :name, :login, :email, :presence => true
 end
 </ruby>
 
@@ -414,7 +414,7 @@ class Person < ActiveRecord::Base
   validates_with GoodnessValidator
 end
 
-class GoodnessValidator < ActiveRecord::Validator
+class GoodnessValidator < ActiveModel::Validator
   def validate
     if record.first_name == "Evil"
       record.errors[:base] << "This person is evil"
@@ -505,7 +505,7 @@ class Person < ActiveRecord::Base
   validates_numericality_of :age, :on => :update
 
   # the default (validates on both create and update)
-  validates_presence_of :name, :on => :save
+  validates :name, :presence => true, :on => :save
 end
 </ruby>
 
@@ -603,7 +603,7 @@ Returns an OrderedHash with all errors. Each key is the attribute name and the v
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
   validates_length_of :name, :minimum => 3
 end
 
@@ -623,7 +623,7 @@ h4(#working_with_validation_errors-errors-2). +errors[]+
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
   validates_length_of :name, :minimum => 3
 end
 
@@ -699,7 +699,7 @@ The +clear+ method is used when you intentionally want to clear all the messages
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
   validates_length_of :name, :minimum => 3
 end
 
@@ -723,7 +723,7 @@ The +size+ method returns the total number of error messages for the object.
 
 <ruby>
 class Person < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
   validates_length_of   :name, :minimum => 3
   validates_presence_of :email
 end
@@ -824,10 +824,10 @@ Here is a simple example where we change the Rails behaviour to always display t
 ActionView::Base.field_error_proc = Proc.new do |html_tag, instance|
   if instance.error_message.kind_of?(Array)
     %(#{html_tag}<span class="validation-error">&nbsp;
-      #{instance.error_message.join(',')}</span>)
+      #{instance.error_message.join(',')}</span>).html_safe
   else
     %(#{html_tag}<span class="validation-error">&nbsp;
-      #{instance.error_message}</span>)
+      #{instance.error_message}</span>).html_safe
   end
 end
 </ruby>
diff --git a/railties/guides/source/active_support_core_extensions.textile b/railties/guides/source/active_support_core_extensions.textile
index d41d8b6c3d..2e295aec3d 100644
--- a/railties/guides/source/active_support_core_extensions.textile
+++ b/railties/guides/source/active_support_core_extensions.textile
@@ -1189,6 +1189,12 @@ To insert something verbatim use the +raw+ helper rather than calling +html_safe
 <%= raw @cms.current_template %> <%# inserts @cms.current_template as is %>
 </erb>
 
+or, equivalently, use <tt><%==</tt>:
+
+<erb>
+<%== @cms.current_template %> <%# inserts @cms.current_template as is %>
+</erb>
+
 The +raw+ helper calls +html_safe+ for you:
 
 <ruby>
@@ -3353,6 +3359,49 @@ The auxiliary file is written in a standard directory for temporary files, but y
 
 NOTE: Defined in +active_support/core_ext/file/atomic.rb+.
 
+h3. Extensions to +Logger+
+
+h4. +around_[level]+
+
+Takes two arguments, a +before_message+ and +after_message+ and calls the current level method on the +Logger+ instance, passing in the +before_message+, then the specified message, then the +after_message+:
+
+<ruby>
+  logger = Logger.new("log/development.log")
+  logger.around_info("before", "after") { |logger| logger.info("during") }
+</ruby>
+
+h4. +silence+
+
+Silences every log level lesser to the specified one for the duration of the given block. Log level orders are: debug, info, error and fatal.
+
+<ruby>
+  logger = Logger.new("log/development.log")
+  logger.silence(Logger::INFO) do
+    logger.debug("In space, no one can hear you scream.")
+    logger.info("Scream all you want, small mailman!")
+  end
+</ruby>
+
+h4. +datetime_format=+
+
+Modifies the datetime format output by the formatter class associated with this logger. If the formatter class does not have a +datetime_format+ method then this is ignored.
+
+<ruby>
+  class Logger::FormatWithTime < Logger::Formatter
+    cattr_accessor(:datetime_format) { "%Y%m%d%H%m%S" }
+    
+    def self.call(severity, timestamp, progname, msg)
+      "#{timestamp.strftime(datetime_format)} -- #{String === msg ? msg : msg.inspect}\n"
+    end
+  end
+  
+  logger = Logger.new("log/development.log")
+  logger.formatter = Logger::FormatWithTime
+  logger.info("<- is the current time")
+</ruby>
+
+NOTE: Defined in +active_support/core_ext/logger.rb+.
+
 h3. Extensions to +NameError+
 
 Active Support adds +missing_name?+ to +NameError+, which tests whether the exception was raised because of the name passed as argument.
diff --git a/railties/guides/source/association_basics.textile b/railties/guides/source/association_basics.textile
index 14bbe907f3..62abc40c81 100644
--- a/railties/guides/source/association_basics.textile
+++ b/railties/guides/source/association_basics.textile
@@ -550,6 +550,8 @@ build_customer
 create_customer
 </ruby>
 
+NOTE: When initializing a new +has_one+ or +belongs_to+ association you must use the +build_+ prefix to build the association, rather than the +association.build+ method that would be used for +has_many+ or +has_and_belongs_to_many+ associations. To create one, use the +create_+ prefix.
+
 h6(#belongs_to-association). <tt><em>association</em>(force_reload = false)</tt>
 
 The <tt><em>association</em></tt> method returns the associated object, if any. If no associated object is found, it returns +nil+.
@@ -817,6 +819,8 @@ build_account
 create_account
 </ruby>
 
+NOTE: When initializing a new +has_one+ or +belongs_to+ association you must use the +build_+ prefix to build the association, rather than the +association.build+ method that would be used for +has_many+ or +has_and_belongs_to_many+ associations. To create one, use the +create_+ prefix.
+
 h6(#has_one-association). <tt><em>association</em>(force_reload = false)</tt>
 
 The <tt><em>association</em></tt> method returns the associated object, if any. If no associated object is found, it returns +nil+.
diff --git a/railties/guides/source/command_line.textile b/railties/guides/source/command_line.textile
index acd105c622..1e570c9992 100644
--- a/railties/guides/source/command_line.textile
+++ b/railties/guides/source/command_line.textile
@@ -31,7 +31,7 @@ h4. +rails new+
 
 The first thing we'll want to do is create a new Rails application by running the +rails new+ command after installing Rails.
 
-WARNING: You know you need the rails gem installed by typing +gem install rails+ first, if you don't have this installed, follow the instructions in the "Rails 3 Release Notes":/3_0_release_notes.html
+WARNING: You can install the rails gem by typing +gem install rails+, if you don't have it already. Follow the instructions in the "Rails 3 Release Notes":/3_0_release_notes.html
 
 <shell>
 $ rails new commandsapp
@@ -73,7 +73,7 @@ $ rails server
 [2010-04-18 03:20:33] INFO  WEBrick::HTTPServer#start: pid=26086 port=3000
 </shell>
 
-With just three commands we whipped up a Rails server listening on port 3000. Go to your browser and open "http://localhost:3000":http://localhost:3000, you will see a basic rails app running.
+With just three commands we whipped up a Rails server listening on port 3000. Go to your browser and open "http://localhost:3000":http://localhost:3000, you will see a basic Rails app running.
 
 h4. +rails generate+
 
@@ -101,7 +101,7 @@ Using generators will save you a large amount of time by writing *boilerplate co
 
 Let's make our own controller with the controller generator. But what command should we use? Let's ask the generator:
 
-INFO: All Rails console utilities have help text. As with most *NIX utilities, you can try adding +--help+ or +-h+ to the end, for example +rails server --help+.
+INFO: All Rails console utilities have help text. As with most *nix utilities, you can try adding +--help+ or +-h+ to the end, for example +rails server --help+.
 
 <shell>
 $ rails generate controller
@@ -134,6 +134,7 @@ The controller generator is expecting parameters in the form of +generate contro
 <shell>
 $ rails generate controller Greetings hello
      create  app/controllers/greetings_controller.rb
+      route  get "greetings/hello"
      invoke  erb
      create    app/views/greetings
      create    app/views/greetings/hello.html.erb
@@ -197,6 +198,8 @@ Examples:
         Creates a Post model with a string title, text body, and published flag.
 </shell>
 
+NOTE: For a list of available field types, refer to the "API documentation":http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/TableDefinition.html#method-i-column for the column method for the +TableDefinition+ class.
+
 But instead of generating a model directly (which we'll be doing later), let's set up a scaffold. A *scaffold* in Rails is a full set of model, database migration for that model, controller to manipulate it, views to view and manipulate the data, and a test suite for each of the above.
 
 We will set up a simple resource called "HighScore" that will keep track of our highest score on video games we play.
@@ -259,6 +262,15 @@ h4. +rails console+
 
 The +console+ command lets you interact with your Rails application from the command line. On the underside, +rails console+ uses IRB, so if you've ever used it, you'll be right at home. This is useful for testing out quick ideas with code and changing data server-side without touching the website.
 
+If you wish to test out some code without changing any data, you can do that by invoking +rails console --sandbox+.
+
+<shell>
+$ rails console --sandbox
+Loading development environment in sandbox (Rails 3.0.0)
+Any modifications you make will be rolled back on exit
+irb(main):001:0>
+</shell>
+
 h4. +rails dbconsole+
 
 +rails dbconsole+ figures out which database you're using and drops you into whichever command line interface you would use with it (and figures out the command line parameters to give to it, too!). It supports MySQL, PostgreSQL, SQLite and SQLite3.
@@ -279,7 +291,7 @@ $ rails plugin install http://svn.techno-weenie.net/projects/plugins/acts_as_par
 ...
 </shell>
 
-h4. +runner+
+h4. +rails runner+
 
 <tt>runner</tt> runs Ruby code in the context of Rails non-interactively. For instance:
 
@@ -287,7 +299,7 @@ h4. +runner+
 $ rails runner "Model.long_running_method"
 </shell>
 
-h4. +destroy+
+h4. +rails destroy+
 
 Think of +destroy+ as the opposite of +generate+. It'll figure out what generate did, and undo it. Believe you-me, the creation of this tutorial used this command many times!
 
@@ -316,7 +328,7 @@ $ rails destroy model Oops
     notempty  app
 </shell>
 
-h4. +about+
+h4. +rake about+
 
 Check it: Version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application's folder, the current Rails environment name, your app's database adapter, and schema version! +about+ is useful when you need to ask for help, check if a security patch might affect you, or when you need some stats for an existing Rails installation.
 
@@ -339,7 +351,7 @@ Environment               development
 
 h3. The Rails Advanced Command Line
 
-The more advanced uses of the command line are focused around finding useful (even surprising at times) options in the utilities, and fitting utilities to your needs and specific work flow. Listed here are some tricks up Rails' sleeve.
+More advanced use of the command line is focused around finding useful (even surprising at times) options in the utilities, and fitting those to your needs and specific work flow. Listed here are some tricks up Rails' sleeve.
 
 h4. Rails with Databases and SCM
 
@@ -472,7 +484,7 @@ We take whatever args are supplied, save them to an instance variable, and liter
 * Check there's a *public* directory. You bet there is.
 * Run the ERb template called "tutorial.erb".
 * Save it into "Rails.root/public/tutorial.txt".
-* Pass in the arguments we saved through the +:assign+ parameter.
+* Pass in the arguments we saved through the +:assigns+ parameter.
 
 Next we'll build the template:
 
@@ -538,8 +550,6 @@ rake tmp:sessions:clear                   # Clears all files in tmp/sessions
 rake tmp:sockets:clear                    # Clears all files in tmp/sockets
 </shell>
 
-Let's take a look at some of these 80 or so rake tasks.
-
 h5. +db:+ Database
 
 The most common tasks of the +db:+ Rake namespace are +migrate+ and +create+, and it will pay off to try out all of the migration rake tasks (+up+, +down+, +redo+, +reset+). +rake db:version+ is useful when troubleshooting, telling you the current version of the database.
@@ -548,24 +558,10 @@ h5. +doc:+ Documentation
 
 If you want to strip out or rebuild any of the Rails documentation (including this guide!), the +doc:+ namespace has the tools. Stripping documentation is mainly useful for slimming your codebase, like if you're writing a Rails application for an embedded platform.
 
-h5. +gems:+ Ruby gems
-
-You can specify which gems your application uses, and +rake gems:install+ will install them for you. Look at your environment.rb to learn how with the *config.gem* directive.
-
-NOTE: +gems:unpack+ will unpack, that is internalize your application's Gem dependencies by copying the Gem code into your vendor/gems directory. By doing this you increase your codebase size, but simplify installation on new hosts by eliminating the need to run +rake gems:install+, or finding and installing the gems your application uses.
-
 h5. +notes:+ Code note enumeration
 
 These tasks will search through your code for commented lines beginning with "FIXME", "OPTIMIZE", "TODO", or any custom annotation (like XXX) and show you them.
 
-h5. +rails:+ Rails-specific tasks
-
-In addition to the +gems:unpack+ task above, you can also unpack the Rails backend specific gems into vendor/rails by calling +rake rails:freeze:gems+, to unpack the version of Rails you are currently using, or +rake rails:freeze:edge+ to unpack the most recent (cutting, bleeding edge) version.
-
-When you have frozen the Rails gems, Rails will prefer to use the code in vendor/rails instead of the system Rails gems. You can "thaw" by running +rake rails:unfreeze+.
-
-After upgrading Rails, it is useful to run +rails:update+, which will update your config and scripts directories, and upgrade your Rails-specific javascript (like Scriptaculous).
-
 h5. +test:+ Rails tests
 
 INFO: A good description of unit testing in Rails is given in "A Guide to Testing Rails Applications":testing.html
diff --git a/railties/guides/source/configuring.textile b/railties/guides/source/configuring.textile
index e39ccbc4b8..d5faf3da2c 100644
--- a/railties/guides/source/configuring.textile
+++ b/railties/guides/source/configuring.textile
@@ -13,7 +13,7 @@ Rails offers (at least) four good spots to place initialization code:
 
 * application.rb
 * Environment-specific Configuration Files
-* Initializers (load_application_initializers)
+* Initializers
 * After-Initializers
 
 h3. Running Code Before Rails
@@ -23,41 +23,65 @@ To run some code before Rails itself is loaded, simply put it above the call to
 
 h3. Configuring Rails Components
 
-In general, the work of configuring Rails means configuring the components of Rails, as well as configuring Rails itself. The +application.rb+ and environment-specific configuration files (such as +config/environments/production.rb+) allow you to specify the various settings that you want to pass down to all of the components. For example, the default Rails 2.3 +application.rb+ file includes one setting:
+In general, the work of configuring Rails means configuring the components of Rails, as well as configuring Rails itself. The +application.rb+ and environment-specific configuration files (such as +config/environments/production.rb+) allow you to specify the various settings that you want to pass down to all of the components. For example, the default Rails 3.0 +application.rb+ file includes this setting:
 
 <ruby>
-config.filter_parameters << :password
+  config.filter_parameters += [:password]
 </ruby>
 
 This is a setting for Rails itself. If you want to pass settings to individual Rails components, you can do so via the same +config+ object:
 
 <ruby>
-config.active_record.timestamped_migrations = false
+  config.active_record.timestamped_migrations = false
 </ruby>
 
 Rails will use that particular setting to configure Active Record.
 
 h4. Rails General Configuration
 
-* +config.routes_configuration_file+ overrides the default path for the routes configuration file. This defaults to +config/routes.rb+.
+* +config.after_initialize+ takes a block which will be ran _after_ Rails has finished initializing. Useful for configuring values set up by other initializers:
 
-* +config.cache_classes+ controls whether or not application classes should be reloaded on each request.
+<ruby>
+config.after_initialize do
+  ActionView::Base.sanitized_allowed_tags.delete 'div'
+end
+</ruby>
+
+* +config.allow_concurrency+ should be set to +true+ to allow concurrent (threadsafe) action processing. Set to +false+ by default. You probably don't want to call this one directly, though, because a series of other adjustments need to be made for threadsafe mode to work properly. Can also be enabled with +threadsafe!+.
+
+* +config.asset_host+ sets the host for the assets. Useful when CDNs are used for hosting assets rather than the application server itself. Shorter version of +config.action_controller.asset_host+.
+
+* +config.asset_path+ takes a block which configures where assets can be found. Shorter version of +config.action_controller.asset_path+.
+
+<ruby>
+  config.asset_path = proc { |asset_path| "assets/#{asset_path}" }
+</ruby>
+
+* +config.autoload_once_paths+ accepts an array of paths from which Rails will automatically load from only once. All elements of this array must also be in +autoload_paths+.
 
-* +config.cache_store+ configures which cache store to use for Rails caching. Options include +:memory_store+, +:file_store+, +:mem_cache_store+ or the name of your own custom class.
+* +config.autoload_paths+ accepts an array of additional paths to prepend to the load path. By default, all app, lib, vendor and mock paths are included in this list.
 
-* +config.colorize_logging+ (true by default) specifies whether or not to use ANSI color codes when logging information.
+* +config.cache_classes+ controls whether or not application classes should be reloaded on each request. Defaults to _true_ in development, _false_ in test and production. Can also be enabled with +threadsafe!+.
 
-* +config.controller_paths+ accepts an array of paths that will be searched for controllers. Defaults to +app/controllers+.
+* +config.action_view.cache_template_loading+ controls whether or not templates should be reloaded on each request. Defaults to whatever is set for config.cache_classes.
 
-* +config.database_configuration_file+ overrides the default path for the database configuration file. Default to +config/database.yml+.
+* +config.cache_store+ configures which cache store to use for Rails caching. Options include +:memory_store+, +:file_store+, +:mem_cache_store+ or the name of your own custom class. Defaults to +:file_store+.
 
-* +config.dependency_loading+ enables or disables dependency loading during the request cycle. Setting dependency_loading to _true_ will allow new classes to be loaded during a request and setting it to _false_ will disable this behavior.
+* +config.colorize_logging+ specifies whether or not to use ANSI color codes when logging information. Defaults to _true_.
 
-* +config.eager_load_paths+ accepts an array of paths from which Rails will eager load on boot if cache classes is enabled. All elements of this array must also be in +load_paths+.
+* +config.consider_all_requests_local+ is generally set to +true+ during development and +false+ during production; if it is set to +true+, then any error will cause detailed debugging information to be dumped in the HTTP response. For finer-grained control, set this to +false+ and implement +local_request?+  in controllers to specify which requests should provide debugging information on errors.
 
-* +config.load_once_paths+ accepts an array of paths from which Rails will automatically load from only once. All elements of this array must also be in +load_paths+.
+* +config.controller_paths+ configures where Rails can find controllers for this application.
 
-* +config.load_paths+ accepts an array of additional paths to prepend to the load path. By default, all app, lib, vendor and mock paths are included in this list.
+* +config.dependency_loading+ enables or disables dependency loading during the request cycle. Setting dependency_loading to _true_ will allow new classes to be loaded during a request and setting it to _false_ will disable this behavior. Can also be enabled with +threadsafe!+.
+
+* +config.eager_load_paths+ accepts an array of paths from which Rails will eager load on boot if cache classes is enabled. Defaults to every folder in the +app+ directory of the application. All elements of this array must also be in +load_paths+.
+
+* +config.encoding+ sets up the application-wide encoding. Defaults to UTF-8.
+
+* +config.filter_parameters+ used for filtering out the parameters that you don't want shown in the logs, such as passwords or credit card numbers.
+
+* +config.helper_paths+ configures where Rails can find helpers for this application.
 
 * +config.log_level+ defines the verbosity of the Rails logger. In production mode, this defaults to +:info+. In development mode, it defaults to +:debug+.
 
@@ -65,25 +89,106 @@ h4. Rails General Configuration
 
 * +config.logger+ accepts a logger conforming to the interface of Log4r or the default Ruby 1.8+ Logger class, which is then used to log information from Action Controller. Set to nil to disable logging.
 
-* +config.plugin_loader+ overrides the class that handles loading each plugin. Defaults to +Rails::Plugin::Loader+.
-
-* +config.plugin_locators+ overrides the class that handle finding the desired plugins that you‘d like to load for your application. By default it is the +Rails::Plugin::FileSystemLocator+.
-
-* +config.plugin_paths+ overrides the path to the root of the plugins directory. Defaults to +vendor/plugins+.
+* +config.middleware+ allows you to configure the application's middleware. This is covered in depth in the "Configuring Middleware" section below.
 
 * +config.plugins+ accepts the list of plugins to load. If this is set to nil, all plugins will be loaded. If this is set to [], no plugins will be loaded. Otherwise, plugins will be loaded in the order specified.
 
-* +config.preload_frameworks+ enables or disables preloading all frameworks at startup.
+* +config.preload_frameworks+ enables or disables preloading all frameworks at startup. Can also be enabled with +threadsafe!+. Defaults to +nil+, so is disabled.
 
 * +config.reload_plugins+ enables or disables plugin reloading.
 
-* +config.root_path+ configures the root path of the application.
+* +config.root+ configures the root path of the application.
+
+* +config.secret_token+ used for specifying a key which allows sessions for the application to be verified against a known secure key to prevent tampering.
+
+* +config.serve_static_assets+ configures Rails to serve static assets. Defaults to _true_, but in the production environment is turned off. The server software used to run the application should be used to serve the assets instead.
+
+* +config.session_store+ is usually set up in +config/initializers/session_store.rb+ and specifies what class to use to store the session. Custom session stores can be specified like so:
+
+<ruby>
+  config.session_store = :my_custom_store
+</ruby>
+
+This custom store must be defined as +ActionDispatch::Session::MyCustomStore+.
+
+* +config.threadsafe!+ enables +allow_concurrency+, +cache_classes+, +dependency_loading+ and +preload_frameworks+ to make the application threadsafe.
+
+WARNING: Threadsafe operation is incompatible with the normal workings of development mode Rails. In particular, automatic dependency loading and class reloading are automatically disabled when you call +config.threadsafe!+.
 
 * +config.time_zone+ sets the default time zone for the application and enables time zone awareness for Active Record.
 
-* +config.view_path+ sets the path of the root of an application's views. Defaults to +app/views+.
+* +config.whiny_nils+ enables or disables warnings when any methods of nil are invoked. Defaults to _true_ in development and test environments.
+
+h4. Configuring Generators
+
+Rails 3 allows you to alter what generators are used with the +config.generators+ method. This method takes a block:
+
+<ruby>
+  config.generators do |g|
+    g.orm :active_record
+    g.test_framework :test_unit
+  end
+</ruby>
 
-* +config.whiny_nils+ enables or disabled warnings when an methods of nil are invoked. Defaults to _false_.
+The full set of methods that can be used in this block are as follows:
+
+* +force_plural+ allows pluralized model names. Defaults to _false_.
+* +helper+ defines whether or not to generate helpers. Defaults to _true_.
+* +orm+ defines which orm to use. Defaults to _nil_, so will use Active Record by default.
+* +integration_tool+ defines which integration tool to use. Defaults to _nil_.
+* +performance_tool+ defines which performance tool to use. Defaults to _nil_.
+* +resource_controller+ defines which generator to use for generating a controller when using +rails generate resource+. Defaults to +:controller+.
+* +scaffold_controller+ different from +resource_controller+, defines which generator to use for generating a _scaffolded_ controller when using +rails generate scaffold+. Defaults to +:scaffold_controller+.
+* +stylesheets+ turns on the hook for stylesheets in generators. Used in Rails for when the +scaffold+ generator is ran, but this hook can be used in other generates as well.
+* +test_framework+ defines which test framework to use. Defaults to _nil_, so will use Test::Unit by default.
+* +template_engine+ defines which template engine to use, such as ERB or Haml. Defaults to +:erb+.
+
+h4. Configuring Middleware
+
+Every Rails application comes with a standard set of middleware which it uses in this order in the development environment:
+
+* +ActionDispatch::Static+ is used to serve static assets. Disabled if +config.serve_static_assets+ is _true_.
+* +Rack::Lock+ Will wrap the app in mutex so it can only be called by a single thread at a time. Only enabled if +config.action_controller.allow_concurrency+ is set to _false_, which it is by default.
+* +ActiveSupport::Cache::Strategy::LocalCache+ Serves as a basic memory backed cache. This cache is not thread safe and is intended only for serving as a temporary memory cache for a single thread.
+* +Rack::Runtime+ Sets an +X-Runtime+ header, containing the time (in seconds) taken to execute the request.
+* +Rails::Rack::Logger+ Will notify the logs that the request has began. After request is complete, flushes all the logs.
+* +ActionDispatch::ShowExceptions+ rescues any exception returned by the application and renders nice exception pages if the request is local or if +config.consider_all_requests_local+ is set to _true_. If +config.action_dispatch.show_exceptions+ is set to _false_, exceptions will be raised regardless.
+* +ActionDispatch::RemoteIp+ checks for IP spoofing attacks. Configurable with the +config.action_dispatch.ip_spoofing_check+ and +config.action_dispatch.trusted_proxies+ settings.
+* +Rack::Sendfile+ The Sendfile middleware intercepts responses whose body is being served from a file and replaces it with a server specific X-Sendfile header. Configurable with +config.action_dispatch_
+* +ActionDispatch::Callbacks+ Runs the prepare callbacks before serving the request.
+* +ActiveRecord::ConnectionAdapters::ConnectionManagement+ cleans active connections after each request, unless the +rack.test+ key in the request environment is set to _true_.
+* +ActiveRecord::QueryCache+ caches all +SELECT+ queries generated in a request. If an +INSERT+ or +UPDATE+ takes place then the cache is cleaned.
+* +ActionDispatch::Cookies+ sets cookies for the request.
+* +ActionDispatch::Session::CookieStore+ is responsible for storing the session in cookies. An alternate middleware can be used for this by changing the +config.action_controller.session_store+ to an alternate value. Additionally, options passed to this can be configured by using +config.action_controller.session_options+.
+* +ActionDispatch::Flash+ sets up the +flash+ keys. Only available if +config.action_controller.session_store+ is set to a value.
+* +ActionDispatch::ParamsParser+ parses out parameters from the request into +params+
+* +Rack::MethodOverride+ allows the method to be overridden if +params[:_method]+ is set. This is the middleware which supports the PUT and DELETE HTTP method types.
+* +ActionDispatch::Head+ converts HEAD requests to GET requests and serves them as so.
+* +ActionDispatch::BestStandardsSupport+ enables "best standards support" so that IE8 renders some elements correctly.
+
+Besides these usual middleware, you can add your own by using the +config.middleware.use+ method:
+
+<ruby>
+  config.middleware.use Magical::Unicorns
+</ruby>
+
+This will put the +Magical::Unicorns+ middleware on the end of the stack. If you wish to put this middleware before another use +insert_before+:
+
+<ruby>
+  config.middleware.insert_before ActionDispatch::Head, Magical::Unicorns
+</ruby>
+
+There's also +insert_after+ which will insert a middleware _after_ another:
+
+<ruby>
+  config.middleware.insert_after ActionDispatch::Head, Magical::Unicorns
+</ruby>
+
+Middlewares can also be completely swapped out and replaced with others:
+
+<ruby>
+  config.middleware.swap ActionDispatch::BestStandardsSupport, Magical::Unicorns
+</ruby>
 
 h4. Configuring i18n
 
@@ -127,37 +232,29 @@ h4. Configuring Action Controller
 
 <tt>config.action_controller</tt> includes a number of configuration settings:
 
-* +config.action_controller.asset_host+ provides a string that is prepended to all of the URL-generating helpers in +AssetHelper+. This is designed to allow moving all javascript, CSS, and image files to a separate asset host.
+* +config.action_controller.asset_host+ sets the host for the assets. Useful when CDNs are used for hosting assets rather than the application server itself.
 
-* +config.action_controller.asset_path+ allows you to override the default asset path generation by providing your own instructions.
+* +config.action_controller.asset_path+ takes a block which configures where assets can be found. Shorter version of +config.action_controller.asset_path+.
 
-* +config.action_controller.consider_all_requests_local+ is generally set to +true+ during development and +false+ during production; if it is set to +true+, then any error will cause detailed debugging information to be dumped in the HTTP response. For finer-grained control, set this to +false+ and implement +local_request?+ to specify which requests should provide debugging information on errors.
+* +config.action_controller.page_cache_directory+ should be the document root for the web server and is set using <tt>Base.page_cache_directory = "/document/root"</tt>. For Rails, this directory has already been set to +Rails.public_path+ (which is usually set to <tt>Rails.root + "/public"</tt>). Changing this setting can be useful to avoid naming conflicts with files in <tt>public/</tt>, but doing so will likely require configuring your web server to look in the new location for cached files.
 
-* +config.action_controller.allow_concurrency+ should be set to +true+ to allow concurrent (threadsafe) action processing. Set to +false+ by default. You probably don't want to call this one directly, though, because a series of other adjustments need to be made for threadsafe mode to work properly. Instead, you should simply call +config.threadsafe!+ inside your +production.rb+ file, which makes all the necessary adjustments.
+* +config.action_controller.page_cache_extension+ configures the extension used for cached pages saved to +page_cache_directory+. Defaults to +.html+
 
-WARNING: Threadsafe operation is incompatible with the normal workings of development mode Rails. In particular, automatic dependency loading and class reloading are automatically disabled when you call +config.threadsafe!+.
-
-* +config.action_controller.param_parsers+ provides an array of handlers that can extract information from incoming HTTP requests and add it to the +params+ hash. By default, parsers for multipart forms, URL-encoded forms, XML, and JSON are active.
+* +config.action_controller.perform_caching+ configures whether the application should perform caching or not. Set to _false_ in development mode, _true_ in production.
 
 * +config.action_controller.default_charset+ specifies the default character set for all renders. The default is "utf-8".
 
 * +config.action_controller.logger+ accepts a logger conforming to the interface of Log4r or the default Ruby 1.8+ Logger class, which is then used to log information from Action Controller. Set to nil to disable logging.
 
-* +config.action_controller.resource_path_names+ is a hash of default names for several RESTful actions. By default, the new action is named +new+ and the edit action is named +edit+.
-
 * +config.action_controller.request_forgery_protection_token+ sets the token parameter name for RequestForgery. Calling +protect_from_forgery+ sets it to +:authenticity_token+ by default.
 
-* +config.action_controller.optimise_named_routes+ turns on some optimizations in generating the routing table. It is set to +true+ by default.
-
 * +config.action_controller.allow_forgery_protection+ enables or disables CSRF protection. By default this is +false+ in test mode and +true+ in all other modes.
 
 * +config.action_controller.relative_url_root+ can be used to tell Rails that you are deploying to a subdirectory. The default is +ENV['RAILS_RELATIVE_URL_ROOT']+.
 
-* +config.action_dispatch.session_store+ sets the name of the store for session data. The default is +:cookie_store+; other valid options include +:active_record_store+, +:mem_cache_store+ or the name of your own custom class.
-
 The caching code adds two additional settings:
 
-* +ActionController::Base.page_cache_directory+ sets the directory where Rails will create cached pages for your web server. The default is +Rails.public_path+ (which is usually set to +Rails.root + "/public"+).
+* +ActionController::Base.page_cache_directory+ sets the directory where Rails will create cached pages for your web server. The default is +Rails.public_path+ (which is usually set to <tt>Rails.root + "/public"</tt>).
 
 * +ActionController::Base.page_cache_extension+ sets the extension to be used when generating pages for the cache (this is ignored if the incoming request already has an extension). The default is +.html+.
 
@@ -169,13 +266,23 @@ The Active Record session store can also be configured:
 
 * +ActiveRecord::SessionStore::Session.data_column_name+ sets the name of the column which stores marshaled session data. Defaults to +data+.
 
+h4. Configuring Action Dispatch
+
+* +config.action_dispatch.session_store+ sets the name of the store for session data. The default is +:cookie_store+; other valid options include +:active_record_store+, +:mem_cache_store+ or the name of your own custom class.
+
+* +config.action_dispatch.tld_length+ sets the TLD (top-level domain) length for the application. Defaults to +1+.
+
+* +ActionDispatch::Callbacks.before+ takes a block of code to run before the request. 
+
+* +ActionDispatch::Callbacks.to_prepare+ takes a block to run after +ActionDispatch::Callbacks.before+, but before the request. Runs for every request in +development+ mode, but only once for +production+ or environments with +cache_classes+ set to +true+.
+
+* +ActionDispatch::Callbacks.after+ takes a block of code to run after the request. 
+
 h4. Configuring Action View
 
 There are only a few configuration options for Action View, starting with four on +ActionView::Base+:
 
-* +config.action_view.debug_rjs+ specifies whether RJS responses should be wrapped in a try/catch block that alert()s the caught exception (and then re-raises it). The default is +false+.
-
-* +config.action_view.warn_cache_misses+ tells Rails to display a warning whenever an action results in a cache miss on your view paths. The default is +false+.
+* +config.action_view.debug_rjs+ specifies whether RJS responses should be wrapped in a try/catch block that alerts the caught exception (and then re-raises it). The default is +false+.
 
 * +config.action_view.field_error_proc+ provides an HTML generator for displaying errors that come from Active Record. The default is <tt>Proc.new{ |html_tag, instance| %Q(%&lt;div class=&quot;field_with_errors&quot;&gt;#{html_tag}&lt;/div&gt;).html_safe }</tt>
 
@@ -185,12 +292,36 @@ There are only a few configuration options for Action View, starting with four o
 
 * +config.action_view.erb_trim_mode+ gives the trim mode to be used by ERB. It defaults to +'-'+. See the "ERB documentation":http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/ for more information.
 
+* +config.action_view.javascript_expansions+ is a hash containing expansions that can be used for the JavaScript include tag. By default, this is defined as:
+
+<ruby>
+  config.action_view.javascript_expansions = { :defaults => ['prototype', 'effects', 'dragdrop', 'controls', 'rails'] }
+</ruby>
+
+However, you may add to this by defining others:
+
+<ruby>
+  config.action_view.javascript_expansions[:jquery] = ["jquery", "jquery-ui"]
+</ruby>
+
+And can reference in the view with the following code:
+
+<ruby>
+  <%= javascript_include_tag :jquery %>
+</ruby>
+
+* +config.action_view.stylesheet_expansions+ works in much the same way as +javascript_expansions+, but has no default key. Keys defined for this hash can be referenced in the view like such:
+
+<ruby>
+  <%= stylesheet_link_tag :special %>
+</ruby>
+
+* +ActionView::Helpers::AssetTagHelper::AssetPaths.cache_asset_ids+ With the cache enabled, the asset tag helper methods will make fewer expensive file system calls (the default implementation checks the file system timestamp). However this prevents you from modifying any asset files while the server is running.
+
 h4. Configuring Action Mailer
 
 There are a number of settings available on +config.action_mailer+:
 
-* +config.action_mailer.template_root+ gives the root folder for Action Mailer templates.
-
 * +config.action_mailer.logger+ accepts a logger conforming to the interface of Log4r or the default Ruby 1.8+ Logger class, which is then used to log information from Action Mailer. Set to nil to disable logging.
 
 * +config.action_mailer.smtp_settings+ allows detailed configuration for the +:smtp+ delivery method. It accepts a hash of options, which can include any of these options:
@@ -211,15 +342,13 @@ There are a number of settings available on +config.action_mailer+:
 
 * +config.action_mailer.perform_deliveries+ specifies whether mail will actually be delivered. By default this is +true+; it can be convenient to set it to +false+ for testing.
 
-* +config.action_mailer.default_charset+ tells Action Mailer which character set to use for the body and for encoding the subject. It defaults to +utf-8+.
-
-* +config.action_mailer.default_content_type+ specifies the default content type used for the main part of the message. It defaults to "text/plain"
-
-* +config.action_mailer.default_mime_version+ is the default MIME version for the message. It defaults to +1.0+.
-
-* +config.action_mailer.default_implicit_parts_order+ - When a message is built implicitly (i.e. multiple parts are assembled from templates
-which specify the content type in their filenames) this variable controls how the parts are ordered. Defaults to +["text/html", "text/enriched", "text/plain"]+. Items that appear first in the array have higher priority in the mail client
-and appear last in the mime encoded message.
+* +config.action_mailer.default+ configures Action Mailer defaults. These default to:
+<ruby>
+  :mime_version => "1.0",
+  :charset      => "UTF-8",
+  :content_type => "text/plain",
+  :parts_order  => [ "text/plain", "text/enriched", "text/html" ]
+</ruby>
 
 h4. Configuring Active Resource
 
@@ -231,6 +360,8 @@ h4. Configuring Active Support
 
 There are a few configuration options available in Active Support:
 
+* +config.active_support.bare+ enables or disables the loading of +active_support/all+ when booting Rails. Defaults to +nil+, which means +active_support/all+ is loaded.
+
 * +config.active_support.escape_html_entities_in_json+ enables or disables the escaping of HTML entities in JSON serialization. Defaults to +true+.
 
 * +config.active_support.use_standard_json_time_format+ enables or disables serializing dates to ISO 8601 format. Defaults to +false+.
@@ -241,42 +372,179 @@ There are a few configuration options available in Active Support:
 
 * +ActiveSupport::Logger.silencer+ is set to +false+ to disable the ability to silence logging in a block. The default is +true+.
 
-h3. Using Initializers
+h3. Rails Environment Settings
 
-After loading the framework and any gems and plugins in your application, Rails turns to loading initializers. An initializer is any file of Ruby code stored under +config/initializers+ in your application. You can use initializers to hold configuration settings that should be made after all of the frameworks and plugins are loaded.
+Some parts of Rails can also be configured externally by supplying environment variables. The following environment variables are recognized by various parts of Rails:
 
-NOTE: You can use subfolders to organize your initializers if you like, because Rails will look into the whole file hierarchy from the +initializers+ folder on down.
+* +ENV["RAILS_ENV"]+ defines the Rails environment (production, development, test, and so on) that Rails will run under.
 
-TIP: If you have any ordering dependency in your initializers, you can control the load order by naming. For example, +01_critical.rb+ will be loaded before +02_normal.rb+.
+* +ENV["RAILS_RELATIVE_URL_ROOT"]+ is used by the routing code to recognize URLs when you deploy your application to a subdirectory.
+
+* +ENV["RAILS_ASSET_ID"]+ will override the default cache-busting timestamps that Rails generates for downloadable assets.
+
+* +ENV["RAILS_CACHE_ID"]+ and +ENV["RAILS_APP_VERSION"]+ are used to generate expanded cache keys in Rails' caching code. This allows you to have multiple separate caches from the same application.
+
+h3. Initialization events
 
-h3. Using an After-Initializer
+Rails has 5 initialization events which can be hooked into (listed in order that they are ran):
 
-After-initializers are run (as you might guess) after any initializers are loaded. You can supply an +after_initialize+ block (or an array of such blocks) by setting up +config.after_initialize+ in any of the Rails configuration files:
+* +before_configuration+: This is run as soon as the application constant inherits from +Rails::Application+. The +config+ calls are evaluated before this happens.
+
+* +before_initialize+: This is run directly before the initialization process of the application occurs with the +:bootstrap_hook+ initializer near the beginning of the Rails initialization process.
+
+* +to_prepare+: Run after the initializers are ran for all Railties (including the application itself), but before eager loading and the middleware stack is built. 
+
+* +before_eager_load+: This is run directly before eager loading occurs, which is the default behaviour for the _production_ environment and not for the +development+ enviroment.
+
+* +after_initialize+: Run directly after the initialization of the application, but before the application initializers are run.
+
+
+WARNING: Some parts of your application, notably observers and routing, are not yet set up at the point where the +after_initialize+ block is called.
+
+h4. +Rails::Railtie#initializer+
+
+Rails has several initializers that run on startup that are all defined by using the +initializer+ method from +Rails::Railtie+. Here's an example of the +initialize_whiny_nils+ initializer from Active Support:
 
 <ruby>
-config.after_initialize do
-  SomeClass.init
+initializer "active_support.initialize_whiny_nils" do |app|
+  require 'active_support/whiny_nil' if app.config.whiny_nils
 end
 </ruby>
 
-WARNING: Some parts of your application, notably observers and routing, are not yet set up at the point where the +after_initialize+ block is called.
+The +initializer+ method takes three arguments with the first being the name for the initializer and the second being an options hash (not shown here) and the third being a block. The +:before+ key in the options hash can be specified to specify which initializer this new initializer must run before, and the +:after+ key will specify which initializer to run this initializer _after_. 
 
-h3. Rails Environment Settings
+Initializers defined using the +initializer+ method will be ran in the order they are defined in, with the exception of ones that use the +:before+ or +:after+ methods.
 
-Some parts of Rails can also be configured externally by supplying environment variables. The following environment variables are recognized by various parts of Rails:
+WARNING: You may put your initializer before or after any other initializer in the chain, as long as it is logical. Say you have 4 initializers called "one" through "four" (defined in that order) and you define "four" to go _before_ "four" but _after_ "three", that just isn't logical and Rails will not be able to determine your initializer order.
 
-* +ENV['RAILS_ENV']+ defines the Rails environment (production, development, test, and so on) that Rails will run under.
+The block's argument of the +initialize+ is the instance of the application itself, and so we can access the configuration on it by using the +config+ method as this initializer does.
 
-* +ENV['RAILS_RELATIVE_URL_ROOT']+ is used by the routing code to recognize URLs when you deploy your application to a subdirectory.
+Because +Rails::Application+ inherits from +Rails::Railtie+ (indirectly), you can use the +initializer+ method in +config/application.rb+ to define initializers for the application.
 
-* +ENV["RAILS_ASSET_ID"]+ will override the default cache-busting timestamps that Rails generates for downloadable assets.
+h4. Initializers
 
-* +ENV["RAILS_CACHE_ID"]+ and +ENV["RAILS_APP_VERSION"]+ are used to generate expanded cache keys in Rails' caching code. This allows you to have multiple separate caches from the same application.
+Below is a comprehensive list of all the initializers found in Rails in the order that they are defined (and therefore run in, unless otherwise stated).
+
+*+load_environment_hook+*
+Serves as a placeholder so that +:load_environment_config+ can be defined to run before it.
+
+*+load_active_support+* Requires +active_support/dependencies+ which sets up the basis for Active Support. Optionally requires +active_support/all+ if +config.active_support.bare+ is un-truthful, which is the default.
+
+*+preload_frameworks+* Will load all autoload dependencies of Rails automatically if +config.preload_frameworks+ is +true+ or "truthful". By default this configuration option is disabled. In Rails, when internal classes are referenced for the first time they are autoloaded. +:preload_frameworks+ loads all of this at once on initialization.
+
+*+initialize_logger+* Initializes the logger (an +ActiveSupport::BufferedLogger+ object) for the application and makes it accessible at +Rails.logger+, providing that there's no initializer inserted before this point that has defined +Rails.logger+.
+
+*+initialize_cache+* If +RAILS_CACHE+ isn't yet set, initializes the cache by referencing the value in +config.cache_store+ and stores the outcome as +RAILS_CACHE+. If this object responds to the +middleware+ method, its middleware is inserted before +Rack::Runtime+ in the middleware stack.
+
+*+set_clear_dependencies_hook+* Provides a hook for +active_record.set_dispatch_hooks+ to use, which will run before this initializer. This initializer -- which runs only if +cache_classes+ is set to +false+ -- uses +ActionDispatch::Callbacks.after+ to remove the constants which have been referenced during the request from the object space so that they will be reloaded during the following request.
+
+*+initialize_dependency_mechanism+* If +config.cache_classes+ is set to +true+, configures +ActiveSupport::Dependencies.mechanism+ to +require+ dependencies rather than +load+ them.
+
+*+bootstrap_hook+* Runs all configured +before_initialize+ blocks.
+
+*+i18n.callbacks+* In the development environment, sets up a +to_prepare+ callback which will call +I18n.reload!+ if any of the locales have changed since the last request. In production mode this callback will only run on the first request.
+
+*+active_support.initialize_whiny_nils+* Will require +active_support/whiny_nil+ if +config.whiny_nils+ is set to +true+. This file will output errors such as:
+
+<plain>
+  Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id
+</plain>
+
+And:
+
+<plain>
+You have a nil object when you didn't expect it!
+You might have expected an instance of Array.
+The error occurred while evaluating nil.each
+</plain>
+
+*+active_support.deprecation_behavior+* Sets up deprecation reporting for environments, defaulting to +log+ for development, +notify+ for production and +stderr+ for test. If a value isn't set for +config.active_support.deprecation+ then this initializer will prompt the user to configure this line in the current environment's +config/environments+ file.
+
+*+active_support.initialize_time_zone+* Sets the default time zone for the application based off the +config.time_zone+ setting, which defaults to "UTC".
+
+*+action_dispatch.configure+* Configures the +ActionDispatch::Http::URL.tld_length+ to be set to the value of +config.action_dispatch.tld_length+.
+
+*+action_view.cache_asset_ids+* Will set +ActionView::Helpers::AssetTagHelper::AssetPaths.cache_asset_ids+ to +false+ when Active Support loads, but only if +config.cache_classes+ is too.
+
+*+action_view.javascript_expansions+* Registers the expansions set up by +config.action_view.javascript_expansions+ and +config.action_view.stylesheet_expansions+ to be recognised by Action View and therefore usable in the views.
+
+*+action_view.set_configs+* Sets up Action View by using the settings in +config.action_view+ by +send+'ing the method names as setters to +ActionView::Base+ and passing the values through.
+
+*+action_controller.logger+* Sets +ActionController::Base.logger+ -- if it's not already set --  to +Rails.logger+.
+
+*+action_controller.initialize_framework_caches+* Sets +ActionController::Base.cache_store+ -- if it's not already set --  to +RAILS_CACHE+.
+
+*+action_controller.set_configs+* Sets up Action Controller by using the settings in +config.action_controller+ by +send+'ing the method names as setters to +ActionController::Base+ and passing the values through.
+
+*+action_controller.compile_config_methods+* Initializes methods for the config settings specified so that they are quicker to access.
+
+*+active_record.initialize_timezone+* Sets +ActiveRecord::Base.time_zone_aware_attributes+ to true, as well as setting +ActiveRecord::Base.default_timezone+ to UTC. When attributes are read from the database, they will be converted into the time zone specified by +Time.zone+.
+
+*+active_record.logger+* Sets +ActiveRecord::Base.logger+ -- if it's not already set -- to +Rails.logger+.
+
+*+active_record.set_configs+* Sets up Active Record by using the settings in +config.active_record+ by +send+'ing the method names as setters to +ActiveRecord::Base+ and passing the values through.
+
+*+active_record.initialize_database+* Loads the database configuration (by default) from +config/database.yml+ and establishes a connection for the current environment.
+
+*+active_record.log_runtime+* Includes +ActiveRecord::Railties::ControllerRuntime+ which is responsible for reporting the length of time Active Record calls took for the request back to the logger.
+
+*+active_record.set_dispatch_hooks+* If +config.cache_classes+ is set to false, all reloadable connections to the database will be reset.
+
+*+action_mailer.logger+* Sets +ActionMailer::Base.logger+ -- if it's not already set -- to +Rails.logger+.
+
+*+action_mailer.set_configs+* Sets up Action Mailer by using the settings in +config.action_mailer+ by +send+'ing the method names as setters to +ActionMailer::Base+ and passing the values through.
+
+*+action_mailer.compile_config_methods+* Initializes methods for the config settings specified so that they are quicker to access.
+
+*+active_resource.set_configs+* Sets up Active Resource by using the settings in +config.active_resource+ by +send+'ing the method names as setters to +ActiveResource::Base+ and passing the values through.
+
+*+set_load_path+* This initializer runs before +bootstrap_hook+. Adds the +vendor+, +lib+, all directories of +app+ and any paths specified by +config.load_paths+ to +$LOAD_PATH+.
+
+*+set_autoload_path+* This initializer runs before +bootstrap_hook+. Adds all sub-directories of +app+ and paths specified by +config.autoload_paths+ to +ActiveSupport::Dependencies.autoload_paths+.
+
+*+add_routing_paths+* Loads (by default) all +config/routes.rb+ files (in the application and railties, including engines) and sets up the routes for the application.
+
+*+add_locales+* Adds the files in +config/locales+ (from the application, railties and engines) to +I18n.load_path+, making available the translations in these files.
+
+*+add_view_paths+* Adds the directory +app/views+ from the application, railties and engines to the lookup path for view files for the application.
+
+*+load_environment_config+* Loads the +config/environments+ file for the current environment.
+
+*+append_asset_paths+* Finds asset paths for the application and all attached railties and keeps a track of the available directories in +config.static_asset_paths+.
+
+*+prepend_helpers_path+* Adds the directory +app/helpers+ from the application, railties and engines to the lookup path for helpers for the application.
+
+*+load_config_initializers+* Loads all Ruby files from +config/initializers+ in the application, railties and engines. The files in this directory can be used to hold configuration settings that should be made after all of the frameworks and plugins are loaded.
+
+NOTE: You can use subfolders to organize your initializers if you like, because Rails will look into the whole file hierarchy from the +initializers+ folder on down.
+
+TIP: If you have any ordering dependency in your initializers, you can control the load order by naming. For example, +01_critical.rb+ will be loaded before +02_normal.rb+.
+
+*+engines_blank_point+* Provides a point-in-initialization to hook into if you wish to do anything before engines are loaded. After this point, all railtie and engine initializers are ran.
+
+*+add_generator_templates+* Finds templates for generators at +lib/templates+ for the application, railities and engines and adds these to the +config.generators.templates+ setting, which will make the templates available for all generators to reference.
+
+*+ensure_autoload_once_paths_as_subset+* Ensures that the +config.autoload_once_paths+ only contains paths from +config.autoload_paths+. If it contains extra paths, then an exception will be raised.
+
+*+add_to_prepare_blocks+* The block for every +config.to_prepare+ call in the application, a railtie or engine is added to the +to_prepare+ callbacks for Action Dispatch which will be ran per request in development, or before the first request in production.
+
+*+add_builtin_route+* If the application is running under the development environment then this will append the route for +rails/info/properties+ to the application routes. This route provides the detailed information such as Rails and Ruby version for +public/index.html+ in a default Rails application.
+
+*+build_middleware_stack+* Builds the middleware stack for the application, returning an object which has a +call+ method which takes a Rack environment object for the request.
+
+*+eager_load!+* If +config.cache_classes+ is +true+, runs the +config.before_eager_load+ hooks and then calls +eager_load!+ which will load all the Ruby files from +config.eager_load_paths+.
+
+*+finisher_hook+* Provides a hook for after the initialization of process of the application is complete, as well as running all the +config.after_initialize+ blocks for the application, railties and engines.
+
+*+set_routes_reloader+* Configures Action Dispatch to reload the routes file using +ActionDispatch::Callbacks.to_prepare+.
+
+*+disable_dependency_loading+*
 
-* +ENV['RAILS_GEM_VERSION']+ defines the version of the Rails gems to use, if +RAILS_GEM_VERSION+ is not defined in your +environment.rb+ file.
 
 h3. Changelog
 
+* December 3, 2010: Added initialization events for Rails 3 ("Ryan Bigg":http://ryanbigg.com)
+* November 26, 2010: Removed all config settings not available in Rails 3 ("Ryan Bigg":http://ryanbigg.com)
 * August 13, 2009: Updated with config syntax and added general configuration options by "John Pignata"
 * January 3, 2009: First reasonably complete draft by "Mike Gunderloy":credits.html#mgunderloy
 * November 5, 2008: Rough outline by "Mike Gunderloy":credits.html#mgunderloy
diff --git a/railties/guides/source/contributing_to_rails.textile b/railties/guides/source/contributing_to_rails.textile
index f501335958..1a1f4e9858 100644
--- a/railties/guides/source/contributing_to_rails.textile
+++ b/railties/guides/source/contributing_to_rails.textile
@@ -105,12 +105,17 @@ mysql> GRANT ALL PRIVILEGES ON activerecord_unittest2.*
        to 'rails'@'localhost';
 </shell>
 
-Then ensure you run bundle install without the +--without db+ option:
+Now you'll have to install Active Record dependencies. This step is a little tricky because just running +bundle install+ without the +--without db+ parameter won't get those dependencies installed. It turns out that bundler remembers the +--without db+ parameter between calls so you'll have to manually override this. (See the "+bundle_install+ man page":http://gembundler.com/man/bundle-install.1.html for details)
+
+The easiest way to do this is to remove bundler's config file and then run +install+ again:
 
 <shell>
+rm .bundle/config
 bundle install
 </shell>
 
+INFO: If you don't feel comfortable deleting bundler's config file, you can achieve the same effect by manually removing the "+BUNDLE_WITHOUT: db+" line on +.bundle/config+.
+
 Finally, enter this from the +activerecord+ directory to create the test databases:
 
 <shell>
@@ -127,7 +132,7 @@ You can now run tests as you did for +sqlite3+:
 rake test_mysql
 </shell>
 
-You can also +myqsl+ with +postgresql+, +jdbcmysql+, +jdbcsqlite3+ or +jdbcpostgresql+. Check out the file +activerecord/RUNNING_UNIT_TESTS+ for information on running more targeted database tests, or the file +ci/ci_build.rb+ to see the test suite that the Rails continuous integration server runs.
+You can also replace +mysql+ with +postgresql+, +jdbcmysql+, +jdbcsqlite3+ or +jdbcpostgresql+. Check out the file +activerecord/RUNNING_UNIT_TESTS+ for information on running more targeted database tests, or the file +ci/ci_build.rb+ to see the test suite that the Rails continuous integration server runs.
 
 NOTE: If you're working with Active Record code, you _must_ ensure that the tests pass for at least MySQL, PostgreSQL, and SQLite 3. Subtle differences between the various Active Record database adapters have been behind the rejection of many patches that looked OK when tested only against MySQL.
 
diff --git a/railties/guides/source/debugging_rails_applications.textile b/railties/guides/source/debugging_rails_applications.textile
index 6613fad406..2c8a6619c2 100644
--- a/railties/guides/source/debugging_rails_applications.textile
+++ b/railties/guides/source/debugging_rails_applications.textile
@@ -48,7 +48,7 @@ Title: Rails debugging guide
 
 h4. +to_yaml+
 
-Displaying an instance variable, or any other object or method, in yaml format can be achieved this way:
+Displaying an instance variable, or any other object or method, in YAML format can be achieved this way:
 
 <html>
 <%= simple_format @post.to_yaml %>
@@ -122,7 +122,7 @@ It can also be useful to save information to log files at runtime. Rails maintai
 
 h4. What is the Logger?
 
-Rails makes use of Ruby's standard +logger+ to write log information. You can also substitute another logger such as +Log4R+ if you wish.
+Rails makes use of Ruby's standard +logger+ to write log information. You can also substitute another logger such as +Log4r+ if you wish.
 
 You can specify an alternative logger in your +environment.rb+ or any environment file:
 
@@ -178,7 +178,7 @@ class PostsController < ApplicationController
 
     if @post.save
       flash[:notice] = 'Post was successfully created.'
-      logger.debug "The post was saved and now is the user is going to be redirected..."
+      logger.debug "The post was saved and now the user is going to be redirected..."
       redirect_to(@post)
     else
       render :action => "new"
@@ -204,7 +204,7 @@ Post should be valid: true
   Post Create (0.000443)   INSERT INTO "posts" ("updated_at", "title", "body", "published",
  "created_at") VALUES('2008-09-08 14:52:54', 'Debugging Rails',
  'I''m learning how to print in logs!!!', 'f', '2008-09-08 14:52:54')
-The post was saved and now is the user is going to be redirected...
+The post was saved and now the user is going to be redirected...
 Redirected to #<Post:0x20af760>
 Completed in 0.01224 (81 reqs/sec) | DB: 0.00044 (3%) | 302 Found [http://localhost/posts]
 </shell>
@@ -601,7 +601,7 @@ There are some settings that can be configured in ruby-debug to make it easier t
 
 You can see the full list by using +help set+. Use +help set _subcommand_+ to learn about a particular +set+ command.
 
-TIP: You can include any number of these configuration lines inside a +.rdebugrc+ file in your HOME directory. ruby-debug will read this file every time it is loaded. and configure itself accordingly.
+TIP: You can include any number of these configuration lines inside a +.rdebugrc+ file in your HOME directory. ruby-debug will read this file every time it is loaded and configure itself accordingly.
 
 Here's a good start for an +.rdebugrc+:
 
@@ -615,7 +615,7 @@ h3. Debugging Memory Leaks
 
 A Ruby application (on Rails or not), can leak memory - either in the Ruby code or at the C code level.
 
-In this section, you will learn how to find and fix such leaks by using Bleak House and Valgrind debugging tools.
+In this section, you will learn how to find and fix such leaks by using tools such as BleakHouse and Valgrind.
 
 h4. BleakHouse
 
diff --git a/railties/guides/source/generators.textile b/railties/guides/source/generators.textile
index c0d3116fe4..6945f6f9bb 100644
--- a/railties/guides/source/generators.textile
+++ b/railties/guides/source/generators.textile
@@ -1,4 +1,4 @@
-h2. Creating and Customizing Rails Generators
+h2. Creating and Customizing Rails Generators & Templates
 
 Rails generators are an essential tool if you plan to improve your workflow. With this guide you will learn how to create generators and customize existing ones.
 
@@ -10,6 +10,7 @@ In this guide you will:
 * Customize your scaffold by creating new generators
 * Customize your scaffold by changing generator templates
 * Learn how to use fallbacks to avoid overwriting a huge set of generators
+* Learn how to create an application template
 
 endprologue.
 
@@ -45,6 +46,8 @@ class InitializerGenerator < Rails::Generators::Base
 end
 </ruby>
 
+NOTE: +create_file+ is a method provided by +Thor::Actions+ and the documentation for it and its brethren can be found at "rdoc.info":http://rdoc.info/github/wycats/thor/master/Thor/Actions.
+
 Our new generator is quite simple: it inherits from +Rails::Generators::Base+ and has one method definition. Each public method in the generator is executed when a generator is invoked. Finally, we invoke the +create_file+ method that will create a file at the given destination with the given content. If you are familiar with the Rails Application Templates API, you'll feel right at home with the new generators API.
 
 To invoke our new generator, we just need to do:
@@ -92,7 +95,7 @@ class InitializerGenerator < Rails::Generators::NamedBase
 end
 </ruby>
 
-First, notice that we are inheriting from +Rails::Generators::NamedBase+ instead of +Rails::Generators::Base+. This means that our generator expects at least one argument, which will be the name of the initializer.
+First, notice that we are inheriting from +Rails::Generators::NamedBase+ instead of +Rails::Generators::Base+. This means that our generator expects at least one argument, which will be the name of the initializer, and will be available in our code in the variable +name+.
 
 We can see that by invoking the description of this new generator (don't forget to delete the old generator file):
 
@@ -131,6 +134,8 @@ $ rails generate initializer core_extensions
 
 We can see that now a initializer named core_extensions was created at +config/initializers/core_extensions.rb+ with the contents of our template. That means that +copy_file+ copied a file in our source root to the destination path we gave. The method +file_name+ is automatically created when we inherit from +Rails::Generators::NamedBase+.
 
+The methods that are available for generators are covered in the "final section":#generator-methods of this guide.
+
 h3. Generators Lookup
 
 When you run +rails generate initializer core_extensions+ Rails requires these files in turn until one is found:
@@ -201,18 +206,18 @@ config.generators do |g|
 end
 </ruby>
 
-If we generate another resource with the scaffold generator, we can notice that neither stylesheets nor fixtures are created anymore. If you want to customize it further, for example to use DataMapper and RSpec instead of Active Record and TestUnit, it's just a matter of adding their gems to your application and configuring your generators.
+If we generate another resource with the scaffold generator, we can see that neither stylesheets nor fixtures are created anymore. If you want to customize it further, for example to use DataMapper and RSpec instead of Active Record and TestUnit, it's just a matter of adding their gems to your application and configuring your generators.
 
-To demonstrate this, we are going to create a new helper generator that simply adds some instance variable readers. First, we create a generator:
+To demonstrate this, we are going to create a new helper generator that simply adds some instance variable readers. First, we create a generator within the rails namespace, as this is where rails searches for generators used as hooks:
 
 <shell>
-$ rails generate generator my_helper
+$ rails generate generator rails/my_helper
 </shell>
 
 After that, we can delete both the +templates+ directory and the +source_root+ class method from our new generators, because we are not going to need them. So our new generator looks like the following:
 
 <ruby>
-class MyHelperGenerator < Rails::Generators::NamedBase
+class Rails::MyHelperGenerator < Rails::Generators::NamedBase
   def create_helper_file
     create_file "app/helpers/#{file_name}_helper.rb", <<-FILE
 module #{class_name}Helper
@@ -265,7 +270,7 @@ Since Rails 3.0, this is easy to do due to the hooks concept. Our new helper doe
 To do that, we can change the generator this way:
 
 <ruby>
-class MyHelperGenerator < Rails::Generators::NamedBase
+class Rails::MyHelperGenerator < Rails::Generators::NamedBase
   def create_helper_file
     create_file "app/helpers/#{file_name}_helper.rb", <<-FILE
 module #{class_name}Helper
@@ -278,7 +283,7 @@ end
 end
 </ruby>
 
-Now, when the helper generator is invoked and TestUnit is configured as the test framework, it will try to invoke both +MyHelper::Generators::TestUnitGenerator+ and +TestUnit::Generators::MyHelperGenerator+. Since none of those are defined, we can tell our generator to invoke +TestUnit::Generators::HelperGenerator+ instead, which is defined since it's a Rails generator. To do that, we just need to add:
+Now, when the helper generator is invoked and TestUnit is configured as the test framework, it will try to invoke both +Rails::TestUnitGenerator+ and +TestUnit::MyHelperGenerator+. Since none of those are defined, we can tell our generator to invoke +TestUnit::Generators::HelperGenerator+ instead, which is defined since it's a Rails generator. To do that, we just need to add:
 
 <ruby>
   # Search for :helper instead of :my_helper
@@ -361,8 +366,258 @@ $ rails generate scaffold Comment body:text
 
 Fallbacks allow your generators to have a single responsibility, increasing code reuse and reducing the amount of duplication.
 
+h3. Application templates
+
+Now that you've seen how generators can be used _inside_ an application, did you know they can also be used to _generate_ applications too? This kind of generator is referred as a "template".
+
+<ruby>
+  gem("rspec-rails", :group => "test")
+  gem("cucumber-rails", :group => "test")
+
+  if yes?("Would you like to install Devise?")
+    gem("devise")
+    generate("devise:install")
+    model_name = ask("What would you like the user model to be called? [user]")
+    model_name = "user" if model_name.blank?
+    generate("devise", model_name)
+  end
+</ruby>
+
+In the above template we specify that the application relies on the +rspec-rails+ and +cucumber-rails+ gem so these two will be added to the +test+ group in the +Gemfile+. Then we pose a question to the user about whether or not they would like to install Devise. If the user replies "y" or "yes" to this question, then the template will add Devise to the +Gemfile+ outside of any group and then runs the +devise:install+ generator. This template then takes the users input and runs the  +devise+ generator, with the user's answer from the last question being passed to this generator.
+
+Imagine that this template was in a file called +template.rb+. We can use it to modify the outcome of the +rails new+ command by using the +-m+ option and passing in the filename:
+
+<shell>
+  rails new thud -m template.rb
+</shell>
+
+This command will generate the +Thud+ application, and then apply the template to the generated output.
+
+Templates don't have to be stored on the local system, the +-m+ option also supports online templates:
+
+<shell>
+  rails new thud -m https://gist.github.com/722911
+</shell>
+
+Whilst the final section of this guide doesn't cover how to generate the most awesome template known to man, it will take you through the methods available at your disposal so that you can develop it yourself. These same methods are also available for generators.
+
+h3. Generator methods
+
+The following are methods available for both generators and templates for Rails. 
+
+NOTE: Methods provided by Thor are not covered this guide and can be found in "Thor's documentation":http://rdoc.info/github/wycats/thor/master/Thor/Actions.html
+
+h4. +plugin+
+
++plugin+ will install a plugin into the current application.
+
+<ruby>
+  plugin("dynamic-form", :git => "git://github.com/rails/dynamic-form.git")
+</ruby>
+
+Available options are:
+
+* +:git+ - Takes the path to the git repository where this plugin can be found.
+* +:branch+ - The name of the branch of the git repository where the plugin is found.
+* +:submodule+ - Set to +true+ for the plugin to be installed as a submodule. Defaults to +false+.
+* +:svn+ - Takes the path to the svn repository where this plugin can be found.
+* +:revision+ - The revision of the plugin in an SVN repository.
+
+h4. +gem+
+
+Specifies a gem dependency of the application.
+
+<ruby>
+  gem("rspec", :group => "test", :version => "2.1.0")
+  gem("devise", "1.1.5")
+</ruby>
+
+Available options are:
+
+* +:group+ - The group in the +Gemfile+ where this gem should go.
+* +:version+ - The version string of the gem you want to use. Can also be specified as the second argument to the method.
+* +:git+ - The URL to the git repository for this gem.
+
+Any additional options passed to this method are put on the end of the line:
+
+<ruby>
+  gem("devise", :git => "git://github.com/plataformatec/devise", :branch => "master")
+</ruby>
+
+The above code will put the following line into +Gemfile+:
+
+<ruby>
+  gem "devise", :git => "git://github.com/plataformatec/devise", :branch => "master"
+</ruby>
+
+
+h4. +add_source+
+
+Adds a specified source to +Gemfile+:
+
+<ruby>
+  add_source "http://gems.github.com"
+</ruby>
+
+h4. +application+
+
+Adds a line to +config/application.rb+ directly after the application class definition.
+
+<ruby>
+  application "config.asset_host = 'http://example.com'"
+</ruby>
+
+This method can also take a block:
+
+<ruby>
+  application do
+    "config.asset_host = 'http://example.com'"
+    end
+  end
+</ruby>
+
+Available options are:
+
+* +:env+ - Specify an environment for this configuration option. If you wish to use this option with the block syntax the recommended syntax is as follows:
+
+<ruby>
+  application(nil, :env => "development") do
+    "config.asset_host = 'http://localhost:3000'"
+  end
+</ruby>
+
+h4. +git+
+
+Runs the specified git command:
+
+<ruby>
+  git :init
+  git :add => "."
+  git :commit => "-m First commit!"
+  git :add => "onefile.rb", :rm => "badfile.cxx"
+</ruby>
+
+The values of the hash here being the arguments or options passed to the specific git command. As per the final example shown here, multiple git commands can be specified at a time, but the order of their running is not guaranteed to be the same as the order that they were specified in.
+
+h4. +vendor+
+
+Places a file into +vendor+ which contains the specified code.
+
+<ruby>
+  vendor("sekrit.rb", '#top secret stuff')
+</ruby>
+
+This method also takes a block:
+
+<ruby>
+  vendor("seeds.rb") do
+    "puts 'in ur app, seeding ur database'"
+  end
+</ruby>
+
+h4. +lib+
+
+Places a file into +lib+ which contains the specified code.
+
+<ruby>
+  lib("special.rb", 'p Rails.root')
+</ruby>
+
+This method also takes a block:
+
+<ruby>
+  lib("super_special.rb") do
+    puts "Super special!"
+  end
+</ruby>
+
+h4. +rakefile+
+
+Creates a Rake file in the +lib/tasks+ directory of the application.
+
+<ruby>
+  rakefile("test.rake", 'hello there')
+</ruby>
+
+This method also takes a block:
+
+<ruby>
+  rakefile("test.rake") do
+    %Q{
+     task :rock => :environment do
+       puts "Rockin'"
+     end 
+    }
+  end
+</ruby>
+
+h4. +initializer+
+
+Creates an initializer in the +config/initializers+ directory of the application:
+
+<ruby>
+  initializer("begin.rb", "puts 'this is the beginning'")
+</ruby>
+
+This method also takes a block:
+
+<ruby>
+  initializer("begin.rb") do
+    puts "Almost done!"
+  end
+</ruby>
+
+h4. +generate+
+
+Runs the specified generator where the first argument is the generator name and the remaining arguments are passed directly to the generator.
+
+<ruby>
+  generate("scaffold", "forums title:string description:text")
+</ruby>
+
+
+h4. +rake+
+
+Runs the specified Rake task.
+
+<ruby>
+  rake("db:migrate")
+</ruby>
+
+Available options are:
+
+* +:env+ - Specifies the environment in which to run this rake task.
+* +:sudo+ - Whether or not to run this task using +sudo+. Defaults to +false+.
+
+h4. +capify!+
+
+Runs the +capify+ command from Capistrano at the root of the application which generates Capistrano configuration.
+
+<ruby>
+  capify!
+</ruby>
+
+h4. +route+
+
+Adds text to the +config/routes.rb+ file:
+
+<ruby>
+  route("resources :people")
+</ruby>
+
+h4. +readme+
+
+Output the contents of a file in the template's +source_path+, usually a README.
+
+<ruby>
+  readme("README")
+</ruby>
+
 h3. Changelog
 
+* December 1, 2010: Documenting the available methods and options for generators and templates by "Ryan Bigg":http://ryanbigg.com
+* December 1, 2010: Addition of Rails application templates by "Ryan Bigg":http://ryanbigg.com
+
 * August 23, 2010: Edit pass by "Xavier Noria":credits.html#fxn
 
 * April 30, 2010: Reviewed by José Valim
diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index 902b7353c0..e371632d87 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -811,6 +811,8 @@ class CreateComments < ActiveRecord::Migration
 
       t.timestamps
     end
+
+    add_index :comments, :post_id
   end
 
   def self.down
@@ -819,7 +821,7 @@ class CreateComments < ActiveRecord::Migration
 end
 </ruby>
 
-The +t.references+ line sets up a foreign key column for the association between the two models. Go ahead and run the migration:
+The +t.references+ line sets up a foreign key column for the association between the two models. And the +add_index+ line sets up an index for this association column. Go ahead and run the migration:
 
 <shell>
 $ rake db:migrate
diff --git a/railties/guides/source/i18n.textile b/railties/guides/source/i18n.textile
index 825185c832..8a39bdf3c1 100644
--- a/railties/guides/source/i18n.textile
+++ b/railties/guides/source/i18n.textile
@@ -127,7 +127,7 @@ If you want to translate your Rails application to a *single language other than
 
 However, you would probably like to *provide support for more locales* in your application. In such case, you need to set and pass the locale between requests.
 
-WARNING: You may be tempted to store the chosen locale in a _session_ or a _cookie_. *Do not do so*. The locale should be transparent and a part of the URL. This way you don't break people's basic assumptions about the web itself: if you send a URL of some page to a friend, she should see the same page, same content. A fancy word for this would be that you're being "_RESTful_":http://en.wikipedia.org/wiki/Representational_State_Transfer. Read more about the RESTful approach in "Stefan Tilkov's articles":http://www.infoq.com/articles/rest-introduction. There may be some exceptions to this rule, which are discussed below.
+WARNING: You may be tempted to store the chosen locale in a _session_ or a <em>cookie</em>. *Do not do so*. The locale should be transparent and a part of the URL. This way you don't break people's basic assumptions about the web itself: if you send a URL of some page to a friend, she should see the same page, same content. A fancy word for this would be that you're being "<em>RESTful</em>":http://en.wikipedia.org/wiki/Representational_State_Transfer. Read more about the RESTful approach in "Stefan Tilkov's articles":http://www.infoq.com/articles/rest-introduction. There may be some exceptions to this rule, which are discussed below.
 
 The _setting part_ is easy. You can set the locale in a +before_filter+ in the +ApplicationController+ like this:
 
@@ -253,7 +253,7 @@ match '/:locale' => 'dashboard#index'
 
 Do take special care about the *order of your routes*, so this route declaration does not "eat" other ones. (You may want to add it directly before the +root :to+ declaration.)
 
-IMPORTANT: This solution has currently one rather big *downside*. Due to the _default_url_options_ implementation, you have to pass the +:id+ option explicitly, like this: +link_to 'Show', book_url(:id => book)+ and not depend on Rails' magic in code like +link_to 'Show', book+. If this should be a problem, have a look at two plugins which simplify work with routes in this way: Sven Fuchs's "routing_filter":http://github.com/svenfuchs/routing-filter/tree/master and Raul Murciano's "translate_routes":http://github.com/raul/translate_routes/tree/master. See also the page "How to encode the current locale in the URL":http://rails-i18n.org/wiki/wikipages/how-to-encode-the-current-locale-in-the-url in the Rails i18n Wiki.
+NOTE: Have a look at two plugins which simplify work with routes in this way: Sven Fuchs's "routing_filter":http://github.com/svenfuchs/routing-filter/tree/master and Raul Murciano's "translate_routes":http://github.com/raul/translate_routes/tree/master.
 
 h4. Setting the Locale from the Client Supplied Information
 
@@ -278,7 +278,7 @@ def extract_locale_from_accept_language_header
 end
 </ruby>
 
-Of course, in a production environment you would need much more robust code, and could use a plugin such as Iain Hecker's "http_accept_language":http://github.com/iain/http_accept_language/tree/master or even Rack middleware such as Ryan Tomayko's "locale":http://github.com/rtomayko/rack-contrib/blob/master/lib/rack/locale.rb.
+Of course, in a production environment you would need much more robust code, and could use a plugin such as Iain Hecker's "http_accept_language":http://github.com/iain/http_accept_language/tree/master or even Rack middleware such as Ryan Tomayko's "locale":http://github.com/rack/rack-contrib/blob/master/lib/rack/contrib/locale.rb.
 
 h5. Using GeoIP (or Similar) Database
 
@@ -464,24 +464,24 @@ I18n.t 'message'
 The +translate+ method also takes a +:scope+ option which can contain one or more additional keys that will be used to specify a “namespace” or scope for a translation key:
 
 <ruby>
-I18n.t :invalid, :scope => [:activerecord, :errors, :messages]
+I18n.t :record_invalid, :scope => [:activerecord, :errors, :messages]
 </ruby>
 
-This looks up the +:invalid+ message in the Active Record error messages.
+This looks up the +:record_invalid+ message in the Active Record error messages.
 
 Additionally, both the key and scopes can be specified as dot-separated keys as in:
 
 <ruby>
-I18n.translate :"activerecord.errors.messages.invalid"
+I18n.translate "activerecord.errors.messages.record_invalid"
 </ruby>
 
 Thus the following calls are equivalent:
 
 <ruby>
-I18n.t 'activerecord.errors.messages.invalid'
-I18n.t 'errors.messages.invalid', :scope => :active_record
-I18n.t :invalid, :scope => 'activerecord.errors.messages'
-I18n.t :invalid, :scope => [:activerecord, :errors, :messages]
+I18n.t 'activerecord.errors.messages.record_invalid'
+I18n.t 'errors.messages.record_invalid', :scope => :active_record
+I18n.t :record_invalid, :scope => 'activerecord.errors.messages'
+I18n.t :record_invalid, :scope => [:activerecord, :errors, :messages]
 </ruby>
 
 h5. Defaults
@@ -672,11 +672,11 @@ Active Record validation error messages can also be translated easily. Active Re
 
 This gives you quite powerful means to flexibly adjust your messages to your application's needs.
 
-Consider a User model with a +validates_presence_of+ validation for the name attribute like this:
+Consider a User model with a validation for the name attribute like this:
 
 <ruby>
 class User < ActiveRecord::Base
-  validates_presence_of :name
+  validates :name, :presence => true
 end
 </ruby>
 
@@ -697,7 +697,7 @@ activerecord.errors.models.user.attributes.name.blank
 activerecord.errors.models.user.blank
 activerecord.errors.messages.blank
 errors.attributes.name.blank
-errors.messagges.blank
+errors.messages.blank
 </ruby>
 
 When your models are additionally using inheritance then the messages are looked up in the inheritance chain.
@@ -706,7 +706,7 @@ For example, you might have an Admin model inheriting from User:
 
 <ruby>
 class Admin < User
-  validates_presence_of :name
+  validates :name, :presence => true
 end
 </ruby>
 
@@ -719,7 +719,7 @@ activerecord.errors.models.user.attributes.title.blank
 activerecord.errors.models.user.blank
 activerecord.errors.messages.blank
 errors.attributes.title.blank
-errors.messagges.blank
+errors.messages.blank
 </ruby>
 
 This way you can provide special translations for various error messages at different points in your models inheritance chain and in the attributes, models, or default scopes.
@@ -733,27 +733,27 @@ So, for example, instead of the default error message +"can not be blank"+ you c
 * +count+, where available, can be used for pluralization if present:
 
 |_. validation                 |_.with option              |_.message                  |_.interpolation|
-| validates_confirmation_of    | -                         | :confirmation             | -|
-| validates_acceptance_of      | -                         | :accepted                 | -|
-| validates_presence_of        | -                         | :blank                    | -|
-| validates_length_of          | :within, :in              | :too_short                | count|
-| validates_length_of          | :within, :in              | :too_long                 | count|
-| validates_length_of          | :is                       | :wrong_length             | count|
-| validates_length_of          | :minimum                  | :too_short                | count|
-| validates_length_of          | :maximum                  | :too_long                 | count|
-| validates_uniqueness_of      | -                         | :taken                    | -|
-| validates_format_of          | -                         | :invalid                  | -|
-| validates_inclusion_of       | -                         | :inclusion                | -|
-| validates_exclusion_of       | -                         | :exclusion                | -|
-| validates_associated         | -                         | :invalid                  | -|
-| validates_numericality_of    | -                         | :not_a_number             | -|
-| validates_numericality_of    | :greater_than             | :greater_than             | count|
-| validates_numericality_of    | :greater_than_or_equal_to | :greater_than_or_equal_to | count|
-| validates_numericality_of    | :equal_to                 | :equal_to                 | count|
-| validates_numericality_of    | :less_than                | :less_than                | count|
-| validates_numericality_of    | :less_than_or_equal_to    | :less_than_or_equal_to    | count|
-| validates_numericality_of    | :odd                      | :odd                      | -|
-| validates_numericality_of    | :even                     | :even                     | -|
+| confirmation    | -                         | :confirmation             | -|
+| acceptance      | -                         | :accepted                 | -|
+| presence        | -                         | :blank                    | -|
+| length          | :within, :in              | :too_short                | count|
+| length          | :within, :in              | :too_long                 | count|
+| length          | :is                       | :wrong_length             | count|
+| length          | :minimum                  | :too_short                | count|
+| length          | :maximum                  | :too_long                 | count|
+| uniqueness      | -                         | :taken                    | -|
+| format          | -                         | :invalid                  | -|
+| inclusion       | -                         | :inclusion                | -|
+| exclusion       | -                         | :exclusion                | -|
+| associated      | -                         | :invalid                  | -|
+| numericality    | -                         | :not_a_number             | -|
+| numericality    | :greater_than             | :greater_than             | count|
+| numericality    | :greater_than_or_equal_to | :greater_than_or_equal_to | count|
+| numericality    | :equal_to                 | :equal_to                 | count|
+| numericality    | :less_than                | :less_than                | count|
+| numericality    | :less_than_or_equal_to    | :less_than_or_equal_to    | count|
+| numericality    | :odd                      | :odd                      | -|
+| numericality    | :even                     | :even                     | -|
 
 h5. Translations for the Active Record +error_messages_for+ Helper
 
@@ -830,7 +830,7 @@ In other contexts you might want to change this behaviour, though. E.g. the defa
 
 <ruby>
 module I18n
-  def just_raise_that_exception(*args)
+  def self.just_raise_that_exception(*args)
     raise args.first
   end
 end
diff --git a/railties/guides/source/initialization.textile b/railties/guides/source/initialization.textile
index 4cc5f3843f..72e10191f9 100644
--- a/railties/guides/source/initialization.textile
+++ b/railties/guides/source/initialization.textile
@@ -1,79 +1,140 @@
 h2. The Rails Initialization Process
 
-This guide explains how the initialization process in Rails works as of Rails 3.
+This guide explains the internals of the initialization process in Rails works as of Rails 3.1. It is an extremely in-depth guide and recommended for advanced Rails developers.
 
 * Using +rails server+
 * Using Passenger
 
 endprologue.
 
-This guide first describes the process of +rails server+ then explains the Passenger + Rack method, before delving into the common initialize pattern these two go through.
+This guide goes through every single file, class and method call that is required to boot up the Ruby on Rails stack for a default Rails 3.1 application, explaining each part in detail a long the way. For this guide, we will be focusing on how the two most common methods (+rails server+ and Passenger) boot a Rails application.
+
+NOTE: Paths in this guide are relative to Rails or a Rails application unless otherwise specified.
 
 h3. Launch!
 
 As of Rails 3, +script/server+ has become +rails server+. This was done to centralize all rails related commands to one common file.
 
-The actual +rails+ command is kept in _railties/bin/rails_ and goes like this:
+h4. +bin/rails+
+
+The actual +rails+ command is kept in _bin/rails_ at the and goes like this:
 
 <ruby>
-  require 'rbconfig'
+  #!/usr/bin/env ruby
 
-  module Rails
-    module ScriptRailsLoader
-      RUBY = File.join(*RbConfig::CONFIG.values_at("bindir", "ruby_install_name")) + RbConfig::CONFIG["EXEEXT"]
-      SCRIPT_RAILS = File.join('script', 'rails')
-
-      def self.exec_script_rails!
-        cwd = Dir.pwd
-        exec RUBY, SCRIPT_RAILS, *ARGV if File.exists?(SCRIPT_RAILS)
-        Dir.chdir("..") do
-          # Recurse in a chdir block: if the search fails we want to be sure
-          # the application is generated in the original working directory.
-          exec_script_rails! unless cwd == Dir.pwd
-        end
-      rescue SystemCallError
-        # could not chdir, no problem just return
-      end
-    end
+  begin
+    require "rails/cli"
+  rescue LoadError
+    railties_path = File.expand_path('../../railties/lib', __FILE__)
+    $:.unshift(railties_path)
+    require "rails/cli"
   end
+</ruby>
 
-  Rails::ScriptRailsLoader.exec_script_rails!
+This file will attempt to load +rails/cli+ and if it cannot find it then add the +railties/lib+ path to the load path (+$:+) and will then try to require it again. 
 
-  railties_path = File.expand_path('../../lib', __FILE__)
-  $:.unshift(railties_path) if File.directory?(railties_path) && !$:.include?(railties_path)
+h4. +railites/lib/rails/cli.rb+
+
+This file looks like this:
+
+<ruby>
+  require 'rbconfig'
+  require 'rails/script_rails_loader'
+
+  # If we are inside a Rails application this method performs an exec and thus
+  # the rest of this script is not run.
+  Rails::ScriptRailsLoader.exec_script_rails!
 
   require 'rails/ruby_version_check'
   Signal.trap("INT") { puts; exit }
 
-  require 'rails/commands/application'
+  if ARGV.first == 'plugin'
+    ARGV.shift
+    require 'rails/commands/plugin_new'
+  else
+    require 'rails/commands/application'
+  end
 </ruby>
 
-The +Rails::ScriptRailsLoader+ module here defines two constants: +RUBY+ and +SCRIPT_RAILS+. +RUBY+ is the full path to your ruby executable, on a Snow Leopard system it's _/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_. +SCRIPT_RAILS+ is simply _script/rails_. When +exec_script_rails+ is invoked, this will attempt to +exec+ the _rails_ file in the _script_ directory using the path to your Ruby executable, +RUBY+. If +exec+ is invoked, the program will stop at this point. If the _script/rails_ file doesn't exist in the current directory, Rails will recurse upwards until it finds it by calling +exec_script_rails+ from inside the +Dir.chdir("..")+. This is handy if you're currently in one of the sub-directories of the rails application and wish to launch a server or a console.
+The +rbconfig+ file here is out of Ruby's standard library and provides us with the +RbConfig+ class which contains useful information dependent on how Ruby was compiled. We'll see this in use in +railties/lib/rails/script_rails_loader+.
+
+<ruby>
+require 'pathname'
+
+module Rails
+  module ScriptRailsLoader
+    RUBY = File.join(*RbConfig::CONFIG.values_at("bindir", "ruby_install_name")) + RbConfig::CONFIG["EXEEXT"]
+    SCRIPT_RAILS = File.join('script', 'rails')
+    ...
 
-If Rails cannot execute _script/rails_ then it will fall back to the standard +rails+ command task of generating an application.
+  end
+end
+</ruby>
+
+The +rails/script_rails_loader+ file uses +RbConfig::Config+ to gather up the +bin_dir+ and +ruby_install_name+ values for the configuration which will result in a path such as +/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby+, which is the default path on Mac OS X. If you're running Windows the path may be something such as +C:/Ruby192/bin/ruby+. Anyway, the path on your system may be different, but the point of this is that it will point at the known ruby executable location for your install. The +RbConfig::CONFIG["EXEEXT"]+ will suffix this path with ".exe" if the script is running on Windows. This constant is used later on in +exec_script_rails!+. As for the +SCRIPT_RAILS+ console, we'll see that when we get to the +in_rails_application?+ method.
 
-In +script/rails+ we see the following:
+Back in +rails/cli+, the next line is this:
 
 <ruby>
-  #!/usr/bin/env ruby
-  # This command will automatically be run when you run "rails" with Rails 3 gems installed from the root of your application.
+  Rails::ScriptRailsLoader.exec_script_rails!
+</ruby>
 
-  APP_PATH = File.expand_path('../../config/application',  __FILE__)
-  require File.expand_path('../../config/boot',  __FILE__)
-  require 'rails/commands'
+This method is defined in +rails/script_rails_loader+ like this:
+
+<ruby>
+  def self.exec_script_rails!
+    cwd = Dir.pwd
+    return unless in_rails_application? || in_rails_application_subdirectory?
+    exec RUBY, SCRIPT_RAILS, *ARGV if in_rails_application?
+    Dir.chdir("..") do
+      # Recurse in a chdir block: if the search fails we want to be sure
+      # the application is generated in the original working directory.
+      exec_script_rails! unless cwd == Dir.pwd
+    end
+  rescue SystemCallError
+    # could not chdir, no problem just return
+  end
 </ruby>
 
-This obviously defines a couple of constants to some pretty important files, _config/environment.rb_, _config/boot.rb_ and _config/application.rb_ all within the context of +__FILE__+ which is of course +script/rails+ in the root of your application. Then it goes on to +require BOOT_PATH+ which leads us onto _config/boot.rb_.
+This method will first check if the current working directory (+cwd+) is a Rails application or is a subdirectory of one. The way to determine this is defined in the +in_rails_application?+ method like this:
 
-h3. Passenger
+<ruby>
+  def self.in_rails_application?
+    File.exists?(SCRIPT_RAILS)
+  end
+</ruby>
 
-Before we dive into what _config/boot.rb_ encompasses, we'll just glimpse at what Passenger does enough to get an understanding of how it requires a Rails application.
+The +SCRIPT_RAILS+ constant defined earlier is used here, with +File.exists?+ checking for its presence in the current directory. If this method returns +false+, then +in_rails_application_subdirectory?+ will be used:
+
+<ruby>
+  def self.in_rails_application_subdirectory?(path = Pathname.new(Dir.pwd))
+    File.exists?(File.join(path, SCRIPT_RAILS)) || !path.root? && in_rails_application_subdirectory?(path.parent)
+  end
+</ruby>
+
+This climbs the directory tree until it reaches a path which contains a +script/rails+ file. If a directory is reached which contains this file then this line will run:
+
+<ruby>
+  exec RUBY, SCRIPT_RAILS, *ARGV if in_rails_application?
+</ruby>
+
+This is effectively the same as doing +ruby script/rails [arguments]+. Where +[arguments]+ at this point in time is simply "server".
+
+h4. +script/rails+ 
+
+This file looks like this:
+
+<ruby>
+  APP_PATH = File.expand_path('../../config/application',  __FILE__)
+  require File.expand_path('../../config/boot',  __FILE__)
+  require 'rails/commands'
+</ruby>
 
-Passenger will require _config/environment.rb_ by way of its +PhusionPassenger::Railz::ApplicationSpawner#preload_application+ method. _config/environment.rb_ requires _config/application.rb_ which requires _config/boot.rb_. That's how the Rails boot process begins with Passenger in a nutshell.
+The +APP_PATH+ constant here will be used later in +rails/commands+. The +config/boot+ file that +script/rails+ references is the +config/boot.rb+ file in our application which is responsible for loading Bundler and setting it up.
 
-h3. _config/boot.rb_
+h4. +config/boot.rb+
 
-_config/boot.rb_ is the first stop for everything for initializing your application. This boot process does quite a bit of work for you and so this section attempts to go in-depth enough to explain what each of the pieces does.
++config/boot.rb+ contains this:
 
 <ruby>
   require 'rubygems'
@@ -91,134 +152,345 @@ _config/boot.rb_ is the first stop for everything for initializing your applicat
   end if File.exist?(gemfile)
 </ruby>
 
-h3. Bundled Rails (3.x)
+In a standard Rails application, there's a +Gemfile+ which declares all dependencies of the application. +config/boot.rb+ sets +ENV["BUNDLE_GEMFILE"]+ to the location of this file, then requires Bundler and calls +Bundler.setup+ which adds the dependencies of the application (including all the Rails parts) to the load path, making them available for the application to load. The gems that a Rails 3.1 application depends on are as follows:
+
+* abstract (1.0.0)
+* actionmailer (3.1.0.beta)
+* actionpack (3.1.0.beta)
+* activemodel (3.1.0.beta)
+* activerecord (3.1.0.beta)
+* activeresource (3.1.0.beta)
+* activesupport (3.1.0.beta)
+* arel (2.0.7)
+* builder (3.0.0)
+* bundler (1.0.6)
+* erubis (2.6.6)
+* i18n (0.5.0)
+* mail (2.2.12)
+* mime-types (1.16)
+* polyglot (0.3.1)
+* rack (1.2.1)
+* rack-cache (0.5.3)
+* rack-mount (0.6.13)
+* rack-test (0.5.6)
+* rails (3.1.0.beta)
+* railties (3.1.0.beta)
+* rake (0.8.7)
+* sqlite3-ruby (1.3.2)
+* thor (0.14.6)
+* treetop (1.4.9)
+* tzinfo (0.3.23)
+
+h4. +rails/commands.rb+
+
+Once +config/boot.rb+ has finished, the next file that is required is +rails/commands+ which will execute a command based on the arguments passed in. In this case, the +ARGV+ array simply contains +server+ which is extracted into the +command+ variable using these lines:
+
+<ruby>
+  aliases = {
+    "g"  => "generate",
+    "c"  => "console",
+    "s"  => "server",
+    "db" => "dbconsole"
+  }
+
+  command = ARGV.shift
+  command = aliases[command] || command
+</ruby>
+
+If we used <tt>s</tt> rather than +server+, Rails will use the +aliases+ defined in the file and match them to their respective commands. With the +server+ command, Rails will run this code:
+
+<ruby>
+  when 'server'
+    # Change to the application's path if there is no config.ru file in current dir.
+    # This allows us to run script/rails server from other directories, but still get
+    # the main config.ru and properly set the tmp directory.
+    Dir.chdir(File.expand_path('../../', APP_PATH)) unless File.exists?(File.expand_path("config.ru"))
+
+    require 'rails/commands/server'
+    Rails::Server.new.tap { |server|
+      # We need to require application after the server sets environment,
+      # otherwise the --environment option given to the server won't propagate.
+      require APP_PATH
+      Dir.chdir(Rails.application.root)
+      server.start
+    }
+</ruby>
+
+This file will change into the root of the directory (a path two directories back from +APP_PATH+ which points at +config/application.rb+), but only if the +config.ru+ file isn't found. This then requires +rails/commands/server+ which requires +action_dispatch+ and sets up the +Rails::Server+ class.
+
+h4. +actionpack/lib/action_dispatch.rb+
+
+Action Dispatch is the routing component of the Rails framework. It depends on Active Support, +actionpack/lib/action_pack.rb+ and +Rack+ being available. The first thing required here is +active_support+.
+
+h4. +active_support/lib/active_support.rb+
+
+This file begins with requiring +active_support/lib/active_support/dependencies/autoload.rb+ which redefines Ruby's +autoload+ method to have a little more extra behaviour especially in regards to eager autoloading. Eager autoloading is the loading of all required classes and  will happen when the +config.cache_classes+ setting is +true+.
 
+The +active_support/lib/active_support/version.rb+ that is also required here simply defines an +ActiveSupport::VERSION+ constant which defines a couple of constants inside this module, the main constant of this is +ActiveSupport::VERSION::STRING+ which returns the current version of ActiveSupport.
 
-Rails 3 now uses Bundler and the README for the project explains it better than I could:
+The +active_support/lib/active_support.rb+ file simply defines the +ActiveSupport+ module and some autoloads (eager and of the normal variety) for it.
 
-> "Bundler is a tool that manages gem dependencies for your ruby application. It takes a gem manifest file and is able to fetch, download, and install the gems and all child dependencies specified in this manifest. It can manage any update to the gem manifest file and update the bundle's gems accordingly. It also lets you run any ruby code in context of the bundle's gem environment."
+h4. +actionpack/lib/action_dispatch.rb+ cont'd.
 
-Now with Rails 3 we have a Gemfile which defines the basics our application needs to get going:
+Now back to +action_pack/lib/action_dispatch.rb+. The next +require+ in this file is one for +action_pack+, which simply calls +action_pack/version.rb+ which defines +ActionPack::VERSION+ and the constants, much like +ActiveSpport+ does.
+
+After this line, there's a require to +active_model+ which simply defines autoloads for the +ActiveModel+ part of Rails and sets up the +ActiveModel+ module which is used later on.
+
+The last of the requires is to +rack+, which like the +active_model+ and +active_support+ requires before it, sets up the +Rack+ module as well as the autoloads for constants within it. 
+
+Finally in +action_dispatch.rb+ the +ActionDispatch+ module and *its* autoloads are declared.
+
+h4. +rails/commands/server.rb+
+
+The +Rails::Server+ class is defined in this file as inheriting from +Rack::Server+. When +Rails::Server.new+ is called, this calls the +initialize+ method in +rails/commands/server.rb+:
 
 <ruby>
-  source 'http://rubygems.org'
+  def initialize(*)
+    super
+    set_environment
+  end
+</ruby>
 
-  gem 'rails', '3.0.0'
+Firstly, +super+ is called which calls the +initialize+ method on +Rack::Server+.
 
-  # Bundle edge Rails instead:
-  # gem 'rails', :git => 'git://github.com/rails/rails.git'
+h4. Rack: +lib/rack/server.rb+
 
-  gem 'sqlite3-ruby', :require => 'sqlite3'
++Rack::Server+ is responsible for providing a common server interface for all Rack-based applications, which Rails is now a part of.
 
-  # Use unicorn as the web server
-  # gem 'unicorn'
+The +initialize+ method in +Rack::Server+ simply sets a couple of variables:
 
-  # Deploy with Capistrano
-  # gem 'capistrano'
+<ruby>
+  def initialize(options = nil)
+    @options = options
+    @app = options[:app] if options && options[:app]
+  end
+</ruby>
 
-  # Bundle the extra gems:
-  # gem 'bj'
-  # gem 'nokogiri'
-  # gem 'sqlite3-ruby', :require => 'sqlite3'
-  # gem 'aws-s3', :require => 'aws/s3'
+In this case, +options+ will be +nil+ so nothing happens in this method.
 
-  # Bundle gems for certain environments:
-  # gem 'rspec', :group => :test
-  # group :test do
-  #   gem 'webrat'
-  # end
+After +super+ has finished in +Rack::Server+, we jump back to +rails/commands/server.rb+. At this point, +set_environment+ is called within the context of the +Rails::Server+ object and this method doesn't appear to do much at first glance:
 
+<ruby>
+  def set_environment
+    ENV["RAILS_ENV"] ||= options[:environment]
+  end
 </ruby>
 
-Here the only two gems we need are +rails+ and +sqlite3-ruby+, so it seems. This is until you run +bundle pack+. This command freezes all the gems required by your application into _vendor/cache_. The gems installed by default are:
+In fact, the +options+ method here does quite a lot. This method is defined in +Rack::Server+ like this:
 
-* abstract-1.0.0.gem
-* actionmailer-3.0.0.gem
-* actionpack-3.0.0.gem
-* activemodel-3.0.0.gem
-* activerecord-3.0.0.gem
-* activeresource-3.0.0.gem
-* activesupport-3.0.0.gem
-* arel-0.4.0.gem
-* builder-2.1.2.gem
-* bundler-1.0.3.gem
-* erubis-2.6.6.gem
-* i18n-0.4.1.gem
-* mail-2.2.5.gem
-* memcache-client-1.8.5.gem
-* mime-types-1.16.gem
-* nokogiri-1.4.3.1.gem
-* polyglot-0.3.1.gem
-* rack-1.2.1.gem
-* rack-mount-0.6.12.gem
-* rack-test-0.5.4.gem
-* rails-3.0.0.gem
-* railties-3.0.0.gem
-* rake-0.8.7.gem
-* sqlite3-ruby-1.3.1.gem
-* text-format-1.0.0.gem
-* text-hyphen-1.0.0.gem
-* thor-0.13.7.gem
-* treetop-1.4.8.gem
-* tzinfo-0.3.23.gem
+<ruby>
+  def options
+    @options ||= parse_options(ARGV)
+  end
+</ruby>
 
-TODO: Prettify when it becomes more stable.
+Then +parse_options+ is defined like this:
 
-I won't go into what each of these gems are, as that is really something that needs covering on a case-by-case basis. We will however just dig a little under the surface of Bundler.
+<ruby>
+  def parse_options(args)
+    options = default_options
 
-Back in _config/boot.rb_, we call +Bundler.setup+ which will load and parse the +Gemfile+ and add the _lib_ directory of the gems mentioned **and** their dependencies (**and** their dependencies' dependencies, and so on) to the +$LOAD_PATH+.
+    # Don't evaluate CGI ISINDEX parameters.
+    # http://hoohoo.ncsa.uiuc.edu/cgi/cl.html
+    args.clear if ENV.include?("REQUEST_METHOD")
 
-h3. Requiring Rails
+    options.merge! opt_parser.parse! args
+    options[:config] = ::File.expand_path(options[:config])
+    ENV["RACK_ENV"] = options[:environment]
+    options
+  end
+</ruby>
 
-After _config/boot.rb_ is loaded, there's this +require+:
+With the +default_options+ set to this:
 
 <ruby>
-  require 'rails/commands'
+  def default_options
+    {
+      :environment => ENV['RACK_ENV'] || "development",
+      :pid         => nil,
+      :Port        => 9292,
+      :Host        => "0.0.0.0",
+      :AccessLog   => [],
+      :config      => "config.ru"
+    }
+  end
 </ruby>
 
-In this file, _railties/lib/rails/commands.rb_, there is a case statement for +ARGV.shift+:
+There is no +REQUEST_METHOD+ key in +ENV+ so we can skip over that line. The next line merges in the options from +opt_parser+ which is defined plainly in +Rack::Server+
 
 <ruby>
-  case ARGV.shift
-  ...
-  when 's', 'server'
-    require 'rails/commands/server'
-    # Initialize the server first, so environment options are set
-    server = Rails::Server.new
-    require APP_PATH
+  def opt_parser
+    Options.new
+  end
+</ruby>
+
+The class *is* defined in +Rack::Server+, but is overwritten in +Rails::Server+ to take different arguments. Its +parse!+ method begins like this:
+
+<ruby>
+  def parse!(args)
+    args, options = args.dup, {}
+
+    opt_parser = OptionParser.new do |opts|
+      opts.banner = "Usage: rails server [mongrel, thin, etc] [options]"
+      opts.on("-p", "--port=port", Integer,
+              "Runs Rails on the specified port.", "Default: 3000") { |v| options[:Port] = v }
   ...
+</ruby>
+
+This method will set up keys for the +options+ which Rails will then be able to use to determine how its server should run. After +initialize+ has finished, then the +start+ method will launch the server. 
+
+h4. +Rails::Server#start+
+
+This method is defined like this:
+
+<ruby>
+  def start
+    puts "=> Booting #{ActiveSupport::Inflector.demodulize(server)}"
+    puts "=> Rails #{Rails.version} application starting in #{Rails.env} on http://#{options[:Host]}:#{options[:Port]}"
+    puts "=> Call with -d to detach" unless options[:daemonize]
+    trap(:INT) { exit }
+    puts "=> Ctrl-C to shutdown server" unless options[:daemonize]
+
+    #Create required tmp directories if not found
+    %w(cache pids sessions sockets).each do |dir_to_make|
+      FileUtils.mkdir_p(Rails.root.join('tmp', dir_to_make))
+    end
+
+    super
+  ensure
+    # The '-h' option calls exit before @options is set.
+    # If we call 'options' with it unset, we get double help banners.
+    puts 'Exiting' unless @options && options[:daemonize]
   end
 </ruby>
 
-We're running +rails server+ and this means it will make a require out to _rails/commands/server_ (_railties/lib/rails/commands/server.rb_). Firstly, this file makes a couple of requires of its own:
+This is where the first output of the Rails initialization happens. This method creates a trap for +INT+ signals, so if you +CTRL+C+ the server, it will exit the process. As we can see from the code here, it will create the +tmp/cache+, +tmp/pids+, +tmp/sessions+ and +tmp/sockets+ directories if they don't already exist prior to calling +super+. The +super+ method will call +Rack::Server.start+ which begins its definition like this:
+
+<ruby>
+  def start
+    if options[:warn]
+      $-w = true
+    end
+
+    if includes = options[:include]
+      $LOAD_PATH.unshift(*includes)
+    end
+
+    if library = options[:require]
+      require library
+    end
+
+    if options[:debug]
+      $DEBUG = true
+      require 'pp'
+      p options[:server]
+      pp wrapped_app
+      pp app
+    end
+</ruby>
+
+In a Rails application, these options are not set at all and therefore aren't used at all. The first line of code that's executed in this method is a call to this method:
 
 <ruby>
-  require 'fileutils'
-  require 'optparse'
-  require 'action_dispatch'
+  wrapped_app
 </ruby>
 
-The first two are Ruby core and this guide does not cover what they do, but _action_dispatch_ (_actionpack/lib/action_dispatch.rb_) is important. This file firstly make a require to _active_support_ (_activesupport/lib/active_support.rb_) which defines the +ActiveSupport+ module.
+This method calls another method:
 
-h4. +require 'active_support'+
+<ruby>
+  @wrapped_app ||= build_app app
+</ruby>
 
-_activesupport/lib/active_support.rb_ sets up +module ActiveSupport+:
+Then the +app+ method here is defined like so:
 
 <ruby>
-  module ActiveSupport
-    class << self
-      attr_accessor :load_all_hooks
-      def on_load_all(&hook) load_all_hooks << hook end
-      def load_all!; load_all_hooks.each { |hook| hook.call } end
+  def app
+    @app ||= begin
+      if !::File.exist? options[:config]
+        abort "configuration #{options[:config]} not found"
+      end
+
+      app, options = Rack::Builder.parse_file(self.options[:config], opt_parser)
+      self.options.merge! options
+      app
     end
-    self.load_all_hooks = []
+  end
+</ruby>
+
+The +options[:config]+ value defaults to +config.ru+ which contains this:
+
+<ruby>
+  # This file is used by Rack-based servers to start the application.
+
+  require ::File.expand_path('../config/environment',  __FILE__)
+  run YourApp::Application
+</ruby>
+
+
+The +Rack::Builder.parse_file+ method here takes the content from this +config.ru+ file and parses it using this code:
+
+<ruby>
+  app = eval "Rack::Builder.new {( " + cfgfile + "\n )}.to_app",
+    TOPLEVEL_BINDING, config
+</ruby>
+
+The <ruby>initialize</ruby> method will take the block here and execute it within an instance of +Rack::Builder+. This is where the majority of the initialization process of Rails happens. The chain of events that this simple line sets off will be the focus of a large majority of this guide. The +require+ line for +config/environment.rb+ in +config.ru+ is the first to run:
+
+<ruby>
+  require ::File.expand_path('../config/environment',  __FILE__)
+</ruby>
+
+h4. +config/environment.rb+
+
+This file is the common file required by +config.ru+ (+rails server+) and Passenger. This is where these two ways to run the server meet; everything before this point has been Rack and Rails setup.
+
+This file begins with requiring +config/application.rb+.
+
+h4. +config/application.rb+
+
+This file requires +config/boot.rb+, but only if it hasn't been required before, which would be the case in +rails server+ but *wouldn't* be the case with Passenger. 
+
+Then the fun begins! The next line is:
 
-    on_load_all do
-      [Dependencies, Deprecation, Gzip, MessageVerifier, Multibyte, SecureRandom]
+<ruby>
+  require 'rails/all'
+</ruby>
+
+h4 +railties/lib/rails/all.rb+
+
+
+This file is responsible for requiring all the individual parts of Rails like so:
+
+<ruby>
+  require "rails"
+
+  %w(
+    active_record
+    action_controller
+    action_mailer
+    active_resource
+    rails/test_unit
+  ).each do |framework|
+    begin
+      require "#{framework}/railtie"
+    rescue LoadError
     end
   end
 </ruby>
 
+First off the line is the +rails+ require itself.
+
+h4. +railties/lib/rails.rb+
+
+This file is responsible for the initial definition of the +Rails+ module and, rather than defining the autoloads like +ActiveSupport+, +ActionDispatch+ and so on, it actually defines other functionality. Such as the +root+, +env+ and +application+ methods which are extremely useful in Rails 3 applications.
+
+However, before all that takes place the +rails/ruby_version_check+ file is required first.
+
+
+
+
+**** REVIEW IS HERE ****
+
 This defines two methods on the module itself by using the familiar +class << self+ syntax. This allows you to call them as if they were class methods: +ActiveSupport.on_load_all+ and +ActiveSupport.load_all!+ respectively. The first method simply adds loading hooks to save them up for loading later on when +load_all!+ is called. By +call+'ing the block, the classes will be loaded. (NOTE: kind of guessing, I feel 55% about this).
 
 The +on_load_all+ method is called later with the +Dependencies+, +Deprecation+, +Gzip+, +MessageVerifier+, +Multibyte+ and +SecureRandom+. What each of these modules do will be covered later.
diff --git a/railties/guides/source/layouts_and_rendering.textile b/railties/guides/source/layouts_and_rendering.textile
index 80a1fdd38d..4cdd4f2709 100644
--- a/railties/guides/source/layouts_and_rendering.textile
+++ b/railties/guides/source/layouts_and_rendering.textile
@@ -106,7 +106,7 @@ Perhaps the simplest thing you can do with +render+ is to render nothing at all:
 render :nothing => true
 </ruby>
 
-If you look at the response for this using Curl you will see the following:
+If you look at the response for this using cURL, you will see the following:
 
 <shell>
  $ curl -i 127.0.0.1:3000/books
@@ -123,7 +123,7 @@ Cache-Control: no-cache
  $
 </shell>
 
-We see there is an empty response (no data after the +Cache-Control+ line), but the request was successful because Rails has set the response to 200 OK.  You can set the +:status+ options on render to change this response. Rendering nothing can be useful for AJAX requests where all you want to send back to the browser is an acknowledgement that the request was completed.
+We see there is an empty response (no data after the +Cache-Control+ line), but the request was successful because Rails has set the response to 200 OK. You can set the +:status+ option on render to change this response. Rendering nothing can be useful for AJAX requests where all you want to send back to the browser is an acknowledgement that the request was completed.
 
 TIP: You should probably be using the +head+ method, discussed later in this guide, instead of +render :nothing+. This provides additional flexibility and makes it explicit that you're only generating HTTP headers.
 
@@ -346,7 +346,7 @@ render :status => 500
 render :status => :forbidden
 </ruby>
 
-Rails understands either numeric status codes or symbols for status codes. You can find its list of status codes in +actionpack/lib/action_controller/status_codes.rb+. You can also see there how Rails maps symbols to status codes.
+Rails understands both numeric status codes and symbols for status codes.
 
 h6. The +:location+ Option
 
@@ -604,7 +604,7 @@ Which would detect that there are no books, populate the +@books+ instance varia
 
 h4. Using +head+ To Build Header-Only Responses
 
-The +head+ method exists to let you send back responses to the browser that have only headers. It provides a more obvious alternative to calling +render :nothing+. The +head+ method takes one response, which is interpreted as a hash of header names and values. For example, you can return only an error header:
+The +head+ method can be used to send responses with only headers to the browser. It provides a more obvious alternative to calling +render :nothing+. The +head+ method takes one parameter, which is interpreted as a hash of header names and values. For example, you can return only an error header:
 
 <ruby>
 head :bad_request
@@ -651,11 +651,9 @@ When Rails renders a view as a response, it does so by combining the view with t
 * +yield+ and +content_for+
 * Partials
 
-I'll discuss each of these in turn.
-
 h4. Asset Tags
 
-Asset tags provide methods for generating HTML that links views to assets like images, videos, audio, JavaScript, stylesheets, and feeds. There are six types of include tag:
+Asset tags provide methods for generating HTML that links views to feeds, JavaScript, stylesheets, images, videos and audios. These are the six asset tags available in Rails:
 
 * +auto_discovery_link_tag+
 * +javascript_include_tag+
@@ -680,7 +678,7 @@ The +auto_discovery_link_tag+ helper builds HTML that most browsers and newsread
 There are three tag options available for +auto_discovery_link_tag+:
 
 * +:rel+ specifies the +rel+ value in the link (defaults to "alternate")
-* +:type+ specifies an explicit MIME type. Rails will generate an appropriate MIME type automatically
+* +:type+ specifies an explicit MIME type. Rails will generate an appropriate MIME type automatically.
 * +:title+ specifies the title of the link
 
 h5. Linking to Javascript Files with +javascript_include_tag+
@@ -829,7 +827,7 @@ You can also supply an alternate image to show on mouseover:
 <%= image_tag "home.gif", :onmouseover => "menu/home_highlight.gif" %>
 </erb>
 
-Or alternate text if the user has rendering images turned off in their browser, if you do not specify an explicit alt tag, it defaults to the file name of the file, capitalized and with no extension, for example, these two image tags would return the same code:
+You can supply alternate text for the image which will be used if the user has images turned off in their browser. If you do not specify an alt text explicitly, it defaults to the file name of the file, capitalized and with no extension. For example, these two image tags would return the same code:
 
 <erb>
 <%= image_tag "home.gif" %>
@@ -939,7 +937,7 @@ The main body of the view will always render into the unnamed +yield+. To render
 
 h4. Using +content_for+
 
-The +content_for+ method allows you to insert content into a +yield+ block in your layout. You only use +content_for+ to insert content in named yields. For example, this view would work with the layout that you just saw:
+The +content_for+ method allows you to insert content into a named +yield+ block in your layout. For example, this view would work with the layout that you just saw:
 
 <erb>
 <% content_for :head do %>
@@ -966,7 +964,7 @@ The +content_for+ method is very helpful when your layout contains distinct regi
 
 h4. Using Partials
 
-Partial templates - usually just called "partials" - are another device for breaking apart the rendering process into more manageable chunks. With a partial, you can move the code for rendering a particular piece of a response to its own file.
+Partial templates - usually just called "partials" - are another device for breaking the rendering process into more manageable chunks. With a partial, you can move the code for rendering a particular piece of a response to its own file.
 
 h5. Naming Partials
 
@@ -1086,15 +1084,13 @@ Partials are very useful in rendering collections. When you pass a collection to
 
 When a partial is called with a pluralized collection, then the individual instances of the partial have access to the member of the collection being rendered via a variable named after the partial. In this case, the partial is +_product+, and within the +_product+ partial, you can refer to +product+ to get the instance that is being rendered.
 
-In Rails 3.0, there is also a shorthand for this. Assuming +@products+ is a collection of +product+ instances, you can simply write this in the +index.html.erb+:
+In Rails 3.0, there is also a shorthand for this. Assuming +@products+ is a collection of +product+ instances, you can simply write this in the +index.html.erb+ to produce the same result:
 
 <erb>
 <h1>Products</h1>
 <%= render @products %>
 </erb>
 
-To produce the same result.
-
 Rails determines the name of the partial to use by looking at the model name in the collection. In fact, you can even create a heterogeneous collection and render it this way, and Rails will choose the proper partial for each member of the collection:
 
 * +index.html.erb+
diff --git a/railties/guides/source/migrations.textile b/railties/guides/source/migrations.textile
index a9c3d51752..0d13fbc10a 100644
--- a/railties/guides/source/migrations.textile
+++ b/railties/guides/source/migrations.textile
@@ -584,7 +584,7 @@ h3. Active Record and Referential Integrity
 
 The Active Record way claims that intelligence belongs in your models, not in the database. As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database, are not heavily used.
 
-Validations such as +validates_uniqueness_of+ are one way in which models can enforce data integrity. The +:dependent+ option on associations allows models to automatically destroy child objects when the parent is destroyed. Like anything which operates at the application level these cannot guarantee referential integrity and so some people augment them with foreign key constraints.
+Validations such as +validates :foreign_key, :uniqueness => true+ are one way in which models can enforce data integrity. The +:dependent+ option on associations allows models to automatically destroy child objects when the parent is destroyed. Like anything which operates at the application level these cannot guarantee referential integrity and so some people augment them with foreign key constraints.
 
 Although Active Record does not provide any tools for working directly with such features, the +execute+ method can be used to execute arbitrary SQL. There are also a number of plugins such as "foreign_key_migrations":http://github.com/harukizaemon/redhillonrails/tree/master/foreign_key_migrations/ which add foreign key support to Active Record (including support for dumping foreign keys in +db/schema.rb+).
 
diff --git a/railties/guides/source/performance_testing.textile b/railties/guides/source/performance_testing.textile
index 41bdd27e9b..b9401f3559 100644
--- a/railties/guides/source/performance_testing.textile
+++ b/railties/guides/source/performance_testing.textile
@@ -398,7 +398,7 @@ $ rails benchmarker 'Item.first' 'Item.last'
 
 h4. +profiler+
 
-+profiler+ is a wrapper around http://ruby-prof.rubyforge.org/[ruby-prof] gem.
++profiler+ is a wrapper around the "ruby-prof":http://ruby-prof.rubyforge.org gem.
 
 Usage:
 
diff --git a/railties/guides/source/routing.textile b/railties/guides/source/routing.textile
index 918279f9eb..32346e8f2b 100644
--- a/railties/guides/source/routing.textile
+++ b/railties/guides/source/routing.textile
@@ -3,7 +3,7 @@ h2. Rails Routing from the Outside In
 This guide covers the user-facing features of Rails routing. By referring to this guide, you will be able to:
 
 * Understand the code in +routes.rb+
-* Construct your own routes, using either the preferred resourceful style or with the <tt>match</tt> method
+* Construct your own routes, using either the preferred resourceful style or the <tt>match</tt> method
 * Identify what parameters to expect an action to receive
 * Automatically create paths and URLs using route helpers
 * Use advanced techniques such as constraints and Rack endpoints
@@ -50,7 +50,7 @@ Resource routing allows you to quickly declare all of the common routes for a gi
 
 h4. Resources on the Web
 
-Browsers request pages from Rails by making a request for a URL using a specific HTTP method, such as +GET+, +POST+, +PUT+ and +DELETE+. Each method is a request to perform an operation on the resource. A resource route maps a number of related request to the actions in a single controller.
+Browsers request pages from Rails by making a request for a URL using a specific HTTP method, such as +GET+, +POST+, +PUT+ and +DELETE+. Each method is a request to perform an operation on the resource. A resource route maps a number of related requests to actions in a single controller.
 
 When your Rails application receives an incoming request for
 
@@ -76,14 +76,14 @@ resources :photos
 
 creates seven different routes in your application, all mapping to the +Photos+ controller:
 
-|_. Verb |_.Path            |_.action |_.used for|
-|GET     |/photos           |index    |display a list of all photos|
-|GET     |/photos/new       |new      |return an HTML form for creating a new photo|
-|POST    |/photos           |create   |create a new photo|
-|GET     |/photos/:id       |show     |display a specific photo|
-|GET     |/photos/:id/edit  |edit     |return an HTML form for editing a photo|
-|PUT     |/photos/:id       |update   |update a specific photo|
-|DELETE  |/photos/:id       |destroy  |delete a specific photo|
+|_. HTTP Verb |_.Path            |_.action |_.used for                                   |
+|GET          |/photos           |index    |display a list of all photos                 |
+|GET          |/photos/new       |new      |return an HTML form for creating a new photo |
+|POST         |/photos           |create   |create a new photo                           |
+|GET          |/photos/:id       |show     |display a specific photo                     |
+|GET          |/photos/:id/edit  |edit     |return an HTML form for editing a photo      |
+|PUT          |/photos/:id       |update   |update a specific photo                      |
+|DELETE       |/photos/:id       |destroy  |delete a specific photo                      |
 
 h4. Paths and URLs
 
@@ -130,13 +130,13 @@ resource :geocoder
 
 creates six different routes in your application, all mapping to the +Geocoders+ controller:
 
-|_. Verb    |_.Path         |_.action |_.used for|
-|GET        |/geocoder/new  |new      |return an HTML form for creating the geocoder|
-|POST       |/geocoder      |create   |create the new geocoder|
-|GET        |/geocoder      |show     |display the one and only geocoder resource|
-|GET        |/geocoder/edit |edit     |return an HTML form for editing the geocoder|
-|PUT        |/geocoder      |update   |update the one and only geocoder resource|
-|DELETE     |/geocoder      |destroy  |delete the geocoder resource|
+|_.HTTP Verb |_.Path         |_.action |_.used for                                    |
+|GET         |/geocoder/new  |new      |return an HTML form for creating the geocoder |
+|POST        |/geocoder      |create   |create the new geocoder                       |
+|GET         |/geocoder      |show     |display the one and only geocoder resource    |
+|GET         |/geocoder/edit |edit     |return an HTML form for editing the geocoder  |
+|PUT         |/geocoder      |update   |update the one and only geocoder resource     |
+|DELETE      |/geocoder      |destroy  |delete the geocoder resource                  |
 
 NOTE: Because you might want to use the same controller for a singular route (+/account+) and a plural route (+/accounts/45+), singular resources map to plural controllers.
 
@@ -160,14 +160,14 @@ end
 
 This will create a number of routes for each of the +posts+ and +comments+ controller. For +Admin::PostsController+, Rails will create:
 
-|_. Verb |_.Path               |_.action |_. helper                  |
-|GET     |/admin/posts        |index    | admin_posts_path         |
-|GET     |/admin/posts/new    |new      | new_admin_posts_path     |
-|POST    |/admin/posts        |create   | admin_posts_path         |
-|GET     |/admin/posts/1      |show     | admin_post_path(id)      |
-|GET     |/admin/posts/1/edit |edit     | edit_admin_post_path(id) |
-|PUT     |/admin/posts/1      |update   | admin_post_path(id)      |
-|DELETE  |/admin/posts/1      |destroy  | admin_post_path(id)      |
+|_.HTTP Verb |_.Path              |_.action |_.named helper            |
+|GET         |/admin/posts        |index    | admin_posts_path         |
+|GET         |/admin/posts/new    |new      | new_admin_posts_path     |
+|POST        |/admin/posts        |create   | admin_posts_path         |
+|GET         |/admin/posts/1      |show     | admin_post_path(id)      |
+|GET         |/admin/posts/1/edit |edit     | edit_admin_post_path(id) |
+|PUT         |/admin/posts/1      |update   | admin_post_path(id)      |
+|DELETE      |/admin/posts/1      |destroy  | admin_post_path(id)      |
 
 If you want to route +/posts+ (without the prefix +/admin+) to +Admin::PostsController+, you could use
 
@@ -194,19 +194,19 @@ end
 or, for a single case
 
 <ruby>
-resources :posts, :path => "/admin"
+resources :posts, :path => "/admin/posts"
 </ruby>
 
 In each of these cases, the named routes remain the same as if you did not use +scope+. In the last case, the following paths map to +PostsController+:
 
-|_. Verb |_.Path               |_.action |_. helper            |
-|GET     |/admin/posts        |index    | posts_path         |
-|GET     |/admin/posts/new    |new      | posts_path         |
-|POST    |/admin/posts        |create   | posts_path         |
-|GET     |/admin/posts/1      |show     | post_path(id)      |
-|GET     |/admin/posts/1/edit |edit     | edit_post_path(id) |
-|PUT     |/admin/posts/1      |update   | post_path(id)      |
-|DELETE  |/admin/posts/1      |destroy  | post_path(id)      |
+|_.HTTP Verb |_.Path               |_.action |_.named helper      |
+|GET         |/admin/posts         |index    | posts_path         |
+|GET         |/admin/posts/new     |new      | posts_path         |
+|POST        |/admin/posts         |create   | posts_path         |
+|GET         |/admin/posts/1       |show     | post_path(id)      |
+|GET         |/admin/posts/1/edit  |edit     | edit_post_path(id) |
+|PUT         |/admin/posts/1       |update   | post_path(id)      |
+|DELETE      |/admin/posts/1       |destroy  | post_path(id)      |
 
 h4. Nested Resources
 
@@ -232,14 +232,14 @@ end
 
 In addition to the routes for magazines, this declaration will also route ads to an +AdsController+. The ad URLs require a magazine:
 
-|_.Verb |_.Path                   |_.action |_.used for|
-|GET    |/magazines/1/ads         |index    |display a list of all ads for a specific magazine|
-|GET    |/magazines/1/ads/new     |new      |return an HTML form for creating a new ad belonging to a specific magazine|
-|POST   |/magazines/1/ads         |create   |create a new ad belonging to a specific magazine|
-|GET    |/magazines/1/ads/1       |show     |display a specific ad belonging to a specific magazine|
-|GET    |/magazines/1/ads/1/edit  |edit     |return an HTML form for editing an ad belonging to a specific magazine|
-|PUT    |/magazines/1/ads/1       |update   |update a specific ad belonging to a specific magazine|
-|DELETE |/magazines/1/ads/1       |destroy  |delete a specific ad belonging to a specific magazine|
+|_.HTTP Verb |_.Path                  |_.action |_.used for                                                                 |
+|GET         |/magazines/1/ads        |index    |display a list of all ads for a specific magazine                          |
+|GET         |/magazines/1/ads/new    |new      |return an HTML form for creating a new ad belonging to a specific magazine |
+|POST        |/magazines/1/ads        |create   |create a new ad belonging to a specific magazine                           |
+|GET         |/magazines/1/ads/1      |show     |display a specific ad belonging to a specific magazine                     |
+|GET         |/magazines/1/ads/1/edit |edit     |return an HTML form for editing an ad belonging to a specific magazine     |
+|PUT         |/magazines/1/ads/1      |update   |update a specific ad belonging to a specific magazine                      |
+|DELETE      |/magazines/1/ads/1      |destroy  |delete a specific ad belonging to a specific magazine                      |
 
 
 This will also create routing helpers such as +magazine_ads_url+ and +edit_magazine_ad_path+. These helpers take an instance of Magazine as the first parameter (+magazine_ads_url(@magazine)+).
@@ -470,7 +470,7 @@ This route would match paths such as +/photos/A12345+. You can more succinctly e
 match 'photos/:id' => 'photos#show', :id => /[A-Z]\d{5}/
 </ruby>
 
-+:constraints+ takes regular expression. However note that regexp anchors can't be used within constraints. For example following route will not work:
++:constraints+ takes regular expressions with the restriction that regexp anchors can't be used. For example, the following route will not work:
 
 <ruby>
 match '/:id' => 'posts#show', :constraints => {:id => /^\d/}
@@ -536,7 +536,7 @@ match 'photos/*other' => 'photos#unknown'
 
 This route would match +photos/12+ or +/photos/long/path/to/12+, setting +params[:other]+ to +"12"+ or +"long/path/to/12"+.
 
-Wildcard segments do not need to be last in a route. For example
+Wildcard segments can occur anywhere in a route. For example,
 
 <ruby>
 match 'books/*section/:title' => 'books#show'
@@ -544,7 +544,7 @@ match 'books/*section/:title' => 'books#show'
 
 would match +books/some/section/last-words-a-memoir+ with +params[:section]+ equals +"some/section"+, and +params[:title]+ equals +"last-words-a-memoir"+.
 
-Techincally a route can have even more than one wildard segment indeed, the matcher assigns segments to parameters in an intuitive way. For instance
+Technically a route can have even more than one wildcard segment. The matcher assigns segments to parameters in an intuitive way. For example,
 
 <ruby>
 match '*a/foo/*b' => 'test#index'
@@ -595,7 +595,7 @@ You can specify what Rails should route +"/"+ to with the +root+ method:
 root :to => 'pages#main'
 </ruby>
 
-You should put the +root+ route at the end of the file.
+You should put the +root+ route at the end of the file. You also need to delete the public/index.html.erb file for the root route to take effect.
 
 h3. Customizing Resourceful Routes
 
@@ -611,14 +611,14 @@ resources :photos, :controller => "images"
 
 will recognize incoming paths beginning with +/photos+ but route to the +Images+ controller:
 
-|_. Verb |_.Path         |_.action |
-|GET     |/photos        |index    |
-|GET     |/photos/new    |new      |
-|POST    |/photos        |create   |
-|GET     |/photos/1      |show     |
-|GET     |/photos/1/edit |edit     |
-|PUT     |/photos/1      |update   |
-|DELETE  |/photos/1      |destroy  |
+|_.HTTP Verb |_.Path         |_.action |_.named helper       |
+|GET         |/photos        |index    | photos_path         |
+|GET         |/photos/new    |new      | new_photo_path      |
+|POST        |/photos        |create   | photos_path         |
+|GET         |/photos/1      |show     | photo_path(id)      |
+|GET         |/photos/1/edit |edit     | edit_photo_path(id) |
+|PUT         |/photos/1      |update   | photo_path(id)      |
+|DELETE      |/photos/1      |destroy  | photo_path(id)      |
 
 NOTE: Use +photos_path+, +new_photos_path+, etc. to generate paths for this resource.
 
@@ -641,7 +641,7 @@ constraints(:id => /[A-Z][A-Z][0-9]+/) do
 end
 </ruby>
 
-NOTE: Of course, you can use the more advanced constraints available in non-resourceful routes in this context
+NOTE: Of course, you can use the more advanced constraints available in non-resourceful routes in this context.
 
 h4. Overriding the Named Helpers
 
@@ -651,16 +651,16 @@ The +:as+ option lets you override the normal naming for the named route helpers
 resources :photos, :as => "images"
 </ruby>
 
-will recognize incoming paths beginning with +/photos+ and route the requests to +PhotosController+:
+will recognize incoming paths beginning with +/photos+ and route the requests to +PhotosController+, but use the value of the :as option to name the helpers.
 
-|_.HTTP verb|_.Path          |_.action |_.named helper   |
-|GET        |/photos         |index    | images_path     |
-|GET        |/photos/new     |new      | new_image_path  |
-|POST       |/photos         |create   | images_path     |
-|GET        |/photos/1       |show     | image_path      |
-|GET        |/photos/1/edit  |edit     | edit_image_path |
-|PUT        |/photos/1       |update   | image_path      |
-|DELETE     |/photos/1       |destroy  | image_path      |
+|_.HTTP verb|_.Path          |_.action |_.named helper       |
+|GET        |/photos         |index    | images_path         |
+|GET        |/photos/new     |new      | new_image_path      |
+|POST       |/photos         |create   | images_path         |
+|GET        |/photos/1       |show     | image_path(id)      |
+|GET        |/photos/1/edit  |edit     | edit_image_path(id) |
+|PUT        |/photos/1       |update   | image_path(id)      |
+|DELETE     |/photos/1       |destroy  | image_path(id)      |
 
 h4. Overriding the +new+ and +edit+ Segments
 
@@ -679,7 +679,7 @@ This would cause the routing to recognize paths such as
 
 NOTE: The actual action names aren't changed by this option. The two paths shown would still route to the +new+ and +edit+ actions.
 
-TIP: If you find yourself wanting to change this option uniformly for all of your routes, you can use a scope:
+TIP: If you find yourself wanting to change this option uniformly for all of your routes, you can use a scope.
 
 <ruby>
 scope :path_names => { :new => "make" } do
@@ -715,7 +715,7 @@ NOTE: The +namespace+ scope will automatically add +:as+ as well as +:module+ an
 
 h4. Restricting the Routes Created
 
-By default, Rails creates routes for all seven of the default actions (index, show, new, create, edit, update, and destroy) for every RESTful route in your application. You can use the +:only+ and +:except+ options to fine-tune this behavior. The +:only+ option tells Rails to create only the specified routes:
+By default, Rails creates routes for the seven default actions (index, show, new, create, edit, update, and destroy) for every RESTful route in your application. You can use the +:only+ and +:except+ options to fine-tune this behavior. The +:only+ option tells Rails to create only the specified routes:
 
 <ruby>
 resources :photos, :only => [:index, :show]
@@ -745,14 +745,14 @@ end
 
 Rails now creates routes to the +CategoriesController+.
 
-|_.HTTP verb|_.Path                     |_.action |
-|GET        |/kategorien                |index    |
-|GET        |/kategorien/neu            |new      |
-|POST       |/kategorien                |create   |
-|GET        |/kategorien/1              |show     |
-|GET        |/kategorien/:id/bearbeiten |edit     |
-|PUT        |/kategorien/1              |update   |
-|DELETE     |/kategorien/1              |destroy  |
+|_.HTTP verb|_.Path                   |_.action |_.named helper          |
+|GET        |/kategorien              |index    | categories_path        |
+|GET        |/kategorien/neu          |new      | new_category_path      |
+|POST       |/kategorien              |create   | categories_path        |
+|GET        |/kategorien/1            |show     | category_path(id)      |
+|GET        |/kategorien/1/bearbeiten |edit     | edit_category_path(id) |
+|PUT        |/kategorien/1            |update   | category_path(id)      |
+|DELETE     |/kategorien/1            |destroy  | category_path(id)      |
 
 h4. Overriding the Singular Form
 
@@ -816,7 +816,7 @@ Routes should be included in your testing strategy (just like the rest of your a
 
 h5. The +assert_generates+ Assertion
 
-Use +assert_generates+ to assert that a particular set of options generate a particular path. You can use this with default routes or custom routes
++assert_generates+ asserts that a particular set of options generate a particular path and can be used with default routes or custom routes.
 
 <ruby>
 assert_generates "/photos/1", { :controller => "photos", :action => "show", :id => "1" }
@@ -825,7 +825,7 @@ assert_generates "/about", :controller => "pages", :action => "about"
 
 h5. The +assert_recognizes+ Assertion
 
-The +assert_recognizes+ assertion is the inverse of +assert_generates+. It asserts that Rails recognizes the given path and routes it to a particular spot in your application.
++assert_recognizes+ is the inverse of +assert_generates+. It asserts that a given path is recognized and routes it to a particular spot in your application.
 
 <ruby>
 assert_recognizes({ :controller => "photos", :action => "show", :id => "1" }, "/photos/1")
diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile
index 693645b202..fbafc40d93 100644
--- a/railties/guides/source/security.textile
+++ b/railties/guides/source/security.textile
@@ -166,7 +166,7 @@ end
 The section about session fixation introduced the problem of maintained sessions. An attacker maintaining a session every five minutes can keep the session alive forever, although you are expiring sessions. A simple solution for this would be to add a created_at column to the sessions table. Now you can delete sessions that were created a long time ago. Use this line in the sweep method above:
 
 <ruby>
-delete_all "updated_at < '#{time.to_s(:db)}' OR
+delete_all "updated_at < '#{time.ago.to_s(:db)}' OR
   created_at < '#{2.days.ago.to_s(:db)}'"
 </ruby>
 
@@ -524,10 +524,10 @@ h4. Logging
 
 -- _Tell Rails not to put passwords in the log files._
 
-By default, Rails logs all requests being made to the web application. But log files can be a huge security issue, as they may contain login credentials, credit card numbers et cetera. When designing a web application security concept, you should also think about what will happen if an attacker got (full) access to the web server. Encrypting secrets and passwords in the database will be quite useless, if the log files list them in clear text. You can _(highlight)filter certain request parameters from your log files_ by the filter_parameter_logging method in a controller. These parameters will be marked [FILTERED] in the log.
+By default, Rails logs all requests being made to the web application. But log files can be a huge security issue, as they may contain login credentials, credit card numbers et cetera. When designing a web application security concept, you should also think about what will happen if an attacker got (full) access to the web server. Encrypting secrets and passwords in the database will be quite useless, if the log files list them in clear text. You can _(highlight)filter certain request parameters from your log files_ by appending them to <tt>config.filter_parameters</tt> in the application configuration. These parameters will be marked [FILTERED] in the log.
 
 <ruby>
-filter_parameter_logging :password
+config.filter_parameters << :password
 </ruby>
 
 h4. Good Passwords
@@ -550,7 +550,7 @@ Ruby uses a slightly different approach than many other languages to match the e
 
 <ruby>
 class File < ActiveRecord::Base
-  validates_format_of :name, :with => /^[\w\.\-\+]+$/
+  validates :name, :format => /^[\w\.\-\+]+$/
 end
 </ruby>
 
diff --git a/railties/guides/source/testing.textile b/railties/guides/source/testing.textile
index 3d4f31cc5d..733c8a755e 100644
--- a/railties/guides/source/testing.textile
+++ b/railties/guides/source/testing.textile
@@ -182,21 +182,27 @@ class PostTest < ActiveSupport::TestCase
 
 The +PostTest+ class defines a _test case_ because it inherits from +ActiveSupport::TestCase+. +PostTest+ thus has all the methods available from +ActiveSupport::TestCase+. You'll see those methods a little later in this guide.
 
-<ruby>
-def test_truth
-</ruby>
-
 Any method defined within a +Test::Unit+ test case that begins with +test+ (case sensitive) is simply called a test. So, +test_password+, +test_valid_password+ and +testValidPassword+ all are legal test names and are run automatically when the test case is run.
 
-Rails adds a +test+ method that takes a test name and a block. It generates a normal +Test::Unit+ test with method names prefixed with +test_+.
+Rails adds a +test+ method that takes a test name and a block. It generates a normal +Test::Unit+ test with method names prefixed with +test_+. So,
 
 <ruby>
 test "the truth" do
-  # ...
+  assert true
 end
 </ruby>
 
-This makes test names more readable by replacing underscores with regular language.
+acts as if you had written
+
+<ruby>
+def test_the_truth
+  assert true
+end
+</ruby>
+
+only the +test+ macro allows a more readable test name. You can still use regular method definitions though.
+
+NOTE: The method name is generated by replacing spaces with underscores. The result does not need to be a valid Ruby identifier though, the name may contain punctuation characters etc. That's because in Ruby technically any string may be a method name. Odd ones need +define_method+ and +send+ calls, but formally there's no restriction.
 
 <ruby>
 assert true
@@ -256,7 +262,7 @@ This will run all the test methods from the test case. Note that +test_helper.rb
 You can also run a particular test method from the test case by using the +-n+ switch with the +test method name+.
 
 <shell>
-$ ruby -Itest test/unit/post_test.rb -n test_truth
+$ ruby -Itest test/unit/post_test.rb -n test_the_truth
 
 Loaded suite unit/post_test
 Started
@@ -315,7 +321,7 @@ Now to get this test to pass we can add a model level validation for the _title_
 
 <ruby>
 class Post < ActiveRecord::Base
-  validates_presence_of :title
+  validates :title, :presence => true
 end
 </ruby>
 
@@ -380,7 +386,7 @@ There are a bunch of different types of assertions you can use. Here's the compl
 |+assert( boolean, [msg] )+                                        |Ensures that the object/expression is true.|
 |+assert_equal( obj1, obj2, [msg] )+                               |Ensures that +obj1 == obj2+ is true.|
 |+assert_not_equal( obj1, obj2, [msg] )+                           |Ensures that +obj1 == obj2+ is false.|
-|+assert_same( obj1, obj2, [msg] )+			                       |Ensures that +obj1.equal?(obj2)+ is true.|
+|+assert_same( obj1, obj2, [msg] )+                                |Ensures that +obj1.equal?(obj2)+ is true.|
 |+assert_not_same( obj1, obj2, [msg] )+                            |Ensures that +obj1.equal?(obj2)+ is false.|
 |+assert_nil( obj, [msg] )+                                        |Ensures that +obj.nil?+ is true.|
 |+assert_not_nil( obj, [msg] )+                                    |Ensures that +obj.nil?+ is false.|
@@ -388,7 +394,7 @@ There are a bunch of different types of assertions you can use. Here's the compl
 |+assert_no_match( regexp, string, [msg] )+                        |Ensures that a string doesn't matches the regular expression.|
 |+assert_in_delta( expecting, actual, delta, [msg] )+              |Ensures that the numbers +expecting+ and +actual+ are within +delta+ of each other.|
 |+assert_throws( symbol, [msg] ) { block }+                        |Ensures that the given block throws the symbol.|
-|+assert_raise( exception1, exception2, ... ) { block }+          |Ensures that the given block raises one of the given exceptions.|
+|+assert_raise( exception1, exception2, ... ) { block }+           |Ensures that the given block raises one of the given exceptions.|
 |+assert_nothing_raised( exception1, exception2, ... ) { block }+  |Ensures that the given block doesn't raise one of the given exceptions.|
 |+assert_instance_of( class, obj, [msg] )+                         |Ensures that +obj+ is of the +class+ type.|
 |+assert_kind_of( class, obj, [msg] )+                             |Ensures that +obj+ is or descends from +class+.|