That’s So… Randomizer

One feature for the Stats Page that had been floating around in my mind since I started developing Version 4 was a way to get a random show that I could just queue up and listen. I finally had a couple of hours to build out the logic to add not only a randomizer for shows, but also for guests, hosts, locations and panelists.

What made easy to implement across the board was being able to use MySQL/MariaDB’s RAND() function in queries. Otherwise, I would have needed to pull down a list of valid IDs for each respective table and use Python’s RNG to pick one at random. While that result in better randomization over the long run, but it would add to the processing time. I wanted it to be as quick and efficient as possible from the application point of view. The RAND() function in MySQL/MariaDB may not scale all too well for tables that have record counts in the tens of thousands. Of the tables in scope, the table with the most number of records is still in the low thousands.

From the front-end perspective, I added a “Random Show” icon in the navigation bar and item in the slide-out navigation menu for devices with smaller screens. There is also a link to load a random show from the main “Shows” page. The randomizer will only include shows that have a show date that is less than or equal to the current date. This should prevent future shows from being selected.

To get a random guest, host, location, panelist or scorekeeper, there is a link on their respective main section page.

I am looking at adding the feature to get a random show from a specific year and possibly adding randomizer endpoints to the Stats API.

In addition to the new randomizer feature, the Stats Page now has rudimentary 404 handling and some of the dependent packages have been updated to keep up with security updates.

As always, the source code for the Stats Page is available on GitHub and is published under the terms of Apache License 2.0.