anderson leite

As vezes para executar uma operação precisamos analizar diversos estados de um recurso, fazer diversas requisições, analizar parametros, etc. Tudo isso por nao termos a real informação do que é possivel fazer com aquele recurso no estado atual em que ele se encontra.

Se ao pedir por um recurso que se encontra em qualquer servidor web, o xml retornado fosse um pouco mais dinâmico, inteligente suficiente para fornecer não todas as possibilidades de operações que aquele recurso possui em diversos estados, mas sim aquelas possíveis no estado atual do objeto, então diversas requisições ou análises seriam poupadas, permitindo com certeza execurtar as operações que naquele momento realmente importam.

server-side

O servidor aqui é responsável por disponibilizar um xml do recurso solicitado, (o que o cliente vai fazer com essas informações veremos adiante). O rails já automaticamente consegue renderizar os dados básicos do objetos solicitado, teriamos normalmente alogo do tipo:

Mas queremos disponibilizar aqui um pouco mais de informações. Um pedido pode ter sido pago ou não. Isso caracteriza o estado dessa informação, que muda totalmente o que podemos fazer com esse recurso.

Se o pedido já foi pago, podemos por exemplo liberar a funcionalidade de envia-lo para os correios, enquanto se ele não foi pago ainda não podemos liberar essa funcionalidade.

Isso é uma máquina de estados, determindos estados podem ser atingidos dependendo do estado atual do recurso.

Supondo que nosso pedido já foi pago e que é possível chamar a ação de despachar para os correios seria ideal que o xml retornado tivesse um pouco mais de informações, como por exemplo:

Ou seja, o cliente tem no xml recebido todas as informações necessarias sobre o que pode fazer com aquele recurso naquele momento, evitando por exemplo requisições desnecessárias ao servidor ou mesmo chamadas erradas de metodos.

E como defino esses estados ?

Obviamente o Rails não gera essa informação a mais que queremos no xml e é ai que entra o Restfulie. O Restfulie sobrescreve a geracao do xml padrão do Rails, adicionando informações em tempo real sobre o estado do objeto solicitado.

Tutorial

Vamos criar nossa aplicacao para fazer o teste:
rails restfulie_server

Abra o arquivo config/environment.rb e adicione:

Atualize fazendo:
rake gems:install

Já temos uma aplicação base com a gem do Restfulie instalada. Precisamos do recurso “Pedido” para fazer os testes. Vamos criá-lo com scaffold para facilitar o exemplo:

script/generate scaffold pedido preco:float descricao:string status:string

Status ?

Esse é um campo obrigatório no Restfulie atualmente. Para definir o que seu recurso pode liberar em tempo real, ele precisa ter um status. Por exemplo, para liberar o “despachar” do nosso pedido o status dele deve ser “pago”.
O status de pago poderia ainda lberar outras acoes em cima do recurso, como baixar o estoque
por exemplo, tudo dependendo da sua regra de negócio.

Definindo o estado

O Restfulie vai procurar pelo método “following_transitions” para saber o que colocar no xml em tempo real. Abra o arquivo models/pedido.rb e adicione:

Pronto! É disso que precisamos para em tempo real saber quando é possível despachar ou não nosso pedido, a url http://servidor/pedido/1 deve agora mostrar o seguinte resultado:

Podemos executar no cliente a chamada a esse recurso. O Restfulie devolverá um objeto serializado contendo os métodos possíveis para aquele estado:

Ao chamar “p.despachar” a action despachar do PedidosController será executada.

Mais utilizações

Informação certa no momento certo, o recurso disponibiliza seu estado verdadeiro atraves do Restfulie. É possivel fazer uma série de configurações ainda no Restfuliepara deixar sua maquina de estados corretamente implementada, configurar actions que não são padrão, etc. Além disso a parte do client também é facilitada com o Restfulie, mas isso fica para um próximo post.

Todo mundo sabe dizer alguma coisa sobre Singletons. Singleton é ruim, singleton é anti-pattern. Mas como implemento um em Ruby e por que não deveria utilizá-lo?

O próprio Rails os utiliza por exemplo no ActiveSupport e em algumas tarefas do Rake. A motivação de um singleton está no fato de que algumas coisas são únicas.

Um singleton geralmente deixa pra própria classe gerenciar a criação do objeto. Antes de chegar na implementação do singleton vamos ver alguns comportamentos do ruby.

Uma variável com um ‘@’ é uma váriável de instância. Já uma variável com duas arrobas é uma variável de classe. Um método em ruby é da classe caso tenha o ’self’ antes.

Podemos criar uma instância e incrementar tanto a variável de classe como a variável de instância.
Ao instanciar uma segunda vez, a variável de classe se mantém e a de instância é obviamente ‘zerada’.

Utilizando a idéia acima podemos criar uma classe simples de log, onde desejamos que apenas uma seja de fato criada. Para isso definiremos o método ‘instance’ como método de classe que sempre retorna a mesma instancia da classe, guardada pela variável de classe “@@instance”

Quase funcionando, porém ainda poderíamos instanciar a classe de log…Pra evitar isso podemos usar o metodo ‘private_class_method’ passado como parâmetro méthodo ‘new’.

A implementação do singleton está completa. A classe cria apenas uma instância dela mesma, não permitindo nunca a criação de uma segunda.

Mas..e se fosse necessário mais um singleton na aplicação ? Teríamos que repetir esse processo inteiro.

O ruby fornece uma alternativa a isso que é incluir o módulo ’singleton’.

Uma chamada a Logger.instance devolve a uma única intância sempre da mesma maneira que a implementação anterior.

eager instantiation x lazy

Existe uma diferença entre o singleton que construímos e o módulo singleton do ruby.

Na nossa implementação do singleton a instância é criada antes de qualquer chamada a Logger.instance. Criar uma instancia antes mesmo antes que ninguém necessite é chamado de ‘eager instantiation’. Já a forma utilizada no módulo singleton espera pela primeira invocação para criar a instância, essa chamada é a conhecida como ‘lazy instatiation’.

Variáveis globais x Singletons

Podemos, por exemplo, utilizar uma variável global como singleton. E é aqui que o negócio começa a ficar feio. Em Ruby, qualquer variável iniciada com ‘$’ é global, você pode acessar de qualquer lugar. Portanto essa poderia ser uma boa implementação para singletons.

NÃO. Não existe nada que controle o calor da variável global nese caso como fizemos com o singleton, além das variáveis globais serem impossíveis de serem criadas antes(eager instatiation). Além disso não existem nada que garanta que essa variável não seja recriada e substituída em outro lugar.

É por isso que em ruby um singleton é implementado como um módulo. Como não é possível implementar um módulo seus métodos claramentes são criados para serem chamados sem permitir a criação de um objeto.

Agora nunca mais teremos mais de uma instância da classe Gerenciador. Ainda não… Ainda seria possível utilizar o método clone do Ruby.

Não que isso seja uma boa idéia, mas mostra como Ruby é uma linguagem onde praticamente tudo pode ser mudado em tempo de execução. A filosofia do Ruby é que se você decide que realmente precisa de uma implementação diferenta da craida anteriormente, a linguagem e permitirá isso, fica a seu critério e a sua responsabilidade.

Singleton: Anti-pattern

Um singleton sempre será basicamente uma variável única de escopo global. Com isso você cria um canal de comunicação direto entre qualquer classe com o singleton, deixando totalmente acomplado o relacionamento entre eles.

Outro problema é a dificuldade de se fazer testes unitários quando sua implementação se relaciona com um singleton. Como o estado pode sempre variar, seus testes terão ganho uma complexidade maior do que a necessária.

A recomendação então é: Não use singleton! Singletons propriamente aplicados são executados apenas uma vez, mas mesmo assim, não use singleton!

O Ceará on Rails é um evento organizado por Alisson Sales, Rafael Cruz Rubert, Tiago Bastos e Victor Sobreira em Fortaleza no campus da UNIFOR.

O campus é ótimo(2009), a estrutura para o evento muito boa. Na foto abaixo, Fábio Akita, Nando Vieira e Rafael Lima carregando seus macs em baixo de um cavalo.

Você pode acompanhar os twitts do evento pelo trend.me =>http://trendti.me/cearaonrails #cearaonrails

Pessoal no auditório do evento

Links: Fotos do evento, Slides da minha palestra

Há um tempo escrevi sobre Ruby Singleton Classes, já nesse post vou criar um plugin bem simples que facilita buscas no Rails e ver uma forma onde singleton classes podem ser úteis.

Atualmente pra fazer uma busca ordenada precisamos fazer algo como:

A partir do momento que instalarmos nosso plugin na aplicação poderemos fazer a busca dessa forma:

Nosso plugin não é nenhum idéia inovadora, mas sim uma necessidade ou problema onde precisaremos utilizar Singleton Classes. Vamos criar uma aplicação de exemplo para criar, instalar e usar o plugin:

Não vou colocar aqui toda a sequência para gerar a aplicação base, mas esse roteiro acima deve ajudar.

Agora vamos comecar a gerar nosso plugin, vamos chamá-lo de default_options.Para iniciar basta rodar => ruby script/generate plugin default_options

Rails plugins e Singleton classes

Agora é preciso adicionar um novo comportamento ao ActiveRecord, a necessidade do plugin é adicionar um método novo a base do ActiveRecord que mude seu comportamento padrão, para isso vamos utilizar Ruby Singleton Classes:

Esse codigo abre a classe Base do módulo ActiveRecord e podemos adicionar qualquer novo comportamento nele.

O objetivo agora é definir um comportamento default quando o método default_find_option for chamado.

Mas isso ainda não muda o comportamento do find, precisamos mesclar o find normal com os parametros passando pro nosso default_find_option. Pra isso vamos redefinir o find:

Quase bom, mas a chamada do find na última linha faz nosso código entrar em um loop infinito, vamos resolver isso da seguinte forma:

Agora podemos chamar nosso método adicionado ao ActiveRecord via plugin. Como teste podemos gerar alguns carrors com fixtures
(test/fixtures/carros.yml):

E rodar alguns testes pro nosso plugin (test/unit/carro_test.rb):

Não vou cobrir aqui como distribuir o plugin, isso fica pra um próximo post.