A “cultura” da certificação é uma das “pragas” que infectam o mundo do desenvolvimento de software e da TI em geral.

Instituições e pessoas sem qualquer experiência real criam processos e avaliam empresas e profissionais com base em critérios duvidosos e, muitas vezes, obscuros.

Hoje existe uma série de metodologias e processos desenvolvidos por acadêmicos, que passam a maior parte do tempo estudando a teoria e criando software científico experimental. Essas pessoas podem ter boa vontade, mas não estão acostumadas com o dia-a-dia do desenvolvimento para clientes “reais”: empresas que esperam que o software seja a solução milagrosa para todos os seus problemas e investem muito nisso.

Baseadas nessa experiência acadêmica, essas pessoas criam processos que não condizem com a realidade do mercado comercial e emitem certificações de acordo com critérios igualmente irreais. Resumindo: certificam que você está usando um processo que não serve para o seu negócio (pode até servir para criar software que controla foguetes, mas não para o que a grande maioria das software houses cria).

Além das certificações para empresas, há também a delicada questão das certificações para os desenvolvedores (MCP, SCJP, Scrum Master etc). Fico me perguntando o que é que essas certificações garantem? Que alguém decorou centenas de linhas de código e esqueceu dias depois?

Bons desenvolvedores não precisam de certificação. Eles são bons em qualquer plataforma e ponto. Isso não significa que não existam bons desenvolvedores certificados, mas que uma grande massa de desenvolvedores medíocres utiliza das certificações para se “pendurar” em algum emprego que paga bem e ficar lá enganando. Em geral, essas certificações avaliam o “domínio” de técnicas em determinada linguagem ou plataforma, sequer chegando perto de avaliar se uma pessoa sabe ou não sabe desenvolver bom software.

Certificações também são utilizadas por selecionadores de mão de obra que são leigos em tecnologia. Como não sabem como avaliar um desenvolvedor de software, ordenam os currículos por número de certificações e, bingo, acreditam ter selecionado os melhores.

Assim como o Vinícius Teles em seus podcasts, acredito que nesses casos o que acontece é bem semelhante a uma prova escolar: os alunos decoram toda a matéria, fazem a prova e, pouco tempo depois, já não se lembram de mais nada. O conteúdo realmente absorvido é muito pouco.

Jamis Buck escreveu um excelente post sobre o assunto. Aqui vão alguns destaques:

Como regra geral, acredito que certificações são uma piada. Pura e simplesmente. (…) A simples idéia de que um teste pode, de qualquer maneira, implicar em competência é de se gargalhar.

Certificação pode produzir programadores competentes? Eu digo “não”. Se você é certificado e competente, então você era competente antes de ser certificado.

Certificações são usadas principalmente por tomadores de decisão ignorantes como um discriminador. Logo, se alguém quer ser notado por um tomador de decisão, precisa passar no teste. É a certificação pela certificação. Isto encoraja qualquer coisa, menos o aprendizado. Encoraja mediocridade em larga escala, causada por pessoas memorizando exatamente o que o teste exige e nada mais. Encoraja aprender fora de contexto. Encoraja a cópia no lugar de pensamento criativo.

Pior ainda é conseguir convencer gerentes disso. Gerentes são burocratas por natureza, possuem uma paixão inexplicável por papelada e documentação (que nem eles mesmo utilizam), adoram andar com livros grossos pregando a última “revolução” no mundo dos processos, caçando certificações como Cobit e PMI e, principalmente, não enxergando um palmo à frente do nariz. Não é por acaso que, hoje, a inovação vêm das startups e pequenos grupos de desenvolvedores pragmáticos que focam no que realmente importa: software simples, elegante e que resolve problemas.

Voltando ao artigo, a leitura é altamente recomendada. Com um exemplo simples e direto, Phillip constrói seu argumento com rara habilidade. Habilidade que só a experiência com desenvolvimento real é capaz de trazer.

O Rails utiliza DSLs em peso, graças à natureza dinâmica do Ruby e sua flexibilidade.

Como publicado pelo Fábio Akita, a ThoughtWorks lançou, na semana passada, o primeiro episódio de seu podcast IT Matters, falando justamente sobre DSLs. O podcast é muito interessante e conta com ninguém menos que o próprio Martin Fowler e mais alguns membros de sua excelente equipe. Vale muito a pena conferir.

Veja mais informações no site oficial.

Link: http://www.netbeans.org/community/releases/60/index.html

Em praticamente dois meses de Rails, testei diversos editores e algumas IDEs e, finalmente, fiz a minha escolha: NetBeans 6.0. Ainda em desenvolvimento, é a IDE com a melhor integração à Rails que utilizei (testei, também, Eclipse, RadRails, jEdit e Komodo IDE).

Essa IDE incorpora ao desenvolvimento Rails muitas coisas que desenvolvedores Java e .NET costumam utilizar: debug completo (breakpoints, watches), code completion, syntax highlighting, inline documentation, integração com SVN, boa extensibilidade com plugins, code folding etc.

Além disso, possui integração muito boa com tasks do Rake e gerenciamento de RubyGems, entre outras coisas interessantes, como os famosos “bundles” do TextMate.

Para uma boa visão geral dos recursos disponíveis no NetBeans 6.0, incluindo screenshots, visite http://www.lifeonrails.org/2007/8/30/netbeans-the-best-ruby-on-rails-ide

Conheci o NetBeans quando estava na versão 4.0, mas preferia o Eclipse para desenvolver em Java. Porém, a versão 6 do NetBeans está muito (muito, mesmo) melhor do que as anteriores.

No entanto, há pessoas que preferem utilizar um editor de texto com alguns recursos a mais, argumentando que “economiza memória” (o que é algo estranho: seu computador tem 1, 2 ou 3 gigabytes de memória e você não quer utilizar uma IDE porque ela ocupa 100 megabytes… alguns chamam isso de desperdício). O editor mais conhecido no mundo Rails é o TextMate, disponível apenas para os felizes proprietários de um Mac.

Para os pobres mortais, há algumas boas opções. Para Windows: E-TextEditor (um “clone” do TextMate para Windows) e Intype. Para Linux, gosto muito do Scribes. Uma boa opção para ambas as plataformas é o SciTE, que eu utilizo para edições rápidas e testes, quando não preciso de uma IDE completa rodando. Há ainda várias outras opções como NotePad++, UltraEdit, Vim, Emacs…

Fica claro que isso é uma questão de gosto e adaptação. Minha recomendação para quem está buscando uma IDE para Rails é olhar atentamente para o novo NetBeans e avaliar seu uso por um tempo. Estão fazendo um ótimo trabalho visando usabilidade em primeiro lugar e, como sabemos, isso costuma dar bons resultados.