-
Notifications
You must be signed in to change notification settings - Fork 2
Sprint2
-
Pull from main before the merge request: We had a lot of merge conflicts when reviewing the merge requests originating the fact that our local versions weren't up to date with the main branch
-
JSON deserialization in Arduino: In the beginning when working with this task, we found it confusing on how to optimally approach this since the researching enlightened different ways of doing it accompanied by different libraries. The main takeaway is that there are many ways of transfering and storing data
-
C++ is more low-level than Java : Since we were accustomed to the more high-level-language Java, we were forced to devote time in understanding the foundational logic of C++ intending to meet our ambitions. One of the problems that arised in this sprint was that declaring a string where it would make sense in Java would give us a compilaiton error. We learned the two following things:
std::string --> Used for manipulation of stringsandchar* --> Pointer to data type char
-
MQTT Broker: We quickly realized that the public MQTT broker services that we were using such has hivemq.com or emqx.io were not very stable and were causing lots of disconnects and bugs within in our product, so it was clear to us that the broker that we're using should ideally be our own locally hosted one to steer clear of any potential bugs.
-
Commits: We learned that when committing, it is a better practice to commit in small cohesive commits instead of a single large one, this has many advantages which include safer failure prevention due to more frequent commits, other members getting features earlier, and less conflicts.
The importance of working in an agile way as a team: Even though we have a discord bot in our discord channel that notifies us when changes are made remotely, we still need to communicate when important pushes to main are made. As for now, we have a discord channel solely responsible for storing the messages from the bot, but these changes represent every possible modification pertaining to this GitLab project (Wiki, ReadMe, Milestones, Issues, Boards, commits in every branch, ...)
-
We only want to see the pushes to main
-
Thus, we don't pay as much attention to each message due to the large quantity of messages
-
The learning outcome is that we need to communicate important remote changes that quickly needs to be pulled to surpress the severity of the presumptive merge conflicts
-
There are two individuals involved in the merge conflicts --> They are aware of this, but the other guys may not be aware of this, since it's easy to miss the merge-conflict-message