Há alguns anos, era muito comum encontrarmos desenvolvedores que conheciam somente uma linguagem, e por isso intitulavam-se “desenvolvedor Java”, “desenvolvedor Delphi”, “desenvolvedor ASP”, ou qualquer outra linguagem. Eram pessoas que conheciam uma, e somente uma, linguagem de programação, e a defendiam com unhas e dentes em qualquer discussão nos fóruns, frequentemente gerando flame wars.

Esse tipo de desenvolvedor ainda existe, mas é cada vez menos comum, e isto é muito positivo. O livro The Pragmatic Programmer recomenda que aprendamos uma linguagem nova por ano, e, com isso, muitos daqueles desenvolvedores Java ou C# estão aprendendo Ruby, Python ou Erlang. Mesmo que não tenhamos pretensão de trabalhar com estas linguagens, pelo menos a curto ou médio prazo, cada linguagem tem suas particularidades, ajudando a quebrar paradigmas. Quando conhecemos somente uma linguagem, temos uma grande tendência a resolver os problemas sempre da mesma forma, conforme aprendemos e como é feito tradicionalmente com aquela linguagem. Desta forma, a tendência é a estagnação, pois não procuramos outras maneiras de resolver os problemas. A partir do momento em que começamos a estudar outras linguagens, abrimos nossa cabeça e começamos a “pensar fora da caixa”, e percebemos que existem muitas outras maneiras de resolver aquele mesmo problema, muitas delas mais simples e adequadas à situação. Surgem os desenvolvedores poliglotas.

Na época dos desenvolvedores monoglotas (sim, essa palavra existe!) era muito comum vermos discussões do tipo: “que linguagem é melhor, X ou Y?”. A melhor resposta é: depende! Depende da situação, do projeto, da experiência da equipe… Para cada situação, uma linguagem pode ser mais adequada que outra, o que traz uma grande vantagem para os poliglotas, pois, para se tomar esta decisão, é necessário conhecer as linguagens disponíveis. Ao mesmo tempo, se ninguém na equipe tiver experiência com determinada linguagem, seria um grande risco utilizá-la no projeto. É como uma caixa de ferramentas: se eu tiver somente um martelo na minha caixa, como farei para apertar um parafuso? É importante termos o maior número possível de ferramentas disponíveis, e conhecimento sobre cada uma delas, para que possamos escolher a mais adequada em cada situação.

Acompanhando esse comportamento, há atualmente uma forte tendência a plataformas poliglotas, o que também é muito positivo. As plataformas existentes já estão bastante maduras, têm algoritmos eficientes para gerenciamento de memória e Garbage Collection, por exemplo, e são bem conhecidas. Encontram-se nesta categoria as plataformas Java e .NET, que estão continuamente aumentando o número de linguagens suportadas - veja a lista de linguagens suportadas pela JVM e pelo .NET. Com isso, a escolha da linguagem para cada projeto fica muito mais fácil, permitindo, inclusive, projetos poliglotas. Se você trabalha com Java e decide utilizar Ruby no seu projeto, por exemplo, basta adicionar o jar do JRuby.

A conclusão que podemos tirar disso é que um desenvolvedor nunca deve estagnar. Procure sempre estudar e aprender novas coisas, mesmo que não seja nada relacionado com o que você está trabalhando atualmente, pois, mesmo que não venha a trabalhar, isso ajuda a quebrar paradigmas e permite que você se torne um melhor desenvolvedor.

Muitos já devem estar sabendo, mas acho que não custa nada ajudar a divulgar: no dia 14 de setembro ocorrerá aqui no Rio de Janeiro um evento imperdível: o Dev in Rio. Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento terá palestras sobre Rails, Django, Java, Open Source e metodologias ágeis, contando, inclusive, com palestrantes internacionais. A inscrição custa apenas R$ 65,00, e, pelo sucesso que está fazendo, acho que as vagas vão acabar logo!

Para quem estiver sem grana, vale a pena tentar ganhar ingressos pelo RubyInside ou pela revista TI digital.

Mais informações sobre o Dev in Rio no site e no twitter. Parabéns aos organizadores pela iniciativa!

Há muito tempo eu uso o Google Reader como leitor de feeds. A principal vantagem sobre as demais alternativas para desktop é o fato de não necessitar de instalação, podendo ser acessado diretamente pelo browser.

Outro dia, tentei cadastrar o feed do Twitter no Google Reader, e recebi a seguinte mensagem: “Sorry, an unexpected condition has occurred which is preventing Google Reader from fulfilling the request”. Tentei acessar o feed diretamente no Firefox, e, após solicitação de login e senha, os feeds apareceram normalmente. Após uma rápida pesquisa, descobri que o Google Reader não suporta feeds autenticados, o que é o caso do Twitter.

Uma das alternativas a este problema seria utilizar um leitor de feeds que suporta autenticação, como a extensão NewsFox para Firefox ou algum outro. Porém, para poder continuar utilizando o Google Reader, uma solução é o FreeMyFeed, um serviço que funciona como uma espécie de proxy para feeds autenticados: você informa a URL, o login e a senha do feed que exige autenticação, e ele gera um novo endereço de feed que permite acesso direto, inclusive pelo Google Reader.

Há alguns meses atrás, eu estava interessado no livro Effective Java, segunda edição. A princípio, eu pretendia comprar na Amazon, mas decidi pesquisar antes. Pela internet, não achei o livro mais barato em nenhum lugar, mas acabei encontrando em uma livraria perto do trabalho por um precinho camarada. Só tinha um problema: era a edição traduzida em português.

Inicialmente nem pensei em comprar a edição traduzida, pois acho que livros técnicos devem ser mantidos na língua original. Algumas pessoas que discordam disto argumentam que nem todos dominam o inglês, mas, sinceramente, se você tem dificuldades com inglês e quer estudar informática, procure um curso de inglês urgente! Por mais que você procure ler somente livros em português, em algum momento vai precisar consultar alguma documentação, referência ou fórum de discussão em inglês. Além disso, acho que nas traduções, por melhores que sejam, acaba-se perdendo um pouco do original (como num filme dublado, em que algumas piadas em inglês perdem completamente o sentido quando traduzidas), aumentando a possibilidade de erros e a dificuldade de compreensão do assunto. Num livro de programação então nem se fala, pois é muito comum utilizarmos muitos termos em inglês que não têm tradução para português - ou até tem, mas o original se popularizou tanto que é usado como se fosse uma palavra do nosso vocabulário.

Na época em que fiz essa pesquisa, o livro estava mais caro na Amazon do que hoje, e ainda tinha que incluir o frete. Aquela edição traduzida sairia por menos da metade. Além disso, eu não teria que esperar a entrega, era só dar um pulo na livraria e comprar. Decidi dar uma folheada no livro, só pra ver se tinha algum erro gritante de tradução, como trechos de código traduzidos - sim, eu já vi livros com aberrações como “calculaMédia”, com acento mesmo. Como não encontrei nada de mais, acabei me deixando levar pela tentação de economizar uns trocados e comprando o livro traduzido.

Quando comecei a ler, achei a tradução muito boa. Nos primeiros capítulos, o único termo que machucou os ouvidos foi “encaixotamento automático” em vez de autoboxing - por mais que esteja correto, esse é um daqueles termos que não se costuma traduzir. Além disso, os trechos de código foram mantidos originais, e abaixo de cada um há a tradução de cada linha de comentário. Achei um pouco desnecessário, porém interessante.

Ao chegar no capítulo 4, estranhamente os comentários nos códigos passaram a ser substituídos pelos traduzidos. Isso continua até o final do livro. Aparentemente a tradução foi feita por pessoas diferentes, e faltou uma revisão mais rigorosa no final. Porém, não é nada que atrapalhe. Mais adiante, vi uma citação a uma referência bibliográfica e resolvi verificar qual era o nome do livro referenciado. Descobri que o livro não tinha bibliografia! Obviamente isso é uma exclusividade da edição em português. Mais uma falha de revisão, e esta é mais grave.

Quando comecei a ler o capítulo 5, que fala sobre generics, achei o trecho abaixo bem estranho:

Antes da versão 1.5, essa teria sido uma declaração de coleção exemplar:

/**
 * Minha coleção de selos. Contém apenas instâncias de Stamp.
 */
private final stamps = ...;

Não está faltando definir o tipo de stamps? Tudo bem, eu não devo ter entendido direito. Sigo a leitura e, um pouco mais à frente aparece o seguinte:

Com os genéricos, você substituiria o comentário por uma declaração de tipo aperfeiçoada para a coleção que passaria ao compilador as informações que anteriormente ficariam ocultas no comentário:

private final stamps = ...;

Ué, mudou alguma coisa? Não é exatamente igual ao código anterior? Resolvi pegar o livro original em inglês emprestado com um amigo, e vejo que nele aparecem os seguintes trechos:

Before release 1.5, this would have been an exemplary collection declaration:

```java // Now a raw collection type - don´t do this!

/**

• My stamp collection. Contains only Stamp instances. */ private final Collection stamps = … ; ```

e

With generics, you replace the comment with an improved type declaration for the collection that tells the compiler the information that was previously hidden in the comment:

// Parameterized collection type - typesafe
private final <strong>Collection &lt;Stamp&gt;</strong> stamps = ... ;

Os destaques em negrito são do livro original. Aparentemente, tudo o que estava em negrito foi omitido na tradução! E, se estava em negrito, é porque é exatamente o trecho mais importante do código! Posteriormente, descobri que isso acontece em todo o capítulo 5. Do 6 em diante os códigos voltam ao normal e não encontrei mais nenhuma bizarrice, exceto a tradução de “thread” para “segmento”.

Outro erro que se repetiu bastante no livro são as referências a números de páginas (ex: “veja a página 147”). Em todas as situações em que isso ocorre, o número da página que é referenciado é o do livro original, tornando a referência inútil na edição traduzida.

A conclusão que tirei dessa situação: livro técnico traduzido nunca mais! Os trocados que resolvi economizar com o livro acabaram saindo muito caros. Vale muito mais a pena investir um pouco mais no livro original - e num curso de inglês, caso você precise - para não ter dor de cabeça com livros mal traduzidos.

Esta semana saiu o Firefox 3.5, com uma série de melhorias, como o recurso de geolocalização e o modo Private Browsing. Além disso, o browser está muito mais rápido que na versão anterior, devido principalmente ao novo engine de Javascript e ao suporte nativo a JSON.

Além disso, outra novidade importante é a adição de suporte ao HTML 5. Esta versão ainda é um working draft, que traz como principais novidades as tags <video> e <audio>, para suporte nativo a mídias. Assim, não é mais necessário usar tags <embed> e um player externo para a exibição dos já onipresentes vídeos online. Existem vários sites que já utilizam HTML 5 para demonstrar os novos recursos, como mostra este post do Zumo e o Video Bay.