Ferramento para União e Pdginação de PDFs, PdfMergeAndPaging

Estou com problemas de acesso ao blogger aqui da empresa onde trabalho e tive que recorrer a um site redirecionador para tanto, inclusive enviando minha senha em modo inseguro.
Vamos ao projeto, surgiu uma necessidade aqui na empresa de alguns departamentos que geram arquivos PDF a partir de várias aplicativos e necessitavam juntá-los e após paginá-lo para publicação na intranet e internet. Para resolver isto, um dos departamento fez a aquisição de uma licença do Adobe Acrobat Professional. Perfeito, sanou toda o seu problema, mas os demais departamentos ainda continuam sem solução.
Pensando nisto resolvi escrever um aplicativo para tentar auxiliar nesta tarefa, para tanto baseei este projeto no iText e acredito que tenha chegado a um uso razoável já.
Como hospedei este projeto no code.google, resolvi divulgá-lo a quem possa interessar http://pdfmergeandpaging.googlecode.com/files/launch.jnlp para instalação do aplicativo via Java Web Start e http://code.google.com/p/pdfmergeandpaging/ para acesso ao home do projeto.
Basicamente estou utilizando Netbeans 6.5 e as bibliotecas iText e ini4j.
Era isto por hora galera.

HTML: select (drop down) em cascata com MentaAjax

Finalmente acredito ter chegado a uma boa solução para controle de 3 campos select (drop down ou mesmo combobox) em cascatas. Para melhor ilustração aí vai o cenário da estrutura de dados. Tenho um catálogo de materiais, cada item deste catálogo faz parte de um subgrupo, cada subgrupo faz parte de um grupo e cada grupo faz parte de uma classe. Preciso selecionar o subgrupo a que pertence um item do catálogo e para tanto faz-se necessário: primeiro a seleção da classe, feita esta seleção o select com as grupos é preenchido; segundo faz-se a seleção do grupo e com isto o select dos subgrupos é preenchido para seleção final.
Estou desenvolvendo este catálogo em Java com mentawai para MVC. Tentei utilizar um cenário igual em que o cascateamento é feito com País, Estado e Cidade, desenvolvimento e relatado no fórum do mentawai, mas não obtive o resultado que desejava. Na verdade eu queria que ao ser feita uma nova seleção de classe, automaticamente os select com grupos e subgrupos fosse preenchidos automaticamente, sendo que o select dos grupos conteria os grupos da classe selecionada e o select dos subgrupos conteria os subgrupos do primeiro grupo da classe selecionada.
Chega de enrolação e vamos ao código!
Primeiro as configurações das actions no ApplicationManager:

       action("/manager/FormMateriais", FormMateriais.class).on(SUCCESS, fwd("/manager/formMaterial.page"));
       action("/manager/FormMateriais", FormMateriais.class, "add").on(SUCCESS, fwd("/manager/FormMateriais.mtw"));
       action("/manager/FormMateriais", FormMateriais.class, "preencheComboGrupo").ajaxOk(new JSONGenericRenderer());
       action("/manager/FormMateriais", FormMateriais.class, "preencheComboSubGrupo").ajaxOk(new JSONGenericRenderer());

Ao ser chamada URL /manager/FormMateriais.mtw, esta preenche a output com as classe, os grupos da primeira classe e os subgrupos do primeiro grupo da primeira classe. Como estou utilizando a tag html do mentawai (mtw:select) esta preenche automaticamente os select classe, grupo e subgrupo com os Maps da output.

   @Override
   public String execute() throws Exception {
       Connection conn = (Connection) input.getValue("conn");

       ClasseDAO classeDAO = new ClasseDAO(conn);
       GrupoDAO grupoDAO = new GrupoDAO(conn);
       SubGrupoDAO subGrupoDAO = new SubGrupoDAO(conn);

       output.setValue("classe", classeDAO.getMap(classeDAO.list()));
       output.setValue("grupo", grupoDAO.getMap(grupoDAO.list(classeDAO.list().get(0).getId())));
       output.setValue("subgrupo", subGrupoDAO.getMap(subGrupoDAO.list(grupoDAO.list(classeDAO.list().get(0).getId()).get(0).getSeq())));
       return SUCCESS;
   }

Por fim, meu JSP com alguns recursos de Ajax disponibilizados pelo mentawai, permitem o preenchimento dinâmico dos selects grupo e subgrupo a cada evento onclick das selects classe e grupo.

               
               
               
               

< script type="text/javascript">
    function getList(transport) {
        var response = new mtw.response(transport);
        response.replaceOptions("grupo");
    }

    function getList1(transport) {
        var response = new mtw.response(transport);
        response.replaceOptions("subgrupo");
    }

    function doRequest() {
        var req = new mtw.request();
        req.setUrl("FormMateriais.preencheComboGrupo.mtw");
        req.addParameter("idClasse", $('classe').value);
        mtw.removeOptions("grupo");
        req.onSuccess(getList);
        req.send();

        doRequest1();
    }

    function doRequest1() {
        var req1 = new mtw.request();
        req1.setUrl("FormMateriais.preencheComboSubGrupo.mtw");
        req1.addParameter("idClasse", $('classe').value);
        req1.addParameter("idGrupo", $('grupo').value);
        mtw.removeOptions("subgrupo");
        req1.onSuccess(getList1);
        req1.send();
    }
< /script>

Bom, ainda não consegui resolver o problema de fazer os preenchimentos automáticos dos selects grupo e subgrupo para outros eventos que não o onclick, na verdade isto é um problema comigo ou com o mentawai, pois não consigo definir dois eventos diferentes nas tags mtw:select, assim resolvi usar onclick em detrimento a onchange ou mesmo onblur.

Era isto por enquanto. Abraços amigos.

Que caminho seguir? Java, C++, Python ou Ruby

Esta eterna questão me toma, não consigo chegar à decisão. Quanto a Java pretendo continuar estudando-a e é certo que logo em seguida, assim que chegar meu notebook, devo iniciar um projeto J2EE pra consumo próprio. Vou utilizar, certamente, o framework MVC do ilustríssimo Sérgio, o Mentawai, que já citei anteriormente nas postagens referente ao meu TCC. Quanto à persistência ainda não defini, bom, mas vou deixar estes detalhes pra mais tarde, quando realmente iniciar o projeto.
Sempre tive muita vontade de ser um programador C, tanto é que muitas e muitas vezes implementei pequenos programinhas em C, nada avançado, mas só para poder dizer que sabia programar em C. Estou achando muito interessante o KDE4, embora eu seja, atualmente, usuário Gnome, mas não posso deixar de admitir que sempre admirei o KDE e o QT (depois que a Trolltech passou a disponibilizá-lo, também, sob GPL). Se o tempo me permitir, tentarei iniciar alguns estudos, sem muita ambição, em C++ e quero utilizar o Kdevelop, o tutorial do Antonio Larrosa (http://developer.kde.org/~larrosa/tutorial.html) e este (http://www.beginning-kdevelop-programming.co.uk/) do Andrew Ward.
Por fim, ainda paira a indecisão sobre começar os estudos em Python ou em Ruby, a inclinação está, atualmente, para o lado do Ruby por causa do Rails.
Gostaria mesmo de saber que vantagens teria o Python sobre o Ruby, pois se, afinal, eu não encontrar nenhuma, acredito que definitivamente Python não será minha opção como linguagem de "altíssimo nível".

2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 005

Vou tentar segui uma sugestão anônima para criação de frases mais curtas de agora em diante. Quem sabe assim, meus textos possam ser melhores compreendidos. Bom, mas se nem eu mesmo, às vezes, me entendo, como fazer meus leitores compreenderem-me plenamente? (Adorei a expressão "meus leitores"). ;-)
Até que enfim eu tinha conseguido superar o problemão de "adormecimento" esporádico do cluster e agora ele funcionava "a mil". Ainda havia um detalhe que não consegui resolver até o final do trabalho e vou relatá-lo resumidamente (a minha moda) para que, quem sabe, alguém possa me dizer o que estava havendo.
Um computador cliente, em uma sessão de testes, fazendo requisições por, digamos 10 minutos, nunca conseguia fazer com que o cluster (nos primeiros testes somente um computador, o primário), chegasse próximo a 100% de uso da CPU. E não era porque o cliente era fraco, pois normalmente não exigia mais de 30% de CPU do cliente neste tipo de teste, enquanto que o cluster não chegava a 80%. Cheguei até a tentar virtualização com Xen para fazer com que um computador rodasse várias instâncias servidoras tentando obter o máximo de sua performance, mas não adiantou em nada. Para ilustrar mais um pouco e tentarem compreender o problema, se eu utilizasse 2 computadores clientes, cada um ocuparia no máximo 20% de sua CPU (média) durante 10 minutos de teste e o cluster, então, passava de 80%. Se no teste fosse utilizado 3 computadores clientes, cada um também usava em média 20% da CPU, mas então o cluster já era carregado a mais de 90%. Nunca entendi isto, procurei razões, gargalos de rede ou de entrada/saída, mas não encontrei.
Estava na responsabilidade de conseguir computadores clientes, para meu cluster de 3 nós, que fossem capazes de "sugar" o máximo de sua capacidade e graças a Deus consegui isto para praticamente todos os meus teste, só um, entre diversas configurações de teste é que não consegui obter, com 3 computadores clientes, 100% de uso da CPU do cluster na configuração de 3 nós.
Até agora ainda Java parece algo pouco irrelevante para o Trabalho de Conclusão, mas lá por maio ele tornou-se peça fundamental. Como nesta época eu já tinha o cluster funcionando (até tive que refazê-lo logo após usar xen, pois consegui destruir com todos os arquivos de configuração do primário), e estava sobrando tempo para algo a mais.
Foi aí que meu orientador de TCC, Alexandre Timm, fez-me aceitar que o mais importante do meu TCC não era o cluster e sim as ferramentas para medição de performance que eu tinha iniciado como um instrumento simples para poder comparar os resultados em diversos tipos de configuração do cluster: 1 nós, 2 nós, 3 nós, entre outros detalhes, para apurar se realmente um cluster obteria alguma vantagem em relação a um computador só.
Que ótimo que este modelo de cluster trazia bons resultados, imagina se eu tivesse perdido meses pesquisando e iniciado o projeto, comprado computadores para verificar que não servia pra melhorar a performance, no máximo para alta disponibilidade, eu teria ficado muito decepcionado.
Era incrível, pois o cluster já tinha failover e failback funcionando. Era desligar o primário "na marra" que o secundário assumia suas funcões, a base de dados postgresql não ficava comprometida e somente a performance é que ficava diminuída. Colocava o primário no ar e este reassumia suas funções, atualizando em disco tudo aquilo que estava desatualizado (somente a partição da base de dados, que era a única coisa realmente mutante do cluster) era automagicamente atualizada e o cluster retomava sua capacidade máxima. Inclusive se um nó parasse de funcionar, o cluster reconhecia e se regulava.
Voltando ao Java, passei então a aprimorar todos os componentes que estava utilizando, separando-os e melhorando a troca de informações entre eles. Eu tinha então:

• uma aplicação web rodando em cada nós do cluster;
• uma aplicação cliente rodando em cada computador cliente
• uma aplicação console que coordenava todos os computadores clientes, iniciando uma sessão de teste simultaneamente e obtendo e armezanando os resultados verificados pelos clientes
• uma aplicação que chamei de gráficos para comparar resultados de testes

É tão extensa as possibilidade de configuração de "peso" por nó para um determinado tipo de processamento, que obtive resultados extraordinários entre um teste e outro, simplesmente mudando estes "pesos" (se realmente alguém estiver interessado posso disponibilizar meu TCC para isto, mas acredito que valha a pena somente para quem esta trabalhando com clusters mesmo).
Aprendi muito sobre Java, tive que usar extensivamente Thread (algo que era totalmente obscuro pra mim), e confirmei que Java é uma ótima plataforma, mesmo em intensa carga jamais "arriou", no máximo apresentou problemas que eu custei muito a saber o que era, hehehe, mas por causa de um módulo de memória que pifou e fazia a aplicação web (na verdade o tomcat), simplesmente sumir da memória.
Estava na transição entre Java 5 e Java 6, e mesmo sendo beta, utilizei Java 6 em praticamente todo o trabalho.
Algo muito engraçado que ocorria era que em testes, distante do meu laboratório, um Athlon 64 3000+ com Debian Sarge, podia processar algo como 30% a mais de requisições que um Athlon 64 3500+ com Windows XP. Este Athlon 64 3000+ era o servidor (ainda é), de banco de dados da prefeitura e o Athlon 64 3500+ era o notebook do meu colega que jamais teve intenção de se ligar ao mundo livre e simplesmente ignorava-o por não lhe fornecer as ferramentas que ele precisava. Então, por causa disto, muitas e muitas vezes "arriava-me" nele por um "simples" Athlon 64 3000+ sem bem mais poderoso, com Linux, que seu ínfimo Athlon 3500+ com ruindous.
Chegou o dia da apresentação do TCC para a banca e era, basicamente, demonstrar como fôra todo o planejamento e construção do cluster, bem como das ferramentas para medição de performance que tinham se tornado tão ou mais importante que o próprio cluster para o escopo do trabalho. Sempre tive muita dificuldade para falar em público, imagina na defesa do TCC!
Minha namorada (na época, hoje noiva. TE AMO), levou uma filmadora para o local da apresentação, mas pedia a ela para não filmar, pois saberia que dificultaria mais ainda meu rendimento. Antes da demanda, a todo momento verificava se ela não estava tentando me enrolar, mas para minha surpresa, quando iniciei a apresentação foi como se minhas vistas se fechassem a tudo, só vinha a minha cabeça parcelas do meu trabalho ancoradas por tópicos de uma apresentação do OpenOffice.org Impress preparada para isto. Consegui consumir mais que 45 minutos e eu achava que poderia falar tudo em menos de 15. Aliás, seriam somente 15 minutos de apresentação por TCC se mais do que somente eu, formando, estivesse terminando a graduação naquele semestre.
Ah! A Katy, sem que eu percebesse, fez toda a filmagem da apresentação e foi um sarro só rever minha performance. Como eu sou ruim de apresentação!
Acredito que este relato sobre meu TCC, Gnu/Linux e Java termine por aqui, a não ser que me venha a cabeças mais algumas coisas interessantes que ocorreram neste período.

2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 003

Que beleza, o cluster estava sendo construído, mas eu precisa poder testar sua capacidade de processamento e minha primeira ação neste sentido foi criar uma aplicação web para instalar no cluster. Esta aplicação web deveria ter que acessar uma base de dados para que simulasse uma aplicação real, que fizesse transações na base de dados, como consultas e gravações.
Eu já tinha resolvido iniciar estudos em Java e na época estava brincando com Mentawai (http://www.mentaframework.org) para desenvolvimentos de aplicações J2EE (este seria meu framework MVC). Antes dele estava penando estudando Struts e depois Webwork2, mas não era nada fácil produzir algo em Java e ter que declarar um monte de coisas em XML. Com Mentawai era tudo muito mais "natural" para mim, logo consegui desenvolver a aplicação web para rodar em Tomcat no cluster (já havia desistido de usar apache, porque para meu projeto, o Tomcat iria servir bem).
Beleza, a aplicação web rodando no cluster, eu acessava com Firefox, mas e como medir os tempos de processamento? Quantas requisições por segundo o cluster era capaz de processar. E se eu tivesse um cluster com 2 nós, 3 nós, ou mesmo um só computador, como eu iria obter resultados para comparação?
Antes mesmo de procurar por uma ferramenta para medição de performance, atraquei-me no desenvolvimento de uma aplicação desktop (com swing, nesta época o matisse estava me salvando, por isto optei por desenvolvê-la em Java) para disparar requisições contra o cluster e obter os tempos de cada resposta. Estava bem legal, mas para minha surpresa, o computador cliente, que estava disparando as requisições ao cluster, retornava praticamente os mesmos valores, independente de utilizar 1, 2 ou 3 computadores no cluster (certos estamos de que 1 nós não seria um cluster). Rapidamente tive a idéia de monitorar o uso de CPU de cada nó durante uma sessão de processamento e foi aí que descobri que meu notebook com processador pentium IV de 2.8GHz não seria capaz de elevar o uso de CPU, nem mesmo o nó primário (um athlon 3000+) de cluster a 100%, ou seja, o cluster estava com folga, mesmo que eu utilizasse um só nó, eu deveria ter que utilizar mais computadores clientes e aí estava um grande problema. A muito custo consegui comprar mais dois "jogos" de gabinete, placa-mae, memoria, disco rígido e processador para, juntamente com meu PC (o primário) formar o cluster. Eita projetinho mal elaborado!

2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 002

Para que eu pudesse ter balanceamento de carga e cada nós rodando um servidor web, eu precisava da base de dados disponível para cada nó o mais imediato possível. Minha idéia era de que cada nós teria uma cópia da base de dados, até mesmo para auxiliar na tarefa de alta disponibilidade. O problema era sincronizar estes dados todos. Isto levou-me a pesquisar sobre sistemas de arquivo replicados em rede, como OCFS2 e GFS, pensando que nisto meu problemas de replicação de dados estariam resolvidos, mas não foi nem perto, depois de muito pelear com GFS, passei a utilizar OCFS2 com o auxílio de um de seus desenvolvedores e consegui colocá-lo em funcionamento, mas não havia forma de conseguir fazer o mysql de um nó enxergar os dados gravados pelo mysql de outro nó, deveria ser algo relacionado a cache que o mysql faz. Voltei para o GFS, já entendendo um pouquinho de replicação de dados em rede e consegui fazâ-lo funcionar. Ah! Esqueci de dizer que eu usava Debian e faria tudo em Debian.
De tanto fuçar até que consegui fazer o mysql, às vezes, um nó enxergar os dados gravados por outro, mas tive que desabilitar tudo quanto é cache, não poderia usar transação (InnoDB) e até mesmo uns negócios de flush do disco rígido tive que configurar. Tentei até mesmo postgresql, mas depois de muito procurar, fiquei sabendo que um diretório que armazena uma base de dados não pode ser acessado por mais de um processo servidor postgresql ao mesmo tempo, ele usa umas travas e o servidor postgresql do segundo nós já não podia abrir a base.
Estava tudo errado, eu queria uma solução de balanceamento de carga que não precisasse ser vinculada a um único fornecedor de banco de dados. Em conversa com o desenvolvedor do OCFS2, este até recomendou-me utilizar uma versão do banco de dados da Oracle com suporte nativo a replicação. Mas se fosse o caso usaria o mecanismo de replicação nativo do Mysql e não era minha intenção.
Passaram-se quase dois meses de pesquisa intensa, até que resolvi que não replicaria a base de dados, todos acessariam do nó principal, o redirecionador, e por minha sorte, ao estudar sobre balanceamento de carga com LVS, "achei" o DRDB e meu problema de replicação de dados estava em partes resolvido. Embora eu pudesse somente ter uma cópia dos dados replicada em outro servidor, este era o modelo do meu cluster para alta disponibilidade, em caso de falha do redirecionador, um outro nó, previamente configurado, assumiria o papel daquele, usando os dados replicados, mas um pouco antes disto até tentei fazer com que o DRDB permitisse gravação em ambos nós, o primário e o secundário, mas não teve jeito, a versão de uso ainda não permitia que o secundário montasse a partição para escrita, somente, leitura, então abandonei de vez a idéia de a base sendo gravada por diversos nós, somente o redirecionador ou primário o faria.
A partir disto, acredito que já era março, passei a implementar LVS e DRDB, para, por fim, Heatbeat e Keepalived. Não que eu tenha terminado em março, mas sim acredito que eu já havia conseguido descobrir todos os componentes de software livre eu precisaria para poder implementar o cluster e realmente as pesquisas feitas nestes dois primeiros meses (janeiro e fevereiro/2006), foram as responsáveis pelo êxito do projeto. Estas pesquisas deveriam ter sido feitas lá em 2004, mas na época eu não estava muito a fim de passar trabalho.

2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 001

Finalmente, no final de 2004 eu havia pensando em algo para o Trabalho de Conclusão de Curso que não fosse desenvolver um sistema. Resolvi que iria enfrentar a tarefa de desenvolver um cluster, afinal, não tinha conhecimento de que alguém no campus da Ulbra tivesse elaborado trabalho parecido e eu julgava-me competente para abraçar esta tarefa utilizando somente software livre.
No início de 2005 apresentei o projeto à banca e a orientaçao do curso veio com a boa notícia de que estava aceito. A princípio, no projeto, especifiquei uma meia dúzia de requisitos para construir o cluster, acredito que eu tenha trabalhado 2 dias neste projeto, o que me fez ter certeza de que em um ou dois meses, utilizando open-mosix eu teria um cluster para rodar aplicações web rodando a milhão. Este foi meu maior erro durante o TCC.
Resolvi que não cursaria o segundo semestre de 2005 e daria início ao TCC somente em 2006, o que efetivamente ocorreu. Chegou então Janeiro de 2006 e tirei para começar a estudar, novamente, open-mosix e algumas coisas a mais que seriam necessárias para construi este cluster, ainda nem estava pesando onde arranjaria os computadores para montar este cluster.
Lia Pitanga falando dos tipos de cluster e foi então que caiu a ficha. Um cluster open-mosix não serviria para aplicações web com apache! Ele era voltado para cálculos paralelizados, utilizando bibliotecas em C para criação do programa a ser paralelizado, era um cluster do tipo de alta performance. Eu definitivamente não queria aceitar que não daria para rodar apache, bem mais rápido, com open-mosix, mas tudo que eu lia era afirmando que não trazia vantagens e que no máximo eu teria que usar um esquema de cache de memória sei lá das quantas... Bom, tive que abandonar open-mosix, o que não poderia ser diferente.
Passei então a estudar o domínio do problema, o que deveria ter feito lá em 2004 com mais vontade. Cheguei então ao tipo de cluster para balanceamento de carga e alta disponibilidade. Em termos de resultado, o de balanceamento de carga daria para mostrar em gráficos as diferenças no número de requisições concluídas pelo cluster em um terminado tempo. Mas ao mesmo tempo achei muito interessante uma solução de alta disponibilidade para um ambiente como o da Prefeitura. Pronto, estava resolvido, modifiquei um pouco a proposta e reapresentei, agora citando cluster para balanceamento de carga e alta disponibilidade. Mas isto não era nada do que eu eu iria passar ainda.

A procura e o encontro: Java

No final de 2003, o Baboo e eu criticávamos o Fabiano. Éramos colegas de faculdade naquela época. Nós defendíamos vorazmente PHP e o Fabiano o Java, com seus argumentos principais de que com PHP os projetos não eram normalmente orientados a OO e que os programadores Java usualmente ganhavam bem mais que os programadores PHP que poderiam ser encontrados em qualquer boteco.
Em meu íntimo estava disposto a continuar com PHP de toda a forma, não querendo render-me a vontade de iniciar a aprendizagem em uma nova plataforma.
Mas o destino como sempre, fez com que no final de 2004, o Fabiano já formado e mestrando na PUC viesse dar aula na disciplina de Tópicos Avançados em Sistemas de Informação I (só por curiosidade, TASI II eu havia cursado um ano antes, era pra estudarmos XML, mas acabamos estudando PHP), onde foi feito uma abordagem básica de J2EE.
Fiquei interessado e também "obrigado" a aprender J2EE e gostei. Embora pra começar um projeto Web em Java demandasse 6 horas de preparação até conseguir fazer um "Hello World!" e as declarações de todos os servlets em web.xml, achei realmente interessante, acho que muito mais por estar finalmente desenvolvendo em Java. Como tarefa para o final do semestre, cada aluno apresentou um framework diferente e coube a mim, o Struts.
Nesta mesma época, eu estava pensando em uma área de estudo para desenvolvimento do meu trabalho de conclusão e ingenuamente eu acreditava que poderia construir algo como um framework em PHP para desenvolvimento mais rápido de sistemas, sem precisar utilizar frames de HTML e que utilizasse templates como Smarty, acredito que seria algo parecido com MVC (mas mesmo quase concluindo o curso de Sistemas de Informação, jamais havia ouvido falar de MVC). Bom, após estudar e apresentar um pequeno exemplo do funcionamento de Struts vi que a tarefa de criar aquele framework em PHP estava além do meu alcance e abandonei de vez aquela idéia e, também, o PHP.
Passei então a dedicar-me ao aprendizado de Java, principalmente para aplicações desktop, mas não conseguia evoluir, porque antes do matisse era muito complicado desenvolver interfaces e eu novato, não conseguia fazer nada, ficava brincando, então com J2EE.

À procura de uma plataforma de desenvolvimento livre 003

Foi então que em 2002 pensei ter encontrado a solução, não que esta não poderia ter sido a minha solução, comecei a dedicar-me a PHP. Neste mesmo ano, Rasmus Lerdorf, o criador do PHP palestrou no FISL e fiquei encantado com a possibilidade de desenvolver para a web, pois era outro bonde que eu já estava quase perdendo, primeiro o GUI e agora a web. Comecei a produzir tudo que podia de programinhas em PHP, inclusive os que seriam mais simplesmente implementados em Delphi ou mesmo CLIPPER. Como PHP lembrava-me os tempos de CLIPPER com sua produtividade e sem precisar ficar arrastando componentes, o problema era o HTML, pois com minha enorme criatividade, meus melhores layouts seriam dignos da exclamação "Nossa que horrível!". Tirando este contratempo, produzia e produzia com PHP, sua facilidade em acessar minha base de dados em mysql (outro que sofri pra quebrar o paradigma, mas isto seria outra história).
Mas algo ainda parecia não estar certo, não me parecia correto produzir tudo para a web. E os sistemas de entrada massiva de dados que o ideal seria uma aplicação console (embora eu relutasse e sempre me "esmurrava" para acreditar que em GUI também poderia ser bom)? Como fazer uma aplicação simples e rodar em um Pentium 133 com 32MB de RAM se eu teria que instalar no computador do cliente um servidor mysql e um servidor http? Coitado de alguns clientes que tiveram que aceitar estas soluções, mas eles já não sofrem mais pois tenho certeza de que não utilizam mais aqueles programinhas que fiz (normalmente produzia de forma quase que gratuita, pois hoje eu vejo que cobrar R$ 50,00 ou R$ 100,00, ainda que em 2002 era piada, mas eu sempre aceitava que isto estava ajudando no meu desenvolvimento pessoal - e porque não?).
Mas não dava não, mysql e apache em 32 MB de RAM não dava. Volta e meia produzia novamente em Delphi, pois rodava e bem de 486 com 32MB de RAM pra cima e mais alguns aninhos se passaram.
Já em 2004 o problema de pouca RAM parecia no passado, mas eu continuava relutando em ter que instalar "trocentos" servidor só pra ter que rodar um simples programa no computador do cliente.
Desde 1997 eu já estava ouvindo falar de Java e que rodava em qualquer browser e que era totalmente orientado a objetos (depois alguns já diziam que não era totalmente, algumas coisas faltavam), mas antes de 2001/2002 eu não vislumbrava desenvolver para a web, torcia para que fosse só moda sistemas rodar em web, páginas sim, sites de e-commerce, mas não sistemas, por favor! Antes de começar a aprender C nem pensava em Java, pois diziam ser o dialeto C e ainda orientado a objetos, fora que não tinha uma IDE RAD, tipo Delphi, "sem jeito, tô fora" eu pensava, como iria produzir alguma coisa assim? Havia uma galerinha (poucas pessoas) na faculade que eram mais abastados e tinham bons computadores, em casa ou no trabalho e podia testar novas tecnologias, alguns até relatavam que estava desenvolvendo em Java usando uma IDE sei lá o quê da Symantec, só que era muito lento. Eu já tinha feito um upgrade no meu PC, agora ele era um Pentium 100 não com 16MB de RAM, já devia estar com uns 96MB, mas não tinha jeito, Java era muuuuuito lento e não tinha vontade nem de aprender, até discutia com uns colegas, mas isto já lá por 2003/2004 que o negócio mesmo era PHP, que Java não era produtivo e sei lá mais o quê (e isto que eu nunca tinha produzido nem um Hello World em Java).
Mas é a vida! Vinha um Fórum de Software Livre e dizia que C++ era o canal pra se desenvolver com QT e lá eu ia eu codificar e codificar durante uns 3 meses, depois ja era C com GTK, depois era PHP com GTK, depois já era Python. Lembro que Python foi interessante, saí da palestra achando que finalmente o mundo estava salvo, para Python tudo era objeto, inclusive um "a".upper() dava pra se fazer. Mas era tudo tão difícil, não digo aprender a linguagem, mas ser produtivo era o problema.
O pessoal do Mono, então, praticamente monopolizou um FISL e, embora olhando meio estranho por se tratar de uma implementação livre de tecnologia Microsoft, achei interessante poder ter bindings atualizados, pois PHP GTK era um caso em que não podia usar as mais recentes características do GTK. Nesta época já contava com uma pequena experiência em Java e pude notar o quanto C# (que havia sido a linguagem que eu queria adotar por contemplar de toda a capacidade do framework) era parecido com ela. Não evolui em nada com Mono, até porque não gostei da idéia de ter que usar Glade pra produzir interfaces e codificar em outro editor, não era tão produtivo quanto Delphi ou CLIPPER e definitivamente eu não iria mais programar em uma plataforma de desenvolvimento que eu tivesse que pagar para utilizá-la e Java e Mono eram gratuítas e livre respectivamente.