What is Thea’s Pantry?

Thea’s Pantry is a food bank for Worcester State University community. It helps students, staff, and faculty who require food and other necessities. This service runs out of the Student Center on campus, offers a confidential service to people in need. There are a lot of positive things about Thea’s Pantry. The Thea’s Pantry client solution is described in full in the Documentation project, which includes User Stories, Architecture, Technology, Workflow, Release Process. Since I came from a retail background, architecture is a very interesting component for me because it helps layout the foundation of the business in general. For example, in this project, the architecture gives info about GuestInfoSystem, InventorySystem, ReportingSystem, IAMSystem (Third-party), EventSystem (Third-party). The Architecture allows the users to interact with the frontend and backend, where the guests will be able to interact with the frontend.

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

I wanted to reread and write more about the architecture of Theas Pantry because it gave a detailed layout of multiple components, some of which are projects being worked on by some teams in the class. The main components shown are the standalone integration tests for GuestInfoSystem, InventorySystem, and ReportingSystem, and then a full integration test for Thea’s Pantry. I liked how it was divided into the standalone tests for the different components that will be worked on and used as a reference for the developers, and it is helpful to also show how they all come together in Thea’s Pantry with the added components such as IAMSystem and DirectorySystem for the full integration.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

I took a look at the user stories documentation to familiarize myself with the process of how everything works. The user stories are organized in a way that I can understand the step by step flow of the processes. I believe that this document will be pretty useful to refer to when working on the project. That being said, I noticed the pantry log entry form has been modified with all of the donation options crossed off. It would make sense to have separate forms for guests and donors. One thing I am curious about though is how they transfer the information from the google forms to the database, I will probably have to look into it some more.
Link: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/blob/main/UserStories.md

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Another aspect of preparation for my Software Development Capstone project is to become familiar with Thea’s Pantry. Thea’s Pantry is a section of LibreFoodPantry that is being worked on by the staff and students of Worcester State University.

One important takeaway from this pantry’s data is that most, if not all, of the pantry’s technology is familiar to me; from OpenAPI and VUE to MongoDB and Docker, these technological tools have all been used by me in a previous class at Worcester State. I chose to write this down due to the fact that I find it nice that the flow of knowledge seems to be “continuous” as opposed to “discrete”. By this, I mean that aspects of one class are used in others, instead of being dropped entirely once the semester ends.

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.

I found the architecture used in Thea’s Pantry interesting. It was nice to see the UML diagrams as they help tremendously with understanding how the architecture works. It is also nice seeing the individual pieces of the system, and then seeing them all together at the end, seeing the entire system come together. I also found the workflow interesting as well, having a new branch for every feature/fix/refractor, each being associated with a merge request when the branch is created. Then, using conventional commits, and commit merging. It is good to see this level of organization in the workflow process.

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

One of the things that I found surprising while going through the Thea’s pantry project was in the UserStories.md file, it includes a .PDF file of the form that the staff would fill out for each visit. What surprised was not that the form was already made or that it was included in the Markdown file but rather it had a copy of the form with strikethroughs. I found this both surprising and interesting because the form looks mostly finished so I would normally assume the version of the form on GitLab would be a polished version without any markups or strikethroughs. I chose to write about this because it made me wonder if there was more that needed to be added or fixed on the form. But seeing the strikethrough also helps me see their thought process as to which they removed or moved certain things in the document.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

After looking through the different documentations, the most interesting thing to me was the User Stories. In Software Development, I can easily imagine there are situations where we are working with a large number of files or “processes” so to speak.  The User Stories illustrate textually the different processes that should occur, in what order they should process, and what is required. This in a sense is a sort of localized version of a software flow chart, but with text instead of graphs. This would be very useful to me or to whomever works on the project. It was also surprising that some sections were further linked to pdf documents further describing the format and or changes.

Link:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/blob/main/UserStories.md

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

Christian Shadis

Worcester State University’s pantry, Thea’s Pantry, is a member in the Libre Food Pantry Community Humanitarian Free and Open-Source Software (HFOSS) project. To prepare to contribute to this project, I familiarized myself with the project’s documentation. Of note was the project’s workflow process, which resolved several questions I previously had about large-scale projects and version control. I had wondered whether many small commits would overload the repository, or whether professional developers were expected to commit much less frequently than I was used to. In the Thea’s Pantry workflow, small inconsequential commits are ‘squashed’ when a feature is merged into the main branch of the repository. I had questioned the consistency of semantic versioning, but Conventional Commits and the automated semantic-release tool¹ addressed those concerns. Examining the documentation offered me some extra insight into how smaller projects become larger, distributed ones.

¹https://github.com/semantic-release/semantic-release

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

I found the user stories section of the Thea’s Pantry GitLab repository to be extremely useful in understanding the scope of the project, as well as how it is actually used by the clients. It explained the general workflow for how the software is intended to be used and the frontend systems that facilitate that use. By using these entry points, it is a lot easier to extrapolate what actually needs to be done in order to create a functioning system. Each step in the process of using the food pantry requires different things from the system, and this shows the day-to-day use of those systems and how they have to interact.

I chose this section as it seemed the most useful to me for understanding the large scale of the project and how it is meant to work for the users.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

I found something useful when reviewing the Workflow documentation for Thea’s Pantry. There are five workflow steps listed online that we should be following but for this post I will focus on Conventional Commits. Although we reviewed this in class, reviewing on my own helped me solidify my understanding of this tool that we will be expected to use. Conventional Commits appear to simply be a set of rules we will need to follow whenever making a commit. The nice thing about Conventional Commits is that it is easy to read for both humans and computers, it works with plenty of other tools (like commitlint), and it dovetails with the Semantic Versioning Specification that is common in the developing field. There were plenty of examples on how to write Conventional Commits on the official website which was useful to review before I start writing my own.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.