During this past sprint session my team and I worked on the LibreFood Pantry Identity and Access Management System. Our goals in this sprint were getting a KeyCloak implementation going and building a small API to work with keycloak and LibreFood Pantry. The first issue I created was designing our API (what endpoints should it have and what basic structure should it have). This issue had a weight of one and I was able to complete it between class on Wednesday and the following class on Monday. This involved creating the LibreAPI/src folder and using NPM to initialize the folder with a package.json file and manually add the folders. The next issue I created was to begin creating the API and writing code. This step involved watching a lot of videos and reading tutorials on how to implement a simple API. The API has two basic functions: Post a string and get an array of all the strings. Two YAML files were created in order to service the endpoints using OpenAPI implementation. I also created an issue on linking KeyCloak with our API and put in in the backlog until there was more research available and I would be able to have the other team mates catch me up on their KeyCloak information. 

Our team divided into two sections: I would work on the API, Mike would start with frontend and backend files then join me in API development, George (our scrum master) handled creating all the legal documents and licensing/documentation, Andrew and Gracia did research on KeyCloak set up and implementation. The research documents were very helpful when it came to better understanding KeyCloak’s structure, function, and how we could link it using a JavaScript adapter. Overall, the division of team labor felt fair when allocating individual team tasks. Having two students focus on development (Mike and I) and the rest of the team handle KeyCloak kickstart (George, Andrew and Gracia). KeyCloak is a very large system and there was a lot of research that needed to be done before we could begin a simple implementation. 

As an Individual I want to improve the way I communicate with my team and try to keep my focus narrowed in. During group meetings, I would find myself asking questions to the research team about KeyCloak that are very off topic from the current discussion. In reflection, I think this may sometimes throw off the group discussion and put my teammates “on the spot” to mentally shift gears to what I’m asking to try and best answer my question. I think this throws off the workflow and next sprint I plan on writing down questions that come to mind as I am working and near the start of the meeting (possibly during my stand up) and chip away at questions during that time, or bring questions up when they are relevant. 

As a team I believe we worked very well together. We all have a true interest in this project and put in a lot of time outside of class to get things done. For this next sprint, we plan on all focusing on getting keycloak up and running and will revisit the code we worked on once we get past our current roadblock which is getting one instance of keycloak to work and use that as the basis for our project. One way we can improve as a team is to communicate more outside of class via discord channels and also communicate with other teams.  We are in the same classroom as other teams working on LibreFood Pantry and our project needs to be linked together with everyone else’s work by the end of the semester. This means we need to take more time to talk with other teams during class or via discord voice channels. 

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

The outcome of the sprint was excellent. We wanted to get a working frontend and a working backend, and we had to familiarize ourselves with the code from last semester. The state of the project did not have a fully functioning frontend, and the backend was not working at all. The goal of this sprint was to clean up the existing code and make the current features work as they should. The nature of this sprint was to set up the GuestInfoSystem front end and back end, and we did well on that. We added several features, but a majority of it was refactoring existing code.

One of the workflows we struggled with was managing branches while we programmed. Because there were three people on the front end and three people on the backend, multiple people worked on the same area of code. The workflow that emerged, especially on the backend, was creating many branches from other branches. The effect of this was that we had a diverging codebase that was difficult to merge and maintain coherence. For example, a branch created from the main branch was to add JSDoc. Then we needed to update an API path, and a branch was created from JSDoc. An individual continued to work on the JSDoc branch while someone else worked on a new branch from this one. Creating a new branches from an existing branchx continued a few times, and updates to the code were scattered. New code was mixed with old code in each different branch.

To not have this issue reoccur, we will be changing our workflow for managing branches. What we will do for the next sprint is make a single branch for each issue and merge it into the main branch following it has been reviewed. If a significant feature needs adding, we will create a branch for this, and multiple people can work on it at once. If there are multiple active branches, we will ensure that one branch does not modify the area of code in another branch. By working on small features and performing common merging, we will make sure code is not lost and each member is working on the most up-to-date code at all times. It was difficult to do this during our initial sprint due to the amount of code that needed to be rewritten to get the backend working. In the next sprint, we will follow this improved workflow.

A change that I will make in the next sprint is to improve the issue creation process. The issues that I made for this sprint were overly broad, and the weight did not fully capture the issue’s headline. For example, ‘Add JSDoc’ has a weight of three, but it sounds like something that could be done in one class period. This issue actually required defining the type for each variable used in the backend, defining function input and output types, and creating object types for each object in the backend. This process involves studying the code, assessing the proper type for each instance, typing each file, and ensuring the types selected do not throw errors between files. What I could have done to improve my issues by creating smaller issues for each of these steps. Each one of these issues could have been done in the same JSDoc branch, but each small issue clearly defines what is being worked on. Following the closure of JSDoc related issues, the branch could be merged into main.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Today I’m taking a break from writing about software apprenticeship to post a quick overview of my progress in the first of three sprints I’m doing as part of a scrum team working on the Thea’s Pantry reporting system. This is my first time on a scrum team as well as my first time working with most of the tech stack involved here, so if it seems sort of unfocused, that’s why.

Here are the links to the commits I wrote during the last sprint:

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

Here I fixed a typo. I also made the repo and wrote a very bare bones readme file that this commit was addressing.

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

Here I copied some boilerplate from an example project.

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

Here I added scripts that make it easier to use docker-compose.

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

I copied some things from an example readme to the frontend readme.

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

I went back and changed the title of that readme to actually be relevant to the project.

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

I deleted a random file that I think someone was using for testing purposes.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/251b4a5088f3998de0bda28ef4f83c68ca69e9bd

This commit contains the bulk of the actual work I did. That being said, I didn’t really know what I was doing, and mostly just thoughtlessly copied stuff over for the sake of getting something out there. I noticed there were dependencies at the top of the file, and that they needed to be either removed from the file or added to the project in order for the code to actually work, although for the sake of time and for the sake of keeping the history clear I decided to just leave them in as they were. After the retrospective meeting, I think there’s really no good reason to keep the validator around when NPM serves the same purpose, although we might still put the logger to use.

So, the problem that has been burning in my mind the most was that I just kind of threw things together, being so unfamiliar with the system that I really didn’t even test to see whether my code worked. A big part of that is that we don’t really have anything functioning yet, but it’s also because in the specific area I was working on (the backend) I actually was a little rusty on how. I am from a background where I’m used to just having an executable file with a call stack that I can look at at any time, and the way this project is spread across multiple machines is something I find somewhat confusing.

We also didn’t take creating issues as seriously as we should have, in my opinion. We kind of threw it all on a few people. We should probably have discussed them for more than just the one class session, and the discussion should have been put in writing on GitLab so that there would be evidence of everyone having participated (a lesson I learned the hard way).

I think many issues were too granular. Many of the above commits were two-weight issues, which our department is using to mean that the task should take about one week. I did most of them back to back in one session, except for the last one, which took another session (in other words, it all added up to one single two-weight issue).

I feel like as a team we’re pretty good at putting the effort in, which is in my opinion the hardest part of anything. I think our biggest struggle is in communication, and I think that’s due in part to unfamiliarity with the project. Something we could try as a team is to pick five areas to research and assign one to each person. Something I could do personally is see if I can get the whole system running so that I can test it out and know what everything is for and what everything is supposed to do.

One final thing I’m going to do is proofread everything I write in this project, because a pretty significant number of commits up there are just fixing typos. I actually noticed another one as I was writing this post, which I’ll probably fix as soon as I post this. I don’t really understand why I made all these errors, since it’s not something I usually do. I suspect it may be because I was panicking when I did most of the work here. That’s definitely something to avoid in the future, since I feel it’s not conducive to programming.

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.

For the first sprint, our team, team 1, have focused on working with 4 projects which are ReportingDocumentation, ReportingBackend, GenerateWCFBReportFrontend, and ReportingAPI. ReportingAPI and ReportingDocumentation are the two new projects created in this sprint. For ReportingDocumentation, we based on the description of the epic called “Create Documentation repository” to add all the necessary files and write the README.md to describe about the ReportingSytem in detail. In README.md, we depicted the role of each project created in the ReportingSytem; we also added the user story, the architecture, and technology sections related to Reporting system from Theas Pantry’s Documentation. ReportingDocumentation is completed as we expected in the first sprint, but we will update more information about each project in the Reporting System if any changes are made in the next sprint.

For the ReportingAPI, we separated the given API from the ReportingBackend into its own repository just like the example API that we have learned from last semester. Based on the example API, we added all the required files to the ReportingAPI. The src folder which includes the paths, responses, schemas, and index.yaml is the only folder that we have edited to create API for the ReportingSystem. This is a simple API, so we finished the ReportingAPI repository in the first sprint without any issues.

The API is similar to the blueprint for ReportingSystem which tells us what should be done in the backend. Based on the API, we know that Get /WCFB/report is the only request that needs to be implemented in the backend. However, the backend of ReportingSystem was made by another group with no instructions for running it. We tried many ways to test the backend and found some bugs in docker-compos.yaml that caused the images and containers to be built incorrectly. Although we fixed those, the backend was not working as expected. We also tried to refactor some of the .js files in the backend to make them look more understandable with the new style. However, since we still have not found a way to check if the old code is working correctly, we got confused when we refactored the backend. So, I think those missions should be redone in the next sprint. For this sprint, our team has not finished the backend yet, we just tried to test the old code of the backend, but we failed many times. So, the backend will be the only project we will focus to work on in the next sprint.

For the frontend, GenerateWCFBReportFrontend, we also based on the example frontend that we have learned from previous semester to create a similar frontend. We added all necessary files like the example; and the src folder is the only folder that we have edited to create the frontend for ReportingSystem. The frontend is still in progress as it is waiting for the backend to be completed. When we finish the backend, we will attach the http request to the method section in the getReport.vue to complete the frontend.

In summary, for the first sprint, we worked with the 4 projects in the ReportingSystem which are ReportingDocumentation, ReportingBackend, GenerateWCFBReportFrontend, and ReportingAPI. We have completed the ReportingAPI and ReportingDocumentation, but we will keep track on and update these two projects if there are any changes in other subsequent sprints. The ReportingBackend and GenerateWCFBReportFrontend are still in progress, but they are planned to be finished in the next sprint.

For the teamwork, I think we worked well as a team but the only change that I would suggest for the next sprint is that we should focus on solving the issues established in the sprint backlog before focusing on anything else. Our team focused too much on working with the backend, which consumed a lot of time with no results, and forgot what should have been done in this sprint. Although we completed all issues in the sprint backlog of the first sprint in time, the work was not evenly distributed among the team members. So, I think that is the point we need to notice to improve for the next sprint. On the other hand, as a member of group 1, I think I should communicate more with the whole team to figure out how to work as a team more effectively.

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

For the first sprint of the semester, I individually didn’t get as much done as I hoped to. I did help others, and collectively as a team we got a good amount done,  but I hoped to get more done individually. For this first sprint, I spent a lot of time looking through the project and the different repositories to find out about each component, how it worked, and how it interacted with the other components. Due to this, I feel that I learned a lot about how the project currently works, how it’s supposed to work, and what systems currently function or do not function. However, this also means that I didn’t have a lot of completed tasks.

The only issue that I had assigned myself on GitLab was the one to rename the subprocess files in the Reporting Backend. We felt that the names ‘send.js’ and ‘receive.js’ weren’t very descriptive, and in order for them to properly reflect what they were for, they would need to be renamed to something more descriptive. This sent me down a rabbit hole of looking through the project files to see everywhere the files were referenced so that nothing would be broken by renaming them, and also to be able to update the names in any documentation in which they were referenced. This led me to discovering that many things in the project were pulled from an old version of the backend, and that many things would have to be redone in order for it to pull new changes and build the image from the new repository. Additionally, I noticed that there were two sets of send and receive files, one in the subprocess folder of the backend, and one in the RabbitMQ folder. This had me very confused, as I at first didn’t know what the send file was for because our module wouldn’t need to send any information through the queue system, but then I discovered that it was simply to insert dummy test data into the queue for it to be received by the backend. I still don’t fully understand why there are two sets of these files, but I now understand what they’re for and will be able to modify and use them.

What worked well within our team was everyone being individually proficient, as well as being proficient in certain areas that others were not. Everyone on the team had their own strengths and weaknesses, and we were able to coordinate so that people’s strengths complimented each other, working towards a more cohesive whole. For example, I am more knowledgeable about the backend systems more so than the frontend systems, so I know more about how the docker containers work and some JavaScript, whereas others know more about Vue and the design of the frontend and are much more proficient than me in JavaScript.

What didn’t  work very well was our team communication. We communicated mostly only in class, and only minimally out of class such as on Discord. Given that we were all individually proficient, we had less of a problem completing tasks individually, meaning we had less of a reason to communicate what we were doing and what progress was being made. I think that sharing more information with other team members periodically, such as what progress has been made, what you’re working on, and what still needs to be done, outside of the scheduled times, could have been very productive and helpful for the team.

To improve upon this, we could have scheduled times for meetings outside of class via Discord, where we could discuss the details of what each of us is currently doing and ask others if they need help or if we need help. This way, we could more immediately resolve an issue that someone is facing, rather than having to wait until the next class to discuss the issue with the other team members. Additionally, the extra time spent as a team could help us to figure out each other’s strengths and weaknesses, and to discuss how we could work better as a team.

Individually, I could have improved upon a few things. First, I should have focused more on completing certain tasks, rather than exploring the project independently of any tasks. I could have learned everything I did about the project while completing tasks, rather than without completing tasks. Second, I could have better shared what I learned about the project with other team members.

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

The first sprint for the Libre Food Pantry software went very well for the most part. Since it was a spike sprint, it was mostly looking up tutorials, making sample projects, and brainstorming ideas.

What worked well for me was that I found a great tutorial on Node.js with Express which also shows you how to connect to and use a MongoDB database. This tutorial gave me a great foundation on how to run a server and handling HTTP requests. The tutorial had great explanations of why we are doing each thing step by step while other tutorials lack such explanations and just show you how to do whatever you are trying to do. From this tutorial I made a To-do list web application using Express, MongoDB, Ajax (Ajax code was provided from a source), Mongoose, and EJS(Embedded JavaScript) as practice for the Libre Food Pantry backend and also to make my skill/understanding more solid by practicing everything I learned from the tutorial. This also gave me a reference to look back on if I ever forget how to do a certain thing.

What did not go so well was my understanding of the project as a whole/how it all fits together. Studying the architecture of the project a few times did not do it for me. It took a while but learning Express, eventually asking my teammates about the technologies they are working with, how they fit in with the rest of the project and studying the architecture again after each new piece of knowledge finally helped it all click.

Some things my team and I could improve on would be to be more interactive on GitLab. By the time we made a repository to upload all of our progress, it was more than half way through the sprint. This meant that we could not review what our teammates were doing and have an understanding of our progress as a team. Also, our communication and teamwork could have improved as well. Instead of working on individual sample projects, we all should have worked together on a single sample project using everything that we learned. This would have been a better learning experience for us since that is what we will be doing eventually for the main project. We also could have had better communication with the product owner. I felt at times that not just me but my whole team was confused or stuck with what was wanted/expected from us. Towards the end of the sprint we eventually asked the product owner some important questions that really helped us move forward for the next sprint. Since we were mostly learning the foundation for new technologies this sprint it did not necessarily effect our productivity, but our motivation and confidence.

A change that I could make as an individual is to improve on communication. I felt that I did not have a good understanding of the technologies that my teammates were researching and how they intertwined with what I was working on. For example I did not understand what RabbitMQ was and what it had to do with the project when all I had to do was ask my teammate researching it to explain. Eventually towards the end of the sprint I did this and it helped my understanding of the project greatly.

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/NodeJSTutorial/NodeJSPractice – Repository where I uploaded files from each tutorial video.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/TodoListApp – Repository holding files for the to-do list web application

https://www.youtube.com/playlist?list=PL4cUxeGkcC9gcy9lrvMJ75z9maRw4byYp – The tutorial I used for my sample to-do list app.

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.

Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I created a sample frontend using vue.js and learned how to build up the environment and set up a sample project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I learned how to create a climate for vue.js on Udemy and Youtube to set up my vue.js settings. I used my tutorials to build my first sample project.

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

I am working with Migena for the Small Frontend, which is going to test the login feature with keycloak. We will use vue.js to build the Frontend and the third-party system, keycloak to test it. We will see how a real example of securing our system with keycloak. Our goal is to build a simple frontend to test keycloak.

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

I will keep meeting with the other teams working on the Frontend to discuss the Frontend’s style, format, and other components.

Reflection on what worked well?

The reflection on what worked well is that we work together with the team members we have worked with before to complete the project plan. Because we have worked together in the same group before, we have a deeper understanding of our teammates and are more accustomed to each other’s habits. There will be a relaxed and happy working atmosphere in the group, and the chemistry between the groups will encourage each other and push the project forward.

Reflection on what didn’t work well?

The reflection on what did not work well is that we didn’t know much about the project initially and thought it was a big project. When faced with the unknown challenge, we were a little confused at first. As we got to know each other and started to move forward with the project, we found that labor division was not reasonable. Because in many issues, Frontend and backend are related. Being responsible for each task affects productivity. So we have overlapping project leaders working together to complete the job, which leads to increased efficiency. It was difficult or challenging to push the task forward, but we encouraged each other through the ZOOM meeting 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/new-sample-project

This is our example repository that contains everything we worked on for Sprint 1.

Review Docker: Reviewed old projects and main commands for docker.

Create Sample Docker projects: Created a sample Docker Project, Did the getting started activities.

Repository for event project: The main repository for the event project.

Learn About RabbitMQ : Learned RabbitMQ components and Implemented them using Docker.

Review Scrum :  Reviewed the scrum guide and understand the process.

For the project, I am part of the reporting team. I mainly work on the event system software that sends and receives a message to other systems using the RabbitMQ messaging system interface. I also work with the database person and did make a docker example project and a cheat sheet of all the docker commands.

What worked well / did not work well

 The thing that worked well for our group is that we were good at organizing everything and everyone was responsible for certain tasks, and I noticed that some of the tasks overlap between us. For example, the backend person must work more closely with the database person. The first few days we were a little confused, but as everything came together our workflow improved tremendously, which helped to complete all the issues for sprint 1. One thing that did not work well is that we had few problems with GitLab, our template was not loading properly at the start so we could not assign proper labels to issues. Also, during meetings, we should have done the group tasks together instead of a person just doing the task.

What changes could be made to improve as a team?

For a project, communication is the key to success. I think that as a team we should be communicating more rather than doing our tasks during the meetings. For instance, if someone is struggling to figure something out, the other team members can help the person and give insights to lead the individual in the right direction. Also, for the next sprint when we are making cards we should be more specific about the descriptions and properly think about the issue and how we can achieve it and it is clear to the person what needs to be done.  

 What changes could be made to improve as an Individual.

As an Individual, the change that I can make is to plan properly for the next sprint. The first sprint I started of slow because I was not sure how you do something or if I am doing it the right way. A properly planned sprint will help me to go with a flow and have a balance rather than getting overwhelmed by doing all the tasks towards the end of the sprint. My communication with the team should get better as we move on to the next phase.

Overall, this was a great learning experience. I think the first sprint was a success and a starting point for our team to move forward with a vision to complete the task that is assigned for us. I’m looking forward to working with the other teams to combine everything and see our progress.

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