• Camera+: aplicativo para tirar fotos com opções adicionais (como controle de exposição separado do foco) e efeitos de pós-processamento.
• Hipstamatic: provavelmente a app que lançou a moda de efeitos vintage em fotos. A mais utilizada hoje é o Instagram, mas ainda prefiro o Hipstamatic.
• 1Password: pra quem utiliza a versão desktop, é uma grande mão na roda pra lembrar senhas quando o celular é tudo que temos à mão.
• Dropbox: ótimo pra visualizar documentos e fotos.
• Convertbot: sou fanboy da Tapbots e uso todas as aplicações dos caras. O Convertbot é um conversor de unidades com muitas opções disponíveis e uma UI fantástica.
• Pastebot: múltiplas áreas de transferência no iPhone, com direito à operações sobre o conteúdo copiado (como efeitos sobre imagens ou tradução de textos). Além disso, com o Pastebot Sync, é possível copiar e colar conteúdos entre Mac e iPhone e vice-versa.
• Tweetbot: cliente de Twitter da Tapbots. UI sensacional, gestures, filtros, possibilidade de usar listas como timeline principal e várias outras opções.
• Weightbot: aplicação para acompanhamento de peso, com estabelecimento de metas, cálculo de IMC e gráficos de projeções (pra você ver se está no ritmo certo pra chegar lá).
• Shazam: está num café e começa a tocar uma música boa, mas você não sabe o nome e/ou artista? Use o Shazam pra identificá-la. Uso bastante com trilhas sonoras de filmes também.
• Kindle: leitor de e-books, se integra muito bem com o Kindle for Mac.
• Reeder: ótimo leitor de feeds.

Hora dos jogos:

• Angry Birds e Angry Birds Seasons: clássico. Ótimo passatempo pra longas esperas.
• Cut the Rope e Cut the Rope: experiments: ótimo jogo que combina elementos de física e habilidade de raciocínio pra resolver os problemas.
• Contre Jour: uma mistura de Angry Birds, Cut the Rope, Portal e outros jogos, com uma trilha sonora e visuais muito bons.
• Rage HD: prévia do próximo jogo para consoles da id Software, um shooter muito bem feito.
• Infinity Blade: provavelmente o jogo com gráficos mais poderosos no iOS, leva o device (e a bateria) ao limite. O jogo em si não é uma obra-prima, mas vale pelos gráficos.
• Death Rally: corrida + destruição, power ups, jogo em estilo bem clássico com ótimos gráficos e controles.
• Fruit Ninja: mais um jogo clássico e ótimo pra passar o tempo.
• Civilization Revolutions: pra quem é fã da franquia, uma versão simplificada do Civ, dá pra fazer um jogo completo em pouco mais de uma hora.

É isso!

Como programadores costumam ser bem radicais (ainda mais com essa mania de ser “opinionado”), isso sempre gera discussões e atritos. Eu já penso que é mais fácil simplesmente buscar uma solução, e eis aqui uma: https://gist.github.com/1096494.

Colocando esse snippet no seu arquivo .irbrc, ao abrir o irb (ou console do Rails), todas as gems do gemset global do RVM serão colocadas no load path, podendo assim serem requeridas na sequência. Eu não costumo usar gemsets por projeto (uso apenas o Bundler, da maneira explicada nesse post), mas deixo o gemset global com algumas gems para esse fim. Meu arquivo .irbrc está disponível no GitHub.

Essa solução não é lá muito elegante, mas funciona muito bem para gems utilizadas no irb. Há algum tempo propus uma solução na lista do Bundler e recebi algumas sugestões, porém nenhuma me agradou (como, por exemplo, obrigar todo mundo que não quer as gems a usar a flag –without a cada bundle install). A discussão pode ser vista aqui. Até cheguei a fazer um fork do Bundler para implementar algum tipo de metadado para controlar isso, mas o código é bem complicado e acoplado, então deixei pra lá.

Como já foi falado anteriormente, esses princípios foram formulados com linguagens estáticas em mente e, por essa razão, precisam ser “adaptados” para que sejam aplicados em linguagens dinâmicas. Note que, em suas formas originais, esses princípios em geral recorrem a técnicas como herança para contornar as “amarras” do sistema estático de tipos.

No caso do LSP temos mais um exemplo disso. Em sua forma original ele é definido da seguinte forma:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

O que foi “traduzido” para o OOP da seguinte forma:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Em Ruby isso não é muito problemático pois, como sabemos, não estamos presos à tipos. O importante, como já vimos com o OCP, é manter a mesma interface, de forma que se precisarmos modificar alguma entidade, as demais entidades que dela dependem não precisem ser modificadas.

Além da interface, também precisamos prestar atenção ao comportamento. Modificações no comportamento podem fazer com que clientes da entidade sofram consequências inesperadas.

Já o ISP é definido da seguinte forma:

Clients should not be forced to depend upon interfaces that they do not use.

Isso quer dizer que um cliente (entidade que depende de alguma outra) não deve depender de interfaces não utilizadas por ele pois, em caso de modificação nessa interface, mesmo que o cliente em questão não a utilize, também terá que ser modificado.

Em linguagens estáticas há uma série de técnicas e artifícios para atingir isso. Em Ruby, o Duck Typing nos entrega esse princípio “de graça”, já que cada entidade depende apenas da interface que utiliza, independente do restante (e de tipos). Apesar disso, devemos sempre buscar entidades com interfaces coesas e bem delimitadas, evitando que sejam muito extensas e genéricas (o SRP se aplica aqui também). Aplicar o design pattern Adapter é uma boa forma de respeitar isso.

Bem, é fácil perceber que os últimos três princípios discutidos (OCP, LSP e ISP) lidam diretamente com formas de garantir interfaces estáveis para atingirmos o nosso objetivo de evitar que mudanças no código gerem um “efeito dominó” e façam com que tenhamos que alterar várias partes do software.

Mas, já que não temos estruturas como Interfaces e classes abstratas para garantir que estamos respeitando a interface definida, como garantir a aplicação desses princípios? Bom, há algumas formas para fazer isso. Você pode “emular” uma interface da seguinte forma:

class MyInterface
  def method_1
    raise "abstract method called"
  end
 
  def method_2
    raise "abstract method called"
  end
 
  # and so on...
end
 
class MyClass < MyInterface
  def method_1
    # do something
  end
 
  def method_2
    # do something
  end
end

Obs: também pode ser feito através de módulos e mixins ao invés de herança.

Isso funciona, mas não é muito o estilo Ruby, certo? A maneira que prefiro fazer é através de specs. Sempre que vou criar um wrapper/adapter ou qualquer estrutura que precise de uma interface estável mesmo quando o código encapsulado for modificado, crio um grupo de “specs de interface” e uso ela para toda estrutura que precise implementar a mesma.

Por exemplo, poderíamos escrever um cliente para o Twitter e escrever nosso código de modo que a gem que consome a API do serviço possa ser trocada sem maiores consequências:

 
# app/adapters/twitter_gem_adapter.rb
class TwitterGemAdapter
  def self.timeline(page=1, per_page=5, since_id = nil)
    options = {:page => page, :count => per_page}
    options[:since_id] = since_id if since_id
 
    Twitter.home_timeline(options)
  end
 
  def self.update(text)
    Twitter.update(text)
  end
 
  def self.reply(in_reply_to_status_id, text)
    Twitter.update(text, :in_reply_to_status_id => in_reply_to_status_id)
  end
 
  def self.retweet(tweet_id)
    Twitter.retweet(tweet_id)
  end
 
  def self.favorite(tweet_id)
    Twitter.favorite_create(tweet_id)
  end
end
 
# spec/support/shared_examples/twitter_adapter_examples.rb
module TwitterAdapterExamples
  shared_examples_for "any adapter for a twitter api gem" do
    it { should respond_to(:timeline)}
    it { should respond_to(:update)}
    it { should respond_to(:reply)}
    it { should respond_to(:retweet)}
    it { should respond_to(:favorite)}
  end
end
 
# spec/adapters/twitter_gem_adapter_spec.rb
describe TwitterGemAdapter do
  context "API contract" do
    subject { TwitterGemAdapter }
 
    it_behaves_like "any adapter for a twitter api gem"
  end
 
  # other specs ...
end

Aqui utilizamos a feature de “exemplos compartilhados” do RSpec, mas isso pode ser feito facilmente em outros frameworks. O importante é que, através dessas specs, garantimos que qualquer adapter implemente a mesma interface. Nesse caso cuidamos apenas disso, mas qualquer comportamento comum também pode ser especificado da mesma forma.

Material recomendado:

• The Liskov Substitution Principle for “Duck-Typed” Languages
• SOLID Ruby, by Jim Weirich – RubyConf 2009
• SOLID Object-Oriented Design, by Sandi Metz, GoRuCo 2009

Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification.

Originalmente, a ideia é que, uma fez finalizada, uma entidade só poderia ser modificada para correções. Qualquer nova “feature” deveria ser implementada em uma nova entidade, que aproveitaria o código da primeira principalmente através de herança. Isso resulta em reaproveitamento da implementação, mas não garante a consistência da interface.

Um pouco depois, com a introdução e popularização de classes abstratas e recursos de linguagem como Interfaces, o princípio evoluiu e passou a ser aplicado em conjunto com o DIP, fazendo com que o código sempre dependesse de interfaces ao invés de implementações. Com isso, era possível reaproveitar uma interface (closed) e modificar a implementação (open).

Mas e nas linguagens como Ruby, em que abrir uma classe é tão simples como definí-la e pode ser feito a qualquer momento? Será que esse princípio se aplica? Isso sempre é tema de muita discussão e aqui vai minha visão sobre isso.

Bem, com Ruby temos algumas formas de modificar uma classe, como herança, mixins, reabrir a classe ou usar metaprogramação. Perceba que, exceto pela herança, as outras maneiras infringem a ideia original do princípio. Mas, como já vimos, o próprio princípio evoluiu para abraçar mudanças nas linguagens e paradigmas.

O importante, principalmente em linguagens com Duck Typing (que, como já vimos, não dão a mínima para tipos), é que a interface seja fechada. Não importa o modo que você escolher para fazer as modificações, desde que a “superfície de contato” entre as entidades permaneça estável.

No exemplo do post anterior poderíamos modificar as classes que passamos como dependências via parâmetro e utilizá-las sem problemas, desde que a interface permanecesse a mesma. Uma vantagem adicional da tipagem dinâmica é que nesse caso podemos utilizar também herança (modificando o “tipo”) sem precisar modificar o código cliente, que só se importa com a interface.

Dessa forma, podemos modificar um pouco o enunciado do OCP para adaptá-lo à nossa linguagem preferida:

Software entities (classes, modules, functions, etc) should be open for extension, but closed for interface modification.

Recomendo esse vídeo-podcast sobre o assunto: Monkeypatching and the Open-Closed Principle

Bom, isso faz muito sentido em linguagens estáticas como Java, onde há estruturas como Interfaces, classes abstratas e outras parafernalhas. No final, na minha modesta opinião, o código torna-se um espetáculo bizarro de indireção e pode mais confundir do que ajudar se você não for cuidadoso. Mas e nas linguagens dinâmicas?

É comum ouvir que, quando você utiliza uma linguagem que contém Duck Typing (a característica que mais gosto no Ruby), você obtém os benefícios do DIP “de graça”. Isso não é bem verdade. Você os obtém de graça somente se pedir com jeitinho.

O que quero dizer com isso?

Vamos ao exemplo do artigo anterior em sua última versão:

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
end
 
class GamePriceService
  attr_accessor :game
 
  # we could use a config file
  BASE_URL = "http://thegamedatabase.com/api/game"
  API_KEY = "ek2o1je"
 
  def initialize(game)
    self.game = game
  end
 
  def get_price
    data = open("#{BASE_URL}/#{game.name}/price?api_key=#{API_KEY}")
    JsonParserLib.parse(data)
  end
end
 
class GamePrinter
  attr_accessor :game
 
  def initialize(game)
    self.game = game
  end
 
  def print
    price_service = GamePriceService.new(game)
    <<-EOF
      #{game.name}, #{game.platform}, #{game.year}

      current value is #{price_service.get_price[:value]}
    EOF
  end
end

Esse código possui algumas dependências rígidas. Chamamos as classes GamePriceService e JsonParserLib explicitamente dentro de GamePrinter#print e GamePriceService#get_price, respectivamente. Note que, apesar do Duck Typing nos permitir utilizar componentes com uma determinada interface independente de tipo, fizemos com que nossas classes fiquem amarradas à alguns tipos através dessas dependências.

Uma forma de se aproveitar dos benefícios do Duck Typing e, assim, conseguir “de graça” as vantagens do DIP, é tornar nossas dependências transparentes. Enquanto linguagens estáticas costumam se utilizar (embora isso não seja obrigatório) de complexas bibliotecas de injeção de dependência para fazer isso (ah, meus tempos de Java e Spring ), em Ruby isso é tão simples quanto passar um parâmetro:

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
end
 
class GamePriceService
  attr_accessor :game, :json_parser
 
  # we could use a config file
  BASE_URL = "http://thegamedatabase.com/api/game"
  API_KEY = "ek2o1je"
 
  def initialize(game, json_parser = JsonParserLib)
    self.game = game
    self.json_parser = json_parser
  end
 
  def get_price
    data = open("#{BASE_URL}/#{game.name}/price?api_key=#{API_KEY}")
    json_parser.parse(data)
  end
end
 
class GamePrinter
  attr_accessor :game, :game_webservice
 
  def initialize(game, game_webservice = GamePriceService)
    self.game = game
    self.game_webservice = game_webservice
  end
 
  def print
    price_service = game_webservice.new(game)
    <<-EOF
      #{game.name}, #{game.platform}, #{game.year}

      current value is #{price_service.get_price[:value]}
    EOF
  end
end
 
# Usage example:
game = Game.new(some_game_data)
webservice = GamePriceService.new(game)
game.price = webservice.get_price
 
GamePrinter.new(game).print

Aqui escolhemos passar essas dependências através dos construtores das classes. Dessa forma, ficamos livres da dependência de tipo e passamos a depender apenas de uma interface. Basta que a classe passada no construtor responda aos métodos que utilizamos e não teremos problema. Outra forma seria passar as dependências apenas para os métodos que as utilizam:

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
end
 
class GamePriceService
  attr_accessor :game
 
  # we could use a config file
  BASE_URL = "http://thegamedatabase.com/api/game"
  API_KEY = "ek2o1je"
 
  def initialize(game)
    self.game = game
  end
 
  def get_price(json_parser = JsonParserLib)
    data = open("#{BASE_URL}/#{game.name}/price?api_key=#{API_KEY}")
    json_parser.parse(data)
  end
end
 
class GamePrinter
  attr_accessor :game
 
  def initialize(game)
    self.game = game
  end
 
  def print(game_webservice = GamePriceService)
    price_service = game_webservice.new(game)
    <<-EOF
      #{game.name}, #{game.platform}, #{game.year}

      current value is #{price_service.get_price[:value]}
    EOF
  end
end
 
# Usage example:
game = Game.new(some_game_data)
webservice = GamePriceService.new(game)
game.price = webservice.get_price
 
GamePrinter.new(game).print

É uma maneira melhor para evitarmos construtores muito complexos quando esse for o caso. Uma vantagem adicional é obtida através da utilização de valores padrão para os parâmetros. Desta forma, a não ser que queiramos utilizar alguma dependência não-padrão, as dependências ficam totalmente transparentes.

Mais uma vantagem é no momento de escrever testes. Passando dependências dessa maneira, é muito fácil criar objetos dublês e utilizá-los para facilitar o processo (tornar a execução mais rápida, evitar o uso de webservices reais etc). Um exemplos simples e eficiente pode ser visto aqui. (slides 34, 35 e 36)

Em geral, se você não conseguir substituir uma dependência por um dublê em suas especificações, seu código está muito rígido e pode se beneficiar da aplicação desse princípio.

Leitura adicional:

Make Your Dependencies Translucent with Default Parameters

Um conjunto de técnicas que podemos utilizar para atingir esse objetivo é chamada de SOLID, um acrônimo que representa cinco técnicas:

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

O objetivo desses princípios é fazer com que alterações necessárias sejam feitas no menor número possível de locais no código. Em outras palavras, é diminuir o custo dessas mudanças através de um design que reduz os efeitos colaterais das modificações.

Nesse artigo vou mostrar um pouco sobre a aplicação do Single Responsibility Principle em Ruby.

Esse princípio nos diz que uma classe deve ter apenas uma responsabilidade e deve executá-la por completo (não devem haver outras classes que executem partes dela). É uma forma de conseguir alta coesão, uma qualidade desejável em código orientado a objetos. Uma classe coesa executa completamente uma responsabilidade, ou seja, essa responsabilidade não fica fragmentada e espalhada entre diferentes entidades no domínio.

Uma forma de pensar sobre o que é uma responsabilidade para facilitar a absorção do conceito é que esta representa uma razão para mudar. Então podemos definir o princípio como: uma classe tem uma e apenas uma razão para mudar.

Vamos a um exemplo de um modelo ActiveRecord que viola esse princípio (alerta para pseudo-código que nem deve funcionar, é apenas um exemplo):

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
 
  def get_official_price
    open("http://thegamedatabase.com/api/game/#{name}/price?api_key=ek2o1je")
  end
 
  def print
    <<-EOF
      #{name}, #{platform}, #{year}

      current value is #{get_official_price}
    EOF
  end
end

Esse modelo tem como sua responsabilidade principal cuidar da lógica de negócio ligada à entidade Game. Porém, como podemos ver aqui, ele também está responsável por consultar um webservice para obter a cotação do jogo e por formatar sua exibição. Essa implementação possui baixa coesão pois essa classe possui mais de um motivo para mudar. Ela será alterada se os requisitos de validação de dados mudarem, se algum detalhe da chamada do webservice mudar ou se precisarmos exibir seus dados numa formatação diferente.

Uma forma de resolver isso seria desmembrar essa classe tendo esse resultado:

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
end
 
class GamePriceService
  attr_accessor :game
 
  # we could use a config file
  BASE_URL = "http://thegamedatabase.com/api/game"
  API_KEY = "ek2o1je"
 
  def initialize(game)
    self.game = game
  end
 
  def get_price
    data = open("#{BASE_URL}/#{game.name}/price?api_key=#{API_KEY}")
    JsonParserLib.parse(data)
  end
end
 
class GamePrinter
  attr_accessor :game
 
  def initialize(game)
    self.game = game
  end
 
  def print
    price_service = GamePriceService.new(game)
    <<-EOF
      #{game.name}, #{game.platform}, #{game.year}

      current value is #{price_service.get_price[:value]}
    EOF
  end
end

Assim aumentamos bastante a coesão de nosso sofware. Cada classe possui apenas uma razão para mudar e atende ao SRP.

Um exemplo mais real pode ser visto no modelo Creditcard do Spree. Note que, entre outras coisas, o modelo também é responsável pelos processos de compra e autorização do cartão (métodos purchase e authorize). Note como esse métodos implementam parte do processo e delegam outras partes para outros componentes quando a responsabilidade deveria ser 100% realizada em outra parte. Isso cria baixa coesão (múltiplas responsabilidades por classe) e alto acoplamento (uma responsabilidade dividida por várias classes interdependentes).

Como um exercício a parte podemos pensar sobre até que ponto modelos do ActiveRecord quebram o SRP por serem responsáveis por persistência e lógica de negócios (que inclui validação de dados). Há muitos desenvolvedores dos dois lados nessa questão. Acredito que há pequenas violações mas de uma forma não prejudicial, já que a persistência é implementada por uma classe especializada e apenas herdada em nossos modelos, de forma que essa é delegada ao framework (que cuida de possíveis modificações necessárias à persistência).

É preciso ter em mente que ser muito extremista com esses princípios também pode levar à problemas e a um excesso de preciosismo que torna-se prejudicial.

Bom, a partir daqui vamos para outros artigos onde serão explorados os outros princípios. O pseudo-código utilizado no exemplo acima ainda tem algumas coisas a ganhar através da aplicação de outros princípios.

Leitura recomendada:

• Cohesion
• Coupling
• Separation of concerns

É algo muito bom que cada desenvolvedor possua sua “stack” preferida de ferramentas. O apreço por esse conjunto leva à dedicação e ao domínio do mesmo.

Entre nós, que orgulhosamente nos categorizamos como “trabalhadores do conhecimento”, creio que, apesar desse apreço à priori não causar prejuízo, trocar de conjunto de ferramentas deveria ser muito fácil (e uma habilidade desejável) já que o que importa é a transformação do conhecimento da forma bruta (dados) à forma desejada (informação), independente do que foi utilizado para isso. É claro que há sempre a curva de aprendizado numa troca dessas: uma nova linguagem, nova DSL/API etc, mas os fundamentos e princípios se mantém.

Nerds, assim como toda pessoa imersa numa sociedade consumista, se definem pelo que consomem e utilizam. Isso é algo bem comum atualmente e vai desde roupas até computadores, editores de texto, smartphones e, pasmem, à p**** da biblioteca que o cara usa pra fazer parsing de XML. Algo que tornou-se muito comum, principalmente com a facilidade que existe para que cada um publique seus pensamentos (blogs, Twitter e afins), é que ocorram “guerras” sobre esse tipo de coisa, já que, em nossa mente, criticar uma coisa que consumo é praticamente criticar a mim e meu modo de viver.

Entre desenvolvedores isso é bem visível. Além das guerrinhas entre comunidades (.NET x Java, Ruby x Python etc) há também as guerras intra-comunidade, em que escolhas de ferramentas são motivo para disputas de ego intermináveis. O cenário, em geral, mostra uma galera que gosta da ferramenta X e acha que, por isso, a ferramenta Y é uma merda inútil e o pessoal que gosta da ferramenta Y achando o mesmo da ferramenta X.

Passemos a um exemplo num contexto diferente para que pré-disposições não afetem nossas conclusões. Imagine que Gordon Ramsay irá a sua casa para fazer o jantar. Ele não vai levar as facas, panelas e demais utensílios que usa em seu dia-a-dia. Vai utilizar apenas o que tem em sua casa. Dias depois você irá a casa dele e utilizará todos os utensílios profissionais à disposição. Bom, a não ser que você seja um anônimo chef de primeira categoria, sabemos quem irá preparar o melhor jantar, não? (sem piadinhas hein! )

Mais um. Quem será que toca melhor: Steve Vai com uma guitarra Giannini de 500 reais ou você com as guitarras ultra-caras dele?

Onde está o conhecimento? Na ferramenta ou no profissional?

Algo bizarro que acontece é ver pessoas que deveriam ter bons conhecimentos sobre lógica confundindo argumento com preferência. Dizer que você prefere X porque acha mais bonito ou mais legal é só sua preferência, não é um argumento para diminuir as alternativas. Chega de “RSpec é mais bonito e moderno, então Test::Unit sucks!” e vice-versa (exemplo aleatório, sem flames por favor).

BREAKING NEWS: se você não sabe patavinas sobre design de código orientado a objeto e uma meia dúzia de princípios básicos, escrever testes em RSpec não vai fazer com que você escreva código melhor do que escrevendo com Test::Unit. Aliás, é bem capaz de piorar as coisas, mas isso é conversa pra outro post.

Em linhas mais práticas, pouco importa para o interessado na informação se ela é processada em PHP ou Ruby, se é formatada em ERB ou HAML ou se está armazenada em MySQL ou PostgreSQL. A ferramenta “certa” é a que faz o trabalho. Sempre há muita discussão sobre isso de “ferramenta certa” e, a não ser que seja algo obviamente errado como usar o Rails pra fazer uma aplicação desktop com controles nativos, o que sempre acaba entrando em jogo é preferência, gosto, estética e etc. Novamente, isso simplesmente não serve como evidência de que algo é superior ou inferior.

“Mas eu sou mais produtivo com X do que com Y!”
“Olha só como meu código fica mais limpo com Z do que com N!”

É, amiguinho. Pra você. Assim como tem muita gente que acredita em divindades criadoras e muita gente que não. Muita gente que acha carros da Porsche bonitos e muita gente que os acha toscos e que os carros da Toyota sim são lindos. Daí a dizer que algum é melhor ou pior é um longo caminho (e, na minha visão, um caminho inexistente).

Pois bem. Por isso creio que, como comunidade, devemos mudar um pouco nosso foco. Tudo bem falar sobre ferramentas, é algo saudável desde que feito com bom senso. Com argumentos, fatos, contexto e harmonia. Não com guerrinhas bobas sobre gosto pessoal e como seu pau é maior que o dos outros sua gem preferida é a mais fodolenta do OMNIverso. É bom para conhecermos alternativas e evoluirmos. Se todo mundo se prendesse ao atual e rejeitasse as novidades, ainda estaríamos perfurando cartões. Enfim, é preciso foco em coisas que realmente fazem a diferença na qualidade. Foco em fundamentos e princípios.

Estatísticas do DataLucas mostram que, a cada dois dias, surgem dezenas de posts falando sobre alguma gem que é a coisa mais maravilhosa já inventada desde o carro voador Toddynho (e que prova que todo o resto é uma merda!), sobre uma miríade de workflows para o VCS da moda, sobre porque a minha biblioteca é mais foda que a sua, sobre como o Agile morreu e, claro, como ele ainda está vivo e funciona muito bem sim senhor!

Legal, todo mundo tem uma opinião sobre o que prefere e sobre o que não gosta. Muito bom, ótimo, sensacional. Mas e o que é imutável? Aquilo que determina qualidade independente do meio utilizado? Já postei bastante essa frase, mas sempre gosto de relembrar:

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Ainda não achei frase que se encaixe mais com meu pensamento sobre desenvolvimento de software. Seja no nível gerencial ou técnico, dominar métodos (ferramentas) ignorando princípios com certeza leva à problema. Manjar de todas as cerimônias e artefatos das metodologias ágeis não vai produzir software de qualidade magicamente. Entender seus princípios, mesmo que você não aplique toda a parafernalha cerimonial, com certeza trará efeitos positivos.

Então fica a pergunta: onde estão os posts e talks sobre princípios? Vamos falar sobre coisas como SOLID (não, não é um besteirol acadêmico), acoplamento, coesão, testes que realmente especificam comportamento, trade-offs arquiteturais e outras questões importantes?

Tentarei fazer a minha parte nisso. Ano passado na RubyConf parte da minha apresentação falou sobre princípios (e outra sobre ferramentas ) e penso em continuar com essa temática tanto no blog quanto em futuras apresentações. Gostaria muito que a comunidade valorizasse mais esse tipo de discussão (wishful thinking…).

Já fiz muito dessas guerrinhas, não sou inocente, mas aprendi a valorizar a base, principalmente abrindo a mente (olha a piadinha!) e dando chances à ferramentas diferentes e, com isso, percebendo que em nossa profissão, felizmente, há vários meios eficientes para atingir os resultados desejados.

And… here comes the flames?

PS: se você é do contra e vai bater o pézinho dizendo que preferência e estética são evidências qualitativas, pode desistir e vaza.

Leitura recomendada: “A Little Knowledge is a Dangerous Thing“

Bem, não me preocupei muito com o motivo disso. Busquei algumas maneiras de formatar essa saída e, entre outras, encontrei a gem turn. Configurei-a no Gemfile do projeto e tudo funcionou perfeitamente de primeira, sem nenhum incômodo. Além da formatação, uma feature interessante é que, ao invés de mostrar pontinhos e letras (ex: …..F…F.), o turn vai mostrando as descrições dos testes e seu status (passou/falhou) à medida que a suite é executada. Feedback bem mais útil.

Veja um exemplo de como fica a formatação através desse link: http://d.pr/mWPe (assim não quebro todo o layout do blog).

Em geral o processador do meu MacBook opera em temperaturas razoáveis. Porém, quando preciso abrir algum conteúdo em Flash… temperaturas de até 92ºC e fan a 6500 rpm são lugar comum. Uma maneira de resolver isso seria a Adobe criar vergonha na cara é utilizar o CoolBook para fazer com que o processador opere numa voltagem mais baixa.

Um pouquinho de teoria: é óbvio que, para operar, o processador precisa consumir energia. A frequência de clock é a principal determinante de quanta energia será consumida. Quanto maior a frequência de operação, mais energia é necessária. O fabricante do processador estabelece voltagens seguras para o clock de cada processador. Porém, nem todo processador nasce igual: por motivos dos mais variados, alguns aguentam mais tranco que os outros. Processadores de notebooks costumam ser os mais “aptos” a isso, pois funcionam com voltagens inferiores aos processadores de desktops. Por isso é possível brincar um pouco e testar voltagens inferiores à padrão.

Com o CoolBook é possível fazer isso, prática conhecida como undervolting (não é possível fazer overclocking com ele). Algumas vantagens do undervolting são: menor temperatura de operação (que leva a menos barulho de fans), maior autonomia da bateria e maior durabilidade da máquina (devido a menos aquecimento). O aplicativo também permite configurar o throttling, que é o ajuste automático da frequência do processador de acordo com a carga de trabalho. Isso ajuda com o consumo de bateria, desde que as frequências mais baixas utilizem voltagens mais baixas. Utilizar frequência de 1Ghz a 0,9v não economiza nada em relação a uma frequência de 1,5Ghz a 0,9v. Dessa forma, só é algo útil se seu processador não for capaz de rodar em sua frequência máxima com a voltagem mínima.

Ao abrir o CoolBook, são mostrados os pares frequência/voltagem padrão para seu processador:

Note as abas “Adapter” e “Battery”. Através delas é possível estabelecer configurações distintas para quando o notebook está ligado à tomada e para quando está utilizando a bateria.

Ao fazermos as modificações, precisaremos fazer alguns testes de carga para verificar se o sistema se comportará bem. Para fazer esses testes, basta utilizar o CPUTest, com as configurações abaixo:

Quanto mais pesados os testes, maior a “garantia” de que o sistema está estável.

Uma coisa importante é nunca salvar as configurações antes de testá-las apropriadamente. Para isso, sempre utilize o botão Set, nunca o Save. Ao clicar nesse botão, o CoolBook colocara o processador para funcionar na frequência e voltagem selecionadas nos combos (caixas de seleção) acima dele.

O processo então é o seguinte: nas caixas de seleção, escolha a frequência e a voltagem desejadas. Clique em Set. Inicie um teste no CPUTest. Se tudo deu certo, é uma configuração estável (caso contrário ocorrerá um kernel panic e basta reiniciar a máquina). O recomendado é baixar um “degrau” de voltagem por vez e testá-lo bastante. Após isso utilize o botão Add para adicionar o par à janela de configuração.

Em geral, faz-se isso com dois ou três pares de frequências e voltagens e deixa-se habilitado o throttling para que o CoolBook selecione a frequência apropriada para o nível de carga de trabalho atual. Não é preciso deixar a janela do programa aberta. Você pode fechá-la e haverá um pequeno processo do CoolBook rodando em background o tempo todo para ajustar as frequências. O nível de throttling (Low, Medium, High, Very High) define a agressividade do mesmo: quanto mais alto, mais frequentemente será feita a troca de frequência. Também é possível configurar uma temperatura limite que, ao atingida, causará a seleção de pares com frequência e voltagem inferiores. O checkbox B/2 serve para cortar a velocidade de bus à metade para diminuir ainda mais a “sede” do processador. Não utilizo essa opção, então não posso afirmar se é eficiente.

O throttling é algo bem útil, mas deixará um processo rodando o tempo todo, consumindo um pouco de processamento e memória (bem pouco, mas ainda sim consumindo). Se você der mais sorte, conseguirá o supra-sumo da eficiência energética e computacional: configurar o processador para sua máxima frequência e mínima voltagem. Dessa forma terá a máxima eficiência: muitas vezes, diminuir a frequência leva o processador a precisar de mais ciclos para terminar uma tarefa. Assim, poderá consumir mais energia que uma frequência mais alta, mesmo utilizando menos voltagem (daí não fazer sentido manter frequências baixas com voltagens iguais à de frequências mais altas).

Eu tive essa sorte e consegui configurar meu processador (Core 2 Duo L9600 2.13Ghz) da seguinte maneira:

Assim, consegui os benefícios que citei acima. Jogando Madden Superstars, um jogo em Flash bem pesado, as temperaturas batiam em 92ºC e o fan disparava, fazendo bastante barulho. Agora, as temperaturas ficam na casa de 78ºC e o fan só começa a girar alto o suficiente para causar ruído (>4000 rpm) após um bom tempo no jogo, presumivelmente por aquecimento da mesa também, o que diminui e eficiência do resfriamento – se utilizo uma base refrigerada, isso não ocorre. A temperatura “em repouso” (quando não estou fazendo quase nada) caiu para ~45ºC, mesmo em dias quentes. Isso tudo também leva a um ganho de duração de bateria na casa de 10% a 15% (claro, dependendo da carga de trabalho).

Note que, como desabilitei o throttling, não há um processo do CoolBook rodando em background e checando as configurações. Com isso, se reiniciar o sistema, a configuração volta ao padrão (no meu caso, 2128 Mhz e 1,0625v). Para não esquecer desse detalhe e acabar usando o processador com mais voltagem do que o necessário, configurei o CoolBook para abrir automaticamente após o boot do sistema – dessa forma, basta clicar em Save logo após o carregamento do sistema e o par frequência/voltagem será aplicado. Como é bem raro precisar reiniciar, não chega a ser um incômodo.

Como a explicação textual não é lá a mais eficiente, se ficou com alguma dúvida, visite a página de vídeos do CoolBook, que mostra esse processo.

Aviso: apesar de underclocking e undervolting não serem considerados arriscados como overclocking e overvolting, não me responsabilizo por problemas decorrentes do uso do CoolBook ou aplicativos semelhantes.

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Substitua “método” por “linguagem” e isso resume muito bem o meu pensamento.