Entwicklungstagebuch, Teil 9 · 17. August 2026, abends
Achtundachtzig Zeitgeber, drei Sekunden Startzeit, ein Vorhaben, vor dem ich Respekt hatte.
Die Ursache stand am Ende in einer Zeile, die richtig aussah — und in einem einzigen fehlenden Wort.
Teil 8 endete am Nachmittag. Was dann kam, war als Aufräumen gedacht: die Restpunkte von der Liste, ein Tippfehler, ein Filter, der nicht greifen wollte.
Am Ende des Abends standen fünf Lieferungen, drei Irrtümer und eine Ursache, die in keiner einzigen Zeile Programmcode steckte.
Eine Zahl für nichts
Seit Teil 6 frage ich vor jeder Änderung ab, was tatsächlich auf dem Server liegt. Das ist die Regel, die mir am meisten Ärger erspart hat.
An diesem Abend sind mir im Terminal zwei Zeilen zusammengelaufen. Aus zwei Befehlen wurde einer, der Dateiname war Unsinn, der Abruf lief nie — und trotzdem kam ein Ergebnis. Eine ordentliche, zweiunddreißigstellige Zahlenfolge, wie sie immer kommt.
Nur war es die Prüfsumme von nichts. Die Rechenvorschrift läuft auch, wenn vorne nichts ankommt, und liefert brav einen Wert für die leere Eingabe.
Es gibt Messungen, die auch dann eine Zahl abgeben, wenn sie gescheitert sind. Die sind gefährlicher als gar keine.
Die Abfrage schreibt jetzt erst in eine Datei und misst danach. Scheitert der Abruf, gibt es keine Zahl statt einer falschen. Und die eine Zahlenfolge, die für „da war nichts“ steht, kenne ich inzwischen auswendig.
Eine halbe Stunde später ist mir derselbe Fehler in anderer Form passiert. Beim Abgleich meldete eine Datei eine Abweichung. Gemessen war beide Male derselbe Wert — falsch abgetippt hatte ich den Sollwert aus meiner eigenen Liste.
Seitdem vergleicht das der Rechner und nicht mehr ich.
Nachtrag vom 28. August: Dieser Satz oben ist an dem Tag dreimal wahr geworden. Ein Prüfling meldete nichts, weil er nichts messen konnte — und weil „nichts“ auf beiden Seiten gleich aussieht, wäre es fast durchgegangen. Elf Tage später, dieselbe Falle, in einem anderen Werkzeug.
Fünf auf dem Bildschirm, zwei in der Datei
Auf der Liste stand seit dem 14. August eine Beobachtung: Der Datumsfilter im Logbuch stand in beiden Feldern auf demselben Tag und zeigte trotzdem alle Einträge.
Reproduzieren ließ sich das nicht. Der Filter ist richtig gebaut, die Felder werden beim Laden nicht vorbelegt, und weder Neuladen noch Zurückblättern stellt einen Wert wieder her. Ich habe die Ursache offen gelassen, statt mir eine auszudenken.
Beim Suchen fiel etwas anderes auf, und das war schlimmer. Wenn Feldwerte und angezeigte Liste auseinanderlaufen, zeigt der Bildschirm fünf Einträge — und der Export schreibt zwei in die Datei. Die Liste stammt aus dem letzten Zeichnen, der Export liest die Felder im Moment des Klicks.
Das ist dieselbe Klasse Fehler wie beim Törnbericht in Teil 6: Zu viele Zeilen in einer Datei sieht man beim Durchsehen. Zu wenige nicht.
Der Export zeichnet die Liste jetzt zuerst neu und schreibt danach. Bei Uneinigkeit gewinnen die Felder — die sind, was jemand eingestellt hat. Die veraltete Liste ist der Fehler.
„Letzter Törn — Keiner“
Ein Bildschirmfoto vom iPad zeigte im Systembereich eine Kachel. Überschrift: „Letzter Törn“. Wert darunter: „Keiner“.
Zwei Zeilen tiefer, in derselben Ansicht: „Törns · 1 Eintrag“.
Die Ursache ist eine Naht zwischen zwei Änderungen, die einzeln beide richtig waren.
Auch das ist eine Gestalt, die wiederkommt. Am 28. August habe ich zwei Kacheln gefunden, die seit jeher dasselbe sagten — eine, weil sie nach Feldern fragte, die niemand schreibt, und eine, die überhaupt niemand je beschrieben hat.
Ein Wort, das seit Wochen fehlte
Der eigentliche Fund des Abends stand in keiner Programmdatei.
Die Startzeit der App lag bei drei Sekunden. Auf der Liste stand das als Brocken, den man nur als eigenes Vorhaben angehen sollte — achtundachtzig Zeitgeber umbauen, Ladereihenfolgen ändern, Bausteine zusammenfassen. Ich hatte Respekt davor.
Dann haben wir nachgesehen, was der Server tatsächlich ausliefert.
Die Serverkonfiguration listet auf, welche Dateitypen gepackt übertragen werden sollen. Für Programmdateien stand dort ein Name, den der Server seit ein paar Jahren nicht mehr verwendet. Zwei Schreibweisen für dasselbe. Eine stand da, die andere nicht.
Stilvorlagen wurden gepackt. Programmdateien nicht — und die sind vier Fünftel der Übertragung.
Ein Wort, in zwei Zeilen ergänzt. Danach kam die Hauptdatei mit sechsundfünfzigtausend statt hundertdreiundsiebzigtausend Byte an. Siebenundsechzig Prozent weniger, hochgerechnet über achthundert Kilobyte bei jedem ersten Start.
Auf einer Mobilfunkverbindung an Bord ist das genau der Unterschied, den ich mir vom Umbau der Zeitgeber erhofft hatte. Und dafür musste keine einzige Zahl in einem Baustein angefasst werden.
Was ich mitnehme
Der größte Anteil an der Ladezeit lag außerhalb des Codes. Bei jedem Umbau der Bausteine wäre er unentdeckt geblieben. Ich hätte an Zeitpunkten gedreht, hätte hinterher Fehler gesucht, die vorher keine waren — und wäre am Ende bei denselben Sekunden gelandet.
Vier Dinge sahen an diesem Abend nach dem aus, was sie nicht waren: ein Tippfehler, den es nicht mehr gab. Ein Filter, der funktionierte. Eine Prüfsumme, die keine war. Ein fehlender Block, der längst dastand.
Und dreimal haben wir uns geirrt, zweimal mit ziemlicher Sicherheit im Ton. Geholfen hat jedes Mal dasselbe: nicht diskutieren, sondern eine Messung bauen, die auch dann etwas sagt, wenn sie einem widerspricht.
Nachtrag zu Teil 8: Dort steht, bei der Software, die mich geärgert hat, habe offenbar niemand nachgerechnet. Heute würde ich ergänzen: Nachrechnen allein reicht nicht. Man muss auch nachrechnen, ob man das Richtige nachgerechnet hat.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.