Archive for the ‘Software’ 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.
Ambiente aberto de Xadrez Online
Author: convidados23 Nov
O Xadrez Livre é um ambiente aberto de ensino e aprendizagem de xadrez criado para servir como apoio ao projeto de ensino de xadrez nas escolas brasileiras.
Mas não é só ensino e aprendizagem que interessam por lá, há também o Ambiente de Jogo (http://xadrezlivre.c3sl.ufpr.br) , onde os usuários podem jogar contra robôs ou entre si - há uma média de 100 usuários conectados, mas já aconteceram picos com 300 jogadores. São 3 níveis de robôs (fácil, intermediário e difícil) que já completaram 100 mil partidas. O robô difícil, por exemplo, já jogou 21.136 partidas e dessas, ganhou 19.668.
Além disso, o Xadrez Livre é composto ainda por outras duas ferramentas:
- o Módulo de Aprendizagem, que tem como objetivo auxiliar o estudo das regras e aspectos introdutórios do jogo de Xadrez, disponibilizando explicações sobre o jogo e suas regras e exercícios de fixação da aprendizagem;
- e o Gerenciador de Torneios, uma ferramenta para o planejamento e o acompanhamento de competições de Xadrez.
Para os desenvolvedores que quiserem contribuir o código fonte está em http://git.c3sl.ufpr.br/gitweb. O servidor é um componente Jabber baseado em XMPP/Jabber, com interface Javascript e Ajax.
Pra quem quiser entrar em contato com a equipe – formada por bolsistas do Centro de Computação Científica e Software Livre (C3SL) da UFPR – escreva para xadrez-devel em c3sl ponto ufpr ponto br.
Post por Carla Rizzotto.
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Na crista da onda
Author: Luiz27 Jul
Ultimamente tenho trabalhado bastante com tecnologias ainda pouco maduras, por exemplo RESTful WebServices com Java. Isso me fez perceber alguns problemas e algumas vantagens de se trabalhar no comecinho ou na crista da onda da tecnologia. Digo onda porque, se formos fazer um gráfico de como uma tecnologia evolui com o tempo (velocidade de surgimento de novos produtos, ou base de usuários), teremos algo parecido com uma onda: no começo, quase ninguém usa; depois de um tempo, todo mundo usa, e aí surgem novos produtos com uma velocidade absurda; no fim, sobram um monte de sistemas legados e alguns desenvolvedores para dar manutenção neles.
A principal vantagem de se trabalhar com tecnologias de ponta é que essas tecnologias, em geral, corrigem os erros cometidos no desenvolvimento das tecnologias anteriores. Os RESTful WebServices Java, por exemplo, exigem bem menos configurações que os WebServices tradicionais.
Outro ponto bastante positivo é poder colaborar e influenciar bastante no desenvolvimento dessa nova tecnologia. Como a base de usuários ainda é pequena e a tecnologia ainda está amadurecendo, é bem mais fácil alterar o que já foi feito e é mais provável que suas sugestões/críticas sejam aceitas. E, se a tecnologia for aberta, você tem a chance de participar do nascimento de um futuro grande projeto.
Em compensação, quando se trabalha com tecnologias de ponta, a chance de se encontrar um bug chato de resolver é bem maior. Claro, isso é uma chance de você participar do desenvolvimento dessa tecnologia (se ela for opensource), mas atrapalha no desenvolvimento do seu projeto que depende dela, o que é chato.
Outros pontos negativos são a falta de documentação/ajuda e de ferramentas prontas baseadas na tecnologia. Como a base de usuários ainda é pequena, há muito o que se fazer e poucos para te ajudar. Mas, na minha opinião, mesmo com esses contras, é muito mais legal e recompensador trabalhar com tecnologias de ponta.
E você, o que acha? Mande sua opinião!
Imagem via Flickr
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
