A equipe de trabalho consistia de dois ``web-designers'', dois programadores e um responsável geral, diretor de informática da empresa.
Entre os programadores estava também uma colega de faculdade, Rachel de Paula , cujo trabalho de formatura pode ser visto em
http://www.linux.ime.usp.br/
rpaula/mac499 . Sobre nossa responsabilidade estava toda a parte de especificação, modelagem, codificação, documentação, testes do projeto e também a integração entre ``design'' e programação afim de tornar o ``site'' navegável. Ainda sem nos dar conta de que éramos estagiários apenas na hora de recebermos o salário, no começo, aceitávamos sugestões de nosso chefe (o diretor de informática) sem suspeitar ou contestar nada porque acreditávamos que ele conhecesse e dominasse as ferramentas que ele nos pedia para estudar e utilizar. Mais tarde também descobriríamos que isso nos custaria atrasos consideráveis na entrega do projeto e que nem tudo que ele sugeria utilizarmos era viável ou até mesmo aplicável, seja no intervalo de tempo proposto, seja na aplicação e funcionalidade da ferramenta em si. A partir de tal ponto passaríamos também a ser responsáveis pelas decisões de projeto e com um pouco de luta conseguiríamos também influenciar, mesmo que em uma pequena parte, no prazo de entrega que até então era estabelecido pelo diretor geral da empresa (um economista) que admitia não entender nada de informática e tão pouco de programação.
O prazo inicialmente estipulado para entrega do projeto foi de um mês. Não participamos de tal estimativa e nem sequer fomos consultados a respeito. Assustados, informamos que não daria tempo nem mesmo de entender direito o que o cliente desejava e muito menos fazer uma especificação aceitável. Ignorados, decidimos não nos preocupar com tal decisão visto que não tínhamos participado dela. Também foi planejada uma segunda fase para o projeto. Mas nada seria entregue no prazo especificado, seja por falta de planejamento, seja por falta de condizência entre prazo viável e prazo estipulado.
Durante todo o trabalho utilizamos como principal fonte de pesquisa e informação nosso meio de trabalho, a Internet. Dentre os principais ``sites'' que utilizamos como fonte de pesquisa estão:
Desafios e frustrações foram muitas. Se por um lado os desafios nos estimulavam a nos envolver cada vez mais com o projeto, as frustrações foram com o decorrer do tempo despertando o desgosto e a falta de interesse. Como nosso primeiro desafio, ainda antes de começarmos o projeto nos foi proposto que estudássemos a ferramenta LDAP ( Ligthweight Directory Acces Protocol ) para que fosse utilizada como forma de agilizar a busca a ser realizada no projeto. Sem ao menos ser informados do que se tratava ou o porquê de tal ferramenta ser aplicável e eficiente, talvez por falta de conhecimento do proponente ou por omissão, iniciamos os estudos de tal ferramenta. A falta de material disponível na Internet e até mesmo de livros nos desestimularam e fizeram com que cada vez mais desconfiássemos da sua aplicabilidade em nosso projeto. Tudo que conseguíamos encontrar eram RFC's a respeito da ferramenta, principalmente no ``site'' da Universidade de Michigan, uma das desenvolvedoras. Duas semanas se passaram e o desânimo era total, não havíamos ainda descoberto se a ferramenta era mesmo aplicável e nem em que contexto era útil e eficiente, enfim, não sabíamos ainda do que se tratava. Mais tarde descobriríamos, mesmo sem ainda entender direito a funcionalidade, a incompatibilidade do LDAP com nossas necessidades.
Com o desenrolar do projeto outros desafios foram surgindo:
Cada um dos desafios e ferramentas acima serão tratados mais especificamente no decorrer desse texto.
Talvez pela própria natureza humana, as frustrações parecem ser mais marcantes que as conquistas. Uma de nossa principal frustração foi o tempo. Não podíamos estipular quanto tempo precisaríamos para realizar determinada tarefa e nos eram estipulados prazos impossíveis. Na falta de organização e na correria, fizemos coisas que hoje nos enojam, código mal comentado, estruturação mal elaborada, os chamados quebra galhos não consertados... Enfim, a falta de tempo suficiente para estudar, discutir e elaborar as coisas de maneira decente foi uma das grandes decepções. Passados alguns meses de trabalho e às custas de revoltas e revoluções conseguimos um pouco mais de voz a respeito dos prazos, mas parece não ter feito muita diferença. A relação entre a empresa e os clientes também nos decepcionava, a empresa acatava toda e qualquer decisão dos clientes, nos fazendo refazer coisas que considerávamos prontas e de acordo com a proposta antes das mudanças. Tais modificações não deixavam o projeto ``andar'' e essas eram feitas com freqüências revoltantes. Na descrição das atividades que será apresentada mais adiante, esses problemas poderão ser melhor compreendidos.
A relação entre responsabilidades e cargo desempenhado também era uma outra frustração. Tínhamos toda a responsabilidade sobre o projeto, éramos como a empresa mesmo dizia os ``donos do projeto'' mas no que lhes convia pois, na hora de receber, estipular prazos e dar opiniões sobre o que deveria ou não ser feito, éramos meros estagiários. Aos poucos, com reclamações nossas e com a pressão dos clientes devido aos prazos não serem cumpridos a situação começou a se modificar, participávamos de reuniões com os clientes principalmente para explicar o que seria viável ou não e o quanto custaria certas modificações dado que éramos os únicos que conheciam tais informações. Mas isso não muda muita coisa. Sobre as reuniões vale a pena ressaltar, até porque é cômico, como o uso de informações irrelevantes e desconhecidas pelos clientes podem ajudar a convencê-los a não fazer ou até mesmo fazer coisas que julgávamos convenientes, basta um ar convincente e palavras bem arranjadas e tudo se resolve.
Agora, vamos tratar um pouco a respeito das técnicas e ferramentas utilizadas e até mesmo citadas previamente nesse texto.
Como foi dito, utilizamos Java como principal linguagem de programação. Os fatos que pesaram bastante na aceitação dessa decisão foram a portabilidade de Java, sua robustez, por estar estritamente relacionada com a proposta e possuir componentes preparados para o tipo de trabalho que iríamos realizar, ou seja, ferramentas para Internet e também pelo afeto pessoal dos programadores com a linguagem de programação. Grande relevância em tal decisão foi a existência da interface JavaServlets que permite a construção de páginas HTML dinâmicas, base de todo o projeto - um ``site'' dinâmico.
Logo no início do projeto nos foi proposto que tentássemos utilizar o LDAP para agilizar a busca a ser feita em nosso ``site''. Sejamos mais específicos: segundo a especificação inicial as buscas a serem realizadas teriam os parâmetros montados estaticamente na página de busca do ``site''. As buscas seriam feitas por estado, cidade e categorias do produto montadas como já disse, por seleção estática do usuário. Nos propuseram então que esses dados ficassem armazenados em uma estrutura de diretórios, uma árvore, pois dada um busca teríamos todo o caminho a percorrer até o dado e sendo assim isso poderia ser feito em um acesso direto na estrutura. Em um banco de dados isso envolveria várias tabelas de tamanho considerável. Como também foi dito, não conseguimos entender a tempo o LDAP e passamos a utilizar JNDI (Java Naming Directory Interface ) para montar tal estrutura de diretórios que armazenariam os dados no disco do servidor. JNDI é uma interface Java para associação de nomes a uma tabela de contexto, utilizada na criação, manipulação e remoção de diretórios bem como, pesquisa, inserção e remoção de dados.
Sobre o banco de dados decidimos por utilizar o mySQL, primeiro por compatibilidade com Java e conhecimento prévio por integrante do grupo de programadores de tal banco de dados bem como do meio utilizado para conexão com ele, e depois pelo preço da licença para uso comercial que é razoavelmente barato.
JDBC foi a interface Java que utilizamos para estabelecer conexão com o banco de dados. Tal interface, desde que disponha de um ``driver'' para a conexão com o banco de dados, fornece um objeto que mantém uma conexão através da qual podemos executar consultas e realizar buscas. De presente também nos é dado pelo Java objetos capazes de armazenar resultados dessas buscas, facilitando o tratamento dos resultados encontrados em cada consulta.
Como a base de todo o projeto do ``site'' são as páginas geradas dinamicamente, JavaServlets foi nossa ferramenta de apoio. Os Servlets, são códigos Java que rodam no servidor e como resposta a uma requisição do cliente geram código HTML dinamicamente e o devolvem como resposta ao cliente. Os Servlets são capazes de receber parâmetros através de dados vindos de um formulário HTML, ou até mesmo via URL e, através do processamento desses dados ou de consultas ao banco de dados uma página HTML de resposta é gerada, personalizada de acordo com cada requisição. Tanta facilidade em se gerar código HTML dinamicamente mais tarde revelaria seu preço. O grande problema de se gerar código HTML através dos Servlets é que todo o código HTML fica embutido no código Java e o HTML tem que ser impresso como se fosse um ``printf'' de C ou até mesmo um ``System.out.println'' de Java, só que esse código é impresso em um objeto de resposta ao cliente denominado ``HttpServletResponse'', proveniente do JavaServlets. Tudo isso significa que uma mudança qualquer no ``design'' da página gerada dinamicamente implicaria em reescrever código na maioria das vezes; com um pouco de sorte implicaria em pequenas modificações.
Tanto problema poderia ter sido selecionado se conhecêssemos uma ferramenta chamada JSP ( Java Server Pages ). Tal ferramenta permite que misturemos código Java com código HTML simplesmente especificando através de ``tags'' da ferramenta onde começa código Java e onde termina, tudo isso no meio do HTML. Uma página JSP quando requisitada por um ``cliente'' é processada primeiro pelo ``servidor'' que devolve ao cliente somente código HTML, processando todo o código Java e montando a página HTML dinamicamente conforme foi programada. As ``tags'' JSP são muito parecidas com as ``tags'' ASP, uma outra ferramenta muito utilizada para o mesmo fim. Com o auxílio dessa ferramenta o código pode ser mais facilmente separado do ``design'' o que corresponde a grande ganho de produção e menos dor de cabeça. O grande obstáculo em utilizar essa ferramenta foi compreender como fazer uso de outras classes Java já escritas, pois não bastava que estivessem em um mesmo diretório ou no ``classpath'', era necessário importá-las, como num ``import'' comum de Java, mas para isso deveria ser um JavaBean. Esse foi então o obstáculo, construir um JavaBean que contivesse nossas classes de conexão com o banco de dados para que pudessem ser importadas pelo JSP. O que nos deteve até quando não pudéssemos mais ignorar tal ferramenta foi a falta de tempo, pressão e falta de coragem de investir na pesquisa dessa nova ferramenta devido ao medo de uma nova frustração e perda tempo como havíamos feito com o estudo do LDAP.
Outras ferramentas nos auxiliaram no desenvolvimento do ``site'', embora em menor escala, são elas: PHP que utilizamos para o envio de e-mails automáticos para os usuários e JavaScript muito utilizada para resolver casos não muito importantes para nós, mas de grande relevância para os clientes tais como ``Cookies'' de reconhecimento do usuário, redirecionamentos e manipulações feitas com os ``Navegadores''.
Dessa aventura por todas essas ferramentas ficaram na expectativa de uso ferramentas para fins conceituais, que nada produzem aos olhos dos clientes mas que são de grande importância aos olhos do programador, tais como ferramentas para modelagem do banco de dados com construção de diagramas de Entidade e Relacionamento (ER) e principalmente de Engenharia de Software, que sentimos falta tanto de uma ferramenta de auxílio quanto da aplicação dos conceitos práticos em si.
Por todos esses desafios, algumas disciplinas cursadas no BCC foram de grande importância, seja como base para o desenvolvimento, seja na percepção de falhas ou na formação pessoal do espírito crítico e de autoconfiança. Dentre todas elas, citemos as de maior relevância no processo de desenvolvimento do projeto: Banco de Dados, Programação Concorrente, Programação Orientada a Objetos, Engenharia de Software, Estrutura de Dados, Redes, Introdução à Computação, Princípios e Desenvolvimento de Algorítimos, Administração de Sistemas UNIX e Laboratório de Programação Vale a pena ressaltar que a estrutura geral do curso e também as outras disciplinas desempenharam um papel importante na formação pessoal como foi mensionado acima.
É interessante dizer aqui também que nosso trabalho não era fiscalizado a não ser pelo prazo de entrega, recebíamos a informação do que devia ser feito e éramos responsáveis pelo resto. O que pode ser estranho talvez seja a confiança que depositavam em nós, nunca fiscalizavam o código e só se importavam com o produto final, ou seja, não nos fiscalizavam durante a execução do trabalho. Participávamos de reuniões com os clientes para podermos opinar quanto a viabilidade das alterações ou inovações a serem feitas e até mesmo para colocá-los a par dos recursos e técnicas utilizadas no desenvolvimento do projeto, muitas vezes era necessário convencê-los de que as modificações acarretariam em grande mudança estrutural e consumiriam muito tempo. Pode ser dito que os únicos que entendiam do código e do projeto em geral eram os programadores, nem mesmo o diretor de informática tinha familiaridade com toda a modularização e muito menos com a codificação.
Como a equipe de trabalho consistia em ``designers'' e programadores, a interação foi bem tranqüila, principalmente devido a relação de amizade existente entre todos e pelos programadores serem colegas de faculdade. Uma diferença fundamental entre membros da empresa era sobre o ponto de vista e forma de encarar os desafios, dentre os diferentes tipos de personalidades podemos agrupar os membros da empresa em três grupos: os que procuram por soluções prontas ou ``sugam'' informação de quem a conheça, os que preferem trabalhar somente com ferramentas já conhecidas e não gostam muito de inovar e de novos desafios e finalmente, os que procuram sempre desenvolver sua solução e estão sempre atrás de novidades e inovações.