A coisa é mais ou menos assim: nos filmes americanos, o cara está no meio de um deserto e acha um fio de cabelo: “– De quem será?”.
Tira um notebook da mochila, mal abre a tampa já está conectado, coloca o fio de cabelo num hair sensor e …
.. vupt! Lá está o retrato do suspeito, frente e perfil, com direito a saber até o endereço da avó dele.
Também nesses filmes, a 20 segundos do lançamento do míssil atômico, aparece um programador, digita rapidíssimo (toca bongô no teclado) e já altera toda a programação, fazendo a bomba cair exatamente no esconderijo do bandido!
Mas, “aqui na terra nós jogamos futebol”, como na canção de Chico Buarque. Você demora alguns meses para montar um sistema web com tudo o que há de melhor: interatividade, segurança, banco de dados etc. Mas nem sempre as empresas estão preparadas para absorver inteiramente um sistema nesse nível.
Isto porque, numa mesma empresa, há um certo desequilíbrio de equipamentos, conexões, treinamento de usuários etc. Nos grandes centros, nos departamentos mais elitizados (diretores, secretárias de diretores e daí para baixo), em geral estão as melhores máquinas e o melhor apoio logístico.
Esta é uma tendência brasileira: colocar os equipamentos mais obsoletos em locais mais distantes, menos favorecidos na tecnologia e paradoxalmente com uma atividade mais intensa.
Então, você, que planejou receber informações online, se depara com o Rústico, ou seja, simplesmente uma combinação de despreparos, no usuário e no equipamento.
Uma certa filial, por exemplo, localizada em certa cidade, possui um posto de informações que deveriam estar constantemente ligadas com a Internet mas enfrenta alguns probleminhas:
1. O usuário é “leigo assumido e resistente”, “catamilhógrafo” estressado que quase não tem tempo para digitar coisas no computador (isso não é nada – geralmente ele se acerta).
2. O equipamento é um dos mais antigos (daqueles que às vezes são doados a instituições de caridade), HD superlotado, sem CD, um tanto quanto enxovalhado, possivelmente rodando ainda com um (grátis) Windows 95.
3. Para a internet há um provedor numa cidade a uns 100km do local – conexão discada e ainda pagando DDD, muitos ruídos e quedas, não funciona em horário de almoço etc.
Poderíamos, sem dúvida, fornecer um notebuqui como o daquele americano lá de cima, no deserto. O duro é convencer ou viabilizar investimentos dessa natureza.
Numa dessas fui chamado a estudar o assunto: viabilizar um sistema de custos, já existente, para funcionar web com SQL Server, porém com uns vinte e poucos elementos “rústicos” na parada.
Dados sobre mão–de–obra, máquinas e materiais teriam de ser digitados para compilação diária. Devido a uma certa complexidade, a digitação deveria ser consistida no ato, junto a um padrão muito variado no dia–a–dia.
Uma solução plausível: comunicar–se uma vez ao dia, (menor tempo possível). Nessa hora o rústico estaria recebendo tabelas e parâmetros para iniciar a sua digitação consistida (offline), ao mesmo tempo em que enviaria os dados já digitados no dia anterior.
Seria, digamos assim, uma web rústica, com alguns pontos estratégicos levantados e resolvidos assim:
Para melhor visualização vamos dar o tratamento de Filial para os rústicos e de Central para o local mais “bem suprido”.
Tramitação
Não foi possível instalar SQL nas filiais, muito menos alojar tabelas do projeto (algumas imensas). Foi decidido então criar uma “storage” especialmente populada para cada filial – dados respectivamente filtrados para cada âmbito.
Por isso, cuidamos de “inventar” um banco de dados também rústico, chamado SpeeDB – muito pequeno, compacto e robusto, do qual foram eliminados alguns índices e relacionamentos desnecessários para esse tipo de aplicação.
Aqui cabe esclarecer: o SpeeDB não é um produto de software. É uma técnica que se constitui no método em si e nos fontes geradores e resultantes em aberto (livres), pré–escritos, documentados e testados.
O SpeeDB gera, sem maiores esforços de programação, um programa “extrator”, um “receptor”, um ou mais “visores/atualizadores”, um “expedidor” e um “coletor”.
O extrator funciona na Central: comunica–se com o banco de dados (SQL, Oracle etc.) e, atendendo a critérios, gera todo o material necessário para cada filial. Esse mesmo programa já cria elementos para respectiva distribuição via internet (pode ser FTP e/ou SMTP – este último meu preferido porque geral e–mails, com que os usuários mais se identificam).
O receptor, instalado em cada filial, administra a recepção das tabelas que vieram via internet e, usando um protocolo especial, habilita o usuário a iniciar trabalhos de digitação (“destrava”, em oposição ao expedidor).
Os visores/atualizadores são programas que podem ser instalados nos rústicos e que resolvem consultas, digitação local muito bem validada, emissão de catálogos e relatórios também locais (mesmo em impressoras antigas).
O expedidor também reside na filial: ele “empacota” o resultado da digitação consistida (normalmente é “movimento”, porém pode ser ainda um pré–processo de alterações cadastrais, por exemplo). Em seguida, prepara o material de expedição via internet (FTP e/ou SMTP) e, a partir desse momento, ele “trava” a digitação, que só poderá ser reabilitada pelo receptor no próximo encontro.
O coletor, situado na central, recebe todos os dados que vão chegando, concentrando movimentos em uma única tabela, já em banco de dados (SQL, Oracle etc.), ao mesmo tempo em que controla um protocolo de chegada (quem já mandou, quem falta).
Assim, a central pode ainda realizar operações super fortalecidas:
– revisar o movimento em uma crítica de coerência (por exemplo, um mesmo veículo estar sendo usado ao mesmo tempo em dois locais diferentes);
– auditar alterações cadastrais ou lançamentos acima dos limites antes de efetivá–los;
– incorporar lançamentos privilegiados e/ou atrasados (sempre há um rústico que esqueceu de lançar uma “coisinha”).
A storage gerada no SpeeDP é muito pequena, jeitosa para viajar via e–mail e/ou, até mesmo, numa eventual e drástica falha de comunicações, via disquetes e malotes. Os “pacotes” ficam numa média de 50 a 250Kb, por aí.
Preparo de usuários
Na central, surge a figura do monitor do sistema: mantém tabelas e parâmetros fundamentais, administra a expedição e o recebimento de dados.
Na filial, não há muito o que treinar – as operações são muito intuitivas e na maioria das vezes executadas com um simples clique no menu/roteiro.
Programas
Os programas são gerados com fontes em aberto, muito bem documentados e livres para alterações e adaptações (crítica consistência, validade e coerência, mensagens, terminologia etc.).
Paradigmas tipo skeleton, também abertos a modificações e adequações a qualquer linguagem de programação. Em princípio foram montados para Visual Basic (VB6 comum).
Esta técnica de geração usa os mesmos algoritmos PnPAP e PnPOP já publicados em 1982, com pesponto de segmentos. A sua eficiência foi simplesmente transcrita para estrutura e recursos atuais.
A formação de fontes toma por base headers de grids, cuja definição pode ser criada standalone e/ou importada diretamente do banco de dados oficial.
Além das aplicações para o tratamento web rústica, consegui gerar ainda, como teste, documentação de tabelas, documentação para interface, programas importadores e exportadores (texto, Clipper DB, Excel – direto, sem Office).
Para melhor desempenho e agilidade de manutenção, foram montados, em VB, cerca de três forms que, incorporados inicialmente a um projeto, trabalham ainda no IDE e passam a administrar a geração de módulos em SpeeDB, forms para visores, updating e muito mais.
Havendo qualquer mudança nos formatos, os programas as assimilam automaticamente, tal como num BD mais sofisticado.
Conclusão
Esse tipo de aplicação pode ser adotado sem dúvida para empresas tipo construtoras, agroindústrias, serviços etc, que geralmente lidam com ambientes rústicos. Os processos SpeeDB funcionam como um add–on para o sistema principal (web, Net etc), sem qualquer interferência.
Os dados recolhidos dos rústicos simplesmente “embarcam” no fluxo como se tivessem sido atualizados no gabinete do diretor–presidente.
Não digo que essa programação seja tão rápida quanto a do americano que batuca no teclado e desarma uma bomba em 20 segundos, mas, considerando pequenos ajustes que podemos fazer para cada empresa, o uso do SpeeDB quase não onera cronogramas preestabelecidos e resolve muito bem, a baixo custo, situações web rústicas nesse nosso Brasil. [Webinsider]
