Creating the website required two almost disjoint efforts. One was the writing of a C++ program to do the actual scheduling. The other was the creation of a website to collect data and display results. The discussion here goes in that order since there are issues involved with the scheduling program that ultimately can only be resolved by subjective opinion. Also, fortunately, it is easy to abstract most of that material enough to make it readable by most everyone. The discussion of the interesting issues associated with the creation of the website will be difficult to understand by anyone without a website creation background.
Scheduling Program
The running of the computer program doing the actual scheduling is kicked off automatically at a preset time. The automatic running of programs is easy to do on any Unix/Linux/Mac computer via a facility called cron that has been around since the 1970's.
When the number of players desiring play is small (roughly less than 15) or the number of start times is small (roughly less than 5), the simple strategy of exhaustive search over all permutations of players meeting hard constraints works. The hard constraints here are player availability on particular days. But searches over permutations are notorious (among computer programmers and mathematicians at least) for blowing up in computational complexity as set sizes increase and that happens here. The scheduling program has a fall back strategy to use when brute force becomes unworkable. It seems to be working satisfactorily, but this is a difficult problem and difficulties may surface when larger numbers of people are playing than have been playing during the Covid pandemic.Defining best for the search brings in subjective judgement. It is necessary to weight the relative importance of having everyone playing their desired number of times versus creating matches with foursomes of comparable playing strength. It is easy to have a weighting factor available to control this relative weighting. Currently it is set based simply on a best guess. Once more are playing and there is more flexibility available in creating the schedule it may become possible to adjust this parameter more intelligently. But even when the tradeoff controlled by this weighting factor is more fully understood, there will still remain the problem that humans will not generally agree on the relative importance of these two goals.
Some randomness is intentionally introduced into the scheduling program. The intention is to shake things up some so that the same players are not playing together week after week. There are two ways randomness is introduced. One is to deviate randomly from week to week the crude player strength estimates obtained from the ladder. The other randomly picks each week a player to favor in scheduling. This latter will only come into play when the number playing is large enough that exhaustive search is unworkable.
A weighting constant is available to control the strength of the weekly random deviations added to the playing strength estimates coming from the ladder. Thus it is trivial to provide control over just how strongly shaking up the schedule is to be weighted. But the problem of ultimately needing human opinion to balance conflicting goals just got worse as there are now three goals to balance.
Website Creation
The website is hosted on an Amazon AWS LightSail Debian Instance. Little configuration was needed beyond Amazon's initial setup of such an instance. Of this, most notable was the installation of Apache2 and PHP packages.
The computer the Instance actually runs on is somewhere in Oregon. LightSail is cheap (two cans of tennis balls per month) and has been thoroughly satisfactory. Amazon may be poised to take over cloud computing in the same way it has come to dominate shopping.
I did not resort to using a "Framework" in creating the web pages. Nor even JQuery. I gather the decision not to use a framework is unusual and the decision not to use JQuery even more so. Frameworks and JQuery are software packages that aim to provide a "better" and "more convenient" interface for page designers than that defined by the underlying HTML and CSS international standards. But I had absolutely no problems writing pure HTML, Javascript, and CSS. Fifty years of experience writing software has left me extremely leery of middleman software. The middleman can disappear. Worse, bugs are inevitable and with middleman software present you have to debug not only your own code and the underlying base interface but also the interface defined by the middleman.
Obviously this soapboxing is all opinion. It is also, apparently, opinion not shared by many. But one unarguable advantage to the approach is that the resulting web pages are small and load fast. Each page, even with the images, is less than 100 kBytes. There are typically only 100 lines of PHP to be interpreted by the host before sending and then only 100 lines of HTML and 100 lines of CSS to be interpreted by the browser. I typically see about 80 ms load times when pages are hosted by my PC on WiFi in my house and about 400 ms when hosted by Amazon in Oregon.
Two buzzword phrases for web page design these days are "responsive web design" and "full functionality for all, with only better aesthetics for those with better browsers." They are good. They both reflect the fact that much browsing of the Internet is now done on cell phones with their tiny screens, rather than desktop computers with their wide displays. There is no way to make the browsing experience on a cell phone as pleasant as it is on a device with a huge monitor, but you at least want to make it functional with the small display.
Thanks to the LetsEncrypt effort it is possible to have the website deliver HTTPS without incurring any expense. Prior to LetsEncrypt, it was necessary to pay fees on the order of $200 per year to obtain the necessary certificates (private keys) to prove you are who you say. Any access to the website via the meadowsTennis.com or http://meadowsTennis.com URLs is quietly upgraded to HTTPS. It isn't really necessary to worry about security on this website. No money is exchanged and new software can be easily uploaded in five seconds if what is there is ever compromised. But it is nice to be running HTTPS anyway as Google Chrome (and I assume all other modern browsers) flash security warnings when you land on a website via HTTP and attempt to view a web page containing form uploads. The browsers have no way of knowing that for these particular pages there is no concern over anyone eavesdropping on the page downloads or monkeying with data uploads. Since it is easy and now incurs no expense, it is simplest to just keep the modern browsers happy and their human users not worrying about potential security problems.