Dica: Migrations com comandos SQL e problemas com testes no Rails
Se você utiliza o método execute em suas migrations para rodar comandos SQL na criação de sua base de dados, cuidado ao rodar os testes de sua aplicação. Na criação da base de testes, o Rails não roda as migrations, ele utiliza o script contido no arquivo schema.rb. O problema é que, ao fazer o dump da base para esse arquivo, o Rails não utiliza os comandos SQL definidos nas migrations e sim os métodos da DSL de manipulação de estrutura e dados (como add_index, create_table, add_column etc).
Devido a isso, se você utilizou alguma particularidade do sistema gerenciador de banco de dados que utiliza ao definir sua base, muito provavelmente ocorrerá um erro no banco de dados ao tentar rodar os testes de sua aplicação.
Exemplo:
Em uma migration:
(...) create_table :tests do |t| t.column :test_column, :text end execute("ALTER TABLE test ADD INDEX test_index(test_column(200));") (...)
No MySQL é necessário definir um comprimento para índices em colunas dos tipos TEXT e BLOB e, como não há essa opção no método add_index, utilizamos um comando SQL. No entanto, no arquivo schema.rb, a criação do índice é feita da seguinte maneira:
add_index "tests", ["test_column"], :name => "test_index"
E isso causa um erro no MySQL. Para corrigí-lo, procure em seu arquivo environment.rb pela seguinte linha:
config.active_record.schema_format = :sql
Por padrão ela vem comentada. Retire o comentário para fazer com que o banco de dados de testes seja criado diretamente com comandos SQL. Caso não a encontre comentada, adicione-a dentro do bloco Rails::Initializer.run.
21 truques de Ruby que você deveria estar usando
Creio que a maioria já viu o artigo 21 Ruby Tricks You Should Be Using In Your Own Code no Ruby Inside. O texto contém truques realmente interessantes, mas esse post é apenas para uma dica: se você ainda não assina o feed do Ruby Inside, faça-o agora! ![]()
Conheça suas gems
Uma boa forma de aprender mais sobre Ruby é “fuçar” no código-fonte de gems. Vagando pelo GitHub e RubyForge esses dias, encontrei um conjunto de pequenos utilitários escritos por Dr Nic (que deve ser um robô ou extraterrestre).
Um desses utilitários chama-se find_gem (não achei um site oficial, apenas esse arquivo de texto explicando como configurar e usar). Ele instala dois comandos em seu sistema:
- find_gem <nome_da_gem>: retorna o caminho completo da gem passada como parâmetro.
- edit_gem <nome_da_gem>: abre os fontes da gem passada como parâmetro no editor configurado com a variável de ambiente EDITOR. Assim você pode vasculhar o código-fonte das gems com mais comodidade.
No MacOS X Leopard funciona muito bem. Outra funcionalidade legal é o auto-complete no comando gem (tanto para os comandos, como install e list, quanto para nomes de gems).
Veja aqui a lista de utilitários do Dr Nic Utilities. Estou utilizando também o git_autocomplete e recomendo.
Google Doctype
O mais novo lançamento da Google chama-se Doctype. Trata-se de uma enciclopédia aberta (a la Wikipedia) para documentar padrões web abertos como HTML e CSS e outros tópicos sobre desenvolvimento como segurança e caching. De quebra ainda estão disponíveis 8 mil linhas de Javascript que formam a biblioteca Javascript desenvolvida pela Google.
A intenção é criar uma referência completa sobre padrões web, tudo com casos de teste. Uma iniciativa muito interessante, vale a pena conferir.
High Five: five tips on testing with Rails
Testing is a very important aspect of Rails programming. The framework makes testing really easy, eliminating some excuses you could have for not testing your applications. Here’s my five tips for testing with Rails:
- Embrace the TDD cycle: this one isn’t Rails related, but is very important. You can write your code first and test it after and you’ll get some benefits, but Test-Driven Development really leverages the power of this automated testing. By writing your tests first you get low coupling and high cohesion through a better interface (API) design. Moreover, by following the red-green-refactor cycle you’ll always know when you’re done and will avoid scope creep.
- Test your helpers: plain and simple. Rais Recipes has a recipe about it and, with Edge Rails, testing helpers got easier.
- Overmocking results in brittle tests:and brittle tests are a bad thing. Many people just mock and stub everything. By doing this you’re coupling your tests to the inner details of the tested code instead of the result of its execution. You can see an example here (and subscribe to that blog’s feed, it’s very good).
- Watch out on your way to BDD: Behavior-Driven Development is in vogue within the Rails community. Be careful. Just like you can write Fortran in any language, you can use something like RSpec and still not do BDD. BDD is about a shift in the way you think about tests, not about tools by themselves. You can use Test::Unit and do BDD. Tools like RSpec and Shoulda (my personal choice) are facilitators, they don’t guarantee anything.
- One assertion per test: this is one of that tips that seems inoffensive but once you’re doing helps a lot. Why? Jay Fields can explain better than me.
And that’s it. Five quick and simple tips that I hope will help you. Feel free to share your own tips in the comments. This article is my entry to the Railscasts’ 100th episode contest. Take some time to visit the site, it’s really good.
Links interessantes
- Ezra Zygmuntowicz anunciou que está fazendo modificações no ActionPack em seu fork do Rails no Github. Basicamente, ele está migrando a funcionalidade de integração com Rack do Merb para o Rails e, com isso, fazendo uma limpeza geral no código, conseguindo mais desempenho e estabilidade e caminhando para uma possível implementação thread-safe.
- Ruby Hero Awards - indique os membros da comunidade que, para você, fazem um trabalho importante. Reconhecimento é uma grande motivação.
- O que é Ruby Enterprise Edition? - Fábio Akita - o Railer que nunca dorme - em mais um excelente artigo.
- Interessado em Git? Então dê uma olhada nesse post para algumas boas referências
- A arte de testar aplicações web - mais uma ótima apresentação de Gregg Pollack
- Posts do Signal vs. Noise: Start a business, not a startup, If you’re working in a big group, you’re fighting human nature, Quit your job!.
- Metaprogramming Ruby Presentation
- Import GMail contacts using Rails
- Lançado Ubuntu 8.04
Configure, make, make install
Ok, se você usa Unix, Linux ou mesmo MacOS X, deve ter executado essa sequência de comandos várias vezes. Mas, você sabe o que eles fazem? Se não sabe, aí vai uma explicação simplificada:
O utilitário make é, de forma geral, um automatizador de tarefas: ele possibilita que você crie scripts para tarefas comuns e os nomeie. Assim, quando precisar executar dada tarefa, pode executar apenas make <nome_da_tarefa>. Essas tarefas ficam no arquivo Makefile, que você deve ter visto várias vezes.
O make também possui algumas regras padrão. Se você der o comando make programa e a tarefa programa não existir, o make executará suas regras padrão. Uma delas é a compilação do arquivo fonte do programa: se programa.c é mais novo que programa.o, executa o “linkador” e compila para executável, caso contrário, apenas compila programa.o (usando aqui programas em linguagem C, comuns na plataforma).
Executar make, sem um nome de tarefa (chamada de “target”), executa a primeira tarefa no arquivo Makefile do diretório atual, que é onde elas ficam definidas. O comando make install executa a tarefa chamada install. Note que tratam-se de convenções: um desenvolvedor poderia chamar essa tarefa de setup, mas a grande maioria segue a convenção.
O comando configure faz o trabalho inicial: configura paths, detecta o shell utilizado, verifica as dependências etc. Esse comando é um script gerado automaticamente e, após ser executado, gera o Makefile com as configurações específicas do seu sistema. Isso poupa muito trabalho do desenvolvedor, dada a extensa variedade de dependências que podem existir no grande universo dos sistemas Unix-like.
Recapitulando:
- Você executa o script configure. Isso cria um Makefile com as configurações do seu ambiente;
- Em seguida, você executa make. Isso faz com que a primeira tarefa do arquivo seja executada. Geralmente isso significa “setar” algumas variáveis e compilar o programa.
- Finalmente, você executa make install. Isso executa a tarefa install e instala o programa em seu sistema.
Isso é o básico. Nem todos os programas se comportam da mesma maneira. Cada um define ações diferentes para seus scripts, mas todos com o objetivo de verificar dependências, configurar o ambiente, compilar e instalar o programa.
Achou alguma besteira no texto? Quer adicionar mais informação? Comente! A comunidade e eu agradecemos.
Fonte:
Jason Fried: Questione seu trabalho
Em sua apresentação na conferência South by Southwest, Jason Fried novamente enfatizou a importância do sofware simples e de atitudes como dividir grandes decisões em várias pequenas decisões e de questionar seu trabalho.

Essas perguntas são sempre muito importante ao analisarmos as vantagens de se fazer algo. Realmente vale a pena? Poderíamos fazer mais simples? Poderíamos fazer outra coisa que agregue mais valor?
Outros pontos de destaque da apresentação:
- Otimize para agora, deixe o amanhã para amanhã;
- As decisões que você faz hoje não precisam durar para sempre;
- Tome pequenas decisões. Elas são mais fáceis de mudar caso não dêem resultado;
- Tenha sucesso e dinheiro ajudando outras pessoas a ter sucesso e dinheiro;
- Comece com o jeito mais fácil. Ele geralmente lhe entrega de 80 a 90% do que você quer;
- Invista mais no que não muda (ex: velocidade de busca sempre será necessário, então a Google investe muito nisso);
- Compartilhe seu conhecimento;
- Interrupções são inimigas da produtividade;
- Seja aberto, honesto e responsável;
- Quase nada é urgente ou complicado demais. Nós é que tornamos assim.
Confira o post de Jason e também o resumo de sua apresentação, feito por Tim Walker.
Ebb - novo web server para Ruby
Ebb é um servidor web escrito em C com binding para Ruby (e, futuramente, Python), que pode ser utilizado com Rails e Merb, entre outros frameworks.
Seguindo a onda de melhorias em desempenho e facilidade de implantação que temos visto ultimamente no mundo dos frameworks web para Ruby (Thin, SwitchPipe), o desenvolvedor do Ebb afirma (e mostra benchmarks) que seu servidor é mais rápido que Mongrel e Thin.
Para instalar, basta o comando gem install ebb (assumindo que as dependências - glib-2.0 e pkg-config - estejam instaladas). Para testá-lo, vá até o diretório raíz de sua aplicação Rails e digite ebb_rails start. Em ambiente de desenvolvimento, pareceu bem rápido.
Problemas instalando o ImageMagick 6.3.9 no Linux?
Montando um novo ambiente de desenvolvimento (com Ubuntu 7.10), precisei instalar o RMagick 2.2.2 e o ImageMagick, do qual o primeiro depende. Tive alguns problemas e achei interessante registrar aqui para servir de referência caso alguém passe pelo mesmo.
Pelas buscas que fiz, algumas outras pessoas tiveram o mesmo problema a partir da versão 6.3.8 do ImageMagick em diversas distribuições Linux.
Para instalar, baixei o tarball do ImageMagick mais recente e segui os passos descritos em http://www.imagemagick.org/script/install-source.php#unix. Ao testar a instalação (digitando o comando display no terminal), recebi o seguinte erro:
error while loading shared libraries: libMagickCore.so.1: cannot open shared object file: No such file or
directory
O que acontece é que a instalação via make copia as bibliotecas utilizadas pelo ImageMagick para /usr/local/lib e, ao executar, o ImageMagick busca-as em /usr/lib. Provavelmente é um bug no script utilizado para compilar e instalar o ImageMagick. Para resolver o problema, fiz uma pequena “adaptação técnica”:
sudo cp /usr/local/lib/libMagick*.* /usr/lib
Desta forma, as bibliotecas ficarão no diretório em que o ImageMagick faz a busca. Não é a solução mais bonita do mundo, mas funcionou.
Se tiver alguma solução mais limpa, por favor, deixe um comentário.