-
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
- 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 introduced an environment where we developed our ideas spontaneously founded on what we currently have and the deadlines to meet, which in turn lead to us having to devote more time to go through the process from idea to completed implementation. The things we would have done differently if we would start the project all over again would be the following:
- Closely observe dates for deadlines and presentations
- Define target customer and problem domain to satisfy
- Create profound functionality-scope of project based on the two preceding steps
- Outline comprehensive plan for the internal workings as well as the external communications for each existing component
(sequence diagram, software architecture, MQTT communication between devices, component diagram)
Note: The aforementioned planning procedure would help us identify what interactions between systems to be implemented
- Create the necessary topics in the app and terminal
- Make sure every topic sends the correct message when it's supposed to
- The group decides on a particular topic to focus on and implements its associated functionalities
Note: This procedure would save us time because we were struggling with identifying the root of the MQTT errors because each class already contained a lot of functionality
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.