Até pouco tempo atrás o Textmate era uma unanimidade para programadores Rails. Recentemente porém tenho visto alguns programadores migrando para outros editores de texto, como o Vim e o Emacs.

Embora eu já tivesse uma certa experiência com esses últimos, eu nunca havia tentando desenvolver código de verdade com eles. Depois de fazer uma experiência trabalhando com cada um deles por uma semana, vejo que ambos são excelentes editores de textos e obviamente boas alternativas para o desenvolvimento de software em diversas linguagens.

Porém, quais critérios devem ser usados ao comparar essas ferramentas e decidir qual delas é a melhor? Quais são as características mais importantes em um editor de textos que poderiam determinar a minha escolha?

Acredito que o mais importante nesse caso é ser proficiente. Chega a ser irritante ver alguém pressionar dezenas de vezes a seta para a esquerda afim de colocar o cursor no começo de uma linha ou recorrer ao mouse para chegar ao topo do documento no Textmate, sendo que existem atalhos para se fazer isso com apenas uma combinação de teclas.

Escolher um editor de textos para programar não deve ser algo trivial. A curva de aprendizado é bastante íngreme até que você não precise mais pensar em quais combinações de teclas devem ser usadas para realizar uma operação. Tudo deve acontecer por reflexo.

É importante que a ferramenta seja flexível, permitindo que o programador possa configura-la de acordo com as suas preferencias. Como o processo de aprendizado é lento, é importante que você possa continuar usando o editor de textos mesmo ao trocar de uma linguagem para outra. Bons editores são capazes de aprender a trabalhar com qualquer nova linguagem de programação que apareça.

Alguns recursos como syntax highlighting e auto-indentation são indispensáveis para o desenvolvimento de software.

A conclusão é que todos esses editores de textos mencionados no inicio do artigo passam com louvor na avaliação dos requisitos mínimos. Mas isso ainda não responde a pergunta: Qual é o melhor editor de textos para se trabalhar com Rails?

Eu não sou um usuário comum do Textmate. Além de me sentir totalmente à vontade com essa ferramenta eu estou constantemente implementando meus próprios Bundles e refinando os recursos que mais uso para o meu estilo de trabalho.

Como particularmente sou mais produtivo no Textmate, então especialmente para mim essa é a melhor ferramenta para programar em qualquer linguagem.

A idéia aqui não é defender o meu editor preferido. De fato, não importa se você escolheu o Textmate, o Emacs ou o Vim. Desde que o seu editor seja uma extensão das suas mãos.

Eu costumo trabalhar muito com o terminal, assim é natural usar o comando mate . para carregar um projeto Rails no meu Textmate.

Em projetos grandes é normal utilizar o sistema de buscas da ferramenta para localizar um arquivo ou encontrar alguma declaração, por exemplo. Embora existam plugin como o excelente AckMate que melhorem perceptivelmente a performance dessas buscas, elas ainda costumam ser lentas. Um dos vilões nessa história são os arquivos temporários e logs que são inclusos no processo de busca, e normalmente esses arquivos costumam ser bem grandes. Além de deixarem a busca mais lenta, eles também acabam poluindo o resultado já que na maioria das vezes não estamos procurando por algo nos logs.

Inicialmente eu costumava remover os diretórios tmp e log depois de carregar o projeto no Textmate. Porém realizar essa operação todas as vezes não era nada prático.

A solução mais simples e definitiva é alterar as configurações do Textmate para que ele ignore esses diretórios. Para isso abra as preferencias do editor de textos (⌘,) e na opção Advanced vá até a aba Folder References.

Os dois campos acima são expressões regulares que determinam quais arquivos e diretórios devem ser carregados em um projeto. Isso é útil para impedir que o diretório do CVS apareça no Textmate, por exemplo.

Para adicionar os diretórios log e tmp nessa lista negra precisamos alterar o campo Folder Pattern. Adicione |tmp|log exatamente antes do |CVS. Pronto, de agora em diante toda vez que um projeto for carregado à partir de um diretório, essas pastas também serão ignoradas.

Além disso você também pode adicionar outros diretórios ou arquivos, como por exemplo a pasta vendor se você não pretende alterar ou visualizar o código de plugins e gems.

Acredite, nem sempre houve interfaces gráficas. Meu primeiro contato com um computador foi feito através de uma tela preta com letras verdes. Não me lembro exatamente, mas provavelmente era alguma versão do MS-DOS ou do PC-DOS.

Qualquer criança com acesso a um computador nessa época, rapidamente aprendia a manipular arquivos e diretórios através de comandos básicos que o sistema operacional oferecia. Era necessário aprender esses comandos se quisesse se divertir com um novo jogo, por exemplo. Além disso, muitos jogos mais sofisticados exigiam que o usuário entendesse, mesmo que superficialmente, como o sistema operacional manipulava a memória. Termos como memória estendida, superior, convencional e expandida eram comuns na roda de amigos.

Pode parecer nostalgia, mas mesmo depois de mais de uma década, todo esse conhecimento básico continua me sendo prático até os dias de hoje. Afinal, a maior parte do meu trabalho é resolvido através daquela mesma janela do terminal.

É claro que muitos programadores conseguem realizar todo o seu trabalho através de uma um ambiente integrado de desenvolvimento (IDE). Mas será que realmente podemos fazer tudo igualmente bem apontando o ponteiro do mouse e clicando?

Eu sempre acreditei que não. Interfaces gráficas são ótimas e realmente convenientes para muitas situações, mas o seu poder também é a sua limitação. Quando nos tornamos dependentes de uma interface gráfica (GUI) para realizar nosso trabalho, estamos presos à imaginação dos desenvolvedores que a criaram.

No terminal, nossa liberdade é quase infinita. Não vamos encontrar nada muito sofisticado lá, a maioria dos comandos e utilitários realizam apenas uma única tarefa. Mas realizam essa tarefa muito bem. Não existem distinções entre documentos, diretórios, discos rígido, drives de CD e DVD, teclados, impressoras e monitores por lá. Todos são simplesmente arquivos e são manipulados como tais, o que facilita muito as coisas.

Mas a maior vantagem do terminal é que podemos facilmente combinar sequencias desses comandos em scripts, o que nos dá a liberdade de automatizar praticamente qualquer tarefa que podermos imaginar, algo essencialmente importante para um programador pragmático que se preze.

Tire o máximo de proveito da sua IDE, mas não ignore o terminal. Aprender a usar bem o shell deve ser uma prioridade para qualquer programador iniciante.

Trabalhando em um novo plugin, surgiu a necessidade de recuperar uma lista com todas as rotas nomeadas de um projeto Rails.

Depois de procurar um pouco, encontrei isso:

1

ActionController::Routing::Routes.named_routes.routes

Trabalhando em um novo plugin, senti a necessidade de usar partials em uma view renderizada através do Builder (index.xml.builder, por exemplo). Porém não é possível utilizar partials em views desse tipo da mesma forma como fazemos no ERb. Nesses casos a linha abaixo não tem nenhum efeito:

1

render :partial => "preferences"

Isso não funciona porque a partial receberá um novo objeto xml Builder quando estiver sendo renderizada. Há várias formas de solucionar isso, mas a mais simples é assim:

1

xml << render(:partial => "preferences")

O objetivo desse post é deixar isso registrado para um eventual esquecimento meu.

Se você está preocupado com a performance do seu programa, saiba que métodos macarrônicos são mais velozes. Ao escrever todo o código dentro de um único método você estará evitando todos os custos envolvidos na chamada de outros métodos, reduzindo o tempo de execução do seu código.

Embora o argumento acima não seja falso, é triste reconhecer que muitos programadores ainda possuem esse tipo de pensamento. Talvez não de uma forma tão radical, mas são poucos os profissionais que entendem que programar é muito mais do que escrever instruções para um computador, mas que o código que escrevemos também será lido por outras pessoas.

O tamanho do método é proporcional a dificuldade de manutenção e entendimento. Quando damos prioridade a escrever métodos pequenos e com nomes descritivos aumentamos a produtividade do time (incluindo o autor do código).

Métodos pequenos, com poucas linhas de código, facilitam a manutenção e a inserção de novas funcionalidades. Use as características da linguagem a seu favor. Não é feio criar um método com um nome longo e descritivo em Ruby. Respeite a pontuação. Acrescente o sinal de interrogação no final quando o método retornar um booleano.

Não estamos apenas escrevendo código, estamos nos comunicando.

P.S.: Sim, eu acabei de ver uma coisa que me deixou irritado.

Definir quanto tempo será necessário para finalizar uma tarefa ou o desenvolvimento de um software não é (ou pelo menos não deveria ser) algo trivial. Estimar prazos faz parte do nosso dia-a-dia como programadores.

O que muita gente não se dá conta é que a precisão com que um programador prevê a entrega de tarefas e projetos é um poderoso indicador do quão bom ele é.

Para informar de forma precisa o tempo necessário para a realização de algo em desenvolvimento de software é necessário que o programador possua uma certa experiência no assunto, tenha um bom domínio do negócio, seja rápido e produtivo.

Embora muitos de nós não apreciem essa difícil tarefa, estimar prazos é parte do nosso trabalho. Fazer isso bem pode ser a diferença entre um programador profissional e um amador.

Em um dia normal, estamos estimando prazos o tempo todo. Ao colocar a comida no micro-ondas você deve informar quantos minutos serão necessários para esquenta-la. Se você tem um horário fixo para acordar, deve analisar quantas horas de sono serão suficientes e então decidir quando deve ir para a cama.

O segredo não está no tempo, mas em quão precisa deve ser a sua estimativa. Se seu chefe pergunta que horas você entregará o relatório amanhã, ele quer ter uma ideia se será antes ou depois do almoço. Se ele lhe pergunta quanto tempo será necessário para resolver um bug critico e colocar o sistema de volta em produção ele precisa de uma precisão maior.

A escala de tempo é muito importante ao se estimar prazos. Por exemplo, você pode dizer “O projeto será entregue em 25 dias” ou pode dizer “O projeto será entregue em cerca de 5 semanas”. Embora ambas as frases indiquem o mesmo tempo, o efeito sob cada uma delas pode ser diferente. Ao dar a primeira resposta, seu cliente provavelmente anotará na agenda dele o dia exato em que você entregará o projeto. Por outro lado, a segunda resposta fará com que ele lhe procure a qualquer momento daqui a 4 ou 6 semanas.

O livro The Pragmatic Programmer dá uma importante dica que nos ajuda a escolher a escala de tempo apropriada ao estimar prazos. Veja a tabela:

1-15 dias    -> dias
3-8 semanas  -> semanas
8-30 semanas -> meses
30 + semanas -> pense bem antes de dar uma estimativa

Qual a vantagem disso? O fato é que quanto maior o tempo, mais difícil é a previsão, exigindo que você seja cada vez mais impreciso. Por exemplo, se sua estimativa é que serão necessários 125 dias para terminar um trabalho, é muito mais seguro dizer que precisará de “cerca de 6 meses” para finaliza-lo.

Todas as estimativas que fazemos são baseadas em nossas experiências passadas. Mas, o que fazer quando é necessário estimar algo que você nunca fez ou que não conhece? A resposta é simples: “não estime”. É melhor pedir para que alguém que já tenha feito algo semelhante lhe dê uma ideia do tempo necessário.

Além de considerar o grau de precisão, também é importante entender qual é o problema antes de começar a chutar um tempo. Quase sempre nossas estimativas dependem de outros fatores para darem certo: “Supondo que não haja trânsito dá para chegar aí em 20 minutos”.

Se possível é muito útil testar alguns aspectos do projeto antes de dizer quanto tempo será necessário para cumpri-lo. Se o sistema precisa ser carregado dentro do Facebook, seria muito bom poder gastar um tempo criando alguma coisa bem simples para esta plataforma afim de analisar o grau de complexidade, isto sem dúvida aumentará a precisão da estimativa.

É muito importante levar em consideração que a equipe, sua produtividade e o ambiente afetam diretamente sua estimativa.

Analisando todos estes fatores, a conclusão é que há apenas uma única resposta correta a se dar quando lhe é pedido para estimar um prazo: “Me dê algum tempo para pensar”. Você sempre terá resultados melhores se retardar a resposta e pensar um pouco mais.

Eu amo programadores incompetentes. Graças a eles os profissionais de TI não podem reclamar de falta de emprego.

Nos últimos anos o mercado nacional de TI registrou um aumento de 40% no número de novas vagas de trabalho. Há estimativas que revelam que a necessidade de programadores no Brasil ultrapassa 40 mil profissionais por ano.

Afim de resolver esse problema, as empresas tem contratado cada vez mais programadores ruins. Porém nós não temos um problema com a quantidade, mais sim com a qualidade. Apenas um único programador incompetente pode facilmente criar duas novas vagas de emprego por ano.

Contratar mais programadores ruins só aumentará a necessidade por mais deles. Se tivéssemos mais programadores bons (que são facilmente identificados), seria necessário contratar menos e não mais.

Assim, quanto mais programadores ruins no mercado, mais empregos. Vida longa aos programadores incompetentes!

Eu tenho uma lista de programadores que merecem o meu respeito. Provavelmente você também deve admirar o trabalho de alguns colegas de profissão. Estranhamente, eu sou obrigado a confessar que vi muito pouco do código de cada um deles.

A maior parte desses programadores ganharam o meu respeito através dos softwares ou livros que escreveram. E não através do seu código.

Um exemplo é Yukihiro Matsumoto. Ele foi o criador da linguagem de programação que utilizo diariamente para realizar o meu trabalho e obviamente está na minha lista de heróis, porém pouquíssimas vezes eu olhei para o código fonte do Ruby, e quando o fiz não teria como identificar se o que estava vendo foi originalmente escrito por Matz ou por algum outro colaborador.

Minha lista está recheada de pessoas que escreveram uma linguagem de programação interessante, um framework útil, uma ferramenta que facilita minha vida ou um bom livro sobre programação. Mas são poucos os que passei a admirar depois de ver algum código que escreveram. Isso me faz pensar…

Na realidade o código que escrevemos tem muito pouco impacto sobre as pessoas. O que realmente interessa é o que fazemos com o código. O que importa é o produto final.

O problema é que a maior parte dos programadores se preocupa demais com o código. Passam horas e mais horas tentando criar o algoritmo perfeito. Porém se esquecem que o melhor código do mundo é inútil se ninguém utilizar o software que o contém.

De forma alguma estou dizendo que devemos jogar tudo para o alto e parar de se importar com a qualidade do código que escrevemos. Porém, tão importante quanto realizar um bom trabalho é fazer com que outras pessoas tomem conhecimento do que você está fazendo. A minha proposta é que aqueles que já são bons programadores hoje, invistam em aperfeiçoar suas habilidades como escritores e palestrantes. Que participem mais ativamente nas comunidades de software e melhorem suas habilidades sociais.

São essas habilidades que vão diferencia-lo dos demais. Não escreva apenas código. Estude, escreva e fale mais sobre código.

Hoje completa exatamente três anos desde que comecei a escrever neste blog. São mais de 780 artigos publicados, 3.800 comentários e 19.000 spams recebidos e interceptados pelo Akismet.

Neste intervalo tive a oportunidade de publicar dois livros sobre as principais novidades das versões 2.1 e 2.2 do Ruby on Rails. O mais interessante é que o conteúdo de ambos os livros foram extrações de artigos escritos para este blog.

Outra fase muito legal foi o ano do Rails Podcast Brasil. Onde Fábio Akita e eu gravamos uma série semanal de podcasts com as novidades da semana no mundo do Ruby e Rails.

Para comemorar esta data especial, eu montei uma lista com os 10 artigos mais lidos nestes três anos.

Os 10 mais lidos

• New Free Book: “Ruby on Rails 2.1 – What’s new”
• Shoulda for RSpec is Remarkable!
• O primeiro livro sobre Rails 2.1 é brasileiro!
• Como Ruby on Rails pode o tornar um programador pior
• Ruby on Rails 2.1 What’s New – Second Edition
• Como motivar um programador
• Adicione algo de valor ao universo
• Livro Grátis: Ruby on Rails 2.2 – O que há de novo?
• Os oito níveis do programador
• Free Book: Ruby on Rails 2.1 – What’s New (7 translations)

Além desses artigos eu gostaria de listar outros que considero importantes na história do blog:

• Um presente para a comunidade de desenvolvedores brasileiros de Ruby e Rails
• Programar é difícil
• Os screencasts perdidos do Nome do Jogo
• Isto é um bug no Javascript?
• O (comovente) guia de Ruby do Why
• Autotest Notification – Doom Edition
• Rails Podcast Brasil #1

Eu agradeço a todos os leitores, principalmente aqueles que comentam e compartilham os artigos no Twitter, você são o combustível para que eu continue pesquisando e escrevendo.