No dia 11 de abril participei do 1st International Workshop on Test Driven Devevelopment (TDD2010), realizado em Paris. Fui apresentar meu paper entitulado “Most Common Mistakes in TDD Practice: Results From An Online Survey With Developers” (que pode ser baixado aqui). A plateia contava com pessoas de renome na comunidade como Michael Feathers, Steve Freeman, Laurie Williams, David Janzen, John Clements, entre outros.
O keynote foi feito pelo Steve Freeman, autor de um dos melhores livros de OO e TDD que já li (Growing Object-Oriented Software, Guided by Tests). Ele basicamente mostrou seu ponto de vista sobre TDD. Segundo ele, “programação comum está para TDD assim como programação procedural está para programação orientada à objetos”. Foco bem definido, bom feedback e progredir sem medo também foram citados como vantagens. Uma citação muito interessante, e que venho pensando há muito tempo sobre como transmitir essa idéia é a de que “o programador deve entender o porquê TDD funciona; caso contrário, é apenas burocracia”.
Em seguida, o aluno de mestrado Theodore Hellman nos apresentou a ferramenta que seu grupo desenvolve em Calgary, Canadá. Ela testa interfaces de uma maneira muito interessante: antes de desenvolver cada interface, o programador faz protótipos na ferramenta, desenhando caixas de texto, botões (parecidos com os que desenhamos no papel). A mágica acontece depois que o protótipo está pronto: você testa o protótipo, clicando nos botões e digitando valores nas caixas de texto fictícias, e a aplicação os executa na aplicação real! O problema é que funciona apenas para aplicações .NET Windows Forms.
Em seguida a apresentação do John Clements (um dos criadores do Dr. Scheme) e do David Janzen (professor da Politecnica da California, possui muitas publicações relacionadas a experimentos com TDD) sobre o quão difícil é ensinar TDD para os alunos. Apresentaram algumas técnicas de ensino e problemas que já tiveram nas primeiras aulas sobre o assunto.
O alemão Florian Barth, da Universidade de Manheim, mostrou a ferramenta para testes de aceitação que seu grupo trabalha. É uma mistura de Fitnesse com linguagem de programação, onde você escreve não só os casos de testes como a implementação do teste em planilhas. É bem interessante, já que basicamente elimina o trabalho de codificação dos testes. O problema é que algumas coisas ainda são um pouco complicadas e exigem um trabalho extra na planilha. Mas sem dúvida é um projeto para ficar de olho.
Robert Chatney apresentou seu framework LiFT, uma DSL para testes de aceitação em Java, inspirada no Cucumber. Ela faz com que seus testes em Java fiquem muito fluentes. Totalmente extensível, é um projeto que pretendo colaborar em breve. O código pode ser encontrado no Google Code.
Em seguida, apresentei meu paper sobre erros (ou desvios) que os programadores cometem quando praticam TDD. Apesar de algumas críticas em relação à metodologia (problemas esses que já eram conhecidos e estavam na seção de “ameaças a validar” do paper), as ideias ali foram elogiadas e todos concordaram com os problemas levantados pelo artigo. Lembrando que esse artigo é apenas um trabalho em andamento, parte da minha dissertação de mestrado. Espero postar partes dela em breve.
Chris Agmen-Smith apresentou sua experiência em um projeto real com ATDD, e fez questão de mostrar que é possível fazer ATDD sem grandes custos, mas com muitos benefícios.
No final do dia, Raj Mudhar solicitou ajuda para pesquisar na área de ATDD em projetos de grande porte. Qualquer empresa que tenha projetos grandes pode participar, divulgando seus dados e juntos publicarem os resultados em conferências de peso.
Resumindo, o evento foi muito muito bom. Um dia inteiro com riquíssimas discussões sobre as mais variadas pesquisas em TDD. Além disso, pude validar muitas ideias com pessoas realmente influentes na área. Um ponto muito interessante é que não estamos tão longe do que eles praticam no dia-a-dia, mas ainda temos um longo caminho a percorrer!
Quando criamos nossas aplicacões e precisamos disponibilizá-las em ambiente de producão queremos que o processo de deploy seja o mais rápido possível. Como tornar este processo padronizado dentro de nossa empresa ?
A forma mais prática é a criacão de pacotes a forma mais difundida é são os pacotes rpm (Fedora) e deb (Debian). Neste artigo vou focar na criacão de pacotes DEBIAN os que estou estudando no momento.
O primeiro passo é preparar o ambiente instalando a seguinte ferramenta no sistema operacional DEBIAN:
sudo apt-get install devscripts fakeroot
Crie um diretório debian no /home/usuario/debian
Baixe o source do software (software.tar.gz) no diretório /home/usuario/debian
Descompacte o arquivo tar.gz em seu diretório de debian acima.
Entre no diretório gerado pelo arquivo descompactado.
Debianizando o projeto com o comando.
dh_make -e email@domantededor -f ../projeto.tar.gz
Este comando irá gerar os arquivos básicos dentro do diretório (debian) para implementacão das configuracões do pacote deb
Como o Vinícius Teles sabiamente disse há alguns anos, “Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming“. Emprestando mais algumas de suas palavras, o motivo é que:
“Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado.
À primeira vista, a programação em par parece ser uma prática fadada ao fracasso e ao desperdício. Afinal, embora possa haver benefícios, temos a impressão de que ela irá consumir mais recursos ou irá elevar o tempo do desenvolvimento. Entretanto, não é exatamente isso o que ocorre.”
Não, não é isso mesmo!
Nossa experiência
Há quatro meses decidimos, de uma vez por todas, levarmos realmente à sério esse negócio de programação em par aqui nos times de desenvolvimento dos sistemas centrais da Locaweb. De imeditato, optamos pelo caminho mais eficaz: reduzimos pela metade o número de máquinas dos times. Sim, quase que do dia para a noite, passamos a ter apenas e tão-somente uma máquina para cada dois desenvolvedores.
Estações de pareamento: como é que é isso?
Desde que fizemos a redução de 50% de nossas estações de trabalho, passamos a ter as chamadas estações de pareamento, máquinas destinadas exclusivamente para trabalho.
Estações de pareamento precisam ter:
- usuário genérico para login;
- script para settar no git o dupla atual;
- configuração padrão de desktop, diretórios e ferramentas;
- apenas o instante messager de trabalho;
- apenas o cliente de e-mail de trabalho;
- acesso total à Internet;
- idealmente: 2 teclados, 2 mouses e 2 monitores (grandes!).
Mas não devem ter:
- arquivos pessoais;
- programas de distração.
Bem, não está diretamente associado ao modelo de estações de pareamento, mas é bem importante também que as duplas tenham ao seu lado o monitor da integração contínua de seu time, para ter sempre à vista o feedback dos builds. No nosso caso, temos monitores suspensos como o que pode ser visto na foto ao lado – de preferência, sempre verdinhos!
Estação de relax: tem isso, é?
Junto com a idéia das estações de pareamento também adotamos a idéia de estação de relax. Atualmente temos apenas uma, dado o tamanho de nossa equipe.
A estação de relax é uma máquina com acesso total à Internet para a galera relaxar um pouco durante a jornada de trabalho, acessar e-mail pessoal, redes sociais, internet banking, enfim, o que quiserem e bem entenderem. Acesso total à qualquer hora do dia!
O que temos colhido com isso?
Até agora só ganhamos! Ganhamos produtividade, qualidade, propriedade coletiva de código, padronização, e por aí vai.
Microsoft Enterprise Library é uma coleção de blocos de código desenhados para auxiliar desenvolvedores .NET com tarefas comuns de desenvolvimento.
Esta versão inclui:
Caching Block
Cryptography Block
Data Access Block
Exception Handling Block
Logging Block
Policy Injection Block
Security Block
Validation Block
Unity
A melhor versão da Enterprise Library contém novas características e atualizações que irão deixar os desenvolvedores .NET mais produtivos. Entre elas estão:
Refatoração da [...]
Em muitos projetos, é importante que o usuário informe senhas que tenham um mínimo de complexidade, evitando que sejam facilmente quebradas. Existem muitas soluções feitas em JavaScript, mas não encontrei nenhuma que fosse boa o bastante no backend.
Pensando nisso, criei uma gem chamada Password Strength que faz validação de diversos padrões, a fim de identificar senhas que sejam fracas. Ela é composta por 2 módulos: ActiveRecord e JavaScript.
A validação da senha é feita com base nas seguintes regras:
Tamanho da senha
Presença de letras, números e caracteres especiais
Presença de maiúsculas e minúsculas
Uso do login/e-mail na composição da senha
Sequências (123, abc, aaa)
Repetições
Cada uma dessas regras recebe uma pontuação negativa ou positiva, que irá influenciar no resultado final.
Assim, com base nessas regras, podemos classificar as seguintes senhas:
123 => fraca
123abc => fraca
aaaaaa => fraca
myPass145 => boa
myPass145$ => forte
Instalação
Para instalar, basta executar o comando
sudo gem install password_strength
Agora, configure seu aplicativo para carregá-la. No Rails 2, basta adicionar a linha abaixo ao seu arquivo environment.rb.
config.gem"password_strength"
No Rails 3, adicione a linha abaixo ao arquivo Gemfile.
O Password Strength permite que você valide senhas sem a necessidade de usar o ActiveRecord.
strength = PasswordStrength.test("johndoe", "mypass")#=> return an object
strength.good?
#=> status == :good
strength.weak?
#=> status == :weak
strength.strong?
#=> status == :strong
strength.status#=> can be :weak, :good, :strong
strength.valid?(:strong)#=> status == :strong
strength.valid?(:good)#=> [:good, :strong].include?(status)
Muito simples!
ActiveRecord
O Password Strength possui suporte para ActiveRecord 2.3+ (foi testado em 2.3.5 e 3.0.0-beta).
No seu modelo, adicione a validação validates_strength_of.
class User < ActiveRecord::Base
validates_strength_of :passwordend
Por padrão, as opções serão :level => :good, :with => :username. A opção :level define a complexidade mínima requerida e pode ser :good, :strong ou :weak (é desnecessário dizer que a última opção não faz o menor sentido, já que qualquer senha será aceita). Já a opção :with define qual o atributo que deverá ser usado na comparação da senha. Se quiser, pode definir um outro atributo:
validates_strength_of :password, :with => :email
Também é possível proibir senhas que usem determinados caracteres por completo com a opção :exclude. Podemos, por exemplo, evitar que senhas contendo a string asdf sejam usadas:
Se você não usa jQuery, pode usar apenas o arquivo password_strength.js e criar o seu próprio adaptador.
A API do JavaScript é essencialmente a mesma, inclusive com as mesmas regras de verificação. Veja:
var strength = PasswordStrength.test("johndoe", "mypass");
strength.isGood();
strength.isStrong();
strength.isWeak();
strength.isValid("good");
Você também pode usar a opção :exclude mas, no momento, apenas expressões regulares são aceitas.
var strength = PasswordStrength.test("johndoe", "password with whitespaces", {exclude: /\s/});
strength.isInvalid();
Se você usa jQuery, pode utilizar o plugin que já vem com o Password Strength.
$.strength("#username", "#password");
A definição acima irá utilizar o campo #username e #password para fazer a validação da senha.
Conforme a senha é digitada, uma imagem é colocada ao lado do campo de senha. Por padrão, as imagens utilizadas são
/images/{weak,good,strong}.png. Se você quiser, pode alterar esses caminhos:
Galera, estou postando aqui um Webcast que gravei para o blog da Locaweb. Trabalho na equipe de desenvolvimento Front-End / UX da Locaweb.
O que você pode fazer hoje para deixar seu site mais rápido?
Um site pode levar por volta de 200ms para gerar o HTML que será recebido pelo browser. Mas o tempo de “montagem” desta página no browser leva diversos segundos, tendo casos extremos com mais de 10 segundos.
Então a mudança que você pode fazer hoje, que vai impactar mais seu usuário ou cliente, é otimizar o tempo de carregamento de seu site no browser. Não é gastar horas e horas otimizando seu código server-side como Ruby on Rails, PHP ou .NET. Mesmo que seu site já tenha milhares de acessos por hora, a primeira coisa a ser feita é otimizar a performance de seu site no browser, e depois partir para a otimização de server-side.
Nesse Webcast falo sobre várias técnicas e dicas para melhorar a performance client-side de seu site:
Dá para acreditar que já se passou 1 ano desde a última mudança de layout?
Peguei duas horinhas dessa madruga para criar uma nova versão, alterada no ar mesmo.
Para dar sua sugestão, crítica ou mesmo avisar de alguma coisa que esteja quebrada, envie um comentário!
Proudly, I give to thee canivete, the Ruby Ultimate Utils gem.
It doesn't ends with world's famine, but at least allows you to mark some methods of your ruby objects as deprecated and they will spit a warning every time you access them.
I think it has room for more - have you any idea to share?
install with gem install canivete or grab source code here
edit: I needed to change the name from ruutils as a gem with a very similar name exists (rutils) - thanks for pointing out jastix.
