Estou transformando o Presentta, que hoje nada mais é que um hack com um monte de tarefas que precisam ser feitas manualmente, em um produto. Decidi começar este novo projeto do zero, então decidi fazer algo diferente.

Em vez de ter um aplicativo monolítico, responsável por todas as partes do sistema, resolvi quebrar este sistema em diversos sistemas menores, cada um com sua responsabilidade. No Presentta, por exemplo, já tenho a parte de realtime com Node.js, interface web com Rails e API com Goliath, mas devem entrar outros sistemas mais para a frente.

Uma das coisas que pensei em fazer foi compartilhar modelos entre os sistemas Ruby. Quando eu ainda estava na WebCo, tínhamos tentado fazer algo semelhante usando submódulos do Git, sem muito sucesso. Lembre-se que naquela época não existia o Bundler. E foi justamente o Bundler que permitiu fazer esse compartilhamento de forma muito simples, como você pode conferir abaixo.

Criando o repositório de modelos

O primeiro passo foi definir o repositório de modelos que seria compartilhado entre os sistemas. No Bundler, todos os projetos precisam ter um gemspec, que é utilizado para empacotar uma biblioteca como RubyGem. No meu projeto, criei um arquivo chamado presentta-models.gemspec que tem o seguinte conteúdo.

# -*- encoding: utf-8 -*-
$:.push File.expand_path("../lib", __FILE__)
require "presentta/models/version"
 
Gem::Specification.new do |s|
  s.name        = "presentta-models"
  s.version     = Presentta::Models::Version::STRING
  s.platform    = Gem::Platform::RUBY
  s.authors     = ["Nando Vieira"]
  s.email       = ["fnando.vieira@gmail.com"]
  s.homepage    = "http://rubygems.org/gems/presentta-models"
  s.summary     = "Share ActiveRecord models between Presentta applications."
  s.description = s.summary
 
  s.files         = `git ls-files`.split("\n")
  s.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
  s.executables   = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
  s.require_paths = ["lib"]
 
  s.add_dependency "mysql2", "~> 0.3"
  s.add_dependency "activerecord", "~> 3.2"
  s.add_dependency "simple_auth", "~> 1.4"
  s.add_dependency "validators", "~> 1.0"
  s.add_dependency "permalink", "~> 1.2"
  s.add_dependency "defaults", "~> 0.1"
 
  s.add_development_dependency "rake", "~> 0.9"
  s.add_development_dependency "rspec", "~> 2.8"
  s.add_development_dependency "factory_girl"
  s.add_development_dependency "factory_girl-preload"
end

Esse arquivo contém todas as dependências, como plugins do ActiveRecord e bibliotecas que serão usadas nos testes dos modelos.

Você também vai precisar definir o seu Gemfile. Neste caso, nós iremos utilizar as mesmas dependências definidas no arquivo gemspec.

source :rubygems
gemspec

O arquivo que irá iniciar a biblioteca é o lib/presentta/models.rb. Nele, além de carregar todas as gems que vou usar, ainda defino as configurações do ActiveRecord. Abaixo você pode conferir apenas as partes importantes.

require "mysql2"
require "active_record"
 
require "presentta/models/user"
require "presentta/models/courses"
require "presentta/models/your_model_here"
 
ActiveRecord::Base.timestamped_migrations = false
ActiveRecord::Base.attr_accessible(nil)
ActiveRecord::Migrator.migrations_paths = File.expand_path("../models/migrations", __FILE__)
 
module Presentta
  module Models
    def self.connect_with(file, environment)
      fail "#{file.inspect} should be a configuration file" unless file && File.exist?(file)
      ActiveRecord::Base.configurations = YAML.load_file(file)
      ActiveRecord::Base.establish_connection(environment)
    end
  end
end

Como será preciso estabelecer a conexão de diferentes lugares, preferi centralizar esta conexão à partir do método Presentta::Models.connect_with. Com isso já é possível configurar, por exemplo, as rake tasks que irão executar as migrações.

Uma das premissas do repositório de modelos era ter um modo de executar as migrations. Para fazer isso, criei um diretório lib/presentta/models/migrations, que tem todas as migrações, como 001_create_users.rb. Perceba que não estou usando o timestamp; como não vou usar os geradores do Rails, é mais prático escrever 001_create_users.rb que 20120306135200_create_users.rb, alteração realizada quando utilizei a configuração ActiveRecord::Base.timestamped_migrations = false.

O arquivo lib/presentta/models/rake.rb será carregado tanto pelo arquivo Rakefile do repositório de modelos, quando pelo aplicativo Rails.

ENV["RAILS_ENV"] ||= "development"
 
require "presentta/models"
require "rails"
 
Presentta::Models.connect_with(ENV["DATABASE_CONFIG"], Rails.env)
require "active_record/railtie"
load "active_record/railties/databases.rake"
 
task(:environment) {}
 
namespace :db do
  task(:load_config).clear_prerequisites.clear_actions
end

Duas coisas que você deve notar aqui. Para poder usar as rake tasks de fora do Rails, precisei definir a tarefa environment para um bloco que não faz nada. No Rails, ela existe e é responsável por inicializar o ambiente. Outra coisa importante é que removi a tarefa db:load_config que, basicamente, define o diretório de migrações e o arquivo de configuração. Mas atenção: ao sobrescrever esta tarefa, as migrações de Rails engines não serão detectadas e, por este motivo, devem ser copiadas para o diretório lib/presentta/models/migrations. No meu caso não uso nenhuma engine, então isso não é um problema.

Agora, no arquivo Rakefile da raíz do repositório de modelos, é preciso carregar as rake tasks do banco de dados. Como uso RSpec, também já coloquei sua tarefa neste arquivo.

require "rspec/core/rake_task"
RSpec::Core::RakeTask.new
 
ENV["DATABASE_CONFIG"] = File.expand_path("../database.yml", __FILE__)
require "presentta/models/rake"

O arquivo de configuração do ActiveRecord é lido à partir da variável de ambiente DATABASE_CONFIG, que aqui definimos para um arquivo na raíz do repositório. Nada diferente do que você já está acostumado a ver no Rails.

defaults: &DEFAULTS
  adapter: mysql2
  encoding: utf8
  reconnect: true
  pool: 5
  host: localhost
  username: root
  password:
 
development:
  <<: *DEFAULTS
  database: presentta_development
 
test:
  <<: *DEFAULTS
  database: presentta_test

Para listar todas as tarefas disponíveis, execute o comando rake -T db.

$ rake -T db
rake db:create          # Create the database from config/database.yml for the current Rails.en...
rake db:drop            # Drops the database for the current Rails.env (use db:drop:all to drop...
rake db:fixtures:load   # Load fixtures into the current environment's database.
rake db:migrate         # Migrate the database (options: VERSION=x, VERBOSE=false).
rake db:migrate:status  # Display status of migrations
rake db:rollback        # Rolls the schema back to the previous version (specify steps w/ STEP=n).
rake db:schema:dump     # Create a db/schema.rb file that can be portably used against any DB s...
rake db:schema:load     # Load a schema.rb file into the database
rake db:seed            # Load the seed data from db/seeds.rb
rake db:setup           # Create the database, load the schema, and initialize with the seed da...
rake db:structure:dump  # Dump the database structure to db/structure.sql. Specify another file...
rake db:version         # Retrieves the current schema version number

Se tudo estiver configurando de forma correta, você conseguirá ver qual a versão do seu banco de dados executando o comando rake db:version.

$ rake db:version
Current version: 7

Do lado do repositório de modelos, você não precisa fazer mais nada!

Configurando o Rails

Agora você precisa configurar sua aplicação Rails para utilizar o repositório de modelos. O primeiro passo é configurar o arquivo Gemfile. Idealmente, seria interessante apontar os ambientes de desenvolvimento e teste para o repositório local, e o ambiente de produção para o repositório do Codeplane. Mas isso não é possível no Bundler, embora seja uma funcionalidade prevista para o release 1.1 (estou usando o Bundler 1.1 RC7 e ainda não é possível). Como ainda estou na fase de desenvolvimento, vou deixar para me preocupar com isso quando chegar a hora. Por enquanto, meu arquivo Gemfile é algo como isto:

source :rubygems
 
gem "rails"                   , "3.2.2"
gem "responders"              , "~> 0.8"
gem "simple_form"             , "~> 2.0"
gem "simple_presenter"        , "~> 0.1"
gem "swiss_knife"             , "~> 1.0"
 
group :development, :test do
  gem "presentta-models"      , :path => "~/Sites/presentta-models"
  gem "thin"                  , "~> 1.3"
  gem "awesome_print"         , :require => false
  gem "pry"                   , :require => false
  gem "rspec-rails"           , "~> 2.7"
end
 
group :test do
  gem "factory_girl"          , "~> 2.2"
  gem "factory_girl-preload"  , "~> 1.0"
  gem "test_notifier"         , "~> 0.4", :require => "test_notifier/runner/rspec"
  gem "spork"                 , "~> 0.9.0"
  gem "capybara"              , "~> 1.1"
end

O seu arquivo config/application.rb também precisará ser modificado. A parte importante aqui são os arquivos que o Rails irá carregar ou, melhor dizendo, não irá carregar, como o arquivo active_record/railtie.

require File.expand_path("../boot", __FILE__)
 
require "rails"
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
 
Bundler.require(:default, Rails.env) if defined?(Bundler)
 
module Presentta
  class Application < Rails::Application
    config.time_zone = "Brasilia"
    config.i18n.load_path += Dir[Rails.root.join("config/locales/**/*.yml").to_s]
    config.i18n.default_locale = :"pt-BR"
    config.encoding = "utf-8"
    config.filter_parameters += [:password]
    config.assets.enabled = false
    config.generators.assets = false
    config.generators.test_framework :rspec, :fixtures => false, :view_specs => false
  end
end

Para estabelecer a conexão com o banco de dados, nós precisaremos utilizar o método Presentta::Models.connect_with. Crie um arquivo config/initializers/activerecord.rb com o conteúdo à seguir.

Presentta::Models.connect_with(
  Rails.root.join("config/database.yml").to_s,
  Rails.env
)
 
require "active_record/railtie"

Finalmente, é preciso carregar as rake tasks. Crie o arquivo lib/tasks/db.rake.

ENV["DATABASE_CONFIG"] = File.expand_path("../../../config/database.yml", __FILE__)
require "presentta/models/rake"

Assim como no repositório de modelos, você pode ver as rake tasks disponíveis com o comando rake -T db.

Configurando outros apps

Seus outros aplicativos como Goliath e Sinatra também pode usar os modelos. Para isso, além de definir o repositório de modelos no Gemfile, você também precisará fazer a conexão usando as linhas à seguir.

require "presentta-models"
 
Presentta::Models.connect_with(
  File.expand_path("../database.yml", __FILE__),
  ENV["RACK_ENV"]
)

Quando alguém decide procurar algum serviço para fazer este papel, é meio óbvio que você quer algo simples e que funcione. Além disso, você quer fazer negócios com uma empresa que considere o vendedor como um parceiro. O mercado brasileiro possui algumas alternativas para quem precisa fazer cobranças na Internet mas, infelizmente, nenhuma delas consegue preencher todos esses requisitos. Para ser considerado um bom serviço, é preciso que ele atue em várias frentes de forma competente.

Junto ao desenvolvedor, fazendo um serviço fácil de usar e com uma documentação que pode ser facilmente acessada, com vários exemplos.

Junto ao vendedor, sendo flexível e provendo o máximo de informações relativas ao pagamento, sempre de forma descomplicada. O serviço de cobrança também deve considerar o vendedor como um parceiro e, em um primeiro momento, estar sempre do seu lado. Oferecer serviços como cobrança recorrente e checkout de pagamentos através de formulários HTML e API também é muito importante.

Junto ao comprador, oferecendo uma interface realmente simples de usar, que funcione em diversos navegadores e dispositivos diferentes com mobiles e tablets.

Em todas as frentes uma coisa extremamente importante é ter um excelente serviço de atendimento ao cliente. Fóruns, chats, suporte através de helpdesk e blog posts. São inúmeras as possibilidades mas, independente dos canais escolhidos, o atendimento deve ser rápido. Muito rápido.

As alternativas disponíveis no Brasil

O Brasil possui inúmeros serviços de pagamento como PagSeguro, MoIP e PayPal. Nesta comparação, você poderá ler as minhas experiências (não muito boas) com estes serviços. Existem outros meios de pagamento como MercadoPago e Pagamento Digital, mas nunca usei nenhum deles e, por este motivo, ficaram de fora desta comparação.

PagSeguro

Em 2007 o UOL comprou a BRPay, que veio a se tornar o PagSeguro que conhecemos. Um dos principais meios de pagamentos da categoria, foi por muito tempo um dos serviços que mais deixou a desejar. Isso está mudando agora que foi lançada a nova versão da API, embora ainda não possua uma série de funcionalidades disponíveis em outros serviços como MoIP e PayPal.

Características:

• Tarifa de cartão de crédito: 6,4% + R$ 0,40
• Demais tarifas: 2,9% + R$ 0,40
• Tarifa de parcelamento: 1,99%/mês, cobrada do comprador ou do vendedor
• Cobrança por formulário HTML ou e-mail

Vantagens:

• Possui a marca UOL, muito fortalecida no mercado.
• A nova API é muito fácil de usar.
• Oferece checkout apenas por formulários HTML ou API.
• A interface é simples e bastante funcional.
• Envia dados completos do pedido na notificação de pagamento.

Desvantagens:

• Cobrança só pode ser feita de brasileiros.
• A URL de retorno é global. Se você possui mais de um produto, terá sempre a mesma página de retorno. Para definir uma URL por transação, o pedido deve ser feito através da API.
• Não possui cobrança recorrente.
• Atendimento lento, que demora a entender o problema, mesmo eu tendo enviado um screencast. Já tive ticket aberto que demorou 2 semanas para ser respondido.
• Saque só pode ser feito após 14 dias do pagamento.
• O e-mail enviado ao vendedor confirmando a compra é incompleto.
• O painel do comprador limita as buscas em 120 dias.
• Não possui ambiente de testes.
• A análise do cartão de crédito demora, e muitas vezes é cancelada. Em uma nova tentativa, o mesmo cartão é aprovado.

MoIP

O iG também decidiu pegar uma fatia do mercado que movimentou quase R$20 bilhões em 2011. Para isso comprou o MoIP, investida pela Ideiasnet. O serviço possui muitas funcionalidades como cobrança através da API e cobrança recorrente. Apontado por muitos com a melhor alternativa, só tive experiências negativas no pouco tempo que usei. Possui uma documentação espalhada e difícil de encontrar, uma API confusa e um suporte lento.

Além disso, o site de desenvolvedores estava infectado com um malware e aparentemente eles não estavam sabendo de nada.

Características:

• Tarifa de cartão de crédito: 7,4% + R$ 0,39.
• Demais tarifas: 2,9% + R$ 0,39.
• Tarifa de parcelamento: 1,99%/mês, cobrada do comprador ou do vendedor.
• Cobrança por formulário HTML, e-mail e API.

Vantagens:

• Diversas modalidades de cobrança: recorrente, e-mail, formulário HTML e API.
• É possível fazer muitas coisas pela API.
• Possui ambiente de testes.

Desvantagens:

• Cobrança só pode ser feita de brasileiros.
• Os dados completos do pedido só podem ser acessados quando o pedido foi gerado à partir da API.
• Atendimento lento. Demorou 8 dias para responder um ticket, relacionado a uma cobrança debitada do cliente, mas que está como cancelada no MoIP. Este ticket ainda não foi resolvido.
• A cobrança com formulário HTML envia dados sem criptografia.
• A cobrança recorrente é um envio de e-mail dizendo para o comprador efetuar o pagamento.
• A interface é confusa.
• Saque só pode ser feito após 14 dias do pagamento.
• O painel do vendedor possui erros constantes, como páginas não encontradas.
• A aprovação do pagamento com cartão de crédito demora.

PayPal

Com a entrada do PayPal no mercado brasileiro, as nossas esperanças de um serviço melhor foram renovadas. Ledo engano. O PayPal é tão ruim quanto os outros serviços, com um agravante: é conhecido por cancelar e bloquear contas, mesmo quando estas estão de acordo com os termos de uso.

Características:

• Tarifa de cartão de crédito: 6,4% + R$0,60.
• Tarifa de parcelamento variável de acordo com o número de parcelas.
• Cobrança por e-mail, formulário HTML e API.

Vantagens:

• Possui presença mundial.
• Permite a cobrança de brasileiros e estrangeiros.
• Possui ambiente de testes.
• Possui cobrança recorrente.
• O saque pode ser feito a qualquer momento.

Desvantagens:

• Ambiente de testes confuso de configurar com contas brasileiras.
• Clientes brasileiros só podem ser cobrados em Real (restrição do governo), o que exige uma lógica diferente para cobranças nacionais e internacionais.
• Não possui boleto bancário.
• Taxas mais altas que os concorrentes para valores baixos.
• Não considera o vendedor como um parceiro.
• Não funciona direito com diversos países (Alemanha, por exemplo).
• Diversos serviços oferecidos nos EUA não estão disponíveis no Brasil.

Finalizando

Atualmente, não existe nenhum meio de pagamento realmente bom. PayPal consegue ser o menos pior, embora você tenha que conviver com o risco do congelamento de sua conta, sem maiores explicações. Mas mesmo com todos esses poréns, o PayPal ainda é a melhor solução se você precisa fazer cobranças nacionais e internacionais, principalmente para serviços digitais.

Minha escolha para cobrança apenas de brasileiros é o PagSeguro. Mesmo sendo mais incompleto que o MoIP, a nova versão é mais simples e fácil de implementar.

Em uma segunda fase, será possível utilizar uma interface web para consultar as transações de todos os serviços, além de poder gerar os formulários de cobrança dos serviços de pagamento através do próprio Pingd. Assim, você não precisa se preocupar em montar formulários diferentes para o PagSeguro, PayPal e MoIP, ter que lidar com encoding, nem outros problemas que já estamos cansados de enfrentar.

Quer saber de uma outra coisa legal? Você poderá acompanhar o desenvolvimento do produto em tempo real. Irei criar este produto em uma espécie de "workshop" online, sem data de término, onde todos os inscritos poderão assistir o desenvolvimento do produto em todas as etapas, passando pela concepção, design, desenvolvimento e deployment.

Para ser avisado quando o "workshop" for lançado, acesse o site howtocode.com.br e se inscreva na newsletter.

A ideia não é revolucionária, mas lembre-se que bons produtos são aqueles que vem para resolver os seus próprios problemas! ;)

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.