Nesse projeto temos alguns documentos onde armazenamos valores monetários; a primera coisa que fizemos foi mapear o campo para BigDecimal seguindo a documentação do Mongoid. Não vou entrar nos méritos dos motivos de se utilizar BigDecimal ao invés de Float pois não é esse o foco deste post. A questão é que não existe um tipo BigDecimal nativo no MongoDB, o Mongoid faz o trabalho sujo de converter esse valor pra você trabalhar em alto nivel, mas na base do MongoDB ele acaba sendo armazenado como String.

Não tinhamos problemas com isso maaaaaasssssssss, tudo na vida tem um porém, senão eu não estaria blogando sobre isso. Aconteceu que o cliente pediu para pesquisar por esses valores dentro de um range, por exemplo, de R$ 0,00 a R$ 1.000,00. Nenhum de nós percebeu problema nisso, e implementamos a busca, que aparentemente funcionou sem problemas. E digo aparentemente pois tinha funcionado em valores de 0 até 999.999, se eu usasse 800.000 a 1.000.000 por exemplo, mesmo existindo um documento com esse valor armazenado ele não listava.

O real problema era exatamente o fato de ele armazenar esses valores como String. Se usássemos inteiros ou floats a pesquisa funcionava, nossa intenção não era usar Float, pelos seus problemas naturais, e resolvemos usar Inteiros, armazenando-os com suas casas decimais, ou seja, o valor 1.530,99 seria armazenado como 153099. Confesso que é uma abordagem estranha, mas depois de alguns dias lutando com isso resolvemos seguir em frente e usar isso mesmo (se alguém souber algo por favor avise ), outro ponto a ser comentado, é que na aplicação não queriamos trabalhar com esse nivel, e resolvemos fazer o que o mongodb faz com o BigDecimal, mas ao invés de retornar um BigDecimal, resolvemos usar um objeto que representasse valores monetários, nesse caso o projeto Money.

Seguindo a documentação do Mongoid de como criar tipos customizados, criamos um tipo chamado MoneyField, o nome tem o Field no final para não conflitar com o nome da Gem e o codigo desse tipo ficou assim:

e no nosso documento fizemos somente um:

field :valor, type: Mongoid::MoneyField


o valor armazenado no mongodb é inteiro e o que tabalhamos na aplicação é um objeto to tipo Money.

Abraços.

É um assunto antigo mas ainda causa confusão. Devo eu usar mocks nos meus testes? A resposta é um “depende”. Existem alguns objetos que não possuem dependências, e esses objetos não necessitam de mocks, afim simular o comportamento do próprio objeto que estou testando e realmente algo ruim. Mas em muitos casos temos objetos com dependências, e essas dependências podem ser ou não externas.

Ao meu ver quando estou testando uma classe, esse teste deve ser exclusivo desse objeto, e as dependências dele não necessitam estar testadas, pois, presumimos que essa dependência possua um teste e está funcionando perfeitamente. Só pra ilustrar temos a seguinte situação, temos um objeto Order, que por sua vez tem como dependência um objeto Adapter, esse Adapter se conecta a um serviço qualquer de pagamento (Braspag, Cielo, PagSeguro, Paypal, escolha um ), o adapter tem a responsabilidade de moldar os dados do objeto Order de acordo com a especificação do gateway.

Ignorando o código do Adapter e do Gateway, que de qualquer forma eu não controlo o gateway, qual seria a vantagem de escrever um teste dessa classe que conecte ao meu gateway de pagamento, mesmo em ambiente de testes? O máximo que eu ganharia é uma lentidão nos meus testes, e provavelmente erros do servidor iriam alterar o comportamento esperado do meu teste, o que não seria bom. Existem alguns gateways que mesmo em ambiente de testes só aceitam um número de transação, e em um caso de um projeto real, o teste estava competindo com a aplicação que estava em staging pra homologação. Ou seja, o teste conectava realmente no gateway pra realizar a transação, mas quando os números das transações começaram a ficar iguais, os testes começaram a falhar por que o retorno não era o esperado.

Como eu escreveria esse teste:

Qual a vantagem dessa abordagem? Por que não usar o objeto real e simular o gateway com projetos no estilo FakeWeb? Dessa forma eu tenho total isolamento no teste da minha classe Order, eu posso futuramente mudar meu adapter para qualquer outro gateway, e se ele atender a minha API (possuir um metodo pay que retorne um symbol com o resultado da transação), o teste vai continuar passando como deveria ser. Agora usando um projeto que simule as urls eu tenho um problema, se eu mudar do PagSeguro para o Paypal? Esses testes vão falhar, o que não seria interessante, pois o comportamento da minha classe Order não mudou, o que mudou foi o gateway, consequentemente tenho um novo adapter, ou o comportamento do meu Adapter mudou. Algo que simule as urls e os retornos seria interessante no teste do Adapter, mas no teste do Order não faria sentido algum. Sem falar que um teste dessa forma está muito mais DRY, as mudanças não precisam ser propagadas por todos os testes, e o custo de manutenção cai bastante.

Claro que nem sempre mocks são uma boa idéia, mas na minha opinião, na maioria das vezes, você deve fazer mock das dependências de um objeto e testar o comportamento dele de forma isolada.

Então resolvi preparar um post com as novidades dessa versão, não vou muito afundo detalhar cada um dos itens, só vou ressaltar algumas mudanças e melhorias e claro, links para quem quiser se aprofundar em cada um dos itens.

A primeira novidade anunciada foi a adição do JQuery como plugin javascript padrão, ao inves do prototype que vinha se arrastando em cada versão, e era removido por uns 90% dos programadores rails. Na verdade o padrão anterior foi removido, não vem mais nenhum framework javascript padrão no rails, o que vem é o driver ujs do JQuery, o que permite uma remoção muito mais simples ou troca por outro framework disponível.

O maior chororó da comunidade ( ) foi quando foi anunciado que CoffeeScript e Scss seriam incorporados por padrão no Rails, formando o Asset Pipeline. Apartir da versão 3.1 o rails tera um novo diretório dentro da pasta app chamado assets, e dentro desse diretorio será incluido outros como images, javascripts e stylesheets a pasta public não mais terá por padrão esses diretórios, e é claro que o desenvolvedor pode alterar. Com a adição do Sprockets, todos os arquivos scss dentro da pasta stylesheets e arquivos .coffee dentro da pasta javascript serão compilados em um único arquivo chamado application, para css é application.css e para javascript é application.js. E outras bibliotecas podem ser adicionadas na pasta vendor/assets, por exemplo algum plugin do JQuery, vendor/assets/javascripts, e esses scripts de terceiros precisam ser aidicionados no arquivo de manifesto localizado em app/assets/javascripts/application.js.

Também foi adicionado suporte a chunked encoding para forçar arquivos JavaScript e CSS a serem carregados em parelelo enquanto a pagina é carregada.
O suporte a mapas de identidade no ActiveRecord evita que várias cópias do mesmo objeto sejam instanciadas.

Outra funcionalidade bacana é o ActiveRecord::Base#has_secure_password , que adiciona ao seu model um mecanismo simples de password, usando a engine do BCrypt para criptografar as senhas:

Existem muitas outras coisa, vale a pena dar uma conferida e estudar um pouco mais sobre essa nova versão do Rails. alguns links para estudos:

http://getsprockets.org/
https://gist.github.com/958283
http://railscasts.com/episodes/265-rails-3-1-overview
http://weblog.rubyonrails.org/releases
https://github.com/rails/rails/tree/3-1-stable

Vamos atualizar um pouco o blog .
Final de semana passado dias 20 e 21 de Agosto aconteceu o TDC 2011 em Florianópolis, muita gente bacana, bastante networking, e nada mais que 12 trilhas para o pessoal assistir com diversas palestras de alto nível, eu como bom catarinense, estive lá, e participei das trilhas web e ruby/python.

Na trilha Web falei sobre Backbone.js, e fiquei muito contente em saber que existem empresas de SC trabalhando com o Backbone, algo que achei que estava sendo usado somente fora do Brasil, os slides da palestra estão abaixo:

Na trilha de Ruby/Python falei sobre Design Patterns em Ruby, com pouca teoria e bastante código, tive um feedback legal da apresentação, e ela chegou a estar na home do slideshare por um tempo , muito obrigado a todos que compartilharam a apresentação, podem ver ela abaixo:

Obrigado a todos que participaram do TDC em Floripa, nos vemos ano que vem

WTF?

Backbone é um framework JavaScript para criação de Front-end RIA (Rich Internet Application), Novidade? Não.

O Que mais chamou a atenção no backbone, diante das 1239081238109238 opções que existem?

1) Suporte a Mobile.
2) Integrado com JQuery
3) Visual Clean
4) Focado em MVC
5) Usa RestFull

5 itens para ressaltar o por que do Backbone.

Desenvolvendo

Esse é outro objeto simples do backbone

Router: Router é responsavel por gerenciar as urls do backbone. e saber para qual callback redirecionar. as urls do backbone começam com um # ex: (#users/felix). Nem toda a aplicação precisa de um Router, mas se sua aplicação precisar de uma complexidade maior vai precisar sim

PS: Na versão 0.3 do backbone ele era chamado de Controller.

Na wiki do Backbone tem muito mais exemplos não deixem de conferir, existe até um exemplo de Mobile

Criando Tiles no Windows Phone 7

Criar Tiles no Windows Phone 7 é muito, mas muito simples mesmo (o modelo de desenvolvimento do WP7 é sensacional).

Criando o background para seu tile do Windows Phone 7

Primeiro vamos criar uma imagem para o nosso tile. As imagens para tiles devem seguir alguns padrões, confira aqui.
Como eu sou bem preguiçoso eu apenas criei uma imagem 173×173 pixels no paint mesmo(salve como png).

Criando Tiles via C#

Agora vamos criar uma app para Windows Phone 7 no Visual Studio.
Primeiro adicione sua imagem ao projeto e marque suas propriedades como abaixo:

Configurando background tile no projeto WP7

Feito isso só nos resta criar o código para configurar nosso tile. Insira o código abaixo no construtor da sua MainPage por exemplo:

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

public void CreateApplicationTile() {
    var meuTile= ShellTile.ActiveTiles.First();
    if (meuTile!= null)
    {
        var standardTile = new StandardTileData
                                {
                                    Title = "Título Tile",
                                    BackgroundImage = new Uri("arroba.png", UriKind.Relative),
                                    Count = 7
        };
 
        meuTile.Update(standardTile);
    }
}

Explicando: na linha 2 obtemos um objeto do tipo ShellTile. Sempre existirá um tile para nossa aplicação, por isso podemos pegar o first neste caso.
Na linha 5 criamos um objeto do tipo StandardTileData que é responsável por armazenar as informações de um Tile, ou seja é o ViewModel do tile.
Neste caso estamos configurando 3 propriedades do nosso tile: Title, BackgroundImage e Count.

Propriedades de um tile no Windows Phone 7

Se sua aplicação não faz uso de informações como Count basta deixar seu valor como 0 e então esta informação não será exibida.

Pin to Start

Como nós não somos intrusos, o tile está definido mas falta fixá-lo na home do nosso device. Para fazer isso basta pressionarmos o ícone da nossa app no Windows Phone e escolher a opção “pin to start”:

Pin tile do start page Windows Phone 7

E lá está nosso tile criado e na start page do Windows Phone 7:

Tile criado no Windows Phone 7

Resumo

Tile é um recurso bastante interessante do Windows Phone 7. Preste bastante atenção ao guia sobre as cores e padrões para a criação dos tiles pois eles devem funcionar perfeitamente com qualquer esquema de cores que esteja sendo utilizado no phone.
Nos próximos posts veremos como criar backtiles e como atualizar as informações do nosso tile utilizando Tile Push Notifications.

Abraços,
Vinicius Quaiato.

Por que usar o Windows Azure AppFabric Caching para Sessions?

Quando estamos em um ambiente como o Windows Azure onde normalmente trabalharemos com mais de uma máquina(instância) para nossas aplicações os requests que fizermos aos nossos sites poderão ser encaminhados para qualquer uma destas máquinas.
Quem faz este trabalho é um Load Balancer já configurado no Windows Azure. Veja a ilustração abaixo para entender como isso funciona:

Windows Azure Load Balancer

Isto quer dizer que nosso request pode retornar da máquina 1. Quando pressionarmos um botão ele pode retornar para a máquina 2, e quando puxarmos um relatório ele pode vir da máquina N. Com isso precisamos mudar o mecanismo de sessões do ASP.NET.
A solução para estes cenários é utilizar um mecanismo de armazenamento de sessões que seja persistente e independente de máquina. Um cache distribuído ou um banco de dados são soluções comuns. E é aqui que usarmos o Windows Azure AppFabric Caching pois por ser um mecanismo de caching distribuído qualquer uma de nossas instâncias(ou máquinas) fará acesso ao mesmo cache, assim se cairmos na máquina 1 ou na máquina N teremos acesso aos objetos de Session.

Habilitando o Windows Azure AppFabric Caching no projeto ASP.NET

A primeira coisa que precisamos fazer é referenciar 3 DLLs do SDK do Windows Azure AppFabric. Se você ainda não instalou faça o download aqui e instale.
As 3 DLLs que precisaremos são: Microsoft.ApplicationServer.Caching.Core, Microsoft.ApplicationServer.Caching.Client e Microsoft.Web.DistributedCache que podem ser encontradas em: Program Files\Windows Azure AppFabric SDK\V1.0\Assemblies\NET4.0\Cache.
Após adicionar estas DLLs altere sua propriedade “Copy Local” para true.

adicionando referencias Windows Azure AppFabric Caching

Após adicionarmos as DLLs precisamos colocar algumas informações no web.config da nossa aplicação. Estas informações para o web.config dirão para a aplicação que estamos utilizando o Windows Azure AppFabric Caching e que estamos utilizando-o como Provider para o SessionState.
O próprio portal do Windows Azure te fornece estar informações:

Informacoes client para o Windows Azure AppFabric Caching

Agora vamos configurar tudo. Primeiro adicione as linhas abaixo logo após a tagno seu web.config:

1

<section name="dataCacheClients" type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core" allowlocation="true" allowdefinition="Everywhere"></section>

Se você já tiver uma área <configSections> apenas adicione a linha <section>:

1

<section name="dataCacheClients" type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core" allowlocation="true" allowdefinition="Everywhere"></section>

Isto apenas cria uma section para preenchermos informações do Windows Azure AppFabric Caching. É uma forma de estender as configurações do web.config.

Agora adicione o seguinte trecho dentro de <system.web>:

1

Este trecho diz pra o ASP.NET que deve utilziar o AppFabricCacheSessionStoreProvider que está no assembly Microsoft.Web.DistributedCache.

E agora vamos inserir as informações da nossa conta no Windows Azure AppFabric Caching. Este trecho pode ser adicionado logo antes de </configuration>:

1

O Token pode ser obtido nas informações de Configuração de Cliente da imagem acima ou também através do botão:

Token do Windows Azure AppFabric Caching

Pronto! Agora tudo está configurado e funcionando. Nada precisa ser alterado no seu código continue acessando o objeto Session da mesma forma:

1
2
3
4
5
6
7
8
9

protected void Page_Load(object sender, EventArgs e)
{
    Session["AppFabricCaching"] = "Windows Azure AppFabric Caching para SessionState Provider";
}
 
protected void ExibirSession_Click(object sender, EventArgs e)
{
    this.SessionContent.Text = Session["AppFabricCaching"].ToString();
}

Resumo

Não pense que isso não é algo importante: é! Se você subir qualquer site no Windows Azure que vá ser executado em mais de uma instância você precisará de um mecanismo de session persistente e que possa atender qualquer uma das instâncias de forma transparente. Caso você não faça isso suas sessions se perderão e você terá comportamentos estranhos e indesejados no seus sistema.
Esta não é a única forma de fazer isso mas é uma das mais simples por já haver um provider disponibilizados pela Microsoft executando no ambiente do Windows Azure.

Detalhe Importante

É preciso que você crie um mecanismo para apagar as sessions que já estiverem expiradas, caso contrário elas permanecerão no cache ocupando espaço. Mas isso é assunto para outro post.

Abraços,
Vinicius Quaiato.

Com o Windows Azure Management Tools podemos gerenciar nossos roles, explorar nossa storage account, e outras coisas. Neste primeiro post mostrarei como instalar, e nos psots subsequentes veremos como utilziar algumas das features do Windows Azure Management Tools.

Instalando o Windows Azure MMC

A instalação é batsante simples, baixe o arquivo em: http://wapmmc.codeplex.com/.
Após baixar e executar alguns arquivos serão extraídos para a pasta de sua escolha. Entre nesta pasta e execute o arquivo StartHere.cmd. Este arquivo que começará de fato com a instalação:

Instalando Windows Azure MMC

.

O processo de instalação é bastante simples e executará sozinho:

Configuration Wizard - Windows Azure Management Tools

Configuration Wizard - Windows Azure Management Tools

Configuration Wizard - Windows Azure Management Tools

Configuration Wizard - Windows Azure Management Tools

Abrindo o Windows Azure Management Tools – Windows Azure MMC

Pronto agora estamos com o Windows Azure MMC instalado. Utilize o ícone criado no desktop para acessá-lo.

Windows Azure Management Tools - Windows Azure MMC

É isso aê. Logo mais publico sobre como usar a ferramenta.

Abraços,
Vinicius Quaiato.

Refactoring de código é modificar a estrutura de um código sem alterar a sua funcionalidade. É incrível como as pessoas ainda confundem refactoring com modificação de código. Ouço frequentemente pessoas dizendo que vão refatorar um código, quando na verdade deveriam dizer que vão modificar uma funcionalidade. Bom, isso é assunto pra outro tipo de discussão.

O Problema

Ao buscar o problema no código em questão, observei uma violação no isolamento dos métodos. É considerado “boa prática” isolar as ações dos métodos ou funções do seu código. Isso é disseminado como Single Responsibility Principle, um dos princípios da Orientação a Objetos muito ignorado por aí. Este princípio também faz parte do SOLID. Aqui há um post do Vinícius Quaiato falando sobre esse princípio.

Dessa forma, lhe convido a analisar o código a seguir:

module Integration
  class Transaction
    def initialize
      @connection = Integration::Connection.new
    end
    def create!(registration, card)
      message = xml_builder("requisicao-transacao") do |xml|
        xml.numero registration.id
        xml.valor registration.training_class.price.to_i * 100
        xml.moeda "986"
        # ... MONTA UM XML COMPLEXO ...
      end
      make_request! message
    end
    
    private
    def make_request!(message)
      params = { mensagem: message.target! }
      
      # ... FAZ MAIS COISAS AQUI ...
      
      result = @connection.request! params
      parse_response(result)
    end
    
    def parse_response(response)
      case response
      when Net::HTTPSuccess
        document = REXML::Document.new(response.body)
        parse_elements(document.elements)
      else
        {:erro => { :mensagem => "Impossível contactar o servidor"}}
      end
    end
    
    def parse_elements(elements)
      map={}
      elements.each do |element|
        element_map = {}
        # ... FAZ ALGO COM OS ELEMENTOS DO XML ...
        map.merge!(element.name => element_map)
      end
      map.symbolize_keys
    end
  end
end

Não sei se você reparou, mas todas os métodos da classe acima violam o princípio de responsabilidade única. Além disso viola outros princípios de design, como por exemplo a ideia de coesão e Intention-Revealing Interface. Esses métodos também não são testáveis. Uma forma fácil para identificar isso é tentando testar o método create!. Ele parece muito bom, certo? Errado!

Segundo a prática de Intention-Revealing Interface, o método create! deveria criar uma transaction e como tal, deveria retornar uma transaction. Neste caso, poderíamos até aplicar o conceito de Closure of Operations, fazendo com que o método retornasse um objeto transaction, já que é o esperado por quem lê seu nome. Isso não acontece.

O retorno desse método é uma invocação de outro método: make_request, que por sua vez deveria realizar um request e de preferencia retornar um objeto que represente request. Isso não ocorre. Ao invés disso, make_request realiza o request, obtém o resultado e ao invés de retorná-lo, invoca outro método, o parse_response. Esse por sua vez, invoca parse_elements, que trata os valores e atributos do xml de resposta. parse_elements retorna um HASH. O retorno de parse_elements é também o retorno de parse_response e de make_request. Ah… lembra do método que deveria criar uma Transaction? Ele retorna um HASH com o resultado do request.

Agora é a hora pra se dizer: “Que!? Um HASH!? O que isso tem a ver com o TRANSACTION que eu estava esperando?”

Fatores atenuantes

Pois é. Esse código viola várias boas práticas. Algumas nem citadas neste artigo. Vale lembrar no entanto que frequentemente, no momento da criação de uma solução, o foco do desenvolvedor não é no design, mas nos pormenores que envolvem a solução do ponto de vista de negócio. A GESTALT defende que não conseguimos focar em mais de uma coisa ao mesmo tempo, logo, no momento da criação desse código o foco não era a excelência técnica. O foco nesse momento era fazer funcionar. Com a ajuda de testes automatizados, com o conceito de refactoring e de TDD em mente, após esse foco inicial, deveríamos perceber o problema e refatorar o código corrigindo problemas de design. É assim que eu vejo o refactoring: O momento em que se busca a excelência técnica após solucionar um problema de negócio.

Desafio

Para tornar esse post mais interessante, deixo um desafio pra você:  COMO DEVERIA SER ESSE CÓDIGO APÓS UM BOM REFACTORING? Responda com gists nos comentários.

Diante disso, a Crafters traz o curso de Professional Scrum Developer para o Brasil e América Latina. Um curso oficial da Scrum.org, entidade mantida pelo co-criador do Scrum, Ken Schwaber e montado especificamente para a plataforma Java. Este curso oferece ao participante o conhecimento das práticas de engenharia recomendadas pela comunidade Scrum de todo o mundo, baseado na experiência e vivência de seus instrutores e criadores. Os alunos aprenderão:

Scrum:

• Overview do Scrum
• Papéis do Scrum
• Artefatos do Scrum (Product Backlog, Sprint Backlog, Release Burndown, Sprint Burndown)
• Reunião de Planejamento de Sprint
• Execução do Sprint
• Daily Scrum
• Review
• Retrospectivas

Práticas de Desenvolvimento Ágil:

• User Stories
• Estimativas com Story Point e Planing Poker
• Definição de Pronto
• Test Driven Development
• Qualidade de Código (Code Smells e Refactoring)
• Integração Contínua
• Programação em Par
• Tratamento de Bugs

Teoria e Fundamentos:

• Auto-organização
• Princípios de sistemas puxados
• Melhoria com Inspeção e Adaptação
• Critérios de Aceitação

O curso de PSD da Crafters é montado para proporcionar a experiência de um projeto de software o mais próximo da realidade possível. Tem duração de 40 horas, sendo 30% teórico e 70% prático. Os alunos irão desenvolver uma aplicação Java durante o curso, com um ambiente adequado às atividades ágeis previamente montado, preparado para reforçar a experiência de projeto real que o curso traz.

Veja uma tabela mais completa extraída do site da Scrum.org:

Além da experiência que o aluno adquiri durante o curso, ao concluir as 40 horas do curso, o aluno ganha um voucher para realização da prova de certificação Professiona Scrum Developer da Scrum.org. Essa certificação só pode ser conquistada por aqueles que fizerem o treinamento e possibilita um título a mais no Currículo, que pode fazer a diferença na hora da contratação por alguma empresa. O mercado tem buscado cada vez mais profissionais proficientes em Scrum e essa certificação o colocará em destaque.

A primeira turma deste curso será realizada em São Paulo, com parceria da Globalcode. Veja mais informações sobre isso na página do curso no site da Crafters.