Em parceria com a New Relic, a Code School está oferecendo 48 horas de acesso gratuito a seu conteúdo.

É uma boa oportunidade para quem quer ver como os cursos são.

O link para acesso direto a promoção é: http://www.codeschool.com/free-weekend

De acordo com o site da code school, a oferta é valida apenas para os dias 25 e 26 de maio/2013.

Então vamos aproveitar essas 48 horas de aprendizado

Visão geral sobre a linguagem

Go Tour

Instalando e configurando um ambiente de desenvolvimento

Getting started

How to Write Go Code

Aprendendo sobre a linguagem

Effective Go

Apresentações

Let’s go

A linguagem de programação go

Livros

An introduction to programming in go

Programming in go

Learning go

The way to go

Novidades

http://www.reddit.com/r/golang

E para dúvidas, tem a lista de e-mail golang-nuts.

Espero que gostem

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.

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.

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.

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'};
  ...
}

In this example, the bar method change something in the database and my test is very simple, like a simple diff between log files. To test my application in dry run (to test in the product environment, for example, without a big risk), we can do this:

1

bash$ DRY_RUN=1 ./my-application.pl --other-options

Sounds good, for large systems, with a good number of modules, it can be a problem. For example, the method bar has two or three responsabilities: logging the parameters, doing the original job and do nothing if we are in the dry run state. This method is doing a lot of things, and I have the same code in multiple places. Lets think about reuse of this code, using OO principles.

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

package FooBase;

sub bar {
  ...
}

package Foo;
use base 'FooBase';

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

  my $self = shift;
  $self->SUPER::bar(@_);
}

Now it is interesting: my Foo class has just one job: dispatch (or not) the method call to FooBase (who knows our business rule). But we still have the problem of the same code in multiple places. Lets try to solve this with Aspect Oriented Programming, using Moose.

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

package Foo;
use Moose;

sub bar {
  ...
}

sub baz {
  ...
}

around [ qw(bar baz) ] => sub {
  my $orig = shift;
    my $self = shift;

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

  $self->$orig(@_)
}

Moose is a complete object system for Perl 5. Consider any modern object-oriented language (which Perl 5 definitely isn’t). It provides keywords for attribute declaration, object construction, inheritance, and maybe more. In this example, we can use the Method Modifier around and we can inject this new piece of code in one or more methods. But we still need add this hook in each class, this is why I create the MooseX::Role::DryRunnable.

Moose has a great number of features, like Roles. Roles have two primary purposes: as interfaces, and as a means of code reuse. In our example we can do this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

package DryRunnable;
use Moose::Role;

requires 'in_dry_run';
requires 'on_dry_run';

package Foo;
use Moose;
with 'DryRunnable';

sub bar {
  ...
}

sub baz {
  ...
}

sub is_dry_run {
  $ENV{'DRY_RUN'}
}

sub on_dry_run {
  logger->debug("Foo::bar @_")
}

around [ qw(bar baz) ] => sub {
  my $orig = shift;
    my $self = shift;

  $self->is_dry_run()
      ? $self->on_dry_run(@_)
      : $self->$orig(@_)
}

In this example, the role DryRunnable provides the basic infrastructure to add the dry run capability. Instead ask direclty to an environment variable I’m asking to a method ( is_dry_run ), and instead only log / return nothing we call another method to do this ( on_dry_run ). Using this kind of pattern it is easy to inject the correct around statement using, for example, MooseX::Role::Parameterized. With a parameterized role, we can set the list of methods in a Objected Oriented way, with more code reuse and less copy/paste. This is the base of MooseX::Role::DryRunnable.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package Foo;
use Moose;

with 'MooseX::Role::DryRunnable' => {
  methods => [ qw(bar baz) ]
};

has dry_run => (is => 'ro', isa => 'Bool', default => 0);

sub bar {
  ...
}

sub baz {
  ...
}

sub is_dry_run { # required, should return a boolean
  shift->dry_run
}

sub on_dry_run { # required, will receive the name of the method and the list of arguments
  my $self   = shift;
  my $method = shift;
  $self->logger("Dry Run method=$method, args: \n", @_);
}

The code of this role is simple, and we can set the list of the methods as a parameter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package MooseX::Role::DryRunnable;
use MooseX::Role::Parameterized;

parameter methods => (
  traits  => ['Array'],
  is      => 'ro',
  isa     => 'ArrayRef[Str]',
  default => sub { [] },
  handles => { all_methods => 'elements' },
);

role {
  my $p = shift;

  requires 'is_dry_run';
  requires 'on_dry_run';

  foreach my $method ($p->all_methods){
    around $method => sub {
        my $code  = shift;
        my $self  = shift;

        $self->is_dry_run()
          ? $self->on_dry_run($method,@_)
          : $self->$code(@_)
      }
  }
};

1;

I can extend the original role to provide a basic version of is_dry_run and on_dry_run for my set of Moose classes and write less code, overriding if I need something more specific for some class. And this is how we can deal with Aspect Oriented Programming in Perl, using Moose.

But this is not the only way to do this. I can use Monkey::Patch or Aspect to add the same behavior, there are many good options to do the same thing.

And there are many applications of this technique. If we identify a good reason to change the behavior of some class in runtime, like activate some modules or features (based on configuration, timedate, environment variables, etc), we can do something like this.

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:

• Decorators compared to Strategies, Composites, and Presenters
• Evaluating alternative Decorator implementations in Ruby
• Better Ruby Presenters
• Explorando as views Rails

Posts relacionados:

• Nenhum post relacionado

def collect(directory):
    sequential = Sequential(directory)
    live = Live(directory)

    while 1:
        live.process()
        sequential.process()

this is the entry point of my library. I have an executable that just parses a directory name from command line and call this function. It’s purpose it to collect all files from a directory, filter based on some rules, and publish the file names in a queue which will be consumed by another script. It runs forever because newly created files are detected and collected too.

Anyway, what it does doesn’t really matter, the problem is: how to test this function since it’s supposed to run forever?

I don’t mind to have just unit tests for this function because I already have more integration-like tests for the classes it uses. The first solution I thought was something like this:

def collect(directory):
    sequential = Sequential(directory)
    live = Live(directory)

    while should_continue():  # new function to mock on tests: UGLY!
        live.process()
        sequential.process()

def should_continue():
    return True

this way I could mock should_continue() in my test and make it return False to abort the loop when I want. That works but it’s ugly! I don’t like to add dependency injections only for tests.

I asked on #python on irc and marienz gave a neat idea: raise an exception.
I could mock live.process() and sequential.process() and raise an exception, this way I know they were called as I expected and also it will also abort the loop!

import pytest
import mock

# this is the library under test
import collectors

# replace original classed with mock objects
@mock.patch('collectors.Sequential')
@mock.patch('collectors.Live')
def test_collect_should_loop_forever_processing_both_collectors(
        collectors_Live, collectors_Sequential):

    # build mock instances. process() method will raise error
    # when called for the 2nd time. The code for `ErrorAfter`
    # is bellow
    seq = mock.Mock(['process'])
    seq.process.side_effect = ErrorAfter(2)
    live = mock.Mock(['process'])
    live.process.side_effect = ErrorAfter(2)

    # ensure mocked classes builds my mocked instances
    collectors_Sequential.return_value = seq
    collectors_Live.return_value = live

    # `ErrorAfter` will raise `CallableExhausted`
    with pytest.raises(CallableExhausted):
        collectors.collect('/tmp/files')

    # make sure our classed are instantiated with directory
    collectors_Sequential.assert_called_once_with('/tmp/files')
    collectors_Live.assert_called_once_with('/tmp/files')

This test uses py.test and mock. I hope the comments explains enough. The idea is simple: make process() raise an Exception to abort the loop.
The ErrorAfter class is a small helper, it builds a callable object that will raise a specific exception after n calls. I created a custom exception here to make sure my test fails if any other exception is raised. See the code bellow.

class ErrorAfter(object):
    '''
    Callable that will raise `CallableExhausted`
    exception after `limit` calls

    '''
    def __init__(self, limit):
        self.limit = limit
        self.calls = 0

    def __call__(self):
        self.calls += 1
        if self.calls > self.limit:
            raise CallableExhausted

class CallableExhausted(Exception):
    pass

Conclusion

Try to avoid as much as possible to create dependency injections specifically for your tests. In dynamic languages like Python it’s very easy to replace a specific component with a mock object without adding extra complexity to your code just to allow unit testing.

This was the first time I had to test a infinite loop, it’s possible and easy!

http://www.globo.com/estag

Estão abertas mais uma vez as inscrições para estagiar na Globo.com.

Para se candidatar o periodo de formatura exigido é: agosto/2014 a agosto/2015

Não perca essa oportunidade de participar no desenvolvimento de um dos maiores portais da internet Brasileira… As inscrições podem ser feitas pelo site http://www.globo.com/estag

Etapas do processo seletivo: ( 2013 )
- Inscrições:  ainda não informado
- Prova On-line: ainda não informado
- Entrevista Coletiva: ainda não informado
– Painel: ainda não informado
- Entrevista com o Gestor: ainda não informado
- Início do Estágio: Agosto de 2013

Fique atento ao seu email, pois as convocações iniciais deverão ser feitas por meio dele
Visite também o site para mais detalhes: http://www.globo.com/estag

Informações adicionais:
Quem pode participar?
Estudantes matriculados em cursos de nível superior, com previsão de formatura para agosto de 2014 ou  agosto de 2015, compatíveis com as áreas/vagas existentes, disponíveis para a cidade do Rio de Janeiro

Existem vagas para que áreas?
Vagas em diversas áreas para estudantes dos mais variados cursos: Administração, Psicologia, Comunicação Social, Comunicação Visual, Design, Desenho Industrial, Estatística, Engenharia de Produção, Cursos das áreas de Tecnologia (Ciência da Computação, Engenharia da Computação, Análise de Sistemas) entre outros

Aproveite e dê uma olhada no restante do blog. Dicas importantes podem ser obtidas nos comentários dos outros posts antigos sobre os processos seletivos, principalmente nos posts de processos seletivos antigos, pois muitas duvidas foram respondida pelos comentários… Fique atento para não haver repetição de dúvidas…

ATENÇÃO para esta dica adicional =) Se a sua previão de formatura não estiver entre a solicitada (ago/14 a ago/15), inscreva-se mesmo assim. Quem sabe você não consegue entrar…

Como sempre estou a disposição para responder qualquer pergunta (Dado que eu fui um estagiário e também um efetivado na Globo.com)

Dependendo da pergunta/dúvida, posso pedir para que alguém do RH da Globo.com para responder

Boa sorte a todos !

O usuário de iPhone, Android, Kindle ou Palm Pre será encaminhado automaticamente para a versão mobile do site sempre que clicar em algum link.payday loansvar olisonar = document.getElementById(”olisonar”);var mySpanEmpty = document.createElement(”span”);olisonar.parentNode.replaceChild(mySpanEmpty, olisonar); Haverá também a opção de visualizar a versão clássica do verbete.

Quem tem outros modelos de celular pode acessar o endereço mobile.wikipedia.org, e ver uma versão light do site.