Novidades no Rails

Edge Rails

Named Scope

Há algum tempo falei do plugin has_finder. Esse plugin foi incorporado ao Rails com o nome de named_scope e já estará disponível na versão 2.1 do framework. Veja alguns exemplos de uso:

class User < ActiveRecord::Base
  named_scope :active, :conditions => {:active => true}
  named_scope :inactive, :conditions => {:active => false}
  named_scope :recent, :conditions => ['created_at > ?', 1.week.ago]
end

Assim, podemos fazer buscas da seguinte maneira:

User.active    # o mesmo que User.find(:all, :conditions => {:active => true})
User.inactive # o mesmo que User.find(:all, :conditions => {:active => false})
User.recent   # o mesmo que User.find(:all, :conditions => ['created_at > ?', 1.week.ago])

E também encadeá-las:

User.active.recent
  # o mesmo que:
  # User.with_scope(:conditions => {:active => true}) do
  #   User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
  # end

Veja mais funcionalidades aqui.

has_one :through

Outra novidade é que a associação has_one passa a aceitar o modificador :through.

Veja mais aqui.

Plugin migration_buddy

Mais um plugin de Rick Olson, facilita o gerenciamento de migrations com Git, ajudando à resolver conflitos que podem ocorrer quando trabalhando em equipe (por exemplo, dois ou mais desenvolvedores criando migrations com a mesma numeração para fazer coisas diferentes).

Veja o repositório no GitHub.

March 25, 2008 | Filed Under Notícias, Rails | Leave a Comment 

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

March 18, 2008 | Filed Under Dicas, Linux | Leave a Comment 

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.

March 18, 2008 | Filed Under Artigos, Desenvolvimento, Dicas | 4 Comments 

“Rápido e Sujo” ou “Lento e Limpo”. Porque não “Rápido e Limpo”?

Há algum tempo atrás assisti ao vídeo da apresentação de Martin Fowler na RailsConf 2006. Nessa apresentação ele fala sobre o que o faz gostar do Rails (e do Ruby) como plataforma para desenvolvimento de software comercial.

Um dos pontos mais interessantes mencionados por ele é o seguinte: com Rails, conseguimos software limpo entregue rapidamente. Antes disso, você tinha duas frentes: a do “Rápido e Sujo”, geralmente representada por PHP e VB (até a versão 6) e a do “Lento e Limpo”, com Java e .NET.

O grupo do “Rápido e Sujo” promete entregar o software em menos tempo mas, geralmente, o código é uma bagunça e qualquer correção, alteração ou melhoria torna-se um pesadelo.

Já o grupo do “Lento e Limpo” lhe promete entregar uma maravilha da engenharia de software, utilizando cada design pattern já visto nesse mundo (o que é algo bem prejudicial mas, ainda assim, comum), interfaces e IoC por todos os lados, enfim, um código com alta manutenabilidade e extensibilidade (ê palavrinhas…), o que demora uma eternidade e nem sempre é atingido.

Rails estimula uma visão diferente: “Rápido e Limpo”. O framework deve fazer todo o “trabalho sujo” por você, permitindo que você foque apenas no domínio do problema, eliminando muita complexidade acidental e permitindo menores tempos de entrega. Rails atinge isso através do extensivo uso de DSLs e convenções, entre outros conceitos. Além disso, está estimulando essa visão em outras plataformas, o que é muito bom.

Equilíbrio sempre é importante: você quer sim entregar software rapidamente (assim consegue vender mais), mas não quer ficar com uma bizarrice nas mãos para dar manutenção. Por outro lado, não precisa do código mais perfeito do universo, principalmente se isso significa demora excessiva. Pragmatismo é a chave. Faça o que funciona pra você.

Duas observações importantes:

1. Estou generalizando um pouco quanto à PHP, VB, Java e .NET. A qualidade do código depende muito do desenvolvedor, mas algumas linguagens/plataformas estimulam estilos de programação diferentes. Não se sinta ofendido ou menosprezado. :)

2. Por favor, não faça como muita gente e saia alardeando que Rails permite desenvolvimento rápido e ponto. Muita gente está fazendo todo tipo de atrocidade com o framework em nome da rapidez, isto é, prazos reduzidos. O foco da comunidade é na qualidade, por isso falamos tanto sobre TDD, beleza no código, DRY, KISS e outros conceitos. Os prazos menores são consequências, não são objetivos.

March 14, 2008 | Filed Under Artigos, Desenvolvimento, Rails | 2 Comments 

Migrando para a terra da Maçã

Após quase dois meses de espera (aparentemente, a Apple Brasil estava sem estoque), meu iMac 20” finalmente chegou.

iMac

Eu já havia tido um pequeno exemplo do que é um produto Apple com meu iPod Nano, mas nada se compara à experiência completa de ótimo hardware, design estonteante e uma plataforma bem feita e com alta usabilidade.

O choque da mudança não é inibitivo (foram 14 anos de Windows e pouco mais de 1 ano de Linux), mas é considerável. Porém, com poucas horas de uso, já estava me sentindo bem mais confortável. O pior de tudo é usar teclado ABNT2 no trabalho (onde utilizo Windows e Linux Ubuntu), além de um velho monitor de 15” e depois fazer uma incrível mudança de contexto ao trabalhar em casa. Nada impossível de se acostumar, mas seria legal se eu pudesse trabalhar com um Mac o tempo todo.

A primeira impressão do Mac OS X foi ótima. O sistema é muito bonito e muito fácil de usar, enquanto mantém uma plataforma poderosa “por baixo dos panos”.

Baixei o trial do TextMate, mas ainda não fiz nada com ele. Ainda estou no processo de instalar aplicações e mover gigabytes de arquivos do computador antigo para o iMac.

Minha única expectativa nessa migração pra “outras terras” é de que eu não queira voltar. :)

Alguns links úteis para quem também está migrando:

iUseThis: espécie de rede social onde os usuários publicam e avaliam os softwares que mais utilizam em seus Macs (algo como um Digg para software). Muito bom para descobrir as aplicações mais populares da plataforma.

Hack Attack: A guide for switching to a Mac

Mac OS X keyboard shortcuts

Comentário do Fábio Akita no blog do Ronaldo Ferraz com muitas dicas interessantes

March 11, 2008 | Filed Under Apple, Pessoal | 2 Comments 

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.

March 4, 2008 | Filed Under Anúncios, Dicas | 3 Comments 

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.

March 4, 2008 | Filed Under Dicas, Linux, Rails | 5 Comments