Note: For the purposes of this discussion, "accessible" means "accessible via mass assignment". See http://news.ycombinator.com/item?id=3781317.

The change in Rails 3.2.3 that will likely affect the most people is a new default setting in config/application.rb for newly generated applications. By default, Active Record is now configured to throw exceptions any time an attribute not included in attr_accessible is included in a mass assignment:

    .
    .
    .
    module SampleApp
      class Application < Rails::Application
        .
        .
        .
        config.active_record.whitelist_attributes = true
        .
        .
        .
      end
    end

(Exactly what this means is explained below.)

The model generators have also been updated to include an attr_accessible line. Unfortunately, if you include all of the attributes in the call to rails generate at the command line, they will all be accessible by default, which kind of defeats the purpose. For example, if you type

    $ rails generate model User name:string admin:boolean

you'll get

    class User < ActiveRecord::Base
      attr_accessible :name, :admin
    end

which probably isn't what you want: chances are that the admin attribute shouldn't be accessible. To prevent security holes, I therefore strongly recommend writing explicit tests for all inaccessible attributes (see below).

To see the effects of the new default, consider a User model with an admin attribute not included in the attr_accessible list:

    class User < ActiveRecord::Base
      attr_accessible :name, :email, :password, :password_confirmation
      .
      .
      .
    end

With the new default configuration, code like

    User.new(admin: true)

will raise an

    ActiveModel::MassAssignmentSecurity::Error

exception. You can test for this (in RSpec) as follows:

    describe "accessible attributes" do
      it "should not allow access to admin" do
        expect do
          User.new(admin: true)
        end.should raise_error(ActiveModel::MassAssignmentSecurity::Error)
      end    
    end

For more details, see the latest version of the Ruby on Rails Tutorial (http://railstutorial.org/book?version=3.2).

    u.role = params[:role] if role_safe?(params[:role])

One of the other interesting changes in this release from my perspective:

* Do not include the authenticity token in forms where remote: true as ajax forms use the meta-tag value DHH

This doesn't really explain accurately what happened. It's not that the default behavior changed; rather a new option was actually introduced to allow you to easily do this if needed for fragment caching a remote form without making it cache a stale authenticity token (used to protect against CSRF attacks).

From the core mailing list:

Rails 3.2.3 also introduces a new option that allows you to control the behavior of remote forms when it comes to `authenticity_token` generation. If you want to fragment cache your forms, authenticity token will also get cached, which isn't acceptable. However, if you only use such forms with ajax, you can disable token generation, because it will be fetched from `meta` tag. Starting with 3.2.3, you have an option to stop generating `authenticity_token` in remote forms (ie. `:remote => true` is passed as an option), by setting `config.action_view.embed_authenticity_token_in_remote_forms = false`. Please note that this will break sending those forms with javascript disabled. If you choose to not generate the token in remote forms by default, you can still explicitly pass `:authenticity_token => true` when generating the form to bypass this setting. The option defaults to `true`, which means that existing apps are NOT affected.

friend of mine recently asked "do you do rails?", I answered something like "nope, going to learn it only if it will be paid well". "well, you can get $150/hr on the project I am working on"...

After this conversation I became really interested :) My question - having no background in ruby or rails, should I just start from latest one? I.e. how compatible it with all code deployed already?

Michael Hartl's guide is excellent and can back that up as as a great starting point.

If you plan on running with a project that's already going that is going to slow down your learning curve. I would recommend doing things from scratch. It's important you truly understand what is happening then just a copy/paste action.

You'll catch a bit of unease with that motivation from some quarters, for what it is worth, but I generally applaud people making microecon 101 work for them.

There are two main branches of Rails in use today: 2.3.x and 3.x . Many of the idioms involved in day to day coding are strikingly similar, but the internals are incompatible in many ways. As a workaday Rails programmer you'll typically spend 95% of your time working far away from the internals, so a solid background in MVP design and Ruby / object oriented programming gets you pretty far on both Rails 2 and 3. Their magic incantations for doing some things are different but they can be cheat sheeted or Googled at need.

In general, you would expect greenfield development to be on Rails 3 but a lot of the money in the ecosystem is still in Rails 2 apps.

Don't sweat it. Try to get involved in a project that is from scratch, that way it won't be an issue.

I'll share my own story, having gone thru just this recently.

First I went thru Michael Hartl's tutorial back in Dec:

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

I believe it was in 3.0 at the time, now been updated to 3.2. No matter. I found a local business who needed something done but had never done more than Wordpress sites. I offerred my services pro-bono w/ a small equity share on the condition I could be mentored by a very sr. guy. At first they said "no, we want just one engineer solo on this". I said good luck with that and they got back to me two weeks later with a very sr. guy to give direction.

Beyond Hartl's excellent tutorial, which in printed form is probably 500 pages or so and will take maybe 40 hours of dedicated work, I highly recommend the Rails guides themselves. Just the getting started guide alone is chock full of info on getting a basic blogging platform together. In doing this project I have reviewed the majority of the Rails guides back and forth, read countless Stack Overflow threads, blog posts, rails casts, etc, and generally spend about 20-30 hours per week above and beyond my day job. The magic in this is that you will have to filter through a bunch of examples that may be several years old and are targeted at various versions of Rails, so you will sort of distill the differences in versions/idioms by osmosis in a way. If I had to take on a 2.3 code base at this point I doubt it would hinder me much.

Where do things stand now? Well, my current project is about to hit customer beta and my mentor has asked me to come along with him on another project for a client in NYC. Also I applied to a local early stage startup and despite having only 3 months under my belt they're considering bringing me on (they were looking for someone with 3+ years, but I learn quick and am very motivated :). If I get the job I'll likely take it (it's something I really believe in, potentially world changing stuff), say goodbye to the Windows enterprise world forever, and forgo doing further contract work for the time being as I won't likely have the time. My main interest now is getting good as quickly as possible. Long term, maybe this company will take off and I'll have the time of my life, maybe I'll strike out on my own startup, or maybe I too will pull $150/hr on contract. Who knows.

Rails 3.2.3 is compatible with Rails 3.1 and later versions. The main difference is a change in the default security settings (made in the wake of the recent GitHub mass assignment vulnerability—and, IMHO, long overdue).

If you want to get started with Rails, I suggest reading the Rails Tutorial, which I just updated to use 3.2.3:

http://railstutorial.org/book?version=3.2

If you're going to be working on a Rails 3.0 project, you can use the first edition of the book instead:

http://railstutorial.org/book?version=3.0

Screencasts for the 3.0 version are available at http://railstutorial.org/screencasts, and I'm planning to start on the 3.2 screencasts later today.