This morning I updated the Ruby on Rails Tutorial book (http://www.railstutorial.org/) accordingly. Happily, since the changes between versions were minor, this mainly involved
I've been going through Rails Tutorial for the past few weeks. You definitely have a gift for communicating clearly and effectively. I would strongly recommend Rails Tutorial to anyone looking to get started with Rails.
Some nice changes there. Namespaces make it even more easy to work with legacy databases or mixing rails tables with say wordpress which prefixes all its tables with 'wp_'. Another nifty change w.r.t MySQL: positioning using :first => true and :after => :other_column. That allows us to keep the attributes in a nice order. Otherwise all the new columns used go below created_at and updated_at which was kind of ugly.
So have I actually, on some smaller projects, but it's going to be a major change to switch over larger ones. I'll be sticking on 2.3 with them for the time being.
Without this ad-hoc "fix" (well it's not a fix, I was using it just to confirm the source of the bug) I'm seeing:
Encoding::UndefinedConversionError: "\xC4" from ASCII-8BIT to UTF-8
all over the place (every time the log is flushed).
p.s. just to clarify, I was testing an app that currently runs in production on ruby 1.8.7 + rails 2.3.5 with rails 2.3.6 and ruby 1.9.2-head. 30 or so tests fail and about 70 have errors. I'll be sure to report any new bugs I find.
I'd be interested to learn where the BINARY data is coming from in the first place. For reasons I outlined in a recent blog post force_encoding is almost never a reliable general-purpose solution