shadowmaru.org

A essa altura todos já sabem sobre a fusão de Rails e Merb, então não me dar ao trabalho de noticiar ou comentar.

O interessante agora vai ser ver exatamente o que de bom do Merb que o Rails vai ter na versão 3. O DHH já postou uma das mudanças e eu traduzo abaixo:

Trazendo provides/display do Merb para o Rails 3

O fluxo de idéias do Merb para o Rails 3 já está caminhando. Deixe-me mostrar um dos primeiros exemplos que estive trabalhando no design. Merb tem uma feature relacionada à estrutura do respond_to do Rails que funciona para os casos genéricos onde você tem um objeto ou coleção que você gostaria de servir em diferentes formatos. Aqui está um exemplo:

1
2
3
4
5
6
7
8
9

class Users < Application

  provides :xml, :json

  def index
    @users = User.all
    display @users
  end
end

Este controller pode responder a requisições html, xml e json. Quando display for executado, ele primeiro checará se existe um template disponível para o tipo requisitado, o que é normalmente o caso com HTML, e caso contrário tentará converter o objeto. Então @users.to_xml como resultado de uma requisição XML.

As aplicações em que eu trabalhei nunca tiveram realmente este caso, no entanto. Sempre tive que fazer mais do que apenas converter o objeto para o tipo ou renderizar um template. Ou eu precisava fazer um redirecionamento para um dos tipos em vez de renderizar ou eu precisava fazer outra coisa além de renderizar. Então eu nunca passei muito tempo com o caso default que já vem com os scaffolds:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class PostsController < ApplicationController

  def index
    @posts = Post.find(:all)

    respond_to do |format|
      format.html
      format.xml { render :xml => @posts }
    end
   end

  def show
    @post = Post.find(params[:id])

    respond_to do |format|
      format.html
      format.xml { render :xml => @post }
    end
  end
end

Corte duplicação quando possível, dê controle total quando não

Mas o caso da duplicação é definitivamente real para algumas classes de aplicações. E isso é muito feio. Os blocos respond_to se repetem para index, show e geralmente mesmo no edit. Isso é três vezes uma estrutura razoavelmente peso-pesada. Este é o caso em que provides/display vem a calhar e elimina a duplicação.

Para o Rails 3, nós queremos o melhor dos dois mundos. A estrutura completa do respond_to quando você precisa fazer coisas que não estavam na estrutura genérica, mas ainda ter a abordagem genérica na manga para quando as circunstâncias estiverem disponíveis para seu uso.

Lidando com simetria e expansão progressiva do design da API

Há algumas desvantagens na dupla provides/display, porém, que gostaríamos de lidar ao mesmo tempo. A primeira é a falta de simetria nos nomes dos métodos. As palavras “provides” e “display” não refletem o seu relacionamento próximo e se você ainda levar em conta o fato que eles estão realmente relacionados à renderização, a coisa fica ainda mais feia.

A simetria se relaciona com outro ponto no design da API que estive interessado ultimamente: expansão progressiva. Deveria haver um caminho suave do caso simples para o caso complexo. Deveria ser como um Ogro, ele deve ter camadas. Aqui está o resultado que chegamos:

1
2
3
4
5
6
7
8
9
10
11
12
13

class PostsController < ApplicationController
  respond_to :html, :xml, :json

  def index
    @posts = Post.find(:all)
    respond_with(@posts)
  end

  def show
    @post = Post.find(params[:id])
    respond_with(@post)
  end
end

Esse é o exemplo padrão de provides/display, mas ele tem a simetria no respond_to como método de classe, respond_with como método de instância, e os blocos originais respond_to. Então ele também parece progressivo quando você abre o respond_with e o transforma em um respond_to completo se você repentinamente precisa de diferenças por formato.

O design também estende o estilo de trabalhar somente em nível de instância sem os default de nível de classe:

1
2
3
4
5
6
7
8
9
10
11

class DealsController < SubjectsController

  def index
    @deals = Deal.all
    respond_with(@deals, :to => [ :html, :xml, :json, :atom ])
  end

  def new
    respond_with(Deal.new, :to => [ :html, :xml ])
  end
end

É bastante frequente que a action index tenha responsabilidades de formato diferentes do new ou do show ou de qualquer outra coisa. Esse design aborda todos esses cenários.

Yehuda também esteve interessado em melhorar a performance do respond_to/with ao eliminar os blocos necessários. Especialmente quando você está apenas usando respond_with que não precisa declarar bloco algum.

Levando em conta tudo isso, acho que este é um grande exemplo to tipo de funcionalidade superior que pode sair de idéias misturadas dos dois lados. Estamos certamente animados em fazer o mesmo truque em vários outros elementos do framework. Tenho explorado como um roteador revisado que importa as melhores idéias de ambos poderia ser. Escreverei sobre isso quando tiver algo real para compartilhar.

Como o Marcio Trindade falou no seu blog, implementei, junto com a equipe da DBurns Design, um e-commerce em Rails usando como base o Spree.

O Spree tem o básico para um e-commerce: produtos, carrinho de compras, checkout, pagamento por cartão de crédito (usando o ActiveMerchant) e taxonomias (categorização). O resto pode ser customizado por você mesmo usando extensões. No nosso caso, fizemos uma extensão para mudar todo o layout da loja, outra para as páginas de conteúdo usando o nosso CMS próprio, outra para imagens para imprensa, e adicionei uma extensão para busca feita pelo Edmundo Valle Neto. O site não está no ar ainda, mas deve estar em breve.

Durante o desenvolvimento do projeto, notei que faltavam algumas features que o cliente exigia: suporte a SSL e pagamentos através do Authorize.Net (até então suportava apenas Linkpoint e PayPal). No melhor espírito open source, postei na lista, o mantenedor (Sean Schofield) me pediu para implementar e o fiz. O Sean aprovou os patches e os incorporou ao projeto, portanto agora o Spree suporta pagamentos pelo Authorize.Net e SSL.

Hoje o Turbo Pascal completa 25 anos. Foi lançado em 20 de novembro de 1983 (duh). Pelo que pesquisei, foi a primeira IDE a ser lançada, pois além de editar os códigos, também compilava, debugava e gerava executáveis.

Foi com o Turbo Pascal que eu comecei a programar, quando entrei na faculdade (hoje em dia isso é considerado muito tarde), em 1995 (olhem só, justamente quando a Borland deixou de desenvolvê-lo, por causa do Delphi). A disciplina de Introdução à Computação (MAC-110) era dada em Pascal, e no laboratório do IME-USP (CEC) tínhamos o Turbo Pascal instalado para fazermos os EPs (exercício-programa).

Achei o Pascal uma linguagem bem fácil para aprender a programar (tanto que Niklaus Wirth a criou justamente para ensinar programação estruturada), por sua semelhança com o inglês, como é hoje o Ruby.

Depois do primeiro ano nunca mais programei em Pascal (nem em Delphi). Já passei por C, C++, Perl, Java, PHP, Ruby, até Cobol e Clipper, mas sempre vou lembrar do Turbo Pascal e sua interface no DOS, me matando para terminar os EPs até a hora da entrega :)

Tem alguma história sobre o Turbo Pascal? Comente aqui.