Significant risks for the project we managed this week:

  • We have encountered difficulties while migrating to AWS. We can host the Web on Apache but Apache continues to host outdated files even if we reboot the server after making changes to the Django files.
    • Succeeded in deploying it to aws server but failed to make it work with apache
    • Currently, need to keep the program running on server and keep the server open in order to make the web app work (Though the web app does work), if Apache is added, then no need to ssh onto the server and run the web application, Apache will keep it running.
    • Met a problem that the code for saving files does not work and files are not saved on server. Fixed this problem by changing the relative path for the files to be absolute paths and the scores can now be saved.
    • Another problem is that Apache always seems to be running an older version of the code. Checked on Google but did not find solutions that could help us and before we find a way to not need to deploy to aws every time we changed something in the code, we decided not to use Apache.
  • Restructured the communication between the web application and the tracker program. Tracker is no longer acting as a TCP server but gets session information from the web application through restAPI calls.
    • After careful consideration, we decided to change the original TCP communication model between the web end and the tracker program to the communication channel through restAPI.
    • Originally, the tracker program acts as a server and waits for the web application to send the title and session information over. However, since it makes more sense to let the Django application act as the server as well. Thus, we deleted the TCP communication channel and replaced it with a restAPI channel.
    • Now, there is a FlipSession model with saves the user session details. Every user has a corresponding flipSession which is constructed upon and registration. The FlipSession model keeps a state which has two possible values: 1 for SESSION_START and 2 for SESSION_END. When the user has done selecting sheet music, his/her flipSession state will be changed to SESSION_START and the score_name field will be updated with the name of the selected score. Either when the user ends the session or when the user logs out, the state will be changed to SESSION_END.
    • The tracker asks for the FlipSession info through restAPI every 2 seconds. When the SESSION_START is set, the tracker gets the name of the sheet music from the JSON response from the web application and starts the matching session. When the SESSION_END is set, the tracker interrupts the running thread and waits for the next SESSION_START signal.

Changes made to the existing design of the system:

  • N/A

An updated schedule if changes have occurred:

  • N/A

0 Comments

Leave a Reply

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