INTRODUCTION: As the final Sprint of my team’s Software Development Capstone project introduces its conclusion, I feel as though it is a good time to reflect on the results of this sprint. Going further, some aspects of this blog (specifically the conclusion) will involve reflection of the project in its entirety. To start, I believe that this sprint may have been weaker than previous ones. Factors supporting this argument include the idea that we now have experience from the previous sprints and that we should be more prepared; factors against the argument include non-work related considerations (such as future semester set-up).

POSITIVE FACTORS: During the final sprint, these favorable events had occurred:

• Our team had made progress on getting Keycloak into a Docker container. Hopefully, futures semesters will be able to complete the project for us (allowing connection to the AWS Team, and other teams in general).
• Speaking of progress, our Product Owner (our Instructor/Professor) has mentioned that the team has made an impressive amount of progress in general. Factors involved with the amount of progress include comparisons to previous semesters’ work, and consideration of the fact that our team had quite literally started this project from scratch.

NEGATIVE FACTORS: As much as the team has improved, there were still some bumps in the project’s road. These bumps include:

• To contrast the statement in the “Positive Factors” section, work on the Keycloak Docker container has been completed, but we do not have a final product yet. However, in our defense: part of this sprint was spent setting up the project for the teams that will work on it in the future.
• As mentioned in the “Self-Improvement Suggestions” section below, this team has done quite well during this sprint (considering the fact that the Scrum Master was not as involved as previous sprints). I understand that Scrum Masters do not have a drastic amount of authority over the rest of the team; at the same time, too little involvement with the team’s work essentially makes them a facilitator “in name only”.

TEAM IMPROVEMENT SUGGESTIONS: Even though we have no more sprints left for the project, it is still a valuable form of criticism to discuss where the team can improve. Factors involve:

• I believe that additional dedication to Sprint Planning would be beneficial for the team. While our first two sprints involved research of our issues (in other words, we didn’t know what we needed to do), having a clear idea of the end goal will make for more efficient work. This is opposed to issues being brainstormed and abandoned like darts thrown at a board.
• In addition to Sprint Planning, having a better structure for our Sprint Review/Demo classes can help. While we get our work done, it’s also important to know how to present it in a neat, organized manner that is easy for the Product Owner to interpret.

SELF-IMPROVEMENT SUGGESTIONS: In addition to team improvement, there is always room for self-improvement. Some ideas for my own improvement are:

• Since I was the Scrum Master for this sprint, I must say that I was not as involved with the role as I would have liked to have been. In future projects, I would like to dedicate more time to the role; hopefully, outside commitments won’t weigh me down like they did during this semester.
• In future Scrum work, I would also like to be more involved with Gitlab issue board work (this factor ties into my criticism of my Scrum Master performance). I feel as though reviewing and commenting on issues isn’t enough; taking the initiative and creating issues is a key factor of being a leader on the team.

Considering the project (and its semester) as a whole, I will say that I appreciate my teammates and the work that they have done. We have all made this Capstone project a pleasure to be involved with; in fact, due to how pleasant the overall experience was, I have shown interest in working with the LibreFoodPantry software outside of the class. To be honest, there’s no reason not to be involved – working with LFP has varying levels of commitment. Regardless of the commitment level, the work is a great way of acquiring work experience and keeping Software Development skills fresh.

LINKS TO GITLAB ACTIVITY:

• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/KeycloakWithoutDocker/README.md (Images added to guides for future semesters).
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/blob/main/.gitlab-ci.yml (CommitLint Setup for commit structure)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/documentation/-/blob/main/History.md (History log, for future semesters)

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.

My third and final sprint for my software development capstone has come to an end. Here is what I did, and my thoughts on it.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/6#note_911958619

This represents my thoughts on this file after looking it over. There’s probably still room for improvement but I didn’t think it was the best use of our time.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/81ce29d85af035a51e668fe6c4c80267c0d72d08

Changed the API to swap out json for plain text, since we want to return a .csv file.

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

Removed this because the previous commit made it unnecessary.

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

Some minor restructuring of the API.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/7c1489a9f4ed45e58e7a6949231f1c40488c7095

Fixed a typo in the filename of the .yaml file mentioned above.

I think everyone had a pretty good work ethic. While individually we may have struggled, we collectively knew what we were doing.

As far as things that didn’t go well, I think we’re still struggling with assigning correct weight point values and issue granularity. Most things I did felt either too easy or too hard for their given point values, mainly the former.

The issues we made mostly felt to me like they were too specific. Sometimes this meant they were too easy, but not necessarily. I think it caused unnecessary confusion, since what should be one task might get split up into three, done by three different people. There’d then be no way for any of them individually to check their work.

There’s the possibility of coordinating the issues so that it’s clear they’re dependent on each other, but I think it would be simpler to just have them all be the same thing. I wouldn’t coordinate issues in this way unless they were clearly separate tasks, but still related.

One thing I think we could have done as a team is coordinate more. I think communication was our biggest weakness. I always felt like no matter what I was doing, I was always kind of going off on my own. At the start of the semester, we agreed to take turns being the scrum master, but as it went on we focused less and less on procedural concerns. I think we could have benefited a lot if someone had stepped up to be the team leader.

As far as things I could have done to improve, I could research more. My biggest roadblock was not really understanding how all the moving parts fit together. I think I overestimated my skills a lot. Also, in the context of a college class, there’s a strong incentive to just do the bare minimum to pass, with any independent study taking away from other classes and out of school activities. I did manage to get a little bit of independent study about the tools we were using in, but not nearly as much as I’d have liked.

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.

With this being our last Sprint for the semester, it couldn’t have ended on a better note. Cooperation between the team members and communication continued to be effective. Everyone seemed stepped up and the work ethic was beyond that I could imagine. Comparing to other team/group projects I have been on in the past.

During this sprint, I worked on creating a key for the endpoint authentication. We were still waiting on the actual key from the IAM team so in the meantime, I created a code that will give authorized individuals in the LibreFoodPantry access to their sites. Such has if a guest has access to the LibreFoodPantry portal, once they put in their login credentials, they will either be authorized or unauthorized. This was by request of the client.

Some of the issues that we faced was the getRange API calls. This method required additional coding to the NestTester, API and the backend. Once that was completed, we were able to move on from this project.

I think over the past two sprints, our usage and knowledge of GitLab Epics and Issues board just continued to improve. One issue we faced in the beginning was apply the proper weight to each ticket. As the sprints continued, our distribution of the weight continued to get better. We ended having a better workflow and a more balanced and shared workload.

With a good portion of our task completed, we mostly spent this sprint communication with the IAM team to get a better understanding of when they need to integrate security mechanisms into our remote function calls. We concluded that this will not be complete this semester and will have to be pushed to next years Capstone class.

We were giving the option to continue to work on this the rest of the summer to better improve the progress that we have. This is not a bad option since technically this is for a real work client that is expecting some type of prototype. Joe has decided to stay on and continue to work on this while myself, I have opted not to. With this being my last year, I have other opportunities that I will be pursuing to better myself in this field.

As the conclusion to this spring, the group decided that each member will record a portion of the project and prepare a video presentation. I’m overseeing the consolidation all the recordings and preparing a video presentation for Dr. Wurst. We broke down what needs to be discussed and each member will pick what they would like to talk about. I will take what’s left over to check off all the topics that we would like to discuss/present.

The capstone was a good experience and helped be become a better team member. Being able to see each member grow from the first sprint till now is always something that I am proud of because I know they each learned and took something away from this class. Not all was smooth, and we definitely had some bumps along the way but in a real world scenario, that is what happens and you have to learn how to adjust and get over those bumps. Theirs always a solution to any problem, isn’t that was coding is, solving problems.

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Oddly enough, I found this sprint to be a tad more challenging than both the first and second. I’d say this is primarily because we were nearing the end of our project, and the team had some difficulty accurately choosing and weighting our epics and issues. I’m unsure if the rest of the team would agree with this sentiment, but it’s certainly something I felt at the beginning of the sprint. We all eventually found worthwhile contributions to work through, but the lack of cohesion or agreement at the beginning was a little jarring. 

Despite this, I’d say the team got some of the harder pieces of work done near the end of the sprint. I certainly remember the getRange file for the API being a huge hurdle to get functioning, but with Jeff and Kenny working together they made it work in the end. Personally, I felt a little stuck after implementing a few new schemas in the API, as I had elected to work on the key validation from the other groups’ projects. I thought I’d give it a shot, as encryption has always been pretty fascinating to me with all the different types of encoding techniques that exist. However, I soon found I was quite far out of my depth; I ended up staring at StackOverload and random forums trying to get the verification working for a lot of class time. There were a few times I thought I had cracked it, but unfortunately it broke the code every time I pushed it into our repository.

In the future and during my career, it’s pretty crucial I learn to reach out or actually post something on one of these forums for help. I’m sure during the process of an actual situation my seniors will be vastly more knowledgeable than me on basically everything, so this is a skill that should hopefully develop naturally. Of course it’s important not to be an incessant pest, but with my genuine willingness to improve I’m sure I’ll be fine.  

Overall, I was still really satisfied with the team this sprint. I think we all found our roles and niches in the project to work on, and were more than willing to answer questions and help out whenever it was needed. I found the capstone to be a great introduction to my future career opportunities, and the familiarity I garnered over the semester should boost my competency level pretty far beyond what it would have been otherwise. I also look forward to working on a team with a dedicated scrum leader who I can look to for some direction if I feel lost.

One thing that I do think the team could have communicated better on was our presentation. I know it’s pretty separate from the actual work we were doing, but for a good amount of time I had no idea what I was supposed to be covering in the video. I defaulted to whatever the team didn’t initially choose, as I wanted them to be more interested in what they were presenting. Unfortunately, it was difficult to glean my responsibilities as some members were quick to post what they preferred, while others didn’t accurately mention their coverage. In the end I just went over the API, and I hope I didn’t overlap all too much with the others’ videos. Regardless, that’s a minor gripe, and I don’t blame anyone because it’s the end of the semester. 

As for some contributions, I added these pretty minor things to the API over the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/blob/main/src/schemas/GREkeyValidation.yaml

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/blob/main/src/paths/invalidKey.yaml

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/blob/main/src/paths/validKey.yaml

I also helped out a bit on the getRange before I started working on the backend key validation. It starts on line 56 of this link. 

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/blob/main/src/data/questionaire.js

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 last sprint did not go as smooth as the previous, we encountered a bunch of roadblocks with the backend that sort of disturbed the plans and dynamic established previously. We were able to get to a decent and somewhat better end product then what we started off with but we didn’t quite reach some of our main goals.

What didn’t work well

As a team:

The biggest issue was the backend not running. We started the spring with all the endpoints written down but we had an issue with connecting it to the database and getting it to work. About half the issues of the sprint were solely related to the backend and now that we could run or test anything, a lot of us were left with not much to do, or not knowing what to do. Consequently it led to a lot of not really productive time.

Individually:

Going into the sprint, my task was supposed to be testing and fixing the two endpoints that I wrote and that didn’t end up happening because of the backend not running. Since there was already two other members actively working on the backend, I found myself not working on anything for like half the sprint. At point, I would join in with the backend work but it turned out to be us three doing the same test so I decided to look inside the folder to see if there was something else I could do.

I also think that this sprint being toward the end of the semester, I ended up focusing my energy on another project since I couldn’t find anything to do.

What worked well

As a team:

We were able to fully refactor the front-ends for the most part, we updated all repositories with all the necessary add-ons (commitlint, RabbitMQ tutorials,…). The backend was created and is running. It’s not working yet and consequently the endpoints are not tested yet. In general, we accomplished over 80% of what the goal was for the semester so it was indeed a success.

Individually:

The one good outcome was that I learned a little bit about automation testing. There was a Testing folder inside the microservices example with classes like axios.js, chai.js api.js and so on. It was a bit confusing but I discovered a bunch of links (blogs and videos) that helped a bit. I pushed a document with all the links in the documentation folder for the other teams to refer to it.

Changes to be Made

Most changes that need to be made are for the next team. They can work on the following:

• get the backend to run, it is very close to being ready as it is working already;
• Take a brief moment to modify the user interfaces for check inventory and add inventory to prevent user error;
• Test and fix all endpoints;
• Develop the front-end calls based off what was set up in the backend and connect it to the web pages for testing the frontend containers with the backend

Links:

Add document with Information on testing folder(backend) (#39) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryBackend · GitLab

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

During Sprint three we ran into issues that bottle necked our project. But in the end we were able to overcome these obstacles and make some good progress.

What did not go as well was the planning of our issues, and not knowing how long each issue would take. One of our issues was connecting our API to our backend, and building our server. This issue ended up taking three people from our group more than two weeks. And we were unable to meanigfully test any HTTP calls until our backend was running properly. Looking back, we should have starting working on this during sprint 2.

What did go really well this sprint was working together to get the app running. We spent one class, all working together. Working through docker errors and making progresss that way. Chirstian made progress on his own as well. He made a docker file and reused the shell scripts from last semester to get the server running. The issue we ran into was that even with the server running, we could not execute any http call, without getting a connection error. This was the status of the issue for about two weeks.

I tried to work through the connections errors using stack overflow and other online resources, but to no avail. I then asked Jared, and sent him a screen shot and he said they ran into a similar issue in his group. Then, Duwal, Jared, and I jumped on a discord call and together we got the server running, so that we could call our http methods wihout connection errors. This was a huge break through for the team.

Another issue we ran into as a team was meeting to make our video presentation. We had a hard time picking a time in which everyone was free. Because classes had ended, and group members had finals and other engagements. The solution we came to was that everyone filmed their part and sent the video to Christian, who is going to edit it together and submit.

One thing I can do to improve as an individual is learning to ask for help, outside of the normal avenues. Once I asked Jared for help, he knew where to get started on our problem. So I learned that sometimes I need to ask an outside opinion for help. There is a limit to how much I can figure out by debugging and googling on my own. And sometimes an outside perspective, or somebody that has encountered this problem before can make all of the difference.

Below are the issues I worked on this sprint:

I added access token capability to the API repo. I added a schema for a 403 response. And I added that response to every path in the API repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/12

I researched endpoint testing standards and created a template js file in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/29

I debgugged tbe connection / server problems in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40

I helped Duwal with the test file for returning the API version. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/25

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

During this sprint my previous work in getting the front ends linked to each other for testing would finally be quickly integrated for the two front ends addInventory and checkInventory.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/6

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

While figuring out how to properly implement it into checkoutGuest front end, it was found to be not properly set up like the other projects and would require setting it up to be the same as the other front ends in terms of their vue formatting.

I was spending the majority of my time learning more about vue and how to set it up within an already created project and managing the new changes when I decided to take a peek at the previous branches as the way this project was currently setup didn’t match the others and I considered the possibility of something in development perhaps being left behind.

I found a branch called updatedFunctionality, and in it was a project formatting exactly like the other front ends and I knew then and there that we needed to integrate it within our current branch. My professor recommended that before we merge it into the main one to do a merge into a test branch to simulate what it would be like between the two and see what conflicting merges we would have to deal with. He also preferred that we didn’t just erase the main branch’s development as to not leave out the work created by previous students.

I successfully merged the two branches and got approval to merge the main and this branch and deal with the conflicting merges of which there was not too much. With some help from my fellow group member Fadi Akram the branch would be merged and my I would implement the changes needed to connect this front ends to the others like I did at the start of the sprint.

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

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

Afterwards I would spend my time testing and working on the user interaction portion of checkoutGuest as it involves a point in which the user of this station will be scanning or manually entering in student ID’s to record items being taken out of Thea’s Pantry. Working on previously established work from Professor Wurst, I modified the user interface to accept ID from both keypresses, scanning, and manually entry by keypress in the same format as it being scanned. I also made sure to prevent future issues by preventing negative values being submitted and locking the text box for user ID when a proper value is entered to prevent further changes if there was a mistake made. I also added a clear button should the user desire to make a change as they have entered the ID, should it not match the one they have typed.

There is still some modifications that should be made to the interface like allowing during manual entry to delete the desired values and modifying the value of the idnum variable to match. It would be just checking for the backspace or delete keypress and modifying the value, but it would require testing and I can’t say I am certain if that would work perfectly just from that idea.

Overall this was a far more productive sprint for myself than the previous ones. The efforts made in the previous ones helped me to succeed in this sprint thanks to understanding vue and html better.

During this sprint my team was primarily focused on fixing the backend and had I finished my work sooner I would have been working with them as well trying to debug it. My team did come together well to focus on that issue but our ability to work on testing the backend was limited by it not being able to startup and work.

I did struggle with some of the JavaScript coding while refactoring it a bit and that is definitely one avenue I need to take to improve on my own skills. It’s fairly similar to other languages I have used but some of the syntax did in a sense fight back against me, like how JavaScript handles operands with their weird truthy and falsey system. While creating conditional checks some would still pass through as it was still considered “truthy”.

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.