Postagem em destaque

A incrível velocidade do Go

Imagem
Um dos motivos que gosto do Go (a linguagem de programação, não o jogo), é que ele é extremamente rápido. E não estou falando de utilizar goroutines pois aí é covardia. Estamos migrando um sistema de Coldfusion para Go e PHP e uma das rotinas insere um registro no banco de dados no início e outra no fim do processo. Pense como se fosse um log, mas um log específico para essa rotina. Dessa forma: 2023-05-18 17:45:03. 687     ... [processaImagem] Incorporando imagem 2023-05-18 17:45:03. 688     ... [processaImagem] Imagem incorporada Entre o inicio e o final do processamento levou 1ms. Até aí, tudo bem, se não fosse o fato dessa tabela ter o campo timestamp como parte da chave primária. Se reparar, o tempo é definido em milissegundos. Com o Coldfusion esse processo dura cerca de 20ms. Simplesmente migrando para Go, o tempo caiu muito, para menos de 1ms e assim, começou a dar erro de chave duplicada. A solução? Depende, sempre depende. No nosso contexto, a mais simples foi feita, pois nã

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

Netflix não mostra ícone de streaming

Google Hacking

FTP não funciona no PHP