Sprint 1 is now over and overall I believe my team and I did a good job for our first sprint. I think there are lots of things we did well but there is still plenty of room for improvement. 

The first thing our team did that I thought worked well was breaking up and weighing our epics. We took the larger epics like updating the documentation or revising the directories and split them up so each problem subgroup would have one. This worked well because each team member got to work on a piece of each epic which gave a good experience to everyone. Everyone working on similar issues was also good because when one or more of us ran into a problem the others were able to help or the team members working on frontends were able to tackle a problem together since what we had to do for this sprint was very similar. Our weights for the issues were also a pretty good estimate. We were able to get the full 35 points of work done right in time for the end of the sprint. 

Something our team can do to improve for the next sprint is to spread out the work better. In this sprint, we mostly worked in a single subgroup but I think switching things up would benefit us. Since we only worked in a single subgroup only three of our group members got to work on the frontend, one person got to work on the backend, and the last member only worked on API. For our next sprint, we want to switch these roles so every team member can get experience in each area. 

I worked on the CheckOutGuestFrontend as well as reviewed and merged code from other team members. The issues I worked on are the following:

The first issue I had was to update or add the files for the documentation, licensing, linting configuration, .gitignore, and .gitattributes to match the inventoryAPI. 

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

The next issue I worked on was revising the directory structure to match the inventoryAPI again.

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

I then worked on updating the devcontainer files to match the inventoryAPI.

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

The last issue and the most difficult one I worked on was updating the pipeline/CI files.

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

A change I could make to improve as an individual is spending a little more time outside of class working on issues when I get stuck instead of waiting for the next class to ask about the problem. Some issues need more direct help to figure out but I think spending more time trying to figure out an issue instead of asking for help after a short time would be good for improving my problem-solving skills. I think another individual issue that can be improved is getting over the fear of completely breaking the code since I am unfamiliar with how certain things work. Sprint 2 seems like the work will be less trying to match the code up to already existing code so having to dedicate more time outside of class will be necessary. 

Overall I think sprint 1 was very successful but there is always room for growth. By doing the changes the team discussed I think sprint 2 will be even more successful.

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

Sprint 1 of working on the LibreFoodPantry was a nice dip in the water of how the scrum framework works. So far, I understand why this framework is very important to the software development process and the added organization it brings when it comes to producing software.

The first thing I worked on in sprint 1 is “added use-strict to the backend” (Link 1). Before working on this issue, it was important for me to understand what “use-strict” was used for. I found out that the “use strict”; line is used to define that the JavaScript code is in “strict mode.” When JavaScript code is executed in “strict mode,” it means that non-existing properties, variables, and objects will throw an error. This was very simple, and it didn’t take too much time to understand the issue and how to resolve it.

Another issue I worked on was “removing the MongoID schema in the GuestInfoBackend” (Link 2). This was also very easy; it consisted of changing the OpenApi.yaml, which included a MongoID schema. The MongoID is unused in the GuestInfoSystem; thus, it must be removed. The biggest problem was merge conflicts. One team member had made a change in the OpenApi.yaml file in the backend in one branch while I was making a change to the YAML file in another branch, and Git didn’t like this. In the future, I think it’s important for us to recognize when issues will show a merge conflict; it’s important to understand them too. I spent some time figuring it out, but then I ended up watching this video on YouTube that perfectly explained the point of merge conflicts. Anyways, I will be able to resolve this better in the future.

The third issue was to “create docker-compose.yaml for the guestinfointegration” (Link 3). I’ve never worked with Docker, so this was a big task for me. I had to attempt to understand Docker the best I could. When I try to read over documentation of another system, I tend to get very frustrated because I’m only left with questions. I think the best thing to do when it comes to this is to take it slow and grasp all the information that makes sense at the moment, then take it from there. Also, it’s best to ask a lot of questions whenever possible. I tend to try and figure things out on my own when I don’t really need to. I have all these resources and people I can go to, and I’m not capitalizing. Despite this, I learned a lot about Docker, and I will definitely come back to it whenever I need to.

The final issue I worked on before ending the Sprint was “Configure guestinfoIntegration” (Link 4). When going into this issue, I didn’t know exactly what the guestinfoIntegration was used for, but from my understanding, it is used as a mock repository showing how the GuestinfoSystem works. Configuring the file wasn’t hard; the only thing I had trouble with was understanding that the Integrations had no build image, thus no build meant that I needed to change the Git testing pipeline. It seems like I should invest more time into looking at the resources that have been presented in the LibreFoodPantry common services. I spent a lot of time getting the pipeline to work, which is good because now I have a better knowledge of how it all works. My concerns are that I take a significant amount of time on issues that can easily be resolved, so it’s my job to look at all my options before scrambling for a solution.

As an individual, I spent a considerable amount of time working on these issues and learned a lot about certain aspects of the project. I want to be able to better organize my findings and solutions in the next sprint. I also want to get a significant amount done between classes. This means setting deadlines so that I’ll have one issue done between each class.

Regarding the team, we have decided that we need to better space out our issues so that no one is doing too much and spending a lot of time on a certain issues, as this could be a problem for productivity. We have also decided that we need to capitalize on local branches before merging, which could help when it comes to merge conflicts. Heading into Sprint 2, maximizing our productivity is the goal.

Link 1: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/59

Link 2: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/60

Link 3: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/merge_requests/3

Link 4: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/2

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Sprint 1 has come to an end, and it’s time for the sprint retrospective. For the first sprint of this semester, I worked on issues for AddInventoryFrontend for the Inventory System. The following are links showing my activity for the project:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/9. This addressed the creation of developer documentation that was not previously present in AddInventoryFrontend but is present in GuestInfoFrontend, and I made sure that it had the licensing files, and added the linting files, and edited the .gitattributes file.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/10. This addressed the revision of the directory structure in which I compared files in AddInventoryFrontend to GuestInfoFrontend and created any files that GuestInfoFrontend had that AddInvenoryFrontend did not have and renamed and relocated files, or created folders to match GuestInfoFrontend.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/12. This addressed the updating of the pipeline/CI files in which I updated the package.json and .gitlab-ci.yml files.

I have also reviewed a merge request from a teammate in which I checked if they created the necessary files with content similar to GuestInfoAPI: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/merge_requests/5 

What worked well with the group is that we all separately worked on the same type of issue. If one member had difficulties with the issue, then another member who figured it out would be able to guide them. For example, we all worked on updating pipeline/CI files and there were some cases where a few people working in frontend had the same errors like issues with using commads/build.sh and were able to work it out with each other. We also had great team communication and were able to freely communicate what we were stuck on or working on, and could easily reach each other outside of class. 

We cooperated well as a group and didn’t seem to have any issues. We had just technical issues rather than teamwork or workload issues. Even then, we did help each other out and I took note of what we may need to remember moving on. When I was stuck facing some errors on an issue, a teammate helped by picking up an issue for AddInventoryFrontend that I was too preoccupied to handle.

To improve as a team, we could work more on projects at home and also try to branch out more. We sort of stuck to our own projects–for example, I handled most of the issues for AddInventoryFrontend, one person worked on InventoryAPI, one for CheckInventoryFrontend, one for CheckOutGuestFrontend, and one for InventoryBackend. It might be more fair to work on different areas for people who ended up working on an area they didn’t want to work with.

In terms of improving as an individual, I could put more time outside of class into my issues–but of course this would happen naturally since this next sprint would have more “intensive” work rather than some copy-pasting situations we had for issues this sprint. I should also be less afraid to make some changes thinking it could mess something up.

I think this first sprint went well with our communication and team support system.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

This blog post is about the sprint 1 retrospective. This is our first sprint as a third group in the Cs-448 class. The topic of the project that we will be working on, which was presented to us as a team is about LibreFood Pantry AWS Deployment. In the first moment, the professor sent an email as a beginning to present us that what group we would be in, who would be the members of our group, and most importantly what would be the project we would work on. That was our first familiarization with our team members. Working as a group for one project, I took it as a very positive thing. I really like when I share ideas with other people about a specific topic, and I also like when I take ideas from others from where I can learn too.

The first thing we as a team did, was that we first created the issues. After that, we shared the roles on what we will be working on. We had very good communication as a team and we also were really clear about the project. The issues I worked on were the Deployment Option for EKS and the other issue was research I did about the Microservices Architecture.

These were the two issues I worked on. In the first issue I had about deploying options for EKS, I tried to give some tips about deploying applications Amazon EKS in the cloud, also I tried to determine which deployment options for EKS we should be using. For my second issue, I mostly did research on what is Microservice Architecture, when, and how to use it, and most importantly the benefits that microservices have.

Working as a team on one project like this, looked like a little challenge thing for me. But at the same time, it helped me improve my acknowledgments. We as a team on this first sprint tried to share ideas, and give our contributions regarding the issues that we created. We had some struggles mabey in the first days we started working on the issues, but got the point. And I think that overall we have done a very good job as a team. We also tried to find other communication ways, like writing for any question or suggestion through discord, and also we have met each other virtually through zoom meetings. These helped us a lot as a team too. And hope that all other sprints will work better than we start.

The issues I worked on:

Deployment Option for EKS: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15

Research Microservices architecture: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

At the beginning of the sprint a general overview was collectively made by the group and some confusion over the scope of work completed so far occurred. We were expecting a majority of our work to be code refactoring but at the time it was noticed that there was no actual operating code to refactor really, and our collective effort was directed at simpler cleanup tasks.

During the first sprint I assigned myself to two tasks created by Sebastian:

1^st https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/61

2^nd https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/2

The first task was creating landing pages for to later connect to the second task which was assigning href links to those landing pages.

I specifically chose these as I have never worked with html except for one occasion earlier in my youth during high school. I felt like this was a good opportunity for learning html and getting familiar with it as it is something I should know how to work with on at least a basic level. The majority of my time was spent on learning how to code in html and dealing with what I considered to be how weird it handles spacing and formatting.

My general experience with learning html did not go as well as I hoped. As with learning anything new the tricks of the trade generally do not surface early on and instead are buried deeper in more specific tutorials.

I generally struggled with spacing and formatting and in specific aligning a couple text boxes until my fellow team member Kurt off the top of his head mentioned that you could add spacing and tabs with specific code that made the pages look slightly more organized. He also told me about CSS and I spent some time learning about that and bootstrapping to find an easier way to automate the formatting of the landing pages.

Now I could have originally finished the landing pages and connecting them to the main landing page, but I had decided that without a more complete formatting style and still uncertain as to the future of those landing pages (the way the users will be directed to these pages depends on the Keycloak and Kubernetes systems being developed by the other teams and might require a complete design change to those landing pages), I chose not to finish the landing pages during the first sprint.

The second issue relates to a far simpler task that seemed a bit more difficult at the time but as I discovered it was far simpler. At the start it seemed like I might have to create other structures in the other front ends for linking together all the landing pages. Luckily after looking over the code it seemed to me that all I would need to do to link the landing pages together would be through the one hub located in the header.vue in the addinventory front end. It is the one point that has the href linking to the other front ends and I’ll be likely directing the landing pages from this point. Ultimately again it wasn’t implemented as the formatting was not completed for the landing pages. Overall I spent far too much time kind of randomly learning html and felt like I needed to find a more organized path to learning html. I also am expecting during the next sprint to have a far more coherent style and to format it based on Worcester States’s general website formatting and color scheme, as well as actually creating the pages and linking them together to finish these two issues

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 Sprint 1, I mainly worked on the frontend of the guest info system. In our group, we split our team into two teams, one for the backend, one for the frontend. This is how we operated until the end of the sprint. We found that this way of splitting the work between the two groups worked well. I don’t think there were any issues with how this worked. I think my only criticism would be that I wouldn’t know what the backend was doing but that was mostly due to us only now starting with stand up meetings. Also, could be due to the fact that we mainly communicated between our own groups. This is a issue I think we could fix, I also need to work on my communication skills more because I sometimes find myself lost at times with what we’re doing.

Another thing that worked well was how well we adjusted to Scrum. I think our Scrum master, Vien, was a really good leader and was the leading factor as to why we did well with this framework. He helped set up everything for us and set the structure for how our team should work and what we should do. He was also very helpful and considerate with me when I would be stuck on something or one of us had an error with something, he would try to figure out what the issue was.

This sprint, I think I could’ve done a lot more, although the work for the frontend was kind of scarce and were minor fixes. For the frontend, we just needed to refactor mostly in this sprint and format it in CSS. CSS seemed the hardest and I wanted to work on it with another team member but he ended up formatting it all alone so I ended up not being able to work on it. Again, this was a communication issue from me since I didn’t tell him I wanted to work on it collaboratively. He ended up doing a great job on the CSS formatting, it almost looked like what we wanted it to look like, a Google Forms page.

As for me, I definitely could’ve done more. The amount of work I did compared to my other frontend team members is definitely lacking and you can see it in the commits. I’m also definitely the weakest coder in the group and it’s very evident. I am trying to learn more and more as I go through the sprint and being in this group encourages me to learn more and become better. In this next sprint, I’m gonna try to do more work, maybe even some of the harder issues like integration and deployment. On a more positive note, I think the group I’m in is a great group of people and is motivating me to be a better coder because this would be similar to the type of work I would be doing when I go into a software dev job.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/cff5f606ea5df652e8e501c65e4166fb26401235
Here, I merged a branch to refactor the register form template into the main branch.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/e5c2de68f4566e2af0796095c46199b32ca55c1f
A small change to change the id-input into vue.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/97c14005f3c0198c412a9f680bb7309ac442d806
Here, I moved id-input.vue from main into our refactor branch, keeping most of the code.

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

INTRODUCTION: Looking back on this sprint, I can say that our group has performed quite well. better than expected, honestly. Perhaps I have an irrational fear of “events always going haywire”, but at least this phobia keeps me well aware of the situation (“on my toes”, you might say).

Considering the activity found on our group’s gitlab project, we can see that this sprint has consisted mainly of research write-ups, alongside some minor work for the frontend, backend and API of the IAMS.

POSITIVE FACTORS: Here are some factors of the sprint that I believe went well:

• Our group had satisfactory distribution of work.
• The group was able to present a “proof of concept” demo that met specifications for the current sprint. Examples include a basic frontend/backend/API system.
• A lot of research was done during this sprint; our group was able to learn a bit about Kubernetes, VUE, Node.js and other software that is crucial for the IAMS.
• Keycloak has not been set up, but a plan has been made to get it running by the end of the second sprint.

NEGATIVE FACTORS: Here are some factors that I believe can be worked upon:

• The group seemed to struggle with suggestion a proper amount of weight for each issue. Specifically, we seemed to “underestimate” the difficulty of certain issues (such as setting up a Kubernetes distribution). In short, the group often weighted issues as easier than they actually were.
• I feel as though having “more concentrated roles” within the team would be beneficial. While we had two teams (coding and research) led by a scrum master, I feel as though we can have “individual” roles. Applying roles such as “Quality Assurance”, “Presentation Director” and “Merge Coordinator” would help make a better team.

TEAM IMRPOVEMENT SUGGESTIONS: In order for the team to improve, some suggestions that I would improvise include:

• More communication. While our group had used discord and gitlab to an impressive extent, I feel as though there can always be improvement. Additional communication can give us a better idea of our current position in the project, as well as create solutions for the next steps forward.
• Enforcing the “Scrum Structure” more properly. This is an extension of the previous criticism (“More Communication”). In addition to standup meetings, the group should be engaging in a “Daily Scrum” meeting every day, (regardless of class)

SOLO IMPROVEMENT SUGGESTIONS: Personally, I feel as though my team worked spectacularly. If anything, I believe that I was the worst one on my team (following the Apprenticeship Pattern: “Be the Worst”). In order to improve upon my own performance, I believe that I should look at the following shortcomings:

• Dedicate more time to the work. Unfortunately, while I am busy with other factors (such as work, other classes, and so on), this is not an excuse. This project is meant to be treated as though it is a paid job; the performance delivered should reflect a similar quality.
• I would also like to reach out to LibreFoodPantry staff, as well as other groups, more often. Communication and cooperation are key factors to creating this massive project; each group creates their “piece of the puzzle”, and then it will all be fit together towards the end.
• Finally, having a greater understanding of my role (such as “Coder”, “Quality Assurance”, and so on) would be crucial to future work. As of this sprint, I seemed to dabble on various topics without concentrating on anything in particular; this can lead to messy, unfinished work.

Most importantly, I would like to point out that this retrospective blog was posted late (it was meant to be done before the start of Sprint 2). This, in itself, is an error that needs to be rectified in future sprints – timeliness and containing work within the sprints is essential in order to keep the project from falling apart. It’s okay if work carries over to another sprint, but that usually needs to be planned from the get-go.

All in all, the first sprint never goes perfect. No matter how hard one tries to make it go right, something always goes wrong. The point of this lesson (and by extension, this class) is to ensure that we look back on these errors; we then perform research on them so we can modify our work habits. All of this is done to ensure that the mistakes don’t occur again in future sprints. As I look forward, I will do my best to enforce these new policies.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

To be honest, I think this first round of figuring everything out went as well as it could have. To start with what could be improved, I’d definitely have to say our team should establish much more concrete issues to deal with the specifics of what we prioritize for getting done. While we certainly got the gist of it as we were progressing, I was feeling quite lost in organizing epics and issues to be more to the point. A second thing that I specifically didn’t do well with was communication with the team. While in class we had no problems (in my opinion) and we get along quite well, but out of class I am egregiously bad at keeping up with messages. Thankfully, I don’t think it interfered too much with the work flow, but it certainly remains an important thing I have to remedy as I owe it to my teammates. In addition, I think the Scrum Master position was a little up in the air, as most of us were looking at each other for help with direction in our sprint. As a result, we all sort of pitched in where we could, and hopefully in coming sprints the role will solidify into a more acute position with specific responsibilities.

As for what went well, I think the team’s communication was much better than I was expecting. In some areas there was a bit of tension when it came to explaining a concept, or deciding what should get done first, but it was amicably resolved with no real issues. I personally enjoy working with everyone in the team, as everyone was ready to come to the table and pitch in. The only area of improvement I can really pinpoint is staying in contact with what each of us may be specifically working on at the moment. At one point me and a team member began to overlap what we were working on, which went on for a little longer than it needed to.  However, I don’t have much to say on this, as I think on the whole it went smoothly. The things that might need to improve I believe will just come with time as we continue to work on the project. 

As for myself, I think some members may not like me as much, as my participation could for sure improve, but that’s neither here nor there; I only say that to remind myself I need to be better. Another place I may need improvement in is with my explanations. I can be quite ramble-y with some assumptions about what others may believe, or already know. I don’t think in a condescending way, but only insofar that the gap in understanding of communication doesn’t help me to get my point across.  

As for some of my contributions, they are as follows:

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/8303274a7264a636ee71a2bc10ae57e4578b6806

Here is when I added a few schemas to the API repository.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9fe22f78eaa34a46c3cb32eedb7080bfe33b9bd5

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/71d797e318075cba6f1ded1bb31ceb0c4fcb7dd5

Here are a couple examples of when I added some basic files to get the API repository updated; I believe there are about 12 similar creations of basic files, but it would be repetitive to include them.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9412a5433a4e8adb9f617d0f892e5a879d1b2455

And finally, here’s an example of me updating a basic attribute file in the repository.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint were adding files to our Documentation Repository, researched Ingress & Gateway, & researched RabbitMQ.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/3

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation

The above links will take you to the issue to add the files to the repository, along with the repository with the files added to it.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11

Here is the issue to research Gateway & Ingress, what they do and how we can take advantage of them.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/5

Lastly, I researched RabbitMQ and what it does and how we could use it.

I cannot think of much to add with regards to change, maybe add a bit more detail to my research posts, but otherwise I think everything was solid.

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