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.

 Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend

I created a new generate WCFB report frontend which I used the sample frontend example from the professor. I have already had a basic model for the frontend, the one I need to do more is to connect the backend API which can let customers download the report for the inventory.

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

I designed the API for backend endpoints.

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

I met with Marcos and Matt and talked about the difference between each group’s FrontEnd design. Also, for the next sprint, we will be having more meetings to help each other out on the API.

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

I looked for WSU visual standards to use for the frontends.

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

As a team, we created a Docker_compose file for the Integration of all systems.

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

I implemented FrontEnd for Reporting with the most recent version

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

I am stilling mak OpenAPI.yaml fileReflection on what worked well?

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

As a team, we are looking at the new architecture and plan accordingly.

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

As a team, we are looking over TheasPantryReport.

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

I am researching Kubernetes with Migena.

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

We are reviewing Scrum issue boards

In terms of what worked well, through the first phase of working together, team members are working together more efficiently to complete the project plan than ever before. After a period of teamwork, we have a deeper understanding of our mission goals and become more accustomed to each other’s habits. There will be a relaxed working atmosphere and the chemistry between the groups will encourage each other to move the project forward.

Reflection on what didn’t work well?

As for why it didn’t work out, there was some confusion about the final product as to the future goals of the project. When faced with unknown challenges, we are still a little confused. As we communicated with the professor, we had some clear goals. Because the front end and the back end are related. Taking charge of every task affects productivity. So we have overlapping project leaders working together to get the job done, which improves efficiency. The task was difficult and challenging, but we encouraged each other through the ZOOM meetings after class.

Reflection on what changes could be made to improve as a team?

As a team with cooperation experience, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress together.

Reflection on what changes could be made to improve as an individual?

As an individual, I need to improve my understanding of the Frontend more quickly to help my team better connect Frontend and backend. I need to arrange my group tasks more reasonably to help promote the whole group project’s completion. Besides, I also need to make clear my work objectives, continue to follow up on the team’s project, and make my part and the whole develop simultaneously. 

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

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

Here is the Link to the repositories that contains everything we worked on Sprint-2. Backend, Frontend, Event system, and Keycloak.

RabbitMQ Docker container:  Created a Docker container for Reporting Team

Learn how to get messages from Queue:  Learned How to send and receive messages using JSON object

Meeting with other Event System Team:  Met with the other teams to discuss the format and schema

Review CSS and HTML:  Reviewed CSS and HTML for the Frontend design.

Work with Backend/Database for MQ: Worked with Database and Backend to figure out the Receive file.

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object.

What worked well / did not work well

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object. I noticed that working together with the team has improved our work productivity significantly and working together helped us to solve problems as a team. For this Sprint there were still a lot of confusing elements. Especially, we had a hard time understanding how the report worked and what the data was involved in the report. Also, the issue description on Gitlab was not precise enough or was not broken down into steps. We were lost in some aspects and did not know what questions to ask. However, it is almost the end of the semester and everyone is busy with exams and project from other classes

What changes could be made to improve as a team?

As a team, we should be communicating more with each other and the professor whenever there is confusion or questions regarding the materials. Also, breaking down the task into small issues will help the team tackle problems one by one. I think it will be great for our team to talk with the other group for example all the FrontEnd people can meet and talk more about the issues and problems they are facing. The same goes for the backend, this will help improve as a team. We also need to add more info to the cards which solve the issue of any confusion regarding who is doing what task.

 What changes could be made to improve as an Individual?

As an Individual, I should be talking with my team more rather than just doing the issues that are assigned to me. If I am struggling with something, then I should ask my teammate or the professor for help rather than just waiting and trying to figure out myself. Since it towards the end of the semester and since every class, I have a project, I should be planning or a schedule to work on individual tasks rather than doing everything at once.

Overall, this was a great learning experience. I think the second sprint was a success and we got a lot of working parts done for the project. I’m looking forward to seeing what the reporting team will accomplish towards the end of the semester.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Hello,

welcome back.

  In todays blog post I will be writing about my second sprint developing part of my universities food pantry website. My team recently finished the second sprint, during which we focused on developing basic skeleton code with basic functionality in place for future development. I and another teammate worked on the front-end development of the project while one classmate worked on the backend and another person worked on the IAM (Identity and Access Management) Communication among our group occurred mainly through GitLab and discord. At the beginning of the sprint, we mainly had documentation on the concepts we were to begin using and now we have progressed to having multiple branches of skeleton code developed.

During the first sprint, I had begun researching REST API and OPEN API with intentions on developing that area of the project. However, due to personal health reasons I was unavailable for slightly over two weeks and was not sure if a return to the project was possible. Due to these unforeseen setbacks, my team had to switch up task assignment. When I returned, another teammate was tasked with taking on the API design, which meant I was to take on the checkout guest front-end. This set me back even further than anticipated because now I had to switch to doing a completely different part of the development process. I began researching and completing tutorials on Vue.js which ended up being quite a bit to take on whilst trying to develop something presentable with Vue.js for the first time. I learned quite a bit and am happy with the progress I made as a student. I take pride in the development of the Checkout Guest front end thus far. It is linked below under the updatedFunctionality branch:

CheckoutGuest

For the second sprint, our team faced the challenge of applying the knowledge/concepts we gained earlier studying Express, Vue and keycloak and applying it. I was uncertain of how to approach the input validation of the student ID field but ended up modifying some code for an input field. I specifically spent some time verifying that the submit button was disabled unless an input of seven digits was entered. I assumed we would work with the WSU pattern of blue and yellow and designed in this way though I was uncertain of specific design layout and appearance that other teams planned to develop. A member of my team had contacted other teams with questions regarding appearance and then refactored according to the newly acquired information. A small hiccup with practical application is to be expected when developing with new frameworks but I still think we worked well despite the initial chaos of using these new frameworks, especially the combination of multiple frameworks.

To improve as a team, we should become more comfortable and fluid working with these new concepts and frameworks by continually practicing them daily in small increments rather than in large infrequent bursts of use. This would help to solidify these new concepts in our minds and keep them fresh. To improve as an individual, I would benefit from checking GitLab daily rather than a few times a week. This will help me to stay more on top of how the other members of my team are progressing and coordinate with them on challenges or setbacks either of us face before they become a major setback.

Overall, our team is doing quite well despite the setbacks. I am grateful to have the opportunity to work with such excellent developers who have great communication skills, are not afraid to ask questions. We work well as a team, and my teammates have been very cordial with any questions or comments about the design process outside of class hours. As someone who grew up dependent on food pantries like this one, I am honored to be able to dedicate my time to the development of this project.

Thanks for taking the time to stop by.

• John Simolaris

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

The second sprint of the semester started a bit rough for me with my surgery, but I was able to get most (if not all) of my work done throughout the weeks we worked. I was able to help a lot with creating the cards and giving them descriptions at the start, and then the first week or so of the sprint I was very busy. After this initial period, I was able to catch up on my work and get a lot done. I was primarily in charge of getting an updated example of our front end based on an old one that was provided to us from previous years. For this, I used google forms, but in the end I had to take screen shots of all my work and upload those in case the forms document that I created got deleted or lost. This will be helpful for our team and for any students working on this project in the future. There is still a bit of work I need to do on this example to make it perfect for what we want, but this has been added as a small task for me to complete in the next sprint. Overall, our entire team did very well getting a lot done, and although I did not get the backend coding assigned to me, I was able to lend my insight and some advice and code to my teammates. This sprint was a lot different than our previous sprint primarily because it had less to do with learning how to use cards and work in a sprint and had more to do with getting real work done to further our progress on this project. I presume that the next sprint will be even more important, and we will have a lot of hard work to do to try to complete all or most of our cards. Some things that worked well this sprint were our team’s hard work ethic for getting everything done and our ability to communicate well and let each other know what needs to get done and what we need help with. For this sprint, we actually added a member because of the IAmSystem team splitting up after the first sprint. This was not a problem at all and in fact was more helpful because we were able to get even more cards completed over the couple of weeks we had to work. If I were to change anything or expect anything more from the next print, it would be that I personally will be able to get a lot more work done earlier in the sprint without having a surgery as a distraction. I am excited to see how far we can get on this project by the conclusion of this semester, and hopefully we will be able to get a nice looking and working project by the end. This whole experience has been great for me so far for learning how to work in groups for sprints, and I know that after college I will run into many projects where I have to work like this.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch 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/6

(Read over/review UpdateGuestInfo for frontend): In the comments, there is detail on how to frontend will function for a guest info update. In case of a new guest or old guest, the ID will be entered first and then the guest will be accessed if they exist.

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

(Implement components/schemas to be used in backend endpoints): Updates were made to the OpenAPI.yaml file. These included new responses, corrections to schemas, and corrections to endpoints.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/backend/-/issues/2

(Implement API for backend endpoints in Node): The title is self-explanatory here; I implemented the GET route while David implemented the PUT route, as well as updating all the example files to fit GuestInfoSystem rather than items for InventorySystem. My chages occurred in endpoints.js and guest.js

As far as our timing within the sprint, we did much better this time than last time. We made use of due dates and stuck to them, even if refactoring was necessary afterwards. Our goal was getting working backend code up and shared with the group. From here, everyone was able to be on the same page in a timely manner. We also made better use of communication within GitLab, mainly in the cards and via merge requests. This way, even if Alex, Tim, or Cam was not working on the backend, they would still be able to see the code and understand how it functioned.

            We still have some significant improvements to be made as a team, though. Even though everything was made more public through cards and merges during this sprint, getting everyone on the same page insofar as how the project as a whole was functioning seemed to be lacking at times. This definitely slows down progress as there was separation between the backend development (what I was mainly contributing to with a great, great deal of contributions from David) and EventSystem and KeyCloak development. I’m still not sure if everyone is grasping how deployment of the system is working with Docker. We still need to be communicating and collaborating more than we are currently, as well as asking more questions if everyone is not in synch. This leads to some ambiguity on division of labor as well. We tend to be working linearly (with some people waiting to work on their part) instead of in parallel. This is where communication needs to be better, as well as planning.

            As a team, we should be communicating better during our time in class. I think I had the assumption that everyone was on the same page when no questions were being asked, which I don’t think was necessarily the case. This would help the pace at which we worked for sure. There is little progress to be made without a thorough understanding of the system. Coming up on our last sprint, there is no time to waste. I would hope no one feels uncomfortable asking questions though; as Apprenticeship Patterns states, expose your ignorance. And perhaps it’s just a lack of articulation in our cards. We have been better in using our cards, but I’m sure they could still benefit from more detail.

            I think I should be better in organizing with members from other teams, especially for the frontend. I wasn’t sure how the backend would be working, so I put off frontend development in favor of the backend. I definitely feel comfortable with that now, but I also feel kind of behind on the frontend. I expect this upcoming sprint to be exactly that: a somewhat hectic sprint. We have our work cut out for us, so focus is the name of the game. Organizing with members of other teams should be greatly beneficial, especially with my beginners Vue.js status. 3 minds are greater than one!

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

During our second sprint for the InventorySystem project, we focused primarily on getting basic “skeleton” systems in-place. By this I mean that we tried to get simpler versions of each of our components working so that they could be used as a baseline for future development. The frontend, backend, database and IAM (Identity & Access Management) systems were focused on primarily throughout this period of work.

I would say that we likely had a proper amount of work planned for development, during this sprint our team was actually bigger, so it was a great help to have more people around to work on development tasks. Because of the larger team, we were able to split-off and each focus on a specific area of the project more effectively.

Two people focused on the frontend (one person worked on one of three necessary frontends each) since there was the project requires multiple front-end interfaces to function. One person focused on the IAM system specifically, and one person focused on the backend system initially. As the sprint progressed, everyone generally was able to complete the majority of necessary tasks, and the project went from having lots of documentation with little working code/examples to having a collection of basic interfaces and systems.

One difficulty I faced specifically was in trying to decide on the appearance & layout of the frontend I worked on during the sprint. Because the preexisting site for the food pantry exists only as a page on the main WSU website, I didn’t have much to go off-of for design besides the general color choices and logo design provided by the university. Something which I found helpful was to organize a meeting with the other teams working on the project, and to ask some questions regarding their process and design choices for their own front-ends. Additionally I was able to get some good advice and feedback from others on my own team based on the development of their frontend components for the project.

I think that having more team members definitely helped our team to be more productive, the process of “splitting-up” tasks worked a lot better this time around because of it. Previously the idea of each person “specializing” seemed harder to achieve, as despite the benefits of distributing the work, there were less people overall, and focusing on one thing meant that other areas would lose out on development focus. Now having a bigger team we were able to use this to our advantage and distribute work more effectively throughout the sprint.

In terms of communication, we used GitLab throughout this sprint to coordinate our efforts, and it seemed like everyone was more used to the process of creating issues and communicating concerns/ideas regarding those issues throughout development. Here: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/36 is one of the issues I worked on, and generally I tried to include things like screenshots of the work I was doing, links to the repository for any code or examples I had worked on, and descriptions included in the comments regarding the process and anything I might have concerns about. Other team members used Gitlab similarly, posting links to relevant resources which could be helpful to others, linking to their work/posting screenshots and describing any difficulties or issues they ran into. Overall I think it has been an excellent tool for organizing our work for the project, as a place to discuss problems related to it, and as a major source of reference.

Conclusively, I think that this sprint went well, and we were able to get some good progress in over the course of ~5 weeks or so. The increase in the size of our team, being used to the process of using Gitlab for coordination, and overall focus on creating “useable” mock-up and skeleton framework code seemed to allow for increased productivity during the sprint.

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