Entwicklungstagebuch, Teil 12 · 21. August 2026
Am Abend standen sechsundzwanzig Lieferungen auf dem Server, jede vor und nach dem Hochladen gemessen. Das ist die Zahl, die man in so einen Text schreibt.
Die Zahl, die haften bleibt, ist eine andere: drei.
So oft habe ich an diesem Tag dieselbe Datei hochgeladen. Sie lag schon beim ersten Mal richtig auf dem Server.
Das ist neun Tage nach dem Tag, an dem ich angefangen habe, Prüfsummen zu verlangen — und zwar genau deswegen: weil ich die Arbeit nicht mehrfach machen wollte. Die Prüfsumme sagt mir, was oben liegt. Sie sagt mir nicht, ob jemand sie richtig liest.
Der Faktor zehn
Der Tag fing mit einer Frage an, die länger offen war: Warum sind Fotos nicht in der Sicherung?
Die Antwort stand seit Wochen im Quelltext: „Ein Törn mit 200 Bildern wären mehrere Gigabyte, und dafür ist weder der Server gedacht noch die Sicherung.“
Ein klarer Satz, eine klare Begründung — und falsch.
Denn zwei Absätze weiter oben steht in derselben Datei, was die App tatsächlich speichert: verkleinert auf 1600 Punkte, JPEG mit 82 Prozent, „aus 4 MB werden meist unter 400 KB“. Zweihundert Bilder sind damit rund 80 MB. Nicht mehrere Gigabyte. Um etwa den Faktor zehn daneben.
Die Begründung galt für die Originale. Gespeichert wird aber nicht das Original.
Niemand hat nachgerechnet, weil die Zahl in die gewünschte Richtung zeigte.
Wichtiger als der Rechenfehler ist das, was darunter lag: Fotos liegen in einem anderen Speicher als der Rest — und dieser Speicher wird genauso abgeräumt. Genau die Sieben-Tage-Regel, vor der die App selbst warnt, löscht auch die Bilder.
Wer pflichtbewusst gesichert hat, rettete sein Logbuch und verlor trotzdem jedes Foto.
Seit dem Tag gibt es eine eigene, verschlüsselte Bilddatei. Nicht als Anhang an die bestehende Sicherung, sondern daneben — aus einem Grund, der keine Ordnungsliebe ist: Die Vollsicherung ist der einzige Weg, der die Borddaten rettet. Käme die Bildermenge in denselben Verschlüsselungsvorgang, hinge die Rettung des Logbuchs daran, dass auch der Bilderdurchgang gelingt.
Gemessen wurde, was dabei im Arbeitsspeicher liegt: Eine Datei von 40,7 MB kostet 0,1 MB. Und ein absichtlich beschädigter Block hat sich selbst übergangen — fünf von sechs Bildern kamen zurück, das sechste wurde gemeldet.
Wo die Sekunden lagen
Zweiter Punkt: Beim Anlegen der Beispieldaten steht mehrere Sekunden ein leeres, unbenanntes Boot auf dem Schirm. Der naheliegende Gedanke ist eine Ladeanzeige.
Erst messen. Das Anlegen selbst kostet vierzehn Schreibvorgänge, 9.706 Bytes, unter zwanzig Millisekunden.
Die Sekunden lagen woanders: Die App lädt sich nach dem Anlegen komplett neu, und das sind 86 Skripte mit zusammen 1,29 MB, alle nacheinander. Auf dem Mac 1.363 Millisekunden. Dazu 700 Millisekunden reines Warten, damit ein Hinweistext lesbar bleibt, den die Seite gleich darauf verwirft.
Eine Ladeanzeige in der Demo hätte einen von fünf Wegen abgedeckt. Dasselbe leere Boot erscheint nach jeder Wiederherstellung und bei jedem gewöhnlichen Start.
Die Abdeckung sitzt jetzt in der Seite selbst und gilt für alle fünf. Die 700 Millisekunden sind ersatzlos weg.
Vier Menüs auf einer Website
Am Nachmittag kam heraus, dass 59 Seiten vier verschiedene Menüs führten. Kein Fehler, den jemand gemacht hat — eines wurde kopiert, dann eines geändert, dann wieder eines.
Die Folgen waren messbar. Nur 9 von 59 Seiten führten überhaupt zum Entwicklungstagebuch — ausgerechnet die Tagebuchbeiträge selbst.
Vier Messungen, die nicht das getroffen haben, was sie treffen sollten
Am Abend kam eine Prüfung der Bedienbarkeit dazu, und die hat vor allem sich selbst geprüft.
Die erste Zahl: null von 274 bei der verbreitetsten Bauform — ein Artefakt des Prüfskripts, nicht der Seite.
Die zweite: 45 Stellen, an denen dieselbe Ansage dreimal hintereinander steht. Ebenfalls ein Artefakt. Der Browser führt ein Element, seinen Textknoten und dessen Textkasten getrennt, alle mit demselben Namen. Eine Vorlesehilfe sagt das nicht dreimal. Echt war genau eine Stelle.
Übrig blieb aber ein Befund, der es in sich hat: 46 Knöpfe hatten als einzigen Text ein Symbol und keine Beschriftung. Eine Vorlesehilfe sagt dann das Zeichen an — „mal“, „Häkchen“, „minus eins“.
Wer nicht sieht, worauf er drückt, drückt nicht.
Seit dem Abend sind es null.
Nachtrag vom 28. August: Diese Knöpfe waren der Grund, warum ich sieben Tage später bei der Messung 398 Knöpfe mit Namen und null ohne bekam. Die Zahl stimmte. Sie hat mir trotzdem nicht gesagt, dass der Logbuchdialog mit einer Vorlesehilfe unbenutzbar ist.
Was ich mitnehme
Vier Fehler an einem Tag, und alle vier haben dieselbe Form: Es wurde gemessen, und die Messung traf nicht das, was sie treffen sollte. Die falsche Adresse. Die nicht verfolgte Umleitung. Das Skript, das die häufigste Bauform übersah. Die Baumdarstellung, die für das Ergebnis gehalten wurde.
Eine Messung an der falschen Adresse ist keine Messung. Und wenn ein Test bestätigt, was man erwartet hat, ist das der Moment, ihn zu prüfen — nicht der Moment, ihm zu glauben.
Die Regel stand schon vorher im Aufgabenheft. Sie steht dort seit dem Tag, an dem ein Cent zwei Tage gekostet hat.
An diesem Tag habe ich gelernt, dass sie auch für Zahlen gilt, die ich selbst erzeuge — besonders für die.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.