Improving the LCP (Largest content paint) performance

I am improving the way that the website create and downloads the images, the main reason is to make the user see something faster. Before the system were doing 2 main things:

• Go trough the entire list of images, creating the elements and placing them into the page.
• Position them.
  But the position of the items were being done after the creation of the images, in another function. Now they are in the same function: it create the element, position it and add it to the page.
  That does not seem like much, but the code got way faster with that, probably because it dont need to go item by item in an list twice just to create an element. I tested the time to load the first element and it went from 8.63s to 6.43s, the test was made with 2200 elements (Yeah ik, it is a lot and normally it isnt that much, but i had to see how they were holding with more than 22 items).

Also i fixed a bug that passed unnoticed while improving the responsiveness: At some point of images the visibility of the elements broke, that was because the perspective (what makes the 3D perspective of the component, and makes it visible with 3D effects) was based on the screen size, not the elements itself. What was the problem in that: Each element takes a size in the screen ‘makes the circle that shows the element be more and more near of our point of view’ (i cant explain it any better, search what is ‘perspective in an 3d element at HTML’ ). While it was approaching our point of view (POV), our POV were exactly at the same position (based on the screen size), so at some point the circle perspective would pass the POV and we would be unable of seeing it well. Now it is based on the elements: The 3d elements were basically a circle, i just used the diameter to change the perspective based on it.
TODO: Maybe i lowered the image quality too much… I will fix it in the next updates.
Also i were trying to improve the font settings to improve the performance, but that wast working so i decided to move on to this because it was more critical (took a while for me to jump to this, maybe like 2 hours trying and trying values in the font settings).
i am also working in a way to load the images in parallel, with that it will take way less time
(I didnt known about LCP before so i spent a while figuring out the way it works).

Improving the performance

After finishing the improvements in the responsiveness, now i decided to improve the performance. I used lighthouse to get insights (i learned about it in an tiktok video) and figured out that the images size were too high (were an png of 1280x1280px), so i saw more about that in the page: https://developer.chrome.com/docs/performance/insights/image-delivery (an link that google lighthouse gave).
With that i saw how to decrease the size while staying with quality, i reached up to the sharp-cli tool, that makes the work of resize, convert and compress the image for me. The command used was that:

npx sharp-cli -i *.png -o ./output resize 320 -f avif -q 50 --effort 6 --smartDeblock --preset photo

The 320 is the size that i want it to be at the end, i got that value by seeing what was the computed value (the value that is being used in the website) in an high resolution pc (not the most higher one, the high but normal pc) with the resolution of 2500x1714px.
With this simple changing the image went from 2mb to 40Kb! Nearly 100% decrease, and take in mind that there is more than one img, so the change were even higher.
Also i created 5 different images: 320px, 480px, 640px, 960px e 1280px. With them the browser can choose which one is better for each device. With these changes i went from 35 points of performance to 59.

The home is now fully responsive

Ah that took a while, but finally it is fully responsive. Now the description at the player UI resizes based on the screen size and active a scroll behaviour when need, also i did some minor change at the emotionDrum perspective to make it show more emotions at the same time, removed the padding in the arrows at the emotionDrum so they will have more space and fixed an error in the genre drum that was making it perspective broke.
After all these devlogs i improved how i make a code responsive.

The emotionDrum is now responsive!

Now the buttons that you use to select the emotion are in the same side as the div that displays the emotion, so they dont fight for space anymore. This change is meant to fix the low size of the items in screens that are too small, in the new way we have more free space to display the emotions, there is not much to say.

What else

I did some minor changes in the size of some items at the player area, now they are easier to read! (I increased the size of some items)

Im nearly finishing the workings on the responsiveness. Now the entire player screen is responsive and do not breaks the texts anymore (except for the description area), also the buttons that show you the next screen (the ones that displays ‘player’ and ‘generos’) are responsive too, the music queue is working perfectly fine, and the area that is used to select an emotion is nearly responsive too, it just needs some adjusts in the two buttons that change the current emotion because they become too small and uses a lot of space when the screen is too small, after that this screen will be finished.
It is taking a really long time, the fact of how many different screen sizes exists makes it harder to finish, but now there is times that i even cannot see if i changed the resolution in some areas, because the system looks the same. I spent quite a while testing different resolutions and combinations of size, i didnt even noticed that i where 6 hours here, but now ik more about css (things like container-type + container based sizes and more ways to set the size of an text)
The video shows how it is now, if u want to see the before just checks the past devlog.

Finished the correction of the errors at the perspective and click in the cover-flow component. Now the perspective stays the same 150vw value (that is based on the screen width) and stays normal, with everything working. Oh man, that needed a lot of logic and out of box thinking finding another ways to check where the user clicked without using an normal click event listener (for those who lost the past devlog or didnt understood, i cannot use a normal eventListener in that because the clicks is detected in another element or in nothing, even with z-index or more in css, so the solution should be done entirely on javascript logic).
The first video is the new way, the second is how it was before all changes in it

i finished the workings on the section of the home page that i where doing before, now has a good responsiveness for pc and a decent one for mobile.
Now im working on the main area of the home page, the one where the user selects the desired genre for the music (second img). It may looks completely fine, but that same element already was a headache before and is here again. The given area is the cover-flow component, before i already fixed it (or so i thought), but it was looking bad (the 3d perspective where a bit strange) and would probably broken if i added new genres.
I were trying to figure out a way to listen to the clicks in the card without any problems, that seems easy at first glance, but the 3d perspective in the element make other elements eat the click from one another, make the clicks dont be listened and so many problems that i nearly decided to erase it and write from scratch. I already found a way to do it by using the mouse position, the center of the screen and the card width (the genre img) to transform it in an value that can be used to select the exact card without any dependencies on the doom selector. It basically uses just some values, put in some calcs and get the difference between the current card (genre) index and the clicked.
Im nearly finishing it, but i still need to figure out some values and more.

Im improving the responsiveness at the home page (before was the player page), but for some reason that idk the emotion selection div is having a strange behavior, i will update what it is after i fix it. Take a look: (the item in the center should be centered)

Hi again! Like said in the past devlog, im improving the responsiveness of the website, specifically in the player part. But it had some problems and where distorting when playing an video, now it resizes based on the screen size in a way that it stays ¨normal¨.
The first video is the new way, the second is the old way.
It still needs a lot of improvements, but it is going!

Making the website responsive

Hi again! Like i said in some devlog, the website dont have support for mobile, that was because it was designed to be at kiosk mode and work just in desktops. but i decided to change that.

First of all: the site where using a lot of absolute values of dimensions, so it where braking even in the desktops (it wasnt responsive at all). But i spent a while changing it, it is isnt ready and has some problems, but is better than before.
(The mobile is still strange, i did not started fixing it yet).

Credits:
https://css-tricks.com/snippets/css/fluid-typography/ - This website shows about a way to make the texts become responsive for the screen using some calcs, it is worth seeing.

The first video is how it was before, the second is how it is now

Creating a new helper

Context: There was an class called youtubeFrameControls, this class basically where designed as an structure to help using the youtube iframe API, but with the time this class where becoming basically to hold just an function (and in a very inefficient way), because the methods that it had before (like the one that runs when the iframe is loaded) had to have more and more specific logic in the codes that used it, so they where useless (because the codes that where using it where rewriting it).

What i did: I picked the only function that where being used and transformed it in an helpers (that can easily be customized). This function was the one that creates the player of the musics, and the function where called createPlayer. Also i removed the old class (youtubeFrameControls) and replaced it for this helper in every place that used it.

It now is way more simple than before and can me more customized.

Refactoring the copa script

I where placing some scripts in a class. These scripts are related with the player functions of the copa script, so i pick all of them and placed in the same class. I did it to follow best practices, but i confess that i still got some doubts about when to create an class and when the variable or method should be static or private (#property), i will search and learn more about because maybe i will have to refactor some parts of the code following these rules of best practices. That was all for now, see ya!

Adding more bug checks

I added some checks in the player class at the startExplication function that checks if the src (the url for the audio) is valid or not by doing an fetch with the HEAD method and checking if the return is an valid audio before trying anything in this function. Also i solved this error in the same function:

Uncaught (in promise) AbortError: The play() request was interrupted because the media was removed from the document. https://goo.gl/LdLk22

This error was because the startExplication function where trying to play the audio before it was loaded, i solved it by making it play the audio just after it was load with the event listener canplaythrough.

There was another error at the playMusic function where the code where trying to play the youtube video before it was loaded, i solved it by making it wait until it was CUED (Where the video isnt playing, but is loaded and showed).

(The website was not created to be in mobile and dont has a lot of support, the video where recorded in my smartphone because i had to record the audio and the audio on my pc dont work. In the Future i Will add mobile suport, but right now im finishing the bugs and etc)

Adding a new description feature

So basically there was an place where was designed to have the description about an music, but that was empty and where only finished today

What it do

It is petty simple, it just show an text about the music that is currently playing, also there is an audio that plays before the music starts playing, but this audios is played just one time before the music so if someone loses it or didnt listen well there was not a second chance to listen for that audio. Now there is this place that holds the same content, but in the format of an text that can be read whenever they want while the music is being played, that was what i added.
Also that text can be hidden, so it will not stay using half of the screen every time (in the screenshot it is active)

What this audios do

This audio / text is part of the main purpose of the website, they give some fun facts about the music that may be useful someday in some kind of quiz or essay.
Also the audio is played before the music and the music plays just after the audio finishes. That is to make whoever is listening listen to the entire audio before having what he (or she) wants, so they will not listen to the music and skip the audio.

Studing about cache

So basically i where studing about cache, the main ideia was to implement it in the sistem, but then i realized something:

• Theres is nearly no difference between cache and a normal request in an localhost project, adding the cache would not improve anything, sometimes it maybe even slow the website, because the page would need load more code.

I realized it afther a while studing about it, but anyway lets focus on another thing.
Also i where studing with google for devs: https://developer.chrome.com/docs/workbox/caching-strategies-overview

Toast applied and tested

The toast notification component is now being used at the player class, i did some tests and it is working very nice, hopefully the user will not see it very often (because that would be a problem, the user must not see it unless there is an error playing the music).

But why did i make it?

It is used to show more about what is going on for the user, so they will not become anxious if it something is working or not.

Why not use another notification system?

Each notification system has its own use cases, the others would be very painful for the user. Imagine every time a simple error (that is simple for me) like the music fail to play there was an error that interrupt the use of the app with an popup or alert, that would be painful, dont it?
That is why i used an toast notification, because it is temporary (disappears after some seconds) and dont stop the use of the website.

Also there is a feature that i implemented for the same reason a few devlogs ago that add a fallback in the music search, so it wont show a message at every single combination.
Lets calculate how many combinations we have: there is around 50 musics in the database, 22 genres and around 40 emotions, multiplying the genres and the music 880 combinations that the user can make. Now lets see how many musics we can get: each music have around 1.2 emotions and 1.2 genres, so we get 72 combinations that lead to an music. With that in mind, we can see that from 880 combinations, just 72 of them are useful combinations, so we get a 8.18% for getting a music, and 91,12% of not getting one. Consider that each failed attempt shows an error that stop the use flow of the website, but that was before the past devlog, now it tries again and again and only afther failing everything it shows an error, at that point it must really show an error.

Thats all, sorry for the long boring text and thanks everyone that read, see yall later

The toast notification is finished

So i finished it, it is a component that u adds in the code that u wants to use. I added 2 icons, 1 for infos and another for warnings.

What i used and did

The element that holds it all is an dialog, the icons are svg, the text is a span and the element that shows the time left is an progress.
To update the time left i used an setInterval that runs at a 10ms delay and deduce 0.01 of the dialog value, so it will be smooth to see. Also there is an if inside that destroy the element and clear the interval when the value of the dialog reaches zero or less (In the past devlog i said about not using an if, but considering how low the cost for an if in that time is i decided to use it anyway).
The function that creates the toast receives some params that will let it be customized by whoever is calling it:

const icons = Object.freeze({ 
INFO: infoIcon(), 
WARNING: warningIcon()
});

function createToast({ message, time = 5, styles, icon = icons.INFO })
// the `message` is the displayed message
// the `time` is the time until close
// the `styles` is custom css styles for the element, it uses the dictionary format {}
// the `icon` is the svg icon

What else?

I will apply it in some elements and post about. See you later!

Creating a toast notification system

So rn im creating what i said in the past devlog about a toast navigation. This isnt finished yet, im still figuring out an way to check the end of the timer, i found some ways to do it, like using an simple if inside the countdown. I didnt comment but i am using an setInterval to decrease the time and an <progress> tag to show the value

but that is a bad ideia, imagine doing 1 if every 50 ms? that dont cost a lot of processing power, but i still will search for other ways to do it just to check, if yall got any hints or ideas leave a comment.
Also i will improve the design, the design is petty poor.

Fixing errors and adding bug checks

Hi everyone, so i were fixing some bugs that i saw that may broke the app, i fixed all of them (for now), here they are:

• There was a logic bug that a class (the one that controls the youtube iframe) where doing stuff that it wasnt supposed to do (not an unexpected behavior, but a logic that should be outside of it), it was an easy fix.
• There was a bug at the player class that when the provided sourceId (for the youtube iframe) where wrong or unable to use it crash and stopped doing anything else (like playing another musics). I tryied solving it in various ways, one was beffore the changes that i did in my last devlog, but i failed because the class that holds the player where hard to fix, this devlog fix it. I fixed it by adding some bug checks and, when some error ocurred, it play the next music.
• There was also a bug at the player class and youtube-iframe-controls class, that for a couple seconds in the start of the website it would broke if u tried to play a music. It was because in the start of the program the youtube API where unable to be used. To fix it i just made it wait until the API where ready using an ASYNC function.
• There was also a bug that, afther the past devlog, it was doing and request at the /api/songs with params at the wrong format. Afther the past devlog the API started using the params genre_id and emotion_id, but the frontend where passing with the incorrect name (genre, emotion).

Something that i implemented

• I upgraded the mysql query that where being used to get more infos about the music, before it where just returning infos like name, author, sourceId, etc, but now it also returns the genre and emotion from that given music.
• I added a bug check at the player class, now if it fails it pass to the next music.

Something that i want implement

I want to implement a simple toast notification system that will apear when something fails, like the playing of some music.

Others

The youtube docs for the iframe where very helpful for this changes, check it out: https://developers.google.com/youtube/iframe_api_reference?hl=pt-br

Optimizating some piece of code

So there was a certain part of the code responsible for the songs queue in the main route, that piece is a core function but where running a while true loop for no reason, here is the part:

async start() {
    while (true) { // { emotion, genre, author, name, sourceId }
      const musicData = await this.#musicQueue.get();
      this.createPlayer(musicData['sourceId'], null);
      this.#showMusicInfos(musicData['name'], musicData['author']);

      this.#queueList.removeChild(this.#queueList.children[0]);
      
      await this.#startExplication(`/storage/${musicData['explicationSource']}`);
      this.player.playVideo();

      await this.#musicFinished.when(true);
      this.#musicFinished.set(false);
    }
  }

Basically the code were calling it at the start and running it forever, but that code where a nightmare to maintain / implement, i tried to implement a safe check here for over 2 hours, but wasnt possible.
I replaced it for a more efficient approach that do a loop in a different way, here it is:

• when adding a music, it checks if it is already playing, if no starts to play.
• when start to play it checks if there is a music in the queue for it to play, if no it stops playing, if yes it get it and play.
• When the music that is playing ends, it call the play function (from the above topic).

That is just it, no while or constant loops, no overhead, it works by basically connecting all the codes in a way that they work together to maintain (or stop) the loop (notice how i said loop, it uses a loop but isnt a while or for loop, it connects the end of one code and the start of another, like a chain.
I made it in the pull request #2, check it out: here

Fixing some forgoten code and more

So at this devlog i were fixing some bugs in a specific ui / route called ¨copa¨, this is a special route added because a teacher asked our team to create them to use at some football games in our school. But since it was a hiddend route and mostly like a easter egg it hasnt been updated in a while and wasnt working anymore.

What i fixed

• i was following a pattern where most of the images that each route used should be in a special foulder of storage (literally called /storage), but this mode (copa) where created before it and was following the old way
• Also there was some errors ocurred afther i changed the entire folder structure, so the copa mode where completely broken, i fixed it too.

What i added

• I had a class about PHP + Laravel | API | Controlers in my course, afther that class i realized that the way the API (copa) where searching for data based on ID where wrong (was doing copa?id=…), i changed it to /copa/id
• There is a function that show the teams to the user to select one that he wants, but the teams list where hard coded and wasnt synced with the database. I made it use the database data instead of a hardcoded value

** That where all for that mode, but i didnt spent 5 hours just on it, i made more: **

Fixing (or making) some other bugs

• There is a script that controls the database that where holding and infinite single connection with the database, something like this

conn =  mysql.connector.connect(**configs)
cursor  = conn.cursor(Dictionary=True)

But all the codes where using the same connection and cursor, so i decided to apply a connecton pool and make each database call get a connection and a new cursor.
Also i added some functions to abstrac the connection and query part:

def __get_connection(self):
        conn = self.db_pool.get_connection()
        conn.ping(reconnect=True, attempts=3, delay=1)
        return conn

    def __execute_query(self, query: str, params: list | None = None, dictionary=True, query_type: QueryTypes = QueryTypes.ALL):
        conn = self.__get_connection()

        try:
            with conn.cursor(dictionary=dictionary) as cursor:
                cursor.execute(query, (params) or ())

                match query_type:
                    case QueryTypes.ALL:
                        return cursor.fetchall()
                    case QueryTypes.ONE:
                        return cursor.fetchone()
                    case QueryTypes.EXECUTE:
                        cursor.commit()
                        return cursor.lastrowid or cursor.rowcount
                    case _:
                        raise ValueError(f"Tipo de consulta não suportado: {query_type}")

If yall want to see it check here at my repo

That was also the first time that i used a Enum (on code) and branchs (on github, but i didnt used them properly)

Others

There was also some other changes, check the repo GF-Silva/Ritualia

What next

Now i will add some bug checks on a piece of code that handle the video display using an youtube iframe.

Changing some values to be relative

I spent a while (more than i expected) changing some strange values that control some settings of a component called cover-flow (this component create and control the images that are displayed in the home screen).
I spent more time figuring out what where each variable and lhe logic behind than acually writing.Before it had some hardcoded values that would probably broke if anything changes, i saw it and solved. I wasnt here for it, i was fixing another bug and fixed it before it broke.
I also used some basic math of circles like angle of an arc. That is all for today

I spent some time correcting errors and logic problems, here they are:

Error Correction

• Music playback would freeze when the music queue ended: This problem would break the app until you restarted it, but it was very simple to solve. I had simply made it remove the first instance of music from the HTML twice, which caused it to try to remove an element that didn’t exist, thus freezing the app.

• Removed an unnecessary loop: In the player section, there was a loop that iterated through all the elements (emotions) in a list to toggle the state of ONLY 1 ELEMENT. With the few elements it had (there were 3), this was minimal, but adding more could be detrimental to functionality. It only did this to toggle the state of the PREVIOUS element from active to inactive. I solved this simply by making it save the index of the last element and use that to access it. It took a while to work because javascript was treating 0 (the first indice / old indice when u start) as false in the if, but afther i figured out why it was simple to solve (if oldIndice != null)

Implementations / Changes

• I separated the API/WEB routes: Previously, the routes exposed by the backend (such as /songs) were in the same file. This wasn’t a problem before, but with the addition of new functions, it could become difficult to maintain and prone to various errors, as the routes weren’t separated (a name could be the same). Therefore, I separated them into: /api (backend API codes) and / (frontend web codes).

• I put the genres in the database: Previously, the genres were in the frontend, and to add a new one, I would have to update both the backend and the frontend. To solve this, I simply added a route that retrieves the current genres (from the database) and uses the data (name / location) to load them into the frontend.

• I added the emotions to the database: The emotions had the same problem; although both (they and the genres) were in the database, the frontend wasn’t based on that data, so I did the same thing I did with the genres.

• I changed the name of where the music explanations were saved: I must have mentioned in a devlog that the folder inside storage was called /explication_source, and I also mentioned that the name was incorrect (because the audio source wasn’t there, nor would it be; the audio files themselves are there), so I changed it to /explication_audios

Updating the README

I saw a post about how to structure a README, how to make it clear and etc. Afther i realized how wrong the old README was (it was confusing, and also was months out of date).

So I chose some topics that would be interesting to include in and filled in a skeleton, spending some time learning what to do and what not to do.

I also didn’t fill in some fields because they aren’t ready yet (they now are stored in my memory to add later).

How it was before: https://github.com/GF-Silva/RitualIa/blob/9a2a7756c777a7042eca28309924e5a408bd561f/README.md

How it is now: https://github.com/GF-Silva/RitualIa/blob/2dea5f80266f06e8633af1aa3c9430065cde9231/README.md

There is a huge difference.
Also i did some bugs and noticed how bad my commits are

After a development pause, here are the various changes made.

Also, I never mentioned it, but this project was made by students focused on the school environment.

(This time I finally got around to writing the devlog myself):

Structure

• Moved main.py to the root
• Replaced mysql-connector with the official version: The added library was a version I didn’t recognize; I added the official one instead.

Cleanup

• Removed some Code that wasnt being used.

Backend

• Change the return value of the SQL cursor: Previously, the cursor returned an array, but for code readability and security, I opted to change it to an array.
• Structured Error 404: The backend used abort in certain parts, but it returns HTML and certain parts of the frontend expected JSON, so I formatted the abort to JSON. This caused a headache, I hadn’t tested it (again lol) and when I saw it, it was time to present the project at school and I was having this error.

frontend

• Fixed the CoverFlow component: An error went unnoticed in the creation of the component, this made the size and spacing of the images look strange, it was fixed to a certain extent.

• I implemented a new playback policy: The text about it got so long that I decided to open an extra topic.

Playback Policy

Now it search for the requested emotion + genre that the user choose, If It fails It search Just for the genre, if It fails again it search for anything.
Now it falls into a fallback:

This policy change was motivated by having to find a song to show in a presentation and failing. I reflected that if it was annoying for me, it would be for the end user (students) as well.

Database

• Added new songs: I added 50 extras and their respective genres/emotions. (Also i wrote some helpers in python to help me categorize and search for the musics in youtube and get and structured sql output, that took quite a while)
• Saved the songs locally: Topic local saving

Local saving

But why would saving the songs in the cloud be a problem?
Nothing comes for free, the server we were using to host the music had a monthly access limit, which was a silent problem that, thankfully, was noticed before it happened.

My mistake, I didn’t even think about the possibility of saving locally and went straight to saving in the cloud, it must have been due to haste and inattention (always plan well what you are going to do before you do it, weigh the risks and benefits).
Now, how it works

• The audios are saved inside the /storage folder.
• The database still saves the location, but this time it saves the relative path (e.g., /explication_audiis/fun_audio.extension). Why save the folder path as well? Won’t the audios always be there?

Yes, but at some point the path might change (e.g., explication_source/youtube/audio_legal.extension).

Future plans

• I’m going to improve my devlogs lol, this one got huge

RitualIa in Evolution: Refactoring, Optimization, and New Features 🎶

Hey everyone! I’m back with a cool update on what’s been happening here at RitualIa.

After that commit where we transformed some scripts into helpers, things have evolved quite a bit. We’ve been doing a heavy refactoring of the project, focusing on organization, performance, and better code architecture.

What’s changed:

• Structure & Organization: I removed legacy folders that weren’t being used, did a mega merge bringing everything from /frontend (the folder that where holding ALL the frontend logics) to the project root (with that the frontend and backend are in the same folder), and switched from FastAPI to Flask on the backend. Why the change of FastAPI to Flask:

• Because my supervisor or mentor (something like this) said and said again to, because there was other guys in the project (still is, but im the main developer, the others stopped doing anything like mounths Ago, and even while they where doing something i still was the main dev), these other guys where total starters and could not hold the learning curve of FastAPI (even with the fact that was Just me that where using It, because it was at the backend and i was the only developing at back).

• Code Quality: We made several methods private in the PlayerControls class, making the API cleaner and more secure. We also fixed the “enclosing class errors” that appeared. These small fixes make a huge difference in code reliability.

• UI/UX Improvements: We created a new CoverFlow component to replace GenreCylinder on the homepage – it’s much smoother and prettier now. We added support for async onClick, grab + touch in CoverFlow, and adjusted visual positioning to keep everything aligned. Oh, and we removed that unnecessary playerText that was cluttering the interface.

• New Features: A really cool feature that was added was the checking for duplicate songs in the queue. Nothing worse than accidentally playing the same song twice, right? Now that doesn’t happen anymore.

• Maintenance & Updates: We updated the fetches to call the new routes, moved the favicon to assets (because everything has its place), and focused on the details.

What’s coming next:

We are in a consolidation phase, laying a solid foundation for the upcoming features. The focus now is on ensuring that each component is doing exactly what it needs to do, nothing more, nothing less.

Thanks for following along!

I’m transforming some duplicate code into helpers so they can be more easily used in new code.

Introducing: The ‘Ritualia’ project is a project developed by me and some colleagues with the help of the school. In it, we have done and continue to do research and assembly with the aim of impacting the daily lives of students in our school and (in the future) other schools. It is an open-source project with an article soon to be published detailing the foundations used, etc. The readme is currently outdated because I am redoing part of the current architecture, but I will update it later to include information on how to assemble and create your own version. The project is divided into hardware and software. I, along with other members, am responsible for the software (which is usable on most computers), and the hardware is relatively simple (it only depends on a display + sound + a controller with an OS + the preparations for installation).