Hoje vou falar um pouco para vocês sobre o RVM (Ruby Version Manager) que viabiliza a instalação de N versões do interpretador Ruby com suas respectivas gemsets.
Ou seja você pode desenvolver o projeto “ABC” usando o Ruby 1.8.7, com seu determinado conjunto de gems dentre elas o Rails 2.3.4, e ao mesmo tempo ter o projeto “DEF” usando o Jruby e o Rails 3.0.0, simples assim sem conflitos internos e liberdade total para o desenvolvimento.
Como faço ? Vamos lá, para quem quiser se aprofundar mais dê uma boa estudada em http://rvm.beginrescueend.com/, e para os mais ansiosos vou apresentar a receita de bolo 
Instalando o RVM
<<(curl http://rvm.beginrescueend.com/releases/rvm-install-head)
Habilite o comando RVM, inserindo a linha abaixo no arquivo ~/.bash_profile
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . “$HOME/.rvm/scripts/rvm”
Teste a instalação
rvm
Criando seu primeiro ambiente
Nesse primeiro exemplo vamos criar um ambiente com o Ruby Enterprise Edition, que é uma branch do MRI(Matz Ruby Interpreter, implementação canônica do Ruby) com uma série de patches que priorizam performance, escalabilidade, memória e etc. Para fazer isso faça o seguinte:
rvm install ree
Aguarde, pode demorar um pouco, ao final da instalação para conferir se tudo deu certo:
rvm list
Será apresentado uma lista do rubies instalados a partir do RVM
ree-1.8.7-2010.02 [ x86_64 ]
Para saber mais comandos:
rvm help
Agora que você instalou o Ruby Enterprise Edition, para usá-lo faça o seguinte:
rvm use ree
A partir de agora o Ruby executado será o Enterprise Edition, vamos instalar um gemset para nosso novo ambiente:
rvm gemset create meu-projeto
Foi criado um gemset dentro do ambiente do Ruby Enterprise Edition, e para usar
rvm gemset use meu-projeto
Pronto, instalamos o RVM, criamos um novo ambiente com o Ruby Enterprise Edition, e seu respectivo gemset, teoricamente tudo certo e para usarmos essas configurações em nosso projeto de uma maneira mais simples com um comando só, faça isso:
rvm use ree@meu-projeto
Entendeu ? informei ao RVM que quero usar o ambiente “ree” com o gemset “meu-projeto”
Quer algo mais simples ainda que garanto vai te poupar possíveis dores de cabeça ?
Crie um arquivo .rvmrc coloque na raiz do seu projeto com o seguinte conteúdo
rvm use ree@meu-projeto
BINGO !
Há 2 semanas atrás, junto com os amigos @alexanmtz, @pedroputz e @rodvlopes participei do Rails Rumble, onde cada time de no máximo 4 pessoas deve desenvolver um produto web usando Ruby on Rails (ou simplesmente o RACK) em 48 horas.
Foi uma experiência extremamente interessante, não conseguimos ficar entre os 25 finalistas, mas finalizamos o nosso aplicativo, que basicamente é um produto que une dois “atores”: guias turísticos independentes, ou empresas de turismo e é claro os turistas ! Dê uma olhada no Take a Walk.
Lições que aprendi:
Um planejamento prévio ajuda bastante, principalmente com relação ao escopo do produto.
Faça um protótipo antes (sim, é permitido)
Um pequeno exercício de modelagem também não faz mal a ninguém !
Se você vai usar alguma API faça um pequeno estudo antes (no nosso caso usamos a api do google maps)
O que fizemos bem:
Equipe multidisciplinar : 2 railers @eltonokada e @rodvlopes, 1 cara de criação @pedroputz e 1 desenvolvedor com foco no front-end @alexanmtz.
Deploy da aplicação no git push usando o esquema do post-receive-hook do github, implementamos uma solução bem simples e rápida que nos atendeu muito bem: cadastramos uma url de callback que é invocada após cada git push, essa url aponta para um arquivo .rb que executa os comandos git clone, roda as migrations e restarta o nginx
Usamos o janrain sem precisar implementar nada relacionado a login em nosso aplicativo, usando os logins de facebook, twitter, e etc.
Descansamos bem, afinal de contas 1 hora programando depois de 8 horas dormindo vale mais que 5 horas programando virado fica a dica.
É isso, foi uma experiência excelente que pretendo repetir a dose no próximo ano.
E at last but not least parabéns a galera do BeerCheckin que venceu com um aplicativo MUITO bom, e sim eles são brasileiros e assim como nós uma equipe formada por profissionais da globo.com.
A partir de dezembro, passo a ministrar o curso “Desenvolvimento Web com Ruby on Rails” no Ilearn. O curso terá duração de 24 horas, distribuídas em 3 sábados, antes de cair dentro do Rails, vou dar um apanhado geral na sintaxe do Ruby, histórico da linguagem, metaprogramação, sintax sugar, símbolos, blocos, enfim… confira a ementa
Espero você lá !
Quer visualizar as queries geradas pelo ActiveRecord em tempo de execução através do console do rails ?
É simples:
>> script/console
>> ActiveRecord::Base.logger = Logger.new(STDOUT)
>> Campanha.find(1)
SQL (0.1ms) SET NAMES ‘utf8′
SQL (0.1ms) SET SQL_AUTO_IS_NULL=0
Campanha Columns (1.4ms) SHOW FIELDS FROM `campanhas`
Campanha Load (0.4ms) SELECT * FROM `campanhas` WHERE (`campanhas`.`id` = 1)
Existe também uma outra maneira, que creio ser mais eficaz
adicione o método no seu arquivo .irbrc
def log_to ActiveRecord::Base.logger = Logger.new($stdout) ActiveRecord::Base.connection_pool.clear_reloadable_connections! end e no console: log_to
após executar a consulta através dos models do activerecord
Tenho um json cadastrado em um campo do meu banco de dados, preciso editar o json e em seguida fazer o update no banco, até aí nada demais, o problema veio quando ao atualizar o json no banco, caracteres como ã, é e etc eram convertidos para unicode, isso acontecia quando fazia o seguinte:
class TesteController < ApplicationController
def meu_metodo
meujson = JSON.parse(‘{“teste”:”ÃO”}’)
meujson.to_json
end
end
com esse codigo a variável meujson recebia {“teste”:”\u00c3O”}
Para debugar resolvi executar a mesma operação em um programa ruby que fazia exatamente a mesma coisa, mas a variável meujson recebia {“teste”: “ÃO”}
Isolando o problema observei que existe um conflito do to_json.
O programa ruby que fiz usava o método to_json da gem json, mas o controller rails que extende o ApplicationController, usa o to_json do ActiveSupport, sobreescrevendo o método to_json da gem json que resolve o problema dos caracteres especiais.
Para contornar esse problema faça o seguinte:
salve o codigo abaixo em: config/initializers/patches.rb
module ActiveSupport
module JSON
module Encoding
class << self
def escape(string)
::JSON.generate([string])[1..-2]
end
end
end
end
end
pronto, agora você pode usar o to_json sem problemas !
É isso, caso alguém ache alguma solução mais elegante, comente ! Espero que seja útil
Meu primeiro contato com Ruby on Rails, foi em 2008 e confesso que estranhei muito toda a “feitiçaria” do Rails. Para quem está acostumado com Java o mundo de Convention over Configuration soa no mínimo estranho em um primeiro momento. Felizmente depois de algum tempo me familiarizei com a linguagem, com o framework e não quero outra vida
Como todos, comecei com o scaffold e analisando o código gerado o que me soou mais estranho foi essa sintaxe:
:alguma_coisa_estranha
Que isso ? dois pontos antes ? que porra é essa ??
Se você também teve essa reação, vamos a explicação
:alguma_coisa_estranha é nada mais nada menos do que um Symbol em Ruby
Tá, blz isso é um Symbol, mas p que usar isso e essa sintaxe esotérica ? vamos lá
:alguma_coisa_estranha é a mesma coisa que “alguma_coisa_estranha”
ambos criam uma nova string alocando um espaço de memória reservado, e é aí que vem o pulo do gato, quando você usa a mesma string diversas vezes em seu código, da forma trivial
“alguma_coisa_estranha”
a cada vez que seu programinha ruby lê essa string ele faz o seguinte: String.new(“alguma_coisa_estranha”)
agora se você cria um símbolo
:alguma_coisa_estranha
e esse símbolo aparece várias vezes em seu programinha ruby ele não vai dar um Symbol.new(“alguma_coisa_estranha”) sempre, isso será feito apenas uma vez, é alocado um espaço de memória e a cada nova chamada ao invés do Symbol.new(“alguma_coisa_estranha”) o interpretador vai ler do mesmo endereço de memória criado no primeiro new do Symbol, economizando esforço do interpretador.
Sacou ? pronto era só isso agora nem ficou tão esquisito
Abraços!
Numa dessas conversas casuais com minha namorada, que é formada em comunicação social, resolvi me atrever a explicar para ela o que é TDD.
Não foi necessário eu exercitar minha didática, pois assim que eu ia começar a explicar (ensaiando mentalmente algumas analogias), ela meio que definiu muito bem. Como assim ? Bom, em seu dia-dia ela é responsável pelo jornalzinho interno da empresa em que trabalha, no nosso bate bola ela me explicou suas técnicas de redação: Primeiro ela enumera os pontos que deseja alcançar (nossos testes) e depois desenvolve o texto em acordo com os pontos (código).
TDD não se resume simplesmente a fazer testes unitários de código, já vi algumas situações em que se desenvolvia o sistema e depois eram criados os testes unitários, não, isso não é TDD.
Desenvolver orientado a testes é uma filosofia de desenvolvimento, onde primeiro você define o que você quer e depois cria-se a inteligência para se alcançar o resultado. (Lembra quando a professorinha dizia “e melhor entender do que decorar”, pois então antes de sair fazendo testes unitários em seu sistema procure entender a essência do que esta fazendo, e os reais porques disso tudo, e esse é meu interesse nesse post )
Vamos la, com essa abordagem, sua aplicação fica concisa, pragmática, orientada aos reais objetivos, sem devaneios ou loucuras ou códigos monstro que tentam se aproximar o máximo possivel de uma bala de prata, aqueles em que se fica horas e horas pensando: “… mas e se daqui algum tempo precisarmos de bla bla bla….” , se cria um mecanismo ultra complexo, onde o real objetivo da aplicação se perde, e fatalmente as exceções começam a mandar na inteligência da aplicação
Além de grande interesse por tecnologia, também sou um amante da filosofia, a base do conhecimento da civilização ocidental vem dos gregos, sim, o TDD também, a essência dessa técnica vem do Crivo de Erastótenes que foi um matemático grego que viveu em 285 a.c e criou tal algoritmo para o cálculo de números primos, e na sua técnica, antes de efetuar o cálculo ele definia o que se esperava.
Já que falei um pouquinho de filosofia, caso você esteja lendo esse post certamente você é um aficcionado por tecnologia, desenvolvimento e afins. Minha sugestão é: abra a sua mente, não leia apenas blogs técnicos, livros sobre linguagens de programação a,b ou c, leia também romances, sociologia, psicologia, biografias e quantas “ias” mais você puder. Como assim ? sim, isso vai fazer com que você exercite outras área do cérebro e certamente isso ajudará você a ser um ser humano melhor
Como disse no post retrasado, estamos usando o playframework em nosso projeto atual. Relatei um pouco sobre a facilidade de uso, mas, como nem tudo são flores, tivemos um pequeno problema.
Precisamos fazer um mock de uma dependência externa para realizarmos os testes unitários adequadamente.
Para isso a solução que encontramos foi utilizar injeção de dependencias, dentre seus plugins, o playframework possui o spring, que é um framework que tem como funcionalidade fundamental: a injeção de dependências. Até aí tudo bem, desenvolvemos nossos testes como manda o figurino, tudo saiu redondo, até que quando fizemos o deploy para o ambiente de desenvolvimento, as coisas não deram muito certo ;-(
Por alguma razão quando rodávamos os testes explodia no log o seguinte erro: Spring Context not started. Mas que raios ? se em nosso ambiente local de funcionava (cowboy code total :” na minha maquina funciona !” ). Vamos lá a diferença era: no ambiente local funcionava rodando no webserver que o playframework levantava, mas, no jbossweb ja era diferente. Estavamos chegando perto, até que com ajuda do commiter principal do projeto descobrimos que o comando “play war” (empacota a aplicação para que ela rode em um container, no nosso caso o jbossweb) nao estava copiando alguns arquivos de configuração para seus respectivos lugares, dentre eles o play.plugins que era o responsavel por apontar o uso do spring, bingo !
Prontamente eles corrigiram o bug, é por essas e outras que cada vez mais acredito na filosofia open source, que busca sempre a evolução a partir do conhecimento coletivo !
Há algum tempo atrás, comecei a fazer alguns testes usando o google appengine, coloquei uma aplicação simples em produção em pouco tempo, apesar de estranhar um pouco algumas coisas, gostei muito da praticidade e da ferramenta de administração que eles disponibilizam. Mas… minha aplicação estava sem testes unitários. Confesso que fui um daqueles que dizia “se nao der tempo, vamos fazer sem testes mesmo”, mas o TDD é um caminho sem volta, conforme se vai praticando, surge um clarão e tudo começa a fazer sentido, o que senti mais dificuldade foi fazer os testes antes do código. Quanto a isso agradeço ao meu grande parceiro de código Emerson, que me catequisou no TDD.
Nesse final de semana voltei a trabalhar com o google app engine, só que agora em um outro projeto, lendo os tutoriais do google appengine não tinha encontrado muitos exemplos de TDD, até que encontrei um framework esperto de testes unitarios GAEUnit http://code.google.com/p/gaeunit/
Ainda não fiz muita coisa mas em breve venho com mais impressões =)
Eis que nosso time recebe mais uma nova missão: disponibilizar uma aplicação para que nossos usuários se inscrevam para um processo de seleção de perfis. A primeira vista simples, não ? Mas o buraco é muiiito mais embaixo, pois o nosso querido formulário tem cerca de 70 campos, dentre eles alguns dissertativos, com validações diversificadas, integração com outros sistemas como o de autenticação e o de envio de vídeos, além de um fator crítico: precisamos de alta disponibilidade, e sim, essa aplicação será MUITO acessada.
Esse é o cenário, agora a solução. A última aplicação que desenvolvemos era orientada a serviços, onde tínhamos o front-end feito em Flash/ActionScript, e os nossos serviços em python, utilizando o framework django, e posso te dizer que foi bem divertido, principalmente porque aprendemos muito. Nunca tínhamos feito nada expressivo em python e tivemos um grande avanço e satisfação. Tendo isso, pensamos “vamos fazer em python” sim, foi bem divertido a linguagem e pragmática, o django e muiito bom Mas… devido aos servidores que serão utilizados e o prazo apertado, é mais viável desenvolvermos a aplicação em Java.
Eis que surge o playframework, um full-stack framework com um propósito bem semelhante do django / rails, só que para java.
Ficamos muito impressionados, e bem felizes com a curva de aprendizado e velocidade de desenvolvimento, com configurações simples e, funcionalidades poderosas, nosso projeto está de vento em popa em apenas 3 dias de sprint. Usamos, spring, hibernate,junit, log4j, selenium e etc.. etc.. tudo isso sem configurações monstruosas, enfim.. tudo isso de uma maneira bem ágil e sem reinventar nada !! e nos concentrarmos efetivamente no real propósito da aplicação !!! na lógica de negócio.
Em tempo de desenvolvimento ele levanta um webserver muito leve, nao há a necessidade de restarts na aplicação, e como disse com configurações extremamente simples
Vai lá e da uma olhada no play !!
