Wie kürzlich angekündigt habe ich mich endlich darüber gemacht, das interne Datenmodell für die Anmeldeseite zu überarbeiten und vernünftig zu implementieren. Und wenn man schon dabei ist, kann man das auch gleich für die Markierungen und die Rangliste machen. Das Ergebnis ist deutlich saubererer Code, mit dem es jetzt hoffentlich keine sporadischen Crashes mehr beim Netzwerkeinsatz gibt.
Augenscheinlich hat sich gar nicht so viel getan, aber unter der Haube dafür um so mehr: Der Patch zu Version 3.5.1 umfasst Stand jetzt knapp 6 500 geänderte (neue, gelöschte und editierte) Zeilen Code. So tiefgreifende Änderungen wollen natürlich intensiv getestet werden.
Stresstest
Zum Testen bietet sich, natürlich als Trockenübung, eine Anmeldung und Auslosung in der Größenordung Hofer Volksfest an. Für das Test-Setup habe ich die gleiche Ausstattung gewählt, die wir damals hatten: Zwei Notebooks für je eine Anmeldungsstelle und eines für die Auslosung. Es gibt eine Voranmeldungsliste (mit der Markierung „Vorangemeldet“). Wenn sich die Paare anmelden, werden sie als „Auslosung fehlt“ markiert. Allein gekommene Spieler werden ebenfalls angemeldet (und automatisch als „Allein da“ markiert). Sobald es geht (zwei allein gekommene Spieler angemeldet), werden aus den allein gekommenen Spielern Paare gebildet. Der dritte Rechner kümmert sich nur um die Auslosung (also um die als „Auslosung fehlt“ markierten Paare).
Ich habe eine Voranmeldungsliste mit 92 Paaren erstellt, die teilweise falsch geschrieben waren, teilweise anders als vorangemeldet „gekommen“ sind und teilweise auch gar nicht. Jeder der beiden Anmeldungsrechner bekam eine Liste mit 60 Paaren und auch allein gekommenen Spielern, die sich an der jeweiligen Stelle anmelden wollten. Der dritte Rechner loste, nach der „Fenster“-Vergabe mit +4 Tischen, die Paare zu.
Das Ergebnis: Alles hat 1A funktioniert. Erwartungsgemäß gab es, natürlich auch bedingt durch die viel höhere Eingabefrequenz (unter Realbedingungen würde es ja nicht so schnell gehen), ein paar Netzwerkkollisionen. Sprich eine Handvoll Änderungen mussten erneut angefragt werden, weil sie der Server aufgrund eines zwischenzeitlich geänderten Datenbestands abgelehnt hatte. Wie gesagt: Das war zu erwarten und kann systembedingt in seltenen Fällen passieren. Macht ja auch nichts, man muss ja einfach nur die Änderung nochmal losschicken. Aber was nicht passiert ist: Ein Crash. Es ist alles stabil gelaufen. Und zwar genau so, wie es laufen sollte.
Nebenbei noch anzumerken ist: Das Ergebnis der schon ordentlich zufälligen „Fenster“-Auslosung mit +4 Tischen war – ohne manuelles Eingreifen! – dass bei den am Schluss 112 angemeldeten Paaren an 56 Tischen nur das Umsetzen von zwei Paaren erforderlich war. Danach war die Auslosung fortlaufend und lückenlos. Das System ist also wirklich für den Realeinsatz geeignet, vor allem für große Turniere – denn zwei oder drei Paare kann man in zwei Minuten an einen anderen Tisch beodern. Und die 100 anderen sitzen schon da, wo sie hingehören.
Muckturnier 3.6.0 t. b. a.
Ein paar neue Features gibt es ja auch noch, und vor allem einen ganzen Haufen Fehlerkorrekturen (es ist immer wieder erstaunlich, was man alles findet ;-). Alles das wird demnächst als Muckturnier 3.6.0 veröffentlicht. Vielleicht direkt nach dem Muckturnier des ASV Leupoldsgrün, das würde ich dann noch als öffentlichen Betatest mitnehmen :-)
Auf dem Muckturnier der JU Leupoldsgrün (bei dem ich übrigens mit meinem Kartpartner Florian Ziehr bei 94 anderen Mitstreitern einen überragenden 13. Platz erringen konnte!) konnte das Muckturnier-Programm endlich mal wieder „richtig“ eingesetzt werden. Mit zwei Rechnern in einem Netzwerk und auch dem Nutzen vieler Features.
Und prompt gab es einen Speicherzugriffsfehler und das Programm stürzte ab. Gut, passiert ist dabei nichts, neu gestartet, neu verbunden und gut. Daten sind keine verlorenen gegangen, und hinterher war auch alles gut bis zum Schluss.
Aber das darf natürlich nicht passieren. Es darf Fehlermeldungen geben, ein Client darf aus dem Netzwerk fliegen … aber ein Absturz ist nicht akzeptabel. In weiser Voraussicht habe ich alle Instanzen in einem Debugger laufen lassen, so dass ich mit Hilfe des Backtraces genau herausfinden konnte, wo exakt der Crash passiert ist. An einer Stelle, wo das eigentlich überhaupt nicht hätte passieren dürfen, beim Speichern des aktuellen Zustands eines Namens-Editors vor einer Netzwerkänderung. Offensichtlich gab es den Editor zu dem Zeitpunkt nicht mehr.
Während ich auf der Suche nach der Ursache und vor allem der Korrektur des Problems war, fiel mir folgender Kommentar ins Auge (geschrieben von mir selber):
// TODO: Most probably, all this here would better implemented in a model/view infrastructure
// and not by messing with a QTableWidget and QTableWidgetItems. Well, at least, it works ;-)
… tut es eben nicht :-P
Die Anmeldeseite war am Anfang sehr einfach. Einfach eine Liste von Namen. Schritt für Schritt kam immer mehr dazu, und es wurde eine Tabelle. Für die Darstellung bot sich ein QTableWidget an, eine „Bequemlichkeits“-Klasse für die tabellarische Darstellung von Daten.
Und dann kam immer mehr Funktionalität dazu, und es wurde immer komplizierter – und das QTableWidget war immer weniger geeignet dafür. Wie bereits erkannt und per Kommentar festgehalten sollte man sowas mit einer eigenen Model-View-Implementierung lösen. Das kam mir aber damals recht kompliziert und schwierig vor, und deswegen habe immer mehr an dem, was da war, rumgebastelt und ein paar Sachen so gemacht, wie man sie eigentlich nicht machen sollte … mit dem Resultat, dass so ein Crash passiert, weil man eigentlich gar nicht mehr weiß, was wann und wo passiert.
Schluss mit lustig: Jetzt machen wir’s mal richtig
Also gut: Dann machen wir das eben so, wie’s eigentlich gehört. Mit einem eigenen Datenmodell, einer Tabellen-Anzeige dafür, und einem „Delegate“, was eine Klasse ist, die u. a. das genaue Zeichnen auf dem Bildschirm und das Editieren regelt. Man lernt ja dazu im Lauf der Zeit, und kennt sich irgendwann auch ein bisschen aus.
Die Daten so anzuzeigen war jetzt nicht das Problem. Aber das „ordentlich“, sinnvoll, sauber und vor allem netzwerkfähig zu machen stellte sich dann doch als ein riesen Fass heraus, das ich da aufgemacht habe. Auf dem Weg sind mir dann auch noch einige Fehler bzw. Unzulänglichkeiten der bisherigen Implementierung aufgefallen, die ich gleich mit behoben habe. Aber es musste viel geändert werden. Teilweise systemweit benutzte Datenstrukturen, Datenbankaufrufe etc. etc. – aber unterm Strich sollte die Anmeldeseite jetzt vernünftig und vor allem deutlich robuster implementiert sein.
Das vorher war in der Retrospektive ein Tanz auf dem Vulkan, wo das Funktionieren des Programms auch mal davon abhängig war, ob oder ob nicht zur richtigen Zeit ein bestimmter Anmeldelisteneintrag unter einem definierten Pixel auf dem Bildschirm zu finden war ;-)
Abgesehen davon ist jetzt einiges schöner, einfacher (auch codeseitig!) und vor allem benutzbarer – dazu aber mehr beim nächsten Release Announcement.
Beim ersten Code-Zustand, der komplett und funktionell aussah, spuckte diffstat für den Patch verglichen zu git master folgendes aus:
wir reden also von gut 3.200 Zeilen geändertem Code. Das ist schon eine Hausnumnmer. Zum Vergleich: Die erste C++-Version (0.7), veröffentlicht am 09.01.2017, hatte insgesamt 3.684 Zeilen Code. Das ganze Programm.
Was jetzt natürlich noch fehlt, ist ein intensives Testen – insbesondere der Netzwerkfunktionalität. Da sind garantiert noch Fehler drin, bzw. neue dazugekommen.
Aber alles in allem sollte das Programm jetzt viel sauberer, robuster, und auch besser zu benutzen sein. Irgendwann wird das schon noch was ;-)
Endlich ist es wieder so weit: Nachdem das letzte Muckturnier der JU Leupoldsgrün am 28.02.2020 vermutlich auch eines der letzten Muckturniere überhaupt vor Corona war, geht es nun endlich wieder los, und zwar mit dem sage und schreibe 19. Muckturnier der JU Leupoldsgrün am 14.04.2023!
Für alle Details gibt es dieses Mal eine eigene Seite. Wir sehen uns dort :-)
Es gibt ein neues Maintenance-Release: Version 3.5.1 behebt ein paar Fehler, die beim Erstellen von Backups aufgefallen sind. Vielen Dank an Matthias Döhla für den Bug-Report!
Im Einzelnen:
Beim Erstellen eines Backups wurden alle seit dem Erstellen bzw. dem letzten Schließen der Datenbank zur Laufzeit festgelegten Parameter (automatische Markierungen, das Behandeln allein gekommener Spieler etc.) nicht gespeichert. Nach einem erneuten Öffnen der Datenbank wurden wieder die Voreinstellungswerte gesetzt. Das ist jetzt korrigiert.
Wenn eine nicht-sequenzielle Auslosung eingestellt war, wurden die Einstellungen bei gewissen Konstellationen beim Öffnen der Datenbank (bzw. nach einem Backup) nicht richtig geladen, sondern die Standardeinstellungen für die Auslosung gesetzt. Jetzt sollten alle Einstellungen für die Auslosung in allen Fällen korrekt wiederhergestellt werden (sofern die Datenbank nicht manuell verändert wurde und unsinnige Werte enthält).
Bisher war bei den Einstellungen für die Auslosung die Voreinstellung für die maximale Tischanzahl immer 1, solang diese Option nicht ausgewählt war. Wurde die maximale Tischanzahl aktiviert, nachdem man bereits andere Einstellungen vorgenommen hatte, wurden diese meistens verändert bzw. deaktiviert. Jetzt wird die maximale Tischanzahl automatisch auf einen sinnvollen Wert voreingestellt, solang die Option nicht aktiviert ist, damit beim Aktivieren die anderen Einstellungen nicht verändert werden.
