29 Aug 2005
Que bom que não foi comigo!
Secador de Cabelo Mondial Ciclone SC-02 18...
Fogão Esmaltec Bahamas Glass 6 Bocas
Li no Cadafalso um artigo superlegal, que no finzinho tinha um link para uma notícia interessante: Computer Associates terá de devolver dinheiro ao TRF-3.
De acordo com a notícia, o TRF-3 investiu cerca de dez milhões de reais no sistema que nunca funcionou, causou prejuízos, mau atendimento, lentidão. A causa do problema seria um servidor inadequado ao volume de usuários e requisições simultâneas. No fim das contas o sistema antigo voltou a funcionar.
Engraçado que o sistema antigo já devia ser inadequado, ou não estaria sendo trocado; porém, com toda a inadequação ainda é melhor que o sistema de dez milhões, com o nome da CA por trás.
Não sei que servidor os caras têm, quais as tecnologias utilizadas na implementação do sistema, qual o banco de dados, nada disso. Mas uso esse fato apenas como inspiração para falar de algumas abordagens que tenho visto por aí que me são, no mínimo, angustiantes.
Por exemplo: tenho visto sistemas implementados usando o Terminal Service como meio de comunicação. Ou seja, um servidor Windows 2003 (ou 2000 Server), e diversas estações clientes acessando-o por Terminal Service. O servidor tem que ser muito bom, ter muita performance, muitos recursos, e as máquinas clientes também não ficam muito atrás. Apesar disso, devido à maneira como o protocolo é implementado, a performance é pobre (para não dizer podre), tanto para atualizar interface quanto para efetuar procedimentos que exijam mais processador.
Outra abordagem que continua exigindo estações muito boas é a de ter os programas instalados localmente, como clientes de um servidor de banco de dados remoto. A performance aumenta muito, porque divide as necessidades de processamento. Porém a atualização do software fica complicada, no que concerne à distribuição de novas versões.
Sou propenso a crer que aplicações web ainda sejam o melhor de dois mundos: processamento centralizado (o que há de importante ocorre no servidor HTTP, que pode muito bem ser uma máquina diferente do servidor de bando de dados), baixa utilização de rede (excetuando-se softwares mal escritos) e interface agradável, bem como (pelo menos na teoria) uma certa independência de plataforma. Porém, a web foi criada para compartilhar documentos, e não para ser ambiente de execução de programas. Apesar de todos os avanços das linguagens de programação para que isso se torne possível, o HTTP continua sendo um protocolo stateless, e o navegador continua estando totalmente nas mãos dos usuários. Com pouca ou nenhuma dificuldade um usuário pode simplesmente desativar o Javascript, e funções de formatação e comunicação que dependam do cliente para funcionar deixarão de existir, expondo as fraquezas do ambiente para fazer aquilo para que não foi projetado.
Lamento, contudo, que não seja mais aceitável (para o usuário médio) a utilização de sistemas em modo texto. O protocolo SSH é muito mais leve do que qualquer protocolo “gráfico”, e com um pouco de boa vontade dá para escrever programas quase tão agradáveis visualmente quanto os orientados a janelas a que a maioria das pessoas está habituada.
Só para comparar: consideremos, para simplificar, que cada pixel na tela precise de um byte para ser levado do servidor ao cliente. Uma tela típica de 1024×768 representa um tráfego de 768kB. Consideremos também uma compactação absurda de 50:1, e teremos um tráfego, para uma única tela, de uns 15.700 bytes. Claro, o protocolo é inteligente o suficiente para só transmitir as alterações que realmente ocorreram na tela, o que acaba diminuindo um pouco o tráfego, mas isso é irrelevante neste momento.
Já em modo texto, uma tela típica de 80×25 exigiria 4.000 bytes para ser transferida, já considerando que além do texto é necessário mais um byte para a informação de cor de cada posição na tela. Considerando uma compactação de apenas 4:1 (contra a de 50:1 do exemplo anterior), meros 1.000 bytes resolvem o problema de transferência da interface com o usuário. Pelo menos 16 vezes menos do que a abordagem gráfica.
É claro que isso não passa de um delírio meu. Embora iniciativas como o Charva amadureçam rapidamente (agora até mesmo os eventos do mouse são suportados, contanto que o cliente SSH os reporte), não creio que o usuário médio fosse aceitar uma solução como esta.
E assim a indústria do hardware vai crescendo, para suprir necessidades que poderiam ser atendidas com um projeto adequado de software. Ou não.
Textos possivelmente relacionados a este
