-
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 from 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 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 transferring 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 to understanding the foundational logic of C++ intending to meet our ambitions. One of the problems that arose in this sprint was that declaring a string where it would make sense in Java would give us a compilation 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 as hivemq.com or emqx.io were not very stable and were causing lots of disconnects and bugs within 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 fewer 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 the 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, ...). Although this wide range of information brings awareness to each member of the group on what changes in the project are made, we realized that in the context of finding the merge requests, the channel becomes bloated caused by the large quantity of messages. Many members have therefore started coding on a new feature using an outdated version of the main, entailing larger merge conflicts in the future. In other words, we want to create a new discord channel for the bot that only notifies the acceptance of merge requests that allows us to know when to pull. Unfortunately, this feature is beyond the scope of this project, and we have a more time-efficient solution: The individual who accepts the merge request has to notify the entire group to pull from the main. We need to communicate important remote changes that quickly need to be pulled to suppress the severity of the presumptive merge conflicts.
Overall, we feel that sprint 2 was extremely productive and delivered many of the planned-out features for the app during it. From the Android UI to the terminal, our progress was exponentially better, indubitably due to increasing familiarity with the technology we are working with. Communication regressed and yet progressed at the same time. We met just as often on campus however we started communicating less while we are away. That change could have led to increased productivity as each member knew their role to play in the puzzle.
One thing to note, the TA's highlighted that our commit numbers were either off or that some members were not doing enough. Upon reflection, we believe it was improper commits at the start of the project as changes were pushed in large chunks instead of smaller pieces. Not to say that unequal contribution is not completely absent, as with any team project, the degree of contribution will vary based on numerous factors.