Perversões curiosas do mundo da TI - 5

A primeira história. Letras fatais

[ Original ]

Era uma vez, George conseguiu um emprego no escritório da Initech. A empresa acabou de alugar vários andares em um antigo prédio de escritórios que passou recentemente da categoria de declínio urbano para os elegantes cafés no térreo e o cheiro de verniz para sapatos e estofados de couro fresco em todos os outros.

Era um espaço vasto, e George estava nessa fase de sua carreira, quando deveria ter um escritório separado com vista para a pista.

Sua primeira tarefa foi corrigir o problema na versão para Mac do software da empresa. Parecia perfeito no Windows, mas os erros de renderização de fonte apareceram no OSX. Esse bug é difícil de encontrar, mas George provavelmente era detetive em uma vida anterior, então estava pronto para esse teste.

A pista mais importante foi a história do controle de versão. Nos últimos três anos, cinco desenvolvedores trabalharam no produto. Parece que cada um deles estava na empresa por cerca de quatro meses e depois foi embora. Por muitos meses eles ficaram sem alterações, então um novo desenvolvedor veio e o ciclo se repetiu novamente. Como George descobriu, seus nomes apareciam o tempo todo quando ele tentava descobrir as funções, o trabalho e as causas dos bugs do produto.

Como o aplicativo era multiplataforma, os desenvolvedores implementaram seu próprio carregador e renderizador de fontes. Pelo menos era assim que ele pensava. A estrutura interna das fontes é uma coisa perigosa e confusa, e isso se reflete no código. Também refletia o fato de que vários programadores, que não preservavam sua integridade, trabalhavam nele um por um. Foi um caos .

No código, George viu memcpy aspectos que, sem dúvida, eram ruins - chamadas inseguras para memcpy , malloc sem aritmética de ponteiro free , que trabalhavam mais na confiança do que na lógica. Mas, aparentemente, nada disso foi a fonte do problema da fonte.

Frustrado, George decidiu se aproximar dela do outro lado. Em telas com erros de renderização, sempre houve uma ou duas fontes especializadas. George carregou as fontes nos utilitários de verificação de fontes da Adobe e da Microsoft e viu relatórios de vários erros.

O código de download da fonte era ruim, mas as fontes eram ainda piores. Tendo identificado o problema, George disse a seu chefe que as fontes precisavam ser corrigidas. O chefe passou para o presidente da empresa.

No dia seguinte, o chefe se aproximou de George: "O presidente quer se encontrar com você urgentemente ".

O escritório do presidente parecia mais uma sala de conferências, mas sem uma mesa de conferência. Uma sala comprida, de um lado uma mesa, janelas por toda a parede e vista para o rio. Um presidente zangado estava sentado à sua mesa.

“O que há de errado com vocês dois? George, você está aqui há menos de quatro meses e já está desperdiçando meu tempo - você está desperdiçando meu dinheiro com alguma idéia maluca sobre um problema nas fontes ?

“Mas é sim. Eu posso mostrar .

“Na versão para Windows, a fonte funciona bem! O problema deve estar no inferno. Eu sei quanto você é pago. Talvez eu deva pegar uma calculadora e calcular quanto custa a empresa para caçar fantasmas? Ele apertou a mesa para que a calculadora ao lado do teclado pulasse um pouco.

As acusações continuaram, mas George já sabia o que faria depois da reunião. No final do dia, ele devolveu o crachá e o laptop de trabalho, juntamente com uma rude e honesta declaração de demissão.

Após uma curta licença não remunerada, George conseguiu um novo emprego. Os anos se passaram e ele já começou a esquecer o tempo gasto na Initech. Mas um dia ele viu uma mensagem sobre o lançamento de um patch crítico da vulnerabilidade do Microsoft Windows. Como se viu, "código de processamento de fonte de terceiros" pode causar a execução arbitrária de código em algumas bibliotecas do Windows. Depois de um pouco de pesquisa, George confirmou seu palpite: foi o código Initech que causou o problema. Além disso, o último binário Initech foi lançado em 2008 - um mês depois que ele deixou a empresa.

A segunda história. Trabalhe no processo, bem como abaixo e acima dele

[ Original ]

Quando Kevin conseguiu um emprego no Townbank no final dos anos 80, ele estava na mesma situação que milhares de outros programadores recém-formados antes e depois: um programador corporativo não apenas escreve código - ele precisa se manter no processo.

O processo difere dos estritos mandamentos das religiões do mundo apenas no sentido de que sua tarefa é manter a integridade do código. Glória ao processo, que seja abençoado, o processo é bom, você deve sempre cumpri-lo e, o mais importante, o processo é útil para você!

Para a maioria dos desenvolvedores, o processo não é tão ruim. Você só precisa se acostumar com isso. Preencha o formulário, obtenha aprovação, registre um plano de teste, escreva a documentação da montagem - tudo isso está em ordem. No entanto, como Kevin logo descobriu, havia no Townbank processos aos quais nem veteranos nem iniciantes podiam se adaptar.

Fator Shiva

A primeira tarefa de Kevin foi trabalhar em um grupo envolvido no então maior projeto do departamento de TI do Townbank - migração em larga escala de um mainframe com envelhecimento gradual para vários novos sistemas VAX. Em teoria, o processo parecia bom - os consultores se reuniram com o cliente e descobriram quais sistemas seriam transferidos, era necessário escrever especificações, atribuir tarefas aos desenvolvedores, o departamento de controle de qualidade tinha que confirmar que o novo sistema funcionava como o antigo, após o qual o código seria exibido em produção .

Quando os gerentes de projeto desenvolviam o processo, esperava-se que as ações imprevistas sempre levassem apenas uma pequena fração dos custos totais ou da quantidade de tempo necessária para implementar a função, e no início era. No entanto, o projeto continuou a evoluir e, quanto mais ambientes foram colocados em operação, mais Kevin e seus colegas desenvolvedores tiveram que adicionar mais tempo às suas estimativas. Oficialmente, os desenvolvedores o chamaram de maneira diferente - testando a integração do sistema, configurando servidores, testando a compatibilidade da mídia, mas entre eles chamavam esses atrasos pelo nome real: "fator Shiva".

Negócio sério!

Não que Shiva fosse um administrador de sistema incompetente ou inexperiente - em qualquer caso. De fato, quando o Townbank decidiu migrar do mainframe para o VAX, o nome de Shiva estava no início de uma lista muito curta de pessoas que poderiam lidar com essa migração de infraestrutura. Shiva assumiu o assunto com toda a responsabilidade, introduzindo suas próprias políticas que poderiam ajudar a remover as falhas do processo. Por exemplo, todas as manhãs, todos os desenvolvedores, analistas ou funcionários do departamento de controle, antes de entrar na quarta-feira, tinham que assinar literalmente no quadro-negro no escritório de Shiva para confirmar sua presença física. Além disso, sentindo que o rastreamento das ações do desenvolvedor foi implementado com detalhes insuficientes, ele introduziu a proteção de controle de versão: para cada alteração e transferência de código entre ambientes, era necessário um memorando. E todas as alterações deveriam ter sido feitas pelo seu ID de usuário. E do seu terminal.

Em um dia calmo, uma pequena alteração pode ser feita em apenas um dia, mas os dias calmos geralmente caem nos feriados ou nos fins de semana. Os desenvolvedores irritados reclamaram com a gerência sênior, argumentando que essas políticas atrasam o projeto e parecem completamente inúteis. Em resposta, a gerência encolheu os ombros - Shiva estabeleceu seus objetivos no início do projeto - ambientes seguros, protegidos da contaminação cruzada com outro código e da incompetência dos desenvolvedores. No final, os servidores VAX ainda eram novos e mesmo muitos dos desenvolvedores seniores ainda não os dominavam completamente.

As massas murmuraram e amaldiçoaram o destino, mas, em vez de se rebelar, derrubando Shiva e encerrando seu governo cruel, todos se resignaram e continuaram a trabalhar. Apesar dos obstáculos e esforços de Shiva, o processo continuou, mas havia uma situação que Shiva parecia negligenciar - e se ele próprio estivesse inacessível?

Programador assistente pequeno

Embora o terminal de Kevin tenha mostrado que ele trabalhou em um clone do ambiente de produção, os nomes dos clientes Nosmo King e Joe Blow deixaram claro que ele havia cometido uma falha grave - o aplicativo se conectou por engano ao banco de dados do ambiente de desenvolvimento e, após o almoço, ele teve que testá-lo. departamento de controle de qualidade. Em uma situação normal, seria mais fácil corrigir o erro - fazer alterações no arquivo de configuração no ambiente de desenvolvimento e retomar o trabalho, mas o destino gostaria que Shiva estivesse em uma reunião longa e deveria aparecer apenas no dia seguinte.

Esperando que Shiva voltasse mais cedo, Kevin foi até sua mesa, mas viu apenas uma cadeira vazia. No entanto, o teclado de Shiva chamou sua atenção. As letras A, S, V, H e eu foram apagadas mais que o resto. Kevin sabia que Shiva estava intoxicado com poder, mas ele era tão narcisista que estava pronto para imprimir seu nome repetidamente? ... Ou talvez isso seja uma pista? Por diversão, Kevin foi para a linha de comando e digitou "shiva" como nome de usuário e senha. Esperando que Shiva pudesse entrar no escritório a qualquer momento, Kevin clicou em "Enter" e ficou chocado por poder concluir a inscrição.

Isso foi incrível. Foi otimo Kevin sabia que precisava compartilhar sua descoberta com alguém. Ele contou isso a um dos veteranos, que costumava ser seu mentor, mas sua reação foi uma surpresa para Kevin.

Descobriu-se que a combinação do nome de usuário e senha do Shiva era o "segredo" favorito do Townbank, que é conhecido desde que Shiva trabalhou como administrador do mainframe.

"Para que Shiva não reconheça", outro desenvolvedor ainda mais experiente explicou a Kevin, "jogamos esse jogo toda vez que o criamos".

"A propósito, para o futuro", continuou ele, "se você não quiser ser pego e arruinado pela vida de todos os outros, deve entrar no seu terminal e não no escritório dele".

A terceira história. Fala grego comigo

[ Original ]


Muitas décadas atrás, mesmo antes do advento de impressoras a laser, sistemas operacionais gráficos e formatos de imagem independentes de dispositivos, Gus trabalhava no departamento de TI da faculdade local. Como um projeto pessoal para momentos de inatividade, ele decidiu descobrir como imprimir o texto em grego. Cerca de uma semana depois, ele montou um programa capaz de imprimir texto grego clássico em uma impressora.

O chefe de Gus trabalhava como gerente de TI, mas, apesar disso, ele se tornou um especialista em filologia antiga. Ele nunca precisou ver o texto grego impresso em uma impressora comum e ficou encantado. O chefe contou a seus amigos, eles mesmos e assim por diante. Logo o mundo dos estudiosos da Grécia clássica se transformou em um simpósio entusiástico e barulhento.

Gus recebeu uma vez um email de um professor universitário desconhecido no Arizona. Ele ouviu do chefe Gus um maravilhoso programa mítico. Ele também consegue?

Gus concordaria de bom grado, mas surgiu um problema. Seu programa foi desenvolvido para a versão anterior do sistema operacional VAX / VMS e do compilador Pascal, e transmitiu o texto para uma impressora VERSAMOD-200 específica, que poderia ser alterada para o modo matriz, e para um driver de impressão específico, que foi cuidadosamente corrigido com código binário, para não estragar imagens matriciais. Gus duvidava que o professor tivesse conhecimento técnico suficiente para apreciar sua explicação, então ele respondeu educadamente e sem entrar em detalhes técnicos: desculpe, mas o programa simplesmente não funcionará em nenhuma outra máquina.

Uma semana depois, um chefe foi até sua mesa, mencionou seu amigo do Arizona e gentilmente perguntou a Gus se ele poderia encontrar alguma maneira de enviar-lhe o programa. As tentativas de Gus de explicar a impossibilidade de executar código em qualquer outro computador no mundo não foram ouvidas.

“Você é um gênio, Gus! Tenho certeza de que você vai inventar alguma coisa. Agradeço antecipadamente! ”, - satisfeito com seu próprio otimismo, o chefe foi embora.

Gus começou a pensar em como poderia atender, ou pelo menos metade, ao pedido do chefe. Finalmente, ele teve uma ideia. Ele entrou na linha de comando do seu computador: DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200 .

Logo, o despejo hexadecimal de seu programa assumiu uma aparência de papel tangível. Gus reuniu uma impressão com um sorriso e entrou no escritório do chefe. Aqui está ela! Este é o programa, como você solicitou.

"Oh!" O chefe pareceu surpreso, mas compreensivo.

"Se eles tiverem algum problema com a instalação, deixe-os entrar em contato comigo e eu ajudarei", disse Gus.

“Ótimo! Muito obrigado! ”, O chefe olhou para a mesa, procurando um envelope de correio adequado.

Um pouco mais tarde, outro de nossos estimados colegas de TI no Arizona foi entregue e ordenado a instalar esse lixão impresso em papel. Ele deve ter passado por um momento chocante na WTF, mas obviamente conseguiu. Pelo menos trinta anos se passaram desde então, e Gus nunca ouviu perguntas do professor ou de outros funcionários da faculdade. Talvez alguém tenha feito um acordo com Hades ou tenha pedido a Cronos para transferi-lo em um momento em que a impressão de caracteres especiais não era mais um trabalho de Sísifo.

A quarta história. Fax de Emergência

[ Original ]


Os faxes estão desatualizados no estágio atual de desenvolvimento da tecnologia. Eles foram inventados mais de uma dúzia de anos antes do telefone, mas, apesar do enorme progresso nas tecnologias de digitalização e e-mail, ainda continuam sendo a forma padrão de comunicação.

Ao transmitir dados, gagueira ou ruído aleatório na linha pode arruinar o fax. A maioria das máquinas de fax modernas possui funções rudimentares de tratamento de erros que alertam o usuário que um fax deve ser reenviado.

Essa maneira de trabalhar com bugs funcionou tão bem que nunca ocorreu a ninguém alterá-la. Mas um analista de negócios da empresa para quem Tom trabalhava teve uma ideia brilhante.

“E se o usuário não estiver sentado ao lado da máquina de fax aguardando uma mensagem?” Ele pensou. "E se o aparelho de fax do remetente não detectar o problema?" Precisamos enviar um relatório de erro por fax!

Embora a preocupação do analista tenha sido fundamentada, Tom e seu grupo contestaram que o envio de uma mensagem de fax com falha não tornaria necessariamente a vida mais fácil para todos.

Eles disseram que, por causa disso, a máquina do remetente ficará ocupada e ele não poderá reenviar o fax original.

“Isso é normal”, disse o analista, “nosso software pode enviar e receber faxes em paralelo. Essa ideia é a melhor que surgiu depois do iPod ! Ela é absolutamente confiável !

Mas o debate foi inútil: aos olhos da gerência, os analistas de negócios estão sempre certos e essa função foi implementada com urgência. O programa foi chamado de "FaxBack" e executou a função correspondente ao nome: transmitiu a transmissão com falha de volta ao remetente (identificado pelo identificador de chamadas) pouco depois da ocorrência da falha.

Por um longo tempo, tudo funcionou sem o menor problema, até que um dia dois carros da polícia com sirenes ligadas pararam perto do escritório de Tom. A polícia disse que atendeu uma chamada de emergência no 911, mas não houve emergência e ninguém admitiu que ligou para o 911.

Logo os policiais partiram, mas no início da manhã do dia seguinte, dois outros carros da polícia dirigiram rapidamente para o escritório. Não houve emergência novamente e ninguém ligou para o 911, então eles calmamente deixaram o escritório.

Mas na terceira vez, quando o carro apareceu na tarde do dia seguinte, os policiais se recusaram a sair até que a fonte da "ansiedade" fosse encontrada. O departamento de polícia tinha certeza de que a ligação vinha do número da empresa e exigia descobrir o que estava acontecendo.

Depois de passar o resto do dia e parte da noite rastreando ligações telefônicas na empresa, Tom descobriu que as ligações para o 911 são provenientes do data center e, mais especificamente, do FaxBack.

Máquinas de fax, como telefones de escritório, precisavam discar “9” para acessar a linha externa. Portanto, quando o FaxBack respondeu a um fax com falha de Nova Déli, discando nove, foi seguido pelo código internacional da Índia - 11, e a “regra especial” do sistema de telecomunicações funcionou.

Quem instalou o sistema de telecomunicações teve a brilhante idéia de tratar o 911 como um caso especial, porque o interlocutor pode não ter pensado em caso de emergência para discar outros nove primeiro. Uma regra especial também se aplicava às linhas no pool de fax, mesmo que o chamador fosse apenas um computador.