Neugierige Perversionen aus der IT-Welt - 5

Die erste Geschichte. Tödliche Briefe

[ Original ]

Es war einmal, als George einen Job in Initechs Büro bekam. Das Unternehmen hat gerade mehrere Stockwerke in einem alten Bürogebäude angemietet, das kürzlich von der Kategorie des städtischen Niedergangs in die eleganten Kaffeehäuser im Erdgeschoss übergegangen ist und bei allen anderen nach Schuhcreme und frischen Lederpolstern riecht.

Es war ein riesiger Raum, und George befand sich in der Phase seiner Karriere, als er ein separates Büro mit Blick auf die Gasse haben sollte.

Seine erste Aufgabe war es, das Problem in der Mac-Version der Software des Unternehmens zu beheben. Unter Windows sah es perfekt aus, aber unter OSX traten Fehler beim Rendern von Schriftarten auf. Dieser Fehler ist schwer zu finden, aber George war wahrscheinlich ein Detektiv in einem früheren Leben, also war er bereit für diesen Test.

Der wichtigste Hinweis war die Geschichte der Versionskontrolle. In den letzten drei Jahren haben fünf Entwickler an dem Produkt gearbeitet. Es scheint, dass jeder von ihnen ungefähr vier Monate in der Firma war und dann ging. Viele Monate lang blieben sie unverändert, dann kam ein neuer Entwickler und der Zyklus wiederholte sich erneut. Wie George herausfand, tauchten ihre Namen immer wieder auf, als er versuchte, die Funktionen, die Arbeit und die Ursachen von Produktfehlern herauszufinden.

Da die Anwendung plattformübergreifend war, implementierten die Entwickler ihren eigenen Font Loader und Renderer. Zumindest dachte er so. Die interne Struktur von Schriftarten ist gefährlich und verwirrend, und dies spiegelt sich im Code wider. Es spiegelte auch die Tatsache wider, dass verschiedene Programmierer, die ihre Integrität nicht bewahrten, nacheinander daran arbeiteten. Es war Chaos .

Im Code sah George eine Reihe von Aspekten, die zweifellos schlecht waren - unsichere Aufrufe von memcpy , malloc ohne free Zeigerarithmetik, die mehr auf Vertrauen als auf Logik beruhten. Aber anscheinend war nichts davon die Ursache für das Schriftproblem.

Frustriert beschloss George, sich ihr von der anderen Seite zu nähern. Auf Bildschirmen mit Rendering-Fehlern gab es immer ein oder zwei spezielle Schriftarten. George hat die Schriftarten in die Dienstprogramme zur Schriftprüfung von Adobe und Microsoft hochgeladen und Berichte über eine ganze Reihe von Fehlern gesehen.

Der Download-Code für Schriftarten war schlecht, aber die Schriftarten selbst waren noch schlechter. Nachdem George das Problem identifiziert hatte, sagte er seinem Chef, dass die Schriftarten repariert werden müssten. Der Chef gab es an den Präsidenten des Unternehmens weiter.

Am nächsten Tag trat der Chef an George heran: "Der Präsident möchte sich dringend mit Ihnen treffen."

Das Büro des Präsidenten ähnelte eher einem Konferenzraum, jedoch ohne Konferenztisch. Ein langer Raum, auf einer Seite ein Tisch, Fenster an der ganzen Wand und Blick auf den Fluss. Ein wütender Präsident saß an seinem Schreibtisch.

„Was ist los mit euch beiden? George, du bist seit weniger als vier Monaten hier und verschwendest bereits meine Zeit - verschwendest du mein Geld für eine verrückte Idee über ein Problem mit Schriftarten ? "

„Aber es ist so. Ich kann es zeigen . “

„In der Windows-Version funktioniert die Schriftart einwandfrei! Das Problem sollte in der Hölle sein. Ich weiß, wie viel du bezahlt bekommst. Vielleicht sollte ich einen Taschenrechner nehmen und berechnen, wie viel die Firma diese Geisterjagd gekostet hat? “ Er schlug auf den Tisch, so dass der Taschenrechner neben der Tastatur etwas sprang.

Die Anschuldigungen gingen weiter, aber George wusste bereits, was er nach dem Treffen tun würde. Am Ende des Tages gab er sein Abzeichen und seinen Arbeitslaptop zusammen mit einer unhöflichen und ehrlichen Rücktrittserklärung zurück.

Nach einem kurzen unbezahlten Urlaub bekam George einen neuen Job. Jahre vergingen und er begann bereits die Zeit in Initech zu vergessen. Aber eines Tages sah er eine Nachricht über die Veröffentlichung eines kritischen Patches der Microsoft Windows-Sicherheitslücke. Wie sich herausstellte, kann der Code zur Verarbeitung von Schriftarten von Drittanbietern in einigen Windows-Bibliotheken zu einer willkürlichen Codeausführung führen. Nach ein wenig Recherche bestätigte George seine Vermutung: Es war der Initech-Code, der das Problem verursachte. Darüber hinaus wurde die letzte Initech-Binärdatei bereits 2008 veröffentlicht - einen Monat nachdem er das Unternehmen verlassen hatte.

Die zweite Geschichte. Arbeiten Sie am Prozess sowie darunter und darüber

[ Original ]

Als Kevin Ende der 1980er Jahre einen Job bei Townbank bekam, befand er sich in der gleichen Situation wie Tausende anderer neu geprägter Programmierer davor und danach: Ein Unternehmensprogrammierer schreibt nicht nur Code - er muss sich an den Prozess halten.

Der Prozess unterscheidet sich von den strengen Geboten der Weltreligionen nur dadurch, dass seine Aufgabe darin besteht, die Integrität des Kodex aufrechtzuerhalten. Ehre sei dem Prozess, möge er gesegnet sein, der Prozess ist gut, du musst dich immer an den Prozess halten, und vor allem ist der Prozess nützlich für dich!

Für die meisten Entwickler ist der Prozess nicht so schlecht. Sie müssen sich nur daran gewöhnen. Füllen Sie das Formular aus, lassen Sie sich genehmigen, registrieren Sie einen Testplan, schreiben Sie die Montagedokumentation - all dies ist in Ordnung. Wie Kevin jedoch bald herausfand, gab es bei Townbank Prozesse, an die sich weder Veteranen noch Anfänger anpassen konnten.

Shiva-Faktor

Kevins erste Aufgabe bestand darin, in einer Gruppe zu arbeiten, die am damals größten Projekt der Townbank-IT-Abteilung beteiligt war - der groß angelegten Migration von einem allmählich alternden Mainframe zu mehreren neuen VAX-Systemen. Theoretisch sah der Prozess gut aus - die Berater trafen sich mit dem Kunden und fanden heraus, welche Systeme übertragen werden würden. Es war notwendig, Spezifikationen zu schreiben, den Entwicklern Aufgaben zuzuweisen. Die Abteilung für Qualitätskontrolle musste bestätigen, dass das neue System wie das alte funktioniert. Danach wurde der Code in Produktion genommen .

Bei der Entwicklung des Prozesses durch die Projektmanager wurde erwartet, dass unvorhergesehene Maßnahmen immer nur einen kleinen Bruchteil der Gesamtkosten oder der für die Implementierung der Funktion erforderlichen Zeit in Anspruch nehmen würden, und dies war zunächst der Fall. Das Projekt entwickelte sich jedoch weiter und je mehr Umgebungen in Betrieb genommen wurden, desto mehr mussten Kevin und seine Entwicklerkollegen ihren Schätzungen zusätzliche Zeit hinzufügen. Offiziell nannten es die Entwickler anders - Testen der Systemintegration, Konfigurieren von Servern, Testen der Medienkompatibilität, aber untereinander nannten sie solche Verzögerungen mit ihrem richtigen Namen: "Shiva-Faktor".

Ernstes Geschäft!

Nicht, dass Shiva ein inkompetenter oder unerfahrener Systemadministrator gewesen wäre - auf jeden Fall. Als Townbank beschloss, vom Mainframe auf VAX zu migrieren, stand Shivas Name am Anfang einer sehr kurzen Liste von Personen, die sich mit einer solchen Infrastrukturmigration befassen konnten. Shiva nahm die Angelegenheit mit aller Verantwortung auf und führte seine eigenen Richtlinien ein, die dazu beitragen könnten, die Mängel des Prozesses zu beseitigen. Zum Beispiel mussten jeden Morgen alle Entwickler, Analysten oder Mitarbeiter der Kontrollabteilung vor dem Eintritt in den Mittwoch buchstäblich an der Tafel in Shivas Büro unterschreiben, um ihre physische Anwesenheit zu bestätigen. Da er der Ansicht war, dass die Verfolgung der Aktionen des Entwicklers nur unzureichend detailliert implementiert wurde, führte er den Versionskontrollschutz ein: Für jede Codeänderung und Übertragung zwischen Umgebungen war ein Memo erforderlich. Und alle Änderungen sollten von seiner Benutzer-ID vorgenommen worden sein. Und von seinem Terminal.

An einem ruhigen Tag konnte eine kleine Änderung an nur einem Tag vorgenommen werden, aber ruhige Tage fielen oft an Feiertagen oder Wochenenden. Verärgerte Entwickler beschwerten sich bei der Geschäftsleitung und argumentierten, dass diese Richtlinien das Projekt verlangsamen und völlig nutzlos erscheinen. Als Reaktion darauf zuckte das Management mit den Schultern - Shiva legte zu Beginn des Projekts seine Ziele fest - sichere Umgebungen, die vor Kreuzkontamination mit anderem Code und vor der Inkompetenz von Entwicklern geschützt sind. Am Ende waren VAX-Server noch neu, und selbst viele der leitenden Entwickler hatten sie noch nicht vollständig beherrscht.

Die Massen murmelten und verfluchten das Schicksal, aber anstatt zu rebellieren, Shiva zu stürzen und seine grausame Herrschaft zu beenden, gaben sich alle zurück und arbeiteten weiter. Trotz der Hindernisse und Bemühungen von Shiva ging der Prozess weiter, aber es gab eine Situation, die Shiva zu vernachlässigen schien - was, wenn er selbst unzugänglich war?

Kleiner Programmierassistent

Obwohl Kevins Terminal zeigte, dass er in einem Klon für eine Produktionsumgebung arbeitete, machten die Kundennamen von Nosmo King und Joe Blow deutlich, dass er einen groben Fehler gemacht hatte - die Anwendung war fälschlicherweise mit der Datenbank der Entwicklungsumgebung verbunden, und nach dem Mittagessen musste er sie testen Abteilung für Qualitätskontrolle. In einer normalen Situation wäre es einfacher, den Fehler zu beheben - Änderungen an der Konfigurationsdatei in der Entwicklungsumgebung vorzunehmen und die Arbeit fortzusetzen, aber das Schicksal hätte Shiva gerne zu einem langen Meeting eingeladen und sollte erst am nächsten Tag erscheinen.

In der Hoffnung, dass Shiva früher zurückkehren könnte, ging Kevin zu seinem Schreibtisch, sah aber nur einen leeren Stuhl. Shivas Tastatur erregte jedoch seine Aufmerksamkeit. Die Buchstaben A, S, V, H und ich wurden mehr als die anderen gelöscht. Kevin wusste, dass Shiva von Macht berauscht war, aber war er so narzisstisch, dass er bereit war, seinen Namen immer wieder zu drucken? ... oder vielleicht ist das ein Hinweis? Zum Spaß ging Kevin zur Kommandozeile und gab "shiva" als Benutzernamen und Passwort ein. In der Erwartung, dass Shiva das Büro jederzeit betreten könnte, klickte Kevin auf „Enter“ und war schockiert, dass er den Eintrag abschließen konnte.

Das war unglaublich. Es war großartig. Kevin wusste, dass er seine Entdeckung mit jemandem teilen musste. Er erzählte dies einem der Veteranen, der früher sein Mentor war, aber seine Reaktion überraschte Kevin.

Es stellte sich heraus, dass die Kombination aus Shivas Benutzernamen und Passwort Townbanks beliebtestes "Geheimnis" war, das bekannt ist, seit Shiva als Mainframe-Administrator tätig war.

"Damit Shiva es nicht erkennt", erklärte ein anderer, noch erfahrenerer Entwickler Kevin, "spielen wir dieses Spiel jedes Mal, wenn wir es erhöhen."

"Übrigens für die Zukunft", fuhr er fort, "wenn Sie nicht vom Leben aller anderen gefangen und ruiniert werden wollen, sollten Sie von Ihrem Terminal und NICHT von seinem Büro aus eintreten."

Die dritte Geschichte. Sprich Griechisch mit mir

[ Original ]


Vor vielen Jahrzehnten, noch vor dem Aufkommen von Laserdruckern, grafischen Betriebssystemen und geräteunabhängigen Bildformaten, arbeitete Gus in der IT-Abteilung des örtlichen Colleges. Als persönliches Projekt für Momente der Ausfallzeit beschloss er, herauszufinden, wie der Text auf Griechisch gedruckt werden kann. Ungefähr eine Woche später stellte er ein Programm zusammen, mit dem klassischer griechischer Text auf einem Drucker gedruckt werden kann.

Gus 'Chef arbeitete als IT-Manager, aber trotzdem erwies er sich als Spezialist für antike Philologie. Er musste nie griechischen Text auf einem normalen Drucker drucken sehen und war begeistert. Der Chef erzählte seinen Freunden davon, sie erzählten es ihren eigenen und so weiter. Bald wurde die Welt der klassischen griechischen Gelehrten zu einem begeisterten und lauten Symposium.

Gus erhielt einmal eine E-Mail von einem unbekannten College-Professor in Arizona. Er hörte von Chief Gus von einem wunderbaren, mythischen Programm. Kann er es auch bekommen?

Gus würde gerne zustimmen, aber es trat ein Problem auf. Sein Programm war für die vorherige Version des VAX / VMS-Betriebssystems und des Pascal-Compilers vorgesehen und gab den Text an einen bestimmten VERSAMOD-200-Drucker aus, der in den Matrixmodus umgeschaltet werden konnte, und an einen bestimmten Druckertreiber, der ordentlich mit Binärcode gepatcht wurde, um dies nicht zu tun Matrixbilder verderben. Gus bezweifelte, dass der Professor über ausreichende technische Kenntnisse verfügte, um seine Erklärung zu würdigen, und antwortete höflich und ohne auf technische Details einzugehen: Entschuldigung, aber das Programm funktioniert auf keiner anderen Maschine.

Eine Woche später kam ein Chef an seinen Schreibtisch, erwähnte seinen Freund aus Arizona und fragte Gus sanft, ob er einen Weg finden könne, ihm das Programm zu schicken. Gus 'Versuche, die Unmöglichkeit zu erklären, Code auf einem anderen Computer der Welt auszuführen, wurden nicht gehört.

„Du bist ein Genie, Gus! Ich bin sicher, Sie werden sich etwas einfallen lassen. Vielen Dank im Voraus! “, - zufrieden mit seinem eigenen Optimismus, ging der Chef.

Gus begann zu überlegen, wie er die Bitte des Chefs erfüllen oder zumindest halb erfüllen könnte. Endlich hatte er eine Idee. Er gab die Befehlszeile seines Computers ein: DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200 .

Bald nahm der hexadezimale Dump seines Programms einen greifbaren Papierblick an. Gus sammelte mit einem Lächeln einen Ausdruck und ging in das Büro des Chefs. „Hier ist sie! Dies ist das Programm, wie Sie es gewünscht haben. “

"Oh!" Der Chef schien überrascht, aber verständnisvoll.

"Wenn sie Probleme mit der Installation haben, lassen Sie sie mich kontaktieren und ich werde helfen", sagte Gus.

„Großartig! Vielen Dank! “, Der Chef warf einen Blick auf den Tisch und suchte nach einem geeigneten Briefumschlag.

Wenig später wurde ein anderer unserer geschätzten IT-Kollegen in Arizona übergeben und beauftragt, diesen auf Papier gedruckten Dump zu installieren. Er muss einen ziemlich schockierenden Moment in der WTF erlebt haben, aber es gelang ihm offensichtlich. Seitdem sind mindestens dreißig Jahre vergangen, und Gus hat keine Fragen vom Professor oder anderen College-Mitarbeitern gehört. Vielleicht hat jemand gerade einen Deal mit Hades gemacht oder Kronos gebeten, ihn zu einem Zeitpunkt zu übertragen, als das Drucken von Sonderzeichen keine Sisyphus-Arbeit mehr war.

Die vierte Geschichte. Notfall-Faxe

[ Original ]


Faxe sind zum gegenwärtigen Zeitpunkt der Technologieentwicklung veraltet. Sie wurden mehr als ein Dutzend Jahre früher als das Telefon erfunden, aber trotz der enormen Fortschritte bei den Scan- und E-Mail-Technologien bleiben sie die Standardform der Kommunikation.

Bei der Datenübertragung kann zufälliges Stottern oder Rauschen auf der Leitung das Fax zerstören. Die meisten modernen Faxgeräte verfügen über rudimentäre Fehlerbehandlungsfunktionen, die den Benutzer darauf hinweisen, dass ein Fax erneut gesendet werden muss.

Diese Art der Arbeit mit Fehlern funktionierte so gut, dass es niemandem einfiel, sie zu ändern. Aber ein Business Analyst der Firma, für die Tom arbeitete, hatte eine gute Idee.

"Was ist, wenn der Benutzer nicht neben dem Faxgerät sitzt und auf eine Nachricht wartet?", Dachte er. "Was ist, wenn das Faxgerät des Absenders das Problem nicht erkennt?" Wir müssen ihm einen Fehlerbericht faxen! “

Obwohl die Besorgnis des Analysten begründet war, beanstandeten Tom und seine Gruppe, dass das Senden einer fehlgeschlagenen Faxnachricht nicht unbedingt das Leben für alle einfacher machen würde.

Sie sagten, dass aus diesem Grund das Gerät des Absenders ausgelastet ist und er das ursprüngliche Fax nicht erneut senden kann.

"Das ist normal", sagte der Analyst, "unsere Software kann Faxe parallel senden und empfangen. Diese Idee ist die beste, die nach dem iPod kam ! Sie ist absolut zuverlässig ! “

Die Debatte war jedoch sinnlos: In den Augen des Managements haben Business Analysten immer Recht, und diese Funktion wurde dringend umgesetzt. Das Programm hieß "FaxBack" und führte die dem Namen entsprechende Funktion aus: Es übertrug die fehlgeschlagene Übertragung kurze Zeit nach dem Auftreten des Fehlers an den Absender (identifiziert durch die Anrufer-ID) zurück.

Lange Zeit funktionierte alles ohne das geringste Problem, bis eines Tages zwei Polizeiautos mit eingeschalteten Sirenen in der Nähe von Toms Büro anhielten. Die Polizei sagte, sie hätten einen Notruf auf 911 beantwortet, aber es gab keinen Notfall und niemand gab zu, dass sie 911 gewählt hatten.

Bald gingen die Beamten, aber am frühen Morgen des nächsten Tages fuhren zwei weitere Polizeiautos schnell ins Büro. Es gab wieder keinen Notfall und niemand rief 911 an, also verließen sie ruhig das Büro.

Aber das dritte Mal, als das Auto am Nachmittag des nächsten Tages erschien, weigerten sich die Beamten zu gehen, bis die Quelle der "Angst" gefunden war. Die Polizei war sich sicher, dass der Anruf von der Firmennummer kam, und verlangte herauszufinden, was los war.

Nachdem Tom den Rest des Tages und einen Teil des Abends damit verbracht hatte, Telefonanrufe innerhalb des Unternehmens zu verfolgen, stellte er fest, dass Anrufe bei 911 vom Rechenzentrum und insbesondere von FaxBack kommen.

Faxgeräte wie Bürotelefone mussten „9“ wählen, um auf die Amtsleitung zuzugreifen. Als FaxBack auf ein fehlgeschlagenes Fax aus Neu-Delhi antwortete und neun wählte, folgte der internationale Code von Indien - 11, und die „Sonderregel“ des Telekommunikationssystems funktionierte.

Derjenige, der das Telekommunikationssystem installiert hat, hatte die gute Idee, 911 als Sonderfall zu behandeln, da der Anrufer im Notfall möglicherweise nicht daran gedacht hätte, zuerst neun weitere zu wählen. Eine spezielle Regel galt auch für Leitungen im Faxpool, selbst wenn der Anrufer nur ein Computer war.