I thought this sprint went well. While the team definitely has room for improvement, I thought that the team cooperated and managed to accomplish our main goal for the sprint, which was to give functionality to the backend of the project. We managed to add the necessary endpoints as well as give invesntory.js functionality. We also managed to accomplish other tasks like adding commitlint to the gitlab-ci.yml file in all the projects repositories as well as coming to a consensus regarding the naming conventions and style decisions. I thought that, overall, the team was much more cohesive this sprint compared to the previous one. The team was able to communicate much more effectively, and the team was more aware of what needed to be accomplished.

I think the team still has room for improvement that could help us become even more cohesive and efficient. I think the biggest area where we could improve is how we come up with tasks and divide the labor. The tasks that we had in our sprint backlogs over the past couple of sprints were rather imbalanced. There were some tasks in there that were important, challenging, and took a lot of time to complete. But at the same time, there were also other tasks were minor, easy, and took little effort to complete. This led to some team members having tasks that would take them more than one sprint to complete, while other team members did many simple tasks and were left with little to do by the end of the sprint. I think this sprint we should try to break up the big tasks into smaller ones, and group minor tasks into bigger, more general tasks. I think team members should also ask the other team member for help if they think that they cannot finish their task by the end of the sprint.

Individually I thought that my performance was satisfactory. I mainly worked on adding commitlint to the gitlab-ci.yml file in the project repositories, but I also spent time trying to understand how RabbitMQ worked. For the latter, I created a demonstration for RabbitMQ that shows how things are sent and received. Ultimately, I managed to complete six tasks by the end of the sprint that are worth seven points. I think my biggest issue was that the tasked I worked on were either too specific like adding commitlint or too broad and vague like figuring out RabbitMQ. I also think that I didn’t communicate with my teammates as much as I should have.

Personally, I have a lot of room for improve in several areas. One of the areas that I want to see myself improve is communication. I felt like I did not communicate with my teammates as much as I should have. For example, I felt like I should have kept my teammates updated with my progress on the RabbitMQ demonstration. For the next sprint, I want to use Discord as well as class time to communicate with my teammates more. Another area where I want to improve is taking on more challenging tasks. Over the past couple of sprints, I felt like my tasks were either too simple or too minor. So, for the upcoming sprint, I want to try taking on a bigger and more challenge tasks.

List of issues that I worked on:

Issue InventoryAPI#2: Added commitlint in gitlab-ci.yml in InventoryAPI.

Issue AddInventoryFrontend#6: Added commitlint in gitlab-ci.yml in AddInventoryFrontend.

Issue CheckInventoryFrontend#4: Created gitlab-ci.yml in CheckInventoryFrontend and added commitlint.

Issue CheckOutGuestFrontend#7: Created gitlab-ci.yml in CheckOutGuestFrontend and added commitlint.

Issue InventoryBackend#27: Created gitlab-ci.yml in InventoryBackend and added commitlint.

Issue InventoryBackend#22: Spent time learning how Rabbit MQ works and created a simple demonstrations that shows how things are sent and received.

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

With reflection on the previous sprint we had a more clear vision of what we could modify and change about the front end systems and possibly some work to be done about the back end system. We also as a group decided to reach out to the IAM and AWS teams to see if we could integrate their work with ours. I also had not finished my previous tasks so it was an issue that I personally needed to address and focus on during this sprint.

I still had the two previous issues from the last sprint on my hands but I did take the responsibility of communicating with the other teams and start working on understanding their work to help integrate it with our team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/8

On this sprint the majority of my time was working learning html and CSS, but in a manner that was constructive and effective as my previous sprint learning session did not go well. In this sprint I had a far more effective learning period by following a six hour html and CSS course which helped me greatly [https://www.youtube.com/watch?v=1Rs2ND1ryYc]. A major portion of my time was watching this, pausing to test out the things I learned and working on the html pages for the Worcester state styled formatting. This would all have been added to their necessary repositories, but I noticed something both funny and disappointing at the same time that changed all the work that I needed to complete.

While I was nearing the end of the sprint I felt as if the pages I did have were ready for testing and possibly creating a branch for and wanted to test it in one of the front ends. I tried running the front end docker containers on my desktop, but I never could get the local host page to run. It would load forever and never show me anything. I also tried separate front ends to see if it was just one front end’s issues, but I still had the same issue. It wasn’t until I tried running two front ends at the same time and had to change one of the ports to discover that it was just local host 8080 that was having a hard time. I tried connecting to it without any containers running on those ports and a page I had not seen in a while showed. It turns out somewhere on my mac laptop Jenkins was running [https://www.jenkins.io/]. This was preventing me from running and I had to do a deep dive through my laptop to find it and stop it completely which had taken far more time than I wanted to. With it disabled I ran the containers and connected to the local host page. It was there that I found that a front end landing page had already been made and implemented and I had unnecessarily wasted my time on trying to create pages for the front end systems. Now I don’t feel as if my time learning on html was wasted but the app.vue already had the needed formatting and style that was appropriate for the landing pages.

Right at the weekend before the end of the sprint was around the time that the IAM team contacted me and provided information on how to set up the keycloak system and I had spent a little bit of time that weekend looking it over. That same weekend was when I had made the discovery about Jenkins. The href task was easy enough to implement and I had tested it and it worked. I just did not have the time at the end to create my own separate branch for each front end as I felt like it needed to be split into separate and specific issues for documentation reasons. The next sprint will have those two fully solved and I’ll probably be focusing the majority of my time on integrating the IAM teams work and testing out their work with ours, but at least I understand html fairly well now!

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

For this sprint we did much better as a group. Communication improved and we are comfortable with the project now. After the first sprint I was worried about how we would perform but now I am much more confidant in our abilities. I am excited for what we will achieve during the upcoming sprint.

Over this past sprint we have gotten the backend to work, added commitlint, updated config files and pipelines, and learned how to use RabbitMQ. I personally did the commitlint for the backend, frontend, and API projects, and worked on the pipeline. I am happy about how everything turned out, and I feel like I learned a lot about how commitlint and the gitlab pipeline works. When working on commitlint I decided it would be cleaner to work in a separate branch since I needed to push to gitlab in order to test my work. I am happy about how it worked in the frontend project, but in the backend I accidentally worked on the main branch instead of the commitlint branch. When working in the future I must always be aware of which branch I am working on and review my work before pushing, since you should not orphan public commits.

When working on the frontend I ran into a problem that was not present for the other projects. I found a solution on stackoverflow and made a comment about it. I am not sure that this is the best place to explain myself since I wonder if people will be able to find my comment in the future.

One thing that I am happy about is that I have increased my workload. I still want to do more in the future, but I am happy that I am doing more to help my group out. I think this is something we could all work on as a group. Most of our work is done in class which is ok, but we would get much more done if we all worked outside of class. One thing I think we could do to improve this is to schedule out-of-class work sessions where we would work for a few hours.

One thing that I think didn’t go well was branching. We made many branches this past sprint, and I do not think we used them properly. In my case, I made a useless branch since I did not use it at all. I feel as though using many branches, while useful, can contribute to confusion with our team and future teams. I do think we should be branching, but I feel as though we could do it better.

Overall, I am happy with the progress we are making. I am glad that the backend works finally, and I am glad that the gitlab project is coming along. I am excited for the upcoming sprint since we have almost finished refactoring, and we can begin working on new features. I am concerned about making new features since I do not have any ideas as to what to do, but whatever we decide to do as a group will be fun to work on.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Following sprint 2, I will start off by saying what worked well. I think we are a little more comfortable with how the sprint process works. An improvement from the last sprint was that we knew what needed to be done for this sprint. We as a team decided to try and flesh out the backend and get it working before we start building the frontend. I think that we went into the sprint strong as everyone sort of picked up issues and started right away. Personally, I spent most of the sprint time working on the removeInventory endpoint and trying to wrap my head around how it would work. I had to look back on past endpoints that I worked with to try and find something to base it off of and ended up with something that made sense to me. For the most part, everyone finished their respective issues and we ended the sprint with a more structured backend.

Of course there is always room for improvement so I think we could definitely improve in terms of communication. There wasn’t much communication between class sessions, mostly reporting back to the team during the standup meetings. While it wasn’t detrimental to the workflow, it should definitely be something to keep in mind, myself included. In the second half of the sprint, we were trying to get the endpoints in one place so that inventory.js could be written and tested. There were some inconsistencies that I found between the endpoints and inventory.js so we should’ve definitely coordinated to decide on function names. We also ran into some issues trying to run the backend container so we couldn’t actually test it this sprint. For the next sprint we will need to test the backend and make it function as intended.

Based on my previous statements, we should make a point to increase communication outside of class time. During this sprint it wasn’t a major issue since we were mainly focusing on our own issues and only needed to coordinate once everything was done. That being said, we should make sure to notify teammates when we finish working on things so that we can carry on smoothly. Since we will need to get the backend working for the next sprint, I think coordination between those who worked on the endpoints will be essential. 

I will say that I am guilty of the lack of communication. I should have just sent a quick message to the discord when I had created a merge request or had an issue in need review. In this case, once the removeInventory endpoint was completed, I should’ve let Sebastian know since he was writing Inventory.js and I could’ve coordinated with him on the function names. Throughout the sprint, I essentially only worked on one issue, which was creating the endpoint. I would like to be more productive, finish issues within their set weights, and then move along with the development. I know what needs to be immediately done for the third sprint so we should be going in strong. I look forward to getting the backend tested and moving onto frontend work.

Issue #25 in the backend involved creating the removeInventory.js endpoint, where I referred to the API and existing endpoints to create.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

For this sprint, my team, team-1, have worked with two epics, which are refactoring backend and adding commitlint to gitlab-ci.yml for all projects which are reportingAPI, reportingFrontend, reportingBackend. We have finished the epic of adding commitlint to gitlab-ci.yml for all projects by following the instructions. However, the most important goal that our team wants to achieve in this sprint is to make the backend work as expected. First of all, we checked the code to see how they were written, and to see if they were written correctly. However, after I found many errors in syntax and some logic implemented incorrectly in the old code. I decided to create the new backend instead of spending time to fix all of those bugs. As a result, we divided our team into three subunits to work independently with the backend. One would try to refactor or fix the old code as much as they can, one would try to create the new backend, and one would create the test for the backend.

My role in this sprint is to create the new backend and refactor it in the new style. I worked with a docker file and index.js to create a backend server. Then, I created a docker-composed.yml containing node image, mongodb, and rabbitmq, to ensure all the services work correctly. After that, I used javascript to generate all possible methods that can be used to make required http requests, endpoints. In the end, the new backend worked as I expected. It has Rabbitmq service and Rabbitmq functions used to receive all messages from a queue. Then, the backend will store those data into mongodb as two collections, guestInfo and Inventory. Finally, this backend will generate the .csv report when we send the required http request.

As for the results of this sprint, I believe our team has achieved its primary goal which is to make the backend work. However, it is not perfect. There are still some issues that we need to solve in the next sprint to meet the customer’s requests, such as creating a function that automatically consumes messages using Rabbitmq, adding some more required columns to the report, change the _id property in the fake data to studentID. On the other hand, we have also created a test for this new backend even though it is not completed yet. We are planning to complete it in the next sprint.

In summary, there are some differences in how things work in this sprint. We have worked independently on the same problems but in different ways. This sounds like we wasted our time having multiple people working on the same problem. However, for this project, I think it makes sense to do it this way. That is because we all do not have enough knowledge to solve the problem, so there is no guarantee that we can successfully create a new backend. So, we decided to keep it safe by preserving and refactoring the old code while working on the new code. I think this is one of the disavantages of this sprint and needs to be improved in the next sprint. In the next sprint, we will back to work with the regular way, each person should take care of different issues to use their time effectively. For myself and my entire team, we have made some improvements comparing to the first sprint. The only thing I think our team should improve more is that we need to communicate more to understand the project deeply, to be ready for the presentation.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

I think that in this sprint we greatly improved our workflow as a team, we knew what we were doing and were a lot more efficient about knowing what we were doing and completing it. We were also a lot better at communicating with each other this sprint than in the previous one, keeping each other updated on what we were doing and what we had to wait on in order to complete our section of the work. We just overall worked a lot better together and were able to complete things as a team as needed in order to get the job done.

Despite the fact that I think we did work a lot better as a team and we did communicate better, I think that it could still certainly use improvement. While we are better about it I still feel like there is some difficulty in communication about what each of us is working on at any given time, and we tend to just wait until class to talk to each other, other than the occasional discord message. We also still have trouble working on the technical side with git, making sure we are merging when we should and focusing on the epics, most of the time, at least for me, we just focus on the individual issues on the issue board and completely ignore the epics aspect of the project organization. Similarly, I think we are still having issues actually running the code with the backend in order to actually test things, but I think that is something we can definitely iron out in the last sprint.

To improve as a team, on the issues listed above, I think that we need to focus a little more again on communicating, especially when things are done and need to be reviewed, and then when they need to be merged. I don’t think we have huge issues in these areas, we just need to make sure we are letting everyone else know when we are done with things. We should also make more explicit what we are working on at any given time, only pulling things to in-process when we are actively working on them would fix this issue I think. Possibly we should focus more on completing epics than the individual issues, just to keep a little more structure to our workflow, but I don’t think it’s been a huge problem thus far, just something to think about. And lastly, I think a big focus of sprint 3 would be making sure we can actually run the code for testing and have the docker images work properly and everything. I think we have talked about it briefly, but getting that fixed I think should be a priority.

As an individual, I think I still need to be a bit more productive and involved in the actual coding process, a lot of what I have done this sprint was just refactoring the file structure and getting some documentation issues worked out (which come to think of it could probably use a little more work). Other than that I feel like I have done very little actual programming work in the past 2 sprints. I just feel like when it comes to doing things other than coding I have a little bit less interest and it is harder to motivate myself. This is a personal issue and I want to finish out the last sprint being as productive as I can be. I am definitely also a culprit of not communicating enough, so I want to make sure for our last sprint that I am keeping everyone updated on what I’m doing and when I’m planning on doing it.

Issue #18 Removed an old file that was a placeholder from a previous group called endpoints.js.

Issue #21 Merged the endpoints folder and the subProcesses folder to remove complexity within the system, keeping the endpoints folder as the main folder for the endpoints.

Issue #2 We discussed naming conventions as a group and I added a markdown file in the Documentation repository to keep track of any style conventions we want to keep a record of.

Issue #24 Created the endpoint for getInventory, using the endpoints from the API and the methods written in the Inventory.js file for functionality.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

I did the bulk of the work for this sprint in one sitting. I haven’t really figured out whether I think this was a good idea or not. On one hand, changing gears is something I’m not great at and I try to minimize it as much as I can. On the other hand, I wound up being pretty burnt out on the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/15

Here’s the first issue I completed. “Learning RabbitMQ” is kind of an ephemeral goal, so I decided to only look into what I consider to be the bare minimum of what we will actually need, which is essentially just the ability to put messages in the queue and take them out of the queue. I feel like I know enough about it to work with it and help get other people up to speed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/16

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/17

I’m sticking these issues together because I wound up having to do them at the same time. To refactor things in the backend, I had to at least make sure it ran without errors, and to do that I needed to sort out the dependencies so that everything being imported at the top of index.js was either removed or installed.

It wasn’t until after I finished doing all this that I remembered someone had already modified the backend server to get it to work, only on a different branch. While that kind of tunnel vision is generally a bad thing in my opinion, doing all this work enabled me to actually understand how this project works. Specifically, I had a breakthrough in understanding that the server is actually just a program with its entry point being the index.js file. My previous experience with web development lead me to believe that the actual flow of the program logic was obscured behind all kinds of layers of indirection and it is in my opinion a little embarrassing that I didn’t see sooner that that was not the case.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/22

Finally, I deleted a directory containing a project from the previous developers that they were using to mess around with RabbitMQ. Not much else to say about that.

I also considered tackling the issue I wrote before about updating the documentation for every project, but I decided against it. Apart from being a little burnt out, I also figured that it’d probably be better to put it off as long as possible so that whoever tackles it can go into it with as much knowledge as possible.

Individually, I think my main issue is just a matter of setting aside time for this project. As a team, I think our biggest problem is the granularity of our issues, although it’s somewhat necessary considering our experience level and the nature of the project. While I struggle to put the work in, I don’t think the team as a whole has this problem. 

All that being said, I am kind of excited about this project now. I was initially skeptical of my ability to contribute to this project, but now I feel like I actually sort of know what I’m doing

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.