Matt’s Status Report for 3/30/24

  • This week was focused on system integration to get ready for the demo. So first I wanted to make sure that the Pis would be able to talk to each other for every song request made. It worked with one user as I was showing this past two weeks but for some reason it did not work when an extra user was making song requests. To fix this I tried to make the queue client class have async functions, and tried to research and take advantage of async Springboot decorators, and I tried to actually make a whole new queue client class for every message—none of those worked. I then tried a different approach which did not even have a separate queue client class. This works all the time for multiple users and is the simplest approach actually with the smallest amount of code. Second Luke, Thomas, and I integrated all of our parts over three different meeting sessions so that we could host the app on the first pi, get user requests with the second pi, and then actually do the computation on the second pi and send back the recommended song to the first pi and update the queue in the backend (I don’t think it actually pushes changes to the front end until there is another song queued/requested so that will be the next step). There were multiple bugs associated with this integration because of name changes and just finding bugs through testing which we worked as a team to fix. Finally, I implemented functionality for changing colors when users like and dislike as well as the app saving what songs each user likes and dislikes. The saving functionality just mentioned is important so that when users request new songs, it won’t reset their likes for other songs which it used to do. We do this by having a dictionary for each song object which maps user id to whether they liked, disliked, or felt neutral about a song. When the whole song queue gets sent to the javascript the dictionary is checked to see what color each song button should be. While I did not implement the actual user keep alive this week like I said I wanted to, I did implement parts that are important for it. I made a new class that maps users to each song they have a vote for and am adding to it appropriately. This is the object that will be referred to when removing user votes because of inactivity.
  • I’d say my progress is on schedule still. I did not do what I said I wanted to do last week but still got a lot of needed work done so it was a good week. 
  • Next week I want to have the app update the queue when a song recommendation is completed, not display like and dislike buttons for song recommendations, and then implement the user keep alive so that users who are not active will not be able to vote.

Leave a Reply

Your email address will not be published. Required fields are marked *