In 2007 DST changed and Mexico did not follow suit, so the short PST/EST/CST timezones were not specific enough anymore. Here is an excerpt from Wikipedia (http://en.wikipedia.org/wiki/Pacific_Time_Zone):
Effective in the US in 2007 as a result of the Energy Policy Act of 2005, the local time changes from PST to PDT at 02:00 LST to 03:00 LDT on the second Sunday in March and the time returns at 02:00 LDT to 01:00 LST on the first Sunday in November. Canada would also acknowledge this change. In Mexico, beginning in 2010, the portion of the country in this time zone uses the extended dates, as do some other parts. The vast majority of Mexico, however, still uses the old dates.
If timezones aren't good enough to display the time, what good are they? If Mexico is calling PST/PDT a different time than everyone else, shouldn't they be using new values instead?
The timezone names most countries use are not unique or entirely stable as time goes by. E.g., America and Australia disagree about what "Eastern Standard Time" means. That's why the Olson/Eggert database names zones for major cities, those are most stable and well known.
I like that you broke out and completed preparatory steps ahead of actually upgrading Rails, but the blog post points out some process smells.
Title Upgrading Airbnb from Rails 2.3 to Rails 3.0
Date January 4, 2012
Why are you blogging about upgrading to Rails 3.0.x when the current stable Rails has been 3.1.x for over 4 months?
> Our app was running Rails 2.3.8 at the time, and the production instances were a mess. Each instance had its own set of gems and its own versions of those gems. Naturally, none of the instances matched.
How did this happen?
> Tobi listed every controller in our app at the time and divided them among the engineers. The engineers went through the templates used by each controller and made sure string output in templates was marked as html_safe or rendered with raw where appropriate.
Most of the XSS work was done in a single day with all of the engineers' help, but there was cleanup on pages that weren't used very often that continued for several weeks after installing the plugin.
Why look at the controller granularity for templating bugs? If any controllers share a partial or helper, you may have engineers stepping on each others' toes.
Also, shouldn't these simple bugs be quickly and fully discovered by automated tests?
> We knew the real upgrade required major code changes, so four engineers started the upgrade on a Saturday afternoon when there were minimal changes being committed. We asked other engineers to hold off on changes over the weekend to prevent any merge nightmares.
If the upgrade is done on a branch, why must the work be completed during the weekend?
And why must you block changes generally for an entire weekend because of work done to a single branch?
> Why are you blogging about upgrading to Rails 3.0.x when the current stable Rails has been 3.1.x for over 4 months?
Like mentioned in another comment, upgrading from 2.3.x to 3.0.x is a feat in itself. Upgrading from 2.3 to 3.1 might be doable on a smaller project, but with code written in several versions of Rails we decided to go 2.3 > 3.0 > 3.1.
> Also, shouldn't these simple bugs be quickly and fully discovered by automated tests?
There was plenty of HTML inside Ruby statements in our templates that started being escaped. Something like:
while ugly was not wrong. This is a very simple version of some of the problems we saw, and there were typically several per template. Writing tests that check the HTML output of template files would be unmaintainable.
> If the upgrade is done on a branch, why must the work be completed during the weekend?
To avoid a big merge. We changed a lot of files and didn't want to have to re-check our work after letting Git auto-merge our changes.
When I've done similar upgrades, I've often found it quicker to have the previous code available to me in another checked out repo rather than switch branches and have to deal with any possible uncommitted changes issues.
I'm just as interested in knowing what happened after the upgrade. How's performance on 2.3 vs. 3.0? Are there plans to upgrade to 3.1 anytime soon? Has using 3.0 increased developer or ops productivity in any measurable way?
Assuming they were already running Ruby 1.9.x, they probably saw a smallish increase in response times moving from 2.3 to 3.0. I've seen that on two separate, large projects.
There is a drastic decrease in response times with switching from 1.8.7 MRI or 1.8.7 REE to 1.9.x MRI.
Are you asking why one might, in general, prioritize that upgrade? Rails 2.x to Rails 3 is a pretty big deal. For a huge production site, the "Merb-ificiation" (modularization) of Rails might be a performance/maintenance win.
(I have no idea why Airbnb in particular upgraded, but the 2->3 upgrade is in general very much worth it --- the new router and Arel alone are sufficient wins).
One of the major reasons for using a framework like rails is to take advantage of open source code that frees you to spend time focusing on your company's core competencies. Some of the most useful gems in the rails ecosystem no longer (or never did) support rails 2. This is the biggest reason in my mind, but release notes on rails 3 itself are here http://edgeguides.rubyonrails.org/3_0_release_notes.html
An amazing feat seeing that airbnb doesn't employ any programmers (I know that because the interface bugs I reported as a paying customer were handled by the PR department or simply ignored).
Sometimes at a startup you just don't have the resources to do everything. Upgrading to Rails 3 pays down their technical debt substantially and will help prevent interface bugs like the ones you encountered in the future.
This particular startup had VC money flooding them from all directions. The bugs are still there. One involves credit card access between users, the rest are trivial (the stuff you'd let a junior programmer handle). Upgrading to Rails 3 doesn't magically solve anything.
