Posts de April, 2013

[Andrews Medina] a diferença entre atributos de classe e de instância

Monday, April 22nd, 2013

“Qual a diferença entre atributos de classe e de instância em Python?”

Essa é uma dúvida muito comum e bem simples de ser respondida. Mas, antes de repondê-la vou demonstrar o que é um atributo de classe e de instância.

atributo de classe

São atributos que são definidos diretamente a classe.

atributo de instância

São atributos definidos a instância, geralmente através do “self”, que representa a instância de uma classe.

Qual a diferença entre eles?

A diferença é que atributos de classes são compartilhados por todas as instâncias daquela classe. Atributos de instancia são únicos para cada instância.

Por exemplo, todas as modificações feitas na lista “l” da classe “C” afetara a lista para todas as instâncias de “C” pois “l” é um atributo da classe.

Já com as instâncias da classe “D” isso não ocorre pois “l” é um atributo de instância, sendo único para cada instância de “D”:

É importante conhecer esse comportamento para não ter resultados inesperados ao construir uma classe.

[Andrews Medina] try.tsuru.io

Friday, April 12th, 2013

Nós da equipe do PaaS da globo.com estamos lançando o try.tsuru.io como private beta com o objetivo de ser uma maneira fácil das pessoas conhecerem e experimentarem o tsuru.

Com o tsuru, times e desenvolvedores não precisam se preocupar com servidores ou em como executar o deploy, eles podem focar no mais importante: a aplicação.

Com ele é possível escrever aplicações na linguagem da sua escolha, usar serviços como banco de dados SQL ou NoSQl, memcacehd, redis e plugá-los a sua app.

Você gerencia sua app usando a linha de comando ou uma interface web e faz o deploy via git. Tudo isso sendo executado pela infra estruturua do tsuru.

O tsuru é um projeto open source se você quiser conhecer o código, montar seu próprio Paas usando o tsuru, contribuir ou sugerir features/reportar bugs sinta-se a vontade.

[Francisco Souza] Try out Tsuru: announcing limited preview

Thursday, April 11th, 2013

A few days ago, Tsuru got some attention in the news. After reading about Tsuru, and seeing some of its capabilities, people started asking for a way to try Tsuru. Well, your claims were attended! We’re preparing a public cloud that will be freely available for beta testers.

TL;DR: go to tsuru.io/try, signup for beta testing and get ready to start deploying Python, Ruby, Go and Java applications in the cloud.

What is Tsuru?

Tsuru is an open source platform as a service that allows developers to automatically deploy and manage web applications written in many different platforms (like Python, Ruby and Go). It aims to provide a solution for cloud computing platforms that is extensible, flexible and component based.

You can run your own public or private cloud using Tsuru. Or you can try it in the public cloud that Globo.com is building.

What is Tsuru public cloud? What does “beta availability” means?

Tsuru public cloud will be a public, freely available, installation of Tsuru, provided by Globo.com. “Beta availability” means that it will not be available for the general Internet public.

People will need to subscribe for the beta testing and wait for the confirmation, so they can start deploying web applications on Tsuru public cloud.

Which development platforms are going to be available?

Tsuru already supports Ruby, Python, Java and Go, so it is very likely that these platforms will be available for all beta users.

It’s important to notice that adding new platforms to Tsuru is a straightforward task: each development platform is based on Juju Charms, so one can adapt charms available at Charm Store and send a patch.

How limited is it going to be?

We don’t know what’s the proper answer for this question yet, but don’t worry about numbers now. There will be some kind of per-user quota, but it has not been defined yet.

People interested in running applications in the Tsuru public cloud that get to use the beta version will have access a functional environment where they will be able to deploy at least one web application.

When will it be available?

We’re working hard to make it available as soon as possible, and you can help us get it done! If you want to contribute, please take a look at Tsuru repository, chose an issue, discuss your solution and send your patches. We are going to be very happy helping you out.

What if I don’t want to wait?

If you want an unlimited, fully manageable and customized installation of Tsuru, you can have it today. Check out Tsuru’s documentation and, in case of doubts, don’t hesitate in contacting the newborn Tsuru community.

[Francisco Souza] Try out Tsuru: announcing limited preview

Thursday, April 11th, 2013

A few days ago, Tsuru got some attention in the news. After reading about Tsuru, and seeing some of its capabilities, people started asking for a way to try Tsuru. Well, your claims were attended! We’re preparing a public cloud that will be freely available for beta testers.

TL;DR: go to tsuru.io/try, signup for beta testing and get ready to start deploying Python, Ruby, Go and Java applications in the cloud.

What is Tsuru?

Tsuru is an open source platform as a service that allows developers to automatically deploy and manage web applications written in many different platforms (like Python, Ruby and Go). It aims to provide a solution for cloud computing platforms that is extensible, flexible and component based.

You can run your own public or private cloud using Tsuru. Or you can try it in the public cloud that Globo.com is building.

What is Tsuru public cloud? What does “beta availability” means?

Tsuru public cloud will be a public, freely available, installation of Tsuru, provided by Globo.com. “Beta availability” means that it will not be available for the general Internet public.

People will need to subscribe for the beta testing and wait for the confirmation, so they can start deploying web applications on Tsuru public cloud.

Which development platforms are going to be available?

Tsuru already supports Ruby, Python, Java and Go, so it is very likely that these platforms will be available for all beta users.

It’s important to notice that adding new platforms to Tsuru is a straightforward task: each development platform is based on Juju Charms, so one can adapt charms available at Charm Store and send a patch.

How limited is it going to be?

We don’t know what’s the proper answer for this question yet, but don’t worry about numbers now. There will be some kind of per-user quota, but it has not been defined yet.

People interested in running applications in the Tsuru public cloud that get to use the beta version will have access a functional environment where they will be able to deploy at least one web application.

When will it be available?

We’re working hard to make it available as soon as possible, and you can help us get it done! If you want to contribute, please take a look at Tsuru repository, chose an issue, discuss your solution and send your patches. We are going to be very happy helping you out.

What if I don’t want to wait?

If you want an unlimited, fully manageable and customized installation of Tsuru, you can have it today. Check out Tsuru’s documentation and, in case of doubts, don’t hesitate in contacting the newborn Tsuru community.

[Tiago Peczenyj] Adding a ‘dry run’ capability to your Moose class with MooseX::Role::DryRunnable

Sunday, April 7th, 2013

A ‘dry run’ is a testing process where the effects of a possible failure are intentionally mitigated. For example, an aerospace company may conduct a “dry run” test of a jet’s new pilot ejection seat while the jet is parked on the ground, rather than while it is in flight. Or, in software development, we can change the behavior of some methods in order to test, like avoid change data into a database (logging the action instead).

There are many ways to implement this capability. For example, we can add an explicity return in each method and test some condition. I will show some options in this article and we will find how to use the module MooseX::Role::DryRunnable in our Moose classes (Perl).

One simple example in Perl, reading from an environment variable DRY_RUN.

1
2
3
4
5
6
7
package Foo;

sub bar {
  logger->debug("Foo::bar @_");
  return if $ENV{'DRY_RUN'};
  ...
}

(more…)

[Guilherme Garnier] Design patterns em Ruby – Decorators, Presenters e Exhibits

Tuesday, April 2nd, 2013

Ao criar um novo projeto Rails, o generator cria uma estrutura padrão de diretórios. Dentro de app, ele cria os diretórios models, controllers, views e helpers. Os três primeiros tem papéis bem definidos, mas mesmo assim há uma certa confusão quando surge algum arquivo “fora do padrão”.

Numa aplicação típica, um model geralmente estende a classe ActiveRecord::Base ou inclui um módulo, como Mongoid::Document, no caso do Mongoid, por exemplo, para mapear a estrutura do banco de dados. Além disso, o model contém as regras de negócio associadas a ele. O controller tem a responsabilidade de mapear a ação atual numa view – por exemplo, ao submeter um formulário para criação de um novo objeto, um controller típico renderiza uma view exibindo uma mensagem de sucesso, ou renderiza a mesma view do formulário com as mensagens de erro, caso haja algum. Já a view é responsável por exibir os dados correspondentes à página atual.

Essa estrutura básica funciona bem numa aplicação simples. O problema é quando a view começa a conter muita lógica. Por exemplo, uma view para exibir dados de um usuário poderia ser simples assim:

@usuario.nome

Porém, se o conteúdo muda dependendo do tipo de usuário (ex: usuário comum e admin), precisamos de um if dentro da view:

<% if @usuario.admin? %>
  admin
<% else %>
  @usuario.nome
<% end %>

Quando mais diferenças houver, mais complexa fica a view. Consequentemente, fica mais difícil de gerenciar. Além disso, normalmente fazemos testes unitários para o model e o controller, e testamos a view somente com testes de aceitação, que são muito mais lentos (é preciso carregar todo o ambiente, Rails, banco de dados, e dependendo do teste, abrir um browser). Fica impraticável testar todos os fluxos de uma view cheia de if’s usando testes de aceitação.

Uma solução comum no mundo Rails é usar os helpers. No exemplo acima, eu poderia ter o seguinte helper:

class UsuarioHelper
  def titulo_usuario(usuario)
    usuario.admin? ? "admin" : usuario.nome
  end
end

Isso deixa o código da view mais simples:

titulo_usuario(@usuario)

E, além disso, posso testar a lógica num teste unitário do helper. Mas essa solução também tem problemas: o helper não está associado diretamente ao objeto em questão. Isso ficou claro no exemplo acima, onde precisei passar o usuário como parâmetro para o método do helper. Isso se repetiria para cada método.

Uma boa solução para este caso é utilizar o design pattern Decorator. Para isso, criamos uma classe que recebe o model como parâmetro no construtor e implementa todos os métodos necessários para lógicas de visualização (ou seja, que não estão associados ao negócio e não devem ficar no model). Quando é chamado um método que não existe, o Decorator delega (daí o nome do padrão) a chamada para o model. Existem várias implementações para o Decorator, essa é uma das mais simples:

module Decorator
  attr_reader :model

  def initialize(model)
    @model = model
  end

  def method_missing(meth, *args)
    if @model.respond_to?(meth)
      @model.send(meth, *args)
    else
      super
    end
  end

  def respond_to?(meth)
    @model.respond_to?(meth)
  end

  def self.included(base)
    base.extend(ClassMethods)
  end

  module ClassMethods
    def decorate(object)
      if object.is_a? Enumerable
        object.map {|obj| self.new(obj)}
      else
        self.new(object)
      end
    end
  end
end

class UsuarioDecorator
  include Decorator

  def titulo
    @model.admin? ? "admin" : @admin.nome
  end
end

Desta forma, temos uma classe que recebe o model no construtor ou no método de classe decorate. A implementação do método titulo_usuario no Decorator ficou muito mais simples. Para utilizá-la, basta decorar o model no controller:

class UsuariosController
  def show
    @usuario = UsuarioDecorator.decorate(Usuario.find(params[:id]))
  end
end

A implementação da view fica assim:

@usuario.titulo

Em casos mais simples, o Decorator atende bem. Mas e quando temos uma página mais complexa, envolvendo diversos objetos? Precisaríamos criar um Decorator para cada model, e lembrar de decorar cada objeto na criação, assim como fizemos com o usuário no exemplo anterior. Outro problema é que podemos ter visualizações diferentes de um objeto em cada tela da aplicação. Como tratar este caso? Poderíamos criar métodos diferentes no Decorator, mas com o tempo o Decorator poderia virar um monstro. Outra opção é criar vários Decorators para aquele model, onde cada um se aplica a uma página. Ou podemos usar um outro padrão, o Presenter.

O Presenter é um padrão também conhecido por outros nomes, como View Object, mas na comunidade Ruby o nome Presenter se popularizou com um post de Jay Fields. O Presenter é muito parecido com o Decorator, mas envolve vários objetos. O contexto do Presenter é uma página específica da aplicação, e recebe como parâmetro todos os objetos necessários à exibição daquela página. Desta forma, toda a lógica de apresentação fica numa única classe. Segue um exemplo de uso do Presenter:

class PedidoPresenter
  def initialize(usuario, pedidos)
    @usuario = usuario
    @pedidos = pedidos
  end

  def titulo
    "Usuário #{@usuario.nome} - #{@pedidos.size} pedidos"
  end

  def links
    @pedidos.map { |pedido| link_to pedido.nome, pedido_url(pedido) }
  end
end

Ainda há uma outra opção além do Presenter, que foi apresentada no livro Objects on Rails. É o padrão Exhibit. A diferença em relação ao Presenter é que, enquanto o Presenter disponibiliza métodos para serem chamados pela view (como no exemplo acima), o Exhibit é responsável pela renderização. Para isso, ele precisa receber um contexto:

class Exhibit
  def initialize(obj, context)
    @obj = obj
    @context = context
  end

  def render_header
    @context.render :partial => "header", :locals => {:obj => @obj}
  end
end

Este contexto pode ser o view_context do controller:

class Controller
  def show
    @usuario = Exhibit.new(Usuario.find(params[:id]), view_context)
  end
end

Outra maneira de instanciar o Exhibit é através de um helper, como mostrado no livro The Rails View:

class Helper
  def exhibit
    Exhibit.new(Usuario.find(params[:id]), self)
  end
end

São muitos padrões que tem a mesma função: encapsular a lógica de visualização num único local, que seja facilmente testável. E qual é a melhor opção entre os três? A resposta depende da situação. Não adianta querer encontrar um padrão perfeito para todos os casos. Na minha opinião, o Decorator funciona bem em páginas mais simples, que envolvem apenas um model. Quando a página é mais complexa e envolve vários models, o Presenter e o Exhibit são mais adequados. E a diferença entre os dois é uma questão de gosto.

Links relacionados:

Posts relacionados:

  • Nenhum post relacionado

[Davidson Fellipe] Moving Wordpress to Jekyll

Monday, April 1st, 2013

Why migrate?

I just wanted to learn a new tool and improving design of website.

Motivation

Almost 3 years this website was powered using Wordpress. Since beginning of the year I was thinking about how convert this blog for a static site generator tool. So, on last weekend I put hands on editor to finish this project.

I had 2 options

Docpad?

DocPad is a framework that allowing for content management via the file system, this tool offer support to plugins that are used for rendering, and has static site generation. It’s built with Node and Express.js.

Jekyll-bootstrap?

Jekyll-bootstrap is very simple, have a minimal structure for blogs, and a static site generator. I chose this one.

New version

There version isn’t dependency on server-side, it’s just server delivery static files. Other services that I use are: Google Analytics (for statistics about users), Disqus (for comments), GitHub (version control).

biggest problems for migration

  • Keep the previous content
  • Keep the same URLs
  • Keep path of Images
  • Comments
  • Convert content for english

Keep the previous content

I migrate all posts from Wordpress, using Wordpress to Jekyll exporter. This tool is a WordPress plugin that converts all posts, pages, taxonomies, metadata, and settings to Markdown and YAML which can be dropped into Jekyll. Thanks Ben Balter for this nice job.

Keep the same URLs

I think about a simple navigation tree, with support for multiple languages, which in the end is like this:

  • Home
  • Blog * Posts (english and portuguese, on the sema page)
  • Talks (english and portugues, on the same page)
  • About

Comments

I wanted to keep current comments from Disqus, for this a will to continue use this tool. Jekyll-bootstrap has this feature.

Benefits

More simplicity for changes on code, more simplicity for users to read my blog, and the website is with a better speed. This is due to in the fact all my posts are static assets now. Now I write the posts using Markdown + HTML.