Archive for the ‘Programacao’ Category
I18n para Java
Author: Jonas Abreu24 Feb
Quando eu comecei a trabalhar na Adaptworks em setembro do ano passado, estou em um projeto onde temos muito espaço para experimentação e criação de melhorias.
Uma dessas melhorias é uma forma diferente de se trabalhar com internacionalização em Java.
Em geral, usamos uma taglib para fazer isso (como a JSTL/fmt). Mas eu realmente não gosto muito de sintaxes como:
<input type="submit" value="<fmt:message key="project.submit.button" />">
Fica bem ruim de ler. Eu lembrava de ter ouvido que era possível estender a Expression Language do JSP, mas nunca tinha dado muita bola pra isso.
Enfim, depois de apanhar um pouco chegamos a uma solução interessante para o mesmo código:
<input type="submit" value="${i18n.project.submit.button}">
Não sei quanto a vocês, mas acho bem mais legível.
O projeto está em http://projetos.vidageek.net/i18n
Feedback é sempre bem vindo.
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Um caso de ódio e talvez um pouco de amor (Também conhecido como automatizadores de build)
Author: Jonas Abreu17 Jan
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:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Dojo de Carro
Author: fabs15 Oct
Tem mais ou menos 1 mês, aproveitei o tempo livre das férias antes das aulas para passear em Amsterdã. Passei antes é claro em Bruxelas para encontrar com Leandro Lameiro, um amigo Politécnico que tive a oportunidade de conhecer nas sessões do coding-dojo de São Paulo (para quem não sabe o que é um dojo, vale a pena dar uma olhada nesse artigo do vidageek sobre o dojo no fisl 9.0).
No caminho (Bruxelas - Amsterdã) estávamos discutindo como escrever um algoritmo para GPS que levasse em consideração a velocidade média de tráfego em cada trecho. Estávamos querendo dessa forma, que o GPS nos desviasse das estradas congestionadas, já que na Bélgica (e na França também) o GPS conhecia os acidentes e engarrafamentos no caminho.
A idéia era que os papéis de piloto e copiloto do dojo, trocassem entre os papéis de piloto e copiloto do carro :-), mas não deu muito certo já que eu não dirijo, e que o tempo de 7 minutos parece ser bem pequeno.
Sempre gostei da idéia de misturar atividades, nos antigos uber-dojos (atuais kakes), onde tínhamos vários grupos programando ao mesmo tempo, diferentes problemas em diferentes linguagens, as pessoas de fora faziam comida.
Alguém tem alguma boa idéia de como misturar dojos com outras atividades?
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Auto refresh no eclipse
Author: Jonas Abreu12 Oct
Depois que eu passei a trabalhar com git, o eclipse começou a me torrar muito a paciência. Toda vez que eu mudava de branch ele perguntava se eu queria atualizar os arquivos abertos. E depois eu tinha que atualizar o projeto para tudo voltar a funcionar.
Depois de quase me conformar, vi um tweet do Miško Hevery (http://twitter.com/mhevery/statuses/3439314089) com exatamente a solução para o problema.
Você só precisa ir em Preferences -> General -> Workspace e marcar refresh automatically. Essa foi umas das descobertas que mais melhorou meu humor nos últimos tempos.
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
