Der Name lügt!
Im Cyccess-Universum gibt es im Augenblick zwei getrennte Server. Der alte verbindet die Desktop-App mit der Handy-App: der Trainingsplan wird am Desktop erstellt, zum Server geschickt und der Athlet downloadet ihn auf sein Handy. Oder der Athlet geht aufs Laufband und wenn er fix und fertig ist, berichtet das Laufband die Trainingseinheit and den Server und der Trainer kriegt sie direkt in die Desktop app.
Seit einer Weile gibt es einen neuen Server nur für die Desktop-App. Damit werden Trainingspläne und Tests zwischen verschiedenen Installationen direkt ausgetauscht - das ging früher nur mit manuellem Export und USB-Stick. Als Bonus bietet der neue Server auf eine Web-Oberfläche, wo man als Athlet seinen Trainingsplan angucken kann.
Die beiden Server wissen nichts voneinander, alle Übertragungen werden vom Benutzer ausgelöst: der Trainingsplan-Upload vom Trainer, Handy-Download, Upload eines Tests oder Sprunges usw. Und jede Übetragung fließt auch nur bis zum nächsten Endpunkt: die Laufbandeinheit wartet am alten Server auf den Download zum Handy und zum Trainer. Wenn der Trainer downloadet, wartet sie in seiner Desktop-App auf den Sync zum neuen Server. Dort wartet sie wiederrum bis der Co-Trainer sie auf seinen Desktop holt. Das ist unnötig langsam und umständlich und fehleranfällig. Je länger es dauert, bis überall der gleiche Datenstand herrscht, desto wahrscheinlicher ist es, daß Konflikte auftreten.
Die offensichtliche Lösung ist die direkte Kommunikation zwischen den beiden Servern. Das habe ich Claude, der KI, erklärt. Er kam hat sich einen soliden Plan ausgedacht und zügig umgesetzt. Der Code sieht gut aus, beim vorsichtigen, manuellen Antesten hat auch alles funktioniert. Dann sollte Claude noch einen Systemtest für die neue Funktionalität hinzufügen. Auch das sieht sehr solide aus:
Funktioniert hat es nicht, weil es die Trainingseinheit "Schnellkraft Standard" nicht gibt. Claude hat sich gedacht, das könnte wohl eine gute Trainingseinheit sein. Das stimmt, aber wir brauchen eine, die in der Datenbank auch vorhanden ist. Mit so einer ging es aber immernoch nicht.
Das Problem ist der Signierschlüssel für die Tokens in der Systemtestumgebung, der muß 32 Zeichen lang sein. Das ist unser Signierschlüssel:
Den hat sich Claude ausgedacht, als er den Systemtest aufgesetzt hat. Er wußte anscheinend, daß es 32 Zeichen sein sollen, aber fand dann wohl, daß es nicht so genau darauf ankommt, ein Zeichen hin oder her, wird schon niemand merken.
Natürlich hat er, darauf angesprochen, sofort gemerkt, daß der Schlüssel zu kurz ist. Und gleich korrigiert:
Damit lief der Systemtest dann erfolgreich durch. Den Plan hat er nach meiner Feature-Beschreibung allein erstellt, die Umsetzung hat er auch gut gemacht. Aber an scheinbar trivialen Problemen scheitert er - daß ihm nicht klar ist, daß eine Trainingseinheit auch tatsächlich existieren muß um im Trainingsplan eingetragen werden zu können, und daß er zwar einen 32-Zeichen-Schlüssel erstellen will, aber nur 31 Zeichen schreibt.
Für mich ist er ein enorm mächtiges Werkzeug und eine riesige Arbeitserleichterung. Wie eine Tunnelbohrmaschine - mit der kann man in zehn Jahren fast 60km Gotthard Basistunnel graben, wo man von Hand mit zehnmal mehr Arbeitern in hundert Jahren nichtmal 10% schaffen würde. Aber die Vorstellung, sie einfach einzuschalten und alleine graben zu lassen, ist absurd. Genauso muß man dabei bleiben, wenn Claude arbeitet, und er belohnt einen mit lustigen Momenten.