# Yo world, more nerdage!

Hello, it me. I'm here with another update on our ml social network book recommendation app that is being built as i write this. We are reaching a real stride in our understanding of the important parts of what we are building. Not to insinuate that that stride wasn't their all along for Kyle. To me, it's very exciting to know what I have to build, even if it is a lot of work - i think one of the hardest parts of building an app is being paralyzed with the many potential problems you can solve. Narrowing down which ones you want to tackle gives you clarity of how the entire system has to work together, and makes it seem all the more possible. That said, for all the newly obtained clarity i have - i am definitely second guessing prior design decisions made 7 months ago. (i'm fixing them dw).

Experimenting with Websockets and avoiding db collisions

One of the cooler parts of our app relies on this concept of a bookshelf, which you can think of like a sometimes collaborative playlist on some popular music apps ( not naming names! ). I think one of the common missed opportunities of music apps is that many of them seem to disregard their social features as more of an afterthought. I know that is easy for me to criticize in my ivory tower of an unfinished WIP software, but i do believe that if they reordered some basic ux to isolate users less (possibly by recommending users with similar taste to each other, connecting playlists, personalized song suggestions, etc) they could have a much more engaging platform. I'm feeling confident that the WIP designs we have for our bookshelves WON'T make this mistake, and instead will strike a nice balance between becoming a feature people can use completely for themselves or being something our users can share with others, bringing people with similar taste together and helping spread knowledge by curating ranked book collections.

But lets address some of the interesting problems we've run into so far. We have these collaborative shelves, which people can create and then assign admins with write privileges too. Write privileges give users permission to reorder books in a shelf, add books to a shelf, and delete books from a shelf. All of these actions might occur simultaneously by different users. As a result, we have been thinking about a few o shits:

• o shit, this user just reordered a book that was deleted. • o shit, this other user just reordered a book that was just reordered somewhere else. • o shit, this one user keeps deleting the same book, while another user keeps adding the same book, while someone else is reordering books.

We are updating clients real time with websocket streams which are created when two users with write privileges edit the same bookshelf at the same time. Changes are sent to a server side service that uses a doubly linked list to check for possible fuckups and either returns errors or executes db calls directly. We also may implement a priority queue depending on the speed of all of this since dll's are slow at traversal and if you have a bookshelf with 100 books that is being reordered it could be nice to send the write actions to a queue to execute instead of doing it directly from the dll class. Also, we might completely scrap that idea, and look at pre-existing db collision solutions available online, although implementing our own could be really fun.

Recommendation algs

Our recommendation alg is going to take time. I honestly am not an expert on this and am more focused on providing us with a front end architecture that wont crash, doesn't do anything weird, is easy to use and looks good.

I've attached some screenshots below:

Other stuff i've been doing:

• Working at ma job 👷‍♂️.

• Playing around with GoLang 🛵 - its pretty freaking rad, although pointers are mad weird.

• Building a Chatgpt action, which i will have to finish tomorrow.

Peace✌️🥐🥐🥐🥐🥐🥐🥐🥐🥐🥐!