Ruby 1.8, Ruby 1.9, Rails 2, Rails 3, cada projeto usando diversas gems. Como isolar esses ambientes para evitar conflitos?

Em Outubro de 2007, surgiu uma ferramenta chamada RVM, com o objetivo de criar ambientes isolados para desenvolver software em Ruby, permitindo que programadores pudessem usar várias versões de Ruby e Gems numa mesma máquina de forma limpa e sem conflitos. O projeto vem se tornando mais popular este ano, e de fato tem se mostrado muito útil. A lista dos autores pode ser conferida aqui.

Instalação

Para instalar o RVM, não é preciso muita coisa além de um ambiente POSIX (linux, bsd, etc). Eu instalei no meu Mac sem problemas. Eu acho que a única coisa que não vem por padrão que você precisa instalar é o git, que é usado para instalar/atualizar o RVM e instalar/atualizar as versões de Ruby.

Dito isso, abra o terminal e execute o seguinte comando:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

O procedimento não deve demorar mais que alguns minutos, dependendo da sua conexão. Em seguida, abra seu profile (.bash_profile, .profile, .bashrc, etc) e adicione as seguintes linhas:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source “$HOME/.rvm/scripts/rvm”
PS1=”\$(~/.rvm/bin/rvm-prompt) $PS1″

A segunda linha é para que a versão do Ruby que você estiver usando apareça no prompt, caso contrário você vai precisar ficar verificando a todo momento qual versão você está usando e isso pode ser bem chato.

Em seguida, carregue o rvm (da próxima vez que abrir o shell isso não será mais necessário):

$ source ~/.rvm/scripts/rvm

Pronto, o RVM está instalado e é hora de começar a arrumar nosso ambiente.

Instalando versões de Ruby

A partir do RVM, é possível instalar qualquer implementação Ruby. Por exemplo, podemos instalar o Ruby, Ruby Enterprise e o Jruby. Para uma lista completa acesse aqui.

Nesse tutorial, vamos instalar o ruby 1.8.7 . Execute o comando abaixo no terminal:

$ rvm install 1.8.7

1.8.7 é um atalho para o último patchlevel da verão 1.8.7 do Ruby. Em geral, isso funciona para todas as versões. A instalação demora um pouquinho, mas nada absurdo, portanto vá tomar um café e volte. Após o termino, “entre” no ambiente do Ruby instalado.

$ rvm –default 1.8.7

Nesse momento, você entrou no Ruby 1.8.7 e definiu essa VM como default no RVM.

Para voltar ao Ruby do systema (fora da RVM), basta ir no shell e digital:

$ rvm use system

Para listar as VMs instaladas (ou Rubies como preferem os criadores e como chamaremos a partir de agora), basta digitar:

$ rvm list

Escolha a Rubie e use-a conforme o exemplo abaixo:

$ rvm use 1.8.7

Instalando as Gems

Uma das manias que a maioria dos Rubistas tem é instalar as gems usando sudo. Isso hoje em dia é considerado má prática. Ainda mais com RVM, já que a intenção é criar uma espécie de SANDBOX por usuário/aplicação, conforme veremos a seguir.

Primeiramente vamos ver as gems que estão instaladas na nova Rubie. O comando é o já conhecido gem list. Ao rodar esse comando na Rubie instalada pelo RVM, você pode ter a impressão que suas gems sumiram, mas na verdade isso é exatamente o esperado, pois cada Rubie tem seu ambiente totalmente isolado. Para ter uma idéia, rode o seguinte comando e veja o output:

$ rvm info

O output fornece toda a informação sobre o ambiente dessa Rubie que está sendo usada no momento. Observe bem a linha home: \n gem:. Nela você verá onde estão sendo instaladas as gems. Repare que ele cria uma estrutura de diretórios sugestiva para você manter suas gems bem isoladas. A estrutura é a seguinte:

~/.rvm/gems/{Rubie@Gemset}/

Todas as gems serão instaladas nesse diretório. Não estranhe o @Gemset, falaremos dele adiante.

Vamos então instalar o Rails nessa Rubie. Não use sudo pelo amor de Deus

$ gem install rails –no-ri –no-rdoc

Depois execute um gem list para ver seu ambiente instalado. Se quiser, execute rvm system e veja que suas gems no ruby do sistema provavelmente são totalmente diferentes.

Gemsets

Vamos falar agora do tal @Gemset que eu coloquei na estrutura. Gemsets é uma forma de criar uma SANDBOX mais “profunda”. Em um primeiro momento pode parecer desnecessário, mas se você pensar que pode ter mais de um projeto por Rubie e não quer que as gems deles se misturem nem gerem algum tipo de conflito, essa estrutura passa a fazer todo sentido.

Supunha que você tenha um projeto chamado blog. Para criar uma gemset (e entrar nele) para esse projeto basta executar o seguinte comando:

$ rvm gemset create blog && rvm gemset use blog

Feito isso você verá que no seu prompt (se você fez essa configuração de instalação) estará aparecendo da seguinte forma: rubie@gemset. Rode o comando gemlist e verá que novamente suas gems que foram instaladas na Rubie sumiram. Mais uma vez isso é esperado, pois acabamos de criar uma nova SANDBOX para esse projeto específico. Nesse momento, basta instalar suas gems nessa gemset que seu projeto terá um ambiente totalmente isolado.

Se você executar o rvm info, verá que a home das suas gems está com um path diferente do anterior, pois o rvm criou um diretório para a Ruby com a nova Gemset, deixando tudo muito bem organizado.

Existem algumas gems que todos os projetos podem precisar, como Rake e Capistrano. Não seria uma boa idéia instalar essas gems em cada gemset. O RVM nos dá uma ajuda nesse sentido, criando uma gemset global, permitindo compartilhar gems entre todas as gemsets de uma Rubie. Para instalar uma gem nessa gemset basta mudar para ela e installar, como já vimos anteriormente. Vamos a um exemplo:

$ rvm gemset use global
$ gem install capistrano capistrano-ext –no-ri –no-rdoc

Pronto, essas gems não precisam mais ser instaladas para cada projeto novo que você for rodar nessa Rubie.

Conclusão

O Ruby Version Manager é uma ferramenta muito interessante para gerênciar seu ambiente Ruby. Ter vários Rubies instalado se torna cada vez mais comum, pois os projetos antigos precisam ser mantidos e novos projetos surgem, usando Rubies mais novos. O uso dos gemsets para isolar as gems também faz toda a diferença, evitando diversas dores de cabeça e deixando o ambiente organizado e limpo. Vale a pena experimentar.

<< UPDATE >>

Tem um comando importante que não abordei que é o rvm list known que mostra as opções de Rubies disponíveis para instalação. Créditos ao Rodrigo Lopes.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Nos últimos anos, alguns sistemas foram construídos para melhorar esse canal de casting (i.e seleção de pessoas)desses programas para a TV Globo. Porém, a cada iniciativa nova de casting por parte de um programa, era necessário criar um novo sistema de acordo com as necessidades. Até ai tudo bem, afinal de contas cada programa tem uma necessidade específica. Por muito tempo, usamos também o nosso 8p para ajudar nesse sentido, inclusive para clientes importantes, como Musas do Brasileirão e Big Brother Brasil.

Passado algum tempo, percebemos alguma semelhança entre as iniciativas de casting. Em sua maioria, a opção era um formulário de perguntas e respostas e o envio de um vídeo. Sendo assim, resolvemos desenvolver uma solução para possibilitar o cliente criar uma nova campanha de casting em alguns dias.

De toda essa experiência, criamos um projeto chamado Plataforma de Participações, com o objetivo de oferecer aos nossos clientes da TV essa forma simples de criar campanhas. Basicamente quem monta uma campanha hoje pode escolher se tem formulário, vídeo ou ambos e pode fazer uma definição completa do seu formulário (caso exista), configurando cada pergunta e seu tipo de resposta, precisando de pouca ajuda técnica para colocar sua campanha de casting no ar. Cada cliente também personaliza seu header, preservando assim a identidade visual da sua marca.

Como todo produto ágil, existem outras features no backlog para atenderem algumas demandas dos nossos clientes.

Nossos primeiros clientes são o No Limite e o Lata Velha do Caldeirão do Huck que já estão no ar há algumas semanas e mostrando que essa Plataforma de Participações tem se comportado muito bem nesse começo.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

No início

Em meados de 1997/1998, pouco antes da bolha da internet, quando eu comecei a trabalhar profissionalmente, eu trabalhava com eletrônica e informática em uma empresa de automação de ponto e acesso. Tive a oportunidade de usar Delphi para desenvolver um protótipo de sistema integrado ao hardware de ponto e acesso dessa empresa, pois eles usavam um programas DOS para extrair dados e jogar num arquivo texto, e o outro programa DOS fazia a leitura desse arquivo para gerar o resuldado de ponto e o acesso. Foi uma experiência ótima, pois meu protótipo acessava diretamente o equipamento pela porta serial e já mostrava as informações em tempo real. Essa idéia foi pouco tempo depois usada pela fábrica para novas versões do software.

Nessa época, a programação desktop ainda reinava e as opções mais comuns eram Delphi e Visual Basic, então sempre algum colega ou outro puxava a sardinha pro lado do Delphi ou do VB. Nessa época, confesso que eu era meio bobo no assunto e eu acabava entrando na onda também, principalmente falando mau do coitado do VB. Tempos depois acabei trabalhando com VB em outros lugares e pude perceber que existia aplicação para ele dependendo do caso. Confesso que sempre gostei mais do Delphi, mas nesse momento eu deixava de ser um apaixonado e passava a fazer a escolha de forma mais racional.

Surge o desenvolvimento pra Web

Quando começei a trabalhar com web em meados de 2000, trabalhei com PERL, depois ASP e ColdFusion. Nesse tempo, surgiu a versão Beta do DotNET em 2001. Foi quando comecei a desenvolver aplicações desktop em WindowsForms e alguma coisa web, com o objetivo de aprender.

Passado pouco tempo e fui trabalhar numa empresa onde usavam tudo da Microsoft. Java nem pensar nessa empresa. Todos falavam mau da Sun e do Java. Nessa época eu já estava bem escaldado com isso e não ia cair nessa novamente, perdendo meu tempo discutindo sobre quem era melhor, Java ou DotNET.

Passado mais um tempo, fui para uma outra empresa onde tinha projetos em DotNET, mas também tinha projetos Java. Como eu já estava estudando Java fazia um tempo, era uma ótima oportunidade para por em prática em algum projeto. Assim que surgiu uma vaga, me ofereci para entrar num projeto de um grande ecommerce brasileiro (que por algumas questões não posso citar o nome). Esse projeto foi ótimo para eu por em prática meus conhecimentos de Java. Nesse momento eu percebi que o pessoal de Java também gostava de falar mau do pessoal de DotNET. Na minha mente estava bem claro que isso era pura perda de tempo, pois claramente nos projetos que eu havia trabalhado eu pude perceber o valor de cada uma dessas tecnologias em cada contexto.

Passou o tempo e acabei não trabalhando mais com DotNET. As empresas seguintes foram todas com Java, exceto aqui na globo.com, onde voltarei a falar mais pra frente.

Muitos FUDs

Uma coisa que sempre percebi nessas brigas é que raramente usava-se argumentos lógicos e bem fundamentados. Geralmente as discussões eram baseadas em achismos e usavam algum argumento falacioso ou duvidoso/pouco claro.

Quando trabalhei para algumas empresas de Telecomunicações, Bancos e Seguradoras aqui no Rio de Janeiro, quase sempre havia um bom legado em COBOL e seus velhinhos de plantão dando manutenção nesses sistemas. Volta e meia eu ouvia algo do tipo: “Esse negócio de Java é apertar botãozinho e ta tudo pronto. Homem que é homem programa em COBOL”. Isso não fazia o menor sentido e por mais que eu tentasse explicar pros caras que não era bem assim, não adiantava, já existia uma opinião sem fundamentos formada na cabeça deles.

Numa dessas últimas empresas que trabalhei (para um dos maiores Bancos do nosso país), eu era Arquiteto junto com mais 14 desenvolvedores em um projeto Java que precisava se comunicar com programas COBOL/CICS. Sabe o que os COBOLEIROS diziam? “Só usem java pra pegar o que for processado aqui no COBOL porque aqui é que aguenta o tranco. Esse negócio de Java só serve para a parte levinha“. Apesar de conhecer sobre todo o poder de processamento dos Mainframes, eu sabia que aquilo era apenas uma provocação, pois eu já havia trabalhado em sistemas web feitos com Java com volumes bem maiores que os desse sistema e tudo correu muito bem. Sendo assim, nem entrei em discussão sobre isso, pois eles já tinham se fechado para o assunto.

Nossos dias atuais

Hoje em dia está muito na moda o uso de linguagens dinâmicas como Ruby e Python para desenvolvimento de software, muitos deles aplicações web. Existem diversos casos de sucesso usando essas tecnologias, e mais uma vez surgem as brigas pra saber qual é a melhor: Ruby ou Python.

Não espere aqui uma opinião minha sobre o que é melhor entre as 2, pois isso não vai acontecer. Não porque eu não tenha preferências, mas simplesmente porque melhor ou pior sempre dependerá do contexto e não somente da tecnologia.

Python é uma linguagem muito usada no mundo opensource, tendo muitos aplicativos console e desktop desenvolvidos para linux. A primeira versão do Youtube foi escrita em Python (não sei se ainda é). O Google AppEngine apesar de suportar Java, foi construido para Python. Existem diversas iniciativas que usam Python e são bem sucedidas.

Ruby apesar de ser uma linguagem bem antiga (1993), só explodiu mesmo com a chegada do Rails (2004/2005). Antes disso ninguém ouvia falar de Ruby. Mesmo assim, Rails trouxe uma ascensão meteórica para o Ruby, surgindo um ecosistema incrível, com uma série de produtos bem sucedidos e documentações fantasticas, screencasts, entre outros. Destacou-se muito com as ferramentas de testes automatizados que tanto precisamos hoje em dia para desenvolvermos software com qualidade.

No time onde eu trabalho na globo.com, desenvolvemos projetos em Java, em Python/Django e Ruby on Rails (projeto atual). Cada uma das escolhas teve razões lógicas e seus benefícios (que se comprovaram). Essa versatilidade faz com que esse time possa trabalhar em praticamente qualquer projeto da empresa, já que tem conhecimento nas principais linguagens que a empresa trabalha. Isso é muito mais benéfico do que ficar preso a uma tecnologia, defendendo-a com unhas e dentes.

O Mito do não escala

Com o advento dessas linguagens dinâmicas, deu bem pra perceber como a maioria dos profissionais não entendia/não entende quase nada sobre escalabilidade de sistemas web. Assim como o COBOLEIRO falava que o Java não aguentava o tranco, começaram a falar que linguagens dinâmicas não escalavam, principalmente o famoso “Rails não escala”.

Certa vez eu lí um post de 2004 (antes do Rails) que já falava sobre esse mito de não escala. Vale a pena conferir aqui. E tem também um screencast mais recente(baixe o vídeo e assista) do Gregg Pollack que nos primeiros minutos mostra na maioria das vezes o que deixa um site lento. Dica: tem pouco a ver com a tecnologia usada.

Portanto, não caia nessa. Pesquise e aprenda como escalar sua aplicação, independente de você estar usando Python/Django Ruby/Rails, Java, DotNET ou qualquer outra tenologia do seu projeto.

Conclusão

Mesmo com essas 2 tecnologias (Ruby e Python) fazendo seu sucesso nos dias de hoje e tendo seu contexto para serem aplicadas, o pessoal ainda continua brigando pra defender a sua tecnologia preferida. Parece que cria-se uma paixão cega pela linguagem, como se fosse uma espécie de religião, saindo do racional e passando a ser totalmente irracional.

Dessa forma, meu conselho para todos os profissionais é que não entrem nessa de ficar defendendo sua tecnologia preferida e atirando pedra na tecnologia concorrente. Aprenda ambas e saiba onde e quando usar cada uma delas.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Como já mencionei em outros posts nesse mesmo blog, nossa área de desenvolvimento de software/informática está cheia de termos/nomenclatura que se confundem facilmente (e.g. as discussões no GUJ sobre DTO). Mais uma vez, falarei sobre um deles: a classificação júnior, pleno, sênior.

Dando uma passeada pelos sites de emprego de informática, é fácil ver vagas para analista de sistemas / programador / desenvolvedor júnior, pleno e sênior, etc. Acontece que a maioria das pessoas (inclusive os gerêntes de TI) não sabem muito bem fazer essa distinção entre os níveis, causando uma grande confusão na cabeça de todo mundo, inclusive na hora de negociar o cascalho. Portanto, vamos começar pelo básico …

Não sou uma pessoa entendida de RH, muito menos sei a história sobre como começou essa nomenclatura de júnior, pleno e sênior. Mas como trabalho na área de TI faz 12 anos e já passei por um bocado de empresas, acho que posso dar meu pitaco sobre o assunto. As melhores definições que consegui na internet para sênior foram: ancião, velho, pessoa com mais experiência em alguma profissão. De cara tem alguma coisa estranha na resposta que o tal gerente deu pro meu amigo, mas não para por ai.

No início da minha carreira, nas empresas onde passei, geralmente o cara sênior era um cara com mais experiência, uma pessoa que viveu mais situações, uma pessoa mais madura (não necessáriamente velha ou idosa). Por muitas vezes, essa pessoa não conhecia uma ferramenta ou outra de trabalho que eu conhecia, mas isso de maneira alguma me colocava no mesmo nível daquele profissional, pois tomando conhecimento da existência daquela ferramenta e utilizando um pouco do seu tempo, a tal ferramenta estava absorvida por este.

E o que eu quero dizer com isso? Eu quero dizer que se você começou agora, mesmo que você saiba python, ruby, java, erlang, haskell, xpto, brainfuck, você é Júnior ainda. Lógico que é ótimo saber diversas ferramentas e eu recomendo a todos estudar para isso. O mesmo princípio se aplica ao profissional sênior. Fatalmente tem algumas coisas que lhe fogem ao conhecimento, porém a diferência é que esse naturalmente conhece muitas ferramentas  devido a sua experiência ao longo dos anos. Não foi simplesmente um livro que leu ou um tutorial da internet que fez, mas projetos reais que participou. Um sênior deve saber debater com seus superiores sem medo, com argumentações bem formuladas, sabendo exatamente a sua posição, mas sem muito se intimidar quando conversa com outro profissional acima na hierarquia. Deve chamar a responsabilidade para si em momentos críticos, deve ajudar e ensinar os demais simplesmente porque isso é de sua responsabilidade.

Saber ou não uma determinada linguagem ou ferramenta não faz necessáriamente de você nem júnior nem sênior, pois isso as vezes depende da sua trajetória de carreira. Eu por exemplo não sei nada de ABAP, pois nunca trabalhei com SAP ou algo que use essa linguagem. Talvez você esteja aprendendo Java nesse momento mas tem 10 anos de experiência com C/C++ e tem ótimas práticas de programação. Em fim, é bem relativo.

Pra finalizar, certa vez um amigo me disse que sênioridade é algo como um estado de espírito. Vou até um pouco além disso. Acredito que sêrionidade é um estado avançado de profissionalismo aliado a maturidade alcançada ao longo do tempo.

Disclaimer:

Para que não pareça que defendo regime de quartel, quero deixar bem claro que hoje em dia de nada adianta você ser maduro e experiente se você é um profissional encostado e desatualizado. E o talento, é claro, sempre fala mais alto.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.