Hoje, porém, parte do meu dia (eletrizante, até) envolveu uma atividade boba, revelou um insight genial:

No Linux, eu precisava desenhar um diagrama de blocos. Tentei com InkScape, e funcionava, com um detalhe: Sendo um editor de SVG, eu precisava criar 2 objetos (Retângulo e Texto), selecionar ambos, alinhar os centros e agrupá-los. Resumindo: Contraproducente.

Depois do InkScape, tentei Kivio – Que ao contrário do original, não possui um único stensil de retângulo. Game Over, K.

Tentei outro no Ubuntu: Karbon (antigamente, KIllustrator). Mesmo sintoma do Inkscape.

Procurando várias alternativas, li em algum lugar que o OpenOffice permitia.

E fez bem e consegui concluir os diagramas.

Mais tarde, refletindo com um colega de trabalho, permitimos um padrão:

• O Java surgiu como basicamente um GIF Animado;
• O NetBeans é ótimo quando o assunto se limita apenas a Swing
• JavaFX é uma segunda tentativa da Sun reaver a posição de melhor animador de GIF depois do Flash
• OpenOffice Draw me permitiu desenhar como eu queria

Em suma: A Sun faz software sério, até (Java, JXTA, OpenSolaris), mas ela queria mesmo era achar-se a Adobe. Só pode.

A História da Web: Relembrar é Entender

Acompanhar a Web envolve um pouco da própria natureza da tecnologia: Novas demandas, novos desafios, e a constante necessidade de manter tudo alinhado com o que já existia, oferecendo recursos que originalmente sequer foram imaginados. Basicamente, as principais tecnologias que compõem a Web, entre 1990 a 2000, surgiram da necessidade de resolver os seguintes problemas:

Agora repare esta tabela com um olhar crítico: Dentro da visão original da Web, ela buscava apenas ser um repositório online de documentos, o que basicamente envolve HTTP e HTML. Ou seja, apenas o primeiro item da lista.

Todas estas necessidades transformaram a mesma em um ambiente dinâmico de troca de informações. Os documentos não eram mais arquivos em uma pasta: Tornaram-se registros complexos em grandes bancos de dados, constantemente acessados e modificados.

A solução Java, àquiela época, eram os Servlets, que buscavam apenas a geração de conteúdo dinâmico. Ela se situa no tempo um pouco depois do conteúdo rico na linha do tempo. Era uma solução adequada? Bem, não muito, mas o Java Server Pages, em 1998, ajudou a aliviar e torná-la mais agradável.

Mas acompanhando esta corrida, perceba que surgiram requisitos implícitos: Bancos de Dados, Logs, Gerência de Concorrência, Pooling de Recursos. Performance e Elegância.

Complexidade

Esta complexidade minou inicialmente o poder do Java. As soluções saiam, mas jamais dentro de padrões aceitáveis de performance. A Lei de Moore ajudou e hoje Java está entre as plataformas mais adequadas em termos de performance, e relação custo-benefício adequadas a maioria das corporações.

Perceba a ressalva acima: Corporações. Ela ainda estava – e ainda está – inacessível a maioria dos desenvolvedores. Desenvolver em casa e publicar na web uma aplicação Java envolve um pouco de esforço em achar soluções de hospedagem, devido a natureza do negócio de hospedagem.

Em paralelo, ambientes como Perl e PHP trouxeram uma outra visão: Ambientes Interpretados, leves, com valores diferentes do que o público-alvo do java buscava. Isto gerou uma impedância entre os ambientes que até hoje persiste: A maioria dos ambientes de hospedagem é capaz de rodar Perl e PHP, mas não Java. Isto criou uma cultura e uma divisão: Programadores PHP acham Java Complexo demais, e Programadores Java consideram PHP inadequado para fazer aplicações dentro das necessidades da sua empresa.

AOP, IOC, DI e ORM: Abordando os Problemas sob outro Ponto de Vista

Estamos em 2004. Nesta época, as soluções Java já estavam sendo questionadas quanto a sua capacidade de manterem-se adequadas aos requisitos modernos. O AOP criou um novo paradigma de programação, mas o conceito de Injeção de Dependências e Inversão de Controle, popularizados pelo Spring, e o de Mapeamento Objeto-Relational (Hibernate) mostraram que desenvolver em Java era possível – apenas não estavam sendo feito de uma forma efetiva.

Em paralelo, o Struts tornava-se norma, enquanto buscava-se ao JSF a agilidade e leveza que o ASP.NET trazia.

Ruby on Rails – Uma Nova Abordagem (e Valores)

O Ruby on Rails é um divisor de águas: Com um novo jogo de valores (YAGNI, DRI), ele buscou a simplicidade e jogou outro requisito na roda: Interatividade. Muitos (bons) programadores Java, Perl, Python e PHP foram para o Ruby on Rails.

Web 2.0

Em paralelo, cunhou-se o termo “Web 2.0”. Redes, Ajax, Mashups. Novos requisitos na roda.

Recomeçando

Neste ponto, haviam 3 grandes problemas:

• Haviam basicamente 2 tribos de desenvolvedores Web: Os programadores de Scripting (PHP/Perl/Python), com ambientes interpretados, dinâmicos e leves, e os programadores Java, compilados e exigindo mais memória;
• As soluções interpretadas forneciam aplicações com grande demanda (CMS), enquanto as Java eram orientadas ao ambiente enterprise. Porém, isso não impedia que soluções de CMS open source fossem viáveis para corporações, mas o temor natural de integrar uma aplicação PHP com uma base de dados manipulada por uma aplicação Java inibia a sua adoção, resultando em vários CMS Java de uso interno – causando diariamente a reinvenção da roda nas empresas;
• Haviam outras maneiras de se fazer as coisas, e mais atrativas que em Java;

No ambiente Java, criou-se um claro conflito de valores: Como produzir mais e ao mesmo tempo, integrar com o que eu tenho?

Esta proposta foi a premissa para a IBM inaugurar o Project Zero.

O Conceito:

O Project Zero busca trazer leveza, reuso, simplicidade e agilidade para o desenvolvimento web. As seguintes premissas foram adotadas:

• O Java permite o uso de linguagens Interpretadas;
• O Ambiente Servlet/JSP é complexo, e isto causa problemas;
• O conceito dos Archives J2EE – EAR, WAR, RAR não provê a reusabilidade necessária para as aplicações, trazendo retrabalho;
• O ambiente deve ser flexível, permitindo que vários meios sejam usados para desenvolver um website;
• O Open Source é uma realidade, e não pode ser ignorado;

Desta forma, a proposta do Zero procura englobar estes fatores em uma solução onde:

• O open source seja uma realidade, e que a equipe interaja com a comunidade buscando uma solução não apenas com massa crítica, mas focada em um objetivo comum;
• Linguagens como Groovy e PHP possam integrar-se com o Java;
• O reuso de aplicações Web seja uma coisa possível
• O desenvolvimento pode ser feito a partir de um runtime pequeno (2MB), podendo ser feito pela linha de comando, IDE (Eclipse), ou até pelo Browser (AppBuilder);
• As abstrações de acesso a dados (arquivos locais e remotos, e-mail, e Web) sejam vistos como recursos REST, abstraindo a complexidade de uma forma homogênea

O Zero possui um website, com blog, forum, issue tracking, área de desenvolvimento, downloads e documentação. Tudo rodando no runtime do Zero, e mantido pela equipe do Zero.

Aplicações:

O meu tcc foi feito no Zero. Ambora me arrependa de ter tido uma abordagem mais monolítica (evitando o PHP e Groovy), comparar a sua performance (Spring + Hibernate) contra um servidor J2EE equivalente demonstrou uma performance superior. Lembra quando falei de um runtime leve? Pois então.

Outro ponto forte é integração: Vamos supor que você possui na intranet um portal MediaWiki, e gostaria de integrar a sua autenticação com algum sistema proprietário da empresa. Ou o seu blog (em WordPress) necessita de alguma integração com o seu CMS Java? Pois – mesmo sendo PHP, o Zero integra com eles de uma forma genial.

E o sMash?

Ah sim, o sMash é a versão comercial do Zero, e é disponível pela IBM. Mas a mesma é baseada no Zero e na sua comunidade.

Concluindo

Então fica o convite: Veja os links acima e julgue se a Web não precisa de um curto-circuito. :)

Ok, now that zero.firephp is here, its time to dissect ProjectZero itself. It was not pleasant to deal with the ivy files, so lets get started before I remember how painful it was to deal with a cheap M2 rip-off.

Java Logging 101: The History

(Skip to the next section if you already know about this)

In the end, there was System.out. And this was good.

People then started to wonder that if would be helpful to separate logging statement from application output. Thus, Unix programmers quickly rushed to System.err, already in the knowledge it was a safe harbor. So now people could enable and disable logging. And that was good as well.

However, people started to notice that when logging was on, performance was down while copious amounts of logging data were written as well. So, Java people borrowed the concept of Logging Levels and started put simple statements to test before logging.

Then, people wanted to have the ability to save output into a file. Perhaps for daemons, or perhaps just to keep a copy handy to look and compare with other. Thus, the logging flags to file output were born.

Then, Ceki Gülcü (aka “The God of Logging ”) came and thought it was a good idea to mix the hierarchy java uses in the package system, mix levels, analyze and came up with Log4J. That was excellent, and several other frameworks were made after his one.

Soon, a company with the Stock Symbol “JAVA” on NASDAQ thought it would be good to bless. What a mess (it rhymed!)… The java.util.logging package was born, and this was not good, culminating in flame wars (vi-versus-emacs-style) in Apachia, a small micronation on the internets.

The overlords at commonia, a small county within Apachia , in an attempt to restore peace and ensure Apachia’s economical growth, devised commons-logging, an ill-fated that while good in nature (trying to automagically bridge logging requests between log4j and java.util.logging), in truth created another layer of abstraction which is still useful today, but creating a third logging API which also brought some nasty classloading issues.

Ceki Gülcü left apache, and log4j 1.3 was soon left deprecated. 2.0 is said to be still in the works. Meanwhile, Ceki came back and revised the concepts between commons-logging and log4j, creating slf4j and logback, respectively, trying to narrow the gap and bring his vision back to the world. It also includes libraries to bridge java.util.logging and plug-in replacements for log4j as well as commons-logging.

In the end, we have 5 apis, all of them completely different.

Oh god… I miss System.out.

Zero

Zero uses java.util.logging. Being a good citizen of the Java World, seems fine. But if you want to use logback, its possible. In particular, download this file, unpack and keep going, as I will outline the steps required to enable logback and, as a bonus, see zero logging under Lilith, a handy logging viewer for logback.

Step #1: Declare the Dependencies

Take the enclosed ivy.xml. Merge the section outlined below into your ivy.xml:

You’re inserting the APIs required slf4j  (transitively, from jul-to-slf4j), as well as logback-classic (which also includes core). However, you’re excluding some dependencies which are not needed for logback. Change them if you need (specially janino).

Step #2: Declare the java.util.logging Bridge

Simply copy the contents from logging.properties into your project.

Step #3: Modify zero.config as you need

In particular, the /config/logging/levels setting. The one declared is set as the root appender. But the syntax is “logger” : “level”, where you put the desired logging levels.

The one declared in the file is pretty verbose, which may be undesirable. I use those settings:

/config/logging/levels += {
  "*" : "ALL",
  "zero.network" : "OFF",
  "zero.core.context.zones.UserZoneHandler" : "INFO"
}

Step #4: Logback

Declare a logback.xml file. The enclosed one should work with lilith. You can also use logback’s Eclipse Plug-In instead.

Step #5: Lilith

Open, Unpack, Run.

Step #6: The result

Here is the result, in all of its glory!

Beyond logback and java.util.logging: commons-logging and log4j

You can also declare the compatible counterparts for integrating commons-logging and log4j into the slf4j/logback combo as well. Check the slf4j web site for more information.

I’ve written some notes on making JXME work, as well as making it work under Java SE as well.

Bearing in mind I’m not your best JXTA/CLDC/JSE source, feel free to take a look. Thank you. :)

Piorou quando diz que para programar não é preciso inspiração. Isso é verdade se você for um macaco que escreve código, mas para quem vai um pouco além disso, programar é muito de inspiração (além de concentração). E convenhamos que inspiração olhando apenas para IDE não é exatamente fácil de alcançar, por isso eu defendo que dispersar os pensamentos as vezes é benéfico para quem está programando.

O que eu penso? Bem, penso que superestimamos a criatividade. Semestre passado, me dediquei a repensar a maneira com a qual eu lidava com os meus processos criativos. Particularmente, produzir trabalhos pra faculdade e entregar código. Não preciso descrever toda a minha produção semestre passado, mas posso sumarizar: Foi imensa.

Mas e afinal, o que ela teve de tão milagroso ou ímpar para justificar este meu post? Método. A Criatividade em si, é paradoxal: Nada realmente é original atualmente, e tudo vem de idéias herdadas anteriormente, apenas com pequenas digressões em cima da anterior. Logo, o chave neste processo criativo, na minha opinião, está em compreender todas as variáveis envolvidas, decidir quais realmente importam, e aonde mexer, à partir de um modelo original.

Soa familiar? É exatamente este a origem dos Design Patterns. Mas não se limita a isso: Parte chave de um processo criativo envolve em constantemente aumentar o seu vocabulário de idiomas. E quanto a isto, ler códigos-fonte e aprender novas abstrações e implementações é, sem dúvida, o segredo de um código rápido, elegante, curto, e de sucesso.

Horários Ajudam: Na minha experiência, estabelecer um horário e criar disciplina ajudou, na medida que eu condicionava o cérebro a trabalhar apenas naquele momento. Eu desplugava, e era o inconsciente que me dava dicas, orientando quanto ao que seria necessário fazer. Lembre-se: Você não precisa saber o caminho aonde chegar lá (mapa / bussóla), quando você pode ter um conjunto de pontos a serem atingidos. Eis porque sempre chegamos tendo apenas a relação de pontos a serem atingidos. Cognição é a chave.

Em tempo: No meu caso do semestre passado, mapas mentais e notas (organizadas ao mesmo tempo usando o OneNote, OnFolio, WikidPad, Trac, e dokuwiki, de acordo com o contexto) foram ferramentas de um valor incalculável. Mas não esqueça: A ferramenta não é nada sem o domínio do processo. E, portanto, a disciplina. 

Eu não nego que sou fã incondicional do Eclipse em Java. A facilidade de navegar e depurar programas é, de longe, a feature que eu mais sou fanático nele. Então, seguem três screencasts, para que você possa aprender como navegar pela interface, pelo código, e como depurar:

Obs: Eu parto da premissa que você instalou o Eclipse e o JDK. :)

Parte 1: Navegando pela Interface

Parte 2: Navegando pelo Fonte

Parte 3: Debugging

Sou um dos integrantes da Sonatype, uma startup envolvendo as figuras chave envolvidas no Maven 2. Se você não conhece o Maven, então acho que compensa você dar uma visitada em http://maven.apache.org/.

Após alguns meses de trabalho, finalmente fomos autorizados a revelar o lançamento da Sonatype. Uma boa introdução é o post do Andrew Williams e o do Jason Van Zyl.

Por hora, é só. Continuem ligados.

Powered by ScribeFire.

<cobalt60> Not really. The overrall idea is to be based off the Profile being used
<cobalt60> The Real pocketserver will use it, for sure :))
<cobalt60> If you want to see the gory details, jump to pocketserver-bootstrap's pom. You'll be scared :)
<yart> hehe, just trying first to start it and see what it can do
<yart> started mnv install - junit.framework.AssertionFailedError: No tests found in org.modafocas.pocketserver.m2.PocketServerMojoTest
<cobalt60> It won't work, really
<cobalt60> just look at the pom, you'll really be scared :)
<yart> uhuhuhuhuh
<cobalt60> I told you! I told you! I told you!
<cobalt60> (mind if I blog this tiny snippet? :))
<yart> maybe not even think to try :)
<yart> Just aks later the questions about the plexus when I will have :)
<cobalt60> this pom is a rarity :)
<cobalt60> It asks antrun which in turn asks maven tasks for ant (thus embedding maven within maven), but after having another bootstrap script written by a groovy ant task :)

No meu entretenimento atual (breve a ser apresentado ao grande público – stay tuned!), um detalhe me chamou a atenção: O quanto realmente perdemos de espaço, em aplicações java. E o quanto ainda temos que aprender (a despeito de inúmeras soluções de gerência integrada de artefatos e dependências encontradas por aí).

Ok, antes disso, um prólogo: Parte da idéia do meu projeto é demonstrar a viabilidade técnica do que eu chamo de aplicações pervasivas. Sabe aquele programinha útil que você sempre mantém no seu pendrive ou CD? Então, isto é um nicho interessantíssimo.

Na maioria absoluta dos casos, as aplicações que empacotam tem uma característica de executáveis desktop. E porque não aplicações web? Bem, isto envolve a necessidade de pensar sobre as seguintes coisas:

• Aonde persistir os dados? No disco rígido, na mídia móvel, em rede, ou em lugar algum?
• Como integrar os zilhões de dependências de uma pilha Web necessita, de forma portável? Isto é, como consigo empacotar o servidor, seus logs, sua área de comunicação inter-processo, e seus módulos nativos para outras linguagens?
• Além disso, será que cabe neste espaço disponível?

Com relação aos isso, decidi basear a solução nas seguintes premissas

• Uso de um bom container genérico de componentes, permitindo a inclusão e a exclusão de features através de componentes;

Assim, com este container, todos os aspectos ficam gerenciáveis a partir de descritores. Uma nova necessidade, um novo componente. E assim a solução se ajusta.

Que tipos de abstrações são necessárias? As principais são: Serviços de Persistência (RDBMS, FileSystem, Configuração, Propriedades), Serviços de Conectividade (SSH, HTTP, SMTP), e Serviços de Localização e Publicação de Recursos (LiveTribe, Bonjour, Container), Logging, Cache, entre outros. Em suma: Tudo aquilo que, em um ambiente de servidor, é tido como de facto, fica sujeito a questionamentos. Como gosto e questionar, acho que a abordagem é válida.

A partir deste container, permitir que os diversos aspectos (storage, logging, IPC, JNI) sejam abstraídos conforme a disponibilização destes componentes;

• Fatorar a questão do storage

Minhas propriedades podem ficar num lugar (persistido na memória, carregado via HTTP, serializado via SFTP), a base em outro (Embedded, ou via um Tunnel SSH), e a aplicação pode continuar no pendrive. Porque não, portanto, permitir que sejam criadas “Zonas” de Storage, como componentes, e disponíveis para os outros serviços? No caso particular, isto é feito através do commons-vfs.

• Gerência de Dependência (ainda indefinido – mantenha-se alerta!)

Este conceito é relativamente novo, mas popularizado por idéias como o Maven (particularmente, o Maven 2), Transit, e agora, o Ivy. Consiste em gerenciar quais classes devem ser carregadas para atender as necessidades de outra e, além disso, permitir a sua resolução dinâmica através de repositórios). Ainda não cheguei a um consenso sobre a isto.

• Empacotamento de Aplicações Java usando técnicas agressivas de otimização de espaço, ou, empacotamento de forma clássica (arquivo zip);

Já ouviu falar no Pack200? Bem, vamos a alguns números, relativos a um stub de carga/resolução de artefatos mínimo para o pocketserver:

Arquivo .jar, sem a inclusão das dependências:

-rw-r–r– 1 aldrin aldrin    8150 2006-12-15 12:05 pocketserver-bootstrap-0.0.1-SNAPSHOT.jar

Nada mal, ok? Aplicando o Jar Jar Links (não esse, mas esse), eu consigo fazer com que as dependências sejam embutidas como um subpacote do pacote principal. Resultado? Isto:

-rw-r–r– 1 aldrin aldrin 3290958 2006-12-15 12:05 pocketserver-bootstrap-0.0.1-SNAPSHOT-full.jar

3.3 Mib? Não era 8K? Era… Ok, vamos refazer o jar, porém aplicando alguma filtragem, e excluindo pacotes que serão desnecessários:

-rw-r–r– 1 aldrin aldrin 1182446 2006-12-15 12:26 pocketserver-bootstrap-standalone-0.0.1-SNAPSHOT.jar

Melhorou. Agora, pack200 para o tiro de misericórdia. Vou pular os detalhes (exige uma explicação sobre compressão lossy, teoria da informação, e compressão/arquivamento). Mas, se queres uma boa noção, ele é uma compressão lossy (estilo .jpg e .mp3, aonde a descompactação não é necessariamente fiel ao arquivo de origem), alinhado com a lógica de compressão após arquivo (i.e., “-Porque meu .tar.gz é menor que o meu .zip”):

-rw-r–r– 1 aldrin aldrin  184475 2006-12-15 12:26 pocketserver-bootstrap-0.0.1-SNAPSHOT-optimized-full.pack.gz

Mas pera, não é um jar. Sim, com razão. O pack200 foi feito para ser usado basicamente pelo JNLP (i.e., Java WebStart). Porém, com alguns ajustes (em breve – caaaalma!), meu módulo de Pack200 pra Jar para o commons-vfs deve reproduzir o efeito desejado). Sem perda de performance, um ganho de mais de 20x em relação ao primeiro jar completo.

E aí fica a dúvida? Será que estamos preparados para isso?

No Contexto: Como troubleshooting é uma tarefa corriqueira, mas os 95% não percebem, e como otimizar o processo de identificação / resolução de problemas. Anteriormente, um e-mail de despedida alertando que o msn do júlio não é google.

Aldrin Leal said:
Taí, cria um modo psicoterapeuta (estilo M-x Doctor do emacs) como bot do MSN, e que também avalie potenciais respostas no google. se depois de 3 frases o mesmo hit aparecer, ele sugere conferir no google
Julio said:
hehehe boa
Aldrin Leal said:
http://www.alicebot.org/
Aldrin Leal said:
http://www.robotinvaders.com/
Julio says (23:36):
po manero
Aldrin Leal says (23:36):
Égua, curti. Os caras tem XML pra alimentar os bots.
Aldrin Leal says (23:36):
VAMO FAZER UM ALDRINLEALBOT AGORA!
Aldrin Leal says (23:36):
(posso blogar?)
Julio says (23:36):
nem
Julio says (23:36):
eu vou pra farra
Julio says (23:36):
pode blogar sim
Julio says (23:36):
tira o nem e bota vamos la so tu
Julio says (23:36):
ahehae

Lately, I´ve refactoring a very specific section on my job’s internal information system: Reporting. But first, a small background:

I parachute-landed at my current employer’s project, as a refactoring/rescue measure. As a solution, I chose key issues to deal with, mostly related to SCM and System Management (e.g., Administrivia). In geek-ese, this means subversion, trac, log4j, maven, more great stuff from Apache Jakarta, and some other great ones from the haus, and sourceforge, objectweb, and IBM Eclipse Foundation. Before, there were only, Hibernate, jUnit and Struts.

Apart from the framework and build environment department, my key goals was to agressively refactor key parts of system. Testing stuff, Hibernate code, SQL handling, and the usual code sniffing cycle (find some random snippet. Smells bad? Think, find similar ocurrences, plan, concept-test, document and deploy a solution. Rinse and repeat). And yes, it works well.

On the improvement room, I also manage some of the operational aspects. We have some schweet tools for improving our ability to prevent some and react to issues as they come, and we’re still planning for more.

Now that you got a glimpse of my project setup, perhaps you might think: Damnit, looks a nightmare to manage. Of course, sometimes the integration breaks. I keep a policy of, before discarding something, grok at the sources, trying to solve’em myself and documented when needed. But overrall, it hasn’t been very hard. Except for the usual reluctancy of adopting a new framework (the infamous NIH symdrome, more on this soon), and my usual answer: to learn to write good code, is to know how to read good code.

BTW, time for a quick Maven-and-Eclipse Tip: Do you need to read your project dependencies source code? Say, for a given artifact in ~/.maven/repository/groupId/jars/artifactId-version.jar (M1, of course), their source code location always gets overriden whenever you do a eclipse:generate-classpath goal, right? Yes, unless you place the zip source code as ~/.maven/repository/groupId/src/artifactId-version.zip. The eclipse plugin expects this form in order to hook’em up correctly. Never mind about setting it manually again!

Back to the NIH stuff. As an afterthought, now I am clearly convinced that, unless that’s core stuff, you can safely borrow from the OSS community.

One of the most underlooked components is our document engine. As a government institution, we have to issue documents of all sorts and purposes. In a structural side, they’re simply servlets which extend from a abstract and utility class which implements all the features they need to handle.

Internal users need to change some documents before to sign and ship to customers, so we resorted to the RTF file format. In practise, it’s easier for them for manually set page-breaks and add minor corrections. We ask them to turn on change tracking and send us a copy, just to correct minor issues and to inspect the need to alter records on our database on a manual basis.

Lately, I’ve had been assigned the task to generate some reports. Remember when I said underlooked? Well, welcome to my current karma payables assignment: The reporting system uses iText for the bulk of its document-generation needs. In a nutshell, iText generates html, rtf, pdf, and a internal Xml format, suitable regeneration with some command-line tools. On an use-case basis, creating a Document with iText looks a lot like dealing with Swing/AWT stuff: You create small instances, plug’em together. On an internal basis, iText *DOES NOT* stores the Document data internally like a DOM Tree. Instead, it relies on their Listeners which, say, map a given Paragraph to a RTF internal structure which gets dumped when the document is set as finished.

If you didn’t use/remember Swing back in the 90’s, pretend you wrote swing applications without a GUI. Forget Matisse, Netbeans, and VE. Such a bad thought, eh? But, apart from Form initialization stuff, and perhaps some Event Handling, it was nice. But you always end up thinking about some way to delegate it to something a bit easier.

Lets make it worse: Pretend you need to maintain a enterprise-wide application with lots of different swing forms. Do yes scare you? God yes. Lots of small, tiny objects tied together waiting for you to break upon a minimal change? You bet.

It became personal, then I decided to do a little research, trying to find suitable ways to work around the need to maintain a java codebase for the sole purpose of document generation. Say, looks easier to manage a velocity template file, or manipulate as a tree.

On this process,  I ended up looking a  lot at iText code. From a developers’ viewpoint, it lacks enough docs (apart from the tutorial and javadocs), completely lacks tests, and its source is a complete mess (multiple constructors point to a single one, which in turns calls its super constructor. Such a hard to decide which one is better to call). To make it worse, accessors didn’t even follow the standard naming conventions. They’re really not your standard POJO.

Resorting to B plan: I decided to completely ignore their XML interface, and stuck at asm for implementing instrumentation was a basis for tracing their calls. asm is awesome, but not for beginners who needs its real soon now. However, it was a nice experience to deal with: Their event-based mechanism really lets you think how, sometimes, small and minimalistic is beautiful.

B Plan, reloaded: Obcessed with the instrumentation idea, I resorted to the man’s best know log generator: AspectJ. And it (kinda worked). I mean, now I have an small aspect which yields java code suitable for inserting into a java file which, in turn, yields the very same document which was advised by the aspect.

(Mental Note: The idea of capturing events on a class basis isn’t very new but, surprisingly, it looks there’s no real thing to play with. There’s a really bright and colorful rainbow out there to the ones who follow it and came up with an Abstract Aspect to let you track how a given codebase invokes/uses another)

I consider it a hack, but I’ll let you reproduce my weekend lab experiment (under the assumption you’re a Eclipse 3.2 user):

1) First, download iText’s source code, and install AJDT. Also, download the binaries jarfiles for log4j and commons-lang and commons-logging.
2) Create a project, import/unpack the source code and enable AspectJ support. Link the dependencies together with the project.
3) Create com.lowagie.text.Trace.aj aspect [link] and com.lowagie.text.TraceDecorator.java [link]
4) In the root directory, create a minimal log4j.xml like this one [link]
5) Create another project, linking to iText’s one outlined in step 2. Create a small test harness, like the ones from the iText Tutorial. But be careful, as some might lead you into problems…
6) Fire up your harness. And check trace.log (you used my log4j.xml from step 4, right? :])
7) Paste up the contents from trace.log into a new classfile. However, insert the following snippet just after your Document() constructor:

        FileOutputStream os = new FileOutputStream(“rtfDoc.rtf”, false);
        com.lowagie.text.rtf.RtfWriter2.getInstance(obj24561483, os);

Replace obj24561483 with your own object instance symbol. On the end, call close():

        java.io.FileOutputStream os = new java.io.FileOutputStream(“rtfDoc.rtf”, false);

There should be some minor issues. Remember, this is not a production-ready build, but a quick proof-of-concept.

As you might conclude, there’s a small room for improvement, like:
- Aspect Reusability: Why not generalize and build a framework for black box reverse engineering?
- TraceDecorator refactoring: This is my current goal. To refactor TraceDecorator into a Listener/Adapter paradigm, thus generating more than just java code (hint: A “Spring-i-ficator” emitting a beans.xml-like output for Spring Users)
- Better handling: Currently, there are only basic functionality covered. Although it (nicely) suits my needs.

Ideas are strongly welcome. That’s why I’m still awake doing this post. To help me leverage key issues and future directions. Please, be my guest :)

And now I’m (kinda) done, albeit tired. Remember, I not only created, but bred a monster out of my own ideas. :)

Aldrin Leal says:
o iText é bom no propósito, mas como framework, deixa a pecar em vários pontos.
Aldrin Leal says:
Do modo como é implementado até a completa ausência de testcases. Seu único recurso quando a documentação falha é o fonte, que não é nada simples.
Paulo says:
é um fonte a la aldrin leal? :)
Aldrin Leal says:
Você já leu fontes meus? Daonde soube da minha fama? :)

Um fonte Aldrin Leal não possui expressões simples, tende a ser extremamente curto (Porque Densidade de Código é o Nome do Jogo), não possuir expressões simples, e sem contar o completo abandono de comentários. E costuma ser em alguma linguagem ainda emergente ou pouco conhecida (como Java era na época que eu fiz o código que, coincidentemente, meu interlocutor teve que manter).

Se você já programou algo na vida, sabe que o compilador é uma espécie de D’us no Antigo Testamento: Cheio de Regras e ai de você se você se esquecer de uma.

Mas ele (o compilador) é implacável, e sequer o parabeniza quando você acerta (perverso ele, não?). Mas isso é só o começo: O fato *DO SEU CÓDIGO COMPILAR* não significa que ele irá fazer o que realmente precisa ser feito.

Essa “frustração conceitual” (i.e., o resultado não corresponde ao esperado pelo conceito) é o bug que todos nós vemos. Aquela mensagem de erro inexplicável, aquela situação que dura um tempo considerável pra acabar, ou simplesmente aquele botão que não faz o que tá descrito no manual são bugs. Ou “comportamentos inesperados”, ou qualquer outro eufemismo que você prefira.

O fato é: Se formos classificá-los os erros, basicamente possuímos dois tipos de erro:

• Erros de Compilação, que são gerados quando o compilador olha o seu código fonte;
• Erros de Execução, que são as exceptions e aquela “alguma coisa que está errada pois não está certa”

Se você decidiu tomar a profissão como caminho pra pagar seus pecados (como eu, diga-se de passagem), com o tempo aprendeu a interpretar e a resolver estes tipos de erro, principalmente os de compilação. Uma minoria aprendeu a evitar os de execução não apenas executando os programas, mas aplicando testes de unidade, introduzindo ferramentas de alerta de possíveis problemas, sistemas de gerência de alteração, bugtracking e uma centena de outros mecanismos e ferramentas para reduzir a incidência dessa turma.

Isso é certamente ótimo quando o seu problema é limitado à uma pessoa e um problema simples, trivial, pontual, e outros ‘al’ que sejam pejorativos. A coisa começa a ficar mais interessante à partir do ponto em que você possui um sistema de controle de fonte *E* mais de uma pessoa envolvida. A partir deste ponto, o ideal é que você passe a se preocupar com que a estabilidade do sistema permaneça inalterada. Afinal de contas, qual a utilidade de uma versão que não compila ou que possui erros graves?

Além disso, é bastante interessante que você consiga compilar a sua aplicação de maneira automática, e, se possível, integrando-se com os testes de unidade. Não apenas no IDE, portanto. Para isso, temos ferramentas como o make, ant, e maven, feitas no intuito de automatizar cada tarefa necessária para que todo o seu projeto seja compilável e configurável a partir de um único ponto central.

Mas ainda assim, há a possibilidade de automatizar o processo ainda mais, fazendo com que toda a compilação e teste seja feita a partir de outra cópia de trabalho da árvore de checkout, afim de conferir mais segurança ao software.

E então entramos na idéia da Integração Contínua: Um processo que recompile/execute os testes a cada commit (ou alteração) que surja no seu sistema.

Soa idéia mirabolante? Dependendo do ponto de vista, realmente o é. Mas, de forma nenhum, é uma idéia nova. É público e notório que a Microsoft mantém áreas específicas para coordenar a compilação do Windows, e que na política da empresa existem regras (informais, obviamente) estabelecendo penalidades para quem for o responsável por introduzir uma falha na compilação (penalidade essa que deve ser bastante dolorida quando o software contém 25 milhões de linhas de código, como o Windows 2000 tinha :])

E, por onde começar com a CI? Bem, se você é devoto do Java, sugiro começar com o CruiseControl. Apesar da configuração dele parecer um pouco amedrontadora, experimente também usá-la em conjunto com o CruiseControl-Config, que então sua barra fica mais leve. :)

Espero postar algumas configurações do cruisecontrol nos próximos dias, pra demonstrar algumas idéias legais dele.