From d389bc33308caa2efcffeeca7f3f3d9d429a7f6d Mon Sep 17 00:00:00 2001 From: overflowerror Date: Sun, 4 Aug 2024 11:55:19 +0200 Subject: [PATCH] feat: Add about page --- html/about/index.php | 8 ++++ html/styles/main.css | 61 +++++++++++++++++++++++++ view/layout.php | 12 ++--- view/pages/about.php | 104 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 180 insertions(+), 5 deletions(-) create mode 100644 html/about/index.php create mode 100644 view/pages/about.php diff --git a/html/about/index.php b/html/about/index.php new file mode 100644 index 0000000..9cfa192 --- /dev/null +++ b/html/about/index.php @@ -0,0 +1,8 @@ + - +
+ +
diff --git a/view/pages/about.php b/view/pages/about.php new file mode 100644 index 0000000..d205114 --- /dev/null +++ b/view/pages/about.php @@ -0,0 +1,104 @@ +

About

+ +
+ +

The Story

+ +

+ Back when I was in school I watched + The Social Network movie. I was fascinates by the scene in which Zuckerberg implemented Facemash in an + eventing. So, I was kinda curious if I could manage that too. I didn't. I took me 3 days to implement a very + simple version. (Writing this now, I also found out + that it took Zuckerberg + a week + - not just an evening. Welp.) Instead of students, my version used pictures of my professors, that I scraped + from my school's website - which, in retrospect, was morally a bit problematic. +

+

+ Recently, I found the old source code again, and I was thinking: Maybe I can rewrite it. Let's not use humans + this time, and instead use something nerdy: Minecraft mobs. And while we are at it, let's also do it properly + - the previous version really was quite bad from a technical perspective. +

+ +

Implementation

+ +

+ The basic idea is to give the users the choice between mobs. The better one is selected and its internal + rating increases. The algorithm used is the Elo + rating system. I won't go into details here, but the basic idea is the following: It works by assigning + each candidate a number, and calculate the winning probabilities for each match. This winning probability + then determines how many points are gained/lost by each candidate. +

+

+ We can also use this rating to calculate the idea pairing. Mobs that have a similar rating might be more + engaging to compare than mobs where it's obvious which one is better. +

+

+ The challenge here is twofold: First, we need to be able to asynchronously calculate and write the ratings to + the database. This could theoretically be solved by utilizing transactions. The other problem is, that I want + to be able to delete entries from the database in case I detect spam or "cheating". So, we need a list of all + changes, so we can undo them if necessary - which would also mean we need to recompute all ratings. +

+

+ The way I chose to solve those problems, is by doing the calculations in on-the-fly in the database. The + only thing we need to store, is the match-ups including the winner and the date for sorting. The rating + calculation is then done by starting from a base rating for each mob (1500 in this case) and applying each + match to the ratings in sequence using a recursive query. (Initially, I tried to keep each rating as its + own row. However, I was not able to make it work. Not sure if that's a limitation of PostgreSQL or if I'm + just not smart enough. ^^ Either way, the current solution uses jsonb objects for the rating + state - which also turned out to be much faster than having each rating as its own object.) +

+

+ This approach works quite well and can handle a few thousands of votes with no issues. However, since we + need to iterate over all matches every time we want to calculate the next pairing, it doesn't scale well + beyond that. My solution for this was to introduce a caching table, that contains a recent snapshot of + the ratings. The recursive calculation than seeds itself with the cache instead of starting from the + beginning. This cache can be generated regularly (maybe once a day) to keep the responses snappy. +

+

+ The flip side of using this cache is, of course, that in case I need to delete some matches, I also need + to delete the corresponding cache entries. It's not a huge deal, but certainly something to be aware of. +

+

+ If you want to learn more, check out the source code over on + Github. Pull Requests are welcome! +

+ +

Credits & Tech Stack

+ +

Minecraft Related Content

+ +

+ Minecraft content and materials are trademarks and copyrights of Mojang Studios. +

+ +

Fonts

+ + + +

Frontend Frameworks

+ + + + +

Backend Technologies

+ + + +

Special Thanks

+ +

+ I'd like to thank the Minecraft Wiki for letting me let use their API to + automatically update the mobs in the vote. The pictures for the mobs are also provided by them. +

+ +
\ No newline at end of file