There's one fix I wanted to point out as I am transition over to using Rails 3 and using the new Passenger 3 modules. This blog post does a fairly good job of talking about setting up the whole scenario but there is one glaring omission: make sure the append a final "/" on the 2nd URL you specify in both the ProxyPass and ProxyPassReverse statements.

ProxyPass / http://127.0.0.1:3000/ 

ProxyPassReverse / http://127.0.0.1:3000/

Apparently, storing facebook related id's require more than your
straight-out-of-the-box integer column type. Instead, I found that you
can specify just about any rdbms-specific column type in Rails
migrations by doing the following:

create_table [:sometable] do |t|
t.column [:column_name], "[column type]"
end

Take special note that the column type must be in quotation marks. In
the case of "bigint", after running the migration, I noticed it
converted it to an integer type with a specific limit.

 

Something to consider when internationalizing your app in Rails, watch for spacing and how you form your arguments. I ran into a problem where my "I18n.t" tags were working on my development machine but then when porting to a different box, it completely crapped out. The culprit:

<%= link_to I18n.t 'finish.tag_begin',
"http://www.facebook.com/photo.php?pid=#{@photo_id}&id=#{@current_user.facebook_id}"
%> <%= I18n.t 'finish.tag_end' %>

 

Notice where "link_to" and "I18n.t" are in close proximity. It seems that my MacOS was more forgiving with the aforementioned syntax. Instead, make sure to put parentheses whenever you find yourself working with helper tags/methods that are in close proximity:

 <%= link_to I18n.t('finish.tag_begin'),
"http://www.facebook.com/photo.php?pid=#{@photo_id}&id=#{@current_user.facebook_id}"
%> <%= I18n.t 'finish.tag_end' %>

What a pain in the ass. As I'm learning to use rails/ruby, one problem
that I didn't really anticipate was dealing with time zone issues.
However, given the nature of my new job and the need to be precise
about cutoff dates and times, precise times are necessary.

Enter the fact that Rails, utilizing ActiveSupport's TimeZone library,
does type casting of date and time information. This became a pretty
big issue for me as I was expected to take in some date/time
information set to EST. One thing that was implied yet never
explicitly stated was that MySQL would store everything as UTC -7
(since I'm in PST).

As such, in order to resolve this issue, I found I had to do the following:

1. Comment out config.time_zone in environment.rb. By default, this is
set to 'UTC'

2. In my rake task, while looping through a csv dataset, I set my
timezone to 'Eastern Time (US & Canada)'

3. I then had to parse the string data and then set it to its
appropriate timezone as such:
t = Time.zone.parse(row[1].to_s)
time_str = t.in_time_zone('Pacific Time (US & Canada)').to_s

One big thing I noticed as I grokked the intertubes for info was that
many examples would encourage this syntax to fit the appropriate
RDBMS: t.in_time_zone('Pacific Time (US & Canada)').to_s(:db) #notice
the :db flag

The ':db' flag ended up messing things up for me. As soon I removed
it, things worked peachy keen.

I found this guide's ( http://guides.rubyonrails.org/routing.html#named-routes) somewhat confusing at first since I had assumed that "map.login" was some formal mapping command.

Instead, I've come to learn that named routes are simply shortcuts for url references in Rails apps. For
example, something like " map.my_history 'home/my_history', :controller => 'home', :action => 'my_history' " creates 2 new methods: my_history_url and hash_for_my_history_url. The former helps with whenever you need a reference to this route and the latter returns a hash used in conjunction with the "url_for" method.

So I should be able to say something like "<%= link_to "My History", my_history_url %>" in other parts of my code.

Totally a nerd posting but I'm just getting started on Ruby on Rails and it's been driving me insane just to try and figure out what the helper paths would be if I had say for instance an Rsvp model that had a many relation with a RsvpGuests model.

Turns out the syntax works out like this:

[first model name all lower case singular]_[second model name all lower case, camel cased words are separated by an underscore]_path

It might be hard to parse this but basically it looks like this for the Rsvp and RsvpGuests models where Rsvp has many RsvpGuests:
rsvp_rsvp_guests_path(@rsvp)

You could imagine other scenarios where this might come in handy to know when working on Rails.

FOLLOWUP:
On subsequent model pages (in this case RsvpGuests), here are the other _url and _paths that get generated:

rsvp_rsvp_guest_path(@rsvp, guest) #show
edit_rsvp_rsvp_guest_path(@rsvp, guest) #edit
new_rsvp_rsvp_guest_path #new