Acho que posso dizer sem medo de errar que na lista de dores de cabeças que meus projetos pessoais e startups me trouxeram, a questão da codificação de strings está tranquilamente entre os TOP 3. E quando eu achei que tudo nesta área estava resolvido, eis que me apareceu um novo bug do nada que me fez perder algumas horas de mal humor. Porque coisas que funcionam por meses e de repente param de funcionar sem motivo aparente em geral me tiram do sério.

O SigaSeuTime (cujo novo site acaba de estrear, se me permitem o autojabá) possui dois bots IM, GTalk e MSN, que fazem parte do conjunto de plataformas para distribuição de contéudo. Ambos os bots são escritos em Java, e a plataforma é escrita em Python. Para fazer a comunicação entre os subsistemas eu uso ou REST ou comunicação via UDP. No caso das notícias em tempo real, acabei optando por UDP para evitar pooling desnecessário. E isso funcionou perfeitamente nos últimos 6 meses: um agente se encarrega de puxar as notícias, processar, filtrar e gravar na base de dados. Outro agente lê as notícias novas e manda pros bots via UDP, para envio aos usuários online. .

Até que de repente, as mensagens começaram a aparecer tanto no MSN quanto no GTalk  com a acentuação totalmente errada. Típico resultado de strings codificadas de um jeito e interpretadas de outro (tinha que existir um jeito fácil e direto de se descobrir a codificação de uma string sem a necessidade de metadados)! Olhando para o histórico do meu SVN vi que as últimas modificações em códigos relativos aos componentes envolvidos neste processo datavam de no mínimo 3 meses.

Ou seja, só podia ser culpa do meu servidor, ou do alinhamento planetário, ou então do Bush! Não não…a culpa, obviamente era minha. Sempre é, por mais que a gente lute contra isso.

A causa do problema estava em um script SHELL que eu criei recentemente cujo objetivo é de reiniciar os bots em caso de falha de comunicação com os servidores. Até então, o processo de reboot era manual, feito por mim mesmo via shell SSH, e a função deste script é de automatizar o processo, matando e executando novamente o bot.

Inofensivo certo? Nem tanto. O script é executado periódicamente pelo crontab do sistema operacional, e foi aí que o problema nasceu: as variáveis de ambiente do cronjob são diferentes das variáveis de ambiente do SHELL SSH, e em particular o segundo possui a variável LANG=en_us.UTF-8, que é justamente a codificação usada internamente pelo sistema. Vivendo e aprendendo: isto influi diretamente na JRE, e a falta da variável fez com que o sistema assumisse outra codificação (provavelmente ISO Latin 1). A solução foi exportar a variável no meu script.

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!

Eu não consigo entender como, até hoje, ainda é possível que eu tenha problemas com coisas simples no Linux como, por exemplo, o c-cedilha.

Como já disse em posts anteriores, eu uso bastante Fedora com Gnome por questões profissionais e, até hoje, eu nunca consegui instalar um Fedora que viesse com o c-cedilha funcionando “corretamente” out-of-the-box no Gnome com as configurações de linguagem e teclado que eu uso (sistema em inglês e teclado US com deadkeys). Pelo menos não do Fedora 4 ao Fedora 10, que foram os que eu usei. Eu não me incomodava muito com isso porque, depois de um tempo, acabei me acostumando a editar na mão o arquivo /etc/gtk-2.0/i386-redhat-linux-gnu/gtk.immodules adicionando o trecho em vermelho na linha abaixo: "/usr/lib/gtk-2.0/2.10.0/immodules/im-cedilla.so" "cedilla" "Cedilla" "gtk20" "/usr/share/locale" "az:ca:co:fr:gv:oc:pt:sq:tr:wa:en" como está “documentado” em vários fóruns na Internet. Eu vivia em paz com isso. A única coisa relativamente chata era ter que editar o arquivo toda vez que o gtk fosse atualizado. Como eu atualizo diariamente a minha máquina, isso acabava acontecendo vez ou outra. Mas, como eu disse, eu estava em paz com este overhead.

O único problema que eu tinha era o Skype. O Skype é feito em cima do Qt, que é uma biblioteca do KDE e, por isso, não obedece as configurações do Gnome. Lá, toda vez que eu digitava “acento-agudo-c” saia ‘ć’. Mas, tudo bem, eu nem falo com tanta gente via chat pelo Skype mesmo. Dava pra levar.

Até que, este ano, uma nova necessidade surgiu: eu precisei começar a escrever mais ativamente textos em Latex. Bom, acho que já exprimi meu descontentamento com soluções derivadas do Latex neste blog mas este não é o assunto deste post. Digamos que não havia muita escolha, então eu fui em frente. No entanto, depois de conversar com algumas pessoas, o melhor software para edição de arquivos .tex que me apareceu até agora foi o Kile. O problema é que o Kile também faz parte do KDE e, portanto, não segue a configuração de c-cedilha do Gnome. Mas, agora, isso passava a ser um problema ingerenciável. Afinal de contas, como escrever textos científicos, em português, sem c-cedilha?!

<flame>

Por favor, caso alguém saiba, ajude-me a esclarecer esta dúvida: Quem é que, por Deus, possui um ‘c’ com acento agudo em sua língua? ć?! Qual é o som disso?! Dúvido que mais povos usem ć do que ç para eles alterarem este comportamento no Linux. Antigamente (há uns 7 anos) não existia ‘ć’, porque agora existe? Me fala ai quem é que foi que alterou isso!

</flame>

Tentei resolver este “probleminha” de várias formas. No meio do caminho eu até descobri que <Alt+c> no Linux produz c-cedilha também. Quer dizer, apenas quando se usa o <Alt> direito (<Alt Gr> se não me engano), mas já é alguma coisa. Tá aí: até então eu nem sabia porque em alguns teclados os <Alt> tinham nomes ligeiramente diferentes. Afinal, porque nomes diferentes para a mesma tecla? Como eu era ingênuo…

Mas eu me recusava a me adaptar ao sistema. O sistema tinha que se adaptar a mim! Claro!

Bom, depois de ler vários fóruns, depois de tentar várias coisas, depois de perder a paciência inúmeras vezes… eu desisti. E passei a pensar que, se existem várias pessoas que adoram Mac OS e se submetem a utilizar seqüências exdrúxulas de caracteres para ter coisas como c-cedilha, eu também poderia me adaptar ao <Alt+c>. Não gosto de me nivelar por baixo, mas fazer o que? Ah, antes que alguém me jogue pedras… nivelar por baixo neste caso. Eu nem mesmo uso ou usei Mac OS, mas já li em alguns lugares no passado que esta limitação existia em teclados da Apple. E isso para mim era um ultraje para um sistema que todos diziam ser amigável.

Bom, o fato é que pouco mais de dois meses depois de me rebaixar a aceitar o <Alt+c> como solução para o c-cedilha eu nem mesmo percebo mais. Estou totalmente adaptado. Sem problemas. E sem ter que editar o arquivo de configuração do gtk toda vez que ele é atualizado.

Mas, apesar de já estar adaptado e de provavelmente não querer mais voltar atrás, eu ainda digo: no Windows eu nunca tive este problema.

Nota: Engraçado, nos últimos tempos eu ando falando mal do Linux em diversos posts. Antes que algumas pessoas achem que eu não goste do Linux, tenho que dizer que, muito pelo contrário, o Linux é o sistema operacional onde eu me sinto mais a vontade. Porém isso não quer dizer que eu não veja defeitos nele. Aliás, provavelmente eu vejo muito mais problemas nele do que em outros sistemas operacionais porque simplesmente eu passo quase que a totalidade do meu tempo na frente de computadores rodando Linux devido ao meu trabalho.