MouseOver Studio

Eu não sou fã dos deploys estilo Heroku, mas sei que muitas pessoas são e que muitas delas não sabem que o Inploy suporta um estilo similar de realizar essa tarefa.

Thomas Ritz contribuiu com um template no Inploy chamado rails3_push que no setup cria um repositorio no servidor e no update da um push nele, seguido por todas as tasks que o Inploy executa normalmente em cada deploy.

Para utilizar esse template. que nem com qualquer outro, basta especificar ele no arquivo deploy.rb:

template = :rails3_push
application = "tweerrer"
hosts = %w(...)
...

Após isso, para configurar o ambiente e realizar deploys em todos os servidores, basta executar respectivamente os seguintes comandos:

inploy setup
inploy

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Em poucas palavras, o Shouty é uma espécie de Twitter que nem o Yammer, Present.ly ou o Identi.ca, porém com muito menos funcionalidades.

Faz um tempo, quando alguém na Gonow queria compartilhar alguma coisa simples com o resto da empresa, ela enviava um email para um endereço que inclui todos os membros da grande equipe. Esses emails eram muito chatos porque além de demorarem muito para serem escritos, demoravam muitos para serem lidos.

Com o tempo algumas pessoas começaram a utilizar o Yammer mas eu não gostei dele porque você consegue seguir pessoas e conseqüentemente se restringir a ver somente as mensagens das pessoas que você segue, pelo que foram sendo criadas panelinhas. Com isso, quando alguém queria enviar uma mensagem para a panela, a pessoa utilizava o Yammer, quando alguém queria enviar uma mensagem para tudo mundo, a pessoa utilizava o email.

Na época procurei outras alternativas mas nenhuma me agradou por terem muitas coisas que não precisava e não fazerem de um modo simples o que eu queria. O que eu queria era uma ferramenta que ajudasse a todos os membros da Gonow se comunicarem de um jeito simples e rápido, sem a opção de criar grupos, que tudo mundo se comunicasse com tudo mundo.

Foi assim que mais ou menos sete meses atrás nasceu o Shouty, uma aplicação que satisfez certas necessidades da Gonow, gerou algumas outras e criou algumas oportunidades de negócio.

De conversa em conversa, algumas empresas ficaram sabendo que a Gonow estava muito interessada em otimizar a comunicação interna e que tinha expertise sobre uma ferramenta, pelo que nos contataram para aplicar algumas regras no Shouty de acordo com as necessidades que tinham e criar uma versão personalizada. Hoje a Gonow tem nos repositórios privados mais ou menos quatro branches diferentes do Shouty, cada um representado uma versão para um cliente diferente.

O Shouty é open source e esta disponível para você baixar e utilizar ele na tua rede, podendo realizar modificações a vontade. Caso alguma dessas modificações seja de utilidade também para outras pessoas e não comprometa o objetivo da aplicação, não esquece de me mandar um pull request.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Caso queiram testar hoje seu código JavaScript numa aplicação Rails 3 de jeito bem simples, o Kristian Mandrup criou um fork do Blue-Ridge onde adaptou os geradores para a nova interface. Os commits dele ainda não foram adicionados ao repositorio oficial e o branch tem uns bugs leves, pelo que criei outro fork e corrigi eles.

Ate que todos os commits sejam aceitos no repositorio oficial, o que podem executar para ter o ambiente configurado é o seguinte:

git submodule add -b rails3 git://github.com/dcrec1/blue-ridge.git ./vendor/plugins/blue-ridge
rails g blue_ridge:skeleton
rails g blue_ridge:javascript_spec core
rake spec:javascripts

Caso não conheçam o Blue-Ridge, o Dr. Nic publicou faz um tempo um post onde explica a ferramenta e onde também publicou o video de uma palestra que ele deu no Rails Underground 2009.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Recentemente a Gonow foi contratada para trabalhar num projeto que já tinha passado por outras duas consultorias com desenvolvedores bastante reconhecidos no mercado nacional. A aplicação foi construída sobre Sinatra e algo que me chamou muito a atenção é que a aplicação não tinha uma linha de teste. Mesmo não sendo uma justificativa, aparentemente não existe nada em português falando sobre como integrar o Sinatra com o RSpec e por isso vou aproveitar para dar uma receita de bolo, de modo que o processo fique mais simples ainda:

* spec/spec_helper.rb:

require File.join(File.dirname(__FILE__), '..', 'main.rb')

require 'spec'
require 'rack/test'

Spec::Runner.configure do |conf|
  conf.include Rack::Test::Methods
end

def app
  Sinatra::Application
end

* spec/main_spec.rb:

require 'spec_helper'

describe Sinatra::Application do
  context "responding to GET /" do
    it "should return status code 200"
      get '/'
      last_response.code.should == 200
    end
  end
end

* Rakefile:

...
require 'spec/rake/spectask'

desc "Run all specs"
Spec::Rake::SpecTask.new do |t|
  t.spec_opts = %w(--format specdoc --color)
end

Muitas pessoas me perguntam porque o Signal não tem diversas funcionalidades que outras ferramentas tem e se seria legal implementar elas. Nesse post vou explicar rapidamente a motivação para o Signal ser do jeito que é, sem entrar em muito detalhe, devido a que já existe muita informação sobre o assunto.

Antes de começar, é bom ter bem claro que integração continua é uma pratica e não uma ferramenta.

Uma das práticas da integração continua é automatizar o build e é por tal motivo que o Signal executa unicamente um comando e não oferece, por exemplo, a funcionalidade de executar varias coisas antes de de rodar o build ou rodar ele com diferentes versões do Ruby.

Outra prática da integração continua é rodar o build em cada atualização do repositório central, o que explica por que no Signal você não consegue agendar os builds, ele espera que você os execute no momento certo, após cada atualização, chamando a devida URL.

Algumas pessoas me pediram que o Signal mostre o histórico dos builds, de modo que alguém consiga saber em qual momento o build quebrou. Essa funcionalidade é valiosa quando o build fica quebrado por um tempo e certo dia queremos consertar ele, o que devemos evitar acontecer. Que nem o Martin Fowler explicou no último link, uma atualização de código somente pode ser considerada completa quando o build decretou sucesso, caso contrario, devemos corrigir ele na hora.

Para finalizar, uma quarta prática da integração continua é automatizar os deploys. Algumas ferramentas oferecem algumas funcionalidades para o usuário poder configurar quando realizar o deploy, como por exemplo quando o build der sucesso. O Signal não oferece essa funcionalidade porque acredito que essa lógica deve ser independente da ferramenta, deve ser parte do processo a ser executado.

Hoje, iniciar uma aplicação com Rails 3, utilizando as bibliotecas padrão, é muito fácil. Porém, quando queremos utilizar aquelas ferramentas que nos facilitavam tanto a vida no Rails 2, alguns problemas começam a aparecer.

Esses problemas não se devem de nenhum jeito à que o Rails ou as bibliotecas estão instáveis. O que acontece é que diversos plugins e gems tiveram que mudar sua integração com o framework e alguns optaram por criar versões pre-release, outros por criar branches e outros simplesmente por criar uma nova versão, o que quer dizer que temos que sair caçando qual versão utilizar e da onde para as funcionalidades serem compatíveis.

Para facilitar o trabalho de muita gente e incentivar a adoção do Rails 3 decidi criar um template que configura as gems que sempre utilizo nos meus projetos e as instala na aplicação, além de outras tarefas que podem ser identificadas facilmente seguindo o script.

Caso o template ajudade você, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Caso estejam trabalhando com jQuery e precisem de uma imagem/mensagem estilo “Carregando…” em todas suas requisições Ajax, o plugin jquery.loading fornece essa funcionalidade com somente um linha de código. No meu caso ficou assim:

$.loading({
  onAjax: true,
  text: 'Carregando...',
  mask: true
});

A opção mask serve para adicionar uma div transparente que impossibilite novas ações ate a requisição acabar.

Esse funcionalidade é possível devido que as requisições Ajax do jQuery disparam certos eventos ao longo do processo, o que nos permite fazer coisas muito legais.

Na Gonow estamos desenvolvendo uma aplicação sobre o Spree. Por mas que eu já conhecia o conceito desse e-commerce por cima, teve que investir um tempo considerável lendo a excelente documentação dele e fazendo muita coisa errada, o que me fez aprender bastante.

O que vou escrever nesse post foi o que mais ou menos passei, de jeito bem simples, para outros membros da minha equipe que não conheciam tecnicamente o Spree e que ajudou eles a entenderem como funciona internamente e a começar a desenvolver sobre ele sem maiores problemas, sabendo onde procurar as coisas quando necessárias.

Deixei de lado o pagamento porque não tinha claro como explicar ele de forma simples e breve, talvez para outro post.

Conceitos básicos

Uma aplicação criada sobre o Spree é composta de um core e uma ou mais extensões. O core é basicamente uma aplicação Rails sem view. Uma extensão é basicamente uma aplicação Rails que complementa o core. Quando baixamos o Spree ele já vem com diversas extensões, como por exemplo o tema padrão pelo qual navegamos na loja e o suporte a pagamentos com cartão via Authorize.net. As extensões estão localizadas na pasta vendor/extensions.

Quando começamos a desenvolver nosso código encima do Spree fazemos isso numa extensão chamada por padrão de site. Para gerar o esqueleto dessa extensão podemos executar script/generate extension site. A extensão site é por default a última a ser carregada, mas existem diversas maneiras de mudar esse comportamento, alterando o load order.

Quando uma extensão é carregada, além do comportamento esperado ao inicializar uma aplicação Rails, o Spree executa a tarefa rake spree:extensions::update e executa dois arquivos: name_extension.rb e name_hooks.rb, onde name é o nome da extensão. A tarefa rake copia todos os assets (javascripts, css, …) da extensão para a pasta public do projeto.

O arquivo de hooks serve para estender os temas do Spree, como o que vem por padrão. A idéia dos hooks é que possamos remover, substituir ou inserir código antes e depois de cada seção numa view, de modo que não tenhamos que duplicar todo o conteúdo para editar algo pequeno.

No arquivo de extensões podemos declarar dependências de gems, registrar métodos de pagamento e abrir algumas classes e módulos, como por exemplo a classe AppConfiguration, que define as preferências do sistema.

Taxons

No Spree existe o conceito de taxon e taxonomia. Um taxon é uma espécie de tag que pode pertencer a um pai e pode ter vários filhos. Quando falamos de pais e filhos, estamos falando de uma hierarquia e uma taxonomia é justamente isso, uma hierarquia de taxons.

O Spree vem com um tarefa rake chamada db:bootstrap que popula o banco com dados de demonstração e cria duas taxonomias. A primeira taxonomia tem com pai o taxon marca e a segunda tem como pai o taxon categoria. Desse modo, um produto pode ter o taxon Ferrari e o taxon Esportivos, podendo pertencer a duas taxonomias ao mesmo tempo.

Métodos de envío

Uma vez que o usuário escolheu os produtos que ele quer comprar, ele deve escolher a forma de envio deles. Cada forma de envio esta mapeada a uma zona. Uma zona pode ser composta por uma combinação de países, estados e outras zonas. Caso queiram utilizar estados brasileiros, podem utilizar esse seed.

Calculadoras

Quando mapeamos uma forma de envio à uma zona, devemos escolher uma calculadora. Uma calculadora é uma classe que recebe um pedido e computa o valor final, após aplicar impostos e coisas similares.

O core do Spree ja vem com distintas calculadoras, mas elas são somente ativadas pela extensão calculators, que vem junto com a aplicação.

Caso esse post tenha ajudado você, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Na mundo da programação, uma anotação é um jeito de marcar o código que esta embaixo dele para diversos fins. No Cucumber, as tags que ele utiliza são uma espécie de anotação para poder aplicar callbacks e classificar algumas funcionalidades e cenários:

@billing
Feature: Verify billing

  @important
  Scenario: Missing product description

  Scenario: Several products

No caso do VRaptor temos anotações para poder classificar um controller como recurso REST ou especificar o acesso a uma action:

@Resource
public class ShoppingCartController {
    ...
}

public class ProductsController {
    @Post
    @Path("/products")
    public void add(Product product) {...}
    ...
}

Em Ruby, duas anotações que utilizamos bastante são os métodos private e protected, que sem argumentos restringem a visibilidade dos métodos definidos embaixo deles:

class User
  def jump; end;

  protected
  def eat; end;
  def flirt; end;

  private
  def sleep; end;
  def dream; end;
end

Dependendo do caso, podemos querer anotar nosso código nesse estilo, como por exemplo para especificar que um método esta depreciado, funcionalidade que podemos obter com a gem Canivete do Douglas Campos:

class Bomb
  deprecate
  def explode; end
end

No código acima, quando alguém chamar o método Bomb#explode, o interpretador ira efetivamente executar o método, mas além disso ira imprimir: Warning: calling deprecated method Bomb.explode.

Esse comportamento pode ser obtido por causa do método method_added, presente em todos os módulos do Ruby, que é chamado toda vez que um método e definido, recebendo o nome do mesmo como parâmetro.

Podemos utilizar esse método então por exemplo para criar uma anotação que serva para especificar que os métodos declarados após ela somente podem ser chamados por um admin, algo assim:

class Module
  def method_added(name)
    unless @_admin_only.nil? or @_proxy_method
      @_proxy_method = true
      alias_method "_admin_#{name}", name
      module_eval <<-STRING
        def #{name}(*args, &block)
          _admin_#{name}(*args, &block) if admin?
        end
      STRING
      @_proxy_method = false
    end
  end

  def admin_only
    @_admin_only = true
  end
end

class User
  def admin?
    [true, false][rand(2)]
  end

  admin_only

  def update_password
    puts "password updated"
  end

  def restart_server
    puts "server restarted"
  end
end

Nó código acima, #admin? ira devolver verdadeiro ou falso aleatoriamente e dependendo do resultado, o método chamado ira ser executado ou não.

Eu sou fan do Pivotal Tracker. Quando utilizava ele na Gonow, a equipe na qual eu estava ficava sentada toda numa unica mesa e isso era muito legal porque mesmo utilizando a ferramenta, era muito fácil avisar todo mundo que um estava pegando certa tarefa ou entregando aquela.

Quando utilizei o Pivotal com uma equipe remota senti falta de saber o que estava acontecendo em tempo real, pelo que decidi criar o Kilt.

O Kilt é um daemon criado em Ruby que fica solicitando as atualizações dos projetos do usuário configurado e mostra uma notificação de alerta para cada uma recebida:

Com o Kilt consigo ficar programando e ao mesmo tempo ficar sabendo de tudo o que esta acontecendo com os projetos nos quais estou envolvido no Pivotal.

Para instalar o Kilt basta baixar a gem e chamar kilt-install com o token do usuário desejado:

sudo gem install kilt
kilt-install TOKEN

Caso não conheçam o token do usuário, podem executar:

curl -u USERNAME:PASSWORD -X GET https://www.pivotaltracker.com/services/v3/tokens/active

o que devolvera um documento xml com o id e o token do usuário. Caso desejem outro método para solicitar o token, podem se referir à documentação do Pivotal.

Uma vez instalado o Kilt, para rodar ele basta executar:

kilt-app