About Me

I myself have been developing software professionally and privately for 25 years. I have been playing badminton myself for almost 20 years. The first years only as a hobby then in VFL Gemmrigheim.

About KLUE Badminton Services

The idea for the development of this service was born through the Jux tournaments of our club. Once a year we organize a club tournament where the fun should be in the foreground, but we also want to have exciting and fair games. So we were looking for a solution that would give us constantly (for each match) changing doubles and mix pairs. The first solution was quickly found: slips of paper with names on them, which we draw undercover. At least this ensures the factor of coincidence. But the disadvantage is that very quickly similar games and pairings meet up more times and often the games are very unfair (the two strongest against the two weakest). Then a system was somehow missing to record the results and to generate a ranking from them.

I just created an Excel with a bit of VB macro and that's what we used for the next years. But the demands on the Excel have always been higher and higher and were a bit different at every tournament. Sometimes we played with a full 16 players, then some were missing and we had to start with a crooked number, but still wanted everyone to get the same number of times. Then we wanted to play only one set, sometimes 2 sets, sometimes 21 to 11. Then some players had to go in the middle of the tournament ... . The whole thing was too complex to be handled with Excel.

I just sat down and thought about how to do it better and designed and finally developed a small Java based software solution, exactly for our use case (joke tournament). Now we switched from Excel to the new software solution. But also now year after year more and more ideas and requirements were added.

Because I also lead the children's training together with 2 nice colleagues and we also looked for a solution for an internal ranking for the children, I have developed a 2nd software similar to the joke tournament solution. The goal was to have a "club ranking", where the children can compete with each other as much as they like. Every training evening 1-2 games were played.

Now I had some time over the autumn and Christmas holidays, which led me to "drill" the software and develop a cloud service for it. First of all, a client separation and a user administration was added. After that I developed step by step more tournament possibilities for it. And in the end I made the whole thing a bit more pretty and added a website.

The system is now ready to be used. If someone has good further ideas, I will be happy to incorporate them into the solution. You can get an overview what the software can do on the help page.

About the Solution Design

Some of you may be interested to know how such a solution can best be set up. That's why I'll give you a few details here without going too much into detail.

Architecture

Software

The software was developed using Vaadin Framework and Hibernate as Java JEE software. It is packaged as a simple WAR (Web Archive), which can be run on any J2EE platform. I use the Apache Tomcat 9.x and Java 8.x here.

The software is developed with Eclipse

Database

As database I decided use Apache Derby 10.15.1.3 (Java DB) under Open JDK 11.

Load balancer

As load balancer nginx 1.17.6 is used

Virtualization

I made my first attempts as a Single Node in the Azure Cloud with the free App Services. This became too unstable and too slow for me, or would be too expensive as a paid service.

That's why the solution now runs virtualized within Docker Container in a 3-tier model in my own environment. Behind a firewall is the nginx load balancer, which distributes its requests to 2 Tomcat application nodes (session persistent).

The application nodes in turn persist their data on the 3rd layer, the central Derby database.

Hardware

As hardware a Raspberry PI 4b with 4 GB RAM is used. The solution is kept so slim that this is completely sufficient. The application nodes rarely need more than 100MB RAM, the database is less than 150MB and the load balancer only 15 MB. Since the CPU load rarely reaches the 10% mark, the Raspberry was probably a bit oversized :-)