Dia desses estava eu resmungando pra minha namorada o quanto a minha pesquisa empaca quando meus colegas (principalmente meu orientador) estão muito ocupados e eu não recebo feedback. Como a gente gosta de fazer sudoku juntos, eu comecei a fazer uma analogia entre os problemas atacados em pesquisa acadêmica e sudoku pra explicar meus resmungos. Achei a analogia curiosa, então aqui vão os dois pontos principais, quem sabe alguém acha mais.

Antigamente, isso desde a idade antiga até mais ou menos a 2a guerra mundial, os pesquisadores eram aqueles seres mitológicos, geralmente um pouco malucos, excêntricos e isolados. Eles resolviam seus problemas separadamente, ficando muitas vezes anos escondendo o jogo até conseguir resultados interessantes. Por isso vemos várias vezes na história casos de descoberta simultânea por pesquisadores isolados. O grande problema desse modelo é que muitas vezes você fica empacado. É isso que acontece comigo quando eu faço sudoku sozinho, sem minha namorada. As vezes tem uma solução óbvia pra uma célula, bem na cara, e eu simplesmente não vejo (obviamente isso acontece com ela também, quando ela faz sozinha). E é exatamente assim que me sinto quando falta colaboração na minha pesquisa: eu as vezes encontro problemas que me travam ou, pior ainda, perco um bom tempo num caminho errado, o que poderia ser evitado se alguém com um “fresh look” no problema me desse um toque. Colaboração se tornou essencial em pesquisa principalmente a partir da 2a guerra, quando a complexidade dos problemas (e o preço das soluções!) começou a ficar grande demais pra um pesquisador solitário (ou um até um país sozinho, vide CERN). E com os meios de comunicação atuais, isso só está acelerando. Um bom exemplo é o My Experiment, um portal em que pesquisadores contribuem a metodologia de experimentos pra facilitar replicação.

Outro aspecto em que sudoku se parece com um problema de pesquisa é no seu lifecycle, ou ciclo de vida. Quando surge um novo problema de pesquisa, ou até uma nova área, é como um jogo de sudoku recém começado. As primeiras células são bem fáceis de serem preenchidas, assim como é bem fácil fazer progresso no problema. Você ataca antes as chamadas “low hanging fruits”, ou seja, faz antes o que é mais fácil de ser feito. Daí surgem aquelas lendas, e essa eu ouvi diretamente da boca do Alan Kay, de cientistas da computação conseguindo PhD em uma semana (nos anos 50, 60) por um algoritmo para alguma coisa que ninguém tinha feito antes (não me lembro exatamente pra que). Um outro exemplo é a invenção dos compiladores, provavelmente o desenvolvimento na área de computação que teve o maior impacto na produtividade, impacto que dificilmente vai ter equivalente no futuro. O ponto é que é mais fácil quando ninguém fez nada na área ainda. Depois a coisa começa a empacar, e tem-se uma fase de progresso incremental, em que problemas difíceis são resolvidos um a um, cada um merecendo um PhD. Depois, quando o tabuleiro já está mais cheio, fica mais fácil de completar. É nessa hora que os pesquisadores perdem o interesse na área, e geralmente os problemas que faltam sobram pra indústria. E é nessa hora que eu perco o interesse, viro pro lado e deixo minha namorada terminar o sudoku em paz!

Eu ando meio ausente deste blog. Percebo que a atividade de escrever requer tempo, e sobretudo, ócio criativo. Raramente consigo escrever um texto entre uma atividade e outra, menos quando são textos com notícias breves, como este sobre o Job4Dev no UOL. E o leitor há de se perguntar: “o que toma tanto o tempo deste pobre rapaz?”.

Respondo: o SigaSeuTime, startup que vem crescendo de forma animadora e que me tem tomado todo o tempo livre fora do horário comercial (sim, porque no horário comercial eu brinco de desenvolver sistemas de controle de tráfego aéreo, que ainda é a minha fonte de renda principal…e única).

Mas, acreditem, não passa um dia sequer sem que eu pense que deveria me dedicar mais a este espaço. E não passa um dia sequer sem que eu leve sermão do Raphael por não meter mais a mão no Job4Dev (assumi o papel de captador de vagas…). Mas isto é assunto pra outro dia.

Vou aproveitar o momento de inspiração para relatar uma experiência que tive recentemente trabalhando com o SigaSeuTime, que me parece interessante.

O ditado “A grama do vizinho é sempre mais verde” se aplica a quase todas as áreas do comportamento humano: nós temos uma tendência a achar que o que os outros têm é melhor. Em termos de linguagem de programação, o fanatismo de certos grupos tende a contrariar este ditado: é muito raro algum fã de uma linguagem admitir falhas, e ver outras opções como sendo mais eficientes, modernas, seguras…

Eu já comentei em algum outro texto que o conjunto Python/Django funcionou como um catalizador da minha capacidade produtiva/criativa. Sempre tive várias idéias (não forçosamente boas) mas tinha uma grande dificuldade de colocá-las em prática em Java (que é a minha linguagem de atuação profissional), e Python me permitiu concretizar algumas de forma rápida e eficiente.

Hoje, depois de uma boa quantidade de linhas de código escritas nesta linguagem, das quais a grande maioria em produção de forma estável  no SigaSeuTime e no Job4Dev, me pego pensando em algumas características presentes em linguagens como Java que eu sinto falta. Na verdade, existe uma principal: tipagem de parâmetros de funções e métodos. Apesar dos amantes de Python me dizerem por meio de comentários que eu preciso mudar minha forma de pensar, ainda acho que tipagem de parâmetros facilita a leitura de códigos alheios, e que sobrecarga de métodos é um recurso bastante elegante e útil.

Por vários motivos, incorporei um subsistema em Java dentro do SigaSeuTime, que implementa uma das plataformas. Este subsistema foi desenvolvido por um programador freelancer, e recentemente tive que mexer no código para fazer algumas adaptações. E foi um ótimo estudo comparativo de ambientes: Java/Eclipse vs Python/Emacs (já testei Python/Eclipse, e não vi grandes vantagens…). Cheguei à conclusão de que, no quadro da minha startup, entre a rede de proteção gigantesca oferecida por Java e a rapidez de desenvolvimento oferecida por Python, eu ainda prefiro a segunda opção.

Não trabalhei em projetos com muitos desenvolvedores em Python (no máximo, eu e mais um ou dois), e tenho certeza de que a rede de proteção de Java evita muitos problemas potenciais de gente mexendo onde não devia, chamadas erradas, etc… Mas como eu sempre trabalhei com pessoas de alto nível no SigaSeuTime e no Job4Dev, a eficiência do ciclo de desenvolvimento/deploy do Python (e das linguagens de script dinâmicas em geral) me parece ser muito vantajosa em um projeto onde o importante é desenvolver rápido para colocar em produção rápido.

E quando eu digo rápido, significa eventualmente resolver um bug no código em produção, através de um Vi ou Emacs rodando em um terminal SSH. Sim, eu já fiz isso mais de uma vez, para o desespero de muitos dos leitores deste blog e defensores de CMMIs da vida.

Grandes empresas precisam implementar processos e mecanismos de controle para organizar o crescimento (muitas vezes desordenado) de pessoas, muitas vezes acompanhado pela redução da qualidade média dos desenvolvedores.

Em ambientes pequenos de startup, onde é possível imaginar uma equipe apenas composta por boas pessoas, os controles e processos são desnecessários e muitas vezes indesejáveis. Neste contexto, todas aquelas preocupações enterprise padrões devem ser deixadas de lado, e os participantes do projeto devem focar suas energias em apenas duas coisas: tornar o projeto uma realidade e trabalhar para que ele seja viável economicamente. O resto é resto…

Existem projetos pessoais que tem a vocação de ficarem para sempre gravados em uma pasta obscura do seu HD. Todo nerd que se preze tem pelo menos um desses: códigos de prova de conceito, brincadeiras escritas em um sábado a noite quando todos os seus amigos cools estavam na balada, e os do orkut estavam offline.

Existem outros escritos com a esperança de darem certo, e de se tornarem o próximo empreendimento de bilhões de dólares. Pouquíssimos chegam lá, mas muitos crescem, começam a ser reconhecidos, criam uma base de usuários, constroem uma marca. E seus desenvolvedores agem exatamente como pais: ficam orgulhosos em ver o filho ficando forte, bonito.

O Job4Dev nasceu como um Pet Project, e foi ganhando consistência. Não, não estamos nem perto de ficarmos ricos, mas estamos construindo uma marca. Vibramos com as primeiras empresas que cadastraram vagas espontâneamente, com os primeiros seguidores no Twitter, com os primeiros usuários do RSS.

E hoje, estamos vibrando muito com a nossa primeira aparição em um grande veículo de mídia, o UOL. Cito:

A Ubisoft divulgou por meio do site Job4Dev, especializado em anúncios de empregos na área de tecnologia da informação, novas vagas para programadores na filial brasileira da produtora no Rio Grande Sul.

Estão disponíveis vagas para programadores especializados em artes 2D e também 3D. O estúdio em questão fica localizado na cidade de Porto Alegre e é o antigo Southlogic, adquirido em janeiro deste ano pela produtora francesa.

O site não revela para quais projetos especificamente são necessários os programadores, mas exige-se domínio de diversos softwares e conhecimento de inglês. A descrição da vaga para programador 2D diz que o foco é em “criação de interfaces e gameplay”, ao passo que o programador 3D fica responsável por “trabalhar na criação, adaptação e manutenção de tecnologia 3D para jogos”.

As descrições completas das vagas e instruções para se candidatar a elas pode ser vista no site Job4Dev.

E neste momento, só posso dizer o seguinte: É nóis na grande mídia, mano!!!!

Semana passada eu estava buscando material de referência para algumas configurações do Git e achei um livro muito bom, chamado Pro Git. O livro foi escrito por Scott Chacon e publicado pela Apress. Como o livro foi publicado sob a licença do Creative Commons, está aberto para traduções e até mesmo adaptações.

No verdadeiro espírito de eating your own dog food, o autor do livro colocou o código-fonte do livro no GitHub e qualquer pessoa pode fazer um fork, para fazer modificações no material. Vi que a tradução para pt_br foi iniciada, mas ainda estava tímida. Ato contínuo, fiz um fork do projeto e comecei a fazer a tradução.

A minha idéia é completar a tradução e colocar aqui no site, em uma seção separada. Obviamente, não é algo que vai ficar pronto em uma semana, ainda mais se eu fizer sozinho. Então, fica a dica: se você quer aprender a mexer com o Git, ajudar a fazer a tradução do livro enquanto usa o Git é o casamento perfeito entre teoria e prática.

Acabo de voltar de férias e, coincidentemente, a tira de hoje do PHD Comics me pareceu muito aproriada:

Estava relendo algumas notas antigas que eu faço para mim mesmo sobre comentários que as pessoas leitoras (e, eventualmente, editoras) deste blog fazem…

Na outra ponta, poderíamos pensar o seguinte: que tal se, ao invés de ter uma equipe de 12 pessoas em um projeto, o que levaria ter 12 pessoas que tenham familiaridade com um conjunto de ferramentas (e aí, obviamente, nos levando a escolher um framework), que tal diminuir a equipe para 3 ou 4 que sejam (a) mais experientes/produtivos e (b) capazes de utilizar ferramentas mais poderosas?

Com a ajuda de uma ferramenta de busca não foi difícil achar que este foi um comentário do Rapahel neste post aqui. Longe de querer reavivar aquela discussão, o que me veio à cabeça foi uma resposta, para mim simples, à pergunta, extremamente importante e sobre a qual já refleti diversas vezes, do Raphael.

Eu diria que o principal problema que eu vejo para não ter uma equipe de 12 pessoas medianas que tenham familiaridade com um conjunto de ferramentas e, no lugar disso, ter uma equipe de 3 ou 4 pessoas mais experientes e produtivas, capazes de utilizar ferramentas mais poderosas é porque é muito difícil contratar estas 3 ou 4 pessoas.

Já coordenei e participei como entrevistador em diversos processos de seleção e às vezes fico horrorizado com alguns currículos recebidos ou pessoas entrevistadas. Além disso, a quantidade de pára-quedistas que aparecem em processos seletivos é enorme. Pessoas que simplesmente não tem nada a ver com a vaga (e chegam a dizer isto explicitamente no currículo) mas que mesmo assim se candidatam a ela.

Por ser tão difícil de achar estes 3 ou 4, pelo fato de os projetos geralmente terem prazos apertados que não possibilitam perder muito tempo formando (ou contratando) uma equipe e, talvez, pelo preço de estes 3 ou 4 ser muito alto quando comparado com os 12 medianos, eu diria que provavelmente eu preferiria me manter com os 12 medianos se eles fossem capazes de entregar o projeto pronto do que gastar tempo e dinheiro buscando profissionais que talvez não apareçam, impactando, no fim das contas, o bom andamento do projeto que, no fundo no fundo, não precisava de pessoas qualificadas para ser entregue em um nível bom (mas não ótimo).

Agora, sinceramente, o que mais me preocupa não é está minha “equação” pragmática. O que mais me preocupa é realmente a dificuldade de se achar pessoas realmente boas. E isso eu acho que é culpa da formação e do interesse geral das pessoas naquilo que elas fazem. Coisa difícil de mudar num curto prazo.

Outro dia, num almoço com outros alunos de pós-graduação do Instituto de Computação da Unicamp, estávamos conversando sobre ferramentas de busca e o que elas fazem bem ou mal para nós.

Na verdade a conversa começou porque uma professora tinha pedido a mim para procurar o número de artigos que referenciavam três artigos que eu estava estudando. Esta é uma métrica bastante utilizada no meio científico para ver quão bom um artigo é. Quanto mais referências um artigo tem em um menor espaço de tempo indica quão mais importante para o meio acadêmico de uma forma geral são as idéias defendidas naquele artigo.

Para fazer esta busca, a professora sugeriu que utilizássemos uma ferramenta de busca desenvolvida especificamente para este propósito: o Citeseer. Basicamente o que esta ferramenta faz é buscar numa base de dados as informações sobre um artigo e as referências cruzadas que outros artigos catalogados na mesma base de dados tem com este artigo buscado. Fiz uma busca para os três artigos que eram meu foco e… nada. Não me lembro exatamente dos resultados, mas acho que um nem foi encontrado e os outros dois, apesar de terem sido encontrados, não eram referenciados por ninguém.

O problema, neste caso, era que eu estava trabalhando com artigos muito novos, publicados no final do ano passado. Como o Citeseer, se não me engano, nem utiliza uma base de dados própria, não havia tido tempo suficiente para esta base de dados, que é alimentada com dados de algumas das principais organizações de pesquisa do mundo (no caso de computação, por exemplo, ACM e IEEE), fosse devidamente atualizada pelos diversos intermediários até chegar ao pessoal do Citeseer.

Tentei, então, o CiteseerX, uma versão nova da engine do Citeseer que ainda está na versão beta. Sem sucesso também.

A minha última tentativa foi, então, o Google Scholar. Bom, ele pelo menos conseguiu identificar os meus artigos (provando mais uma vez que o Google realmente consegue indexar algumas coisas bem rápido). Mas ainda assim meus artigos não eram referenciados. Tudo bem. Eles eram novos e isso era de se esperar.

Mas ai, no meio disto tudo, veio à tona três perguntas interessantes: você já usou outra ferramenta de busca que não o Google? Se sim, quando e porque você mudou para o Google? Será que um dia vamos parar de usar o Google?

Muita gente que eu conheço sempre usou o Google. Acho que estas pessoas teriam ainda mais dificuldades de mudar de ferramenta de busca um dia, eventualmente, se isto acontecesse.

Bem, este não é o meu caso. E toda esta conversa que tivemos me fez lembrar de quando comecei a usar a Internet. Este ano faz quinze anos (nem eu imaginava que já era tanto tempo). Em 1994, a World Wide Web estava engatinhando ainda. As ferramentas de busca, idem.

Na verdade, em 1994 não existia nenhuma ferramenta de busca que merecesse este nome para falar a verdade. Naquela época, eu e muitos outros colecionávamos os endereços que achávamos mais interessantes. Eu tinha uma planilha que chegou a ter cerca de 200 endereços catalogados e divididos em categorias. Nesta época eu já via a necessidade de ter uma ferramenta de busca (que fosse uma busca na minha planilha), mas eu não tinha conhecimento técnico para fazer isto — infezlimente; se tivesse, talvez eu estaria milhionário hoje.

O fato é que, naquela época, agrupar endereços em diretórios era tudo o que dava para ser feito. Foi assim que nasceu, também em 1994, o “Jerry and David’s Guide to the World Wide Web”, que, ainda naquele ano passou a se chamar “Yet Another Hierarchical Officious Oracle” ou, simplesmente, Yahoo!. Mais da história inicial do Yahoo! pode ser encontrada aqui.

Eu não tive o prazer de acessar o site inicial de Jerry and David pelo meu navegador Mosaic (primeiro navegador existente e predecessor do Netscape 1.0). Mas a versão inicial do Yahoo! eu usei. Era o melhor que se tinha na época. Andei procurando no Internet Archive uma versão do site inicial do Yahoo!, onde só existia a estrutura de diretórios e nenhuma ferramenta de busca ainda. Mas nem mesmo o Internet Archive indexava páginas há tanto tempo atrás. A primeira home page do Yahoo! que existe lá é de outrubro 1996. Clique aqui para dar uma olhada (até os links funcionam! ). Nela existe a famosa estrutura de diretórios do início do Yahoo! (que deve existir até hoje) e uma ferramenta de busca (talvez a primeira da qual eu me lembre).

Eu parei de usar o Yahoo!, se não me engano, pouco antes de entrar na faculdade, em 1999. Naquela época já existia uma ferramenta de busca chamada AltaVista que conseguia atingir diversos sites que, aparentemente, não eram visitados ou corretamente classificados pelo Yahoo!. Como dizia o próprio slogan do AltaVista, ele era “The most powerful and useful guide to the Net”. O AltaVista ainda existe. Hoje ele é parte do Yahoo!, que, se não me falha a memória, em um determinado ponto no tempo comprou a engine do AltaVista para utilizar em suas próprias buscas. Eu, no entanto, não voltei a usar o Yahoo! como ferramenta de busca.

Até que, já lá para o meio do meu tempo de faculdade, muitas pessoas vinham me falar do Google. Com o tempo, as buscas que eu fazia no AltaVista já não pareciam tanto satisfatórias. E, quando eu, insatisfeito, ia até o Google e repetia a mesma busca, ele me retornava resultados melhores. Com o tempo, fui largando o AltaVista e passei a usar somente o Google.

Como já comecei a usar o Google quando ele era uma ferramenta estável, usei o Internet Archive para buscar as primeiras versões da página do Google. É interessante notar que a primeira página registrada para o Google no Internet Archive (que, neste caso, deve ser a primeira página deles mesmo) não era tão diferente da atual e o nome Google aparecia com um ponto de exclamação no final  (“Google!”)… será que isto tinha alguma coisa a ver com o então maior site de busca do momento “Yahoo!”? Yahoo!, inclusive, para o qual o engine criado por Larry Page e  Sergey Brin (fundadores do Google) foi oferecido e rejeitado, o que levou à criação do Google. Mas isto é outra história…

Bom, o fato é que o tempo foi passando e hoje o Google, para mim, está agregado em rotinas automáticas no meu computador. Para falar a verdade, não acesso mais a ferramenta de busca pela página web do Google já faz muito tempo. Uso apenas o plug-in de busca para o Firefox ou o Google Desktop para fazer isso. Com isto, fica cada vez mais difícil a mudança para outra ferramenta de busca, na minha opinião, pois tudo já está pronto e funcionando assim.

No entanto, isto não quer dizer que não existam outras opções. Ano passado foi lançado o Cuil (leia-se “cool”), um site de busca criado por ex-funcionários do Google. O grande diferencial do Cuil seria a não utilização da popularidade de uma página como item preponderante no cálculo de relevância da página, o que pode ser bem interessante em alguns casos, especialmente quando se busca conhecimento e não simplesmente popularidade. No entanto, eles mesmo adimitiam na época que não era necessário apenas uma boa ferramenta de busca: o maior trabalho estaria em quebrar a inércia dos usuários (a minha, por exemplo, como descrevi no parágrafo anterior, é bem alta).

Outra que sempre tentou desbancar o Google foi a Microsoft. Ano passado ela tentou comprar o Yahoo!. Não deu certo. Este ano ela lançou o Bing, sua nova ferramenta de busca. Apesar do visual mais bacana que o do Google (na minha opinião) e de ele vir embutido em vários produtos da Microsoft, isto não foi suficiente para mudar a inércia do usuário.

Sinceramente, eu acho que a única maneira de quebrar esta inércia do usuário em relação às ferramentas de busca que ele usa é criar algo que o Google ainda não oferece (não me pergunte o que… se eu soubesse não estaria escrevendo este post, mas sim implementando esta idéia ). Ou fornecer ferramentas de busca que retornem resultados mais aprimorados que os do Google em campos nos quais o Google talvez não seja satisfatório. Eu listaria como dois campos em que o Google está longe de ser satisfatório em relação às buscas, na minha opinião, as buscas por imagens e por vídeos. O “Santo Graal” nestas áreas, por mim, seria conseguir fazer busca não pelos textos das páginas em que as figuras ou os vídeos aparecem, mas sim fazer busca pelo significado das imagens e dos vídeos mesmo. Algo que eu acho que a computação ainda está um pouco longe de conseguir fazer de forma automática e eficiente.

Esta nem é tão nova assim, mas se alguém ainda não viu acho que vale a pena ver.

O Wii é hoje talvez o vídeo-game de última geração que mais unidades vendeu. E muito disso certamente se deve ao novo modo de interação com o usuário que ele introduziu, já que em termos de inovação e evolução de tecnologia de processadores, por exemplo, ele fica bem atrás de seus concorrentes XBox 360 e PlayStation 3. Já falei um pouco sobre isso aqui. Nesse post, inclusive, disse que achava que esta nova forma de interação do Wii poderia introduzir novas alternativas para a computação de uma forma geral. Este post atual é sobre isto.

Todo este novo modo de interação com o usuário introduzido pelo Wii é responsabilidade do Wiimote, o controle do vídeo-game. O que talvez nem todo mundo saiba é que é possível utilizar o Wiimote para tarefas que não aquelas para as quais ele foi originalmente desenhado, ou seja, ser apenas um controle de vídeo-game.

Os vídeos abaixo mostram ao menos três coisas muito legais que são possíveis de se fazer com um Wiimote. Basicamente elas utilizam o fato de o controle ter uma câmera infra-vermelha embutida para captar movimentos e o fato de ele também ser um dispositivo bluetooth para enviar estas informações para um programa rodando em um computador. Este programa traduz as informações captadas pela câmera em ações no computador.

Mais informações sobre os projeto de Johnny Lee podem ser encontradas aqui.

Apesar de eu não conhecer nenhuma, imagino que existam ferramentas comerciais capazes de prover estas funcionalidades. O que mais me chamou a atenção nestes casos foi a simplicidade e a maneira quase prosáica com que foi possível montar sistemas de interação relativamento complexos e capazes de obter informações mais parecidas com aquelas que o ser humano está acostumado a lidar, como movimentos naturais do corpo.

Por outro lado, também é interessante pensar nos tipos de aplicações em que estas soluções podem ser utilizadas. Fico imaginando quantos artistas plásticos que trabalham com mídias digitais ou arquitetos e engenheiros que trabalham com desenho técnico conhecem estas tecnologias e o quanto elas poderiam auxiliar o dia-a-dia deles.

Estas soluções nos aproximam cada vez mais de cenários pensados em filmes e livros de ficção científica. Um outro salto nesta direção está sendo dado pelo Projeto Natal da Microsoft (que, por sinal, é liderado por Alex Kipman, um brasileiro — veja uma entrevista dele para a revista Exame aqui). O propósito é relativamente parecido com a proposta dos projetos do Johnny lee, mas agora são utilizadas imagens reais captadas por uma câmera normal. Inicialmente pensado para o XBox 360, certamente o Projeto Natal também será extendido para PCs no futuro. O primeiro dos vídeos é o vídeo institucional de lançamento do sistema. Achei ele bem marketeiro e tenho dúvidas sobre quanto do que é mostrado já é realidade. Já o segundo me parece mais com um tipo de aplicação demo que é desenvolvida para o teste de um sistema deste tipo. De qualquer forma, tendo uma empresa como a Microsoft por trás destas campanhas de marketing, é difícil dizer qual o estágio de amadurecimento deste sistema apenas pelos vídeos na Internet. Só vendo uma demonstração real para saber mesmo.

De qualquer forma, eu não ficaria surpreso se estivermos interagindo com computadores das maneiras como foram propostas acima em poucos anos.

O que eu acho mais legal em desenvolver O Eclipse é que se a extensão que você idealizar e implementar for algo que você acha que pode ser útil para várias pessoas você tem a possibilidade de contribuir esta funcionalidade de volta para o Eclipse.

O Eclipse é um projeto de código-aberto, com uma comunidade extremamente ativa. Para contribuir sua funcionalidade para o Eclipse funciona mais ou menos como em qualquer projeto de código-aberto: é necessário um certo grau de envolvimento com a comunidade de uma forma geral, por exemplo, através da participação em listas de discussão ou fóruns; é necessário que o que você deseje contribuir seja algo que a comunidade gostaria de adicionar ao projeto; e o seu código deve ser totalmente original e isento de qualquer impedimento jurídico, por exemplo, se tiver sido distribuído pelo resultado do seu trabalho para uma empresa, é necessário que a empresa libere o código para ser contribuído. Cumpridas estas premissas básicas, é só contribuir o código!

Agora, se você está achando que este processo pode ser burocrático e demorado eu lhes digo o seguinte: eu também pensava assim. Até que após trabalhar dois anos desenvovendo plug-ins para Eclipse a minha equipe e eu conseguimos ultrapassar todas as barreiras (internas e externas, sendo que as externas às vezes são as mais fáceis) e contribuimos todo o nosso produto de volta para o Eclipse. Hoje as mais de 45.000 linhas de código do Cell IDE, um conjunto de plug-ins que facilita a programação em C/C++ para processadores Cell é parte do PTP (Parallel Tools Platform), um sub-projeto do Eclipse que adiciona à plataforma básica funcionalidades específicas para facilitar a programação em C/C++ para clusters.

Bom, é claro que este lado legal de desenvolver O Eclipse pode ser vivenciado ao se contribuir para qualquer projeto open source (do kernel do Linux ao ‘cp’, comando de cópia de arquivos em ambientes UNIX-like). O que você ganha com isso? Bom, além de reconhecimento da comunidade, você certamente ganhará experiência na leitura e entedimento de código-fonte, no desenvolvimento de projetos e na comunicação com equipes de desenvolvimento (nem sempre tão) grandes e dispersas por várias partes do planeta.

Escutamos muito as pessoas falarem em desenvolvimento no Eclipse, utilizando esta ferramenta poderosa como plataforma de desenvolvimento. Para mim o Eclipse é a melhor plataforma de desenvolvimento genérica na qual eu já trabalhei. E, certamente, é uma das melhores plataformas de desenvolvimento para Java (para mim A melhor) e C/C++ (com certeza não A melhor) que eu já usei.

Opiniões pessoais a parte, eu passei três anos, de 2006 a 2008, não apenas utilizando o Eclipse como plataforma de desenvolvimento mas também como produto final do meu trabalho. Ou seja, eu não só desenvolvi no Eclipse. Eu desenvolvi O Eclipse.

Muitas pessoas escutam falar que o Eclipse é uma plataforma extensível. Afinal de contas, se fosse diferente, certamente não teríamos os incontáveis plug-ins para Eclipse que adicionam inúmeras funcionalidades interessantes. O que talvez nem todo mundo saiba é que extender o Eclipse é muito fácil! E talvez por não saberem disso, acabam achando que é algo difícil e não se aventuram por este mundo interessante.

O melhor de tudo é que para extender o Eclipse a única coisa que você precisa é do própio Eclipse! Ou seja, a melhor ferramenta para desenvolver o Eclipse é o próprio Eclipse.

Neste artigo vou abordar o passo-a-passo de como criar um plug-in simples para o Eclipse.

Primeiramente, alguns conceitos. O Eclipse possui o que chamamos de pontos de extensão (extension points). Estes são arquivos XML que possuem configurações que definem possíveis extensões do Eclipse. A plataforma básica já fornece uma série de pontos de extensão que podem ser facilmente utilizados para extender as funcionalidades já disponíveis (por exemplo, neste mini-tutorial iremos criar um novo menu com uma ação específica). À medida em que você for ganhando mais traquejo na implementação de pontos de extensão, você vai naturalmente notar a necessidade de você mesmo criar seus próprios pontos de extensão a partir de coisas que você extendeu anteriormente da plataforma básica (espero falar disso em um post futuro).

Mas vamos ao que interessa a este tutorial. Para começar você vai precisar ter instalado uma máquina virtual Java. Sugiro as da IBM ou da Sun, já que elas funcionam muito bem com o Eclipse. Um aviso aos usuários de Linux: as máquinas virtuais que veem com as distros (GCJ ou iced-tea) em geral não funcionam corretamente e possuem bugs em funcionalidades básicas, tornando difícil ou impossível rodar o Eclipse com elas. Se você já roda o Eclipse como plataforma de desenvolvimento você certamente já possui uma máquina virtual Java instalada.

Depois é necessário instalar o Eclipse SDK. Outro aviso aos usuários Linux: também não recomendo os empacotamentos de Eclipse SDK que vem com as distros. Em geral são ligeiramentes diferentes em relação ao Eclipse distribuído pela Eclipse.org e, muitas vezes, possuem bugs que não existem na versão original.

Quando usado como plataforma de desenvolvimento para Java ou C/C++ não é necessário ter o Eclipse SDK instalado. Basta o runtime do Eclipse. Para instalar o Eclipse SDK basta certificar-se de que você baixou o pacote com o nome Eclipse SDK do site Eclipse.org ou que você tenha instalado a feature “Eclipse Project SDK” através do Update Manager do Eclipse runtime.

Bom, feito isso, siga os seguintes passos:

1) Crie um novo projeto de desenvolvimento de Plug-In para Eclipse.

1.1) Clique no menu File -> New -> Project….

1.2) Selecione a opção Plug-in Development -> Plug-in Project na janela que se abrir e clique no botão “Next”.

1.3) Dê um nome para seu projeto, por exemplo org.eclipse.test e clique no botão “Next”.

1.4) Clique no botão “Next” no próximo passo do Wizard, chamado de “Content”.

1.5) No passo de escolha de Templates, selecione o template “Hello, World”. Clique no botão “Next”.

1.6) No último passo do wizard, não altere nada e clique no botão “Finish”.

2) O Eclipse irá perguntar se você deseja alterar a Perspectiva atual para a Perspectiva de desenvolvimento de plug-ins. Clique em “Yes”.

3) O Eclipse abrirá o editor no arquivo MANIFEST.MF. Este arquivo define as características de seu plug-in como, por exemplo, de quais outros plug-ins ele depende, quais pacotes ele exporta, quais extension points ele extende, quais extension points ele provê e outras configurações. Não vou me ater a este arquivo pois ele não será realmente importante para o desenvolvimento deste caso simples.

4) Utilizando este Template “Hello, World”, você verá que o Eclipse criou uma pasta src/org.eclipse.test.actions com uma classe SampleAction.java. Abra esta classe no editor dando um duplo clique no arquivo.

5) Esta classe possui um método public void run(IAction action) que define qual ação será executada ao se clicar no menu que estamos criando. No caso deste template, a ação executada é bem simples: abre-se uma janela com uma mensagem de “Hello, Eclipse world”.

6) Para ver seu plug-in em ação numa instância de Eclipse não é necessário instalá-lo, ainda. O Eclipse provê uma funcionalidade através da qual, de dentro do Eclipse, você pode lançar um novo Eclipse que carregará os plug-ins que você está desenvolvendo no seu workspace. Para fazer isto você terá que “executar” seu plug-in de maneira semelhante ao que você já faz para suas aplicações Java ou C/C++.

6.1) Clique no menu Run -> Run Configurations….

6.2) Dê dois cliques em “Eclipse application” no lado esquerdo da janela que se abrir. O Eclipse criará um novo launcher para aplicação Eclipse que, por padrão, a incluirá os plug-ins que estão no seu workspace.

6.3) Clique no botão “Run”.

7) Um novo Eclipse será executado. Note que nele aparecerá um menu novo, que não existia na instância anterior de Eclipse, com o nome “Sample Menu”. Clique em Sample Menu -> Sample Action.

Uma janela será aberta com a frase que você definiu na classe SampleAction.java.

Parabéns! Você acaba de criar um plug-in para Eclipse ao extender o extension point que permite a adição de novas opções de menu ao Eclipse.

Um tutorial semelhante a este pode ser acessado de dentro do próprio Eclipse através das “Cheat Sheets” providas pelo Eclipse SDK. Clique em Help -> Cheat Sheets… e depois selecione a opção Plug-in Development -> Creating an Eclipse Plug-in na janela que se abrir. Selecione “Create a plug-in” na view que se abrir e siga os passos descritos na tela. Este tutorial, apesar de estar em inglês, possui uma quantidade bem legal de informações sobre como criar plug-ins para Eclipse com links explicando vários conceitos relacionados. Vale a pena!