AkitaOnRails

Isso criará um menu drop down com todas os fuso-horários disponíveis no TzInfo. O segundo parâmetro ('TimeZone.us_zones', no caso) é uma 'zona de prioridade'. O propósito é agrupar os fuso-horários mais relevantes no topo da lista. A classe TimeZone já possui um array 'us_zones' de instâncias de TimeZone, mas você pode usar qualquer outro grupo de TimeZones da sua localização atual.

Quando o usuário escolher, você deve pegar essa informação e salvar em algum lugar (o User model, por exemplo). Então, para cada requisição, quando o usuário faz o sign on, o before_filter do controller da aplicação ajustará o singleton 'Time.zone', como nós vimos anteriormente.

E é isso para o suporte à tempo. Isso abre muitas possibilidades e melhorias futuras, mas por enquanto é bom saber que toda a bagunça de uma gem separada, 2 plugins diferentes e uma alternativa imcompleta à classe Time se foram e deram lugar a uma abordagem mais consistente. Para saber mais veja: "RailsCasts":https://railscasts.com/episodes/106, "Ryan Daigle":https://ryandaigle.com/articles/2008/1/25/what-s-new-in-edge-rails-easier-timezones e  "Geoff Buesing":https://mad.ly/2008/04/09/rails-21-time-zone-support-an-overview/.

h2. "Sexier" Migrations

Este nome não é o oficial, mas as Migrations finalmente receberam um pouco mais de atenção. A essa altura, com projetos maiores sendo feitos, as Migrations originais tinham que evoluir. Eu encarei esse problema um pouco antes e a solução mais sensata que encontrei foi a da Revolution Health, as "Enhanced Migrations":https://revolutiononrails.blogspot.com/2007/11/enhanced-migrations-v120.html. Muitos outros tentaram resolver esse quebra-cabeças mas essa ainda era a alternativa menos enrolada.

_"Mas, qual é o problema?"_ você deve perguntar. Bem, deixe-me descrever um cenário hipotético.

* O desenvolvedor A começa um novo projeto Rails e cria algumas migrations. Como você sabe, os nomes delas começam com números incrementais, começando em 1, 2, etc. Então ele cria migrations até a 4 e faz commit do código-fonte no repositório central (Subversion ou algum outro).
* O desenvolvedor B faz check out do código e começa a colaborar no projeto. Ele precisa de dois models novos, então o 'script/generate migration' criará as migrations 5 e 6.
* Ao mesmo tempo, o desenvolvedor A continua programando e precisa criar outros três models. Lembre-se que neste ponto, a sua máquina só possui as migrations de 1 a 4, já que o desenvolvedor B ainda não fez commit do seu trabalho. Então o desenvolvedor A criará as migrations 5, 6 e 7.
* Agora o desenvolvedor B concluiu sua tarefa inicial e fez commit do seu trabalho no repositório.
* O desenvolvedor A faz update do repositório e recebe as migrations 5 e 6 do desenvolvedor B. Agora o desenvolvedor A tem duas migrations '5' e duas outras migrations '6'. Quando ele rodar 'rake db:migrate', as mudanças do desenvolvedor B nunca serão executadas porque ele já está na sua migration 7.

Existem muitas variações para este cenário, mas no final das contas:

* Você tem mais do que uma pessoa trabalhando no mesmo projeto
* Por causa da natureza do trabalho colaborativo, você necessariamente terá várias migrations atropelando umas às outras que ou conflitarão ou nunca serão executadas.
* Vários tipos de problemas não-triviais aparecerão muito rápido e a sua produtividade cairá rapidamente.

O que o pessoal da Revolution Health fez? Ao invés de incrementar com números inteiros, eles trocaram por *timestamps numéricos*. Então, um exemplo de nome para uma 'enhanced' migration seria: "1203964042_Adicionar_coluna_xpto.rb".

Isso evita ter identificadores conflitando, mas não resolve este cenário:

* O desenvolvedor A cria e executa duas migrations às 10 da manhã e faz commit na mesma hora
* O desenvolvedor B faz update do repositório, cria outras duas migrations às 11 da manhã, executa e faz commit na hora
* O desenvolvedor A cria duas migrations ao meio-dia e executa ambas. Só então ele se lembra de atualizar do repositório e depois faz commit do seu trabalho.

Percebeu o problema? Pelo fato das últimas duas migrations que o desenvolvedor A criou serem mais recentes que as do desenvolvedor B, mesmo depois de fazer update do repositório e rodar 'rake db:migrate', nada acontecerá, porque as migrations do desenvolvedor B são mais antigas e o plugin da Revolution Health só grava o timestamp da última migration que foi executada.

Então, mesmo que você evite os conflitos, ainda terá muitas oportunidades de perder migrations e de ter problemas difíceis de resolver depois, como uma coluna faltando porque sua migration nunca foi executada.

No Rails 2.1 ele registra todo o histórico de migrations (a tabela antiga schema_info foi substituída pela schema_migrations). No mesmo cenário acima, seria 'detectado' que as migrations do desenvolvedor B nunca foram executadas e então elas seriam executadas, mesmo que fora de ordem. Isso quase sempre funciona porque as mudanças de cada desenvolvedor não deveriam ser dependentes umas das outras (a menos que a última migration do desenvolvedor A remova uma tabela que a migration do desenvolvedor B tenta modificar, o que é raro).

*Desvio:* Na verdade, essa pode ser uma boa hora para adicionar o plugin Restful Authentication ao nosso projeto. Para isso, usaremos outro recurso novo no Rails 2.1: instalar um plugin de um repositório Git, assim:

<macro:code>
./script/plugin install git://github.com/technoweenie/restful-authentication.git