A execução de testes em Rails é feita, normalmente, com o comando rake test. Este comando executa automaticamente todos os testes unitários e funcionais. Porém, algumas vezes queremos executar apenas uma parte dos testes, seja porque sabemos que outra parte do sistema está dando algum erro que pretendemos tratar depois, seja porque acabamos de alterar um trecho do código (ou dos testes) e queremos verificar se estes estão OK.

Para executar apenas os testes unitários, executamos o comando rake test:units. Para os testes funcionais, rake test:funcionals. Mas se quisermos executar um arquivo de testes específico, devemos trocar o rake pelo próprio ruby:

ruby test/unit/usuario_test.rb

Para ser ainda mais específico e executar um único método, basta acrescentar o parâmetro --name:

ruby test/unit/usuario_test.rb --name test_dados

Outra vantagem de testar executando o Ruby diretamente (sem o rake) é que não ocorre o problema de tabelas não existentes no ambiente de desenvolvimento, como ocorre com o rake.

Referência: Rails: Unit Test without Rails


Quem já tentou tratar caracteres acentuados em Ruby deve ter percebido que a linguagem não considera estes caracteres como letras. Métodos como upcase e downcase são “locale insensitive”, como diz a descrição destes métodos no manual do Ruby:

str.downcase => Returns a copy of str with all uppercase letters replaced with their lowercase counterparts. The operation is locale insensitive—only characters `A’ to `Z’ are affected.

O projeto Brazilian Rails foi criado com o objetivo de resolver este e outros problemas. O projeto é instalado como um plugin para Rails, e define novos métodos para a classe String, como o upcase_br e o downcase_br, que podem ser usados em substituição aos métodos originais. O plugin acrescenta ainda outras funcionalidades, como data, hora, feriados, dinheiro e mensagens de erro, todas adaptadas ao português brasileiro.

Ontem enviei um patch para o projeto, contribuindo com alguns novos métodos para Strings. Em breve a versão atualizada deverá ser disponibilizada, conforme o post do Celestino Gomes.


Aqui na Globo.com adotamos Scrum em (quase) todos os projetos. Quando cheguei aqui eu não conhecia praticamente nada sobre Scrum, e precisei aprender sobre o assunto para não ficar perdido.

Minha primeira fonte de consulta para o assunto foi o ótimo livro Agile Software Development with Scrum (que, inclusive, está na lista de livros recomendados para desenvolvedores pelo Guilherme Chapiewski). É um livro introdutório, muito bom para quem está começando a conhecer o assunto.

Outro material interessante sobre o assunto são as checklists, também indicadas pelo GC.

Finalmente, o site Visão Ágil, que publica periodicamente uma revista em PDF sobre desenvolvimento ágil, inaugurou uma seção Biblioteca, com palestras, artigos e apresentações, alguns deles sobre Scrum. Vale a pena dar uma olhada.


O blog Penguim’s Place publicou um excelente artigo em 3 partes, apresentando várias técnicas para procurar falhas de segurança em servidores web utilizando apenas o Google para isso. São técnicas muito interessantes, como buscar servidores com a página inicial padrão do Apache (o que pode indicar que ele foi mal configurado) e procurar por falhas específicas em banco de dados. Na parte final são apresentadas técnicas de defesa.


Na versão 2007, o Microsoft Office começou a usar o formato OpenXML como padrão - no caso do Word, a extensão deste formato é docx. Porém, este formato é incompatível com o OpenOffice (e com versões anteriores do Word…). Para abrir arquivos deste formato no OpenOffice, instale o odf-converter. Após instalá-lo, reinicie o OpenOffice e você conseguirá abrir e salvar nesse formato. O pacote deb pode ser acessado aqui. Instalei este pacote sem problemas no Ubuntu com OpenOffice 2.3, apesar dos comentários nessa página de download.

Referência: Arquivos OpenXML (.docx, .xlsx) no OpenOffice e BrOffice sem traumas