Primeira Etapa : Foi definido em qual projeto trabalharíamos de acordo com nossas expectativas de trabalho e preferências. Então nos foi passada a expecificação do projeto para que pudéssemos estudá-la. Ficamos por essa semana apenas estudando o projeto, decidindo o que seria ou não possível fazer, qual seria a melhor forma e que tecnologias poderíamos utilizar. A empresa também estava em faze de mudança de endereço, instalação de equipamentos e móveis.
Ainda em fase de mudanças os equipamentos não estavam totalmente instalados e o acesso à Internet, nossa principal fonte de pesquisa, ainda era precário com apenas uma linha telefônica e um microcomputador para conexão via modem. Estava sendo providencidas a rede e a conexão via rádio nesse período. Durante essa semana decidimos pelas tecnlogias as serem utilizadas: linguagem de programação Java, banco de dados mySQL, JavaServlets e, como recomendação de nosso chefe, LDAP (Lightweight Directory Acces Protocol), embora não soubéssemos do que se tratava. Fizemos então uma expecificação (contra-proposta) para apresentar aos clientes e participamos da reunião na qual a expecificação foi apresentada. Devo dizer que não podemos chamar o que fizemos exatamente de uma especificação de projeto nas linhas de Engenharia de Software, pois não fizemos nada mais que especificar as ferramentas a serem utilizadas com um pouco de embelezamento para impressionar os clientes.
Segunda Etapa : Começamos a estudar o que seria necessário para instalação e funcionamento dos Servlets. Depois de muita pesquisa e dor de cabeça conseguimos fazer tudo funcionar. Devo admitir que o medo de fazer algo de errado que pudesse comprometer o servidor no começo nos bloqueou um pouco. Mas superado mais esse obstáculo e com a ajuda de nosso administrador da rede, também um colega de faculdade Roberto Pires de Carvalho, conseguimos com que os Servlets funcionassem. Produzimos nossos primeiros Servlets para teste e aprendizado.
Terceira Etapa : Seguros de que já sabíamos trabalhar com JavaServlets e de que tudo funcionava, passamos para o estudo da ferramenta LDAP. Sem uma informação precisa do que se tratava e apenas com a ordem de que estudássemos a ferramenta saímos às cegas a procura de informação sobre o LDAP. Encontramos pouquíssimas referências e nenhum livro a respeito, a principal referência que tínhamos era uma RFC encontrada no ``site'' da Universidade de Michigan. Com tão pouca informação continuamos sem saber ao certo do que se tratava a ferramenta mas, mesmo assim, passamos a tentar instalá-la e configurá-la. Devido às dificuldades encontradas e ao consumo de tempo, a Rachel passou a dedicar seus estudos à interface Java JNDI para acesso a estruturas de diretórios enquanto eu ainda tentava configurar o LDAP. Mas as dificuldades continuaram e depois que a Rachel conseguiu entender como funcionava JNDI desisti do LDAP e, vale ressaltar, a tal ponto eu ainda tinha dúvidas quanto a aplicabilidade da ferramenta às nossas necessidades.
Quarta Etapa : Desencantados com o LDAP e certos de que JNDI supriria nossas necessidades de armazenar informações em estruturas de diretórios visando agilizar a busca dado um certo caminho, passamos para a modelagem do banco de dados. Construímos um esboço do modelo ER e depois de muitas reflexões chegamos a um modelo final. Partimos então para a conexão com o banco de dados jazendo uso de JDBC (Java Data Base Conectivity ). Para isso precisamos encontrar um ``driver'' para a conexão que precisaria estar disponível no servidor. Encontrado o ``driver'', passamos à construção de classes para conexão e interação com o banco de dados. Tais classes disponibilizam métodos para execução de consultas ao banco de dados, sendo que alguns desses métodos tratam as respostas recebidas referentes as consultas e devolvem a informação organizadas em estruturas de dados tais como um vetor ou uma ``hashtable'', tudo isso para facilitar nossa interação com o banco de dados.
De posse de uma classe para conexão com o banco de dados, passamos à construção das tabelas modeladas anteriormente no modelo ER. Com o banco de dados construído fizemos os servlets de cadastro dos usuários e empresas. A tal ponto, percebemos que um projeto pode mudar muito em relação ao que foi combinado na especificação inicial, isto é, se você não tem poder para dizer não ou fazer do seu jeito. Devido a esse fato, várias coisas mudaram no banco de dados e tivemos que remodelar e refazer muitas coisas. Surgiu então o medo de mudanças como essa surgirem na fase final do projeto. Torna-se perceptível a tal ponto a falta de uma especificação bem elaborada e falta de compreensão da proposta dos clientes, dado que eles mesmos não sabiam o que queriam direito, mas tinham certeza apenas do prazo curto que a empresa admitiu cumprir.
Quinta Etapa : A primeira etapa das inúmeras modificações que sucederiam. A especificação foi mudada em vários pontos, modificações foram feitas no cadastro e nas regras de negócio. A ``Engenharia de Software Reversa'' começou a ser feita: a codificação do projeto começou a ser feita muito antes dos clientes saberem realmente o que queriam, não tivemos a chance de conversar e discutir com eles o projeto, tivemos apenas que ir fazendo e incorporando as mudanças. Sabemos que o preço por isso pode ser caro, mas sem voz para decidir esperávamos sinceramente que também não tivéssemos voz para responder pelos erros. Desculpem a sinceridade, mas a tal ponto, a falta de conhecimento do assunto dos responsáveis pelo fechamento do contrato do projeto e inúmeras outras coisas me faziam achar que esse barco afundaria.
Sexta Etapa : Um desafio interessante. Foi necessário fazer um ``carrinho de compras'' e para isso precisamos aprender a abrir sessões de navegação no servidor para o cliente. Isso não foi tão difícil, o grande desafio foi que essa sessão de navegação deveria conter o número de identificação da compra do cliente no banco de dados, antes mesmo dessa compra ser criada, pois durante todo o processo de compra inúmeros outros objetos do banco de dados precisariam ter uma relação com essa compra. O fato é que duas empresas poderiam realizar compras ao mesmo tempo, então tínhamos um problema de concorrência, pois duas empresas poderiam ter uma sessão aberta com o mesmo ID de compra e isso provocaria erros de consistência no banco de dados bem como o erro de inserção da segunda compra. Decidimos por construir uma tabela no banco de dados que guardasse apenas o último ID de compra cadastrada assim, cada vez que uma sessão de compra fosse aberta, atomicamente consultávamos a tabela para saber qual seria o próximo ID da compra e o incrementávamos. Para realizar essas ações atomicamente contamos muito com a ajuda dos conhecimentos da disciplina Programaçã Concorrente e com a ajuda da professora Dilma do Departamento de Ciência da Computação.
Sétima Etapa : Passamos ao aprendizado de JSP (Java Server Pages). Com o uso de Servlets o HTML estava embutido no código Java o que atrapalhava muito a integração entre ``design'' e programação, principalmente porque o ``design'' muda a toda hora. O JSP é uma ferramenta que permite escrever código HTML interpolado com código Java, assim toda vez que um ``cliente'' solicitar uma ``página .jsp'' ao servidor, esse último primeiro interpreta a página JSP e depois devolve ao cliente somente código HTML gerado conforme implementação da página JSP. O grande desafio de se utilizar JSP foi construir um JavaBean com as classes de conexão com o banco de dados para que esse JavaBean pudesse ser importado e o código reutilizado. Um fato interessante foi que não conseguimos construir o JavaBean ``na mão'' como gostamos de fazer, seguimos todos os passos indicados no tutorial mas não obtivemos sucesso; eu disse interessante porque é de nossa natureza rejeitar coisas prontas e ferramentas gráficas para programação e tivemos que ``apelar'' para o JBuilder - uma ferramenta gráfica para programação em Java. Feito isso, nossa vida melhorou muito, o código Java agora pode ser mais facilmente separado do código HTML e o ``design'' e programação se tornaram mais independentes.
Oitava Etapa : Estamos quase terminando o projeto, mas muitas alterações são pedidas e além disso vários ``bugs'' foram encontrados pois, na pressa, produzíamos código como máquinas e muitas vezes não o testávamos direito, às vezes nem testávamos. Terminamos nessa etapa o que estava pendente, consertamos os ``bugs'' e fizemos as alterações pedidas mas, o ``site'' não foi pro ar. Participamos de muitas reuniões para ouvir as mudanças que eles queriam que fossem feitas e tentar convencê-los de não fazer outras que implicariam em refazer e reestruturar tudo que fizemos. Particularmente tudo que fizemos por esse dias não me agrada nem um pouco.
Permitam-me um desabafo: Engenharia de Software reversa é tudo que temos feito por esses dias, coisas novas aparecem de repente e tudo era pra estar funcionando ``pra ontem''. As modificações pedidas interferem em toda a estrutura de dados: simplesmente inserem um ou dois campos no cadastro e acham que tudo funcionará miraculosamente assim que os campos aparecerem no html, buscas que eram feitas por Cidades, Estados e tipos de estabelecimentos (Restaurantes, Carro, etc) agora são feitas por palavra chave e eles dizem que não funciona, que pena não? É óbvio que não funciona, nada disso estava previsto e não há nada a respeito no banco de dados! Ninguém tem coragem de dar um basta nisso tudo e agente tem que ficar fazendo as modificações. Agora todos os dias temos uma reuniãozinha com os clientes para discutirmos essas coisas, infelizmente, um pouco tarde demais. A meu ver, deveriam ter sido feitas antes de se começar o processo de codificação e uma outra durante o processo, mas só e nenhuma mais. Eu e a Rachel somos programadores quando se tem que fazer e cumprir prazo de entrega e estagiários na hora de estabelecer os prazos de entrega e de receber o salário. Que saudades de autômatos, árvores rubro-negras, grafos... !
A esse ponto estão sendo feitos os retoques finais. Mais modificações levaram a prolongar o prazo de entrega. A tal ponto nada temos feito além de refazer e enfeitar o que havíamos feito. Um concorrente surgiu e os clientes ficaram desesperados, queriam mudar todo o ``design'' porque haviam se cansado antes mesmo de lançarem o ``site''. Algumas discussões se sucederam, semanas e mais semanas se passaram e, feitos mais alguns retoques o ``site'' foi pro ar no dia 10 de setembro. Sem novos desafios ou obstáculos, me tornei uma máquina que repetia sempre as mesmas tarefas. Comecei a ter um certo nojo de tudo que fiz durante esse projeto. Porque na pressa de estar pronto éramos como máquinas de gerar código que atendesse às necessidades visuais dos clientes e do próprio chefe. Como máquina, eu não pensava, e o código ficou horrível, muitíssimo mal comentado e ``porco''. Mas, não me culpo por isso pois, junto com outras pessoas, tentamos mudar um pouco a empresa, mas foi em vão. Cheguei a conclusão de que talvez os fatos que tenham feito valer a pena ter feito o estágio foram ter descoberto que não sou tão ignorante assim e descobrir o perfil de empresas nas quais nunca mais pretendo trabalhar, porque eu acredito naquilo que faço e que aprendi e não pretendo abandonar todos os meus princípios e ideais. Prefiro então, abandonar o que está errado: o emprego.