Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Your application should *always* reference your application const (as Blog::Application) and Rails.application should be used just internally.

If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
  middleware stack via config.middleware.use. You can use
  methods on the middleware stack to control exactly where
  it should go
* if it behaves like a Rack endpoint, you can link to it
  in the router. This will result in more optimal routing
  time, and allows you to remove code in your endpoint
  that matches specific URLs in favor of the more powerful
  handling in the router itself.

For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.

Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.

Cover more of the Rails initialization process, regarding the internals of YourApp::Application inheritance from Rails::Application and more.

If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
  middleware stack via config.middleware.use. You can use
  methods on the middleware stack to control exactly where
  it should go
* if it behaves like a Rack endpoint, you can link to it
  in the router. This will result in more optimal routing
  time, and allows you to remove code in your endpoint
  that matches specific URLs in favor of the more powerful
  handling in the router itself.

For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.

Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.

Cover more of the Rails initialization process, regarding the internals of YourApp::Application inheritance from Rails::Application and more.

Reorganized initializers a bit to enable better hooks for common cases without the need for Railtie. Specifically, the following hooks were added:

* before_configuration: this hook is run immediately after the Application class 
  comes into existence, but before the user has added any configuration. This is
  the appropriate place to set configuration for your plugin
* before_initialize: This is run after all of the user's configuration has completed,
  but before any initializers have begun (in other words, it runs right after
  config/environments/{development,production,test}.rb)
* after_initialize: This is run after all of the initializers have run. It is an
  appropriate place for forking in a preforking setup

Each of these hooks may be used via ActiveSupport.on_load(name) { }. In all these cases, the context inside the block will be the Application object. This means that for simple cases, you can use these hooks without needing to create a Railtie.

They can be bundled. Just the git repos can't. Use rails/rack-mount for that.

This reverts commit ef6cdc97.

Rip out bundler notes, they're now living at http://github.com/radar/how-rails-works/raw/master/bundler.textile. It really needs its own guide.

Signed-off-by: NJeremy Kemper <jeremy@bitsweat.net>