This post is dedicated to the odd stuff actually present in Rails 2-3-stable and some gems/plugins.

It’s written in hurry, I’ll probably write another post detailing my experience in migration a big project from Rails 2 to 3; I can’t tell when it will happen but hopefully soon.

1) find_each mantains the scopes forever.

Suppose you have a normal AR callback on a Class (Track in this example) and some named_scope.
Take a look at this code:

tracks.marked_for_deletion.find_each(:batch_size => 100) do |trk|
trk.destroy
end

When in your callback you want to execute some basic AR finders, they will keep any scope defined in the find_each constructor, in this case user and marked_for_deletion.
Not fun but it works this way, a normal find doesn’t retain scopes.

2) to_json does not support :procs.

In the rare occasion that you need to support Proc in your custom to_json you’re out of luck.

3) Use VCR if your tests needs an internet connection.

VCR is an awesome gem that in my opinion surpassed any other tools in its category, you can find it here: http://github.com/myronmarston/vcr

4) Less dependencies

The road to upgrade a big app to Rails 3 is not exactly straightforward, especially if you made use of ‘hacks’.
But hacks are the lesser problem when you are tied to plugins/gems that breaks every now and then.
I learned to stay away from gems such as searchlogic and formtastic, they breaks with every Rails upgrade (even stable) and reported tickets doesn’t get looked at if the problem you are describing is odd or no one else confirms.
Being an edge user I do my homework and whip up a patch if possible, but sometimes it just gets ignored because “we aren’t targeting this rails release yet”.
Forms are boring to write, but if you write them “the rails way”, maybe with a custom builder, you know for sure that they will always work.

5) TDD is very useful, but..

I bet that even amongst the TDD evangelists there is someone that doesn’t always write code in advance.
I’m not sure if I’m the first to point out the obvious (or the most courage one, admit it), but you can’t always know where your code is going.
Sometimes you are in hurry and write tests later, sometimes you do not write tests at all because the thingie is super-easy (or at least it seems) that it’s not important if you don’t write a test immediately, it can’t break.
Well, it will.
So, my advice is not to lose your sanity and write always tests first (especially when you know your app is complicated and not a collection of scaffolds), but please do write them.
If you know that you are getting behind with your tests take some hour to do them, run rcov, which should indicate where you need them the most, but don’t accumulate too much code not covered, it’s guaranteed that it will backfire horribly.

6) If you are using paperclip and you need reliable content-type detection..

You are not so lucky. Paperclip is a cool plugin/gem but for some reason when I want to extend the code I lose my sanity. Now after one year of using it extensively I know it rather well, but for some reason from the one million ticket Thoughtbot have on this problem very few gets integrated.
Reliable content-type detection is a pain. I found the best workaround examining all the paperclip forks and merging my changes.
If you want to take a look just search masterkain on github and look at it.

7) Shoulda changed heavily

The new rspec-matcher syntax is pretty cool. However that required me a solid day of work to convert everything; if you intend to keep it around better start now.

8) Bundler and :git repositories

At the time of writing Bundler have a small problem, if you run Passenger in development bundler cannot find gems you included through :git.
And yes, I use bundler on rails 2-3-stable, it comes with some pain but at least less stuff to upgrade when making the switch to Rails 3.