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.

After going over the Thea’s pantry GitLab group, I thought the layout was quite interesting. There are 5 systems: GuestInfoSystem, InventorySystem, ReportingSystem, IAMSystem (Third-party), EventSystem (Third-party).

The GuestInfoSystem stores information about guests of the pantry and about their visits to the pantry. The InventorySystem stores information about the inventory of the pantry adjusting it based on deliveries and visits to the pantry. So far, the food inventory is kept by weight only which I thought was a little unfortunate because it would be much more effective if it was kept by categories (cans, milk, snacks,…). The ReportingSystem generates reports on guests, visits to the pantry, and inventory.

Overall, I am excited to work with all these systems and to make them even better. I think this whole project has a good balance of challenging work while still being doable and manageable.

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.

Looking at the workflow page for the Thea’s Pantry documentation, the first thing I noticed was “conventional commits.” I’d seen them in the commit logs of the projects but wasn’t aware of the name of this format or the motivation behind it.

There’s also the system of having one branch per feature being worked on. In my college courses, none of the projects I’ve worked on have really been large enough to have a need for branches, unless the point of the project was learning about branches. The last time I’ve actually had to use branches was back in high school for my vocational classes (I’m pretty lazy so my personal git projects tend to not have branches) and so hopefully my git skills come back to me.

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.

Thea’s Pantry is a custom pantry management system for Worcester State University. For developers to correctly design an application to meet the needs of the end-user, user stories are created. These stories are a generalized overview of the application workflow from the perspective of a type of user. Staff and Administrator are the two identity roles where Administrator has all permissions including those of the Staff role. The staff role is responsible for handling interactions with guests visiting the pantry and updating inventory when donations come in. Administrators are responsible for monitoring the inventory levels and generating monthly reports for the Worcester County Food Bank. I chose to examine the user stories of the Theas Pantry project because I am interested in how the application is operated by its users and the features it provides.

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.

In my previous post I discussed Libre Food Pantry, a collaborative effort between multiple colleges in New England to create software to help local food pantries better serve their communities. This time I will briefly discuss Worcester State’s contribution in the form of Theas Food Pantry which is used right here on campus.

Theas Food Pantry is a software solution to the food pantry of the same name on campus created by Computer Science Majors. This is made up of many industry standard frameworks such as REST API calls, a JavaScript based front end written with the Vue framework, and Docker for containerization. It is interesting to see how, like many websites and databases this is made using tools that are commonplace in the industry. Many of these tools are open source and yet are still a part of the core workflow in many major software development firms.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

While LibreFoodPantry, which I introduced from my last blog, serves the local Worcester as a whole, another similar project, Thea’s Pantry, is developed exclusively for the Worcester State University community. The user story in this project is written linearly instead of a map compared to LibreFoodPantry, it’s less specific but illustrating the general purpose. However, LibreFoodPantry didn’t indicate the architecture and technology used in the project, Thea’s Pantry instead demonstrated everything beforehand giving the readers a technical perspective about how this project is going to be implemented. Since the big task is broken up into smaller pieces, different teams of developers can work at the same time and each new completed project will become a feature of the final product. Furthermore, by using GitLab CI pipeline, it will be continuously delivered with a new semantic versioning. Overall, this project idea is to benefit both students and pantries at the same time by educating students to develop something practical for the people.

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

• User Stories

I know the costumer ultimately is the organizer using the device, but I could not stop thinking of the people on the other side, who are they, a community member in need, a homeless person, a student in need. This made me think about privacy and sensible ways of presenting quantity constraints in a respectable way. I don’t think a future in UI/UX is for me, but I believe the user should be expanded.

• Architecture and Technology

What I think is most helpful is the architecture and technology. Mostly architecture, I remember how easy it is to get lost on systems that have many parts with different relations. The UML diagrams are important not only to get it right in the first place but check whether you did get it right or not. I think dependencies are hard to describe concurrently having their layout ahead of work makes everyone’s lives a lot easier.    

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