Um ano

No último sábado, dia nove de agosto, este blog completou um ano de vida, contados a partir do primeiro post. Tem sido uma caminhada muito boa. Aprendi muita coisa (sou meio viciado nisso ;) ), mudei muita coisa e, hoje, Ruby e Rails “me sustentam”.

Obrigado a todos que acompanham, prestigiam e comentam. Já são mais de 200 assinantes do feed, o que me deixa muito feliz! :)

Reprisando aquele primeiro post: Ao trabalho! ;)

Um pouco mais sobre named_scopes

Um pouco mais? Mas cadê o primeiro artigo sobre isso? Bom, não o escrevi, mas vou partir do ponto em que parou o Nando Vieira em seu artigo sobre named_scopes. Logo, assumo que você já sabe o que é um named_scope e conhece algumas possibilidades, como condições dinâmicas e encadeamento de named_scopes.

Apenas lendo uma introdução aos named_scopes já dá pra ficar bem empolgado. É um recurso simples e, ao mesmo tempo, poderoso e, quando bem utilizado, pode resulta no código bonito e sucinto que buscamos todo dia.

Vamos, então, explorar mais algumas possibilidades desse recurso.

Clique para ver o artigo completo…

Ruby quick tip: Blocos para fallback em hash lookups

Normalmente, ao tentar fazer um lookup em um hash com uma chave não existente, você tem o seguinte comportamento:

>> h = {:foo => "bar"}
=> {:foo=>"bar"}
>> h[:other_foo]
=> nil

Você pode adicionar um bloco para tratar esses casos:

>> h = Hash.new { |hash, key| "#{key} is not here"}
=> {}
>> h[:foo]
=> "foo is not here"

É possível, inclusive, alterar o hash em questão:

>> h = Hash.new { |hash, key| hash[key] = "value for #{key}" }
=> {}
>> h[:foo]
=> "value for foo"

Learncast #1: BDD leve com Shoulda - testando modelos ActiveRecord

Behavior Driven Development parece ganhar tração constantemente nas comunidades de desenvolvedores de teste. Isso não é à toa: essa “nova” mentalidade dá o toque semântico que faltava às técnicas de Test Driven Development.

Na comunidade Rails, os três projetos mais conhecidos na área de BDD são RSpec, Shoulda e test/spec. Minha escolha é o Shoulda, que utilizo desde o lançamento com muito sucesso. Há um bom tempo venho “rascunhando” um screencast introdutório e, finalmente, ele está pronto. Clique aqui para baixá-lo em formato QuickTime.

O objetivo do screencast é apenas mostrar superficialmente o que é Shoulda e como testar funcionalidades de modelos ActiveRecord (como validações e associações). Em breve virão mais alguns cobrindo testes de controllers e mais detalhes sobre o uso do plugin.

Links interessantes:

Shoulda: tutorial | repositório | RDocs | bundle para TextMate

Plugin QuietBacktrace

Comentários, críticas e complementos são muito bem-vindos!

Obs: estou resfriado, mas fiz o possível para deixar o som o mais claro possível. Por favor, avise caso eu não tenha conseguido. :)

Update: como apontado nos comentários, subi o vídeo sem o som (duh!), mas isso já foi corrigido. Obrigado pelo aviso, pessoal.

Update 2: disponibilizei o script e as imagens que utilizo para o Autotest com o Shoulda em minha máquina, rodando o Leopard. Crie, na pasta home de seu usuário (/Users/<nome_do_seu_usuário>/), uma pasta chamada .autotest_images e copie as duas imagens para lá. Crie, também na home, um arquivo chamado .autotest e preencha-o com o script contido no pacote. Esse script é baseado em um script publicado pelo Carlos Brando.

Rails-footnotes, um plugin fundamental

Se você desenvolve em Rails no MacOS X com TextMate, você tem que utilizar o plugin rails-footnotes. Sério. É obrigatório. Mesmo.

Esse plugin coloca um rodapé em todas as páginas de sua aplicação, quando no ambiente de desenvolvimento, mostrando várias informações, como parâmetros da requisição, sessão, cookies, filtros, rotas, queries e log. Além disso, contém também links para abrir arquivos (como o controller ou view atual) no TextMate. Isso permite que você, enquanto navega pela aplicação, possa abrir no TextMate arquivos relacionados a página aberta no navegador, como o controller, a view, o layout ou a folha de estilos.

Parabéns ao José Valim, principal desenvolvedor do plugin atualmente.

Extremamente recomendado.

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.

A TIM, assim como as outras operadoras, é uma porcaria

Sempre recomendei a TIM como operadora móvel GSM no estado de São Paulo… até recentemente, quando precisei da empresa para algo a mais do que triviais ligações e mensagens.

Eu possuía um plano pós-pago e um número com DDD 14 (interior de São Paulo). Me mudei para a cidade de São Paulo e entrei em contato com a TIM para mudar meu DDD (perderia meu número anterior) e mudar para um plano pré-pago. Fui informado de que isso era possível mas, mesmo assim, tive que ficar uma hora e quarenta minutos negando um plano de conta fix que o atendente ficava continuamente empurrando. A regra deve ser: “Não basta dizer NÃO uma vez, são necessárias cinqüenta vezes para ter certeza”.

Após isso, o atendente inicia a migração. Note que ele deveria, em primeiro lugar, mudar o número e, após isso, o plano. Se você tem um plano pré-pago, não consegue alterar seu número, deve comprar outro chip.

Fico meia hora na linha enquanto a migração era realizada, a ligação cai e fico sem qualquer sinal por uns dez minutos. O sinal retorna, consulto o plano via SMS e vejo que estou com cinco reais de crédito num plano pré-pago. Mas o número permanecia o mesmo. Entro em contato novamente e sou informado de que clientes de planos pré-pagos não podem alterar seu número. Passo os números de protocolo e nome do atendente e me afirmam que, mesmo sendo um erro da empresa, teria que comprar um outro chip ou entrar com um processo na justiça (claro, com uma risadinha irônica, pois o trabalho pra levar adiante um processo é muito comparado a quinze reais de um novo chip).

Resultado: estou com o número antigo e plano pré-pago, graças a mais um show de incompetência e desrespeito.

Ingenuamente eu ainda acreditava e recomendava a TIM para meus amigos. Não mais. Estamos mergulhados em um mar de incompetência e amadorismo quando se trata de telefonia no Brasil.

Fui mais educado no título, mas a melhor frase para descrevê-las é: “A TIM, assim como as outras operadoras, é uma merda“.

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! :)

Novidade pra quem gosta de screencasts

Mike Clark anunciou há pouco em seu blog os Pragmatic Screencasts. O projeto inicia com quatro séries, cada uma sobre um tema (como Erlang e ActiveRecord), cada série com episódios vendidos a cinco dólares cada.

Screencasts são uma excelente forma de aprendizado prático e esta parece ser mais uma boa fonte, ao lado de Peepcode e Railscasts.

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.

Next Page →