If you need cronjobs you probably use the whenever gem. It’s an awesome tool to configure your scheduled jobs with a nice and easy DSL. It also has built-in integration with Capistrano, but there’s a caveat: it will update the crontab of the deployer, not the runner‘s one.

To solve that issue, I’ve dropped the “automatic” integration (just a simple require “whenever/capistrano”) and used a hook to invoke whenever passing a user option to specify which user’s crontab to update. Here’s the relevant code:

after "deploy:update_code" do
  run "cd #{release_path} && #{try_sudo} GEM_HOME=/opt/local/ruby/gems RAILS_ENV=production bundle exec whenever --clear-crontab #{application} --user #{runner}"
  run "cd #{release_path} && #{try_sudo} GEM_HOME=/opt/local/ruby/gems RAILS_ENV=production bundle exec whenever --update-crontab #{application} --user #{runner}"
end

The code above sets some env vars for sanity sake and runs whenever specifying the runner user as the crontab owner.

There’s another small tweak you’ll need. On your schedule.rb file, add the following code on the very first line:

env "PATH", ENV["PATH"]
every 10.minutes do
  # ...
end

This will avoid nasty path-related errors (the cronjobs won’t find the gem’s bins and all that). And… that’s it! Have fun!

1) Descubra qual o seu “gem path”, o local onde suas gems estão instaladas. No meu caso, o Rails está instalado diretamente no sistema e não utilizo rvm ou rbenv. Para encontrar essa informação, utilizei o comando “gem env” diretamente no terminal. Meu path é “/usr/local/lib/ruby/gems/1.9.1/gems/”.

2) Acesse o diretório da gem railties. Essa gem é como um “rails-core”, sendo o núcleo e o “hub” em que todas as outras gems que compõe o framework (e também extensões de terceiros) se registram para serem carregadas:

lucashungaro@IronMan:/usr/local/lib/ruby/gems/1.9.1/gems
$ cd railties-3.2.2/guides
 
lucashungaro@IronMan:/usr/local/lib/ruby/gems/1.9.1/gems/railties-3.2.2/guides (master)
$ gem install RedCloth
 
lucashungaro@IronMan:/usr/local/lib/ruby/gems/1.9.1/gems/railties-3.2.2/guides (master)
$ ruby rails_guides.rb
 
lucashungaro@IronMan:/usr/local/lib/ruby/gems/1.9.1/gems/railties-3.2.2/guides (master)
$ mv output ~/projects/documentation/rails_guides_3.2.2

Isso irá compilar os guias no diretório local “output”, o qual movemos para uma localização mais familiar. Não encontrei uma forma de mudar o diretório com argumentos na linha de comando. Você pode fazer isso se chamar o gerador via código, no entanto. O script aceita outras opções via linha de comando, como a opção de gerar guias para o Edge Rails ou versão Kindle, entre outras.

3) Ao término do processo, teremos os guias compilados em HTML no diretório indicado. Para acessá-los você pode criar um bookmark em seu browser ou utilizar um SSB. Prefiro a segunda maneira e, para isso, utilizo o Fluid (para encontrar alguns ótimos ícones visite esse grupo no Flickr. Basta criar uma nova aplicação e apontar para o diretório em que geramos os guias, iniciando pelo arquivo index.html.

Rails Guides com Fluid

First, let’s review some things:

• Yes, I know you can deactivate a lot of the bundled stuff in Rails; that doesn’t solve any of the issues.
• Yes, I’m aware of Railties; It’s nice, well built, a good step forward; still doesn’t solve any of the isses.
• Most of the people who reacted badly to my article (and @merbist‘s one) pointed out that, to use and understand Rails’ “modularity” you’re supposed to buy a book; I don’t think it should be necessary (nothing against the book, it’s very good)

The issues I pointed out converge to one thing: modularity isn’t configurability. Yeah, I can edit my default generated Rails app and remove all sorts of things, including using some hackish code to remove middlewares from its stack. This isn’t modularity on the application-level.

I know that Rails’s internals are more modular on Rails 3 than they’ve ever been. I’ve saw Jose Valim’s talk about how they’ve applied SOLID principles to achieve that, it’s really nice (read the slides if you can, it pays off). I’m not talking about that. I’d like to emphasize that I’m talking about modularity at the application level, not at internal code level.

Here’s an example (hypothetical context, of course):

$ rails new my_app # generates a lean app (not a Sinatra-style app, a Rails app without the unneeded stuff)
 
... # days after
 
# Hmmm, I need to send e-mails!
$ cd my_app
$ rails add actionmailer # adds and installs actionmailer, generates the boilerplate needed
 
# Hmmm, I need to speed up my assets load time!
$ rails add rails-assets-pipeline

Modular. Apps. Things I can incrementally build upon. Now, mailer should probably be there by default, but you get the idea.

These gems would be separated from Rails core. I really don’t care if a “full” Rails app ends up installing 100 gems as long as I’m in control of that and can start with way less.

What’s the advantages?

• Easier to learn: beginners will have a better experience since they can learn the framework gradually;
• Still powerful: that doesn’t force you to dumb it down, as many suggest. Modular apps suit the needs of novices and experienced developers as well;
• Goodbye clutter and unneeded code: the framework will only load the code I need. Boot time will be decreased as well as memory consumption. Yes, I know that if you deactivate something today, most of the code won’t be loaded, which gets us to…
• Less code to understand: it will be easier to contribute to the framework as it will have way less code and I can gradually dig in. I can contribute with the core without stumbling into the assets pipeline, for example.

Well, I could elaborate more on that, but it’s the main idea. Rails’ internals are way better, yes, and that’s awesome. But the framework still lags behind on many things I think should receive priority instead of adding built-in support for SASS, CoffeeScript and things like that. I’m currently taking a look at Rails’ codebase to see how I can fit these ideas in. I hope to have some pull requests ready soon. If you’re interested in helping, please contact me.

]]> http://blog.lucashungaro.com/2012/03/01/modularity-on-rails/feed/ 7 http://blog.lucashungaro.com/2012/03/01/modularity-on-rails/ http://feedproxy.google.com/~r/LearningOnRails/~3/7xPiyvXg9a8/ http://blog.lucashungaro.com/2012/03/01/rails-has-entered-the-framework-death-spiral/#comments Thu, 01 Mar 2012 04:44:52 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=423 I usually write here in Brazilian Portuguese but this post is written in English in the hope of getting some useful attention and discussion going on (yes, wishful thinking).

Before we start this, let’s make some things clear. When I criticize Rails there’s two common reactions:

The Lovers:

• “OMG, DHH and the Core Team are awesome, they know what’s better for you, stop crying!”
• “Well, stop using Rails and create something better!”
• “You should not criticize the tool that pays your bills!”

The Haters:

• “Yes! Yes! Let’s burn these motherfuckers!”

Let me be totally clear here: Rails is very useful and I like it a lot (although I used to like it way more). Otherwise I would just dismiss it and don’t even bother trying to get some attention to the issues I’ll describe. I respect the work and effort of so many people that keep the framework going fixing bugs and adding features. You should too, it’s not a walk in the park and very few people actually get some time to do this kind of work. A special mention goes to Aaron Patterson (@tenderlove), a guy who relentlessly keeps cleaning up the mess that Rails’ codebase has become while still keeping his humility (sadly, a rare trait in our community).

Some days ago, when talking with a friend, he said “Rails has entered the framework death spiral – it’s now adding features for feature-sake”. I agree. The “Rails is opinionated software” idea is clearly lost as it’s trying to embrace everything and has turned into a playground for some people (not the entire team, to be clear) instead of a framework that shapes the way web applications are created (that paradigm is shifting and meanwhile Rails is messing around with CoffeeScript and SASS).

One example of this “playground theory”? Releasing a piece of crap like the assets pipeline, clearly rushed and so fucked up that it makes me think if it’s the worse thing I ever had to use to build software, occupying a honorable spot besides the Struts framework, ASP and JavaServer Faces.

The main problem, in my humble opinion, is: Rails has turned into bloatware. I see the problem from two angles: as a potential contributor and as a user of the framework.

As a contributor

Rails has so many things included by default now that the code is really big. I tried to understand it some time ago and got quickly frustrated by the massive amount of coupled code and features that distract you from the main workflow of the framework. Yes, I could probably just get some ticket and solve a bug, but I like to understand the whole before going around throwing code like crazy to get some commits in. OSS activists will probably bash me for this, calling me lazy, but it’s the way I work, sorry.

The solution? Well, my suggestion is this: the rails gem should contain only the core, the request processing cycle and hooks for the other parts to hang in (ORMs, template engines, other gems in general). It already has this in some form, a framework called Railties, but all the things that hook into it are still in the same codebase, divided in a few other gems.

The asset pipeline is a main offender here and the easiest example to bring to the surface. This thing should *really* be into its own gem and out of Rails. It could be included in Rails’ default Gemfile, I don’t care, but please do not throw more code into the mess. I won’t even start the discussion about the quality of the pipeline per se, but I digress. If you want the default approach, the one the Core Team chose, just generate a full app and install de default gems. Otherwise we could have a lean application generator that remove all the uneeded dependencies without hacks. Better yet if that one could be the default.

If my memory isn’t failing me, I believe Merb did things this way. Besides lessening the burden on contributors it should force people to write decoupled code, something the Rails Core Team has been improving on for some time now, by the way.

Yes, I know Rails included extra things like ActionMailer and ActiveRecord from the beginning and they’re independent gems. As I said before, I’m fine with default choices, but I also think that Rails’ starting point should be a lean and simple mini-stack that could be easily incremented as the user needs it to be.

As a user

People who are experienced with Rails tend to forget that beginners do exist. Most of the so called “Railers” I know see themselves as a kind of superior being surfing the waves of awesomeness, forgetting that legacy must be supported and new people will try Rails. Funny thing is that the developers that use Rails as a mere tool (what it is) see this issue clearly, while people that see it as a religious cult dismiss it.

The first issue is legacy. Rails completely ignore this (as is common with frameworks in so called “non-enterprise” ecosystems) and makes no effort to support people that work with legacy code. The community itself fails hard at this, as we don’t even talk about that as we should. Think about how rare it is to see a talk about legacy applications on conferences in contrast to the plethora of talks about new features/libraries or how you should be writing your code. We fail hard here.

The second issue is that, as of today, Rails is incredibly hard for beginners to learn and use effectively. It’s slow, has a freaking unbelievable amount of dependencies right of the bat (this can be normal down the road, not by default), it’s cumbersome to set up (don’t you love some gem version hell?), it’s not quick to get up and running anymore. I usually joke that the “15 minutes blog” today should be called “the 1 hour and 30 minutes blog”. That’s not to mention the big disparity between the official literature and documentation (“the DHH way”) and the way real Rails apps are developed.

EDIT: to be fair, I installed the latest Rails and generated a new app. No version hell this time, hurray! The last three times I did it, it was a nightmare. Things are still slow though. You can generage your application with “rails new my_app –skip-sprockets –skip-test-unit” to drop the generation time from ~2 minutes to about ~30 seconds. Other flags like –skip-active-record and –skip-javascript are available to bypass some default dependencies.

It’s hard for people who already knows Rails to imagine how it is to begin with the framework today. I’ve seen beginners trying it and it was ugly. Think about how many unrelated things someone has to go through to understand a simple “Hello World” in a default Rails application today.

What got me interested in Rails was the “batteries included” approach, yes. But there was a thin line and, to me, that line has been crossed. Rails went past the line of “including everything you need for a quick start” to “including everything the Core Team thinks you need to build a gigantic web application following every techniques they find appropriate”. Yes, I know it’s best practice to minify my JavaScript but I’m a grow up, let me do it the way I want without clogging up the framework with a lot of useless code (yes, I can deactivate it, but it’s still useless since I won’t use it and it will slow my boot time and bloat the framework code, hence the idea of splitting Rails into more gems and do not install them by default nor include them in the same codebase).

Conclusion

The Rails framework should really get trimmed down. Non-fundamental trinket should be separated and, maybe, we could have two application generators: a “lean” (maybe just ActionPack and Railties, something like that) one and a “full” one. That way it would be a lot easier to grasp the framework code and contribute while allowing newcomers to taste the goodies gradually, learning instead of being drowned into a lot of concerns that really doesn’t relate to the core of developing a well built application.

EDIT: Yes, the title of the article is harsh and I recognize it does not reflect what I wanted to suggest here. It was wrong and tabloid style. It was chosen out of frustration, which shouldn’t be a reason to do it. The intention of the article is to spark a good discussion, not to be alarmist and accusatory, which the title makes it sound like.

]]> http://blog.lucashungaro.com/2012/03/01/rails-has-entered-the-framework-death-spiral/feed/ 5 http://blog.lucashungaro.com/2012/03/01/rails-has-entered-the-framework-death-spiral/ http://feedproxy.google.com/~r/LearningOnRails/~3/4xuNa5_rEMg/ http://blog.lucashungaro.com/2011/09/03/iphoneipad-minhas-aplicacoes-favoritas/#comments Sat, 03 Sep 2011 19:34:50 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=421 Simples e rápido, minhas aplicações favoritas para iOS:
• 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!

]]> http://blog.lucashungaro.com/2011/09/03/iphoneipad-minhas-aplicacoes-favoritas/feed/ 0 http://blog.lucashungaro.com/2011/09/03/iphoneipad-minhas-aplicacoes-favoritas/ http://feedproxy.google.com/~r/LearningOnRails/~3/PeKrYuAwOGY/ http://blog.lucashungaro.com/2011/07/23/gems-locais-irb-e-bundler/#comments Sat, 23 Jul 2011 18:40:56 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=419 Gosto de algumas gems como o wirble, que adicionam algumas funcionalidades ao irb (e, por consequência, ao console do Rails). O problema é que, em projetos que utilizam o Bundler, fica complicado adicionar esse tipo de gem ao Gemfile, pois elas não são realmente dependências do projeto e nem todos gostariam de utilizá-las.

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á.

]]> http://blog.lucashungaro.com/2011/07/23/gems-locais-irb-e-bundler/feed/ 0 http://blog.lucashungaro.com/2011/07/23/gems-locais-irb-e-bundler/ http://feedproxy.google.com/~r/LearningOnRails/~3/N8i0FghOiVo/ http://blog.lucashungaro.com/2011/05/18/solid-ruby-liskov-substitution-principle-e-interface-segregation-principle/#comments Wed, 18 May 2011 22:38:49 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=416 Para fechar os cinco princípios do SOLID, vamos falar sobre os dois princípios restantes: Liskov Substitution Principle (LSP) e Interface Segregation Principle (ISP).

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
]]> http://blog.lucashungaro.com/2011/05/18/solid-ruby-liskov-substitution-principle-e-interface-segregation-principle/feed/ 1 http://blog.lucashungaro.com/2011/05/18/solid-ruby-liskov-substitution-principle-e-interface-segregation-principle/ http://feedproxy.google.com/~r/LearningOnRails/~3/4xLCVJFtEtk/ http://blog.lucashungaro.com/2011/05/11/solid-ruby-open-closed-principle/#comments Wed, 11 May 2011 17:43:22 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=413 Muitos dos princípios da programação orientada a objetos foram criados com linguagens estáticas em mente. Esse é o caso do Open-Closed Principle, enunciado da seguinte maneira:

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

]]> http://blog.lucashungaro.com/2011/05/11/solid-ruby-open-closed-principle/feed/ 1 http://blog.lucashungaro.com/2011/05/11/solid-ruby-open-closed-principle/ http://feedproxy.google.com/~r/LearningOnRails/~3/3m-1IF6LYPU/ http://blog.lucashungaro.com/2011/05/09/solid-ruby-dependency-inversion-principle/#comments Tue, 10 May 2011 02:57:16 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=410 Continuando os artigos sobre SOLID, vamos falar um pouco sobre o Dependency Inversion Principle. Em resumo, esse princípio diz que os componentes devem depender de abstrações ao invés de implementações.

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

]]> http://blog.lucashungaro.com/2011/05/09/solid-ruby-dependency-inversion-principle/feed/ 5 http://blog.lucashungaro.com/2011/05/09/solid-ruby-dependency-inversion-principle/ http://feedproxy.google.com/~r/LearningOnRails/~3/_AoBYQgg70w/ http://blog.lucashungaro.com/2011/05/04/solid-ruby-single-responsibility-principle/#comments Wed, 04 May 2011 05:34:38 +0000 Lucas Húngaro http://blog.lucashungaro.com/?p=409 Utilizamos BDD e técnicas do programação orientada a objetos não apenas para obter código mais limpo e bonito. Na verdade, essas são consequências do principal objetivo: criar código que tenha baixo custo de manutenção, isto é, não demande muito tempo e pessoas para correções e melhorias.

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
]]> http://blog.lucashungaro.com/2011/05/04/solid-ruby-single-responsibility-principle/feed/ 3 http://blog.lucashungaro.com/2011/05/04/solid-ruby-single-responsibility-principle/