Über Mich

Ich beschäftige mich seit über 25 Jahren mit IT Architekturen und entwickle nebenbei seit dieser Zeit auch selbst sowohl beruflich als auch privat Software.

Seit etwa 20 Jahren spiele ich Badminton. Fand das anfangs noch sehr spradisch und ausschließlich als Hobby statt, bin ich aber nun seit über 10 Jahren im VFL Gemmrigheim.

Über KLUE Badminton Services

Die Idee zur Entwicklung dieses Services ist über die Jux Turniere unseres Vereins entstanden. Einmal im Jahr richten wir ein Vereinsturnier aus bei dem der Spaß im Vordergrund stehen soll, trotzdem wollen wir aber auch spannende und faire Spiele haben. Also haben wir nach einer Lösung gesucht, die uns ständig (für jedes Match) wechselnde Doppel und Mix Paarungen zusammenstellt. Die erste Lösung war schnell gefunden: Zettel mit Namen drauf, die wir verdeckt ziehen. Das sorgt zumindest für den Faktor Zufall. Nachteil ist aber, dass sehr schnell ähnliche Partien und Paarungen weitere male zusammen treffen und oft die Partien sehr unfair sind (die beiden stärkesten gegen die beiden schwächsten). Dann fehlte ja auch irgendwie ein System, die Ergebnisse fest zu halten und daraus eine Rangliste zu generieren.

Ich hab dann einfach mal ein Excel mit ein bissle VB Makro erstellt und das haben wir die nächsten Jahre genommen. Die Anforderungen an das Excel sind aber immer weiter gestiegen und waren bei jedem Turnier etwas anders. Mal spielten wir mit vollen 16 Spielern, dann fehlten einige und wir mussten mit einer krummen Anzahl starten, wollten aber trotzdem, dass alle gleich oft dran kommen. Dann wollte man mal nur einen Satz, mal 2 Sätze mal bis 21 mal bis 11 spielen. Dann mussten teilweise Spieler mitten im Turniergehen... . Das ganze war ziemlich schnell zu komplex um es mit Excel bedienen zu können.

Ich habe mich dann einfach mal hingesetzt und mir überlegt, wie man das besser machen kann und habe eine kleine Java basierte Software Lösung entworfen und schliesslich entwickelt, genau für unseren Anwendungsfall (Jux Turnier). Nun wechselten wir vom Excel auf die neue Software Lösung. Aber auch jetzt kamen Jahr für Jahr immer weitere Ideen und Anforderungen hinzu.

Da ich auch bei uns gemeinsam mit zwei netten Kollegen das Kindertraining leite und wir auch für die Kinder nach einer Lösung für eine interne Rangliste gesucht haben, habe ich eine zweite Software ähnlich der Jux-Turnier Lösung entwickelt. Ziel war hier eine "Vereinsrangliste" zu haben, wo die Kinder sich frei nach Lust und Laune miteinander messen können. Jeden Trainingsabend wurden 1-2 Spiele ausgetragen.

Nun hatte ich über den Herbst und die Weihnachtsfeiertage etwas Zeit, was mich dazu veranlasst hat, die Software "aufzubohren" und einen Cloud Service dafür zu entwickeln. Als erstes kam eine Mandaten Trennung und eine Benutzerverwaltung hinzu. Danach habe ich Schritt für Schritt weitere Turnier Möglichkeiten dazu entwickelt. Und am Ende das ganze noch etwas aufgehübscht und mit einer Webseite versehen.

Das System ist jetzt fertig und kann genutzt werden. Wenn jemand gute weitere Ideen hat, baue ich diese gerne noch in die Lösung ein. Einen Überblick, was die Software alles kann bekommt ihr über die Hilfe Seite.

Über die Architektur der Lösung

Den ein oder anderen wird vielleicht interessieren, wie man eine solche Lösung am besten aufsetzt. Darum nenne ich hier ein paar Details ohne zu stark in die Tiefe zu gehen.

Architektur

Software

Die Software wurde mittels Vaadin Framework und Hibernate als Java JEE Software entwickelt. Gepackt ist sie als einfaches WAR (Web Archive), die damit auf jeder J2EE Plattform lauffähig ist. Ich nutze hier den Apache Tomcat 9.x und Java 8.x

Entwickelt wird die Software mit Eclipse

Datenbank

Als Datenbank nutze ich Apache Derby 10.15.1.3 (Java DB) unter Open JDK 11.

Loadbalancer

Als Loadbalancer kommt nginx 1.17.6 zum Einsatz

Virtualisierung

Meine ersten Versuche habe ich als Single Node in der Azure Cloud mit den freien App Services gemacht. Das wurde mir schnell zu instabil und auch zu langsam, bzw. wäre als bezahlter Dienst eben zu teuer.

Deshalb läuft die Lösung heute virtualisiert innerhalb von Docker Container in einem 3-Tier Modell in meiner eigenen Umgebung. Hinter einer Firewall steht der nginx Loadbalancer, der seine Anfragen an 2 Tomcat Applikations Knoten verteilt (Session persistent).

Die Applikationsknoten persistieren ihre Daten wiederum auf dem 3. Layer, der zentralen Derby Datenbank.

Hardware

Also Hardware kommt ein Raspberry PI 4b mit 4 GB RAM zum Einsatz. Die Lösung ist so schlank gehalten, dass das völlig ausreicht. Die Applikationsknoten brauchen selten mehr als 100MB RAM, die Datenbank weniger als 150MB und der Loadbalancer gar nur 15 MB. Da auch die CPU Last selten mal die 10% Marke erreicht ,war der Raspberry wohl etwas "oversized" :-)