yakread

I've been working on this kind of thing over the past several years (for a while full time as an attempted entrepreneur, now on the side for the past couple years). The latest iteration is https://yakread.com -- hit "take a look around" and you can see the "home page"/a list of recommendations without signing up. The recommendations are personalized, i.e. the probability you'll see any particular post depends on your individual interactions with past posts, if you've signed up. (it does collaborative filtering with spark mllib). So that may be a bit different from what you had in mind, since your comment sounds more like an unpersonalized system, but with some extra exploration thrown in. However in practice I suspect the biggest thing the collaborative filtering is doing at Yakread's current scale (not much) is learning which items are g

Hm, I was curious about the biased shuffle, since I was not expecting that particular shape. It looks like we basically build up the list of bookmarks as follows [0]: x = rand() if x < p: element = first element else: element = random element return [element] + shuffle(rest of list, according to the original order) In some sense, it's reminiscent of selection sort. Any particular reason for choosing this approach? One "obvious" downside is that this ends up being an O(n*k) algorithm because you end up building a new list each iteration. It's also harder for me to intuitively understand how shuffled the list is based on the parameter, other than at the two extremes. [0] https://github.com/jacobobryant/yakread/blob/bff756c68d86a07... I'm also curious about the interleaving approach described in the last section:

It's a fun part of the code to work on for sure :). I started trying out datastar in another part of the app by the way, mostly for the frontend signals so far e.g. https://github.com/jacobobryant/yakread/blob/8a61443235d1f6f... Since this app isn't collaborative it's not clear to me if there'd be any benefit of doing any long-lived SSE vs. just sticking with the request-response model I'm already doing with htmx. Also since various parts of the app do take 100 - 1000ms to render/query, so rerendering the whole page on any change I don't think would be a good fit. But even just having the signals part baked in is pretty nice.