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.

The second sprint definitely improved from the first sprint. In this sprint we mostly worked on the Message Queue, sending and receiving JSON data and then inserting it into a local MongoDB database. We did this with RabbitMQ and the ampqlib Node.js package. To do this we first created sample JSON objects then stringified these objects in order to send it to the message queue. Then we pull them off the message queue with our receive module, parse the string back to JSON, and send it over to the Insert module where we then put a timestamp on the data and insert it into the database. I also designed the endpoints and researched how to put JSON data into a CSV formatted file for the report.

What worked well was our teamwork this sprint. Me and Derin worked together to make the send and receive files, changing them to send to two queues, and deciding how we were going to do it. I would say that the teams teamwork has improved greatly from the first sprint where we all kind of did our own thing. This sprint we took the time to communicate and combine our knowledge to get stuff done.

What did not go so well was our production rate. We did not get a whole lot done, as we only worked on the message queue. This could be partly due to getting used to working with others as we had to focus more on communication than work. This means that we did not get to work on dockerizing our application, working with Migena to integrate our keycloak system, or any other of the backend functions such as the endpoints.

Changes that can be made include improving our teamwork/communication skills, everybody should learn at least an overview of the other technologies even if we are not the people implementing them, and communication with the other teams as well. We still do not know the data that will be sent to us, how we will connect our containers together etc. The last thing we should change is our productivity rate. Designing the endpoints and working on the message queue is not enough work for the sprint. There is still a lot to be done and only one more sprint left to do it. For the third sprint, we will all have to pick up the pace to get it done.

Changes I can make as an individual would be making an effort to communicate with the other teams, learning technologies I will not use directly such as keycloak, and communicating with Migena and Haoru to combine the backend with frontend and the keycloak system. I think it would be extremely beneficial for me to at least learn how keycloak works so that I can properly work with Migena to implement it into the whole system. A last thing I would change as an individual would be to take more time to understand Docker as I will be using it in the third sprint to containerize our application. I do not have a great understanding of it just yet.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/tree/main/src/subProcesses

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/34

This is the card I made about meeting for the event system cross cutting team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/44

This card was for deciding the message format we would use.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/43

This card was to learn how to use rabbitmq with docker.

This sprint was not significantly better than the first for me, at least in terms of productivity.  Something that worked a little better than last time was adding details to cards. Last sprint I used the cards very little, if at all. I mostly added links to cards with no explanations. This time I added explanations for the cards’ purpose and updated them (at least the meeting card was updated).

Many things also did not work well this time. Because I did not join the event cross cutting team until this sprint, I had no idea I would be working with RabbitMQ. This sprint a lot of time was spent learning about it. That probably should have been done during Sprint 1. I also just did not do as much work as I should have or wanted to do. It was a little tough having to coordinate between two teams as well. I felt like I was neglecting my original team as I worked with the event system team. The even system team if really more like two pairs though with Rainiery and I trying to coordinate with the reporting system separately to send messages to them.

As a team I think we did really well, or at least the rest of my team did really well. Adding Cameron did not disrupt our workflow at all, and he meshes really well with us. I also feel like he brings a lot to the table and is just a really smart and cool teammate in general. We are able to communicate what we need with from each other well too. Like when Tim would show us and keep us updated with the mock front end design. We were able to give some input as to what we thought needed to be changed or what we thought was working well. We were generally just on the same page and I was very satisfied with my team for this sprint.

As an individual, first and foremost I should contribute more to my team. While I do not feel like I was holding anyone back, I do not feel like I was adding anything to the team. I understand we are all working on separate systems, but I do not think I did much to move our team forward. I also should have kept my team updated better on what we were doing in the event system so we could plan ahead for sending messages from our back end. Personally being able to communicate better with everyone is something I have to work on.

Overall, while this sprint was not my best performance, it was one filled with a lot of progress of my team as whole and at the end of the day that is what is more important. I am part of a team and we have a task to accomplish. I should be a part of accomplishing that task and sharing the load equally with everyone else.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/40

This was for designing how the database would look and the schemas for all the different fields required.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/30

This was for the implementation part of the reporting database that I designed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/26

This was for reviewing css and html using tutorials online.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/23

I worked on designing the API for some of the backend endpoints by playing around with swagger.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/80

We worked on creating an open api yaml file that will be used in the next part of the sprint.

The thing that worked well in this sprint for our group, the reporting system, was that before we started the sprint we were able to break down more efficiently what everyone’s role would be. For this sprint we added one more person, and they were responsible for their iam system and each of us had our roles. However, this time I was able to work separately on my issues and then meet with them team for issues that are related to the whole team and how we can help each other out. A lot of the database stuff I was working on was related to the backend aspect, so I worked on that with the other teammate who was assigned the backend role.

Some things that didn’t work well was that we had problems with some of the things we were supposed to do with the report. It was unclear in the beginning what aspects would go in the report and which teams would be sending what. So for this sprint there was a lot of meetings to figure out more of the aspects of the report and not as much as being able to implement the features required.

A few changes we could have made as a team for future sprints are to have the meetings with other teams or product owner about the specifics earlier on in the sprint. This way we can focus on creating the different schemas and backend as well as frontend implementations that are required for the overall pantry and not be stuck on the details. With this procedure, we can get more work done and if there is any confusion we can meet and clear it up after we have done some more implementations on our parts.

Changes I can make as an individual to improve the sprint is to figure out all the details of my role first, then start working. There is not point in getting confused on what to do and start working without a clear grasp. This is where I can work with my team more and ask more questions about a certain issue I have. Instead of working independently on all my tasks, I can ask my team for certain things that there are issues on.

Overall, I think the second sprint was really helpful managing confusion with the project and sorting it out to a solution by meeting with the team and others. I think we helped each other out with the details by meeting with other teams and the product owner who had more details about the product we were supposed to make. I think it was a good learning experience and successful sprint and I am looking forward to the next sprint.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.