Rails 2.3.0 RC1: Templates, Engines, Rack, Metal, much more!

Rails 2.3 is almost ready for release, but this package is so stock full of amazing new stuff that we’re making dutifully sure that everything works right before we call it official.

So please help us do thorough testing of this release candidate. Lots of the underpinnings changed. Especially the move to Rack. So we need solid testing and will probably have a slightly longer than average release candidate phase to account for that.

But boy will it be worth it. This is one of the most substantial upgrades to Rails in a very long time. A brief rundown of the top hitters:

  • Templates: Allows your new skeleton Rails application to be built your way with your default stack of gems, configs, and more.
  • Engines: Share reusable application pieces complete with routes that Just Work, models, view paths, and the works.
  • Rack: Rails now runs on Rack which gives you access to all the middleware goodness.
  • Metal: Write super fast pieces of optimized logic that routes around Action Controller.
  • Nested forms: Deal with complex forms so much easier.

And that’s just the tip of the iceberg. We’ve put together a complete guide for the Rails 2.3 release notes with much more information.

You can install the release candidate with:

gem install rails --source http://gems.rubyonrails.org

Enjoy, report the bugs, and let’s get Rails 2.3 final out the door soon.

This Week in Edge Rails

January 24, 2009 – January 30, 2009

This week we saw 35 commits in edge Rails – though many are bug fixes and minor things. Here’s one more preview of some of the recent and significant changes.

Localized Views

Rails can now provide localized views, depending on the locale that you have set. For example, suppose you have a Posts controller with a show action. By default, this will render app/views/posts/show.html.erb. But if you set I18n.locale = :da, it will render app/views/posts/show.da.html.erb. If the localized template isn’t present, the undecorated version will be used. Rails also includes I18n#available_locales and I18n::SimpleBackend#available_locales, which return an array of the translations that are available in the current Rails project.

commit
commit

Reconnecting MySQL Connections

MySQL supports a reconnect flag in its connections – if set to true, then the client will try reconnecting to the server before giving up in case of a lost connection. You can now set reconnect = true for your MySQL connections in database.yml to get this behavior from a Rails application. The default is false, so the behavior of existing applications doesn’t change.

commit

Easier Testing for JDBC

To make life easier for anyone using Rails on JRuby, Active Record now includes test tasks for a bunch of database accessible via JDBC: Derby, H2, hsqldb, MySQL, PostgreSQL, and sqlite3 (the latter three are also available through non-JDBC connections, as you know). You need to have the database, the activerecord-jdbc-adapter gem installed, and the specific activerecord-jdbcdatabase-gem for the database you’re testing. Then you can run tests like this: jruby -S rake test_jdbcmysql (with similar tests for the other adapters, of course).

commit

HTTP Digest Authentication Support

This one first appeared a couple of weeks ago, but was reverted due to some problems with the initial implementation. Fortunately, the problems were resolved, and Rails 2.3 will ship with built-in support for HTTP digest authentication. Ryan Daigle published some sample code.

commit

grouped_options_for_select Helper Method

Action View already has a bunch of helpers to aid in generating select controls, but now there’s one more: grouped_options_for_select. This one accepts an array or hash of strings, and converts them into a string of option tags wrapped with optgroup tags. For example:


 grouped_options_for_select([["Hats", 
   ["Baseball Cap","Cowboy Hat"]]], 
   "Cowboy Hat", "Choose a product...")

returns


 <option value="">Choose a product...</option>
 <optgroup label="Hats">
   <option value="Baseball Cap">Baseball Cap</option>
   <option selected="selected" value="Cowboy Hat">
     Cowboy Hat
   </option>
 </optgroup>

commit

Ruby / Rails Conferences

When the economy hits a downturn this typically has an immediate effect on tech conferences. Many tech conferences cannot run successfully without sponsorships, and with companies becoming more conservative with spending the marketing budget is usually the first item to get cut.

So yet another way you can help Ruby and Rails Activism is by attending (supporting) a conference. Below you’ll find conferences coming up in the next 6 months. If you think I’ve missed one, or if the information is incorrect, please post a comment.

Acts as Conference

February 6-7 – Acts As Conference in Orlando, Florida

Cost: $125

RubyRx

February 19-21 – RubyRx in Durham, North Carolina

Cost: $550

MountainWest RubyConf 2009

March 12-14 – MountainWest RubyConf 2009 in Salt Lake City, Utah

Cost: $100

Scotland on Rails

March 26-28 – Scotland on Rails in Scotland, United Kingdom

Cost: £150

Locos X Rails

April 3-4 – Locos X Rails in Buenos Aires, Argentina

Cost: ?

LA Ruby Conf 2009

April 4 – LA Ruby Conf 2009 in Los Angeles, California

Cost: $75

Golden Gate Ruby Conference

April 17-18 – Golden Gate Ruby Conference in San Francisco, California

Cost: ?

RailsConf 2009

May 4-7 – RailsConf 2009 in Las Vegas, Nevada

Cost: $695

Euruko 2009

May 9-10 – Euruko 2009 in Barcelona, Spain

Cost: 30 Euro

RailsCamp 5

May 15-18 – RailsCamp 5 in Brisbane, Australia

Cost: $120 AUD

Update

Since I initially wrote up this post, there have been several more events I’ve been made aware of (from the comments):

It’s pretty cool to see more RubyCamps. I’m a big fan of BarCamp type events where you keep admission free. Perhaps in this financial climate these types of events will prosper more then they normally do. Feel free to bug me if you want help putting one of these together or need help with publicity.

Autoloading ActiveResource schemas

I just committed a little feature during our Rails core hackfest in Chicago: [Autoloading ActiveResource schemas](http://github.com/technoweenie/rails/commit/be73b3f250373a3b68a680cd7aef8c2116f0f905). Note: this is in my personal fork that's up to date with the rails repo, and will probably be merged in for Rails 2.3. I've received some requests for this from people having problems using `Lighthouse::Ticket` records with `form_for` helpers in their Rails apps. The idea is that resources can automatically load the starting XML just once, like the way ActiveRecord loads the schema from the database. This is already part of the current Rails scaffolding:

class PostsController < ApplicationController
  def new
    @post = Post.new
    respond_to do |format|
      format.html # new.html.erb
      format.xml { render :xml => @post }
    end
  end
end
There is one problem though, this probably won't work for protected or nested actions. Ideally a Rails app will set a top level route for the resource, and disable any before filters if `request.format.xml?` is true.

map.route 'tickets/new.:format', :controller => 'tickets', :action => 'new'
You can get around this by modifying the `#schema` hash directly, or calling `#reset_schema` with your own prefixes. Here's a sample using the [Lighthouse API lib](http://github.com/Caged/lighthouse-api/tree/master).

Lighthouse.account = 'entp'
Lighthouse.token = 'monkey'
Lighthouse::Ticket.reset_schema :project_id => 1

# or, use a well known public project
Lighthouse.account = 'rails'
Lighthouse::Ticket.reset_schema :project_id => 8994
Ticket.new # => #<Lighthouse::Ticket:0x1707898 @attributes={"permalink"=>nil, "updated_at"=>nil, "number"=>nil, "title"=>nil, "creator_id"=>nil, "tag"=>nil, "attachments_count"=>0, "priority"=>0, "closed"=>false, "assigned_user_id"=>nil, "user_id"=>nil, "created_at"=>nil, "state"=>nil, "milestone_id"=>nil}, @prefix_options={:project_id=>8994}>
Comments?

Visualizing the Rails commit history

Ilya Grigorik wrote up a post on [generating a code swarm visualization from git repositories](http://www.igvita.com/2009/01/27/ruby-swarms-visualizing-rails-git/). He wrote [gitter](http://github.com/igrigorik/gitter/tree/master) to feed the git commit info for the Rails repository and feed it to [code swarm](http://github.com/rictic/code_swarm/tree/master):
Ruby on Rails from Ilya Grigorik on Vimeo. It's worth checking out the HD version. Git was introduced around 4:40 :)

Nested Model Forms

The most popular request on our new Feedback site was for the ability to easily manage multiple models in a single form. Thankfully Eloy Duran has a patch that does just this. But before we roll it into rails 2.3 we want to get some more feedback from you guys. Eloy's written this brief introduction to the patch, so take a look, and add any feedback you have to the lighthouse ticket.

In Rails it has always been a little tricky to create a single form for both a model and its associations. Last summer, the :accessible option was committed as a first stab at a unified solution for dealing with nested models. However, this feature was pulled before the 2.2 release because it only supported nested models during object creation.

The resulting discussion on the core mailing list and our need for mass assignment have resulted in this patch for ticket #1202 which is now up for scrutinizing.

Since this is a rather large patch we would like to invite you to give it a try. Please report any issues or give feedback about the patch in general. We are especially interested to know how the provided solutions work for applications that allow deletion of nested records through their forms.

Below I'll give a quick tour on what the patch does and how to use it so you have no excuse not to give it a try.

Get the patch

Start by creating a new application:

$ mkdir -p nested-models/vendor
$ cd nested-models/vendor

Vendor your Rails branch with the nested models patches:

$ git clone git://github.com/alloy/rails.git
$ cd rails
$ git checkout origin/normalized_nested_attributes
$ cd ../..
$ ruby vendor/rails/railties/bin/rails .

An example of nested assignment

Suppose you have a project model with associated tasks:

class Project < ActiveRecord::Base
  has_many :tasks

  validates_presence_of :name
end
class Task < ActiveRecord::Base
  belongs_to :project

  validates_presence_of :name
end

Now consider the following form which allows you to simultaneously create (or edit) a project and its tasks:

<form>
  <div>
    <label for="project_name">Project:</label>
    <input type="text" name="project_name" />
  </div>

  <p>
    <label for="task_name_1">Task:</label>
    <input type="text" name="task_name_1" />
    <label for="task_delete_1">Remove:</label>
    <input type="checkbox" name="task_delete_1" />
  </p>

  <p>
    <label for="task_name_2">Task:</label>
    <input type="text" name="task_name_2" />
    <label for="task_delete_2">Remove:</label>
    <input type="checkbox" name="task_delete_2" />
  </p>
</form>

Before the patch

Before this patch you would have to write a template like this:

<% form_for @project do |project_form| %>
  <div>
    <%= project_form.label :name, 'Project name:' %>
    <%= project_form.text_field :name %>
  </div>

  <% @project.tasks.each do |task| %>
    <% new_or_existing = task.new_record? ? 'new' : 'existing' %> 
    <% prefix = "project[#{new_or_existing}_task_attributes][]" %> 
    <% fields_for prefix, task do |task_form| %>
      <p>
        <div>
          <%= task_form.label :name, 'Task:' %>
          <%= task_form.text_field :name %>
        </div>

        <% unless task.new_record? %>
          <div>
            <%= task_form.label :_delete, 'Remove:' %>
            <%= task_form.check_box :_delete %>
          </div>
        <% end %>
      </p>
    <% end %>
  <% end %>

  <%= project_form.submit %>
<% end %>

The controller is pretty much your average restful controller. The Project model however needs to know how to handle the nested attributes:

class Project < ActiveRecord::Base
  after_update :save_tasks

  def new_task_attributes=(task_attributes)
    task_attributes.each do |attributes|
      tasks.build(attributes)
    end 
  end

  def existing_task_attributes=(task_attributes)
    tasks.reject(&:new_record?).each do |task|
      attributes = task_attributes[task.id.to_s]
      if attributes['_delete'] == '1'
        tasks.delete(task)
      else
        task.attributes = attributes
      end
    end
  end

  private

  def save_tasks
    tasks.each do |task|
      task.save(false)
    end
  end

  validates_associated :tasks
end

The code above is based on Ryan Bates' complex-form-examples application and from the Advanced Rails Recipes book.

After this patch

First you tell the Project model to accept nested attributes for its tasks:

class Project < ActiveRecord::Base
  has_many :tasks

  accept_nested_attributes_for :tasks, :allow_destroy => true
end

Then you could write the following template:

<% form_for @project do |project_form| %>
  <div>
    <%= project_form.label :name, 'Project name:' %>
    <%= project_form.text_field :name %>
  </div>

  <!-- Here we call fields_for on the project_form builder instance.
       The block is called for each member of the tasks collection. -->
  <% project_form.fields_for :tasks do |task_form| %>
      <p>
        <div>
          <%= task_form.label :name, 'Task:' %>
          <%= task_form.text_field :name %>
        </div>

        <% unless task_form.object.new_record? %>
          <div>
            <%= task_form.label :_delete, 'Remove:' %>
            <%= task_form.check_box :_delete %>
          </div>
        <% end %>
      </p>
    <% end %>
  <% end %>

  <%= project_form.submit %>
<% end %>

As you can see this is much more concise and easier to read.

Granted, the template for this example is only slightly shorter, but it's easy to imagine the difference with more nested models. Or if the Task model had nested models of its own.

Validations

Validations simply work as you'd expect; #valid? will also validate nested models, #save(false) will save without validations, etc.

The only thing to note is that all error messages from the nested models are copied to the parent errors object for error_messages_for. This will probably change in the future, as discussed on the ticket, but that's outside of the scope of this patch.

Let's look at an example where Task validates the presence of its :name attribute:

>> project = Project.first
=> #<Project id: 1, name: "Nested models patches", created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15", author_id: 1>

>> project.tasks
=> [#<Task id: 1, project_id: 1, name: "Write 'em", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">,
#<Task id: 2, project_id: 1, name: "Test 'em", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">,
#<Task id: 3, project_id: 1, name: "Create demo app", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">,
#<Task id: 4, project_id: 1, name: "Scrutinize", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">]

>> project.tasks.second.name = "" 
=> "" 

>> project.valid?
=> false

>> project.errors
=> #<ActiveRecord::Errors:0x23e4b10 @errors={"tasks_name"=>["can't be blank"]}, @base=#<Project id: 1, name: "Nested models patches", …, author_id: 1>>

Transactions

By now you are probably wondering about the consistency of your data when validations passes but saving does not. Consider this Author model which I have rigged to raise an exception after save:

class Author < ActiveRecord::Base
  has_many :projects

  after_save :raise_exception

  def raise_exception
    raise 'Oh noes!'
  end
end

Here's the Project data before an update:

>> project = Project.first
=> #<Project id: 1, name: "Nested models patches", created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15", author_id: 1>

>> project.tasks
=> [#<Task id: 1, project_id: 1, name: "Write 'em", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">,
#<Task id: 2, project_id: 1, name: "Test 'em", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">,
#<Task id: 3, project_id: 1, name: "Create demo app", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">,
#<Task id: 4, project_id: 1, name: "Scrutinize", due_at: nil, created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">]

>> project.author
=> #<Author id: 1, name: "Eloy", created_at: "2009-01-22 11:17:15", updated_at: "2009-01-22 11:17:15">

Now let's delete the first Task and change the name of the second Task:

>> project.tasks_attributes = { "1" => { "_delete" => "1" }, "2" => { "name" => "Who needs tests anyway?!" } }
=> {"1"=>{}, "2"=>{"name"=>"Who needs tests anyway?!"}}

>> project.tasks.first.marked_for_destruction?
=> true

>> project.tasks.forty_two
=> nil # Oops, I meant #second of course… ;)

>> project.tasks.second.name
=> "Who needs tests anyway?!" 

Finally, let's try to save the Project instance:

>> project.save
RuntimeError: Oh noes!
  from /Users/eloy/code/complex-form-examples/app/models/author.rb:9:in `raise_exception_if_needed'

An exception was raised while saving one of the nested models. Now let's see what happened to the data:

SQL (0.1ms)   BEGIN
Task Destroy (0.3ms)   DELETE FROM `tasks` WHERE `id` = 1
Task Update (0.2ms)   UPDATE `tasks` SET `updated_at` = '2009-01-22 11:22:23', `name` = 'Who needs tests anyway?!' WHERE `id` = 2
SQL (17.0ms)   ROLLBACK

As you can see, all changes were rolled back. Both updates as well as the removal of records marked for destruction all happen inside the same transaction.

As with any transaction, the attributes of the instance that you were trying to save will not be reset. This means that after this failed transaction the first task is still marked for destruction and the second one still has the new name value.

Conclusion

This patch allows you to create forms for nested model as deep as you would want them to be. Creating, saving, and deleting should all work transparently and inside a single transaction.

Please test this patch on your application, or take a look at my fork of Ryan's complex-form-examples which uses this patch.

Your feedback is much appreciated. However, keep in mind that we can't possibly satisfy everyone's needs all at once. Please suggest additional features or major changes as a separate ticket for after the patch has been applied. The goal is to fix the bugs in this patch first so we all have a clean foundation to build on.

On a final note, I would like to thank David Dollar for the original :accessible implementation, Fingertips (where I work) for sponsoring the time that has gone into this patch, Manfred Stienstra for extensive help on the documentation, and in no particular order Lance Ivy, Michael Koziarski, Ryan Bates, Pratik Naik and Josh Susser for general discussion.

RailsConf 2009: Viva Las Vegas!

RailsConf 2009 is now open for registration. We’re going to Las Vegas this year. More precisely the Las Vegas Hilton from May 4th through 7th. It’s going to be a party for sure.

There has been such an incredible amount of activity since last year. We have the merging of Merb back into Rails, Rails 2.2 and 2.3, and probably a good showing of Rails 3.0. So we should be absolutely packed for great content this year.

It’s going to be hard to top 2008, though. I really thought that was a fantastic show. Great lineup of proposals, great speakers, and a great sense of community. Which is pretty hard to do when you have almost 2,000 people gathered. So we’ll try extra hard this year to outdo it.

So I hope to see many familiar and new faces this year. We have early registration open until March 16th, so you can save up to $200 by getting it done early.

Don’t forget to get your speaker proposal in either. You have until February 17th.

See you all in Vegas!

This Week in Edge Rails

January 17, 2009 -January 23, 2009

Edge Rails saw 28 commits this week. Here’s a look at some of them. As always, you’ll want to go back to the GitHub commit list if you want to look at every single change. As we near 2.3, many of the commits we’re seeing are bug fixes rather than new features, and I’m generally not covering those here.

More Rack Middleware

The Rack-ification of Rails continues, with more and more Rails code being refactored into Rack middleware. This week, parsers for XML, JSON, and YAML got moved into ActionController::ParamsParser middleware. In the long run, this sort of refactoring will make many of Rails services open to other Rack clients, without every framework needing to reinvent all of the same wheels. commit

Deprecations

If you were one of the people who got used to running script/performance/request to look at performance based on integration tests, you need to learn a new trick: that script has been removed from core Rails now. But don’t worry if you depend on it. There’s a new request_profiler plugin that you can install to get the exact same functionality back.

Also on the deprecation list is ActionController::Base#session_enabled?, which now returns a deprecation warning when you try to use it. But given that sessions are lazy-loaded now, to disable them all you need to do to disable them is to not use them in the first place. commit

Local Caching for All!

Last week, we saw an improvement to caching performance when using MemCacheStore, keeping a local request cache to avoid redundant reads. This week, that work was refactored so that it can be used with any remote store. commit

This Week in Edge Rails

January 10, 2009 -January 16, 2009

24 commits for edge Rails this week (with one patch ported over to the 2.2 branch as well). If you want a pre-release look at Rails 2.3, this is a fine time to install a copy of edge, if you’re not already there. It’s plenty stable enough for test sites, though there are a few rough patches yet.

Nested Transactions in Active Record

Several people contributed to a big patch that gives us nested transactions in Active Record, a much-requested feature. Now you can write code like this:


User.transaction do
    User.create(:username => 'Admin')
    User.transaction(:requires_new => true) do
      User.create(:username => 'Regular')
      raise ActiveRecord::Rollback
    end
  end
  
  User.find(:all)  # => Returns only Admin

Nested transactions let you rollback an inner transaction without affecting the state of the outer transaction. If you want a transaction to be nested, you must explicitly add the :requires_new option; otherwise, a nested transaction simply becomes part of the parent transaction (as it does currently on Rails 2.2). Under the covers, nested transactions are using savepoints, so they’re supported even on databases that don’t have true nested transactions. There is also a bit of magic going on to make these transactions play well with transactional fixtures during testing. commit

MemCacheStore Enhancements

Nahum Wild contributed some work that (inspired by his spandex_mem_cache_store plugin) that enhances the performance of Rails when using MemCacheStore. The basic idea is to keep a per-request local cache of requests sent to MemCacheStore, cutting down on unnecessary reads and leading to better site performance. commit

Making Active Record Callbacks behave

You may recall the spot in the Active Record documentation that says “If a before_* callback returns false, all the later callbacks and the associated action are cancelled.” What you may not know is that this is actually broken in the current version of Rails: if you cancel a before_update or before_create callback, the after_save callbacks still run. In Rails 2.3, this will behave the way that the documentation says it does. commit

Fractional seconds for TimeWithZone

The Time and TimeWithZone classes include an xmlschema method to return the time in an XML-friendly string. As of this week, TimeWithZone supports the same argument for specifying the number of digits in the fractional second part of the returned string that Time does:


>> Time.zone.now.xmlschema(6)
=> "2009-01-16T13:00:06.13653Z"

commit

JSON Key Quoting

If you look up the spec on the “json.org” site, you’ll discover that all keys in a JSON structure must be strings, and they must be quoted with double quotes. As of this week, Rails does the right thing here, even with numeric keys. commit

Test Refactoring

Josh Peek spent some time refactoring various tests inside of Action Pack, including those for query string parsing, JSON parameter parsing, XML parameter parsing, multipart parameter parsing, and URL-encoded parameter parsing. While you won’t see any new functionality as a result of this work, it’s worth shining a spotlight on the often-thankless cleanup that keeps the Rails code in good shape.

Changes to Object#try

After some discussion, the semantics of Object#try have changed slightly: it now raises NoMethodError on private methods and always returns nil if the object is nil. commit

Rails Documentation Projects

With the recent revitalization of the Rails Wiki project, we’re seeing people ask how the various pieces of Rails documentation fit together. I thought it might be useful to lay out how the Rails Activists see everything fitting together as we move forward.

Rails is a large and mature framework, with a lot of functionality – and with the Merb merger, there will be even more to learn in the future. As such, it presents challenges for developers at all levels trying to understand how to use Rails effectively. There are many resources to help with the learning process, including commercial books and magazines, screencasts and podcasts, tutorials, blog entries, and training courses. But there is also a series of official written documentation projects.

There’s no such thing as one-size-fits-all documentation. Different developers bring different skill sets, backgrounds, and levels of professional maturity to learning Rails. There are at least four levels of official documentation, overlapping but serving different needs:

  • Inline documentation, with comments within the code itself (that you can see by running rake doc:rails within any Rails project).
  • Rails Guides
  • Rails Book (a new project for Rails 3.0)
  • Rails wiki

Although at first glance there appears to be substantial overlap, our feeling is that the each of these projects occupies a distinct (and valuable) niche.

RDoc

  • Provides immediate help for syntax questions
  • Maintained by the actual core developers and generally up-to-date

Rails Guides:

  • Provides focused “how to” help for particular problem domains
  • Target the mid-level developer, possibly with Rails experience
  • Have a large amount of existing high-quality material
  • Are already being continuously revised to track changes in edge Rails
  • Can include version-specific tutorial code samples
  • Can be delivered as a part of core Rails to provide “guidance at your fingertips” for new developers

Rails Book:

  • Provides high-level architectural guidance and overview of how the pieces fit together
  • Digs into the philosophy of the “Rails Ways”, so readers can understand why the framework works the way it does
  • Targets the developer new to Rails or those wanting to go from the “trees” to the “forest” view
  • Offers help in conceptualizing Rails and choosing between alternative modules (ORMs, routing DSLs, etc.) in the Rails 3 timeframe
  • Can draw on the Merb experience in simultaneous translation and pulling in contributions from many writers
  • Largely version independent
  • Gives a structured path through end-to-end documentation in a way that standalone Guides do not

Rails Wiki

  • Community-driven documentation that can respond rapidly to new software and new questions
  • A good repository to links to external information
  • Potentially a showcase for Rails itself in the underlying software
  • A place to put the accumulated community knowledge, even the pieces that are not often needed

It’s important to note that we don’t see these four projects as entirely separate efforts that have no interaction with one another. In particular, it seems likely that the Book will link to the Guides for those seeking additional detail, while the Guides will link to the Book for those seeking additional high-level guidance. We also anticipate that the wiki will point readers to both Guides and Book (as well as to other sources of information).

So, what can you do to get involved? If you’re a writer, translator, or editor, any of these documentation projects would love to have your help:

  • To contribute to the RDoc, write a Rails patch with good comments or check out the docrails project.
  • To help the Rails Guides, get in touch with Pratik Naik or Mike Gunderloy, or drop by the #docrails channel on IRC freenode.
  • To get involved with the Rails Book, contact Matt Aimonetti.
  • To add to the Rails Wiki, join the rubyonrails-wiki group.