A data de entrega a que propus este projecto foi 3 de Julho de 2008, hoje, dia 18 posso dizer que falhei redondamente o que estava planeado para este trabalho. A data de entrega do material provisório, para análise da minha orientadora foi dia 16. Próximo dia 22 terei de terminar o projecto, tem de estar o mais completo possível e fazer tudo o que é suposto, ou pelo menos tudo o que foi colocado no relatório.

Se algum aluno da ESTG ler isto, saberá que o que é importante é o relatório, como dizemos por aqui, “Ninguém olha para o código, só tem de funcionar!”. Mas eu olho para o código, olho para o que escrevi, para as escolhas que fiz, aquelas linhas que não deviam existir, aquelas práticas que bem sei não estarem de acordo com os padrões que impus a mim mesmo durante todo o tempo em que me sinto parte deste curso.

Não sei o que me incomoda mais, se ter falhado os objectivos do projecto, se saber que os falhei porque não tive a coragem de encostar à parede a minha colega de projecto. Sei que o projecto foi idealizado por mim, o software é, principalmente, para minha utilização, mas este foi supostamente um projecto para dois alunos, não para um!

Neste momento tenho consciência que não existe uma linha de código, um único algoritmo, implementação, seja o que for, naquele projecto que não seja meu, que não tenha sido pensado, planeado e executado por mim, cada funcionalidade foi implementada por mim e cada bug é culpa minha. E olhando para o relatório as coisas não parecem muito diferentes.

Ainda me lembro do choque que foi, ao fim de quase dois meses e meio, descobrir que o trabalho a que a minha colega se tinha proposto fazer, não estava feito. Dois meses de suposta escrita de relatório que se revelaram em cerca de 20 páginas de autêntico lixo. Testos que neste momento se encontram no servidor, apenas porque não tive ainda tempo para os apagar.

Mas não a culpo pelo que aconteceu, a culpa foi minha não ter tentado fazer o projecto sozinho, ou não ter apresentado a porta da rua. E por isso estou cansado, demasiado cansado para continuar o projecto, demasiado cansado para levar isto até ao fim.

Cada execução é uma tortura, encontrar um erro no código já não é visto como um problema que precisa ser resolvido mas sim como mais um prego no caixão, e posso dizer-vos, a quem quer que tenha tido a coragem de ler isto, que o caixão é bonitinho, todo pregadinho a dourado, sim, porque se os erros se parecem com pregos, ao menos que sejam pregos de oiro, e me levem rico para cova.

E este é o meu entusiasmo, hurray!, tenho projecto para acabar, hurray!, chumbei a duas frequências por não ter tido tempo de estudar, hurray!, não fui a dois exames para fazer o trabalho que estava atribuído à minha colega, hurray!, o projecto é para entregar terça-feira, e nada funciona!

Portanto, falhei os objectivos, falhei o que queria fazer, o que tinha, com elevada expectativa, definido para o meu último ano de curso. Hurray!, mais um ano em que não devo ter férias, ao menos isso não me tiram, a rotina de não ter férias e passar o Verão a estudar para os exames de Setembro.

E agora vou ver um filme, perder-me na certeza de saber que não sou capaz de acabar isto, estou demasiado cansado!

Não que a plataforma seja má ou que considere uma má escolha ter enveredado por este caminho, apenas que algumas coisas podiam ser mais evidentes, estar melhor documentadas, ou pura e simplesmente serem mais simples de atingir.

Um pouco de referência: A aplicação está ser desenvolvida em Java, usando a plataforma Netbeans, e uma camada de persistência conseguida através de bases de dados relacionais. A abstracção em relação ao SGBD usado é criada através do uso de uma tecnologia ORM, neste caso o Hibernate.
Ora a plataforma impõem uma forma modular de desenvolvimento, o que implica ter de planear a aplicação em pedaços que possam encaixar uns nos outros e, ao mesmo tempo, possam ser substituídos por blocos que cumpram os contractos de comunicação, podendo implementar esses mesmos contractos como bem entenderem. Além desta pequena dificuldade, a comunicação entre módulos é feita com base em dependências, pelo que a inclusão do Hibernate teve de ser feita tendo em atenção estas dependências e as forma como os seus métodos estariam acessíveis está relacionada com o tipo e ordem de dependências existentes entre os módulos.

Para quem já usou o Hibernate, falar do pesadelo que é configurar o correcto mapeamento das entidades, não é coisa nova. Para os que não usaram, não tenho palavras para o descrever! Já tinha usado a tecnologia antes, em aplicações Java standards e em aplicações JEE, nada me preparou para isto.
A documentação é uma confusão, não sendo nada fácil de ler, está escrita de um forma que em muitos casos torna os exemplos ambíguos e complexos para além da necessidade.
Como exemplo posso dizer-vos que durante as primeiras 2 semanas em que estive a trabalhar com a camada de persistência, o mapeamento das entidades estava, na sua maioria, errado! Nada disto é surpreendente, afinal todos sabemos como um programador a aprender comete asneiras. Nada será de estranhar senão o facto de que todo o sistema esteve a funcionar, como devia, devo realçar, até ao momento em que tive de acrescentar um único atributo novo a uma entidade, e, naturalmente, tudo veio por aí abaixo. Classes que deixaram de ser guardadas na base de dados, excepções por tudo o que era acesso à base de dados, uma completa panóplia de erros que nunca tinha conhecido. Resultado: voltar a ler *toda* a documentação da tecnologia, na forma do manual de referência constituído pelas 80 e qualquer coisa páginas de texto em Times New Roman, tamanho 8, para poupar papel e impressão.
Depois de uma tarde inteira de volta das entidades, revendo todos os atributos, cardinalidades das relações e direcção das mesmas, consegui colocar o sistema de novo a funcionar, embora não me perguntem como porque, a bem da verdade, não sei bem o que fiz .

Primeiro problema: partilhar a instância do objecto que controla a ligação à base de dados por todos os módulos que precisem de aceder aos dados. A instância tem de ser única, tem de ser acessível de forma universal e tem de estar instanciada quando a aplicação estiver pronta a ser usada.

Segundo problema: tenho uma instância… não, tenho duas… mas que raio!, são três?… cogumelos outra vez?!

Terceiro problema: como aceder aos dados? Quem faz as pesquisas e como garantir que os dados estão coerentes para que se possam criar interfaces gráficas com o utilizador.

Quarto problema: criar nós a partir dos dados da base de dados. Tarefa que não foi nada fácil.

Quinto problema: e agora queria uns “menuzitos” por aqui… hum… assim não…. Mas, se é tão simples criar um menu com base no que está seleccionado como é que crio um quando não existe um nó seleccionado? Pois, exemplos de como criar um menu de contexto baseado no que está seleccionado não faltam, agora baseado no que não está, é que é mais complicado.

Estes são, entre outros, os problemas que terei de resolver esta semana, isto sem poder falhar, o projecto é para entregar dia 2 do mês que vem, Julho, e estou atrasadíssimo, deveria estar na 6ª iteração do desenvolvimento mas pelo andar das coisas estou na 2ª 1/2…
Parece-me que serei capaz de os resolver entretanto, pelo menos se não me aparecer mais um imprevisto relacionado com a falta completa de documentação para o que pretendo fazer; a ver vamos.

P.S.: Se queriam ver a solução para este problema, tenho pena mas não será hoje, é tarde, estou cansado e não me apetece escrever mais, além disso, sempre me oferece uma desculpa para mais uns 5 textos

Esta foi a única palavra que ouvi durante mais de uma semana. Estava na minha cabeça sempre que pensava no trabalho que tinha de desenvolver para começar o JFindMyFiles. E quando nos sentimos sobrecarregados com o trabalho e a ponta de desânimo aparece, começamos a pensar nestas exigências.

Para desenvolver o software para a cadeira de projecto do curso terei de justificar tudo o que faço, as escolhas e decisões que tomo, sejam elas quais forem. É frustrante saber que temos a escolha certa e não termos como justificar o que escolhemos, porque não temos documentação que apoie a nossa decisão.

A primeira luta foi a escolha da plataforma RCP, como é natural escolhi a plataforma Netbeans, que tirando o toolkit gráfico, o facto de ser realmente multi-plataforma, e alguns pormenores de de desenho, é bastante igual à plataforma eclipse e ambas permitem atingir o objectivo. Talvez excepto a parte do requisito “multi-plataforma”, que devido a um bug, não daria para atingir usando Eclipse RCP.

Como devem imaginar, documentação sobre estas duas plataformas existe em quantidades monumentais. Ele é livros, tutoriais, exemplos, wikis, Javadocs, tudo o que um programador precisa, excepto duas coisas: listagem das plataformas RCP existentes, e comparação entre elas.
Até a Wikipédia que tanta informação tem, redireccionava recentemente o link de RCP para RIA, duas coisas completamente diferentes.

Como justificar então a escolha da plataforma? Sim, porque até o bug (1, 2, 3) não era conhecido na altura da análise e as duas plataformas pareciam ter exactamente o mesmo potencial, sendo apenas uma questão de gosto, coisa a que os arguentes da ESTG Leiria não acham muita piada, isto pelas apresentações de projecto que tenho visto nos dois últimos anos.

Recorri à experiência de outros programadores para me auxiliarem nesta demanda, e pedi ajuda na mailing list de utilizadores de Netbeans, discussão que podem seguir, caso tenham curiosidade em http://www.nabble.com/Choosing-Netbeans-platform-or-Eclipse-RCP-to16012394.html. A ajuda que me deram não foi muito grande uma vez que não posso usar como apoio na minha decisão, uma discussão numa lista, por mais conceituada que seja. Por sorte encontrei várias referências a um artigo publicado (sendo que artigos publicados são irrefutáveis ) e comecei a animar… apenas para desanimar outra vez quando descobri que o dito artigo existia mesmo mas em alemão!, e não, eu não sei ponta de alemão.

Mas no momento em que mais se desespera aparece logo uma solução, contactado o autor do artigo sobre a possibilidade de obter algumas dicas em inglês, pelo menos umas notas que eu podesse usar, o mesmo se prontificou a enviar-me no dia seguinte uma versão do dito artigo em inglês. Pois é, ainda há gente simpática no mundo , e um muito obrigado ao sr. Kai Toedter pela amabilidade.

No entanto tudo isto deixou uma pergunta que me tem vindo a incomodar: O que é que está a ser avaliado, os meus conhecimentos com engenheiro, a aplicação dos conceitos que aprendi e das metodologias de engenharia, que supostamente adquiri ou a minha capacidade de ler o que os outros fizeram?
Estamos a formar engenheiros ou bons leitores?

Talvez tenha levado a necessidade de justificar coisas ao extremo, mas essa é a ideia que passa e que nos é transmitida durante o desenvolvimento do projecto.

Este programa que pretendo ver concluído no início de Junho deste ano já existe na minha lista de coisas para fazer há mais tempo do que me consigo lembrar, talvez algures entre 2001 e 2002, quando experimentei um software chamado Argentium Myfiles e mais tarde o Where Is It. Ambos servem para catalogar os ficheiros que existem em discos e pastas, espalhados pelo computador ou em bolsas de CDs a ganhar pó, o problema é que esses softwares não são livres, nem tão pouco gratuitos, mas são úteis, pelo menos para mim. Daí até querer fazer um para as minhas necessidades foi um passo, o problema foi conseguir dar esse passo.

Inicialmente por falta de conhecimentos, depois por falta de tempo, nunca iniciei correctamente o desenvolvimento do sistema, com sorte consegui que fosse aceite para a cadeira de Projecto Informático do curso e juntamente com uma colega iniciamos o desenvolvimento da malfadada aplicação.

Este é o primeiro de um conjunto de textos que pretendo publicar sobre a minha experiência no decorrer deste projecto. Esperemos que sejam agradáveis de ler.