Tag: ruby on rails

Resolvendo problema de zlib na instalação do Rails com RVM

Tentando instalar o rails utilizando o comando “gem install rails –pre” recebia sempre o erro:

ERROR:  Loading command: install (LoadError)
no such file to load — zlib
ERROR:  While executing gem … (NameError)
uninitialized constant Gem::Commands::InstallCommand

Para solucioná-lo, basta seguir as seguintes etapas:

rvm package install zlib
rvm remove 1.8.7 (no caso, a versão do seu Rails)
rvm install 1.8.7 (sim, a mesma que fora removida)

Pronto, agora ele será recompilado com a zlib.

Simples!

Anúncios

Mongrel no lugar de Webrick

Vou ser bem direto: Webrick não é uma opção para servidor Ruby on Rails. Nem para testes.

Recentemente trabalhei no desenvolvimento de um sistema de indicações de oportunidades de negócios. O sistema era bem simples, e o desenvolvimento só não foi mais rápido pois foi o primeiro projeto adotado a ser desenvolvido em Ruby on Rails pela empresa. Como já citei num artigo anterior, “as primeiras semanas foram doloridas. Pensar tudo de trás para frente, uma nova linguagem, e tudo o mais que uma migração assim nos permite sofrer, pode ser um pouco dolorido, mas vale a pena.”

Uma das coisas que passei mais sufoco foi, com certeza, a dificuldade de configurar um servidor de entrega. Diversos fatores entraram em questão, a própria decisão de qual máquina seria escolhida, a criação da máquina virtual (já haviam outras máquinas virtuais instaladas) e outras particularidades que não dizem respeito ao RoR.

Se tratava de um servidor simples, que seria utilizado apenas para mostrar aos clientes o sistema funcionando e permitir que eles pudessem “brincar” um pouco com o sistema. Pensei logo: “ora, já usamos o Webrick para testes locais, logo não encontraremos problemas.” Mas não foi bem assim.

Rodar o Webrick localmente pode fazer tudo o que você pretende, mas tente rodar de um IP remoto. Pensando bem, tente rodar utilizando seu póprio IP da rede (não vale 127.0.0.1). No caso do nosso sistema, o carregamento de uma página simples de login durava cerca de 3 min. Quando entrava, enfim, no sistema, além da demora, alguns elementos (imagens) não eram carregadas. O Webrick era a grande dor de cabeça.

Parece besteira de iniciante. E realmente era, mas naquele momento eu simplesmente não poderia ter perdido tanto tempo com isso.

A segunda tentativa que nos parecia óbvia foi instalar o Passenger: um mod_rails para o Apache que supostamente seria a opção mais viável. A instalação não foi tão diferente quanto qualquer mod para Apache, e suas configurações. O problema foi a inconstância do pacote e das gems. Primeiro que é quase impossível desinstalar a gem. Quando assim o fiz, simplesmente a gem continuava lá na “gem list”, mesmo desinstalada. Depois de formatarmos a máquina virtual e instalarmos tudo do zero novamente, funcionou perfeitamente. Nos demos por satisfeitos.

No dia seguinte, sem maior explicação ou alguém ter sequer acesso ao servidor, o passenger não funciona mais. E isso já era véspera da entrega do sistema. Algo assim não poderia falhar. Não era uma opção.

A essa altura, depois de muitas tentativas de correção, já havíamos desistido de entregar através do servidor de testes. Continuamos o desenvolvimento do sistema, pois alguns tópicos precisavam ser finalizados.

Dia seguinte, dia de entrega. Lendo alguns artigos em blogs que tratavam de Rails, me veio a possibilidade de testar o Mongrel. Fui meio sem esperança, pensando se tratar de algo “como o Webrick”, que serviria apenas para testes locais. A instalação é bastante simples, não passando de um “gem install mongrel”. Para rodar, bastava digitar “mongrel_rails start”. Nenhuma configuração foi necessária, nenhuma palha foi mexida, nada mais foi feito. Simplesmente duas linhas e lá estava meu servidor de testes funcionando e rodando a aplicação perfeitamente.

Em 2 min concluí uma operação que me custou cerca de 20 horas sem sucesso. Mais tarde, ao me aprofundar e ler casos de uso, descobri que o mesmo servidor Mongrel é o servidor Rails utilizado pelo Twitter. Sem sombra de dúvidas, poderia ser facilmente utilizado no servidor final, de produção.

CodeIgniter + Ruby on Rails + Django

Gostaria de fazer um breve comparativo entre esses três frameworks, pois julgo terem bastante semelhanças e trabalham de forma parecida.

Confesso que o título original desse artigo era “CodeIgniter x Ruby on Rails x Django“, mas por que ser ‘versus’ se pode ser ‘mais’?

Não vou ser determinista nem tampouco taxativo, mas poderia resumir uma possível dúvida quanto à escolha do melhor na seguinte frase: “Escolha sua linguagem e pegue seu Framework“. Diria que é mais um relato de utilização do que propriamente um comparativo de funcionalidades.

CodeIgniter

Trabalhei com CodeIgniter no desenvolvimento do site Portal da Classe Contábil, projeto iniciado pela Fortes Informática e hoje um dos maiores portais de contabilidade do país. Já tínhamos uma equipe que trabalhava com PHP e outra que trabalha com Java, sendo que a de PHP nunca havia experimentado um framework antes.

A curva de aprendizado foi realmente muito curta, apesar de não termos utilizado todos os plugins e bibliotecas que ele oferecia (muita coisa tivemos que fazer na mão, devido a complexidade do portal). Os conceitos de MVC são muito bem aplicados e nos permitiu ter um ritmo de desenvolvimento realmente ágil. Como entrei no projeto inicialmente como webdesign, a separação do ambiente das “views” foi essencial para o sucesso da equipe.

Ruby on Rails

Recentemente recebemos uma demanda muito grande no desenvolvimento de sistemas para web e, como já vínhamos adotando XP e metodologias ágeis na empresa, buscamos alguma ferramenta que pudéssemos ser mais produtivos e realizar testes e iterações mais eficientes.

Foi determinado então que a ferramenta utilizada seria o Ruby on Rails. Por quê? Porque foi um framework realmente pensado e elaborado para ser utilizado por quem utiliza metodologias ágeis.

Sob a consultoria de Christiano Milfont, tivemos o prazo de 2 meses para desenvolver um sistema interno de indicações de prospectos. Confesso que as primeiras semanas foram doloridas. Pensar tudo de trás para frente, uma nova linguagem, e tudo o mais que uma migração assim nos permite sofrer, pode ser um pouco dolorido, mas vale a pena.

Não diria que virei fã incondicional de Ruby on Rails, mas com certeza diria que é um framework excelente e bastante produtivo. Creio que o domínio da ferramenta e um interesse por aprender uma nova linguagem possam fazer do profissional um cara extremamente produtivo.

Django

Meu coração até bate forte ao falar de Python (sem maldade, por favor). Não entendo por que essa linguagem não é utilizada por todos. Mas, quer saber? Não estou nem aí. Desde que eu a utilize e consiga fazer tudo muito rápido e com o código altamente organizado e simples, eu não me importo com o que os outros achem.

Django é um framework altamente pythônico. Pythônico no que se diz a “programe pouco que eu faço tudo”. Realmente é incrível como ele trata com simplicidade tarefas corriqueiras. E não engessa tanto. Talvez essa seja uma de suas principais qualidades: você pode usar o framework, mas se não quiser, não use!

Suas pastas são todas organizadas da mesma forma que classes do Python e tem um plugin fantástico, onde toda a administração é gerada automaticamente. Não se preocupe com (quase) nada do backend… o Django faz (quase) tudo para você.

Python é minha escolha para projetos pessoais e pretendo com um tempo utilizar profissionalmente. Me espanta as empresas e os próprios programadores não darem valor a uma linguagem tão produtiva e organizada. Talvez por ser fácil demais, e eles não acreditarem que possa ser uma linguagem realmente poderoza, ou talvez por modismo mesmo (as que estão em voga ainda são Java e Ruby).

Conclusão

Acho que deu para perceber qual seria a minha escolha, mas se você for escolher um desses frameworks, pensem primeiro que linguagem você gostaria de utilizar, então estude o framework correspondente.

… mas não descarte os outros. Hoje em dia programador nenhum pode se dar ao luxo de se prender a uma só linguagem.

Novo tempo Geek

Ainda tenho um certo pé atrás sobre utilizar frameworks. Quanto à facilidade de criação do básico e desenvolvimento de ferramentas simples, em geral, são ferramentas de extrema necessidade e indispensáveis, mas quando o “bicho pega”, sempre tem-se um trabalho tremendo.

Dou como exemplo algumas customizações de layout que tenho necessidade de executar em sistemas no trabalho. O que percebo é que “facilidade de mais”, como auto-criação de forms e tudo o mais acaba “engessando” o layout e tornando difícil uma customização do layout.

Não desacredito em frameworks, e até afirmo que tal dificuldade parte talvez pelo fato de não conhecer o framework a fundo, mas fica aí o comentário.

Dos diversos frameworks que tenho estudado e utilizado (CodeIgniter em PHP, Ruby on Rails em Ruby e Django em Python), o que recomendo é o Django, tanto pela sua facilidade de criação de elementos básicos, como sua sintaxe muito mais organizada e seguindo os preceitos “pythonicos”. Beleza no código é fundamental, e nesse quesito a comunidade Python é primoroza.

Por causa dessa necessidade que estou encontrando de falar de coisas mais Geeks, estou cogitando uma migração do Blog, na verdade seria a criação de um mais voltado à tecnologia.~

Não sei ainda se darei continuidade a esse, sendo que mudando o foco (e layout) ou começo outro do zero. Por enquanto, vai por aqui mesmo.