This weekend during Rails Bugmash I stumbled across some nice posts about Rails 3 generators which motivated me to share them and add some comments!

First, David Trasbo wrote a nice guide about how to make your first Rails 3 generator, it covers up all the basic steps including setting it up in a gem. He also puts the deserved attention into Thor::Actions, which contains most helpers you need in a generator, like copy_file, template, create_file, empty_directory and so on.

On another post, Ben Scofield talks about apply method, which is also in Thor::Actions, and how to use it to dry your application templates.

Wait… so Thor::Actions is used both in generators and in Rails application templates? Exactly, Rails’ new generators unifies both application templates and generators API into one. While Thor::Actions holds basic methods, all Rails specific methods like environment, rakefile, generator are in Rails::Generators::Actions. If you already wrote an application template, you will feel more at home when writing a Rails 3 generator.

Paul Barry talks how easy it’s to customize your scaffold to use Rspec, Haml and Factory Girl instead of Test::Unit, Erb and Fixtures. This all works because scaffold is just a meta generator which provides hooks for template engine, test framework, ORM and so forth. A good way to see the hooks system working is by running script/generate scaffold --help before and after Paul changes, so you can see exactly how generators options update depending on the configuration values you set. While I wrote Rspec generators used in the example, he implemented himself Haml and Factory Girl generators and they can all be used as example if you plan to build your own.

Finally, Zigzag Chen wrote about templates customization and how you can change your scaffold controller to use json instead of the xml format. New generators have source paths, so you can customize them simply by copying files to RAILS_ROOT/lib/templates.

Rails Bugmash was excellent to gather feedback and we also got some tickets on Lighthouse, mainly about how generators help can be improved for people starting with Rails. Many thanks to Rails Bridge and besides the posts linked above, there is a generator guide, which may help you get started and maybe write your own post as well.

Tags: gems, generators, plugins, rails, ruby, thor
Posted in English | 8 Comments »

2009 se foi. Foram 10 meses muito agitados para nós. Aprendizado intenso, momentos de cansaço físico, desafios constantes e dúvidas sobre o futuro são fatores que estão presentes no nosso dia-a-dia.

Antes de iniciar as operações da Plataforma Tecnologia (fev/09), nos questionávamos duas perguntas que davam frio na barriga:

Como fazer uma empresa de serviços dar certo?!
Como sair da inércia e conquistar os primeiros clientes?!

Não sabíamos as respostas. Mas estávamos lá.
Cada um com suas habilidades e todos com um sentimento que se equilibrava entre arrogância e inocência. Sem motivos muito claros, nós simplesmente acreditávamos que poderia dar certo.  Então, por que não tentar?

Aqui estamos: tentando.

É difícil dizer se a Plataforma Tecnologia será bem sucedida ou não. Só o futuro dirá.

O que podemos dizer é que avançamos muito mais do que imaginávamos e acreditamos estar na direção certa.  Sabemos onde queremos chegar, mas há inúmeros caminhos para escolher. Uns melhores, outros piores.

Fato é que durante 2009 descobrimos algumas coisas que consideramos valiosas e queremos compartilhar nossa opinião.  Seguem abaixo.

• Contrate pessoas cujo trabalho você confia (e vice-versa): se você precisa micro-gerenciar sua equipe, então algo está errado. Micro-gerenciar times de desenvolvimento de software é uma tentativa (ruim) de assegurar a qualidade durante o processo produtivo. É preciso entender que o processo em si não é tão importante. O importante é o resultado final. Dê autonomia a sua equipe. Parta do pressuposto que sua equipe é capaz de atingir os objetivos até que seja provado o contrário (e se o “contrário” ocorrer, há diversas ações que podem ser tomadas, mas isso rende assunto para um outro post inteiro).
• A maioria dos clientes descrevem soluções ao invés de descrever as reais necessidades: é natural que isso ocorra. E ao invés de culpá-los por não saberem descrever corretamente as necessidades, ajude-os a esclarecer qual o problema a ser resolvido. Em seguida, construa com ele uma solução (software).
  Não se esqueça que é o seu cliente que tem o conhecimento sobre o segmento/negócio e uma boa solução será resultado de um trabalho conjunto. Se um cliente não se dispuser a trabalhar em conjunto para desenhar uma solução, então caia fora. Este projeto terá grandes chances de ter problemas.
• 6 meses é muito tempo para empresas recém-nascidas e pequenas: É importante saber onde se quer chegar, mas nesta fase da empresa, não faz muito sentido realizar planejamentos com horizontes longos. Muita coisa muda e muito rápido.
  Descobrimos que vale a pena fazer planejamentos com maior freqüência e com horizontes mais curtos. É como se a cada 6 meses a empresa estivesse realizando um “release”. Faça “retrospectivas”, “release plannings”, “sprint plannings” relativos à empresa e priorize a execução do que trará mais valor durante os próximos 6 meses. A grande vantagem de uma empresa de pequeno porte é sua capacidade de responder à mudanças (agilidade). Aproveite-a!
• Nunca haverá momento ideal para implementar algo: já nos pegamos dizendo “assim que der uma sossegada, a gente começa a re-estruturar bla-bla-bla”. A verdade é que este momento de sossego dificilmente chegará, ainda mais se a empresa estiver em crescimento. Se há necessidade em implementar ou mudar algo na empresa, faça-o o quanto antes (ou de acordo com a prioridade). Esperar só vai piorar os sintomas que este problema estiver causando. Quanto mais você esperar, pior será.
• Saiba claramente qual o seu DNA: isso pode soar um pouco filosófico, e de fato é. Mas é algo que se mostrou muito importante para nós. Todo o time deve saber e compartilhar dos valores que moldam as decisões de negócio e refletem na maneira de operar o dia-a-dia da empresa. Pode ocorrer momentos em que fechar um novo contrato significará deixar o DNA de lado e isso será um pouco doloroso.
  Mas da nossa experiência, posso afirmar que valeu a pena não se desviar do DNA. Quando olhamos para trás, fica muito claro que tomamos boas decisões. Warren Buffet já dizia… “In the business world, the rear view mirror is always clearer than the windshield“.
  É a mais pura verdade!

Espero que estes tópicos possam ajudar startups e outras empresas iniciantes.

Gostaria de pedir que ajudem a enriquecer o post e comentem. Compartilhem suas experiências!

Tags: empreendedorismo, negócios, the plataforma way
Posted in Português | 5 Comments »

A couple days ago DHH twitted that they were getting Basecamp running on Ruby on Rails 3.0.

This means Basecamp migrated from the first Rails release up to the edge one. So how come people say so frequently how hard is to update their applications from Rails 2.1 to Rails 2.2? And the answer is simple: plugins.

Every time you are adding a plugin to your application, you are inserting some hundreds or even thousands of lines of code in your application, without knowing what it does exactly. And sometimes this becomes technical debt, mostly noticeable when you have to update to a new Rails version. And why is that? Because a lot of plugins are monkey patching Rails, so whenever Rails changes its internal API between releases, the plugin breaks.

However, they are two simple actions you could do to improve your application maintainability, your ruby fu and also give a little back to the community.

The first one is easy: check the source code of the plugin you are installing. Does it needs to monkey patch Rails code? Or even worse, Ruby classes? If so, how much? If too much, turn it down. Search for simpler solutions or even start one from scratch with just what you need, it will take more time, but you will learn a lot through the process.

Another very compelling reason is that reading other people’s code is one of the best ways to learn. You will learn new things and probably see a few things which could be done better. And when it happens, write a patch!

Besides, whenever something is going wrong in your application, you will know better where to start searching and you will eventually help plugins authors to track bugs down. And, in the worst scenario, if you have to update the plugin after a Rails release on your own because the plugin creator is no longer interested, you will be more capable to do so.

Some people often choose plugin A because of features X, Y and Z. But whenever they have to add feature W, they are stuck, because the plugin code is a complete spaghetti. And all this time, they could have chosen plugin B, which just has feature X, but adding Y, Z and W would be quite easy. Reading the plugin’s source code is one way to ensure you are prioritizing code quality instead of features count.

And the second step, guess what, is easy too: run the plugin test suite. Really, it will take just a couple minutes. You definitely don’t want to use a plugin where the test suite fails (or which does not have a test suite at all). Imagine that for some reason you need to add features to a plugin, how you will ensure you did not break other thing while doing so? Or even worse, imagine you have to update the plugin for a new Rails release. How can you ensure the plugin works on 3.0 if you cannot even ensure it works on 2.3?!

Some already noted that I have patches applied in different plugins around GitHub. And this is the very reason: I check their code, send simple suggestions whenever it’s possible and most important of all, I choose well which plugins to use. So whenever I need to write a new feature because the application I’m working on needs it, I know it will be easy, since the plugin code is quite well written and test suite is green.

It’s really two small efforts, which gives everyone, including you, a lot back.

Tags: plugins, rails, source code
Posted in English | 1 Comment »