Vinicius Ebersol

Como já disse algumas vezes, em nossa equipe estamos modificando a nossa estrutura, em busca de maior produtividade e integração de ferramentas como o Git. Já estamos experimentando o Retrospectiva, mas este não resolveu nossos problemas e ainda criou alguns outros. Por exemplo, ele não tem ferramenta de estimativa de tempo, o que em nossa equipe é muito importante. Foi então que o Everton deu a idéia de utilizarmos o Redmine, é um trac em Rails que tem todos os recursos que utilizamos no Trac atual e além disso, tem muitos recursos que no Trac só funcionam como plugins.

Uma breve olhada no demo do Redmine nos deixou muito felizes, pois ele tem tudo que utilizávamos no Trac e mais um pouco! E o melhor de tudo, é em Ruby on Rails. Ok, é em Rails, mas o que isso tem a ver? Isso permite que além de termos a possibilidade de colaborar com a comunidade de desenvolvimento, possamos criar outros recursos que acharmos necessários ou integrar com uma futura ferramenta, como nosso site ou blog.

Entre os recursos que achamos diferenciais no Redmine, o principal é o fato de ele ser multi-projetos e permitir que o administrador determine a qual projeto cada usuário pertence. E o melhor de tudo, tem suporte a Git, o que atualmente tem se tornado muito importante para nós.

Algumas telas do Redmine:

Alguns recursos do Redmine:

• Multiple projects support
• Flexible role based access control.
• Flexible issue tracking system
• Gantt chart and calendar
• News, documents & files management
• Feeds & email notifications.
• Per project wiki
• Per project forums
• Simple time tracking functionality
• Custom fields for issues, projects and users
• SCM integration (SVN, CVS, Mercurial, Bazaar and Darcs)
• Multiple LDAP authentication support
• User self-registration support
• Multilanguage support
• Multiple databases support

Com todos estes recursos, não tem porque não utilizar o Redmine. Veja mais alguns recursos do Redmine.

Primeiramente vou falar sobre o fato que me levou a escrever este post. Há um tempo atrás escrevi um post rápido falando da dificuldade de validar a marcação dos formulários em rails com o W3C validator. A minha reclamação foi ouvida, ou pelo menos o problema foi solucionado. Hoje já é possível que inputs com o name do tipo name="post[title]" passem na validação da W3C.Para verificar isto comecei a acessar alguns sites em rails, e fiquei pasmo com o fato de muitos deles não passarem na validação, por erros bestas como a falta de elementos básicos como a barra no final de tags como <br /> ou ainda o não fechamento de tags. Então fui na página do Rails e dei uma verificada nos sites indicados. O resultado foi:

• Basecamp – Reprovado
• Campfire – Reprovado
• 43 Things – Reprovado
• Odeo – Reprovado
• Shpify – Reprovado
• Fluxiom – Reprovado
• Strongspace – Reprovado
• Typo – Aprovado

Dos projetos brasileiros em rails:

• Spesa – Aprovado
• Mapia – Reprovado
• Pelotas Center – Reprovado
• Canguçu Center – Reprovado

Da amostra acima, temos 83% de reprovação no W3C Validator, o que atualmente acho demais! Na verdade acredito que com todos os recursos que o Rails oferece, a reprovação deveria ser muito menor, algo em torno do inverso do resultado atual, ou seja, 15%.

Com este artigo não tenho como objetivo participar da promoção do Rails Podcast Brasil, mas sim alertar a todos os desenvolvedores da necessidade de ter um código limpo e semanticamente correto. Muitos podem achar que é exagero e paranóia ficar se preocupando com a validação da sua marcação, mas a verdade é que devemos pensar sempre no usuário, e não na conveniência de fazer uma marcação rápida para entregar o trabalho logo e receber. É muito importante discutir acima de tudo sobre a semântica da coisa, e dedicar um tempo especial para isso. Já perdi tardes batendo boca com os colegas de equipe – em especial com o Everton, que tem uma noção muito boa de padrões web e semântica – de como otimizar a marcação para deixá-la limpa e fácil de entender. Posso afirmar que não foi tempo em vão.

Isto é um alerta a todo programador ou pessoa que trabalha o dia inteiro na frente do computador. Não tome café na volta de seu computador, principalmente se ele é um notebook.

Eu derramei café em toda a extensão do teclado, mas foram pingos, não foi uma xícara inteira, mesmo assim caiu um pouco em baixo das teclas. Primeiramente eu limpei com um lenço de papel e segui trabalhando, de repente começou um barulho estranho, uns estalos em algumas teclas enquanto eu pressionava, pois o café que estava em baixo delas começou a secar. Então falei com o Fábio Riemke, e na noite de ontem ele me trouxe uma graxa sintética branca e colocou em baixo das teclas. Além de resolver o problema do barulho, deixou todo o teclado mais silencioso, pois ele aproveitou para passar em todo o resto do teclado. É uma dica muito boa!

Vida de quem trabalha com tecnologia é assim, hoje você aprende uma coisa que amanhã não será mais necessário, e assim consecutivamente… Encontro-me em um estágio de aprendizado constante, ainda mais quando estamos promovendo na equipe uma alteração drástica na infra-estrutura.

Em reunião decidimos no início do ano que iríamos utilizar trac’s em ruby para facilitar a customização e a integração com nosso futuro site, clientes, etc… É um passo muito grande para uma equipe que arrecém está se estabelecendo, porém, creio que nos tornará mais produtivos e com certeza diferenciais no mercado.

Outro fator importante, é a mudança no controlador de versão. Muitas vezes ficamos empatados em tickets por depender de conexão (pode acontecer de sua internet estar fora do ar) ou ainda por problemas como este. Por isso decidimos passar a usar o Git.

Ainda não etávamos utilizando Git, por estarmos em projetos antigos, mas esta semana começamos um projeto e decidimos (apenas eu e o Everton) usar git como repositório local juntamente com o git-svn para commitar ao servidor (o Retrospectiva ainda não tem suporte a Git, mas AINDA…). Eu já sei os comandos básicos do Git e do Git-SVN, mas confesso que o que me incomodou foi o Vim como editor padrão. Sou usuário linux, mas não me sinto nem um pouco à vontade para usar este editor, eu uso sempre o Nano para tarefas no console e o Emacs para programar. Então hoje a tarefa do dia foi aprender a modificar o editor que eu irei utilizar para fazer os comentários do commit. No subversion é muito fácil alterar, mas no Git eu encontrei muitas informações confusas acerca disto, somente algumas horas depois achei a solução fuçando no git da minha máquina mesmo. Nisso, o dia já estava acabando e eu notei que mesmo perdendo um dia, essa coisa boba de procurar como alterar o editor padrão do Git me mostrou outros recursos que eu posso utilizar no Git e Git-SVN.

Para alterar o editor padrão do Git no Ubuntu, é muito simples:

1. Abra o arquivo com o seu editor favorito:

sudo emacs /usr/bin/git-commit

2. Vá até a linha 582 e altere o editor, no meu caso eu alterei do vi para o emacs, mas você pode alterar para o nano para editar seus commits no terminal:

${VISUAL:-${EDITOR:-emacs}} "$GIT_DIR/COMMIT_EDITMSG"