-
Notifications
You must be signed in to change notification settings - Fork 2
Sprint3
Issues labeled out-of-scope signifies our future updates if we were to continue this project
-
Impossibility of sending an MQTT message of a string containing notes for an entire song: The wio terminal crashed when it recieves a string containing all notes. We were forced to align our thoughts with space complexity in order to implement the feature of being able to play songs from the speaker without hard coding these notes in Arduino. We came up with a solution to send sequential song-note-chunks, where each chunk is a substring of equal length
(except the last one if the song-note-string can't be divided into N chunks) -
Impossibility of sending pictures along with the string of song notes: Since the images were bigger than the song-notes combined with the impracticality of chunking images, we made the decision to exclude this idea from our project. We could have hard coded every single song-image in Arduino, but that would cause an inconsistent unmaintainable code. As mentioned in the bullet-point above we do not hardcode our songs. Hence, hardcoding the images would just detoriate our project from the developers' point of view
-
Prevent loss of changes when merge conflicts arises: Clone local back-up repositories or push changes remotely on separate branches before merging branches whose internal contents are differentiated by a significant number of commits
-
In regards of code-implementation, there's always a way to optimize or polish one's code to fulfil its purpose: In previous courses we learned about the SOLID principles for maintainability and the reduction of time complexity with efficient algorithms. In this course, one thing we learned among other things is that the way you write algorithms affects the space complexity. As mentioned earlier in this page, we couldn't send the song-notes in one whole string due to the resulting space required for the wio terminal to recieve it. Therefore, we changed the algorithm and divided the string into sequential sub-strings.
- There is more than one way to protect the main: We were previously only aware of creating branches from the master branch, but one more important aspect is to push on a frequent basis to the main. This entails more testing since we must ensure that this branch always works regardless of the state in the project. However it easily is broken by the resulting complexity of the merge requests accompanied by many commits, and solving these conflicts of larger scale is not only risky, but time consuming and inefficient
Lessons applicable to other courses (General, Team dynamics, Team management, What we would be different if we would do the project again)
- Detailed plan of the system and its interactions from the start: At the start of this course, we set out on a kind of concrete plan, directing us all in a somewhat common direction. Nonetheless, as the project progressed the apparentity of our differing interpretations of the project's internal approaches grew.
-
This caused our - Because we developed our idea as the project progressed
-
Use diagrams - Sequence diagrams
-
This detailed plan will help us identify what interactions between systems to be implemented, then we would first make sure every connection works and then we would focus on implementing the features - Save time - Classes not bloated
Link here
Sprint 3 went quite well. Although it was a lot of work initially, we managed to get the majority of it done. However, we did consider some features to be out of scope due to technical difficulties in their implementation such as saving a bitmap of the user's profile picture to the phone's local storage. Moreover, there were many bugs that we had to iron out and consider that could have been dealt with if we tried the app extensively instead of testing it only after a feature is implemented which lead to a lot of chaos and long meetings to fix them.
The documentation of the project we feel was overall good. We made a few diagrams that could help newcomers to better understand the project scope, aim, architecture, and functionality it provides.
We believe the app is easily extensible and modular for future updates if the team wishes to work more on it as a passion project.
In conclusion, we are quite satisfied with the MVP the team has created for users who are passionate about their weight loss journey while enjoying music in a way they have not experienced before.