Eu sou um grande fã de automatização de tarefas repetitivas. Odeio ter que repetir tarefas.

Isso me torna um grande fã de coisas como integração contínua, deploy contínuo, testes e automatizadores de builds.

Para IC, o cruisecontrol.rb é maravilhoso. Deploy contínuo eu resolvo com um simples script bash. Quanto aos testes, o infinitest (ainda vou falar mais sobre ele, mas ele é demais!) trouxe alegria de volta a minha vida.

Mas quando chega na parte de automatização de build, o mundo desaba. Como minha maior experiência é com Java, vou falar apenas sobre java.

Convenhamos, os dois automatizadores mais usados são terríveis. Tanto ant quanto maven nos fazem perder mais cabelos e mais cedo do que deveria.

Como a gente começa um projeto que vá usar um desses automatizadores? Pegamos um projeto antigo, copiamos o xml de configuração, colamos, apagamos uma parte, mudamos outra e pronto. Temos um novo projeto. Mas porque raios a gente precisa dessas coisas que foram copiadas? No ant porque o ciclo básico de muitos projetos é igual. No maven porque ele exige muita coisa quase inútil.

Eu já não gosto de xml (na verdade, acho xml muito legal, o problema é que usam ele para tudo - e na maioria das vezes, usam mal) e tenho que manter xmls muito parecidos entre todos os meus projetos. Um problema sério que o ant tem é que tudo tem que ser configurado ou ele não faz nada. Você acaba tendo que programar o seu build em xml (o que pra mim já elimina ele da minha vida).

O maven facilita um pouco nesse lado. Como ele tem um mínimo de convenções, com apenas umas 15 linhas de xml eu consigo convencer ele a compilar meu código. Mas são 15 linhas inúteis. Ele simplesmente não funciona sem essas 15 linhas.

Enquanto você apenas usa o maven para compilar seu código, rodar testes unitários, gerênciar suas dependências (sim, como todo usuário de maven eu passo por um classpath hell -em geral causado por projetos com dependências mal configuradas- por mês, mas ainda acho que vale a pena não precisar adicionar na mão), gerar a configuração para sua IDE, gerar seus jar/war, é tudo lindo e maravilhoso. O problema começa quando o projeto começa a ganhar um pouco mais de massa.

Já tentou configurar um build separado para testes de integração? mvn integration-test é uma das maiores mentiras já contadas. Você tem que se matar com o plugin do surefire (test runner que o maven usa) para conseguir separar os testes. E se você quiser um build separado para testes de aceitação? Pior ainda. Não existe mvn acceptance-test. Então ou você roda junto com o integration-test ou apela para profiles e reduz sua vida em alguns anos. E se eu sonhar com um build que rode testes de regressão para segurança (que não faz sentido rodar a cada commit. Uma vez por dia é o suficiente em muitos projetos). Nesse ponto você começa a pensar em suicídio.

E deploy? Ha! Quando você pensa isso alguém pula de trás do monitor, grita “Pegadinha do Malandro!” e te manda procurar o cargo plugin, que não vi funcionar com menos de 100 linhas de xml (quando funcionou).

Um padrão que eu notei que vem acontecendo comigo é que eu uso sempre três automatizadores. O maven para gerênciar dependências, compilar, rodar testes (mesmo com o inferno dos profiles). Scripts bash/ruby/perl/python/o_que_der_na_telha para deploy. E make para juntar tudo isso. Como? Make? Que o pessoal usa pra C? Esse mesmo. O make é simplesmente um monte de alias para um monte de comandos. Perfeito para juntar coisas completamente aleatórias.

Acabo tendo coisas como make test, integration-test, acceptance-test, deploy, etc. Mas o monte de lixo continua ali, escondido, esperando o próximo classpath hell para se auto-destruir.

Meu principal ponto com o maven é que ele tenta fazer muito mais do que deveria. Na boa? Não tem como escrever um plugin genérico para fazer deploy. Todos os sistemas são muito diferentes um do outro. Então não faça algo que vai funcionar mal e que seja difícil. Deixa para o programador se virar. Apenas facilite isso.

Bom, não escrevi esse monte de coisas apenas como um desabafo (embora tenha me feito muito bem :) ). Eu vou começar a desenvolver um automatizador que tenha uma filosofia diferente os atuais e facilite manter a minha zona organizada. Sem configuração alguma (tirando gerênciamento de dependências que não dá para evitar em qualquer projeto que use testes) ele vai ser capaz de compilar seu código, rodar qualquer tipo de teste (unit, integration, acceptance, etc). Ciclo de vida modificável (se eu não quiser que ele rode os testes unitários antes dos de aceitação, ele simplesmente não roda). O deploy fica a cargo do programador, mas o automatizador facilita a execução dos scripts. Ah, eu disse que não será usado xml algum para configuração?

Enfim, o que preciso nesse momento é de pessoas que estejam afim de contribuir com idéias e críticas (do tipo “não gosto de X porque Y”) pra esse planejamento inicial. Não criei uma lista ainda porque não sei se existem outros interessados (eventualmente sou eu que sou incapaz de usar ant e maven). Por enquanto podemos começar pelos comentários mesmo :)

Posts Relacionados:

Infinitest

VidaGeek.net agora também é Fórum!

Prêmio Turing

FeedBurner e Google

Dia C - Pilha do C

O Iogurte Indutivo

Como migrar de SVN para GIT

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Apenas muito recentemente consegui fazer o Firefox 3.5 do Ubuntu, também conhecido como Shiretoko, funcionar com o plug-in Google Gears. Foram, basicamente, duas bobagens que impediram a instalação e o uso desse plug-in com facilidade.

O primeiro problema é culpa do Ubuntu. O Firefox 3.5 vem rebatizado de Shiretoko no Ubuntu. Isso significa que o navegador não é reconhecido como Firefox pelos servidores. Assim, a página de instalação do Google Gears diz que seu navegador não é suportado. Para contornar isso, é necessário mudar o nome que seu navegador usa para se identificar para o servidor. Você pode mudar isso facilmente: abra seu navegador Shiretoko, acesse a URL “about:config”, confirme que você sabe o que está fazendo (!), filtre a lista por “useragent” e troque “Shiretoko” por “Firefox” no valor da chave “general.useragent.extra.firefox”. Para confirmar que isso deu certo, entre novamente na página do Google Gears. Se o botão de instalação apareceu, ok.

O segundo problema aconteceu porque eu já utilizava o Google Gears no Firefox 3.0. Por algum motivo (não sei se isso acontece sempre), o Google Gears do Firefox 3.0 e o do Firefox 3.5 estavam utilizando a mesma pasta para guardar dados e configurações. Então o Gears do Firefox 3.5 encontrava as configurações do Gears do Firefox 3.0 e isso gerava diversos erros de navegação; redirecionamento sem fim no login do GMail, por exemplo. Infelizmente, a minha solução para esse problema foi apagar a pasta em que ficavam essas configurações: ~/.mozilla

Depois de tudo isso e de baixar todos os meus e-mails do GMail novamente, finalmente funcionou! Se você tiver uma outra solução para o problema, compartilhe!

Montagem tosca por mim mesmo, utilizando os ícones do Firefox 3.0, do Shiretoko e do Google Gears

Posts Relacionados:

Livro grátis de Ubuntu

Ubuntu planeja versão móvel

Compartilhando pastas e arquivos com Ubuntu

Firefox começa a dominar Europa

Firefox na China

YubNub

Ubuntu Ganha o Parlamento Francês

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Agora que além de aprendiz de cientista da computação, eu virei Engenheiro de Informática e Redes em treinamento, tenho aulas de Administração de Sistemas aqui em ESISAR.

Um dos exercícios de Trabalho Prático (Exercício Programa + Professor para quem é do IME) era escrever um script que listasse todos os usuários em /etc/passwd.

Rapidamente me lembrei de “Cadu punhos de aço” e dei minha resposta usando sed, entretanto, o que você vê abaixo é uma versão melhorada e corrigida por Tiago Peczenyj (obrigado thiago):

root@linux# sed -nr ‘/^([^:]+):x:([^0][0-9]{2,}).*$/{s//\2 - \1/;p}’ /etc/passwd

Feliz com a minha resposta, o professor mostrou o mesmo comando com awk:

root@linux# awk -F’:’ ‘{ if ($3 > 100) printf “%s - %s \n”,$3,$1}’ /etc/passwd

(nos comentários existem versões com melhorias :-)

Achei fantástico como awk pode ser mais verboso. Alguém ai conhece um ou outro e pode mostrar umas dicas?

Para quem quer aprender um dos dois, ficam aqui os links:

Sed - Un Introduction Tutorial by Bruce Brannet

Awk - A tutorial

Posts Relacionados:

No related posts

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Uma vez por semestre (pelo menos) eu passo por um problema bizarro quando eu preciso configurar login utilizando chaves de criptografia.

Eu sempre resolvia (depois de quebrar bastante a cabeça) e esquecia qual a solução. Dessa vez, para não esquecer, vou compartilhar com todo mundo aqui :)

O meu problema é simples. O ssh simplesmente ignora minhas chaves. Coloco o nome certo. Adiciono no authorized_keys. E nada do maldito ssh fazer o login sem pedir senha.

A solução a qual sempre chego é simples:

chmod 700 .ssh

Minhas permissões para a pasta .ssh estavam erradas. Isso acontece porque eu crio na mão a pasta muitas vezes (em geral, quando estou configurando uma máquina). Por padrão, quando você usa o mkdir, ele cria a pasta como 744, o que significa que outros usuários podem ler e executar arquivos de dentro daquela pasta.

É aqui que mora o perigo. Chaves publicas realmente não tem problema que sejam lidas, afinal são publicas. O problema é a sua chave privada. Essa não deve estar acessível por razão alguma. Se outras pessoas podem ler sua chave privada, elas podem se passar por você.

Por causa disso, o ssh checa quais são as permissões do diretório .ssh . Se outros usuários puderem ler sua chave, ele considera ela como comprometida e simplesmente a ignora. O problema é que ele ignora de forma completamente silenciosa. Daí você perde os cabelos procurando pelo problema (nem mesmo rodando no modo verboso ele informa sobre isso).

Posts Relacionados:

Trocando chaves rsa rapidamente

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.