Category Archives: CS@Worcester

First Impressions of Capstone: LibreFoodPantry & Thea’s Pantry

I’m genuinely excited about this first blog post for our Capstone! This course feels like a real step into professional software engineering, and I’m eager to learn as much as I can. I also hope our professor challenges us rigorously, helping us approach problems like true professionals in the field.

From LibreFoodPantry, I was surprised and excited to see AWS as a sponsor, it’s amazing to have industry support for student projects. Another highlight was the section on authorship under licensing. It reminded me that Git tracks all contributors and that co-authors should be credited for collaborative work, a detail many students often forget. I also learned about the Shop Manager role, responsible for shop activities with elevated privileges. Maybe one day I’ll be back as a Shop Manager, joking, but also serious!

From Thea’s Pantry, everything finally clicked. Reading the developer documentation, I understood why we took all the other courses (and realized, laughing at myself, that even while juggling work and personal projects, every course actually mattered!). The User Stories, Architecture, Technology choices, Workflow, and Release Process all made sense, especially because my personal projects gave me context (check my GitHub!). I found the Git conventional commit messages particularly useful and plan to start practicing them. I also appreciated the faculty’s points on architecture naming conventions, which are surprisingly valid. One curiosity: there are two systems requiring third-party solutions, I wonder why we couldn’t design them ourselves, especially something like the IAM System.

Overall, I’m incredibly excited for this Capstone and expect to gain a lot from it. This semester promises to be both challenging and rewarding!

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Thea’s Pantry Blog

I found the mission tab very interesting upon reading about it. I really like this whole project idea as a whole and the “mission” tab is well put together in the sense that it describes very well what the pantry is for. The goal to be able to teach students while also helping out the community is a very nice touch. I am looking forward to learning more about it and how all the years of learning are going to be put to use in how the pantry works as well as how to work on a team environment on a real project. I appreciate this project because I think this will help me understand team work and how bigger applications are planned out and executed. I am used to working on things alone so this will put to the test how I can work with others as well as learning at the same time from others. I chose to write about this because not a lot of colleges do this for students. Also a lot of internships lately require “3 years or more” of experience that a lot of students don’t have and this is a way to show the experience we have gained over the years as well as to show that this is a project that I have worked on and gained a lot of valuable information. I also believe this is a great opportunity in general to test my skills as a developer. The website as a whole is pretty neat too.

From the blog Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.

FRONT/BACK ENDs

The blog entry “Front-End vs. Back-End Explained by Waiting Tables at a Restaurant” breaks down the differences between front-end and back-end development in a straightforward, humorous, and visually appealing manner using an everyday scenario. The front-end is likened by the author to a waiter in a restaurant, who deals directly with customers and is in charge of communication, presentation, and ensuring that they receive what they want. The back end is compared to the kitchen, where the actual cuisine is prepared by the chefs (or servers, databases, and business logic). Although the kitchen is not visible to patrons, the restaurant cannot operate without it. The article also describes how APIs function similarly to a menu, outlining exactly what can be requested and how the restaurant would react. For novice engineers, this example helps make difficult technical concepts more understandable.

I picked this article because it directly relates to the concepts we have been covering in class, the transition from monoliths to client-server and ultimately microservices. We witnessed firsthand how the front-end and back-end communicate through well-defined paths in our Microservices Architecture exercise. For example, the StaffBrowser or AdminBrowser interfaces with the GuestInfoBackend, InventoryBackend, or ReportingBackend. Each backend service mimics the kitchen/waiter structure outlined in the article by processing data and returning results to the browser. The article’s description of how requests go through the system is consistent with even the API endpoints we looked at, such as CheckInGuestFrontend or the Express.js servers that power each system. Knowing this example made it easier to understand why our class project is divided into several components and why there needs to be exact communication between them.

As I thought about the post, I saw how crucial it is that both front-end and back-end engineers comprehend their responsibilities and the connections between the systems. Separating responsibilities makes systems easier to maintain, scale, and debug, as we discovered when we compared the monolith versus microservices models in class. The essay reinforced the point by demonstrating how, similar to a restaurant, uncertainty at the front-end or back-end results in delayed service, mistakes, and disgruntled customers, in this case, users. I was also reminded of the importance of APIs. We were effectively looking at the menu that specifies exactly what the front-end can request and how the server will reply when we examined the OpenAPI definitions and backend endpoints in our code. I want to use this example going forward whenever I create or work with APIs. It will be easier for me to organize cleaner services and interact with coworkers if I know what belongs in the “kitchen” and what belongs in the dining room. I want to focus more on how front-end requests move through the various back-end systems and how each service does its function on its own as we continue to work with microservices.

Front End v. Back End Explained by Waiting Tables At A Restaurant

From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.

A quick look at front-end

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well.

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense.