Uma coisa que ouço sempre na comunidade Java (falo dessa pois é a que conheço melhor) são os brados de “não reinventar a roda”. Cada vez que alguém aparece com um problema e fala de uma solução que algum projeto já resolve, desincentivam o programador completamente, falando que não vale a pena resolver novamente o problema já resolvido.

Eu não tenho como discordar mais de uma afirmação como essa.

A maior parte do tempo que dedico ao desenvolvimento fora do trabalho eu estou reinventando rodas. O Mirror é um exemplo disso. Dá pra fazer quase tudo que ele faz usando a API de reflection nativa do Java, mas é muito mais trabalhoso. Se eu não decido que reinventar a roda era uma coisa boa, eu não teria uma forma melhor de trabalhar com reflection. Além de que meu conhecimento sobre reflection não seria um décimo do que é hoje.

Além disso, tem um problema maior. Quando você usa uma camada de abstração, você ignora o que está acontecendo por baixo dos panos. Muitas vezes isso é bem importante, mas é bem perigoso também porque abstrações vazam. Em algum momento você terá que lidar com a infraestrutura que está embaixo da abstração e nesse momento, conhecer como a roda foi criada é fundamental.

Então, ao contrário do que a maioria diz, eu reinvento a roda sempre que posso. Depois que está funcionando e tem uma boa cobertura de testes, se for melhor (na minha opnião) do que existe no mercado eu extraio e lanço opensource. Caso contrário, migro meu código para uma das soluções existentes. Gastei mais tempo? Não. Fiz um investimento em mim (e provavelmente na minha equipe). Me tornei mais capacitado para resolver esse e vários outros problemas.

Mas é bom lembrar que você não vai poder fazer isso sempre (afinal, não se vive apenas de investimentos). Sem contar que reinventar a mesma roda sempre é bobagem (você vai aprender muito menos do que reinventando uma roda nova).

Posts Relacionados:

Os Homens-Bomba do Software Livre

Mac Widgets

FISL 10: Seaside versus Rails

Google Analytics de cara nova

Linguagens de programação

INC - Pequeno + Pequeno == Grande?

Mitos do Linux derrubados

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

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.

Um geek, por definição, é alguém que gosta de aprender coisas novas sempre: novas tecnologias, como as coisas funcionam, por aí vai. E qual o melhor jeito de aprender? Com um professor ou mentor, alguém para te explicar os comos e os porquês. Mas nem sempre esse mentor tem esse papel explicitamente. No dia-a-dia, no trabalho, na faculdade ou até mesmo em casa, sempre tem alguém que sabe alguma coisa melhor que você e pode te ensiná-la, e é preciso humildade para reconhecer isso.

O verdadeiro geek, aquele que realmente gosta de aprender, está pronto para aprender a qualquer hora com qualquer um. Ele reconhece quando alguém tem algo para lhe ensinar e vê com felicidade uma oportunidade assim. Fica feliz quando alguém o corrige, porque assim ele está aprendendo. O verdadeiro geek é humilde para ver todas as pessoas como possíveis professores de alguma coisa.

Posts Relacionados:

YACP - Condições Booleanas

Oito (ou dez) coisas que todo geek precisa pra produzir mais

TRUE & TRUE == FALSE ?

Nova Coluna Semanal: Geek Style of Life

VidaGeek.net Agora No Twitter

YubNub

Fazendo fontes com carros

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

Desde o começo de agosto, o vidageek conta com cobertura internacional! Isso mesmo, eu (o Fabs) me mudei para França, e  nos próximos 6 meses pretendo escrever uma série de artigos sobre a vida de um geek aqui pela Europa. Por hora, vou falar um pouco das minhas dificuldades tecnológicas, mas você pode ver mais sobre o meu dia a dia, arte, cultura e etc no meu blog pessoal. Tem um monte de fotos no picasa também.

Bom, por hora separei algumas historias.

Comprando um Ordinateur Portable (Notebook):

Três dias depois que cheguei em Paris, meu mac apresentou um problema na NVIDIA (clássico). Procurar uma assitência técnica foi um pouco complicado, e como também queria um eeepc para viajar, no meio do caminho decidi atrasar o concerto do mac e comprar um netbook.

Eu já fui do tipo de defensor do software livre que ficava indignado com aqueles pcs com um linux qualquer coisa que são vendidos no Extra. Depois por um tempo, escolhi ter menos dor de cabeça com computadores e comprei um mac. Pois bem, queria voltar ao mundo Linux, mas o primeiro problema que encontrei foi, diferente do Brasil em que vc ainda pode escolher entre windows e linux mal instalado, aqui, tudo vem com windows.

Segundo problema, pode esquecer o teclado QWERTY q vc está acostumado. Aqui é tudo AZERTY (Fica mais fácil de escrever a palavra fAZER :-). O máximo que consegui foi uns adesivos para colar em cima e ter o layout de teclado que eu uso. Quase dei um pulo em Londres para ver o DtSato e comprar lá.

Linux 9.04 “ne marche pas” (não funciona)

Dois dias depois de comprar meu eeepc 1101HA, ainda estava apanhando das configurações. Atualmente, ele roda Ubuntu 9.10 alpha (para funcionar todos os drivers), quando instalei o netbook-remix 9.04 não o kernel não suportava nem a wireless nem a ethernet.

Escrevendo nos Parques

Estou escrevendo esse artigo do meio do Jardim das Plantas. É incrível como existem lugares aqui para sentar, ler um livro, fazer pique-nique e bater papo. Faz muito sol em Paris, mas é muito legal ter essas sombras. A vantagem? Você pode usar seu notebook neles sem medo. Já vi até umas pessoas andando por ai de computador na mão, no meio da rua, numa boa.

Telefone Móveis

Não tive problema com isso, meu orientador me deu um chip e meu N95 já funcionava quando coloquei os pés no aeroporto. Mas fui comprar celular com a minha amiga e me expantei com o quanto é barato. Por 30-35 euros por mês, há 3G, televisão, gps, ligações ilimitadas para um conjunto de 2-3 celulares e cerca de 3h de ligação por mês. O Serviço 3G é excelente em Paris.

Wifi pela cidade

Qualquer lugar que eu paro na cidade tem Wireless (umas 30 redes). Os provedores de tv a cabo e internet oferecem esse serviço por assinante. A Free, operadora que minha amiga assina, tem uma tal de FreeWifi na cidade toda. Você habilita o seu roteador de casa a servir rede nos arredores de onde você mora, e recebe uma senha para poder usar pela cidade toda, uma ótima forma de colaborar.

Bom, por hoje só essas coisinhas do cotidiano. Em breve devo ir ao Dojo aqui em Paris e outras atividades para contar mais para vocês.

Se tiverem alguma dúvida sobre como algo funciona por aqui, é só deixar nos comentários. Abraços.

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.