A pergunta acima, apesar de ser um pouco provacativa, introduz uma discussão interessante. A maioria dos desenvolvedores, ou aspirantes a desenvolvedores, afirmam categoricamente que dominam o HTML, mas será que isto é mesmo verdade?

Pois bem, é óbvio que alguns poucos realmente o dominam, eu, pelo menos, conheço dois, mas a verdade é que a grande maioria conhece superficialmente esta tão subestimada linguagem. Em geral, ou conhecem um subconjunto relativamente pequeno do HTML, ou então conhecem apenas a sintaxe da linguagem, sem saber exatamente como usá-la, o que ao meu ver é ainda pior do que o primeiro caso.

Contudo, como a maioria dos browsers é muito pouco rígido quanto a corretude do HTML, muitos erros grotescos acabam sendo ignorados, e o browser indulgentemente apresenta a página da melhor forma possível. Como consequência, os desenvolvedores, principalmente os iniciantes, acabam construindo a noção de que conhecem bem o HTML e que ele se trata de uma linguagem fácil, chegando até mesmo a estranhar o fato de alguém estudar o assunto mais profundamente.

Eu afirmo isso sem me excluir, pois, apesar de saber da importância deste tópico, posso, na mais autoindulgente das hipóteses, me considerar apenas mediano no HTML. Digo isso pois conheço uma quantidade razoável dos seus elementos, além de saber o básico sobre o seu uso, como, por exemplo, que ele só deve ser usado para estruturar o conteúdo, e não para definir a apresentação, que é tarefa do CSS.

E por falar em CSS, o que eu disse acima também se aplica a ele e ao XHTML, embora a maioria não se considera tão proficiente nestas duas tecnologias. Isso é claro considerando os que sabem da existência do XHTML.

Entretanto, o objetivo aqui não é de maneira alguma criticar os desenvolvedores que não conhecem profundamente o HTML, até porque eu faço parte desta parcela, além de sequer ser um desenvolvedor ainda. O que eu pretendo aqui é despertar em alguns de vocês a consciência recém-adquirida por mim de que o HTML é mais do que algumas poucas tags jogadas de qualquer maneira em um arquivo .html. Ele merece sim atenção, além de um estudo um pouco mais extenso do que um breve tutorial.

Eu estou fazendo a minha parte, uma vez que estou lendo no momento o Use a Cabeça! HTML com CSS & XHTML. Aliás, este é um livro excelente, e a sua tradução não compromete a compreensão do texto, portanto eu o recomendo.

Sendo assim, vamos conhecer de verdade o HTML, XHTML e CSS. Isto é um bem que fazemos a nós mesmos, pois são estas tecnologias que formam a base da Web, e se quisermos atuar neste ambiente temos a obrigação de conhecê-las. Quem sabe assim nós contribuimos para uma Web menos caótica. Não custa sonhar.

Na última semana, durante uma aula de Engenharia de Software 2, foi levantada uma questão interessante: quem tem culpa quando um sistema dá errado?

Durante o debate, um dos alunos, provavelmente um desenvolvedor, defendeu a idéia de que a culpa é sempre do usuário, que, em sua infinita imaginação, sempre consegue utilizar o sistema da maneira errada.

Como exemplo, foi citado uma aplicação que possuia um formulário para busca contendo datas, sendo que, por algum motivo qualquer, não se poderiam fazer buscas sobre ocorrências anteriores a 1985, pois isto resultaria em um erro. Acontece que os usuários do tal sistema frequentemente se esqueciam deste detalhe, persistindo em realizar buscas informando datas inválidas. E por mais que os desenvolvedores os lembrassem desta limitação, o problema permanecia, levando a conclusão, por parte do aluno, de que o problema está no usuário.

Já o professor, sabiamente, afirmou que se o usuário erra, é porque o desenvolvedor permitiu que tal erro ocorresse. Por exemplo, no caso mencionado acima, o mais apropriado seria que fosse impossível entrar com uma data inválida, ou simplesmente verificar a entrada e não processá-la se for o caso, gerando assim uma mensagem para o usuário. Portanto, neste caso, se o usuário errou, é porque o desenvolvedor errou antes.

Mas, apesar de concordar com o professor neste exemplo, devemos considerar que é apenas uma situação isolada. No geral, embora seja uma das funções do desenvolvedor evitar erros do usuário no uso do sistema, é evidente que ele não é o único culpado quando as coisas dão errado.

Responsabilizar apenas uma das partes é sempre uma atitude extrema e preguiçosa. A responsabilidade pelo sucesso ou fracasso de qualquer sistema depende tanto de quem o desenvolve como de quem o utiliza. No entanto, o relacionamento entre os usuários de uma aplicação e os seus desenvolvedores é bastante complicado por “culpa” de ambas as partes.

Do lado dos desenvolvedores, a noção de que o usuário é sempre o culpado é bastante comum. A verdade é que é sempre mais fácil delegar a culpa a outra pessoa, e como nesta situação há basicamente apenas dois papeis envolvidos, só sobrou mesmo o usuário para culpar. Portanto, não espero ouvir de um desenvolvedor algo do tipo “O sistema saiu do ar devido a um erro que eu cometi”. As pessoas, em geral, são orgulhosas e não têm muita auto-crítica, e não seria diferente com quem desenvolve software.

Já da parte do usuário, por estar muitas vezes consciente desta posição dos desenvolvedores, eles acabam se sentindo acuados e constantemente vigiados, de forma a serem responsabilizados pele erro mais recente do sistema. Isto, somado ao fato de sempre haver a suspeita, nem sempre infundada, de que um novo sistema pode significar demissões, acaba fazendo com que ele veja o desenvolvedor como uma ameaça ao seu emprego, ou pelo menos à sua posição na empresa, o que obviamente prejudica bastante a relação entre eles.

A verdade é que existem sim usuários menos capazes, e é natural que eles utilizem o sistema de forma menos produtiva, no entanto, se este tipo de usuário causar de fato um erro no sistema, é porque este erro não foi evitado antes pelos desenvolvedores. Até porque, inaptidão não é uma característica presente unicamente nos usuários. Ou, em português claro, também existem desenvolvedores ruins.

O que nós temos que entender é que mesmo que não sejamos desenvolvedores ruins, qualquer aplicação que formos desenvolver em uma empresa irá falhar se não contarmos com a colaboração daqueles que a usarão. Ninguém entende melhor do que o usuário o que o sistema deve realmente fazer, incluindo algumas sutilezas que jamais seriam imaginadas por nós. E são justamente estas sutilezas que resultarão em erros no futuro, caso nós não soubermos como vencer a barreira invisível que existe entre nós e os usários. Afinal, seja lá o que estivermos desenvolvendo, muito provavelmente será utilizado para informatizar o trabalho que este usuário desenpenha na empresa, e ninguém melhor do que ele mesmo para nos dizer como funciona este trabalho.

No fim das contas, para fazermos bem o nosso trabalho precisamos da cooperação do usuário. Portanto, é necessário darmos o primeiro passo e mudarmos de atitude, para que assim o mesmo aconteça do outro lado, possibilitando a ambos um melhor desempenho nas tarefas que somos pagos para fazer.

Há poucos dias atrás foi criado no fórum do GUJ(Grupo de Usuários Java) um tópico sobre a necessidade de profissionais de TI cursarem uma faculdade.Foi uma discussão bastante interessante, onde muitas pessoas expressaram a sua opinião sobre o assunto, inclusive eu. E, depois de reler todos os posts do tópico e pensar um pouco mais a respeito, decidi ampliar a minha resposta a esta pergunta.

Como disse lá no GUJ, a necessidade de um curso superior para profissionais de TI depende basicamente do que a palavra necessidade se refere neste caso. Ou seja, necessário para o quê exatamente?

Se for em relação aos conhecimentos adquiridos durante a faculdade, fica difícil responder, pois isso varia muito de instituição para instituição. Algumas delas agregam bastante conteúdo aos alunos, e outras fingem que ensinam alguma coisa. De qualquer forma, em ambos os casos, o aluno pode adquirir todo este conteúdo por conta própria, dependendo obviamente do perfil da pessoa. Alguns tem capacidade de aprender através de livros, por exemplo, e assimilar todo o conteúdo visto na faculdade, ou até mais. Mas há também aqueles que precisam ter aulas para aprender, o que justifica cursar uma faculdade. De qualquer forma, nenhum dos dois é melhor que o outro, são apenas perfis de pessoas diferentes.

Já em relação ao mercado de trabalho, atualmente é muito difícil conseguir um emprego em TI sem curso superior, mas não é impossível. Eu mesmo conheço pelo menos uma pessoa que conseguiu um bom emprego na área sem ter concluído a faculdade. Na verdade, esta pessoa começou a graduação assim que conseguiu o emprego, por exigência da empresa. Portanto, a faculdade costuma facilitar as coisas, mas não ter cursado ou completado uma não impossibilita ninguém de ter uma carreira em TI, apenas dificulta as primeiras contratações.

Ainda sobre o mercado de TI, temos também que considerar o objetivo profissional de cada um, o que nos faz perceber uma exceção do que foi dito acima. Um desenvolvedor, por exemplo, pode fazer uma faculdade para facilitar a sua entrada em uma empresa, ou então para aprender parte do conteúdo que precisará(não se engane, faculdade alguma ensina todo o conteúdo necessário), no entanto, isto não se trata de uma exigência para este tipo de profisisonal. Contudo, há casos de carreiras que de fato exigem uma vivência acadêmica, como, por exemplo, um professor universitário, que dificilmente terá menos do que um mestrado.

Sendo assim, a resposta para esta pergunta é a mesma de outras tantas perguntas relacionadas a TI: depende. Depende do perfil da pessoa e dos seus objetivos profissionais. Mas o que realmente importa aqui é sabermos que nenhum pedaço de papel qualifica(ou desqualifica) uma pessoa. Um bom profissional, não só de TI, é construído através da experiência e da constante dedicação em se aprimorar na sua área.

A consultoria Synectics publicou o resultado de uma pesquisa cujo objetivo era obter uma lista com os 100 maiores gênios vivos. No 1º lugar desta lista está o inglês Tim Berners-Lee, o criador da World Wide Web, que divide esta colocação com o químico suiço Albert Hoffman, criador da droga LSD, que revolucionou os tratamentos psiquiátricos nos anos 40.

Além destes, a lista contém também o criador dos Simpsons, Matt Groening (4º) , Nelson Mandela (5º), o arquiteto brasileiro Oscar Niemeyer (9º), os fundadores do Google , Larry Page (20º) e Sergey Brin(20º), Steven Spielberg (26º), Dalai Lama (26º), Prince (33º), Osama Bin Laden (43º), Bill Gates (43º), a atriz Meryl Streep (49º), Paul McCartney (58º), Stephen King (58º), o co-fundador da Apple, Steve Wozniak (67º), a cantora Aretha Franklin (67º), David Bowie (67º), o inventor do celular, Martin Cooper (67º), o criador do Homem Aranha e dos X-Men, Stan Lee (72º), George Lucas (72º), a escritora J. K. Rowling (83º), o projetista do rifle AK-47, Mikhail T. Kalashnikov (83º) e Quentin Tarantino (100º).

Entre as ausências, a mais surpreendente, pelo menos pra mim, foi a do Steve Jobs, co-fundador e CEO da Apple, ainda mais porque o outro co-fundador, Steve Wozniak, foi incluído. Mas ao que parece, estar a frente de uma empresa que foi fundamental na definição da computação pessoal, tornar a Pixar um dos maiores estúdios de animação do mundo, e recuperar a Apple anos depois de ter sido demitido de lá, não é suficiente para ser considerado um gênio.

De qualquer forma, ainda que seja difícil(ou impossível) identificar alguém em particular como o maior gênio vivo, não podemos dizer que o Tim Berners-Lee é indigno deste título. Afinal de contas, ele criou algo que mudou o mundo para sempre, sem a qual você sequer estaria lendo este texto.

Primeiro tivemos o post sobre código sem comentários, depois o post abordando comentários em excesso, agora, finalmente, veremos algo que devemos usar: código autodocumentado.

Do que se trata?

Um código é autodocumentado quando você pode compreendê-lo facilmente apenas lendo o seu arquivo fonte. Para atingir tal nível de fluência, além de um programador que conheça a linguagem utilizada, precisamos que a maior parte do código fonte seja perfeitamente claro, além disso, devemos também comentar os trechos de código complexos que eventualmente existirem.

Escrevendo código claro

Talvez a tarefa mais difícil na busca por um código autodocumentado seja programar de forma extremamente clara, não só para si, como também para todos os outros programadores. Para conseguir isto você precisará de prática, dedicação e até mesmo uma certa dose de talento. Ou seja, não é nada fácil, e é justamente por isso que eu disponibilizo abaixo algumas dicas para facilitar esta atividade.

1. Siga as convenções da linguagem de programação que você utiliza, mesmo que você não goste delas. Fazendo isso, você irá reduzir a surpresa dos outros programadores e adestrar o pensamento de forma a reconhecer automaticamente certas construções.
2. Dê nomes intuitivos a todas as estruturas do seu programa. Isto inclui, por exemplo, classes, variáveis, métodos, arquivos, entre outros. Fazendo isto, ninguém irá parar pra pensar no propósito dos elementos que compõem seu software, possibilitando assim uma leitura mais fluente.
3. Escreva código que cumpra o objetivo, e só. Não escreva nada desnecessário, lembre-se que quanto menos linhas melhor.
4. Não escreva métodos longos. Se um método acaba se prolongando, é provável que ele faça coisas demais, devendo assim ser refatorado em dois ou mais métodos.
5. Evite escrever instruções excessivamente longas ou complexas. Em geral, essas instruções podem ser decompostas, e, ainda que isto signifique mais linhas de código, é melhor do que criar um ponto potencialmente complexo.

Escrevendo comentários

Clareza no código é apenas metade do necessário para termos código autodocumentado, sendo o uso de comentários a outra metade. Esta necessidade se dá devido a natureza complexa do software, pois mesmo quando escrevemos código de forma clara, poderão existir trechos do código onde a compreensão seja naturalmente mais difícil, sendo preciso usar comentários para resolver o problema.

Contudo, é importante ressaltar que apenas comentar não adianta nada. Temos que fazer o comentário valer a pena, afinal, mesmo ele sendo necessário neste caso, ainda implicará em mais tempo para escrever, ler e manter o programa.

Tendo isto em vista, separei abaixo algumas poucas dicas que talvez possa ajudá-lo a escrever bons comentários:

1. A menos que esteja trabalhando com uma equipe muito grande, não é necessário escrever comentários referentes a autoria dos códigos. Em geral, uma divisão de tarefas adequada já se encarrega de definir claramente quem faz o quê.
2. Escreva comentários somente para trechos de código complexos. Um comentário para descrever o objetivo de um elemento do programa é desnecessário, uma vez que um bom nome já é o suficiente. Por exemplo, não é preciso comentar o objetivo de uma classe chamada LoginController, uma vez que o nome não deixa dúvidas sobre o seu propósito.
3. Quando for escrever um comentário, não fale sobre a sintaxe do código, e sim da sua semântica no domínio da aplicação. Lembre-se que você está comentando um programa, e não a linguagem utilizada.
4. O comentário deve ser absolutamente claro sobre o trecho de código que ele está explicando, de forma a não restar dúvida alguma sobre o seu funcionamento.
5. Os comentários são apenas pequenos textos explicativos, e não artigos, portanto, seja sucinto e evite comentários com muitas linhas. Se puder utilizar apenas uma linha, melhor.

Use apenas o que gostar

As dicas acima não são dogmas, assim como tudo mais que eu disse nessa série de posts. Trata-se apenas da minha opinião sobre esta questão, logo, sinta-se a vontade para ignorar parte das dicas, parte do que eu disse, ou até mesmo tudo que leu nestes posts. Cada um tem sua maneira de desenvolver software, e eu estou longe de ter autoridade suficiente pra dizer que alguém está errado simplesmente porque discorda do que eu acredito ser o ideal.

Depois de vermos no post sobre código fonte sem comentários o quão ruim é esta prática, é hora de conhecermos outro cenário quase tão desagrádavel quanto: comentários em excesso.

A Transição

A maioria dos aspirantes a desenvolvedor já sabe da existência dos comentários quando está aprendendo a sua primeira linguagem de programação. Mas, como disse no post anterior, nesse momento nós ainda não temos maturidade para entender os benefícios desta abordagem, e consequentemente não comentamos nada.

Passado esse estágio inicial, e em geral quando já estamos na segunda linguagem, é comum lermos novamente sobre os comentários e a sua importância. Como neste momento nós já possuímos um pouco mais de conhecimento, e em geral também passamos a nos preocupar com as boas práticas no desenvolvimento de software, tendemos a reconhecer o valor dos comentários e os adotamos.

No meu caso, essa mudança de hábito ocorreu quando começei a estudar Java, aproximadamente 6 meses depois de aprender o básico sobre programação com o Pascal. Eu estava estudando através do clássico livro Java - Como Programar(6ª Edição), e o livro comentava bastante os seus códigos fonte, principalmente no início.Além disso, também lia costantemente sobre a importância dessa prática em fóruns sobre Java, principalmente no fórum do GUJ.

É claro que como resultado desta nova exposição ao tema, desta vez já tendo bagagem suficiente para assimilá-lo, eu acabei adquirindo o costume de comentar os meus códigos.

Pecando pelo Excesso

Acontece que eu não apenas escrevia comentários, eu escrevia muitos deles, bem mais do que o necessário. Se não me engano, eles ocupavam pelo menos metade das linhas dos meus arquivos fonte.

É claro que na época eu já desconfiava que aquilo não era uma boa prática, mas, como aquele código tinha fins meramente didáticos, achei que não tinha problema. E de fato, nesse primeiro contato com os comentários, o excesso até pode ser algo bom, uma vez que dá prática na tarefa, o que pode vir a ser útil no futuro. Além disso, também serve para agilizar o aprendizado, uma vez que você acaba escrevendo conteúdo sobre o que está aprendendo.

Mas, em cenários reais, pecar pelo excesso é quase tão ruim quanto pecar pela ausência. Portanto, quando estiver escrevendo programas de verdade, análise os comentários no seu código e tente avaliar se não há mais do que o necessário. Mesmo sendo esta uma questão subjetiva, em geral, se você se sentir desconfortável, é porque provavelmente exagerou mesmo.

Por que é tão ruim?

Se você leu o post anterior, onde eu descrevo como uma irresponsabilidade o ato de não comentar o código de um programa, pode estar confuso agora sobre o porquê de eu estar chamando a atenção para o excesso de comentários. Acontece que a velha máxima também se aplica aqui: tudo em excesso é ruim.

Neste caso, é ruim porque idealmente um programa deve atingir o objetivo proposto com o mínimo de linhas possível, obviamente sem sacrificar a legibilidade do código. Dessa forma será mais rápido para criar o programa, para ler ele, e também para mantê-lo, já que os comentários devem ser atualizados junto com o código que descreve.

Contudo, quando escrevemos comentários demais, o número total de linhas do programa aumenta desnecessariamente, criando assim vários pontos de disperção, pois será gasto mais tempo em atividades que não agregam valor real.

Seja Preguiçoso!

Por fim, uma dica final que eu posso dar quanto a esse assunto é para você seguir o meu exemplo e ser preguiçoso. Sempre que você sentir aquela indisposição pra inserir um comentário em um determinado trecho do programa é porque provavelmente ele não merece existir. E se ele não merece existir, não há porque colocá-lo. Lembre-se, não exagere jamais no quantidade de comentários que você escreve em um programa.

Uma das abordagens em relação aos comentários é simplesmente não comentar nada no código fonte. É cômodo, prático, e não exige esforço algum. Mas será que esta é mesmo a melhor prática?

No início…

Em geral, quando estamos aprendendo a programar, esquecemos completamente dos comentários, embora a maioria dos tutoriais ou livros sobre linguagens de programação ensine a sintaxe deles logo no início. Mas, nesse momento, o nosso foco é outro, estamos empolgados demais para ficar escrevendo comentários. Além disso, também não temos ainda a maturidade necessária para entender os seus benefícios.

Eu sei disso porque foi assim comigo, e muito provavelmente foi assim com você também. No meu caso em particular, eu iniciei na programação com o Pascal, a primeira linguagem de muita gente, e sinceramente nem lembro mais a sua sintaxe para comentários, tal a constância com que eu os usava.

Eu sei que isso não soa nada profissional, mas, neste contexto, onde estamos apenas aprendendo uma linguagem, ainda que não seja a primeira, esta abordagem é aceitável, afinal, não estamos falando sobre uma situação real de desenvolvimento.

E como ficam as coisas no mundo real?

No mundo real, onde estamos escrevendo código que irá virar um programa de verdade, não inserir nenhum comentário é uma tremenda irresponsabilidade, ainda que se trate de algo relativamente simples, onde você é, e sempre será, o único envolvido.

Sua memória irá te trair

Um dos motivos que faz com que tal prática seja condenável é o fato de nós, como seres humanos, termos uma memória incrivelmente falha. Você lembra o que almoçou 3 dias atrás? Provavelmente não, então como quer lembrar de cada detalhe de um programa que escreveu há semanas, meses ou até mesmo anos atrás? É simplesmente impossível.

Neste momento, você pode estar pensando que ainda que não lembre de cada detalhe do programa, você sempre poderá ler o código fonte e entender o seu funcionamento. Ledo engano! Software não é tão simples assim. Mesmo em linguagens expressivas como Ruby, podemos não entender o que queríamos fazer em certos trechos do código se ficarmos um certo tempo sem ter contato com ele.

O programa não é seu

Outro motivo para desconsiderar esta prática é o fato de que, na grande maioria dos casos, quem desenvolve o programa não é o seu dono. Em geral, o que acontece é que alguém nos paga para desenvolver um software com o objetivo de informatizar uma tarefa.

Esta pessoa, que investe na criação do programa, é o seu legítimo dono, e você tem a obrigração de desenvolver o sistema proposto de forma que ele não fique preso a você de forma nenhuma. Em outras palavras, o dono do programa deve ter a capacidade de mantê-lo facilmente sem a sua presença.

Para que isso ocorra, o código deve ser claro o suficiente para que qualquer outro programador com conhecimento na linguagem de programação utilizada seja capaz de entendê-lo.

Contudo, como vimos há pouco, às vezes é difícil entender o significado de certos trechos de código, mesmo quando escritos por nós mesmo. Logo, escrever um programa que seja claro não só pra nós mesmos, como também para outros programadores é ainda mais difícil. Por mais que escrevemos código legível, sempre há alguns pontos mais complexos.

É justamente para tentar resolver esse problema que existem os comentários, já que eles podem elucidar o funcionamente destes trechos mais problemáticos. Sendo assim, não comentar o código do programa é uma forma de dificultar, ou até mesmo impossibilitar, que ele seja compreendido por outros programadores, deixando assim o verdadeiro dono do programa preso a você.

Seja profissional!

Espero ter deixado suficientemente claro que não há motivo digno de consideração para não usar comentários, portanto, seja profissional! Não cometa este atentado contra as boas práticas do desenvolvimento de software. Os outros programadores agradecem.

Escrevendo o post sobre comentários no Ruby, me veio à mente um assunto bastante recorrente no desenvolvimento de software: o uso correto dos comentários.

Basicamente, existem 3 abordagens relativas a este assunto, e ao escrever sobre cada uma delas, eu percebi que se trata de um tópico um pouco mais extenso do que eu imaginava. Sendo assim, decidi dividir o que originalmente seria um post bem longo, em uma série de 3 posts mais focados, sendo um sobre cada abordagem.

O 1º post, Comentários são para fracos!, analisa a abordagem mais cômoda: não escrever comentário algum. Avalanche de comentários é o 2º post da série, e fala sobre a prática de entupir o código fonte de comentários. Por fim, temos o post Código autodocumentado, que é sobre o que eu acredito ser a melhor forma de atacar o problema: escrevendo código autodocumentado.

Espero que gostem desta pequena série de posts relacionados.

Há poucas dias atrás, houve uma certa discussão em torno de um post no blog do Obie Fernandez, um rubysta de fama internacional. O post se chamava Top 10 Reasons Why Java Sucks Ass, que em português significaria algo como 10 Razões Porque Java É Uma Droga.

Neste post, apesar de dizer algumas verdades sobre o Java, Obie estava sendo claramente motivado pelo senso de humor, já que não tem como considerar seriamente uma lista que inclui Java tem IDEs como um dos seus itens.

Mas parece que parte da comunidade Java não achou graça, e reagiu, ao meu ver, de forma exagerada nos comentários do post. Um deles, Daniel Spiewak, até mesmo escreveu um post parecido, dessa vez enumerando as 10 Razões Porque Ruby É Uma Droga.

Acontece que essa não foi a única situação parecida nos últimos dias, teve também uma discussão entre parte da comunidade Ruby on Rails brasileira e um programador .NET, que se iniciou por conta de um post chamado Porque Rails é melhor que ASP.NET? e terminou no post Ruby on Rails não tem futuro - corra atrás da sua certificação enquanto é tempo, no blog do Carlos Brando, que de certa forma originou o post que compara o Rails ao ASP.NET quando escreveu Por que .NET é melhor do que Rails?.

Por fim, houve também uma certa repercussão em torno do artigo 7 reasons I switched back to PHP after 2 years on Rails, ou 7 razões porque eu voltei pro PHP após 2 anos no Rails, escrito por Derek Sivers e publicado no blog sobre Ruby da O’Reilly.

Diante destas discussões, eu pensei em escrever sobre o protecionismo de alguns programadores, sejam eles programadores Java, .NET ou PHP, mas então eu lembrei de mim mesmo.

Há cerca de um ano e meio atrás, eu tinha recém iniciado os estudos do Java, e então um amigo me falou que existia uma linguagem “nova” chamada Ruby, e então me indicou o famoso tutorial Why’s (Poignant) Guide to Ruby.

Na ocasião, eu sequer me dei ao trabalho de pensar sobre o assunto, e apesar de ter ido dar uma olhada no tutorial, eu o fiz já com o resultado definido: não gostaria do tutorial e muito menos do Ruby. Pensei na hora “Aquilo definitivamente não pode prestar”. Enfim, eu fiz a proeza de realizar uma ação já tendo decidido qual é o resultado dela antes mesmo de iniciá-la.

Pouco tempo depois, esse mesmo amigo também me aconselhou a estudar sobre o Ruby on Rails, além de explicar algumas de suas vantagens, no qual foi novamente ignorado sem maiores buscas técnicas do que seria este tal Ruby on Rails. Pelo contrário, dessa vez eu sequer me dei ao trabalho de fingir dar uma chance ao Rails, não buscando material algum sobre o assunto.

Depois de muito tempo, e em grande parte por influência dos excelentes artigos do Fábio Akita sobre o Ruby on Rails, eu decidi dar uma nova chance ao Ruby e também ao Rails. Como resultado desta nova busca, dessa vez sem um resultado pré-definido, eu me tornei um fã tanto do Ruby como do Rails, tendo ambos hoje como meus principais objetos de estudo.

Ainda assim, eu demorei um certo tempo para perceber o quão estúpido eu fui. Na verdade, eu só percebi mesmo ao ver este mesmo comportamento sendo repetido por outras pessoas. Então eu consegui identificar o motivo desta atitude nessas outras pessoas, e só então a ficha caiu, e eu vi que era a mesma motivação que me moveu no passado: o protecionismo.

Sendo assim, hoje é fácil para mim olhar pra trás e me achar uma besta pela minha atitude passada, assim como também é fácil criticar a reação dos programadores Java, .NET e PHP envolvidos nas discussões mencionadas.

No entanto, justamente por ter sido tão irracional no passado, baseado no protecionismo de não querer que outra coisa seja boa para que isso não signifique que o que eu estou estudando não é, eu entendo o comportamento desses programadores. Se eu não dei importância ao assunto quando me foi apresentado por um amigo, não é de se espantar que eles façam o mesmo quando apresentados por estranhos.

E mais importante que entender, eu tento me policiar agora para não fazer o mesmo novamente. Não somente nesta questão, mas em outras também, ou seja, quando identificar algo que eu considero irracional vindo de outra pessoa ou de outro grupo, tentar olhar para mim mesmo pra ver se não encontro uma correspondência nas minhas próprias ações. Até porque, eu só percebi o meu erro através da reprodução dele por parte de outras pessoas.

Sendo assim, aconselho aqueles que tiverem lendo isso a fazer o mesmo, olhar para essas e outras atitudes irracionais, e então olharem para dentro de si mesmos para verificar se há correspondências. Muitas vezes não notamos que cometemos os mesmos erros que achamos estúpidos quando o vemos em outras pessoas. Sendo assim, usemos os erros alheios como ferramenta para descobrir os nossos, pois lamento informar, mas não é só os outros que cometem erros muitas vezes estúpidos.

E para finalizar, gostaria de dizer que isto não é de maneira alguma uma crítica a comunidade Java, PHP ou .NET, até porque a raíz de comportamentos estúpidos não está em nenhuma dessas linguagens de programação, e sim no comportamente humano.