Desenvolvimento Ágil - Blog da Improve It: Tag ruby

Como Testar parte 2 - Mocks

Marcos Tapajós — Sun, 16 Nov 2008 18:22:13 -0200

Tem gente "chutando" Demeter.

Minha idéia era escrever um post dessa série por semana, mas infelizmente uma tendinite tem me atacado e está meio complicado ficar escrevendo muito. Por isso mesmo esse segundo artigo será bem compacto. Todos os códigos citados nesse post fazem parte de um projeto How Test que está disponível em: http://github.com/tapajos/how-test

Nesse post a minha idéia é mostrar de forma bem simples como funciona um mock object no Rspec e no Test::Unit(usando o mocha).

Para exemplificar eu vou fazer uma crítica a uma construção que eu tenho visto muito em diversos projetos e que viola a Lei de Demeter(Principle of Least Knowledge). Ou como dizia, o meu amigo, Bernardo, "Tem gente chutando Demeter!".

Vamos a um exemplo dessa violação:

Supondo que você tenha um modelo Account que se relaciona ao modelo User.

class Account < ActiveRecord::Base
  belongs_to :user
end

Freqüentemente eu vejo construções do tipo:

@account.user.name
@account.user.mail
@account.user.rg.number
@account.user.rg.state
@account.user.rg.city

O grande problema é que nesse tipo de construção você está "conhecendo" coisas demais e certamente vai pagar por isso num futuro breve, quando você precisar fazer um refactoring e tiver que mudar em vários lugares. Imagina se o User deixa de ter um "name" e passa a ter um "full_name".

Para resolver esse tipo de problema basta você concentrar esse "conhecimento" no seu modelo Account da seguinte forma:

class Account < ActiveRecord::Base
  belongs_to :user
  def user_name
    user.name
  end
end

OBS: Vou me concentrar apenas no problema com o nome e não vou me preocupar em validar se o relacionamento foi estabelecido.

Bem, finalizada a crítica a uma falha de design OO vamos ao objetivo desse post, mostrar como *EU* testaria esse problema.

Como eu falei no post anterior, não gosto muito de usar fixtures para testes unitários e por isso mesmo vou apelar aos mock objects. Se você não está muito familiarizado com mocks sugiro que pare por aqui e leia um pouco mais sobre isso. Uma referência rápida pode ser o wikipedia mas realmente sugiro que vá mais adiante.

Testando usando RSpec(usando o framework de mock padrão):

before(:each) do
  @account = Account.new    
  @user_mock = mock_model(User)
  @account.stub!(:user).and_return(@user_mock)
end

describe ".user_name" do

  it "should delegate to user.name" do
    @user_mock.should_receive(:name).and_return("Tapajós")
    @account.user_name.should == "Tapajós"
  end

end

Testando usando Test::Unit com mocha:

setup :create_model

def test_user_name
  @user_mock.expects(:name).returns("Tapajós")
  assert_equal "Tapajós", @account.user_name
end

private

  def create_model
    @account = Account.new
    @user_mock = mock("User")
    @account.stubs(:user).returns(@user_mock)
  end

Explicando...

Em ambos os casos eu preciso que a minha account simule o relacionamento com User e para isso eu vou retornar um mock object. Isso é feito pelas linhas:

RSpec:

@account.stub!(:user).and_return(@user_mock)

Test::Unit:

@account.stubs(:user).returns(@user_mock)

Após o setup ou o before, temos um modelo @account onde o @account.user retorna um mock.

Feito isso eu preciso configurar o meu mock, isto é, informar que ele receberá uma mensagem name (chamada do método .name) e essa retornará o meu nome(sim, sou egocêntrico). Isso é feito pelos métodos "should_receive" e "expects" conforme as linhas abaixo:

RSpec:

@user_mock.should_receive(:name).and_return("Tapajós")

Test::Unit:

@user_mock.expects(:name).returns("Tapajós")

Depois que nossos mocks foram devidamente configurados podemos, finalmente, fazer nossa verificação do retorno, isto é, simplesmente chamar nossos métodos conferir o retorno. Pronto teste feito com sucesso, sem precisar recorrer a banco de dados nem configurar fixtures.

Nesse momento deve ter surgido uma dúvida: "Porque uma hora você usa stub! e outra um should_receive?"

A resposta é bem simples, o stub! não faz um verify no final enquanto a outra chamada sim. Na pratica isso significa:

Stub! ou stubs

Quando eu uso stub!(ou um Stubs) eu estou configurando o meu modelo account para responder pelo método user retornando o @mock_user porém não me interessa quebrar esse teste caso você não chame esse método.

Should_receive ou expects

Quando eu uso should_receive(ou um expects) eu estou configurando o meu mock user para responder pelo método name porém caso esse método não seja chamado eu devo quebrar meu teste, pois isso seria um comportamento indesejável.

Porque usar mocks?

Ao contrário do que muita gente pensa o uso de mocks não é um bicho de 7 cabeças, é bem simples. Na verdade testar é algo simples, desde que você tenha domínio do ferramental e os mocks são realmente úteis em diversos casos.

Imagina que o seu sistema precise fazer consultas a uma api publica do Yahoo e para isso você tenha criado uma classe de consultas. Você não vai querer(nem o Yahoo vai gostar) ir lá no servidor toda vez que você rodar os seus testes. Isso tornaria os seus testes lentos e impossível roda-los offline. Nesse caso você resolve seu problema "mockando" essa classe.

Como Testar parte 1 - Models

Marcos Tapajós — Sun, 26 Oct 2008 02:51:35 -0200

Quando comecei a estudar Extreme Programming descobri que não é possível fazer nenhum software de qualidade sem uma excelente base de testes. Desde então tenho me dedicado muito ao estudo das mais diversas ferramentas e técnicas para elaborar bons de testes.

O assunto testes é bastante polêmico e não pretendo (nesse post) tentar convencer ninguém da importância deles. Se você não faz testes e/ou discorda de qualquer uma das minhas afirmações deixo algumas perguntas para você refletir.

1 - Quantos bugs fixes você fez esse ano?

2 - Quantos tickets abertos existem no seu bug tracker?

3 - Quantas vezes você fez um deploy de uma nova versão em uma sexta feira de tarde e saiu mais cedo do trabalho?

4 - Quantas vezes você "virou a noite" esse ano?

Acabei me tornando um evangelizador de testes porém nunca fiz nada muito prático para passar o conhecimento que eu adquiri para a comunidade. Só que agora vou me redimir dessa falha iniciando uma série de posts onde vou expor um problema e como EU testaria usando Test::Unit e Rspec. Não vou falar de Shoulda pois não gosto dele. :-)

A idéia de escrever essa série de posts sobre testes surgiu logo após a gravação do terceiro episódio do RailsBox e gostaria de agradecer ao Ozeias e ao Davis Cabral por terem me motivado.

"Back to the cold cow..."

O ActiveRecord simplifica muito nossos modelos porém tenho observado que em vários projetos os desenvolvedores deixam de testar corretamente os seus modelos usando a alegação que não vão testar alguma coisa que o Rails já testou. Esse é um argumento valido em alguns casos pois você está apenas delegando responsabilidades mas você sempre deve testar se a responsabilidade foi realmente delegada.

Um exemplo clássico são as validações. Teoricamente você não precisaria testar como elas são implementadas mas deve testar se elas realmente existem pois se alguém remove-las seus testes vão continuar passando mas sua aplicação estará quebrada e/ou permitindo inconsistências de banco de dados.

Nesse post vou mostrar como testar alguns comportamento do ActiveRecord usando como base o modelo User. Todos os códigos citados nesse post fazem parte de um projeto How Test que está disponível em: http://github.com/tapajos/how-test

class User < ActiveRecord::Base
  validates_presence_of :name
  validates_format_of :mail, 
                      :with => /([-.\w^@]+@(?:[-\w]+.)+[A-Za-z]{2,4})+/i,
                      :on => :create,
                      :allow_nil => true
  has_many :accounts
  named_scope :actives, :conditions => ["active = ?", true]
end

Uma boa estratégia para orientar o desenvolvimento dos teste é elaborar algumas perguntas que darão origem aos seus cenários de testes.

Validação do nome

Posso cadastrar um usuário sem nome? Não

Testando usando Test:Unit:

def test_if_check_presence_of_name
  assert !@user.valid?, "Should be invalid"
  assert_equal "can't be blank", @user.errors[:name]
end

Na primeira linha desse teste o assert recebe um segundo parâmetro que por ser opcional não é muito comentado mas merece uma atenção especial. Esse argumento nada mais é do que a mensagem que será exibida quando o teste quebrar. Quando você omite esse parâmetro o teste quebra exibindo a mensagem 'false is not true' que não ajuda muito a entender o que está acontecendo.

Testando usando RSpec:

it "should reject if name is not given" do
  @user.should have(1).error_on(:name)
  @user.errors[:name].should == "can't be blank"
end

Validação do e-mail.

Posso criar um registro com um e-mail inválido? Não
Posso atualizar um regitro com um e-mail inválido? Sim
Posso criar um registro com um e-mail em branco? Sim

Testando usando Test:Unit:

VALIDS_MAIL = %w(foo@bar.com foo@bar.com.br foo@globo.com foo@i_hate_the_microsoft.com foo@i_love_my_mac.com)
INVALIDS_MAIL = %w(foobar.com foo@bar i_hate_the_microsoft.com i_love_my_mac.com)

def test_if_reject_invalid_format_os_mail_on_create
  INVALIDS_MAIL.each do |mail|
    @user.mail = mail
    assert !@user.valid?, "Should be invalid when mail is #{mail}"
    assert_equal "is invalid", @user.errors[:mail]
  end
end

def test_if_not_reject_when_mail_is_nil
  @user.name = "Tapajós"
  assert @user.valid?, "Should be valid"
end

def test_if_not_check_format_of_mail_on_update
  @user.name = "Tapajós"
  assert @user.save, "Should save"
  @user.mail = "an invalid mail"
  assert @user.valid?, "Should be valid"
end

def test_if_accept_a_valid_mail
  VALIDS_MAIL.each do |mail|
    @user.name = "Tapajós"
    @user.mail = mail
    assert @user.valid?, "Should be valid when mail is #{mail}"
  end
end

Testando usando RSpec:

INVALIDS_MAIL.each do |mail|
  it "should reject because #{mail} is an invalid mail" do
    @user.mail = mail
    @user.should have(1).error_on(:mail)
    @user.errors[:mail].should == "is invalid"
  end
end

VALIDS_MAIL.each do |mail|
  it "should be valid when mail is #{mail}" do
    @user.mail = mail
    @user.should_not have(1).error_on(:mail)
  end
end

it "should not reject if mail is not given" do
  @user.name = "Tapajós"
  @user.should be_valid
end

it "should not check mail format on update" do
    @user.name = "Tapajós"
    @user.save.should be_true
    @user.mail = "an invalid mail"
    @user.should be_valid
end

Testando o relacionamento com Account.

Um usuário pode ter mais de uma conta? Sim

Testando usando Test::Unit:

def test_has_many_accounts
  association = User.reflect_on_association(:accounts)
  assert association, "Association with account is not found"
  assert_equal :has_many, association.macro
end

Testando usando RSpec:

it "should has many accounts" do
  association = User.reflect_on_association(:accounts)
  association.should_not be_nil
  association.macro.should == :has_many
end

Testando o User.actives

Posso listar usuários inativos? Não

Testando usando Test::Unit:

def test_if_actives_use_the_correct_conditions
  assert_equal({:conditions=>["active = ?", true]}, User.actives.proxy_options)
end

Testando usando RSpec:

it "should find for all users that status of active is true" do
  User.actives.proxy_options.should == {:conditions=>["active = ?", true]}
end

Para esse post ficar mais simples e curto não me preocupei em validar se o tamanho máximo dos campos está coerente com o tamanho máximo permitido pelo tipo no banco de dados. Essa é uma validação EXTREMAMENTE importante que não deve ser esquecida!

No próximo post dessa série falarei um pouco sobre a Lei de Demeter, como respeita-la e testar alguns métodos usando Mock Objects.

O que você achou desse artigo? O que você gostaria de saber sobre testes de ActiveRecord que eu não falei aqui?

Aguardo o feedback de vocês.

Mais uma gem no Brazilian Rails

Marcos Tapajós — Tue, 23 Sep 2008 23:20:36 -0300

O Brazilian Rails acabou de ganhar uma gem para lidar com CPF e CNPJ desenvolvida pelo Cássio Marques. Ele fez um post no seu blog explicando como utilizar.

http://tinyurl.com/cpfcnpj

Além dessa nova gem a versão 2.0.8 do Brazilian Rails recebeu algumas pequenas correções feitas pelo Akita e pelo Sergio Brant.

Gostaria de agradecer aos três pelas colaborações.

Integration Plugin com GIT

Marcos Tapajós — Wed, 25 Jun 2008 20:31:35 -0300

Agora o Integration Plugin suporta GIT!

Desde o lançamento do Integration Plugin eu tinha a sensação que faltava o suporte ao GIT porém como o plugin foi extraído dos nossos códigos e não usávamos esse SCM ele foi lançado assim mesmo.

Logo depois o Eduardo Fiorezi me enviou um patch adicionando esse suporte e posteriormente o suporte ao git-svn só que eu não aceitei de imediato pois faltava documentar e eu estava completamente sem tempo para isso. Só que hoje recebi um patch do Sylvestre Mergulhão atualizando a documentação.

Obrigado aos dois!

Brazilian Rails no github

Marcos Tapajós — Tue, 22 Apr 2008 15:33:13 -0300

Acabei de terminar a migração do plugin Brazilian Rails para o github. Achei que ia ser bem mais complicado do que foi ! :-)

Nós decidimos manter o SVN como um espelho (por um tempo) para facilitar a instalação nas versões anteriores a Rails Edge. Agora existem duas formas de instalação que estão detalhadas na página do plugin.

Para quem quiser acompanhar o projeto a url no github é:

http://github.com/tapajos/brazilian-rails

Nova Página para o Brazilian Rails

Marcos Tapajós — Tue, 25 Mar 2008 19:47:57 -0300

Hoje o Brazilian Rails ganhou um site um pouco mais bonitinho com um design igual ao do nosso outro plugin.

Na verdade esse é um template, de autoria do Leandro, que será usado em todos os nossos plugins. Só não está mais bonito pois resolvi meter a mão e me antecipar ao Leandro.

Brazilian Rails: Patch aceito.

Marcos Tapajós — Tue, 25 Mar 2008 05:44:23 -0300

Como sempre estou atrasado e só hoje vi alguns patch no Brazilian Rails.

Patch #17896 - usar_como_dinheiro não funciona com audit.

O Sylvestre Mergulhão identificou uma incompatibilidade do plugin com o audit que não fazia log das colunas mapeadas com o usar_como_dinheiro. O patch que ele enviou já foi aceito.

Patch #18822 - Criação de metodos para que o select_estado funcione com o form_for.

Esse patch foi enviado pelo Rafael Cardoso e é bastante pertinente só que não foi aceito ainda pois o patch foi gerado de forma incorreta. Ele já fez contato comigo e vai enviar o patch correto em breve.

Queria agradecer aos dois pela colaboração constante. Já perdi a conta de quantas vezes aceitei código deles.

Ruby on Rails Integration Plugin

Vinicius Manhães Teles — Wed, 12 Mar 2008 22:31:31 -0300

Continuous Integration is a very important practice for us. The problem is that we never liked the way it's done most of the time, using a server such as Cruise Control. So we prefer to do what we call a synchronous continuous integration. James Shore wrote some time ago exactly what we've always felt about the Cruise Control approach.

All of our projects have a set of automations in place that help us on the integration process. Since our very first Rails project, we've been using some rake tasks to integrate our projects. They've been evolving so far and last week we decided to refactor them, polish and publish as a Rails plugin called Integration.

Integration is an almost paranoid set of integration tasks that will help you maintain your projects healthy and your repository clean. Once you've installed it, all you have to do is run the command below whenever you want to integrate some code:

rake integrate

Ok, let's be honest here. You'll probably need to configure a few things. Read the project page and you should be fine. If you manage to use all the tasks in your project, let us know. Somehow, we believe this won't happen very often... You'll see! :-)

Go ahead. Checkout the Integration plugin.

Brazilian Rails - Demorou mas agora foi !

Marcos Tapajós — Sat, 08 Mar 2008 13:43:00 -0300

Depois de muito tempo(ou falta de tempo) resolvi solucionar alguns bugs reportados no plugin.

Quem quiser saber de mais detalhes sobre os bugs pode dar uma olhada lá na página do projeto no RubyForge. Vou apenas listar as repostas que eu dei a cada um deles.

Bug 17663 - Inclusão da validação less-than-or-equal-to

Regis, realmente estava faltando essa messagem. Já foi adicionada. Obrigado.

Bug 17664 - Pluralização correta para 'mail' e 'email'

Regis, realmente estava faltando essa regra. Já foi adicionada. Obrigado.

Bug 17439 - Atributos possuem gênero, fazendo com que alguns erros apareçam com erros de concordância.

Lucas, não foi possível aceitar seu patch pois ele não está acompanhado de testes. Umas das nossas restrições com relação a patch e novas funcionalidades é que todas devem ser acompanhada de testes. Entretanto o problema que você relatou é realmente relevante e por isso mesmo deixarei o bug em aberto para que, quando possível, algum dos desenvolvedores corrija. Caso seja do seu interesse evoluir seu código para virar um patch que atenda as exigências do projeto a equipe estará a disposição para te ajudar no que for necessário.

Bug 18022 - Conflito de plugin.

Realmente confirmei que existe essa incompatibilidade. Não analisei mais a fundo o problema mas ao que me parece o plugin ActiveScaffoldLocalize modifica a forma como as validações são armazenadas e seus usos. Como apenas traduzimos, sem mudar nada, temos problemas sempre que o nosso plugin é iniciado após o ActiveScaffoldLocalize. Estou analisando a melhor forma de solucionar esse problema. Com relação ao link no Readme ele está correto. O segundo link nessa sua mensagem está errado pois o protocolo usado não é o http. O link correto é o do Readme (svn://rubyforge.org/projects/brazilian-rails/).

Bug 18077 - usar_como_dinheiro

O usar_como_dinheiro foi planejado para funcionar com o Active Record. Ele utiliza coisas específicas do Active Record, como, por exemplo, as validações. Para utilizar em modelos que não tem herança do Active Record é necessário fazer uma nova implementação que no momento não está planejada mas quem sabe num futuro próximo possa ser feita.

Gostaria de agradecer a todos pelo feedback mas em especial ao Regis que mandou duas soluções prontas. Prometo tentar responder mais rapidamente.

Plugin Brazilian Rails atualizado

Marcos Tapajós — Sat, 22 Dec 2007 05:08:00 -0200

O Vinícius e o pessoal do Lucidus, andaram corrigindo alguns comportamentos indesejáveis na classe dinheiro quando ela era usada em composição no Active Record. Agora o método usar_como_dinheiro tem o mesmo comportamento das composições com Date.

Além disso o Rafael e o Sylvestre identificaram um comportamento que apesar de não ser um bug não fazia muito sentido. Quando um dinheiro era comparado com alguma coisa que não era Dinheiro ele lançava uma exceção ao invés de retornar false. Esse é um comportamento que foge ao padrão do Ruby. Normalmente em Ruby objetos diferentes podem ser comparados e o retorno será false. Exemplos:

"a" == Date.today
false
"a" == 1
false
"a" == Dinheiro.new(1)
false

Como estou preso no aeroporto de Curitiba, sem nada para fazer, acabei de aplicar o patch que eles enviaram. Obrigado pessoal !

Rails for Kids 2007

Vinicius Manhães Teles — Mon, 29 Oct 2007 09:29:00 -0200

Os eventos de Rails estão chegando. Agora é hora de divulgar a iniciativa do Carlos Eduardo, da e-Genial. Ele está promovendo o Rails for Kids 2007, que acontecerá no dia 15 de dezembro de 2007 a partir das 9h.

O Rails for Kids 2007 é uma maratona de palestras online sobre Ruby e Ruby on Rails via Treina TOM, que contará com os seguintes palestrantes:

Carl Younblood - Surgeworks LLC (EUA)
Demetrius Nunes
Eduardo Fiorezi
Fabio Akita
Rodrigo Urubatan
Ronaldo Ferraz
Shairon Toledo
Vinicius Manhães Teles

O evento será beneficente e será cobrado uma pequena taxa de R$25,00. Todo dinheiro ganho será doado para a Cotolengo MS, instituição que cuida de portadores de necessidades especiais de qualquer idade.

Em breve o Carlos irá lançar o site do evento com mais detalhes, então fique atento!

Segundo Seminário Ruby on Rails

Vinicius Manhães Teles — Thu, 20 Sep 2007 09:33:00 -0300

No dia 27 de outubro ocorrerá o Segundo Seminário Ruby on Rails, em São Paulo. Mais uma vez, o evento será promovido pela Tempo Real Eventos e contará com ótimas apresentações de pessoas que estão usando o Ruby on Rails para valer.

Na parte da manhã teremos o TaQ e o Ronie falando sobre o que aconteceu no mundo Ruby e Rails do ano passado para cá. Depois um tutorial no melhor estilo "show me the code", promovido pelo pessoal da Dextra. A manhã encerra com a apresentação de posters. Aliás, essa é uma idéia bacana.

Nesse ano os organizadores querem mostrar ao público o máximo de cases, para que as pessoas saibam o que vem sendo feito com o Rails no Brasil. Se você quiser apresentar o seu case, veja o que fazer.

A parte da tarde começa com a apresentação do Projeto Lucidus, que será feita por mim e outras pessoas da equipe. Haverá também apresentação de outros posters, o Carlos Eduardo, falará sobre o case da e-Genial e o Ronaldo Ferraz vai falar da Bitbucket.

Acredito que esse será um ótimo evento, ainda melhor que o do ano passado. Nós da Improve It iremos comparecer em massa e estamos ansiosos para participar e conhecer algumas pessoas com as quais convivemos no mundo virtual, mas nunca tivemos a chance de conhecer pessoalmente, como o Carlos Eduardo, o Ronaldo Ferraz, entre outros.

Plugin Brazilian Rails atualizado.

Marcos Tapajós — Mon, 03 Sep 2007 07:04:00 -0300

Acabei de atualizar o plugin Brazilian Rails adicionando uma classe para lidar com dinheiro.

No plugin existe um arquivo com os exemplos de como usar cada uma dessas novas funcionalidades.

XP: melhor em Java ou em Ruby?

Vinicius Manhães Teles — Thu, 23 Aug 2007 04:22:00 -0300

Alan Kloh e Rodolfo Burla foram meus alunos na UFRJ em 2006. Esse ano, para encerrar a graduação, eles fizeram um Projeto de Fim de Curso que comparou Java e Ruby sob o ponto de vista das práticas do XP.

Eles desenvolveram duas versões de um mesmo sistema, uma em Java e outra em Ruby. A partir daí, fizeram um comparativo entre a facilidade de adoção das práticas do XP no desenvolvimento de cada versão. Além do comparativo, o trabalho também apresenta aspectos interessantes de cada linguagem, bem como seus pontos fortes e fracos.

Alguns resultados interessantes:

Linhas de código em Java: 665. Linhas de código em Ruby: 78. Portanto, foram necessárias 8,5 vezes mais linhas de código em Java.
Linhas nos arquivos de configuração em Java: 449. Linhas nos arquivos de configuração em Ruby: 23. Foram necessárias 19,5 vezes mais linhas de configuração em Java! Detalhe importante: A quantidade de linhas de configuração em Java foi 5,7 vezes maior que a quantidade de linhas de código em Ruby!

Para conhecer o trabalho, baixe o arquivo com o projeto de fim-de-curso: Comparativo entre as linguagens de programação Java e Ruby para projetos que utilizem Extreme Programming.

Problema no Brazilian Rails corrigido.

Marcos Tapajós — Thu, 02 Aug 2007 18:59:00 -0300

Uma das nossas premissas é que o nosso plugin nunca deve conflitar com o padrão do Rails, ou seja, uma aplicação já em funcionamento deve ser capaz de instalar o plugin e não parar de funcionar.

Essa preocupação surgiu quando ao modificar o to_s da classe Date minha aplicação parou de funcionar já que eu esperava um formato diferente de "%d/%m/%Y". Resolvi criando um outro método chamado to_s_br e mantendo o to_s original.

Hoje o Kristopher Murata me chamou a atenção para um problema, que ontem mesmo eu tinha notado e comentado com o Celestino Gomes, que o nosso plugin estava quebrando essa nossa premissa ao modificar as regras de pluralização do Rails.

Para corrigi esse problema eu retirei uma linha do init.rb do plugin deixando a inclusão dessa funcionalidade opcional através da adição de uma linha ao enviroment.rb

Gostaria de agradecer o feedback do Kristopher.

Plugin Brazilian Rails Atualizado

Marcos Tapajós — Tue, 31 Jul 2007 18:55:00 -0300

Acabei de atualizar o plugin Brazilian Rails adicionando ao método to_date da classe String a capacidade de lidar com datas no formato "DD/MM/AAAA".

A classe Date recebeu um método chamado to_s_br que gera uma string com a formatação "DD/MM/AAAA".

Foi criado o método estático valid? na classe Date para validar os formatos da data e o seu conteúdo.

No plugin existe um arquivo com os exemplos de como usar cada uma dessas novas funcionalidades.

Atualizado em 31/07/2007 às 22:46

Também foram adicionadas as traduções para os nomes do meses e dos dias e suas respectivas abreviações.

Improvecast 9: Entrevista com Carlos Eduardo na Série Ruby on Rails

Vinicius Manhães Teles — Fri, 13 Jul 2007 14:07:00 -0300

Acaba de ser publicado o Improvecast 9 no qual entrevistei Carlos Eduardo, da e-Genial. Conversamos sobre desenvolvimento de aplicações RIA (Rich Internet Applications) utilizando Ruby on Rails e Flex.

Também falamos sobre a experiência de trabalhar em casa, longe dos grandes centros e do ambiente de aprendizagem Treina TOM, desenvolvido pela e-Genial. O Carlos é uma figura muito conhecida e querida na comunidade brasileira de desenvolvimento Rails e Flex. Já escrevemos sobre ele em duas ocasiões: aqui e aqui.

Esses foram alguns dos assuntos tratados no podcast:

O que é a e-Genial e em que áreas ela atua?
O que o levou a adotar o Rails?
O que é o Adobe Flex?
O que o levou a adotar o Flex?
O que é um Adobe Community Expert e como você te tornou um?
O que é o Treina Tom?
Como está sendo o resultado da primeira turma do Curso de Flex e Ruby on Rails?
Como é trabalhar em casa, com sua esposa, em Chapadão do Sul, longe dos grandes centros?
Quais os aspectos positivos dessa abordagem?
Quais as dificuldades que essa abordagem de trabalho traz?
Planos para o futuro e novos produtos.

Ao final da conversa, anunciamos uma novidade. Na sexta-feira da próxima semana, dia 20 de julho de 2007, às 20:30h, farei uma palestra gratuita sobre Extreme Programming através do Treina TOM:

Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade.

Para participar da palestra, você deverá acessar o Treina TOM no dia do evento, através desse link. Vale lembrar que hoje (13/07/2007), às 20:30h, é dia da palestra gratuita do Fábio Akita no Treina TOM. O tema é: JRuby, o melhor de dois mundos. Para quem não conhece, Fábio Akita é autor do excelente Repensando a Web com Rails, que é uma das principais referências sobre Rails no Brasil.

Plugin Brazilian Rails Atualizado

Marcos Tapajós — Sun, 08 Jul 2007 15:33:00 -0300

Acabei de atualizar o plugin Brazilian Rails adicionando ao modulo Inflector algumas regras de formação de plural para o português.

Plugin Brazilian Rails

Marcos Tapajós — Fri, 06 Jul 2007 21:30:00 -0300

Acabei de publicar no RubyForge a primeira versão do plugin Brazilian Rails.

Desde que eu comecei a programar em Ruby, usando o Ruby on Rails, sempre adorei o sistema de plugins, onde facilmente podemos incorporar novas funcionalidades que atendem a vários projetos.

Sempre tive vontade de colocar nossos códigos disponíveis como plugins mas nunca tive tempo para fazer isso. Inevitavelmente continuo sem tempo mas agora estou contando com um time de amigos que resolveram me ajudar. São eles:

André Luiz Kupkovski (Ancar)
Celestino Ferreira Gomes (Ancar)
Rafael Fraga Walter (Ancar)
Fernando João Manfroi (Ancar)
Luciene Souza Luna (Ancar)

Esse plugin surgiu da necessidade de usar o método error_messages_for para sinalizar na camada de vista os erros encontrados nas validações do nosso modelo. Essas mensagens eram em inglês, o que fazia com que os desenvolvedores tivessem que implementar algo semelhante no RHTML.

Acabamos notando que várias outras coisas poderiam ficar mais simples aos brasileiros usando-as como estamos acostumados. Por exemplo, nosso formato padrão de data é DD/MM/AAAA mas Ruby não trabalha da mesma forma. Para solucionar esse problema fizemos uma implementação que modifica o método to_date do modulo String para lidar com esse nosso formato.

Esse nosso primeiro release não abrange todas as nossas implementações mas resolvemos publicar o quanto antes para poder contar com o feedback dos nossos usuários e melhorar continuamente.

Trata-se de um projeto Open Source, onde gostaríamos de contar com a colaboração da comunidade Brasileira com sugestões e quem sabe com novos desenvolvedores. Minha única exigência com relação aos patches é que eles venham acompanhados de testes.

Quem quiser experimentar nosso plugin basta executar uma única linha e reiniciar sua aplicação Rails.

script/plugin install -x \
svn://rubyforge.org/var/svn/brazilian-rails

Como temos vários tipos de códigos diferentes devemos fazer outros plugins em breve !

Fotos, fotos e mais fotos

Vinicius Manhães Teles — Wed, 30 May 2007 23:25:00 -0300

Aqui na Improve It temos inúmeras fotos dos projetos XP em que estivemos envolvidos e dos treinamentos que realizados. Há muito tempo que queríamos colocá-las no site. Mas, como fazer isso de forma prática? Afinal, são centenas de fotos e esse número cresce semanalmente.

Um dos desafios é encontrar uma forma de fazer upload facilmente. Usar uma página com upload de arquivos é muito chato. Além disso, demora demais. Revolvemos pesquisar as melhores soluções em armazenamento de fotos na web e, inevitavelmente, analisamos o Flickr.

Felizmente descobrimos que o Flickr não apenas resolve esse problema, mas também o faz de maneira excepcional. Ele disponibiliza várias ferramentas desktop para upload de fotos, que tornam o processo bastante rápido.

Para melhorar as coisas ainda mais, o Flickr disponibiliza uma ampla API, que permite que integremos nosso site com seus serviços. Obviamente há várias formas de usar essa API em Ruby. Então, escolhemos uma e colocamos a integração para funcionar. Agora, você já pode conferir o resultado.

Nessa página, estão os albuns que criamos no Flickr. Toda vez que criarmos novos albuns por lá, essa página será atualizada automaticamente. Por enquanto, temos apenas alguns poucos albuns, mas, com o mecanismo no ar, começaremos a colocar mais e mais fotos nos próximos dias. A propósito, você também pode ver nossas fotos diretamente no Flickr. Passe lá e deixe seus comentários! ;-)