Andrei Hilário Catarino (andrei@linux.ime.usp.br)

número USP : 2946555

Empresa: Humpty Dumpty Informática S/C Limitada

Supervisor : Andréa Maria Altino de Campos Loparic

Orientador : Prof. Dr. Yoshiharu Kohayakawa

Realizei meu estágio na empresa Humpty Dumpty Informática, que utiliza o nome fantasia de That's Internet. A That's Internet foi fundada em 1996 como um dos primeiros provedores de Internet do país. Oferecendo acesso a Internet, hospedagem e construção de páginas de Web e listas de discussão. Como a That's Internet está na área de Internet desde o seu início no Brasil, passou por diversas situações que causaram grande impacto nos provedores, como o acesso ilimitado a Internet, num período em que a empresa, assim como a grande maioria, oferecia o serviço por horas de utilização; a entrada de empresas de acesso gratuito também causou um impacto negativo na empresa.

Inicialmente o provedor That's Internet ficava no escritório/sede, porém no final de 2000 mudou-se para uma empresa tercerizada que cuida dos acessos dos clientes bem como da máquina que os hospeda. Além de um significativo aumento de banda, obteve-se com essa mudança uma melhor relação custo/benefício. O escritório da empresa passou somente a lidar com a construção de páginas de Web, desenvolvimento de programação e design além de reunião com os clientes.

Já conhecia a That's Internet antes da minha contratação como estagiário. Assim quando a empresa precisou de alguém para realizar a programação do Portal BR, me contatou e expôs o problema.

Para se entender melhor o que é o Portal BR vou explicar a situação que precedeu a sua necessidade.

Mais de 100 (cem) provedores de pequeno e médio portes de diversas regiões do país eram associados ao Portal Nacional que tinha por objetivo fortalecer o meio dos provedores, além de facilitar a comunicação entre eles e possíveis trocas de experiências. Além disso o Portal Nacional fornecia uma página em comum para todos os provedores; estes podiam alterar algumas cores, adicionar links ou alguns textos e banners, mas a estrutura geral era a mesma : uma coluna na esquerda com alguns links comuns e outros próprios de cada um, notícias, artigos, enquetes e um pequeno fórum.

Porém a estrutura de programação que mantinha o portal em funcionamento não era a ideal; gerava uma taxa de transferência diária na faixa de 12 Gigabytes (como referência a maioria dos provedores de hospedagem no Brasil permitem uma transferência de 200 Megabytes e nos EUA de 400 Megabytes) e isso era causado por uma programação (feita em Cold Fusion) que, para qualquer item selecionado, por exemplo um artigo, fazia uma consulta a um banco de dados Oracle, onde eram verificava as cores do provedor, seus links do menu esquerdo entre outros itens. Isso causava um enorme gasto com a infra-estrutura o que contribuiu para o fechamento do Portal Nacional.

Foi nesse ambiente de dispersão que fui chamado para, num prazo critico, termos desenvolvido um produto similar ao Portal Nacional possibilitando a manutenção de um grupo de associados. Pois muitos provedores não dispunham de uma equipe de programadores ou web-designers que pudessem manter uma página inicial.

Eles na sua maioria tinham o seu provedor vivendo do comércio do acesso a Internet.

Aceitei o desafio de montar um portal similar ao Portal Nacional, de uma maneira que não gerasse um trafego enorme mas que possuísse os principais itens por ele oferecidos como as enquetes, a escolha de links, e cores entre outros.

Inicialmente a equipe era composta por somente três pessoas : eu, que realizava a programação, Andrea que ajudava a definir estratégias de implementação, e Teresa, que nos dava um suporte no design.

Como estou acostumado a utilizar o ambiente Linux, e este também já era utilizado na That's Internet decidimos realizar toda a programação e hospedagem em sistema Unix; outro fator que favoreceu a sua escolha foi o custo nulo de licenças.

Restrições essas que não existiriam caso fossemos os donos da máquina, porém, após algumas consultas com os membros da equipe, além de analise de outros sites hospedados na Pair decidiu-se por ela.

Como íamos hospedar numa máquina Unix, faltava decidir em que linguagem iríamos sustentar o Portal BR. Inicialmente foi definido que a página principal e todas as outras iriam ser desenvolvidas em PHP, e que as operações realizadas em background, como geração de arquivos ou atualizações, iriam ser implementadas em Perl. Os banco de dados iriam ser implementados em mySQL, dado que existem módulos de interface de Perl-mySQL e PHP-mySQL.

Baseado nas limitações da máquina e nas linguagens de programação a serem utilizadas, passamos a definir o que manteríamos do Portal Nacional. A idéia inicial era fazer uma cópia fiel do anterior, porém implementada com a nova tecnologia. Definimos que alguns itens de menor importância seriam retirados entre eles "Frase do Dia" e "Banner Pop-Up". Porém os outros itens deveriam estar em funcionamento similar ao original.

Citarei a seguir os principais itens desenvolvidos :

A página principal possuía uma estrutura básica que deveria ser mantida durante a navegação (visualização de notícias, artigos): era o menu da esquerda e a coluna da direita. Assim, o que era alterado durante a navegação era somente a parte central da tela. Analisamos algumas soluções para manter essa navegação : uma delas foi a utilização de frames, porém esta idéia foi descartada após alguns testes; neles sempre acabava existindo uma barra de rolagem, o que não era admissível na página de abertura de um provedor. Pesquisei mais a fundo PHP e descobri que existia uma função que incluía outros arquivos inteiros numa páginas PHP (include()). Após alguns testes, vimos que essa função era a ideal, pois podíamos manter toda a estrutura padrão e alterar a parte central através de mudanças no arquivo a ser incluído nela (por exemplo um artigo ou uma notícia) evitando também a existência de barras de rolagem, pois gerávamos somente uma página, construída dinamicamente. O recurso do "include" passou a ser uma ferramenta amplamente utilizada. Através dela, podíamos acrescentar trechos inteiros na página principal, acrescentando somente uma linha no PHP.

Limitamos em três as partes que podiam ser personalizadas pelos provedores : coluna da esquerda, parte do miolo e cores da página. Para desenvolver as partes personalizadas decidimos utilizar novamente o recurso "include"; assim a página principal possuía dois includes extras : esquerda.html e miolo.html. Esses dois arquivos eram gerados e atualizados mediante um interface chamada de publicador, que ficava hospedado no servidor central. Os arquivos atualizados eram enviados para os clientes nas atualizações (item que irá ser melhor descrito abaixo). As cores também eram alteradas através do publicador, porém o método de alteração das cores no resultado final era feito através de um arquivo CSS: são gerados arquivos de estilo, que depois são chamados pela página principal para implementa-los em tabelas, fontes e links, através de um nome (por exemplo <FONT class="titulo">).

O sistema de notícia que iríamos utilizar seria da mesma empresa que fornecia para o Portal Nacional, Baguete (www.baguete.com.br). As notícias eram fornecidas diariamente em três períodos (manhã, tarde e noite), todos os dias, através de um sistema de envio por ftp. O primeiro problema era o envio do arquivo, inicialmente eles enviavam um arquivo de banco de dados em Access. Tive muitas dificuldades para encontrar uma solução para ler o arquivo e trata-lo em ambiente Unix. Finalmente conseguimos mediante conversas com a empresa Baguete, que ela nos fornecesse as notícias através de arquivos texto: um arquivo com todas as notícias de todos os editoriais (esportes, ciências, economia, informática e mundo) e outro com uma notícia extra. Isso facilitou muito o meu trabalho, visto que assim só foi preciso ler um arquivo texto e através dele gerar todos os arquivos de notícias.

Eram gerados todos os dias aproximadamente 200 arquivos de notícias, num formato que permitia a sua inclusão na página principal. Essas notícias eram acessadas através de uma capa onde constavam todas as manchetes de cada editorial. A capa também era gerada através do arquivo de notícias enviado.

Todo o sistema de geração de notícias funcionava automaticamente, tanto a leitura do arquivo como a sua manipulação e posterior substituição por um mais novo.

Atualmente as notícias são compradas de outro fornecedor, Plugar (www.plugar.com.br), que utiliza um sistema mais prático para a sua implementação, através de scripts em Javascript. Assim não é mais preciso gerar arquivos de notícias ou de manchetes; basta usar somente uma chamada de Javascript.

As principais decisões para esta mudança levaram em conta três pontos : preço, implementação e melhorias para os clientes. A sua implementação foi fácil, necessitando somente de uma validação de cada cliente, feita pela central da Plugar. O melhor ganho foi em relação a qualidade das notícias, pois passamos a contar com atualização quase instantânea, ao contrário de atualizações controladas e limitadas.

A previsão do tempo permitia que cada cliente tivesse na página principal a previsão para a sua cidade sede. Assim, um cliente de São Paulo teria a previsão da capital paulista, enquanto um cliente de Diadema teria a previsão da sua cidade. Isso foi obtido com a alteração de uma variável que discriminava a cidade de cada provedor.

O tempo é fornecido 2 vezes por dia, através de uma arquivo no formato texto que contém a previsão para o dia atual e para os 3 dias seguintes. O pacote comprado pelo Portal BR inclui todas as capitais do Brasil, além de mais 200 outras cidades. O Portal BR possui um sistema que permite consultar a previsão nessas cidades. Para isso é gerado diariamente um arquivo para cada cidade, que está num formato padrão lido pela página que gera a previsão do tempo. O seu sistema de atualização é bem semelhante ao utilizado pelas notícias, no seu início.

Para implementar o "Jogo Rápido", que na verdade é uma enquete com duas alternativas, foi criado um banco de dados em mySQL, onde cada pergunta e seus respectivos votos são armazenados num registro. A sua atualização é feita pela equipe mantenedora do Portal BR através de uma interface simples, o que contribui para agilizar a sua renovação.

A "Minha Opinião" é um sistema onde se faz uma pergunta e os usuários podem dar suas opiniões.

O sistema também é implementado através de um banco de dados. E possui uma interface semelhante à do "Jogo Rápido" para ser alterada.

No início, esses dois itens foram os únicos que exigiram uma interação com um banco de dados. Através de algumas pesquisas na Internet obtive exemplos de como interagir com mySQL através de PHP.

A sua modelagem foi simples e não representou muito tempo em relação a sua implementação.

Tínhamos então um servidor do Portal BR e seus clientes, que eram os provedores. A idéia era que todos os provedores tivessem todos os arquivos na sua própria máquina, evitando assim ao máximo a comunicação com o servidor central. Comunicação essa que ficou restrita somente à interface com os publicadores e à interação com o banco de dados.

Como gerávamos as notícias e o tempo em prazos determinados, além de criar um novo artigo por semana, precisávamos atualizar os provedores ao menos 4 vezes por dia. Por questões de segurança foi decidido que não teríamos acesso às máquinas dos provedores através de SSH. Assim tivemos de analisar qual seria a melhor solução, tanto para nós como para os servidores, em segurança e em praticidade. Como estou habituado a utilizar o Linux, já havia utilizado o comando wget, que permite o download de um determinado arquivo, ou arquivos. Assim, pesquisei para verificar a sua segurança e decidimos por utiliza-lo na atualização. Cada provedor iria baixar um arquivo em comum e outro próprio.

O arquivo em comum conteria novos artigos, os arquivos do tempo atualizados e outros. Já o arquivo próprio teria somente os arquivos alterados pelo publicador (esquerda, miolo, css).

Para garantir a sua automatização, pedia-se aos provedores que programassem a execução de um script que chamava o wget no crontab. Dessa forma tínhamos os próprios provedores gerenciando a sua atualização.

O pré requisito para o cliente poder realizar a instalação era possuir o Apache instalado.

Para realizar a instalação, criei um arquivo que continha os arquivos básicos. Entre eles cito a estrutura inicial (uma página principal, os arquivos da esquerda, miolo, notícias, tempo, artigos entre outros), um script de atualização e informações de como alterar os arquivos que posteriormente passariam por uma atualização.

Nesse período, fui o encarregado de dar suporte aos clientes. Tive de lidar com clientes com conhecimento técnico em informática e outros sem nenhum conhecimento, com o pessoal do suporte e até mesmo com o dono do provedor, que muitas vezes fazia o papel de departamento técnico.

Alguns dos problemas que ocorreram foram com provedores que não possuíam o Apache instalado e estavam fazendo isso pela primeira vez. Nesses casos, além de dar suporte para o nosso produto, também tive de dar um suporte em Linux. A maioria dos provedores não se mostrava interessada no novo funcionamento do Portal BR, bastava que ele funcionasse. Alguns em compensação gostaram de saber como itens como atualização, segurança e o publicador funcionavam. Algumas dessas observações sobre o funcionamento foram muito úteis e foram implementados em posteriores atualizações.

Após a instalação do Portal BR e sua consolidação, a empresa pode começar a pensar em expandir.

A That's Internet passou a ter uma equipe que cuidaria dele. Essa equipe possuía um coordenador, Andrea, um programador, eu, um design, Teresa e um criador de conteúdo, Marcos. Além de um responsável pelas contas Malena.

Realizamos reuniões semanalmente decidindo que artigos devem ser criados ou irem pro ar, que novos itens realizar e como tratar de eventos do cotidiano, como a Copa ou as eleições. A interação com a equipe é fundamental, pois o conteúdo decide o design a ser utilizado, e a programação deveria se encaixar nela.

Através desse trio : design-programação-conteúdo criamos diversos módulos, alguns que ficaram no ar somente durante o evento.

Dentre esses módulos destaco:

O cartão virtual é um dos nossos módulos de maior sucesso.

Para a Copa do Mundo decidiu-se realizar um jogo de perguntas, onde no lugar de perguntas teríamos palpites. Seriam três tipos de palpites : vencedor, líderes de grupo e vencedor de jogos com respectivo placar. Cada palpite tinha um limitante da data, o que precisava de um controle automático da própria página. As dificuldades deste módulo foram: quantidade de dados a serem tratados (existiam 64 jogos); a modelagem dos bancos de dados; e a interface. Todo o sistema foi implementado em PHP e mySQL.

Cada usuário iria possuir um login e senha únicos, que permitiam o seu voto dia a dia. Foi criado também uma interface amigável para a entrada dos resultados dos jogos e posterior averiguação dos vencedores.

A agenda cultural é um programa que necessita de um auto-gerenciamento, pois ela deve retirar automaticamente eventos já realizados, além de informar dinamicamente quais as cidades que possuem algum evento em cartaz. O responsável pelo criação do conteúdo do Portal BR iria ser o Editor da agenda, mas permitíamos também a inscrição de outras pessoas como agentes culturais. Essas pessoas eram autorizadas pelo editor a inserirem eventos, que passavam por uma prévia triagem antes de irem ao ar.

Todo o sistema foi implementado em PHP e mySQL. Nesse módulo, iniciamos uma maior interação da programação com o conteúdo e design: dependendo do evento ser grátis, de censura livre, ou da categoria (teatro, cinema entre outros), alterávamos a página, inserindo uma imagem para grátis e um símbolo diferente para cada categoria. Essa alteração permitia um maior variação da página de forma automática.

Para o segundo turno das eleições decidimos pela criação de um jogo de perguntas, num total de 18 perguntas ( 3 por dia, durante 6 dias), permitindo em cada uma somente uma tentativa de resposta. Nessa programação pude utilizar os conhecimentos usados na criação do jogo de palpites para a Copa do Mundo. Mas como o banco de dados era muito diferente, assim como as respostas, foi necessário uma modelagem totalmente nova. Como na Copa, cada usuário cadastrado possuía um login e uma senha.

Cada módulo era decidido com um prazo de pelo menos um mês de antecedência; somente nas eleições o prazo foi de uma semana, desde a elaboração até a implementação e disponibilização do módulo.

Para definirmos um módulo novo, fazíamos durante a reunião semanal uma breve discussão do que seria mais interessante ir pro ar. Considerando também o que os clientes mais pediam. O cartão virtual era um desses pedidos. Após a definição do módulo, passávamos para a fase de discussão dos itens que fariam ou não parte dele, além de tecnologias implementadas, e futura administração do mesmo.

Alguns pontos falhos nessa estrutura resultaram em alguns problemas, um deles era a falta de um cronograma

de atividades, o que resultava em atrasos, pois o coordenador da equipe não sabia o que cobrar para se ter um acompanhamento das atividades já realizadas ou por serem realizadas. Outro problema, que causava o atraso além da perda de trabalho era a mudança das especificações do módulo em relação ao pedido original. Um problema que só foi resolvido após o segundo módulo realizado foi a integração do design com a programação, onde somente após várias reuniões conseguiu-se um método que permitia um rápido andamento do projeto.

O acompanhamento é feito com maior dedicação após a sua "inauguração", onde se detecta erros e melhorias que devem ser implementados. Após um período de aproximadamente duas semanas a equipe deixava de acompanhar o módulo, que passava a ser administrado pelo responsável encarregado, o qual a qualquer nova idéia ou problema acionava a equipe na reunião semanal.

Além dos trabalhos realizados no Portal BR, realizei outros trabalhos de programação, estes trabalhos aproveitavam a estrutura já definida de responsabilidades, o que contribuía bastante na sua especificação.

Dentre os outros projetos desenvolvidos destaco:

O projeto da Discurso Editorial foi um dos mais empolgantes. Consistia no desenvolvimento de uma livraria virtual, com compras on-line e pagamento através de cartão de crédito ou boleto bancário.

Nesse projeto pude conhecer melhor algumas ferramentas que não havia necessitado utilizar nos módulos do Portal BR, como o uso de cookies e a interligação com o banco para se efetuar a cobrança.

Além de necessitar modelar um banco de dados para suportar o catálogo de livros e de clientes, precisei desenvolver uma tecnologia de envio de relatórios e de alteração dinâmica dos produtos, quando em promoção ou não.

O projeto da Anpof - Associação Nacional de Pós-Graduação em Filosofia consistia na organização das inscrições no X Encontro Anual da Anpof. Através de um banco de dados e de uma interface feita em PHP, os interessados realizavam sua inscrição via Web. O programa automaticamente considerava se o inscrito era professor ou aluno e a data da inscrição, para determinar o valor da taxa.

Este trabalho não possuiu uma especificação muito detalhada do que era o desejado. Assim muitas alterações foram sendo realizadas com o produto já no ar. Além disso, os relatórios dos inscritos e pagantes não foram previamente definidos; assim tínhamos muitos relatórios desnecessários e outros eram necessitados. Estes relatórios faltantes iam sendo feitos à medida com que era percebido a sua falta, o que muitas vezes me tirava de um determinado projeto por um dia para atender essas requisições.

A SOF - Sempre-Viva Organização Feminina, possuía uma equipe de jornalistas, porém não possuía um método prático de publicação das matérias. O projeto consistia no desenvolvimento de um publicador de notícias, que pudessem ser aprovadas ou não por um editor.

Apesar de no início achar que esse trabalho seria complexo, pude resolve-lo utilizando basicamente um banco de dados, que permitia editar, apagar e inserir novos itens. Pude perceber como as vezes um problema parece ser mais complicado na especificação do que o é na prática.

O próprio desenvolvimento do Portal BR foi um dos maiores desafios profissionais que realizei. Nele tive um prazo crítico, que não podia ser ultrapassado, e que exigiu um aprofundamento nos conhecimentos de programação para solucionar problemas, além de permitir o acompanhamento de um produto do seu início até a sua instalação pelos clientes. O período que passei dando suporte à instalação foi bastante produtivo, pois tive que interagir com diversos níveis de clientes.

Os diversos módulos criados para o Portal BR também permitiram uma ampla variedade de projetos, apesar de quase toda a programação estar centrada em PHP, Perl e mySQL.

Um fato que encorajava a equipe eram alguns emails que elogiavam o nosso trabalho, fosse pela sua originalidade, como na Copa ou pela sua ampla cobertura, como ocorreu nas eleições.

Uma frustração que tive em relação a empresa foi a ausência de um treinamento. Tinha o apoio de livros que a empresa possuía, porém a maior parte das dúvidas tive que sanar com meus colegas ou através de buscas na Internet. A consultora de tecnologia tem mais familiaridade em outras linguagens como html, Javascript e Pascal; no entanto, deu-me bastante apoio na hora de modelar um sistema, analisando comigo quais os campos necessários e os tipos de acessos e consulta que seriam permitidos pelo sistema.

A interação com a equipe era ideal, onde todos sabiam onde começava a sua responsabilidade no projeto e onde começava a dos outros membros da equipe. Além disso, todos tinham conhecimento do que cabia a cada um fazer. A distribuição da responsabilidades dos módulos após a sua inauguração também funciona muito bem, ficando claro a todos quem administra o que e qual o motivo que levou a essa escolha. Cito por exemplo que o responsável pelo design administra também o módulo do cartão virtual e a entrada de artigos no ar, pois exigem mais trabalho de imagens e diagramação, apesar do artigo ser escrito pelo responsável pelo conteúdo.

Este administra a agenda cultural, pois ela necessita de um conhecimento melhor da utilização das palavras.

O coordenador geral, além de manter a equipe unida, e controlar o andamento dos projetos, também realizava um controle geral do Portal BR, verificando o que estava se tornando obsoleto e fazia a maior parte do trabalho de analisar os novos módulos a serem criados.

Na área de Internet, as decisões devem ser tomadas rapidamente, assim como a decisão da melhor ferramenta a ser utilizada. Nesse estágio, também pude perceber como realização de uma especificação e o modelamento de um banco de dados bem feitos poupam trabalho no futuro, consertando erros ou refazendo itens inteiros.

O cotidiano USP-estágio teve algumas dificuldades, mas também muitos pontos positivos. Como a empresa fica perto da USP eu podia sair das aulas e almoçar sem tanta pressa, porém quando tinha que fazer exercícios programas (Eps) ou estudar para alguma prova, via o meu dia se estender até mais à noite. O clima na empresa era de apoio aos estudos, o que permitia flexibilizar os horários, fato que ajudou muito quando tinha provas mais importantes.

Muitas aulas da computação se mostraram necessárias na prática, como engenharia de software, banco de dados, laboratório de banco de dados além de estrutura de dados, administração de redes Unix, redes e interação homem-computador. Muitas vezes percebi como uma boa documentação facilita quando se tem de alterar um programa feito há algum tempo, e como também é importante saber montar uma interface amigável do seu programa para os usuários finais.

Outro ponto importante foi a diferença entre o trabalho em grupo na USP e o trabalho em grupo na empresa. Como tínhamos na empresa funções mais determinadas, como programação, design, durante as reuniões e distribuição de trabalhos todos já sabiam qual parte do trabalho lhes seria determinado, o que agilizava bastante as reuniões. Já nos trabalhos realizados na USP, muitas vezes se perdia bastante tempo dividindo as tarefas.

Como trabalhei numa empresa voltada mais para a Internet, pude lidar com trabalhos pedidos por terceiros. Ao desenvolve-los ganhei muito mais confiança nas minhas habilidades e percebi o quanto tinha aprendido na USP. Muitas dificuldades que encontrei eram resolvidas através de buscas na Internet, onde as vezes outros já haviam tido os mesmos problemas e divulgavam as soluções encontradas.

Tenho orgulho de ter podido desenvolver o Portal BR. Dos mais de 100 provedores do Portal Nacional tivemos 20 que se associaram a ele, com uma atuação que se estende por 5 estados (SP,RJ,ES,GO,DF). Isso exigiu uma grande responsabilidade minha, mas também um grande voto de confiança da empresa.

Todos as semanas aprendia alguma coisa nova, fosse em PHP, mySQL, Perl ou em se lidar com o cliente, fato que acontecia sempre que alguma reunião era necessária. Pude não só desenvolver minhas habilidades em computação, como minha postura em tratar o cliente, vendo que muitas vezes um simples programa resolve inúmeros problemas.

Agradeço ao Instituto de Matemática e Estatística, aos professores e colegas que juntos me auxiliaram tanto na minha formação acadêmica e profissional como também no meu desenvolvimento critico e pessoal.

Utilizei muito os livros :

PHP - Professional PHP - Jesus Castagnetto, Et Al, Harish Rawat & Sascha Schumann - Editora Makron

Perl - Programming Perl - Larry Wall, Tom Christiansen & Randal L. Schwartz - Editora O'Reilly

MySQL -Teach Yourself mySQL - Mark Maslakowski - Editora Sams

E os sites :