Em novembro do ano passado (2007) tivemos o RejectConf’07 em São Paulo, onde eu tive o privilégio de fechar o evento com uma palestra motivacional. Depois deste evento, tivemos muitos outros em vários estados do Brasil e online.
Nem faz tanto tempo assim, mas muita coisa aconteceu desde então. A comunidade brasileira de Ruby on Rails cresceu muito e muita gente conseguiu abandonar seus antigos empregos e começar a trabalhar exclusivamente com Ruby, alguns para empresas nacionais como no caso do Brasigo (que esta semana seu produto), outros para empresas de fora do Brasil.
Agora mais uma vez a comunidade de desenvolvedores Ruby e Rails volta seus olhos para São Paulo com o anúncio do Rails Summit Latin America, um evento que promete alavancar o crescimento da nossa linguagem e framework preferidos por aqui.
Infelizmente desta vez não vou palestrar, mas teremos pessoas mundialmente conhecidas como Dr. Nic, Obie Fernandez e até mesmo o criador do Rails, David Hansson em palestras com direito a tradução simultânea e tudo mais.
Para quem participou do primeiro RejectConf em uma sala de aula na USP, vai ser muito legal reencontrar toda aquela galera novamente num evento desta proporção.
Eu encontrei um serviço bem legal na internet que permite juntar vídeo com slides e resolvi dar um tapa no vídeo da palestra que fiz no RejectConf. Para os saudosos, ou para quem não pôde participar, o vídeo está aí embaixo:
Na próxima versão do Rails teremos uma forma mais elegante de fazer isto usando o método memoize (é memoize mesmo e não memorize). Vamos alterar o exemplo acima para funcionar com esta nova funcionalidade:
classPerson< ActiveRecord::Basedefage
um_calculo_muito_complexo
end
memoize :ageend
O método age será executado apenas uma vez e o seu retorno será armazenado e retornado em futuras chamadas ao método.
Só existe uma diferença entre os dois códigos acima. No primeiro, como o método é executado todas as vezes, se o valor armazenado na variável @age for nil ou false o cálculo (muito complexo) será executado novamente até termos a idade da pessoa.
No segundo exemplo, o método age só será executado uma vez e o valor retornado será sempre devolvido nas próximas chamadas, mesmo que seja nil ou false.
Além do map.resources, há também uma forma singular (ou “singleton“) de rotear recursos: map.resource. Esta forma é usada para representar um recurso que só aparece uma vez no contexto.
Faz muito sentido usar uma rota singular quando temos um recurso que será único dentro da aplicação ou da sessão do usuário corrente.
Por exemplo, em um projeto de uma agenda cada usuário registrado tem seu próprio catálogo de endereços, então poderíamos cria nossa rota assim:
map.resource :address_book
Com isto podemos usar todo o conjunto de recursos disponibilizados pelo Rails, tais como:
GET/PUT
address_book_url
GET
edit_address_book_url
PUT
update_address_book_url
Note que tudo está no singular. Estamos assumindo que no contexto atual não precisamos especificar qual catálogo de endereços desejamos, ao invés disso podemos simplesmente dizer “o catálogo de endereços”, já que o usuário atual só tem um.
O relacionamento entre a tabela de catálogos e o usuário corrente não é automático, você deve autenticar o usuário e retornar o catálogo dele. Não existe mágica ou poderes psíquicos aqui, é apenas uma outra técnica de roteamento a nossa disposição, se precisarmos.
Este episódio é curto, tem pouco mais de 30 minutos, afinal a vida está meio corrida ultimamente. Projetos… projetos…
Neste episódio comentamos sobre os 15 milhões que a Engine Yard recebeu e como eles pretendem gastar esta grana, mostramos um meio alternativo de usar o logo do Rails (?), explicamos o que é o DataFabric e fechamos com uma propaganda gratuita do Rails Summit Latin America (Locaweb, depois eu passo o número da minha conta).
