Actually, I think it’s a good think to learn both, or as much stuff as you can, because different approaches and philosophies provide different vantage points for dealing with similar issues. Of course, it’s probably out of the question that newsroom developers can go to their IT folks and say, “This week it’s Django. Next week, Rails. After that, who knows?”

So if you have to choose, consider these factors:

1. Do you have in-house expertise in either the framework or the underlying language? If so, take advantage of that. I know I’d still be a Python moron without the near-constant guidance I got from Adrian when I worked at WPNI. I’d be more of a Ruby moron without my fellow developers at the Times.
2. Is this your first time with a programming language? Personally, I found learning Python easier than I expected and I found that learning Ruby was easier because I knew some Python. YMMV, of course.
3. Are you going to need admin apps for much of what you build? If so, then I think that makes Django more attractive, since the admin is such a nice app and it comes baked-in. (Yes, Rails has scaffolding, but it’s not designed to be a full-fledged admin out of the box.)

Here’s what you don’t have to worry about: finding developers that know either Python or Ruby. There are a good number of them, and these frameworks are fun to work with. You don’t have to worry so much about backend issues: both run fine atop MySQL, Postgres and SQLite databases. SQL Server only? Django’s not gonna be as helpful, although you could always be the person who helps make support for it a reality.

The main philosophical difference between the two that I see in practice is the configuration vs. convention thing. Django doesn’t have, for example, a recommended JavaScript library; it leaves that up to you. Rails also allows you to use pretty much whatever, but it puts Prototype out there as sort of a default that you can override. Your reaction to issues like this will depend a lot on your own personal habits and experiences. So try both (or more). See what you like. Then go with it. Just don’t forget that there are always other ways of doing things, and you can learn a lot from them.

But most trainings are highly dependent on the instructor, and having Charles Brian Quinn was a great benefit. Yes, CBQ knows his Rails, but maybe more important was that he kept the same energetic and patient demeanor the entire week. Think about it: he was the only instructor for a class that had a wide range of backgrounds and experience, and he was unflappable from 9 am to near 11 p.m. every day. That’s pretty remarkable, and it helped make the class even better.

The class covered quite a bit of material – “as much as [Charles] could possibly cram into five days”, as the certificate says – so I don’t have any complaints about substance. One possible suggestion would be for BNR to do a brief poll of attendees to get a sense of their experiences/backgrounds, and distribute that to the class beforehand. That could help an instructor plan and would also save a few minutes on Monday morning, when we were all raring to go.

In all, I’d definitely recommend Big Nerd Ranch for its total immersion learning style. Oh, and I’m thinking of incorporating an afternoon walk into my schedule, too.

So instead of calling create, call Object.new and pass in the individual params except the ID. Then, on the next line, assign ID and then call save. Voila.

In action, then:

@person = Person.new(:first_name => params["person"]["first_name"], :last_name => params["person"]["last_name"])
@person.id = params["person"]["id"]
@person.save


Not that I recommend this for external apps, mind you. But it might come in handy in some circumstances.

Update: Aron suggested that this could be done without passing individual params items, and he’s right. You’d just have to pull out the ID first and assign it temporarily, then pass the entire params["person"] hash in our example to the create call and finally add the ID element back before saving.

• Using partials with bject and not :locals (no need to put the instance variable in every controller that will make use of a partial). Plus, collection in partials to display tables of data, for example. And partial _counter, too. (ie, widget_counter). Dang, I had no idea.
• Ok, I’m finally clear on setting up HABTM associations. Finally.
• Route names: another thing that you don’t really realize are more valuable than they appear.
• Beginning to understand how Rails handles resources as well.

• .map { block } is plenty cool. .map(&:symbol) looks odd, but is more succinct.
• I now realize why you might render to a template. Cool.
• Array has a .to_csv method. Nice.
• Creating a new logger object and having it send to STDOUT helps make script/console more helpful.
• I now realize why flash is really useful.
• Controllers can figure out a url from an instance variable, apparently (Rails 2.0)

One thing that I noticed was that in a rake task, requiring ar-extensions right at the top of the file, before the environment was loaded, resulted in a MySQL error (this occurred on MySQL 5.0 and 5.1). A colleague got it to work by important individual functions within ar-extensions, but I was able to load the entire plugin inside the task after I established a connection to the database. Like this:

task :some_task => :environment do
ActiveRecord::Base.establish_connection()
require 'ar-extensions'

Not the cleanest way, perhaps, but it works, and gives you access to all of ar-extensions goodies, which include some ORM syntax that can keep you from jumping into SQL in the :conditions portion of a ActiveRecord find. So, instead of :

Thing.find :all, :conditions => ['begin_date > ?', date]

You can write something like:

Thing.find :all, :conditions => { begin_date_gt => date }

Ar-extensions also provides a to_csv functionality to enable quick CSV dumping.

I started out by reading a book on Active Record, which is the ORM for Rails, and I would suggest that to anybody coming to Rails from a database background, because that way you’re not struggling to pick up both database concepts and Rails/Ruby syntax. Migrations? Good. Rake tasks? Good. The book itself is a decent practical guide, though not perfect, and will be a useful reference for me as I progress.

A very helpful book for me has been David Black’s “Ruby for Rails”, which is a great guide to syntax and concepts for people like me who are new to these things. On many levels, Ruby is elegant and makes a great deal of sense.

The other resource that I couldn’t do without is my colleagues, all of whom are much better-versed in Ruby and Rails than I am. Learning this in isolation would be a much greater challenge.

I’ve got a lingering preference for the url layout of Django, which allows uses regular expressions to construct any kind of url I’d like, and I’m sure I’ll get more comfortable with Rails’ routing and controller syntax as I get further into those areas. And yes, there is that magic, too, which has its ups and downs. Suffice to say that I’ll still be using Django for personal stuff, but you’ll see me experiment with Rails outside work as well.

In December I was in New York and went with one of the nytimes.com developers to the RubyNYC meeting, where features of Rails 2 were being discussed. It was an interesting presentation – much of it over my head – but one of the points that grabbed my attention was a brief discussion of the use of slugs in Rails. Slugs? Where have I heard that before? Nice to see a newspaper term work its way further into the Web.