Category Archives: CS@Worcester

FOSS -> HFOSS

https://timreview.ca/article/399

Free and open source software (FOSS) has been a focus of our curriculum this semester. Our introduction to working with and managing the Theas Food Pantry software has provided us with experience contributing to this FOSS as well as understanding the benefits of these types of programs. The article Humanitarian Free and Open Source Software  by Chamindra de Silva dives into the important subsection of FOSS, one that focuses on humanitarian efforts and how it can benefit those in need or those suffering from a disaster event; otherwise described as “software engineers without borders”. A key aspect of this type of software – and the reason I chose to highlight this article – is that it inspires collaboration from others in the community, with the goal to make the program better, evolve it, and offer it as a tool for others to use and benefit from; therefore upholding the key principals of FOSS.

The article explores technology’s role when it comes to humanitarian efforts, it creates software to help address rapid-onset natural disasters, slow-onset natural disasters, and human instigated disasters. Many of these models support efforts to aid in managing large scale data management problems that would otherwise often overwhelm traditional information gathering methods. Humanitarian goals and values align with many in FOSS’s mission; to be available to the public to serve a common good, to rely on the support of those in a community to help others in that community, and lower cost in order to leave more funds for aid. 

However, outside of their similarities, HFOSS requires more attention to certain “best practices” due to the nature of importance within the community it is serving. It demands a product be of high quality and relatively stable because system failures can result in information loss that affects life-saving efforts. The software is required to be highly intuitive with an easy learning curve, while also being resilient to many types of political and economical and ecological environments. 

Humanitarian free and open source software has been of interest since our initial introduction to it in class. Having been aware of and utilized FOSS implementations, I was unaware of this specific movement. The idea that I can connect uniting people in our world together by helping them during times of crisis with software development and my career in tech, appeals to me greatly. Knowing that I could potentially help create software that connects people with lost loved ones (Sahana), or host maps of previously unmapped areas to help first responders (OpenStreetMaps), helps me open my mind to evergrowing opportunities afforded to me in my new career. It also gets me thinking about ways to create and tie in a HFOSS project of my own that relates to my current career in Veterinary Medicine.

From the blog Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 3

November 16th, 2025

Considering how clean code was recently on my mind (mostly due to a recent assignment), I thought it might be interesting to look into. I ended up finding out that there a various style guides (well, a comic from an assignment also showed me that too) and this blog shows some examples. It is nice as a basic overview of some style guides. It most notably noted 3 types of styles that revolve around whitespace usage and brace placement. It compliments what I was learning in class as the class typically focused on things like function and variable names, reducing the amount of nested loops, and the usage of too many parameters. The blog goes over how some styles place braces in a way to make it easier to parse through things like heavily nested loops and such. These both end up telling of ways to increase clarity but in different ways, which is super fascinating.

Interestingly, this led to me to look at my own code. My current code uses the “Allman” style of braces. This was taught to me back in AP Computer Science back in high school. I vaguely remember “Allman” being discussed in class, but I never made the connection between it and how I typed code. I ended up doing it since it was the easiest to read. Well, that and the professor told me that this was the “proper” way to code. (I vaguely remember the thing I did code in also automatically did it for me too.) Since then, I’d sometimes just go around and putting braces in that format. (Perhaps I’m worse off due to this since I overly rely on a style. I’ll need to learn to read other styles soon.)

Overall, I’ve mainly noticed my code is super, super bad. Like, overly bad. So next time I code something, I should do many different things. This blog I picked and the assignments on “clean code” would be a good start honestly. (Unfortunately, as someone who “thinks by doing,” I had a habit of creating copious amounts of technical debt without even realizing it. Then again, I was always the type to prefer redoing things entirely as opposed to looking for minor improvements….) Maybe one day my code will be actually good for once. And thankfully, I’ve got various places to start improving. There’s a long road ahead…. Well, at least that means that I have a lot of ways I can improve; the plateau isn’t here just yet. In fact, it is very far from where I am.

https://iannis.io/blog/the-ultimate-code-style/

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

CS343: The Dark Days of Design (and DDD)

This week I read a blog post from Robert Laszczak of Three Dot Labs titled “Software Dark Ages”. You can find that post here.

If the Dark Ages happened a long time ago, why are people still using Eclipse?

What was the article about?

Laszczak recounts his experience working for a company heavily ladened with pretty much every single kind of organizational, institutional, architectural, and technical flaw or burden out there. In his retelling, even something as simple as changing the functionality of a button would take months because of extremely high code coupling–among myriad other problems.

The way he solved this problem was to use DDD, or domain-driven design. DDD, like the similarly named test-driven development (TDD), places foci on particular problem domains and builds up around them. In TDD, these foci would have been our tests and test coverage, which we would then use to build up our code against. In DDD, we start with the problem and come up with a solution pattern that perfectly encapsulates the problem and its who/what/why/whatever.

If this sounds deceptively intuitive, that’s because it probably is. As Laszczak points out, DDD and problem-solutions like it have existed for almost two dozen years at this point (DDD’s whitepaper dates to 2003). The reason why they’ve fallen into obscurity is because people have forgotten the enlightened ideas of antiquity like they’re living in the Dark Ages.

In [the] Software Dark Ages, infrastructure is putting down important software design techniques.

The problem is, Laszczak bemoans, that the modern software DevOps team is more concerned with achieving technical marvels (e.g. getting that Atlassian Certified t-shirt) than spending their brainpower on something as simple as considering the wheel. Technology is great, except why are we using it? What purpose does it have, not only for us, but for our customers?

The reason we engage with structural criticism is to gain a better understanding of the system at play. Look at 432 Park Ave in NYC and you might see what a poor grasp of domain causes for a project, and when engineers are aware of the customer and their problems but choose to ignore both because… it was easier?

432 Park Ave: A beautiful marble-like white concrete exterior dominates the New York City skyline…
…except for the bughole voids and the hilariously slapdash Blu-Tak patch-and-fill job. A beautiful mess.

Why does DDD matter & why did I choose this post?

We have many frameworks for tackling software problems and organizing work, but very infrequently do we stop to consider the intricacies of the problem and how we can shape our project to meet the problem’s needs (inputs) rather than our organization’s abilities (outputs). Having high productivity and a strong team culture is important, but what does that mean if our codebase is in a terrible shape and our customer’s final product isn’t right-sized to their needs?

In our class, we’ve begun to work with Thea’s Pantry, and one of the things we’ve touched upon time-after-time is that the state of the system is specifically tailored to the needs of the pantry. Not all pantries–not a lot of pantries–the code we are looking at is the way it is because someone or something at Thea’s Pantry needed it to be that way.

That’s what thinking in terms of DDD yields us.

What not thinking about DDD yields:

  • 432 Park Ave
  • The Torment Nexus (NB DevOps: not an Atlassian product, don’t try it!!!)

What I think: DDD is a mouthful.

Kevin N.

From the blog CS@Worcester – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

OpenAPI and Cloud POS

I came across an article from Oracle that talks about the benefits of a cloud POS system that uses an OpenAPI backend. It starts by highlighting the importance of having a cloud POS system in a restaurant. The biggest benefits are its responsiveness, scalability, and security. It allows businesses to add and drop menu items with ease, and prioritize orders in the kitchen. It comes with built-in analytics to help them make decisions. Oracle tells about how Simphony, their cloud POS system, has local storage to allow the system to continue working through internet outages. Next, they compare OpenAPI to private API. The main difference is that OpenAPI allows for developers to connect the software more seamlessly with less restrictions. Private API, on the other hand, is only really available to internal developers, making it less user friendly. They then talk about how Simphony is built on OpenAPI architecture, making it easier for the customer to interact with, getting data and feedback quicker. This makes for a more trusting relationship between partner and client. They make a point that it provides both scalability and security. OpenAPI is flexible and responsive, giving businesses that choose to use a POS system with open API architecture an edge. In restaurants specifically, it allows for the front of the restaurant to connect with the kitchen more easily.

The reason this was important for me to read and write about is that we are spending a lot of time in my CS343 class discussing OpenAPI. It isn’t the easiest thing to grasp, but the more we learn about it, the more interested in it I am. This was especially interesting to me because Oracle is a very big tech company, and I was curious to see how they marketed their product that uses OpenAPI architecture. As we are learning about OpenAPI systems through real-world applications, it is always interesting to see how these things are applied in a real work environment. A POS system is a very appropriate use for OpenAPI. I enjoyed learning about the different types of products that Oracle offers using OpenAPI architecture. It was also cool to see how a company like Oracle uses OpenAPI and encourages their customers to use their products with it as well. It is reassuring to see how wide-spread the use of OpenAPI is. This encourages me to learn more about it in the future, and to make sure I am well versed in this subject matter.

https://www.oracle.com/apac/food-beverage/restaurant-pos-systems/simphony-pos/why-choose-cloud-pos-system-open-api/

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

Better your Coding Standards

For this quarters blog, I decided to write about Coding Standards and chose to read Why You Need Coding Standards by David Mytton. To start off, Mytton talks about what does “proper” code really mean. It is not just any code that works, but rather code that is easy to fix, add to, and update in the future. His blog mentions a common problems that we face today. Many developers start learning code with their own style which only they might understand. Once a project grows and other people join in, different styles will collide and make the code confusing. Mytton explains the frustration of working with messy code and how stressful it is to scroll through long, unclear code with confusing variable names, missing comments, and code without spacing.

There are two main examples that were used to show the difference that coding standards make. Both examples were written in PHP, the first example was messy. There wasn’t spacing, variable names were unclear, no braces around control structures, and long conditions missing parentheses. Although it technically worked, it was definitely hard to read at first. The second example showed the same logic. This time around there was clean formatting, clear variable names, proper indentation, and braces correctly placed. I’ve never used PHP but it was obvious that the second example was much easier to understand.

I selected this blog because recently in class we’ve been working on clean coding and realized how hard it can be to understand code written in different ways. I also wanted to further my understanding of how professionals handle this problem and how they keep projects organized. I think that this blog was able to explain that point in a simple and relatable way for me.

From this blog I learned that coding standards are beyond just “good habits.” It prevents confusion, reduces mistakes, and allows projects to run more smoothly. I also learned that a coding standard is not something that just one person creates and uses for themselves but rather by the whole team. I hope that I am able to fix my poor coding habits and write code that allows others to collaborate with my work. I think before this, I didn’t care much whether somebody would be able to read my code but rather if it was able to run then I was satisfied. My mindset has changed and I want to be more consistent with following coding standards.

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

CS343-01: Third Quarter Blog

Software Constr – Blog Three

APIs are something we come across a lot, especially the openapi.yaml file we look at for the Microservices Activities in class. So, I wanted to make a note for myself on what APIs are, the benefits, and the different types.

Firstly, what is an API? API stands for Application Programming Interface and it’s a mechanism that helps two software components communicate by the use of definitions and protocols. “For example, the weather bureau’s software system contains daily weather data. The weather app on your phone “talks” to this system via APIs and shows you daily weather updates on your phone.” And there are four different ways an API works: SOAP, RPC, Websocket, and REST.

The SOAP API is short for Simple Object Access Protocol API and it works with the client and server exchanging messages and other the use of XML. Remote Procedure Calls, RPC, APIs has the client complete a procedure on the server in which the said server would send back an output. Websocket APIs use JSON objects to pass the data being used and supports a two-way communication between the client apps and the server.

REST API is one we had just worked with in class and had homework on. It’s the most popular since it’s flexible and has the client send a request as data to the server which starts to use internal functions to return outputs back to the client. REST stands for Representational State Transfer that defines functions such as GET, PUT, DELETE, etc., all of which we have seen in the openapi.yaml file.

The REST API has four main benefits: integration, innovation, expansion, and ease of maintenance. Integration is used to increase development speed since the functionalities won’t have to be made from scratch because of the fact that APIs are used to integrate new applications with existing software systems.

Innovation is where industries can change with new arrivals of apps entirely since they can make changes without having to rewrite the entire code at the API level. “Businesses need to respond quickly and support the rapid deployment of innovative services.”

Expansion is something where it’s a unique chance for businesses to meet the needs of their customers across so many different platforms. “For example, maps API allows map information integration via websites, Android,iOS, etc. Any business can give similar access to their internal databases by using free or paid APIs.”

And finally, ease of maintenance. REST APIs act as a sort of gateway between systems. They each make changes internally so that the API isn’t impacted and in response? “Any future code changes by one party do not impact the other party.”

Source: https://aws.amazon.com/what-is/api/

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS348-01: Quarter Three

Software Process Management – Blog Three

In class, we’ve been learning about clean code and heard the name “Uncle Bob” multiple times. Because of this, I was trying to learn more about him and what else I could from clean code. Which led me to the SOLID Design Principles.

To start, Uncle Bob is a man named Robert Cecil Martin who had been born on December 5, 1952, according to Wikipedia and many other sites I had looked at. He is an American software engineer, instructor, and author – most recognized for promoting many software design principles and for being an author and signatory of the influential Agile Manifesto. He authored many books, articles including being the editor-in-chief of a C++ Report magazine, and was the first chairman of the Agile Alliance. He actually was self taught and joined the software industry at the age of seventeen. “Martin is a proponent of software craftsmanship, agile software development, and test-driven development. He is credited with introducing the collection of object-oriented programming (OOP) design principles that came to be known as SOLID.”

What is SOLID? Well, it’s an acronym for the five different object oriented design principles that Robert C. “Uncle Bob” Martin had created. In this acronym, there lies the Single Responsibility Principle, Open-Closed Principle or OCP, Liskov Substitution Principle, Interface Segregation Principle, and finally Dependency Inversion Principle.

One of the principles, the Open-Closed Principle, was something that I remember learning in class, even having to refer to it for a question in an activity we did. Modules, classes, and functions should be open to extensions, but closed for modifications. The rest however? Those were new and at first glance, my immediate thought was to Google it.

According to Wikipedia, the Dependency Inversion Principle or DIP is “a specific methodology for loosely coupled software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.”

The Liskov Substitution Principle in the source says that “if class A is a subtype of class B, then we should be able to replace B with A without disrupting the behavior of our program.” It was actually initially introduced by a woman named Barbara Liskov in 1987 where it was based on sustainability so that nothing would break.

Barbara Liskov is an American computer scientist who was a pioneer contributor to many programming languages and distributed computing. Some of her most notable work includes “the introduction of abstract data types and the accompanying principle of data abstraction, along with the Liskov Substitution Principle, which applies these ideas of object-oriented programming, subtyping, and inheritance.”

Source: https://medium.com/@lavishj77/solid-design-principles-dd3c0afe7e97, https://en.wikipedia.org/wiki/Robert_C._Martin, and https://en.wikipedia.org/wiki/Barbara_Liskov

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

API and Modern Day Development

 

 

This article, “Understanding the Role of
APIs in Modern Backend Development” starts with what API is and how it is now
backbone of modern-day development. APi is a set of rules and protocols that
allow software components to interact and expose backend functionality or data
to other services, clients, or platforms. The article shows and explain different
types of APIs used in backend development, REST APIs, GraphQL APIs, WebSocket
APIs. Rest Apis are most used architecture, based on HTTP methods, makint it easy
to scale, maintain, and secure. GraphQL APIs are improved alternative of Rest
Api, which allows clients to request exactly the data they need in a single
query, reducing the number of requests sent to the backend. WebSocket APIs on
the other hand, enables bi-directional real-time communication between the
client and server making it useful in applications like chat, live updates or
gaming. After that the article explains best practices for using API in backend
development and they reasons why we need them; Use Clear and Consistent Naming
Conventions, Document Your API, Implement Security
This article ends with to popular backend frameworks for building API and why
they are used. Examples include Node.js (Express.js), Django (Python), Ruby on
Rails (Ruby)  Spring Boot for Java,
Laravel for PHP, and FastAPI for Python.

           I
recognize that one of the areas I’ve struggled with is using and designing APIs
effectively. Therefore, I chose this article, because it tackles that with
further knowledge that I currently have. I found out in the world there are
more to the Apis than just the Rest Apis and this article well explains other alternatives
to Rest Apis and what they do and its examples. Not only that, but the article also
explains important things to do while using Apis and popular framework that I can
later learn to improve my skills as full stack engineer.

From this article I learned not just new
apis and where to use them but also the framework section gave me context about
which tools I might adopt based on my need and language, and their benefits. It
also expands on what I need to do further implements the practice so I might not
be confused in the future while building apis and that they are they are
contracts between system. In the future, I will try to better document
everything while checking out the version control more carefully than before.
Not only that, but I might also try out different Apis to make Backends the other
APIs like GraphQL APIs, WebSocket APIs seems useful in parts for future
practices. 

 

https://medium.com/@danieltaylor2120/understanding-the-role-of-apis-in-modern-backend-development-36059945db1d 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

API and Modern Day Development

 

 

This article, “Understanding the Role of
APIs in Modern Backend Development” starts with what API is and how it is now
backbone of modern-day development. APi is a set of rules and protocols that
allow software components to interact and expose backend functionality or data
to other services, clients, or platforms. The article shows and explain different
types of APIs used in backend development, REST APIs, GraphQL APIs, WebSocket
APIs. Rest Apis are most used architecture, based on HTTP methods, makint it easy
to scale, maintain, and secure. GraphQL APIs are improved alternative of Rest
Api, which allows clients to request exactly the data they need in a single
query, reducing the number of requests sent to the backend. WebSocket APIs on
the other hand, enables bi-directional real-time communication between the
client and server making it useful in applications like chat, live updates or
gaming. After that the article explains best practices for using API in backend
development and they reasons why we need them; Use Clear and Consistent Naming
Conventions, Document Your API, Implement Security
This article ends with to popular backend frameworks for building API and why
they are used. Examples include Node.js (Express.js), Django (Python), Ruby on
Rails (Ruby)  Spring Boot for Java,
Laravel for PHP, and FastAPI for Python.

           I
recognize that one of the areas I’ve struggled with is using and designing APIs
effectively. Therefore, I chose this article, because it tackles that with
further knowledge that I currently have. I found out in the world there are
more to the Apis than just the Rest Apis and this article well explains other alternatives
to Rest Apis and what they do and its examples. Not only that, but the article also
explains important things to do while using Apis and popular framework that I can
later learn to improve my skills as full stack engineer.

From this article I learned not just new
apis and where to use them but also the framework section gave me context about
which tools I might adopt based on my need and language, and their benefits. It
also expands on what I need to do further implements the practice so I might not
be confused in the future while building apis and that they are they are
contracts between system. In the future, I will try to better document
everything while checking out the version control more carefully than before.
Not only that, but I might also try out different Apis to make Backends the other
APIs like GraphQL APIs, WebSocket APIs seems useful in parts for future
practices. 

 

https://medium.com/@danieltaylor2120/understanding-the-role-of-apis-in-modern-backend-development-36059945db1d 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

API and Modern Day Development

 

 

This article, “Understanding the Role of
APIs in Modern Backend Development” starts with what API is and how it is now
backbone of modern-day development. APi is a set of rules and protocols that
allow software components to interact and expose backend functionality or data
to other services, clients, or platforms. The article shows and explain different
types of APIs used in backend development, REST APIs, GraphQL APIs, WebSocket
APIs. Rest Apis are most used architecture, based on HTTP methods, makint it easy
to scale, maintain, and secure. GraphQL APIs are improved alternative of Rest
Api, which allows clients to request exactly the data they need in a single
query, reducing the number of requests sent to the backend. WebSocket APIs on
the other hand, enables bi-directional real-time communication between the
client and server making it useful in applications like chat, live updates or
gaming. After that the article explains best practices for using API in backend
development and they reasons why we need them; Use Clear and Consistent Naming
Conventions, Document Your API, Implement Security
This article ends with to popular backend frameworks for building API and why
they are used. Examples include Node.js (Express.js), Django (Python), Ruby on
Rails (Ruby)  Spring Boot for Java,
Laravel for PHP, and FastAPI for Python.

           I
recognize that one of the areas I’ve struggled with is using and designing APIs
effectively. Therefore, I chose this article, because it tackles that with
further knowledge that I currently have. I found out in the world there are
more to the Apis than just the Rest Apis and this article well explains other alternatives
to Rest Apis and what they do and its examples. Not only that, but the article also
explains important things to do while using Apis and popular framework that I can
later learn to improve my skills as full stack engineer.

From this article I learned not just new
apis and where to use them but also the framework section gave me context about
which tools I might adopt based on my need and language, and their benefits. It
also expands on what I need to do further implements the practice so I might not
be confused in the future while building apis and that they are they are
contracts between system. In the future, I will try to better document
everything while checking out the version control more carefully than before.
Not only that, but I might also try out different Apis to make Backends the other
APIs like GraphQL APIs, WebSocket APIs seems useful in parts for future
practices. 

 

https://medium.com/@danieltaylor2120/understanding-the-role-of-apis-in-modern-backend-development-36059945db1d 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.