Postagem em destaque

Huguinho e Zezinho surfando com granizo

Imagem
Certa vez, em outubro de 2023, Huguinho e seu amigo Zezinho foram surfar no final da tarde. O vento estava forte e a chuva, constante. Quando chegaram perto da praia, mal conseguiam segurar suas pranchas. O mar estava bem mexido, e ainda tiveram que andar cerca de 1 km até o pico. Quando estavam se aproximando, começou a cair granizo! Dava para ouvir claramente o barulho das pedras contra as pranchas. Eles se abrigaram embaixo do posto avançado dos salva-vidas, mas não adiantou muito. Ficaram olhando o mar — que estava bem agitado e quebrando bem longe — e perceberam que estava difícil passar a arrebentação. Como o granizo não parava, decidiram entrar assim mesmo. Logo que entraram no mar, o granizo cessou, mas aí começou o verdadeiro desafio: passar a arrebentação. Depois de levar várias séries na cabeça e quase sem forças, finalmente conseguiram. E começaram os raios! Quando estavam quase decidindo sair por causa deles, os raios pararam. Ufa! É algo estranho: você está lá, só você (c...

Artigo 6 - Bug do ano 2000

(Publicado originalmente entre 1994/95)

Bug pode ser traduzido como problema, erro, defeito. Só que o do final deste milênio será provavelmente o maior de todos os tempos. O problema todo começou por falta de planejamento ou visão. Pois as datas, dentro dos programas, eram armazenadas no seguinte formato: dd/mm/aa. Ou seja, dois dígitos para o dia (correto), dois dígitos para o mês (correto) e dois dígitos para o ano (econômico). Econômico porque a até alguns atrás o espaço para armazenamento (tanto em memória quanto no disco rígido era extremamente caro). A data no formato dd/mm/aa precisa de 25% menos espaço do que no formato dd/mm/aaaa. Um registro que tenha 10 datas no formato dd/mm/aa, precisará de mais 20 dígitos para ficar no formato dd/mm/aaaa. Se existirem 100 mil registros, o arquivo irá crescer 2 milhões de dígitos.

Por exemplo, quando num sistema (programa), que armazene as datas no formato dd/mm/aa, entramos com a data de 15 de Janeiro de 2000, o sistema irá guardá-la como 15/01/00. Se fôssemos tirar um relatório com data maior que 31/12/98 o sistema não mostraria essa data de 15/01/00, porque (para o computador) 15/01/00 é menor que 31/12/98.

Existem soluções como a que um engenheiro de Joinville apresentou, que consistia em utilizar os meses de 13 a 24 para representar os anos de 2000 a 2099, 25 a 36 para os anos de 2100 a 2199, e assim até os meses de 85 a 96 para os anos de 2600 a 2699.

Para se corrigir um sistema de tamanho médio, como um Sistema Comercial Integrado (contas a pagar e a receber, estoque, faturamento e banco), de cerca de 100 mil linhas de programa, a um custo por linha de código de US$ 0,70, gasta-se US$ 70.000,00. Pelo menos alguém saiu ganhando nesta situação: os programadores. Que já estão, em alguns casos, até negando serviço. Além disso, o preço por linha de código a ser verificado está subindo sem parar. Estima-se que até o ano 2000 o preço por linha de código chegue a US$ 7,00, dez vezes o preço atual.

E não é só no ano 2000 que os programas começarão a acusar o problema. Desde já, os programas precisam estar preparados, pois num financiamento de 5 anos (60 meses), as datas que forem lançadas deveriam estar no formato dd/mm/aaaa, caso contrário, essa pessoa passaria a ter um dívida de 100 anos!

Comentários

Postagens mais visitadas deste blog

Google Hacking

Netflix não mostra ícone de streaming

Radar no KM 175 da BR101