Neste artigo, você verá um passo-a-passo de como instalar e configurar o ambiente de desenvolvimento no Windows com Ruby 1.9.3-p0 e Rails 3.2.1, MySQL e Git.

Instalando o Ruby

O primeiro passo é instalar o Ruby. Isso pode ser feito com o RubyInstaller, mantido pelo Luis Lavena. Faça o download do instalador Ruby 1.9.3-p0.

Assim que o download for concluído, execute-o para iniciar a instalação. Siga os passos apresentados pelo instalador e não deixe de marcar a opção "Add Ruby executables to your PATH".

O Ruby já está instalado. Para se certificar de que ele está funcionando, abra o seu terminal. Para isso, digite "powershell" no menu Windows e execute o programa "Windows PowerShell".

No terminal, digite o comando ruby -v. Isso deverá exibir a versão instalada do Ruby.

Nós também iremos precisar do Ruby DevKit, um instalador disponibilizado no próprio site do RubyInstaller e que permitirá instalar extensões nativas como json e mysql2. Na página de downloads do Ruby Installer, faça o download do arquivo DevKit-tdm-32-4.5.2-20111229-1559-sfx.exe.

Assim que o download for concluído, você precisará extrair os arquivos para o diretório C:\Ruby193\devkit. Esse diretório não existe, então você precisará criá-lo.

Agora, volte ao terminal. Você precisará instalar o DevKit na instalação atual do Ruby. Para isso, digite o comando cd C:\Ruby193\devkit para ir ao diretório que você acabou de extrair. Execute o comando ruby dk.rb init e depois ruby dk.rb install.

Pronto! Agora o seu Ruby já está instalado!

Instalando o MySQL

Antes de instalar o Rails, você precisará instalar e configurar o MySQL. Para fazer isso, acesse a página de downloads e baixe o instalador. Assim que o download for concluído, inicie a instalação.

Quando for perguntado sobre o tipo de instalação, escolha "Complete". Clique em "Install".

Assim que a instalação finalizar, marque a opção "Launch the MySQL Instance Configuration Wizard" para iniciar o assistente de configuração. Clique em "Finish".

No assistente de configuração, selecione a opção "Detailed Configuration".

Defina o tipo de servidor como "Developer Machine".

Selecione a opção "Multifunctional Database", que permite criar bancos de dados do tipo InnoDB e MyISAM.

O próximo passo permite definir onde os bancos de dados serão criados. Nós iremos definir um diretório diferente do padrão. Assim, quando uma nova atualização do MySQL for lançada, não perderemos os dados armazenados até então. No dropdown onde está escrito "Instalation Path", escolha o diretório "\Data".

Agora você precisa escolher quantas conexões concorrentes você espera. Escolha a opção "Decision Support (DSS)/OLAP".

Marque as opções "Enable TCP/IP Networking" e "Enable Strict Mode".

Você também pode definir qual o tipo de codificação de caracteres padrão. Escolha a opção "Best Support For Multilingualism", que irá definir o UTF-8 como o tipo padrão.

Para iniciar o MySQL automaticamente quando o Windows é iniciado, marque a opção "Install As A Windows Service". Não deixe de marcar a opção "Include Bin Directory in Windows PATH".

Como estamos executando o MySQL em modo de desenvolvimento, você pode desmarcar a opção "Modify Security Settings".

Agora, clique em "Next" e depois "Execute" para aplicar as configurações que acabamos de definir.

Pronto! Para saber se o MySQL foi corretamente instalado, abra uma nova janela do terminal e execute o comando mysql --version. Você deverá ver a versão do MySQL instalado.

Nós ainda precisaremos configurar o Ruby com suporte ao MySQL. Para fazer isso, acesse a página de downloads do MySQL e clique no link MySQL Connectors. Você precisará da versão "Connector/C (libmysql)". Na página de download, escolha a opção sem o instalador. Escolha a versão de 32-bits. Isso é necessário porque o Ruby é 32-bits e, mesmo que a instalação do MySQL tenha sido feita em 64-bits, o conector que será usado por ele deve ter a mesma arquitetura.

Extraia os arquivos e copie o arquivo mysql-connector-c-noinstall-6.0.2-win32/lib/libmysql.dll para o diretório C:\Ruby193\bin. Isso é necessário pois DLLs precisam estar no PATH do Windows e, o diretório bin do Ruby no Windows adiciona todas as dependências lá.

Se tudo deu certo, você conseguirá usar a gem mysql2 no Windows.

Instalando o Ruby on Rails

Agora que já temos o Ruby e o MySQL devidamente configurados, podemos instalar o Ruby on Rails. Antes, vamos fazer uma pequena configuração para desabilitar a geração de documentação toda vez que uma gem for instalada. Isso não é obrigatório, mas você verá que o tempo usado para gerar a documentação é um tanto quanto longo.

No Windows, o arquivo de configuração do RubyGems deve ser criado em C:\ProgramData\gemrc. O diretório C:\ProgramData não é exibido por padrão, então você precisará modificar suas configurações do Windows para exibir os arquivos e diretórios ocultos.

Com o seu editor de textos preferido, crie o arquivo C:\ProgramData\gemrc com o conteúdo à seguir.

gem: "--no-rdoc --no-ri"

Agora volte ao seu terminal e digite o comando gem install rails. Isso demorar um pouco pois o Rails irá instalar todas as suas dependências.

O próximo passo é criar um novo app do Rails. Para isso, execute o comando rails new hello -d mysql. Por padrão, o Rails irá usar o SQLite; por isso passamos o argumento -d mysql.

Se tudo der certo, seu app foi gerado e as dependências instaladas.

Instalando o Git

Já estamos quase no fim! Agora, vamos instalar o Git. O Git é um sistema de versionamento de arquivos que vem sendo cada vez mais utilizado. Se você ainda não conhece sobre Git, fique ligado no workshop Git no dia-a-dia, que eu dou no HOWTO. Veja também o screencast Começando com Git, publicado pelo Fabio Akita.

Uma das alternativas para se usar Git no Windows é usar o msysGit. Faça o download do instalador. Neste exemplo, irei utilizar a versão Git-1.7.9-preview20120201.exe.

Você terá três opções de instalação. Selecione "Run Git from the Windows Command Prompt".

A próxima opção do instalador é o tipo de conversão de quebras de linha que deve ser utilizado. A menos que você saiba o que está fazendo, selecione a opção "Checkout as-is, commit as-is" para manter o tipo de quebra de linha presente no arquivo, sem fazer nenhuma conversão automática.

Depois que a instalação for finalizada, inicie uma nova janela do terminal. Execute o comando git --version para saber qual a versão instalada.

Eu já tinha usado o SDK do Flex para compilar ActionScript em SWF antes. A grande vantagem é que eu posso usar apenas a linha de comando para gerar os arquivos. Nada de uma IDE extramente lenta, como a do Flash. Além disso, ainda posso usar o Guard para compilar automaticamente sempre que um arquivo for modificado.

Instalando o Flex SDK no Mac OS X

A instalação do SDK é bastante simples. Após fazer o download do SDK, que tem por volta de 164MB, você precisa extrair os arquivos.

$ mkdir -p ~/local/flex
$ cd ~/local/flex
$ curl -O http://fpdownload.adobe.com/pub/flex/sdk/builds/flex4.6/flex_sdk_4.6.0.23201_mpl.zip
$ unzip flex_sdk_4.6.0.23201_mpl.zip

Agora, você precisa adicionar o diretório ~/local/flex/bin ao seu $PATH. Para isso, basta adicionar a linha abaixo ao arquivo ~/.bash_profile ou equivalente.

$ echo 'export PATH="$HOME/local/flex/bin:$PATH"' >> ~/.bash_profile

Recarregue suas configurações com o comando source ~/.bash_profile. Se tudo der certo, o comando which mxmlc está disponível.

$ which mxmlc
/Users/fnando/local/flex/bin/mxmlc

Compilando seu primeiro SWF

Diferente do que você está acostumado, para criar SWFs você usará apenas código ActionScript. Nada de IDE. E isso é uma coisa boa! Crie um arquivo chamado Main.as. Esse arquivo será o arquivo principal, que será equivalente ao stage principal do Flash.

package {
  import flash.display.Sprite;
 
  public class Main extends Sprite {
    public function Main() {
      trace("It works!");
    }
  }
}

Note que o nome do arquivo deve ser igual ao nome da classe, nesse caso, Main. Para compilar o arquivo Main.as você terá que executar o comando mxmlc.

$ mxmlc -output main.swf \
      -as3 \
      -static-link-runtime-shared-libraries \
      -default-size 130 50 \
      -optimize \
      -verbose-stacktraces \
      Main.as
Loading configuration file /Users/fnando/local/flex/frameworks/flex-config.xml
/private/tmp/main.swf (592 bytes)

Nada muito complicado. Estamos gerando o arquivo main.swf à partir do arquivo Main.as. O tamanho do stage será de 130x50. É óbvio que esse exemplo, não faz muita coisa. Se você abrir este arquivo no navegador será presenteado com uma bela tela branca que não faz nada!

Para visualizar uma descrição dos parâmetros aceitos pelo comando mxmlc, execute o comando abaixo.

$ mxmlc -help details list

Usando componentes

Um dos problemas que tive com a compilação foi que componentes não estavam sendo renderizados. O único modo que funcionou para mim foi exportar todos os componentes como uma biblioteca compartilhada. Como você precisa do Flash para fazer isso, resolvi disponibilizar este arquivo em http://f.simplesideias.com.br/components.swc.

Vamos atualizar nossa classe Main para adicionar um botão. Ao clicá-lo, iremos alterar seu label para "Clicked".

package {
  import flash.display.Sprite;
  import fl.controls.Button;
  import flash.events.MouseEvent;
 
  public class Main extends Sprite {
    public function Main() {
      var button:Button = new Button();
 
      button.label = "Click me!";
      button.move(15, 15);
 
      button.addEventListener(MouseEvent.MOUSE_DOWN, function(event:MouseEvent):void {
        event.target.label = "Clicked!";
      });
 
      addChild(button);
    }
  }
}

Para criar novos botões, você precisa carregar a classe flash.controls.Button, disponibilizada pelo arquivo components.swc. Esse arquivo deve ser carregado pela linha de comando.

$ mxmlc -output main.swf \
      -as3 \
      -static-link-runtime-shared-libraries \
      -default-size 130 50 \
      -optimize \
      -verbose-stacktraces \
      -include-libraries=`pwd`/components.swc \
      Main.as

O resultado final será algo como a imagem abaixo.

Compilando os arquivos automaticamente

Uma das melhores mudanças nesse processo é que agora posso executar tudo pela linha de comando. E posso, inclusive, cmpilar os arquivos automaticamente usando bibliotecas como o Guard. Primeiro, vamos instalar as gems necessárias.

$ gem install guard guard-shell

Na raíz de seu projeto, crie o arquivo Guardfile com o conteúdo à seguir.

guard :shell do
  watch(/\.as$/) do
    system <<-SHELL
      mxmlc -output main.swf \
            -as3 \
            -static-link-runtime-shared-libraries \
            -default-size 130 50 \
            -optimize \
            -verbose-stacktraces \
            -include-libraries `pwd`/components.swc \
            Main.as
    SHELL
  end
end

O código acima irá compilar o SWF toda vez que uma alteração for detectada em arquivos com a extensão .as. Para iniciar o monitor, basta executar o comando guard.

Finalizando

Por pior que o Flash seja, ele ainda é imbatível em uma coisa: broadcast de áudio e vídeo. É muito fácil publicar sua webcam e seu microfone. Já que não existe nenhuma outra alternativa viável, evitar o uso da IDE já ajuda bastante no dia-a-dia.

Para você ter uma ideia de como o Flex é (sic) flexível, veja o que fiz para o Presentta até agora:

Desenvolvedores Ruby estão mais acostumados em definir objetos pelo que eles podem fazer, do que por seu tipo. Esta técnica é chamada de duck typing.

Se anda como um pato e faz barulho como um pato, então deve ser um pato. E o interpretador ficará feliz em fazer com que o objeto seja tratado como um pato. Na prática, isso significa que em vez de fazer verificações de tipo de um objeto, você deve se preocupar se este objeto é capaz de executar o método que você precisa.

Pegue como exemplo strings, arquivos e arrays. As classes Array, File e String implementam o método de instância <<, que quase sempre significa append. Você pode se aproveitar desta interface para criar, por exemplo, uma classe de log que não se importa com o tipo de objeto que irá armazenar esses logs.

class SimpleLogger
  def initialize(io)
    @io = io
  end
 
  def log(message)
    @io << "#{Time.now} - #{message}\n"
  end
end

A classe SimpleLogger consegue enviar os logs para arrays, strings, arquivos e, se quiser, para qualquer outro objeto que implemente o método <<.

O Ruby realmente abraça o duck typing por toda a linguagem. Diversos protocolos exigem que o objeto apenas implemente um método to_<protocol>. Muitas operações que envolvem arrays, por exemplo, exigem que o objeto do lado direito da expressão apenas implemente o método to_ary.

class Numbers
  def to_ary
    [4, 5, 6]
  end
end
 
[1, 2, 3] + Numbers.new
#=> [1, 2, 3, 4, 5, 6]

A classe Hash, por exemplo, permite que você una dois objetos, desde que o método to_hash seja implementado.

class Configuration
  def to_hash
    {root: "/etc"}
  end
end
 
config = Configuration.new
 
{name: "Custom config"}.merge(config)
#=> {:name=>"Custom config", :root=>"/etc"}

Não é preciso dizer que este tipo de protocolo por convenção permite criar códigos muito mais flexíveis, com extrema facilidade.

Isso não significa que saber o tipo de objetos não seja útil. Veja, por exemplo, as operações matemáticas. Qualquer objeto pode ser convertido em números. Para isso, basta implementar o método coerce, que recebe o objeto que está solicitando a coerção. O exemplo abaixo mostra como criar uma classe cuja instância pode ser convertida em números inteiros e flutuantes, mas não em instâncias da classe BigDecimal.

class NumberOne
  def coerce(object)
    case object
    when Integer
      [object, 1]
    when Float
      [object, 1.0]
    else
      raise TypeError, "#{self.inspect} can't be coerced into #{object.class}"
    end
  end
end
 
puts 1 + NumberOne.new
#=> 2
 
puts 1.0 + NumberOne.new
#=> 2.0
 
require "bigdecimal"
puts BigDecimal.new("1.0") + NumberOne.new
#=> TypeError: FakeNumber can't be coerced into BigDecimal

O duck typing vai além de simples regras; é um estilo de programação. Antes de exigir tipos de objetos, pergunte-se se isso é realmente necessário. Às vezes, o tipo do objeto é muito importante, mas muitas vezes isso simplesmente não importa.

NOTA: Este artigo foi tirado do e-book "Conhecendo o Ruby" que estou escrevendo. Se inscreva na newsletter do HOWTO e saiba quando ele for lançado.

O processo em si é bastante simples. Primeiro, você deve organizar todos os seus arquivos em algum diretório, por exemplo, some_site/public. Este diretório pode conter arquivos HTML, JavaScript e CSS. Na prática, você pode servir qualquer tipo de arquivo.

Crie o arquivo some_site/config.ru. Nós iremos servir os arquivos estáticos com Rack. Primeiro, nós vamos criar um aplicativo usando o Rack::Builder. Este aplicativo usará um middleware que redirecionará a requisição na raíz do site para o arquivo some_site/public/index.html.

Todos os outros arquivos do diretório some_site/public serão servidos com o Rack::Directory.

app = Rack::Builder.new do
  use Rack::Static, urls: {"/" => "index.html"}, root: "public"
  run Rack::URLMap.new({
    "/" => Rack::Directory.new("public")
  })
end
 
run app

Crie também um arquivo Gemfile, que terá como única dependência o próprio Rack. Este arquivo Gemfile deve estar na raíz do seu projeto e será algo como isto.

source :rubygems
gem "rack", "~> 1.3"

Execute o comando bundle install para instalar a dependência e gerar o arquivo Gemfile.lock.

Na raíz do projeto, inicie um novo repositório Git e faça o commit inicial.

$ cd some_site
$ git init
Initialized empty Git repository in /Users/fnando/Sites/some_site/.git/
$ git add .
$ git ci -am "Initial commit"
[master (root-commit) 54e37c9] Initial commit
 4 files changed, 31 insertions(+), 0 deletions(-)
 create mode 100644 Gemfile
 create mode 100644 Gemfile.lock
 create mode 100644 config.ru
 create mode 100644 public/index.html

Agora, basta criar seu aplicativo no Heroku. Se você ainda não possui uma conta configurada, veja o que é preciso fazer. Se tudo estiver certo, você pode criar um novo aplicativo com o comando heroku apps:create <seu-app>. O stack padrão é baseado no Ruby 1.9, então estamos muito bem acompanhados.

$ heroku apps:create some-site
Creating some-site... done, stack is bamboo-mri-1.9.2
http://some-site.heroku.com/ | git@heroku.com:some-site.git
Git remote heroku added

Para fazer o deploy, execute o comando git push heroku.

$ git push heroku 
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 768 bytes, done.
Total 7 (delta 0), reused 0 (delta 0)
 
-----> Heroku receiving push
-----> Ruby/Rack app detected
-----> Gemfile detected, running Bundler version 1.0.7
       Unresolved dependencies detected; Installing...
       Using --without development:test
       Fetching source index for http://rubygems.org/
       Installing rack (1.3.5) 
       Using bundler (1.0.7) 
       Your bundle is complete! It was installed into ./.bundle/gems/
-----> Compiled slug size is 152K
-----> Launching... done, v3
       http://some-site.heroku.com deployed to Heroku
 
To git@heroku.com:some-site.git
 * [new branch]      HEAD -> master

Certifique-se que está tudo funcionando. Basta acessar a URL exibida após o deploy que, neste caso, é http://some-site.heroku.com.

Obviamente, usar esta URL não é nada profissional. Você pode configurar seu próprio domínio, sem gastar nada (se não me engano, você precisa adicionar o seu cartão de crédito, mesmo sendo funcionalidades gratuitas). Adicione a extensão "Custom Domains".

$ heroku addons:add custom_domains:basic
-----> Adding custom_domains:basic to some-site... done, (free)

Adicione também a extensão "Zerigo DNS".

$ heroku addons:add zerigo_dns:basic
-----> Adding zerigo_dns:basic to some-site... done, (free)

Finalmente, você pode adicionar seu domínio com o comando heroku domains:add <seu domínio>.

$ heroku domains:add somesite.com
Added somesite.com as a custom domain name for some-site

Você precisará adicionar o registro de DNS que irá redirecionar www.somesite.com para somesite.com no site da Zerigo. Para acessar este painel de controle, execute o comando heroku addons:open zerigo_dns:basic.

$ heroku addons:open zerigo_dns:basic
Opening zerigo_dns:basic for some-site...

Clique no botão "Configure".

Você será redirecionado para uma tela como esta:

Clique no link "Host > Add" para adicionar um novo registro. No campo "Host", digite "www", defina o tipo do registro como sendo "Redirect" e, por último, digite a URL de destino no campo "Data".

O Zerigo DNS funciona bem para poucos acessos, mas você pode rapidamente ultrapassar o limite do plano básico. Neste caso, sugiro que dê uma olhada no serviço oferecido pela DNSimple, que custa apenas US$3 para 10 domínios e é extremamente simples de configurar; existe até uma opção de configuração com apenas um clique para aplicativos hospedados no Heroku.

É muito comum termos condições em nossas views. Objetos possuem diferentes estados e muitas vezes precisamos mostrar esses estados visualmente. E normalmente começamos pelo caminho mais fácil, que é adicionar ifs na view.

Acontece que isso não precisa ser sempre assim. Neste artigo vou mostrar como funciona um pattern chamado Presenter, que permite diminuir/remover a complexidade de views e controllers.

Começando com o seu próprio presenter

A primeira coisa que você precisa detectar é que tipo de lógica é possível extrair de sua view. Algumas coisas mais genéricas fazem mais sentido serem extraídas como helpers. Outras, como ifs para determinar qual partial deve ser renderizada provavelmente devem ser movidas para seu presenter.

Imagine que você tenha uma view como esta:

<h1><%= @product.name %></h1>
 
<% if @product.description %>
  <p class="description"><%= @product.more %></p>
<% end %>

Não se deixe enganar por esse tipo de lógica. Embora pareça inofensiva, coisas como esta podem sair do controle rapidamente.

Esta view precisa de uma variável @product que deve ser definida em nosso controller:

class ProductsController < ApplicationController
  def show
    @product = Product.find(params[:id])
  end
end

Agora, precisamos de uma classe que irá "envelopar" nossa instância da classe Product. Crie o arquivo app/presenters/product_presenter.rb. Como este diretório não está no load path do Rails, vamos ter que fazer uma configuração no arquivo config/application.rb.

module HOWTO
  class Application < Rails::Application
    # ... 
    config.autoload_paths << config.root.join("app/presenters").to_s
  end
end

Volte ao arquivo product_presenter.rb e crie a classe ProductPresenter.

class ProductPresenter
  def initialize(product)
    @product = product
  end
end

Esta classe será responsável por expor todos os atributos que nossa view irá acessar. Em vez de definir cada um dos métodos manualmente, podemos apenas delegar as chamadas para o objeto. Para fazer isso, vamos usar o método Module#delegate, adicionado pelo ActiveSupport.

class ProductPresenter
  delegate :name, :description, to: :"@product"
 
  def initialize(product)
    @product = product
  end
end

Qualquer chamada aos métodos ProductPresenter#name e ProductPresenter#description serão delegadas para o objeto que foi armazenado em @product. Você também poderia utilizar o módulo Forwardable, mas a versão adicionada pelo ActiveSupport é mais elegante.

Agora, podemos remover aquele if. Se você não se lembra mais dele, dê uma última olhadela, pois logo ele não mais existirá! Adicione o método description. Faça com que este método retorne o parágrafo com a descrição, caso ela tenha sido definida. Como é necessário retornar uma tag HTML, vamos usar o helper content_tag.

class ProductPresenter
  delegate :name, to: :"@product"
 
  def initialize(product)
    @product = product
  end
 
  def description
    if @product.description.present?
      helpers.content_tag(:p, @product.description, class: "description")
    end
  end
 
  private
  def helpers
    ApplicationController.helpers
  end
end

Altere o controller para que ele passe a instância da classe Product para o presenter.

class ProductsController < ApplicationController
  def show
    @product = ProductPresenter.new(Product.find(params[:id]))
  end
end

Para finalizar, basta modificar nossa view.

<h1><%= @product.name %></h1>
<%= @product.description %>

Para o caso de partials, o funcionamento é basicamente o mesmo. No entanto, em vez de fazer a renderização no próprio presenter, é mais fácil retornar o nome da partial que deve ser renderizada.

Imagine que nossa view tenha mais um if que irá renderizar uma partial diferente para produtos gratuitos.

<% if @product.paid? %>
  <%= render "order", product: @product %>
<% else %>
  <%= render "download", product: @product %>
<% end %>

Podemos implementar um método chamado ProductPresenter#checkout_partial que irá fazer aquele if, retornando apenas o nome da partial.

class ProductPresenter
  delegate :name, to: :"@product"
 
  def initialize(product)
    @product = product
  end
 
  def description
    if @product.description.present?
      helpers.content_tag(:p, @product.description, class: "description")
    end
  end
 
  def checkout_partial
    @product.paid? ? "order" : "download"
  end
 
  private
  def helpers
    ApplicationController.helpers
  end
end

E na nossa view, basta renderizar o retorno do método ProductPresenter#checkout_partial.

<%= render @product.checkout_partial, product: @product %>

A esta altura, você já deve ter percebido como presenters podem remover completamente a lógica das views. Embora seja muito fácil fazer isso sem a necessidade de bibliotecas, algumas coisas precisam ser implementadas toda vez. É o caso de helpers, rotas e métodos de internacionalização.

Pensando nisso, decidi extrair aquela organização de código que eu estava utilizando em uma gem chamada simple_presenter.

Usando o simple_presenter

Para instalar, basta executar o comando abaixo:

$ gem install simple_presenter

Lembre-se de adicionar a gem ao arquivo Gemfile.

source :rubygems
gem "rails", "3.1.3"
gem "simple_presenter", "~> 0.1"

Aquele mesmo presenter que definimos pode ser trocado por algo como isto:

class ProductPresenter < Presenter
  expose :name, :description
 
  def description
    if @subject.description.present?
      h.content_tag(:p, @subject.description, class: "description")
    end
  end
 
  def checkout_partial
    @subject.paid? ? "order" : "download"
  end
end

Note que não precisamos mais definir o método ProductPresenter#initialize, nem o método ProductPresenter#helpers. Também tivemos que mudar todas as referências a @product para @subject; isso é necessário porque, por padrão, o nome do objeto que receberá os métodos delegados é @subject.

O simple_presenter adiciona os métodos helpers e h que permite acessar os helpers do Rails. Os helpers de rotas podem ser acessados com os métodos routes e r. E, finalmente, os helpers de internacionalização podem ser acessados por translate e t, e localize e l.

Escrevendo testes

Escrever testes para presenters é muito simples. No caso do RSpec, basta criar o diretório spec/presenters. Aquele nosso presenter pode ter testes como este:

require "spec_helper"
 
describe ProductPresenter do
  let(:product) { mock(Product, name: "Some product") }
  subject { described_class.new(product) }
 
  its(:name) { should eql("Some product") }
 
  describe "#description" do
    it "returns content" do
      product.stub description: "Some description"
      expected = %[<p class="description">Some description</p>]
 
      subject.description.should eql(expected)
    end
 
    it "returns no message" do
        subject.description.should be_blank
    end
  end
 
  describe "#checkout_partial" do
    it "returns partial for paid products" do
      product.stub paid?: true
      subject.checkout_partial.should eql("order")
    end
 
    it "returns partial for free products" do
      product.stub paid?: false
      subject.checkout_partial.should eql("download")
    end
  end
end

Finalizando

Você deve ter percebido que presenters permitem tornar suas views muito mais simples. Além disso, eles tem a vantagem de serem fáceis de testar.

A coisa mais difícil dos presenters é se acostumar com eles. Mas depois que você se acostuma, dificilmente terá uma view complicada e também nem vai querer deixar de usá-los!

UPDATE 1: O Valim me lembrou que à partir do Rails 3 não é mais preciso adicionar diretórios app/*, pois o Rails faz isso automaticamente. Eu sabia disso, mas o costume ainda permanece.

No HOWTO as aulas são gravadas para quem quer assistir depois. O grande problema é que, como as aulas são longas (por volta de 2 horas de duração), os vídeos ficam muito grandes. Tentando resolver este problema, consegui encontrar a configuração perfeita para quem precisa exportar vídeos longos.

Antes

Antes de encontrar estas configurações, não tinha muito o que fazer. Eu modificava o preset Web – High como o screenshot abaixo.

A minha última tentativa de exportação de uma aula de 2h15 levou 4 horas para exportar o vídeo e resultou em um arquivo de 665MB. A qualidade ficou muito boa, mas o tamanho do arquivo é, obviamente, um problema.

Antes, eu usava o iShowU e um vídeo com a mesma duração ficava por volta de 300MB, o que já é um tamanho extremamente razoável. A grande vantagem do iShowU é que você não precisa exportar o vídeo depois de gravá-lo (obviamente isso tem um ponto negativo que é a falta de recursos que o ScreenFlow oferece, mas se você não precisa, nem vai sentir falta) e que tornava a liberação do vídeo muito mais rápida, já que bastava fazer o upload do vídeo.

Mas, então, porque deixei de usar o iShowU? Bem, nas duas últimas gravações tive problemas com ele: um dos vídeos ficou sem áudio e o outro ficou com a imagem fixa. E esses erros aconteceram mais ou menos no meio do vídeo, sem nenhuma explicação.

Depois

Dado o tamanho do arquivo gerado pelo ScreenFlow, comecei a procurar configurações melhores que reduzissem drasticamente o tamanho do vídeo. Fazendo algumas buscas madrugada adentro, encontrei esse artigo no blog da própria Telestream, empresa que criou o ScreenFlow.

Neste artigo eles mostram como configurar o ScreenFlow com um codec chamado x264. Mesmo seguindo este artigo, você precisará modificar algumas outras configurações que não são mencionadas.

Para instalar este codec, que é gratuito, basta você fazer o download no site do desenvolvedor. Depois, copie o arquivo x264Encoder.component para o diretório ~/Library/QuickTime. Pronto! Agora, basta configurar o ScreenFlow com este novo codec. Reinicie o ScreenFlow para que ele faça a detecção.

Na hora de exportar (⌘+E), clique no botão “Customize > Video > Settings”. Na opção “Compression Type”, selecione o codec “x264Encoder”. Altere as configurações desta janela para as mesmas do screenshot abaixo.

Você vai precisar configurar também o próprio codec. Para isso, nesta mesma janela clique no botão “Options”. Isso abrirá uma janela com todas as opções de personalização do codec. Modifique as opções como o screenshot abaixo.

Por último, se o seu screencast é baseado em voz, com quase nenhuma trilha sonora, você também pode modificar as configurações do áudio, diminuindo ainda mais o tamanho do vídeo exportado. Basta você modificar a qualidade do áudio para 64kbps de bitrate, como no screenshot abaixo.

Meu Macbook Pro não é lá essas coisas (Mid 2009, com processador Core 2 Duo 2.26 GHz), então demorou um pouquinho. Depois de 6 horas, aquele mesmo vídeo que tinha ficado com 665MB de tamanho foi exportado como 266MB.

O meu servidor agradece, e os alunos também!

class Person
  class << self
    def description
      "It defines an user"
    end
  end
end

No exemplo acima estamos definindo uma método de classe Person.description. Infelizmente, quando a quantidade de métodos é muito grande, a legibilidade fica prejudicada; você não consegue saber rapidamente se este método é de classe ou instância.

Na maioria das vezes essa escolha é feita sem um objetivo; a explicação é que é possível salvar alguns caracteres ao não digitar self de novo e de novo.

Particularmente, acho que o código acima fica muito mais legível quando escrito desta forma:

class Person
  def self.description
    "It defines an user"
  end
end

Isso não significa que você não deva usar nunca a classe singleton. Eu uso constantemente. Mas não para definir métodos dessa maneira. Eu gosto, por exemplo, de definir atributos.

class Config
  class << self
    attr_accessor :root_dir
  end
end

Um outro uso é quando preciso modificar alguma classe quando um hook é executado, como em plugins do ActiveRecord.

module MyPlugin
  module ClassMethods; end
  module InstanceMethods; end
 
  def self.extended(base)
    class << base
      include InstanceMethods
      extend ClassMethods
    end
  end
end
 
ActiveRecord::Base.extend(MyPlugin)

O método Module#include é privado. Uma alternativa seria injetar este módulo com o método Object#send. Eu só não faço isso pois terei que estender este objeto com os métodos de classe, então prefiro usar a classe singleton para manter o código mais legível.

Finalizando

Definir muitos métodos com a classe singleton pode ser prático, mas prejudica a legibilidade e você não quer que isto aconteça. Prefira a classe singleton para métodos que não estão disponíveis no contexto da classe como o attr_accessor. Não é porque você pode fazer algo, que você deve fazê-lo mesmo assim.

Hoje é meu último dia na Locaweb. Depois de quase dois anos (tudo isso, acredita?), decidi sair da minha zona de conforto. Após bater um papo com um dos meus chefes (que na verdade era para ser uma comida de rabo, em inglês, feita de forma elegante), percebi que tinha passado da hora de eu seguir o meu próprio caminho. Com muitas coisas rolando ao mesmo tempo, eu já não conseguia me dedicar à Locaweb como as pessoas esperavam que eu fizesse. Pensei bastante sobre tudo isso e sempre chegava à mesma conclusão. Era hora de seguir em frente.

A Locaweb é uma grande empresa para se trabalhar. Pessoas inteligentes, ambiente descontraído… se você entrar lá e estiver disposto à aprender, vai sair muito mais esperto. Eu aprendi muita coisa lá e também fiz muitas amizades (vocês sabem quem são). Não era minha intenção sair neste momento, mas tem coisas que vem para dar um chacoalhão, meio que dizendo “E aí? Vamos em frente de verdade agora?”.

Bem. E agora, qual é o plano? Continuarei fazendo as coisas que já fazia. O Codeplane vai muito bem, obrigado. Isso não significa que não tenha coisas para melhorar. Já estou trabalhando em um bug tracker, que está demorando mais do que eu tinha planejado, por causa dessa minha saída da Locaweb. Também quero implementar outras coisas como webhooks e, quem sabe, a tão pedida visualização de código, nos mesmos moldes do Github.

Tem o HOWTO, que está muito bem, também. Sempre com turmas lotadas (mais de 300 pessoas já passaram por lá), consigo fazer ali algo que sempre quis: ensinar. Para quem acha que caí de paraquedas nisso, minha intenção desde que estava na faculdade era ensinar. Era isso que eu fazia no meu estágio, e era isso que eu pretendia fazer profissionalmente no futuro. Consegui suprir essa minha necessidade por algum tempo escrevendo tutoriais, sempre pensando em quem fosse ler. Quando comecei a aprender Node.js e consegui criar uma versão realmente útil do Presentta, vi que eu podia investir nisso. Recebi bastante elogios na forma como os workshops são apresentados, então acho que estou fazendo um bom trabalho.

Existem outras ideias que irei tirar do papel aos poucos. Alguns produtos que quero fazer… enfim, o futuro promete! Eu tenho plena certeza de que a jornada será dura. Mais dura do que qualquer coisa que já enfrentei até então. Tenho picos de medo, alternados com aquele sentimento de que tudo vai dar certo. Sorte a minha que tenho uma esposa que me encoraja em tudo, um pai que sempre está lá quando preciso, e amigos que acreditam em mim. Mas mesmo assim, desejem-me sorte. Nunca é de mais.

Não é que eu não goste do Github*. O único problema do Github é que os limites são muito baixos. O plano mais básico de US$ 7 dá direito a 5 repositórios privados e apenas 1 colaborador.

A grande questão é que tenho uns 30 repositórios privados. Neste caso, eu teria que assinar um plano "Business", que não sairia por menos US$ 100, ou seja, totalmente inviável.

O Dropbox + Servidor funcionou por um tempo, mas uma coisa começou a me irritar. Todo o processo de criação dos repositórios era manual.

$ mkdir repo.git
$ cd repo
$ git init --bare

E a coisa piorava quando eu precisava dar permissão para alguém acessar algum repositório privado. Foi quando decidi fazer o meu próprio "Github". Trabalhei em cima da ideia por algum tempo, mostrei para algumas pessoas e finalmente resolvi tirá-la do papel. Foi assim que nasceu o Codeplane.

O Codeplane é um serviço que começa como um Git hosting, mas minha intenção é evoluir para um produto para pequenos times e freelancers. Tenho muitas outras ideias que apenas o tempo e o uso do produto irão dizer se são viáveis. O Codeplane ainda não tem preço, mas devo fazer isso nos próximos dias.

Se você usa Git e precisa de repositórios privados, dê uma olhada no Codeplane. Ele também está disponível na versão em português.

*Agora, só uso o Github para manter meus projetos OpenSource. Nesse ponto ele é imbatível!