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.

É fato que nos dias de hoje muitas tecnologias novas surgiram no cenário mundial. Temos sido inundados por celulares, smartphones, notebooks, netbooks e outros mais. Hoje em dia existe internet 3G nas principais grandes cidades do mundo. Internet WIFI já é algo comum faz tempo. Esses recursos estão começando a mudar nossas vidas de uma forma surpreendente. Mas será que essa idéia é nova? Quando será que começaram as pesquisas sobre essas tecnologias? Qual será o impacto futuro em nossas vidas? Acredito que estamos realmente num caminho onde a computação fará parte de quase todos os objetos que usamos no dia a dia.

Definição

Ubíquo não é uma palavra muito usada em nosso cotidiano. Portanto, vale a pena apresentarmos alguns significados para nos ajudar a aprofundar mais no assunto.

Ubíquo significa algo universal, ou seja, algo que todos entendem, conhecem. Ubíquo também pode ser interpretado como aquilo que esta presente em todos os lugares, ao mesmo tempo. É como onipresença. Essa segunda definição tem mais a ver com o conteúdo desse artigo.

História

Em 1991, Mark Weiser escreveu um artigo chamado “O Computador do Século 21 (The Computer for the 21st Century). Weiser era cientista chefe do Centro de Pesquisa Xerox PARC. Nesse artigo, ele definiu o termo Computação Ubíqua, que define um contexto onde a presença computacional em algum objeto é totalmente transparente para quem usa e em alguns cenários totalmente invisível. Weiser também exemplifica a escrita, que foi provavelmente a primeira tecnologia de informação e que se tornou Ubíqua em países industrializados. Ele usa esse exemplo para definir que as tecnologias que são mais profundas são as aquelas que “desaparecem”. Por desaparecer, acho que Weiser quis dizer que a tecnologia fica tão arraigada no nosso dia a dia tornando seu uso automático, deixando de ser aquele algo novo e surpreendente. Vislumbrando como seria a computação do nosso século, Weiser também fala sobre redes gigabits, armazenamento de terabytes e sobre Tabs e Pads, que seriam os palms, smartphones, Kindles e iPads que temos hoje. Quase no fim do artigo, ele conta uma estória ilustrativa de uma pessoa vivendo nesse mundo todo conectado e apresenta diversos protótipos feitos por ele e sua equipe de alguns desses equipamentos e tecnologias.

No que diz respeito a tecnologias, lembro-me bem que Java era uma dessas que originalmente foi criada para ser usada em dispositivos embarcados, especialmente na informatização da casa, mas era algo muito avançado para época. Isso surgiu no mesmo ano em que Weiser escreveu seu artigo. No fim das contas a linguagem Java tomou outro rumo, muito bem sucedido por sinal.

Contexto atual e futuro

É impossível negar que a computação Ubíqua tem afetado nosso dia a dia. Hoje temos Hotspots WIFI em diversos lugares. A internet 3G está presente nos celulares modernos, possibilitando infinitas formas de comunicação. Serviços de Voz sobre IP tornaram possível usarmos ferramentas como Skype, que permite obter um número de um País e utilizar em qualquer lugar do mundo. Cada vez mais fazem parte do nosso dia a dia tecnologias como as de automóveis com computador de bordo, iPhones, iPads, totem para compra de ingressos no cinema, totem para check-in de voos, e outros mais.

Outra tecnologia que está acelerando o processo da computação Ubíqua é o Cloud Computing. Há alguns anos, milhares de pessoas tem suas contas de email online em serviços como gmail, yahoo mail e similares, de forma a não precisarem mais de um cliente de email como ferramenta obrigatória em seus computadores. Essa modalidade é conhecida como SaaS (Software as a Service). Outra modalidade é o IaaS (Infrastructure as a Service), onde existe uma infraestrutura transparente para quem contrata servidores, podendo adicionar mais recursos computacionais ao invés de mais um computador ou hardware físico. Mais recentemente surgiram também plataformas para desenvolvimento de software totalmente na web como o Google App Engine, Heroku e outros. Esse é o modelo PaaS (Platform as a Service).

Hoje em dia fala-se muito também em casas inteligentes, um conceito onde toda a casa está interligada e conectada, permitindo que luzes acendam com comando de voz, geladeiras enviem pedidos de compras ao supermercado quando estiverem perto de esvaziar, cafeteiras saberem o horário do seu café da manhã e prepararem o café sem você precisar fazer nada, e por ai vai. Esse conceito está ligado a Computação Pervasiva, que é uma espécie de subárea da Computação Ubíqua. Quem assistiu o filme “O Demolidor” (1993), com os atores Silvestre Stalone e Welsey Snipes, lembra que esses conceitos estão presentes no filme. Embora atualmente existam algumas iniciativas de empresas nesse ramo de Computação Pervasiva, essa tecnologia ainda está bem distante de uma adoção em massa.

Falando de futuro, é bem verdade que ainda não chegamos no nível onde Weiser aponta em seu artigo, mas afinal, ainda estamos no início do século, tendo passado apenas uma década. Uma das frases ditas por ele nesse artigo que chamou muito a atenção sobre esse futuro foi: “Não precisamos de nenhuma revolução na inteligência artificial, apenas incorporar a computação no cotidiano”.

Conclusão

O Caminho para Computação Ubíqua tem avançado muito nos últimos anos. As pesquisas e previsões de Mark Weiser tem se concretizado, quase que como uma profecia. Como profissionais de TI, nos resta estar atentos as oportunidades de negócio que essas tecnologias tem a nos oferecer e tirar proveito disso.

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

Vou fazer um resumo das palestras que assisti.

Chad Fowler – http://chadfowler.com

A palestra do Chad foi como sempre focada em carrreia. Ele advertiu os desenvolvedores que produzem porcaria todo dia sem peso algum na consciência. Ele pensa (e eu também) que nós não devemos investir tempo desnvolvendo coisas que já sabemos que são porcaria. E isso não é pessimismo, simplesmente é não perder tempo.

Chad falou também sobre os FUDs que sempre usam contra Ruby/Rails. Isso não foi nenhuma novidade mas ele abordou de forma bem divertida e valeu muto a pena.

Uma das partes mais legais foi a estatística mostrando que Ruby só faz parte de 6% da requisição do usuário. Na verdade não só ruby, mas outra tecnologia também. Isso bom para refletirmos sobre as discussões sobre performance e escalabilidade das aplicações web.

Gregg Pollack – http://envlabs.com

O foco da palestra do gregg foi sobre como atacar alguns pontos para o otimizar sua aplicação Rails. Dentre as formas, ele apresentou algumas gems/plugins que ajudam a identificar alguns pontos para melhoria de performance em uma aplicação. Vou destacar algumas:

• Bullet – Ajuda a identificar queries com alguns problemas. Ex: N + 1
• Rails Indexes – Identifica colunas onde deveriam ter índices. Se baseia nas buscas do sistema.
• Scrooge – Faz com que o ActiveRecord passe a buscar somente os campos que estão sendo usados, ao invés de buscar todos os campos. Ex: em um find(:all), após a primeira execução, o scrooge identifica quais campos foram usados e ná próxima vez modifica a query para não buscar os campos desnecessários.
• Rack Bug – É uma Monitor para aplicações Rack. Fornece basicamente todas as informações. Sessões, CPU, Memória, etc. Bem útil
• oink – Mostra detalhes dos requests de cada controller. Ex: consumo de memória.
• Cloud Crowd – Servidor para rodar tarefas em background. Feito em sinatra.

Ilya Grigorik – http://www.igvita.com/about/

Ilya falou sobre integração/comunicação de aplicações baseadas em web, utilizando-se de tecnologias como XMPP, AMQP, Webhooks, PubsubHubbub. Foi bem interessante, pois a maioria do auditório conhecia pouco sobre o assunto.

Fabio Akita – http://akitaonrails.com

A palestra do akita foi sobre agile. Ele falou bastante sobre a teoria do caos, sistemas complexos e a evolução das coisas. No fim, o recado maior foi alertar que agile não é o último estágio no desenvolvimento de software, deixando claro que temos (e vamos) que evoluir ainda mais.

Glenn Vanderburg – http://blog.thinkrelevance.com

Palestra sobre o framework Tarantula, que tem por objetivo fazer testes de ataques XSS, SQL Injection, entre outros. Achei bem interessante, pois é possível automatizar esse passo, que geralmente fazemos manualmente. Glenn inclusive sugeriu que faça parte do build antes de lançar um release.

Fabio Kung – http://fabiokung.com/

Fabio fez uma ótima palestra sobre DSLs (Domain Specific Languages) internas usando Ruby. Ao invés de apresentar exemplos simples ele apresentou um exemplo real de uma necessidade de uma aplicação que trata de instâncias de máquinas na cloud da Locaweb.

Carlos Vilella http://lixo.org

Carlos fez uma palestra bem curta, falando sobre o uso de Ruby na Thoughtworks. Falou sobre os poucos projetos que falharam e deixou o restante do tempo para perguntas.

Tapajós – http://tapajos.me/

A palestra do Tapajós foi sobre bancos de dados não relacionais. Focado bastante em CouchDB e Rails, ele explorou algumas features chaves na utilização dessa abordagem de banco de dados, também fazendo uma curta palestra e deixando boa parte do tempo para perguntas.

Bruno Miranda – Rails não escala

Eu gostei muto da palestra do Bruno, apesar de achar que o que ele falou é básico para qualquer Arquiteto de Software experiente.  Bruno falou bastante sobre filas, sharding, Cache, Proxy reverso, otimização de queries e sobre rodar processos em background. Acho que a palestra dele foi válida pois qualquer um hoje em dia que aprende tecnologias como Rails sai fazendo aplicações sem um conhecimento mínimo de arquitetura de software. Quando as coisas não dão certo culpam a tecnologia, gerando FUDs.

Vinicius Teles (http://improveit.com.br/) – Empreendorismo

A palestra do Vinícius foi ótima para quem pretende desenvolver um produto e/ou abrir seu próprio negócio. Ele abordou pontos como Fluxo de Caixa, oportunidades vastas que existem no Brasil e o impacto de pequenas decisões certas ou erradas que tomamos na nossa vida profissional.

Obie Fernandes – http://obiefernandez.com/

A palestra do Obie encerrou o evento em grande estilo, falando sobre talento, esforço e reforçando bem o que eu disse há um tempo atrás nesse blog. Não adianta você saber um monte de coisas se não souber bem, se não tiver experiência com isso, treino, treino e mais treino. Você só ganha nível com tempo e treino, isso é fato.

Pra finalizar, gostaria de parabenizar ao Fabio Akita e a Locaweb pelo excelente evento mais uma vez.

E ano que vem tem mais.

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

Sobre a melhoria contínua, vou focar aqui nos aspectos (1) errar e (2) compromisso com a mudança.

Errar

O erro sempre foi um tabu nas empresas. Errar sempre foi considerado sinônimo de fraqueza ou incapacidade. No modelo que estavamos acostumado a trabalhar, erros geralmente eram punidos com severas advertências, demissões e/ou humilhações. No modelo em que estamos tentando trabalhar, os erros devem ser vistos como oportunidade para crescermos e melhorarmos como indivíduo e como profissional. Dessa forma, errar faz parte do processo, já que inevitavelmente erraremos algumas vezes ao longo da jornada.

Compromisso com a mudança

Quando pensamos em compromisso com a mudança no nível da empresa, talvez seja mais fácil, mas quando pensamos para o nível pessoal, complica um pouco. Mudar manias, paradigmas pessoais e outras coisas mais, geralmente é um processo bemmmm complicado. Porém, essa é a oportunidade que temos para aplicar na prática o que aprendemos com os nossos erros.

O compromisso em melhorar é fundamental para que haja resultados práticos. Errar e não melhorar, repetindo os mesmos erros, faz com que de nada tenha servido a oportunidade de reflexão.

Nosso papel quando os outros erram

Quando um colega seu errar, ajude. Criticar, humilhar, querer ver o mau dessa pessoa, de nada ajudará. Isso só fará com que você esteja piorando como profissional e como pessoa. Se for possível, ajude, se não for, torça para que essa pessoa consiga usar seu erro como uma oportunidade de melhoria. E não se esqueça: você também erra e vai continuar errando.

Testemunho pessoal

Recentemente, tive a infelicidade de cometer um erro. Foi um pequeno erro, mas que aconteceu e então isso me entristeceu bastante. No momento em que percebi essa falha, tratei de resolver o que precisava ser resolvido de forma mais urgente e deixei a reflexão para o primeiro momento oportuno.

Passado pouquíssimos dias, fiz uma profunda reflexão sobre a falha para que ela não viesse a ocorrer novamente. Dessa forma, além de melhorar como pessoa, acredito ter melhorado como profissional.

Talvez você pense: mas assumir assim um erro? Não tem vergonha disso não?

Digo com toda naturalidade: NÃO!!!

Quem erra é porque está evoluindo, quem erra é porque tenta alguma coisa, quem erra é porque pensa, quem erra é porque raciocina … quem erra, é porque está vivo. A diferença está em aproveitar isso como oportunidade.

Conclusão

Eu erro, você erra. Logo, nós erramos. Portanto, a melhoria contínua começa em nós!!!

Referências:

[1] http://visaoagil.wordpress.com/2009/01/06/melhoria-continua-e-efetiva-atraves-do-hansei-e-kaizen/

[2] http://www.slideshare.net/Comunidade_Lean_Thinking/melhoria-contnua

[3] http://en.wikipedia.org/wiki/5_Whys

[4] http://pt.wikipedia.org/wiki/Kaizen

[5] http://en.wikipedia.org/wiki/Hansei

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