Mas antes de chegar no assunto, vamos rever que o Rails não é puramente MVC. O “Controller” do Rails agrega coisas que deveriam ser feitas na view (basicamente, buscar o objeto para ser exibido). Para mais detalhes, ver meu post anterior.

Por esse motivo, e unicamente por este motivo, eu não acredito ser possível fazer teste unitários de controllers.

Um teste unitário deve, em teoria, testar um pedaço do sistema, isoladamente de outras partes. Como fazer um teste unitário de algo que é, essencialmente, um “glue code”, ou seja, um código que une regras de negócio (Models) e interfaces (Views)?

Antes do Rails 3, eu usava uma abordagem mais “integrada” para esses specs. No controller, eu usava a palavra-chave do rspec-rails “integrate_views”, e testava o par “controller-view”. Os specs ficavam mais ou menos assim:

describe PeopleController do
  integrate_views
  
  it 'should show people on "index"' do
    sessions[:user_id] = Factory(:user).id
    Factory :person, :name => "Foo Bar Baz"
    get :index
    response.should be_success
    response.body.should include("Foo Bar Baz")
  end
  
  it 'should render "new" view if validation failed" do
    sessions[:user_id] = Factory(:user).id
    post :create, :person => { }
    response.should render_template("new")
  end
end

Claramente, isso não é um teste unitário, mas há um grande ganho nessa abordagem: se eu resolver mudar a variável “@users” para “@records”, e atualizar a view, não preciso mexer em nenhum spec. Na prática mesmo, eu não preciso mexer em nenhum SPEC se eu mudar o layout, adicionar mais informações na view, buscar mais registros no controller e atualizá-los na view, enfim, em qualquer momento eu sei, exatamente, se o teste está falhando ou passando, sem as fragilidades que mocks podem oferecer.

No Rails 3, porém, apareceu um novo diretório: spec/requests. No início do projeto que estou fazendo, comecei a usar o spec/controllers para fazer meus testes (com, obviamente, “render_views” no lugar de “integrate_views”), mas pouco a pouco isso se mostrou um pouco… inútil, digamos assim. Isso porque o diretório “spec/requests” pode usar o “Capybara” para fazer seus testes, o que significa que com os drivers corretos, eu posso inclusive rodar javascript, e nesse caso eu posso ter uma abordagem ainda MAIS integrada: ao invés de ir direto para o controller que eu quero testar, eu posso de fato LOGAR o usuário, ver se a ação que eu quero testar está disponível (isto é, se há links que levam até a ação), ver se o usuário tem acesso ou não (e testar mais facilmente os acessos), etc… o que me levou a, definitivamente, deixar de usar o “spec/controllers” para esse tipo de teste. O resultado final é mais ou menos assim (usando Capybara):

describe 'People' do #Refere-se ao PeopleController
  it 'should list people' do
    Factory :person, :name => "Foo Bar Baz"
    user = Factory :user
    visit root_path
    click_link 'Sign in'
    fill_in 'Login', :with => user.login
    fill_in 'Password', :with => user.password
    click_button 'Login'
    click_link 'People'
    body.should include('Foo Bar Baz')
  end
  
  #... mesma coisa para o "new", só que preenchendo os formulários
end

Ok, só que o teste definitivamente ficou maior do que a versão do Controller. Para resolver isso, basta criar um arquivo, digamos, em “spec/support/login_helper.rb”, e colocar o código de logar usuário lá. Mais um ou outro helper, e o arquivo fica mais ou menos assim:

#arquivo spec/support/login_helper.rb
def enter_on_admin_by(link)
  login_user
  click_link link
end

def login_user(user = Factory :user)
  visit root_path
  click_link 'Sign in'
  fill_in 'Login', :with => user.login
  fill_in 'Password', :with => user.password
  click_button 'Login'
end

Aí o SPEC fica assim:

describe 'People' do
  it 'should list people' do
    enter_on_admin_by 'People'
    body.should include('Foo Bar Baz')
  end
  
  it 'should show errors if creating an invalid person" do
    enter_on_admin_by 'People'
    click_link 'New person'
    click_link 'Save'
    body.should match(/Name can't be blank/)
  end
end

A maior vantagem desta abordagem é que, quando os códigos nos controllers ou views tiverem um pouco mais de peculiaridades, é possível escrever um código de teste apenas para o controller e testar aquela funcionalidade isoladamente… claro, desde que isso não introduza testes frágeis.

Enfim, como um “bonus point”, uma coisa que eu me preocupo sempre é em escrever poucas linhas de teste para fazer coisas “the rails way”, isto é, se eu for testar uma tela de cadastro “padrão”, eu não precise escrever demais. Para isso, eu fiz um helper nos meus testes:

#arquivo spec/support/crud_helper.rb
def assert_created_record(element)
  record = Factory.stub element
  update_each_attribute element, record.attributes
  click_button 'Create'
  body.should include(record.attributes.values[1].to_s)
end

def update_each_attribute(element, attributes)
  attributes.each_pair do |field, value|
    field_name = "#{element}[#{field}]"
    fill_in_field field_name, value
  end
end
private :update_each_attribute

def fill_in_field(field_name, value)
  case value
    when String then fill_in field_name, :with => value
    when true, false then check field_name
  end
rescue Capybara::ElementNotFound
end
private :fill_in_field

E então, meus testes podem ficar mais simples quando eu for criar uma pessoa no formato padrão do Rails:

describe 'People' do
  #...outros testes...
  
  it 'should create a new person' do
    enter_on_admin_by 'People'
    click_link "New person"
    assert_created_record :person
  end
end

E com isso, se for bem disciplinado, é possível identificar imediatamente “código-morto”: se cada teste em seu “spec/requests” está cobrindo uma característica de seu programa, basta rodar uma ferramenta de cobertura de código (simple_cov, por exemplo) no diretório spec/requests. Espera-se que todos os controllers estejam cobertos. Se um model tem partes que não estão cobertas, provavelmente essa parte pode ser eliminada do sistema. Até agora, só vi vantagens nessa abordagem.

Por fim, se alguma parte do sistema depender de Javascript, é possível escrever o método com:

describe 'People' do
  it 'should do something with ajax', :driver => :webkit do
    click_link "Remote call"
    wait_until { body =~ /Add child/ }
  end
end

e usar a gem “capybara-webkit”, que é muito boa. Só lembrar de SEMPRE usar “wait_until”, para assegurar que a página carregou antes de continuar o teste. Outra coisa, esse tipo de abordagem exigiria desabilitar “transactional_fixtures”, o que deixa os testes BEM mais lentos. Uma alternativa seria, num arquivo como “spec/support/ar_shared_connection.rb”, colocar o código abaixo (retirado do blog da PlataformaTEC):

#Baseado no artigo da Plataforma:
#http://blog.plataformatec.com.br/2011/12/three-tips-to-improve-the-performance-of-your-test-suite/

class ActiveRecord::Base
  mattr_accessor :shared_connection
  @@shared_connection = nil
 
  def self.connection
    @@shared_connection || retrieve_connection
  end
end
 
# Forces all threads to share the same connection. This works on
# Capybara because it starts the web server in a thread.
ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection

Enfim, é isso. Controllers para specs bem específicos, requests para testar extensivamente o controller em abordagem mais “integrada”, e models para testar regras de negócio. Agora, só falta aprender como fazer o SPORK funcionar corretamente :).

Enfim, vamos lá: no Rails, quando fazemos um “scaffold”, é criada uma combinação de coisas para nós: uma “migration”, que cria uma tabela no banco. Um “model”, que basicamente é o mapeamento dessa tabela para um objeto. Um “controller”, que faz a busca do registro certo e repassa para a renderização da tela. Por exemplo, a ação “edit”:

  def edit
    @foo = Foo.find(params[:id])
    render :action => 'edit' #Isso é redundante, mas deixa explícito um aspecto importante.
  end

Além disso, há uma série de boas-práticas, tais como não concentrar código de regra de negócio no controller, não colocar lógica nas views, enfim. Porém, essas “regra gerais” pecam em um ponto:

Rails não é 100% MVC…

Bom, explicando mais detalhadamente: digamos que todas as telas de cadastro precisem, além dos dados gerais do objeto, um “select” que contenha dados de outra model:

  <p>
    <%= f.label :bars %><br />
    <%= f.select :bar_id, Bar.all.map { |b| [b.name, b.id] } %>
  </p>

Pelas regras do Rails, isso é lógica na view, e deveria ser movido para outro lugar. Um helper, um controller, enfim. Mas o que é exatamente um helper? O lugar certo do código é realmente em um helper? E se esse código dependesse do registro atual, algo como:

  <p>
    <%= f.label :bars %><br />
    <% 
       bars = if @foo.is_admin?
         Bar.all.map { |b| [b.name, b.id] }
       else
         Bar.only_active.map { |b| [b.name, b.id] }
       end 
    %>
    <%= f.select :bar_id, bars %>
  </p>

E agora, isso deve ficar na view, num helper (eu, particularmente, acho estranho colocar lógica num helper quando ele depende de uma variável de instância que veio de um controller), ou no próprio controller?

Bom, a resposta é simples: esse é um código DA VIEW. Só que, a view NÃO É só o HTML (ou, no nosso caso, o ERB, HAML, enfim). No Rails, controllers fazem um papel que é responsabilidade da view, que basicamente é buscar os registros e instanciar os modelos que são necessários para a view existir. Se for usado render :update, :inline, :text ou mesmo “render_to_string”, só estamos ainda mais expondo esse método da view no controller.

Então, o que verdadeiramente é o “V” e o “C”?

Pelo MVC, através de observers, a view é notificada de alterações no “model”, e reage de acordo com a alteração. Logo, se o model foi salvo, a view reage identificando se esse salvamento foi bem sucedido, ou se foi mal-sucedido e em cada caso decide o que fazer. A view é também “independente” do controller, isso é, uma view contém em si TODAS as informações necessárias para ser exibida. Porém, sabemos que a web é “stateless”, logo não podemos guardar o estado do model e da view e “encaixar” observers nesse modelo… mas, poderíamos sim deixar o rails mais “MVC”:

#app/controllers/foos_controller.rb
class FoosController < ApplicationController
  def edit
    render :FooView, :edit #Até poderia ser redundante, também
  end
  #...
end

#app/views/foo_view.rb
class FooView < ActiveView::Base #imaginando uma abordagem...
  def edit
    @foo = Foo.find(params[:id])
    erb :edit
  end

  def bars_collection
    Bar.all.map { |b| [b.name, b.id] }
  end
  private :bars_collection
end

#app/views/foo_view/layouts/edit.html.erb
<% form_for(@foo) do |f| %>
  <p>
    <%= f.label :bars %><br />
    <%= f.select :bar_id, bars_collection %>
  </p>
<% end %>

BEM mais separado. Além disso, agora toda a lógica de renderização da view fica num lugar correto chamado “View”, não espalhados pelos controllers. Por fim, acaba-se a necessidade de “helpers”, pois temos uma abordagem “orientada a objetos” para views. Alguém afim de implementar isso?

Há uma última coisa a mencionar: “Models” não são apenas tabelas em banco de dados. Model é basicamente um “objeto de domínio”, ou seja, uma classe que concentra regras de negócio de um determinado tipo, que podem ou não estar ligados a dados mesmo. Ou seja, nada me impede de criar um model assim:

class TaxCalculator
  def initialize(salary)
    @salary = salary
  end

  def ir
    @salary * 0.25 #Hipoteticamente, claro...
  end
end

E usá-lo em minha view. Recapitulando, então:

• Models são objetos de domínio. Podem representar cálculos, dados, registros de banco de dados, coleções de registris em bancos de dados, etc.
• Views são objetos que definem uma tela. Podem ter lógica de programação envolvida, desde que essa lógica se prenda apenas à exibição para o usuário. Reagem a mudanças na view, em casos onde a programação envolve mudança de estados (tal como GUI)
• Controllers são objetos que reagem a interações do usuário (cliques em botões, etc) e roteiam essas ações para causar uma mudança de estados no Model que, consequentemente, informará a View através do mecanismo de “observers” que algo mudou, e quem decide como vai atuar naquela mudança é a View.

Ok, mas e no mundo “stateless” da web, aonde instâncias das views, controllers e models são “descartadas” depois de cada requisição, o que fazer? Nesse caso, cada framework tem sua abordagem. No caso do Rails, o Controller server como um “roteador”, que a partir de uma reação (GET, POST, PUT ou DELETE numa URL) identifica o que foi feito (através do método HTTP, da URL e dos parâmetros) e roteia para o caminho certo (redireciona para outro controller ou outra action, ou re-renderiza uma página).

Essa foi a abordagem Rails. Não está certa nem errada, mesmo a abordagem “MVC pura” não está certa nem errada. O que está errado é defender uma certa prática no MVC porque o Rails faz assim…

Para os que me conhecem mais a fundo, sabem que eu sou meio “alérgico” a redes sociais. Aderi ao twitter e ao facebook depois que muita gente já estava usando, e não tenho linkedin, nem google buzz ou google+. Só que eu acho que algumas pessoas estão “perdendo o fio” do que é cada rede social. Usei o twitter, sempre, mais como uma forma de me manter atualizado tecnicamente do que para encontrar amigos-afinal, eu não vejo o motivo de ficar trocando mensagens de 140 caracteres com amigos meus (e deixar isso disponibilizado para o mundo). Aliás, cabe aqui uma observação interessante: a língua, o idioma, é absolutamente frágil. Por isso existem tantas formas de dizer algo, de falar ou pronunciar uma palavra, um sentido… por isso o “teste de Turing” ainda não foi vencido, por isso que é tão difícil processar linguagem natural, por isso que existem trocadilhos e poesias-todos, abusando de características da linguagem que podem dar duplo-sentido, dupla-interpretação, etc.

Isso, na linguagem falada. A linguagem escrita é MUITO pior.

Porque, na linguagem escrita, você não tem aspectos simples como o olhar da pessoa, sorrisos, movimento corporal, tom de voz, e às vezes é difícil de dar a entender que uma coisa é sarcasmo quando se está escrevendo (antes, se usava itálico, tipo “Hahaha, claro que eu vou fazer isso!”). E em 140 caracteres, é MUITO mais difícil. Especialmente em português, que é um idioma que notavelmente se escreve demais (“Right click” vs “Clique com o botão esquerdo do mouse” é um exemplo bem notável). Percebo isso no twitter quando eu não gosto de algo e posto lá: pra não ser subentendido, eu preciso escrever mais de 140 caracteres…

Mas voltando ao assunto: redes sociais. Aí, começam a surgir os clones, que são “o facebook do X” ou o “twitter do Y”, ou os clones open-source, ou os clones de empresas que querem mercado “*cof* Google *cof*”, enfim. E também tem os usuários que retwittam algo no facebook, ou colocam hashtags no facebook, ou informam que “tão saindo de casa”, “tão almoçando”, ou fazendo check-in nos lugares pelo 4square (ou um de seus clones)… e eu acho que essas pessoas perdem um pouco o fio da meada de uma coisa:

Quando você publica algo no facebook, você está postando algo para CENTENAS de pessoas. Por exemplo, no meu facebook, eu possuo cerca de 150 amigos-e me considero alguém que tem poucos amigos, já que eu só adiciono quem eu conheço, etc… mas usando uma média para baixo, vamos pensar em 200 amigos. Digamos que eu poste algo no meu “mural”-só com isso, duzentas pessoas estão vendo. Se uma dessas pessoas compartilhar, são mais duzentas. Digamos que vocês compartilhem 50 amigos, sua postagem foi para 350 pessoas. Se você postou algo que é uma piada interna, e pode ser mal-interpretado… no caso do 4square, já imaginou que ao fazer “check-in” na sua casa, com dois simples “compartilhar” de seus amigos você está publicando o endereço da sua casa para umas 300 pessoas que você nunca viu na vida? Que se alguém quiser saber se você está em casa, basta acessar seu mural e esperar pelo seu “check-in” em algum lugar muito longe? E que as coisas que publicamos em nossos murais dizem muito a respeito da nossa condição social, etc. Em resumo, um possível ladrão pode:

- Saber seu nome, e de seus parentes (e grau de parentesco)
- Saber quais são seus “gadgets” e computadores em casa
- Saber AONDE é sua casa
- Saber AONDE você ESTÁ
- E tudo isso SEM SAIR DE CASA…

Apenas com um computador, conectado na internet. É absurdo, porém verdadeiro.

Outra coisa: você é um ativista em prol do socialismo, veganismo, budismo, do metal, à favor ou contra determinada lei, enfim, você pode postar algo assim no Facebook. MAS, e isso é um GRANDE MAS, a partir do momento que você posta algo você dá ao direito das pessoas

- Concordarem com você
- Discordarem de você
- Não darem a mínima

E aí, acontecem os não-raros posts falando “puxa, o mundo está passando fome, e ninguém dá a mínima” ou os “essa é minha opinião, se você não concorda guarde pra você” e outros “mimimimimi”s. Só que, o que as pessoas esquecem especialmente no segundo caso, e que se você postou algo pra algumas pessoas que você sabe que podem discordar ou até não gostar, quem deveria ter guardado isso pra si é você, a não ser claro que você esteja disposto a aceitar que as pessoas possam discordar. E nisso pode sim surgir discussões úteis. Como ferramenta de discussão, a internet pode ser até melhor do que pessoalmente, SÓ QUE isso exige uma maturidade que eu, sinceramente, acredito que nós ainda não adquirimos.

Se há algo de bom nisso tudo é que o twitter, o facebook, nos ajudam a desenvolver uma tolerância maior a certas coisas (meio que um “teste de fogo”). Quantas vezes eu já quis deletar um usuário do twitter porque os tweets dele era superficiais (e cegos) em determinados assuntos, mas não o fiz porque outros tweets dele são muito bons? No fim das contas, acabei desenvolvendo uma tolerância maior à opiniões-mesmo que elas sejam incorretas (e mesmo que nenhuma explicação lógica do mundo faça a pessoa mudar de idéia). Isso é algo que os botões de “ignore” tiraram de nós, essa habilidade-no primeiro momento que alguém começou a escrever coisas que fisgam um pouco suas idéias, “ignore” nele…

Por fim, e o mais estranho, quando alguém diz que quer colocar monitoramento na internet, as pessoas gritam em nome da “privacidade”. Qual privacidade, quando deliberadamente informamos tanta coisa na internet pra qualquer um ver, sem distinção nenhuma?

Lembrando que eu sou, sim, muito a favor da privacidade na internet. Porém, me preocupa o fato de que se eu me recuso a deixar explicitado na internet quem eu sou, como eu sou, aonde eu moro, enfim, todas as possíveis informações sobre mim, de repente eu sou a pessoa estranha…

Proponho uma pergunta: qual é a idéia da graduação, nos tempos como hoje? Explicando, em tempos de Wikipedia, de Google, aonde entra uma graduação? Acho que aqui, temos que separar duas coisas: Faculdade, Universidade, e Colegial Técnico.

Pra maior parte das pessoas (e infelizmente, para nosso país e o mercado de trabalho e governo dele), a graduação é um “upgrade” da formação média, e o “colegial técnico” fica meio perdido nesse meio do caminho… além disso, muitos professores (e infelizmente eu conheço isso, tendo trabalhado numa universidade federal) ainda acham, nos dias da Wikipedia, que são donos do conhecimento, e ninguém chega ao conhecimento sem o intermédio deles.

Os que me acompanham no Twitter devem ter visto que eu prestei o Poscomp. Num dos livros que peguei, havia a seguinte frase:

Função injetora é aquela que, para dois elementos distintos a, a’ ∈ A, f(a) ≠ f(a’)

Uhn… então, eu resolvi ir para a Wikipedia:

Uma função diz-se injectiva (ou injetora) se e somente se quaisquer que sejam x1 e x2 pertencentes ao domínio da função, se x1 é diferente de x2 implica que f(x1) é diferente de f(x2)

Há um “Link” para “domínio”, e há um gráfico mostrando graficamente essa explicação. Não precisa ser um gênio para entender que a explicação da Wikipedia está mais simples e melhor explicada e exemplificada. Ok. Mas, e isso é importante notar, eu não chegaria ao artigo da Wikipedia sem o livro, sem o poscomp, e não teria entendido a palestra do Tenderlove sem ter estudado para o Poscomp (ainda que eu tenha usado os livros como “grandes índices” e a Wikipedia como forma de aprender, propriamente dita).

Continuando: o que é a graduação? Antes disso, vamos pensar na etimologia: universidade, vem de “Universo”, ou seja, você tem um universo de informações à sua disposição. Universidade não deveria ser um “level-up” da faculdade, onde ela adquire determinado número de alunos e cursos e, de repente, é uma universidade. Algo que eu sempre digo, pintar uma casa abandonada de verde não vai melhorar a estrutura dela, ou a localização, ou a segurança-ela continua sendo uma casa abandonada, porém agora está pintada de verde…

Vamos pensar no seguinte assunto (coisas q eu não vi na minha “universidade”, mas enfim): Automatos, Linguagens, Linguagens Regulares, e até mesmo complexidade de algoritmos. Tenderlove falou sobre o assunto e mostrou como aplicar esses conceitos na hora de criar uma nova forma de identificar rotas no Rails 3.2. Interessante, porém mesmo quem já viu automatos, linguagens regulares, etc. nas faculdades provavelmente não sabia aonde aplicar esses conceitos. Mas estou saindo do assunto de novo, então voltando: todos esses conceitos são, sim, importantes de ver numa universidade, e até mesmo numa faculdade, porém (e esse porém é bem grande) na maioria das vezes um desenvolvedor de sistemas NÃO PRECISA saber estes conceitos, a não ser que você vá criar um framework super famoso usado por milhares ou até milhões de pessoas como o… Rails, por exemplo…

O problema, não é a graduação, mas a necessidade dela para conseguir empregos melhores (ou até para conseguir empregos, simplesmente), e o que se ensina nela sem aplicação. Conheço aos montes pessoas que sabem o que são linguagens regulares mas não conhecem expressões regulares, que sabem o que são AST, Bytecodes, Interpretadores, JIT, e acham que os programas feitos em Java não são interpretados, que Ruby 1.9.2 não tem bytecode (só pq não tem um arquivo, digamos, RBC contendo o bytecode) ou até mesmo que confundem “linguagens dinâmicas e estáticas” com “linguagens interpretadas e compiladas”, respectivamente.

Resultado final: 80% (sem exagero) dos programadores só precisam de um “colegial técnico”, ou nem isso. Para um programador acima da média, ele aprenderia MUITO mais rápido (e poderia ser um programador pleno ao invés de júnior ou estagiário) conceitos interessantes numa faculdade DESDE QUE a faculdade se importasse em ensinar coisas importantes, como SOLID, boas-práticas, TDD (no nosso cenário atual, só teste automatizado já estaria bom), programação funcional (de um jeito decente, não essas “brincadeiras acadêmicas de calcular fatorial recursivamente”), enfim, outros conceitos que se usam em 80% do mercado de trabalho. O colegial técnico, nessa história, serviria para o profissional saber programar, única e exclusivamente. Esses dois lugares PRECISAM ENTENDER que não são mais detentores exclusivos do conhecimento, então eles devem atuar como facilitadores no acesso à informação. A idéia aqui é: se eu posso procurar algo na Wikipedia, porque eu não o faria? Então, o colegial e a faculdade precisariam me apontar nessa direção, me ensinar o básico ou o intermediário, e não acharem que só porque há um professor formado me ensinando eu não vou ter conhecimentos fora o que me ensinam. Ao mesmo tempo, o trabalho dessas duas instituições seria também acabar com os vícios que muitos programadores tem (ok, isso é quase uma piada, já que na faculdade e no colegial técnico normalmente é o lugar aonde se adquirem mais vícios, mas isso teria que ser repensado também).

A universidade fica como o lugar aonde se ensinaria, verdadeiramente, conceitos que fariam o profissional conhecer estruturas de dados complexas (eu não estou falando de pilhas e filas, isso os profissionais realmente empenhados aprendem sozinhos porque são estruturas simples) e saber como aplicá-las na solução de problemas e ainda digo mais: quanto MAIS comum for o problema que for possível ser resolvido com uma estrutura dessas, melhor. Se eu sei resolver um problema simples com automatos, é MUITO mais fácil eu aprender aonde aplicar em problemas complexos. Ao mesmo tempo, precisamos acabar com as “Javaschools”. Precisamos, nessas universidades, parar de pensar em resolver todo e qualquer problema com apenas Java ou C++. Automatos, Árvores B, não são fáceis de implementar. Pseudocódigo não significa NADA, porque não roda. Podemos escrever o código em Ruby, ou Python, ou outra linguagem SIMPLES, porque o intuito do trabalho é ensinar a ESTRUTURA DE DADOS e APLICÁ-LA na resolução de um problema (se possível, mostrando quão melhor é o desempenho dessas estruturas ao invés de usar os algoritmos comuns), e não ficar brigando pra fazer a implementação de algo que o aluno já sabe, conceitualmente, porque a linguagem escolhida não é declarativa o suficiente.

Mas, como isso infelizmente é ilusório demais, prefiro continuar brigando e batendo cabeça ao afirmar que uma graduação, da forma como é feita hoje, não é necessária para um bom profissional. Se existissem livros mostrando aplicações de estruturas de dados, eu até afirmaria que ler esses diversos livros é importante. Porém, da forma como se ensina hoje ciência da computação, não vejo nem a presença nem a ausência da graduação como qualquer fator se o profissional é bom ou não.

Não estou dizendo que eu não idento meu código-longe disso. Apenas que eu prefiro evitar a identação sempre que for possível. Mas vamos por partes…

Primeira coisa, isso começou há algum tempo quando uma pessoa propôs o seguinte problema: montar uma lista encadeada (Linked List) com as seguintes regras:

1) A lista deve validar se ela está vazia, e lançar um erro caso tente-se retirar um item da lista vazia
2) Cada método pode ter, no máximo, uma linha
3) Não se pode usar “if” em momento algum

Claro que é uma bela loucura, mas depois que eu consegui resolver esse código, pensei: se eu consegui resolver um problema desses com apenas uma linha por método, será que meus códigos não tem coisa demais?

Aí, comecei a experimentar isso em código de produção. Isso meio que criou um estilo de codificar bem interessante, e vou tentar mostrar aqui com alguns exemplos:

Digamos, por exemplo, que temos um código que valida determinados atributos. Depois, um método que, se os atributos forem válidos, salva. Caso contrário, exibe algo na tela. Somos tentados a escrever um código assim:

def save
  if valid?
    save_product_without_validations
    return true
  else
    puts "Invalid record!"
    return false
  end
end

Não é difícil de ver que esse método faz coisas demais… ele tem a lógica do que deve ser feito se o produto for válido e se ele for inválido. Pensando numa descrição breve do que esse método faz, “save deve salvar o produto se ele for válido” já mostra que tem algum código a mais… e se retirarmos a identação?

def save
  return invalid_product unless valid?
  save_product_without_validations
  return true
end

def invalid_product
  puts "Invalid record!"
  return false
end
private :invalid_product

E essa é uma das táticas que eu uso. A outra, basicamente, é em relação aos “case”. Eu, particularmente, não idento o “when” no mesmo nível do “case”, e isso é por apenas um motivo: cada “case” tem apenas um comando.

case age
  when 18 then just_completed_18
  when 21 then buy_a_car_already
  else uninteresting_age_found
end

Isso auxilia, absurdamente, a idéias das boas-práticas de qualquer sistema. Claro que, como sempre, isso não é uma regra-de fato, se existe uma regra sobre código limpo é que não existem regras absolutas sobre o código limpo… simplesmente porque, seguir regras cegamente não garante um bom “design”, caso isso fosse possível já teríamos encontrado uma regra matemática para um bom design e todo o processo de refatoração poderia ser feito automaticamente-já que já existem “ofuscadores de código”, porque não um “refatorador automatizado”?

Claro que esse tipo de prática não serve para algumas linguagens. Por exemplo, qual o uso do exemplo acima no caso de Java:

switch(age) {
  case 18: justCompleted18(); break;
  case 21: buyACarAlready(); break;
  default: uninterestingAgeFound();
}

Não faz muito sentido quando se precisa forçar o “break” no código, na verdade. Mas voltando às identações, isso vale não só para condicionais, como para loops também:

metadata.each { |m| create_record(m) }

(que, nesse caso, funciona ainda melhor na versão em Scala)

metadata foreach createRecord

Finalizando esse curto post: a idéia não é evitar identar o código-simplesmente, a idéia é evitar aqueles códigos que parecem um sinal de maior (>) aonde se tem diversos “ifs” encadeados, ou coisas parecidas… sempre que for abrir um IF, ver se não faz mais sentido criar um novo método e usar o “if” com uma linha só. Sempre que for abrir “case”, deixar cada condição do case num método separado. E, se isso estiver dando muito trabalho, se em cada um dos novos métodos estiver chamando outro “if”, talvez seja hora de pensar numa mudança no design, talvez extraindo uma classe separada (ou uma Factory) para as condições.

E, vale a pena dizer: se um código tem mais de quatro níveis de identação, ele tem um sério problema…

Como mesmo eu não tenho muitos conhecimentos em linguagens funcionais, resolvi propor um problema para mim mesmo: implementar uma árvore binária em Ruby, e depois portá-la para Scala, tentar uma abordagem imutável em Scala, e depois portar para Haskell. O código está no github, mas algumas coisas vão ser discutidas aqui.

Primeiramente, a árvore imutável é feita recriando a árvore inteira. Claro, não podemos re-criar apenas um nó e apontar, digamos, a referencia de seu pai para esse novo nó, porque o pai é imutável (assim como qualquer outro aspecto do programa).

class Node[A <% Ordered[A]](value: A = None, left: Option[Node[A]] = None, right: Option[Node[A]] = None) {
    def insertNew(newValue: A): Node[A] = value match {
        case v if(newValue < v) => insertLeft(newValue)
        case _ => insertRight(newValue)
    }

    private def insertLeft(newValue: A) = new Node(value, newChild(left, newValue), right)
    private def insertRight(newValue: A) = new Node(value, left, newChild(right, newValue))
    private def newChild(child: Option[Node[A]], newValue: A) = child match {
        case Some(child) => Some(child insertNew newValue)
        case None => Some(new Node(newValue))
    }
}

val a = List(1, 2, 3) //Cria uma lista. O método "find", abaixo, retorna um Option[Int]
//para essa lista, pois essa lista é do tipo List[Int].
val b = a.find(e => e == 2) //"b" é uma instância do tipo Some[Int]. O tipo "Option" i

Option, em Scala, tem dois valores possíveis (duas sub-classes): “Some”, e “None”. Some é quando o valor foi encontrado, None quando não foi encontrado. É possível fazer “pattern match” nesses casos, igual ao “case Some(child)”. Enfim, a idéia funciona, a árvore é re-criada, mas precisamos ficar pensando em casos que a sub-árvore existe (Some) e em casos aonde ela não existe (None), e é quase como trabalhar com nulos, mas de uma forma mais “abstraída”, que no nosso caso se reflete no compilador reclamando se você não tratar um Option.

Agora, a versão em Haskell. Primeiro, definimos um tipo de dados:

data Tree a = EmptyTree | Node a (Tree a) (Tree a)

A árvore (Tree) ou é uma árvore vazia (EmptyTree) ou um nó que contém um valor, uma árvore à direita e uma à esquerda.

Wow.

Sério, o ponto aqui não é a API. É simplesmente o que isso significa. Eu não disse que uma “árvore vazia” é um nulo, um None, ou qq coisa que o seja. Eu descrevi o que é, para mim, uma árvore. Além disso, Haskell permite definir seus métodos de acordo com o que eles esperam receber. Ou seja, um método pode ser definido de forma diferente se ele espera “1″ ou se ele espera outros valores, como no caso do fatorial:

fat 0 = 1
fat x = x * (fat x - 1)

Ok, estamos chegando em algum lugar. E se implementássemos nossa árvore assim também?

(<<) EmptyTree value = Node value EmptyTree EmptyTree
(<<) (Node value left right) newValue = if newValue < value 
    then Node value (left << newValue) right
    else Node value left (right << newValue)

Nesse código, (<<) é para definir uma função chamada "<<". Em Haskell, qualquer função que não seja composto por caracteres alfanuméricos pode ser escrito entre os operadores. Assim, uma função chamada "($@) parametro1 parametro2" pode ser escrita ou como "($@) parametro1 parametro2" ou como "parametro1 $@ parametro2" (note a ausência de parenteses, que Haskell não precisa e nem deixa). Achei que a idéia de fazer um método "arvore << valor" faz mais sentido do que "insertInto arvore valor". Voltando ao código acima, repare em uma coisa incrível: esse código, SOZINHO, monta uma árvore. Nem mais, nem menos. Podemos fazer isso em Scala?

A verdade, é que podemos.

class Tree[A <% Ordered[A]]() extends Traversable[A] {
    def << (newValue: A): Tree[A] = this match {
        case EmptyTree() => Node(newValue, EmptyTree[A], EmptyTree[A])
        case Node(value, left, right) if(newValue < value) => Node(value, left << newValue, right)
        case Node(value, left, right) => Node(value, left, right << newValue)
    }
}
case class EmptyTree[A <% Ordered[A]]() extends Tree[A]
case class Node[A <% Ordered[A]](a: A, left: Tree[A], right: Tree[A]) extends Tree[A]

Repare nos "case class". São o equivalente ao "data" do Haskell, só que BEM menos descritivos, infelizmente. Agora, vamos pensar numa forma de percorrer essa árvore. Em Haskell, podemos criar uma lista e podemos imprimir os valores da árvore:

toArray EmptyTree = []
toArray (Node value left right) = toArray left ++ value : toArray right

printTree EmptyTree = return ()
printTree (Node value left right) = do
    printTree left
    print value
    printTree right

PORÉM, não podemos aproveitar uma função para a outra… porque, a função "toArray" é "pura", pois não tem efeitos colaterais e retorna um valor único (a lista). Já o printTree retorna um valor simbólico (chamado de "IO ()", que indica que ela tem efeitos colaterais (o IO) e que não retorna nada (um conjunto vazio)). Tentei usar um meio de aplicar uma função, e ver se essa função "aplicada" poderia ou imprimir ou retornar uma lista, mas não rola – uma tem efeitos colaterais e não é "pura", a outra não tem e é "pura", e Haskell é bem categórico em dividir o código entre essas duas partes.

Já o código em Scala:

class Tree[A <% Ordered[A]]() extends Traversable[A] {
    def foreach[U](f: (A => U)) = this match {
        case Node(value, left, right) => left foreach f; f(value); right foreach f
        case EmptyTree() =>
    }
}

Como eu extendo o Traversable (o equivalente ao Enumerable do Ruby), eu posso aproveitar isso para o toList e tudo o mais. Porém, como é possível ver, essa função não é "pura", pois no caso do EmptyTree, ela simplesmente não retorna.

Isso é desejável? Isso é uma aberração dos paradigmas? Claro, isso dá uma flexibilidade que nem Haskell nem Java (ou Ruby) possuem, mas aí vem a pergunta: que paradigma é esse? É um "pseudo-funcional", "orientado a objetos e funções"? Quais as implicações, as regras que aprendemos continuam valendo?

Eu ainda busco a minha resposta para isso. Mas, como o que eu mais gosto em uma linguagem é a flexibilidade que ela me oferece, não posso negar que, hoje, Scala disputa com Ruby em linguagem mais flexível.

Aí, entrou a gem Johnson. Basicamente, é um interpretador Javascript dentro de Ruby, de forma que seja possível rodar código JS dentro do Ruby (e o resultado vem como uma Ruby String, ou um Numeric, enfim). Já falei sobre isso quando estudei “The Ruby Racer” e os testes com V8 no Ruby, até me interessei pelo “env.js”, porém na época a versão que rodava com Johson estava muito ruim ainda (e infelizmente, ainda está)

Porém, o novo Env.JS (1.3) já roda no Johnson. E está muito melhor.

Enfim, o env.js, porém, nessa versão virou mais um “browser” do que uma “biblioteca”, então acabei fazendo umas adaptações para ele rodar como biblioteca do Johnson. Junto com isso, fiz um pequeno hack:

document.oldGetElementById = document.getElementById;
document.getElementById = function(id) {
    var element = document.oldGetElementById(id);
    if(element) return element;
    element = document.oldGetElementById('someDivThatWillNeverBeOverwrited');
    var newDiv = document.createElement('div');
    newDiv.id = id;
    newDiv.innerHTML = "";
    element.appendChild(newDiv)
    return newDiv;
}

A idéia, aqui, é ao invés do “getElementById” retornar “undefined” se o elemento não for encontrado, criar um novo elemento sempre. Isso é importante porque, criando sempre um novo elemento, é possível testar o comportamento de um javascript, sem necessitar de “fixtures”. Esse foi o primeiro passo, basicamente. O segundo, foi implementar uma classe para abstrair todas as alterações na página, rodar o Javascript, identificar eventos e ligar com o Env.JS. Como estou usando Johnson, chamei essa classe de EnvJohnson.

Enfim, a idéia principal é: criar um ambiente Javascript, re-escrever o “getElementById” do “document”, salvar a página como estava antes e rodar um script que veio do Rails nele, salvando a página que veio depois. Isso traz um sumário de tudo o que foi alterado na página, como por exemplo, elemento que foi substituído, elemento que foi alterado, elemento que mudou a cor, mudou as propriedades tipo “style”, “class”, etc. A API que achei, por hora, é assim:

js_for response.body, :prototype do |js|
  js.should replace_inner_html_of(:example)
  js.should_not replace_inner_html_of(:example2)
end

A primeira linha inclui o “prototype”, e cria um “EnvJohnson” para o que vier de resultado no “response.body”. A partir daí, o resultado é computado e pode-se usar os modelos tipo “replace_inner_html_of” e outros que ainda vão surgir.

Claro, a biblioteca ainda está bem no começo, mas confio que muitas alterações serão feitas para ser uma abordagem possível para testes unitários bem menos “dolorosos” no Rails. Como sempre, o código está no github. Ele não funciona muito bem com prototype (problemas no Env.JS) mas JQuery roda bem, pelo menos o que eu testei até agora.

Aguardo pull requests :)

Então, vamos falar um pouco sobre Duck Typing. O básico, a maioria já sabe:

def imprimir(objeto)
  print objeto.falar
end

Ou seja, na declaração do método eu não defino nenhuma regra do que aquele objeto pode receber; apenas chamo os métodos que eu o objeto passado como parâmetro deveria implementar, e confio que vai dar certo. Parece simples, e até um pouco inseguro, então tem gente que prefere fazer umas checagens antes (tipo usando objeto.is_a?(Pessoa) ou objeto.respond_to?(:falar)), mas eu acho que isso quebra a idéia de Duck Typing. Para mim, tudo se resume a uma palavra: Protocolo.

Quem já leu algo sobre protocolos na internet deve ter visto coisas sobre, digamos, o HTTP, SMTP, etc. Qual a idéia? Um protocolo, basicamente, define um conjunto de regras que devem ser seguidas caso você queira se comunicar com aquele serviço/servidor/whatever e ser entendido. Simples, fácil. Como um exemplo bem tosco, vamos tentar acessar o Google usando os seguintes comandos:

telnet google.com
**montes de informação**
GET /

Bom, você verá que, milagrosamente, o google responde para nós uma página. Agora, no lugar do “GET /”, tente escrever algo arbitrário, tipo “Hello, world”, e o que você ganha é uma mensagem de erro (que pode, ou não, ser um HTML válido).

O que isso significa? Significa, na verdade, que o Google espera um protocolo: para exibir páginas, você usa esse comando “GET”, com mais uns parâmetros, e recebe uma página. Se você usar um comando que não existe, recebe um erro. Para quem entende HTTP, isso é óbvio.

Em Ruby, assim como outras linguagens dinâmicas, a linguagem se comporta de forma parecida. Você documenta, informalmente (quando eu falo “informalmente”, eu quero dizer que o código não força aquela forma de programar. Assim como no HTTP, você pode mandar comandos que não existem, eles só não serão entendidos e podem gerar erro), como cada classe, cada método, cada parte do programa funciona, e espera que o programador tenha bom-senso suficiente para fazer as chamadas do jeito correto.

Essa é uma mudança muito mais drástica do que se espera. Por exemplo, no Rails, digamos que queremos um comportamento assim: sem usar um banco de dados, queremos fazer uma validação. Digamos, um “CAPTCHA”. Você digita aquelas letrinhas que aparecem na imagem, e se estiver errado, o campo fica vermelho, igual o Rails faz. A documentação do Rails peca aqui, mas para termos o mesmo comportamento, precisamos que o objeto (digamos, uma instancia de CaptchaValidator, talvez?) implemente os seguintes métodos: errors (que deve retornar um objeto semelhante a um hash), error_on(field) (que retorna o erro naquele campo), e errors.full_messages (que retorna as mensagens de erro em texto puro, num formato semelhante a um Array). Se você implementar esses três métodos, mais um atributo (attr_accessor) para receber a informação do captcha, definido mais um ou dois métodos (no rails 3, mais um, na classe: “model_name”, que tem que retornar um ActiveModel::Name) você pode fazer uma view assim:

<% form_for @captcha do |f| %>
  <%= f.error_messages %>
  <p><%= f.label :capcha_text %><%= f.text_field :captcha_text %></p>
  <p><%= f.submit 'Login' %></p>
<% end %>

Sem conhecer o código, vendo “de fora”, o @label é um registro num banco de dados, é um objeto, o que ele é? Sinceramente, não importa. O que importa é que o @label atenda um protocolo, e é por isso que recomenda-se que o protocolo seja o mais simples o possível (Rails peca um pouco aqui também. Ao invés de ter que implementar o método error_on(field), o ideal seria que ele pegasse direto do errors, como “errors[field]“).

Aliás, isso é a regra de mix-in também: a idéia do mix-in (originalmente, pelo que parece) é de dar poder a um objeto usando um protocolo; por isso os modules padrão do Ruby, pelo menos a maioria, tem nomes que terminam com -able (-ável, em português) como Comparable ou Enumerable (Comparável e Enumerável). No caso do Comparable, você está dando poder a uma classe de ser comparada com outra-o protocolo diz para implementar um método (<=>(other)) que, quando for rodado, compara esse objeto com outro e retorna -1 se este objeto for maior, 0 se forem iguais, ou +1 se o outro for maior. Quando você mixar o Comparable, métodos como ==, < , <=, virão de brinde. O Enumerable, idem, você só precisa implementar o método "each". Claro, muita gente usa modules como se fossem "herança múltipla", e em alguns casos são implementações muito boas (ActiveModel::Validations sendo um ótimo exemplo), mas idealmente isso é herança múltipla, não mix-in, e isso tem que ficar claro.

Então, duck-typing de novo: a idéia de se programar nesse paradigma basicamente é assim: se você quer um objeto que se comporte como se fosse uma herança de determinada classe, tudo o que se precisa fazer é descobrir quais métodos precisam ser implementados (isso pode ser de varias formas, até mesmo criando uma classe vazia e ir acompanhando erro a erro de "undeclared method") e, então, implementá-los. Parece simples (e de fato é), porém é aonde muita gente peca, criando classes que definem um método aonde ele só lança uma exception (para que declará-lo, afinal?), esperando que ele seja herdado, ou usando mix-in como herança múltipla (tipo o que o DataMapper faz, e não, na minha opinião não é algo desejável), ou ainda herdando classes e usando "remove_method" para remover métodos que não seriam usados. Ruby é uma linguagem no qual a idéia de duck-typing é muito presente, o tempo todo. Abuse de composição, a linguagem facilita para você.

Claro, ainda há muito mais o que falar sobre Ruby e duck-typing, mas isso fica para outros posts.

Muitos programadores Rails sabem a regra “Controllers magros, Models gordos”. É interessante também saber um pouco sobre o porque dessa regra, mas antes disso, vamos discorrer sobre o que é o “Model” de Rails, comparando com o “Model” da maior parte dos frameworks Java (lembrando que eu não sou programador Java, se eu falar qualquer besteira, me corrijam).

Pegando por exemplo o Hibernate, normalmente há uma classe que mapeia um objeto para uma tabela, e outra classe que faz as buscas (chamada normalmente de Facade). Então, teríamos um diagrama como: JDBC -> Model -> Facade. Já no caso do Rails, o mapeador ActiveRecord já abstrai a parte de “ter que mapear um objeto para uma tabela”, e também já nos oferece formas de buscar esses registros. Resultado, que o “Model” do Rails é meio que uma junção de “Model” e “Facade” do Java, e isso sozinho. Parece então óbvio que regras de negócio vão para ele, não é? Senão, qual o uso de uma classe vazia?

Bom, minha abordagem não é bem essa. E para isso, eu uso o princípio das CRC Cards, da metodologia XP.

CRC – Class, Responsability, Collaboration, é uma forma bem simples de identificar entidades e classes num projeto. Como exemplo, uma classe “Pessoa”:

Classe: Pessoa
Responsabilidade: Representar uma pessoa válida no banco de dados
Colaboração: vamos deixar de fora por enquanto

Digamos agora que eu preciso saber o salário líquido daquela pessoa. É prática comum, infelizmente, a partir do campo (atributo) “salario”, fazer todos os cálculos de imposto, descontos, e então dar o resultado. Mas isso está certo? Olhando para a “responsabilidade” da classe Pessoa, ela deveria “Representar uma pessoa válida no banco de dados”. A responsabilidade da classe são, então, validações, e assegurar que os dados que ela vai retornar são representações de parte daquela pessoa (como exemplo, um método “nome_completo”, que concatena o “nome” e “sobrenome”).

Minha abordagem é a seguinte: No Rails 2, no arquivo environment.rb, tem uma linha:

  # config.load_paths += %W( #{RAILS_ROOT}/extras )

Eu descomento essa linha e adiciono uma lista de diretórios para minhas regras de negócio:

  config.load_paths += ["#{RAILS_ROOT}/app/calculos"]

No rails 3, é necessário adicionar (no caso do meu aplicativo chamar-se Exemplo):

Exemplo::Application.configure do
  config.autoload_paths += ["#{RAILS_ROOT}/app/calculos"]
end

Agora, no diretório “app/calculos”, eu crio um arquivo como “salarios.rb”:

class Salarios
  def initialize(pessoa)
  end
  
  def salario_liquido
  end

  def impostos
  end
end

Enfim, com todas as regras que eu precisaria. Agora, para um exemplo mais real: uma vez, tive que montar um sistema que as regras de validação de um cadastro eram variáveis. Para não expor código que pode estar protegido, vamos inventar aqui uma regra arbitrária: administradores podem alterar todos os dados de uma pessoa. Porém, se o usuário NÃO FOR um administrador, aí ele não pode diminuir o salário de uma pessoa, somente aumentar. O que impacta aqui é o “update” do controller. Primeiramente, vamos fazer uma pequena alteração no controller:

PeopleController < ApplicationController
  def update
    @person_updater = PersonUpdaterRule.return_rule_for current_user, params[:person_id]
    @person = @person_updater.person
    if @person_updater.update_attributes(params[:person])
      redirect_to @person
    else
      render :action => 'edit'
    end
  end
end

Retirei algumas coisas para ficar mais breve. A idéia aqui é que, ao invés de listar os erros do @person, listamos os erros do @person_updater. No rails 2, é possível fazer isso com o helper “error_messages_for :person_updater”. No rails 3, é necessário fazer isso manualmente, infelizmente. Outra possibilidade é o @person ser o próprio PersonUpdater, e delegar todos os métodos desconhecidos (name, age, salary, em resumo, qualquer método que pertença ao model) para o lugar correto, nesse caso o model Person.

Agora, a implementação. Uma possível implementação dos Updaters é:

#arquivo app/rules/person_updater_rule.rb
module PersonUpdaterRule
  def self.return_rule_for(current_user, person_id)
    #Para os que gostam de design pattern, isso é uma Factory :)
    if current_user.admin?
      PersonUpdaterRule::Admin.new person_id
    else
      PersonUpdaterRule::NonAdmin.new person_id
    end
  end
end

#arquivo app/rules/person_updater_rule/admin_rule.rb
module PersonUpdaterRule
  class AdminRule
    include Validatable #se for rails 2. Instalar a gem durran-validatable
    include ActiveModel::Validations #se for rails 3
    validate :valid_person
    attr_reader :person

    def initialize(person_id)
      @person = Person.find person_id
    end

    #Validações padrão da pessoa relacionada a esse modelo
    def valid_person
      @person.valid?
      @person.errors.each { |k, v| errors.add(k, v) }
    end
    private :valid_person

    def update_attributes(params = {})
      return false unless valid?
      @person.update_attributes(params)
    end
  end
end

#arquivo app/rules/person_updater_rule/non_admin_rule.rb
module PersonUpdaterRule
  class NonAdminRule < AdminRule #Herdando as regras de validação do Admin.
    validate :salary_not_lower

    def salary_not_lower
      before, after = @person.changes['salary']
      return if before.nil?
      errors.add(:salary, "can't lower") if(before.to_i > after.to_i)
    end
    private :salary_not_lower
  end
end

A vantagem dessa abordagem é separar, claramente, as validações específicas de cada situação. Esse tipo de validação não tem sentido ser implementado no modelo; afinal, uma pessoa vãlida precisa ter um salário, e essa é a única regra que pertence ao registro. Da mesma forma, não faz sentido ter que passar, sempre que for atualizar o registro, qual o usuário logado atualmente no sistema. Finalmente, essa é uma regra de negócio que pode ser alterada com o tempo, e é ideal que ela esteja separada do resto das regras para que possa ser facilmente atacada quando necessário.

Por fim, mais para frente escreverei um post sobre “Duck Typing” que talvez explique um pouco mais o código acima. Mas a idéia é, SEMPRE, evitar concentrar lógica demais num lugar só. Fica bem mais desacoplado, faz mais sentido e evita o God Anti-Pattern, ou seja, um “super-objeto” que faz tudo.

Fortaleza, logo nos primeiros dias, mostrou a minha insanidade. Sinceramente. Escancarou a insanidade que é viver em São Paulo, nessa selva de pedra, completamente desumana. Para começar, logo no primeiro dia, o taxista conversando conosco (às 0h), e, do nada, vê que passou o hotel e resolve dar ré… numa avenida. E tudo bem, um outro carro passou por ele como se nada tivesse acontecido.

A população tem um olhar mais vivo por lá. Os passos são sadios, calmos, não apressados e ansiosos como em São Paulo. Aliás, as pessoas olham para você. Parece bobo, e de fato é, mas tente andar na Paulista e impressione-se em ver como as pessoas não fazem contato visual. Nem na Berrini, ou qualquer um desses “centros comerciais” de São Paulo.

Mercado, e as pessoas comentando: “o quê, você vai embora às sete?”. Detalhe, o mercado fecha oficialmente às sete mas, seis e meia, o pessoal já está arrumando as coisas, afinal o mercado fecha às sete, não às oito ou “até o último cliente”.

Fui parado duas vezes na rua por pessoas, uma com uma nota de vinte na mão, outra de cinquenta. O motivo? Saber se eu conseguia trocar a nota pra ela. À noite, a avenida beira-mar é lotada de gente, correndo, praticando esportes, andando de patins ou qualquer coisa parecida. Nenhum contrato, nenhuma formalidade, só chegar lá e praticar com o pessoal. Simples assim. Simples como um dono de uma barraquinha que, ao ver que as crianças estavam jogando bola sozinhas, foi lá jogar com elas. Algum tempo depois, as crianças cansaram, foram até o pai, que as pegou na mão e foram embora. Nenhuma palavra trocada entre o pai ou o dono da barraca, nenhum olhar hostil, como se aquele comportamento fosse tão normal por lá que é o que se espera de qualquer pessoa.

Isso faz pensar um pouco. O ritmo que vivemos em São Paulo, é sustentável? É agradável? Isso é engraçado pensar, porque todos os acessos à informação que eu tenho são de contatos em São Paulo-toda a idéia de empreendedorismo que eu tenho é de São Paulo, a idéia de “dedicar-se dias e noites ao trabalho para fazer algo grandioso e ficar rico ou próximo de rico” ou algo assim. Essa “realidade” é real em Fortaleza, ou em lugares mais calmos? Existe mesmo uma “regra” como essa, ou será que estamos apenas repetindo idéias divulgadas por países como os EUA, sem ver a “big picture”?

Enfim, Fortaleza. Talvez, a primeira cidade que eu visitei, e pensei: “aqui, é um lugar bom para morar”. É comum para nós, de São Paulo, pensarmos no estado como a “locomotiva do país”, “quem carrega o Brasil nas costas”, e coisas assim. Será que estamos realmente com essa bola toda? Ou será isso apenas uma desculpa, um motivo para vivermos e aceitarmos a vida que vivemos?

Just saying :)