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:

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:

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

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:

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:

configure; make; make install

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.

slide_JF

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:

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.

Next Page →