Category Archives: cs-wsu

Exploring the LibreFoodPantry and Thea’s Pantry

As someone who has been learning about Computer Science for 7 years, I have always wanted to have a shot at being able to create an open-source project both for my career and creativity. When reading through the Values from the LibreFoodPantry Main Page, specifically about the “FOSSisms”, I had very closely related to the 11th FOSSism, the FOSSism that stated “It’s not what you know; it’s what you want to learn”. I had found this particular FOSSism inspiring as I have always wanted to create open-source software for solving particular tasks, even if I did not know anything about the software or the items that the software is trying to process. FOSSism 11 also helps to clarify the importance of FOSSism 3, where the goal is simply to “Give back” to the community, as I am hoping to use the things I learn from working with open-source software to help me with Software Engineering in the future.

After reading through the different items about the LibreFoodPantry, I delved into the documentation under the Thea’s Pantry repository to explore more about the open-source software being used. While I did read through the functionality of the software, some being more familiar than others, I was really intrigued with the User Stories under the Developer documentation. I read through the stories about how a user would think over designing a particular software. Reading through this part of the documentation, I had found that in order for a particular part of the system to function as intended, a user would have to make great use of a real-world problem in order to brainstorm new features to contribute to Thea’s Pantry. I am hoping that these user stories can help me use my current skills as a Computer Scientists to help make a great contribution to Thea’s Pantry.

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

Software Architecture Patterns (Token Blog)

While I do not have a great understanding of Software Architecture as much as I do with programming the Backend of that same software, I still take into appreciation the looks of its design.  When I took sight of “The top 5 software architecture patterns: How to make the right choice” written by Freelance writer Peter Wayner, one of the things that was eye-catching was how the Software Architecture Patterns were described throughout this blog.  While the Microservices Architecture was one of the only architectures that I had familiarized myself with while reading through the different architectures, I had been more interested in the endless vacuum of strengths that the Space-based architecture had when seeing the benefits that it poses.  The article had given a very understanding of all the Software Architectures by showing their strengths and their weaknesses, making it easier to see where their limits are foreseen.

I chose this article since I searched far and wide for a topic that I least understood, but still would be inspired to follow through reading about it for fulfillment.  The article does a really great job at grabbing the reader, as the most complex part about trying to understand a Software Architecture is when you are trying not to break your own code with a Software Architecture that poses a great risk in causing your program to crash unexpectedly.  For the simplicity of the reader, Wayner had given either a telling example or a visualization that would help the reader have a simple explanation of what the structure is designed to do for your program as its structure.

The biggest takeaway I had after reading this article was that I was still able to learn that each architecture shapes your program in a way to help better understand what to do with your program next.  However, Software Architecture is still only the beginning of what you need to do to fully design your software.  A software may still need changes that an architecture alone cannot fix, but what an architecture should do is help you see the full picture of your own work that you have done.  A Software Architecture is only a frame in the end, but the program you create would be best suited for an environment that is needed to put it on full display.

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

REST API (Token blog)

When I was first introduced to the concept of an API, a shortened abbreviation of Application Programming Interface, I never thought of it being used far outside the scope of Computer Science.  However, as I revisited some software that I used in the past and observed the current software I worked with recently, I was more than surprised by the fact that an API is universally used across the Internet.  For this blog, I explored a blog called “10 Most Popular Frameworks For Building RESTful APIs” written by Developer Advocate at Moesif, Preet Kaur. In this blog, the author explained that when deciding on the API framework to use, you needed to choose one that uses a programming language that you are familiar with, but you can also use in spite of its shortcomings.  Further down the blog, she gave some examples of popular API frameworks that are used by many developers; one of those frameworks that was mentioned was Express JS, a framework I am familiar with.

One of the biggest contributing factors that brought me to use this article for this blog is not only the different frameworks that Kaur had given examples of, but also where you can find and learn about them.  Reading this blog got me hooked on the many different types of API frameworks that I could look at to familiarize myself with each that may give me a better understanding of the specifics of REST API for my drive toward a career in Software Engineering.  Even if the frameworks in question were written in programming languages that I am not as efficient in programming in, I still believe that this blog has helped me in understanding the overall meaning of building an API for use in creating applications and beyond.

My biggest takeaway from this blog is that the API framework you use to build an application, software or other kind of design is not only dependent on your skill at programming or engineering, but also what your goal is with using the framework you choose for your creation.  While this blog was more general than the previous ones I read through, I still stand with a vision that the API framework that I use will only be as helpful as the skills I use to develop and engineer my path to a greater goal in creating the perfect software.


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

Writing Clean Code in Python

At Worcester State University, I have been learning about programming through the context of Java. However, there are many other programming languages aside from Java. Though they likely follow the same principles and patterns, there are also inevitable differences, or at least a different approach to these same principles or patterns in practice.

The article Best Practices to Write Clean Python Code written by vanigupta20024 goes over Python specific clean code practices. The author presents four main tips:

  1. Clean indentation
  2. Using virtual environments
  3. Modular code
  4. “Pythonic” code

Clean indentation was taught in class under the context of “horizontal openness” or “horizontal spacing”. This principle is necessary for all languages, but it is especially necessary for Python. Python does not use braces to specify code blocks. Instead, it relies solely on space and tab indentations. Because of this, not only is clean indentation required to readable code, it is required for executable code!

Using virtual environments is something specific to Python. It allows the programmer to create a separate and custom environment for their project where any installed libraries and packages are separated from those installed outside the environment. That way, dependencies can be easily shared and managed separately for each project. Instead of having someone install libraries one-by-one, it is much cleaner to have the person run a requirements.txt file to automatically install all the necessary libraries and packages to run the code in one execution.

Modular code is a tool in Python that helps programmers follow the DRY principle (Don’t Repeat Yourself). This makes code clean by allowing programmers to create something like a code library that can be imported and implemented into the Python program without having to have all the code in the repository. Even better, modules can be uploaded into the Python database to be accessed by anyone, meaning that instead of having to create the function themselves, programmers can simply import the function they need to use in their code, making the code less dense and neater.

“Pythonic” code refers to special Python shortcuts that can make code easier to read by simplifying a task that would normally take multiple lines of code. For example, when swapping values, a programmer might initially think to write code this way:

value_a = 5
value_b = 6
temp = 5

value_a = value_b
value_b = temp

However, that is a lot of lines simply for swapping two values with the addition of a third variable. Instead, there is Python shortcut for this that simplifies the process.

value_a = 5
value_b = 6

value_a, value_b = value_b, value_a

Clean code is definitely an aspect of programming that I want to become more adept with. Python is not a language taught at WSU, but it was the sole language I used in my internship and research projects which is why I decided to do research on tips and tricks for clean code through the context of Python programming.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Adhering to the Law of Demeter

Also known as the Principle of Least Knowledge, the Law of Demeter states that objects should avoid accessing data and methods that belong in other classes and instead, only interact with its immediate dependencies (Baeldung).

When used with Object-Programming languages, the goal of the Law of Demeter is to make the components of a program less dependent on each other, loosely coupled, and therefore easier to manage and scale.

There are five rules to the Law of Demeter:

  1. The first states that methods should only call methods that belong to their same class. It is not recommended for a method in class X, for example, to call on another method in class Y.
  2. The second rule expands on the first to say that methods of a class should only call methods that belong to the objects created by that class. For example, a method X of a class Z should only call methods of an object created by method X.
  3. The third rule states that a method should only ever interact with an object when passed to it as an argument. There should be no direct access to the object within the method itself.
  4. The fourth rule allows the method of a class to invoke the method of a class given that it is an instance variable of the same class. For example, method X of class C is allowed to call the method of an object held as an instance variable of C.
  5. The fifth rule is similar to the fourth rule except it states that the method of a class is able to call the method of a static field in that same class, similar to a method of an object of the same class.

When these rules of the Law of Demeter are applied, they help prevent code from becoming tightly coupled, meaning that they cannot operate independently. However, there are some exceptions to certain cases such as for chain calling, fluent APIs, or working with data structures. An experienced programmer will know when and how to effectively apply the law of Demeter.

While refactoring the code for one of my research projects, I had practiced to apply the GRASP principles to the new design. For another project that I am refactoring, now that I am more comfortable with the GRASP principle, I will focus more on applying the law of Demeter to make sure my code is not tightly coupled. This means code that is less fragile, scalable, and easier to manage.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Week 13 Clean Code

In my search for a topic this week, I searched for an article closely related to our homework and our last five Pogil activities. I kept it simple and looked for an article about clean code. I understand we have been loaded with tons of information about clean code but when was having more of something bad. I wanted to see different perspectives of clean code outside of class and what people inside the field or with experience opinions on. Allowing me to get insight from outside of class will be very helpful. Also, being able to have an open mind with coding can go a long way plus being able to see similarities with what I have learned and my own opinions. 

This article starts by describing the term “Spaghetti code” which refers to complex tangled code that is hard to decipher and causes frustration for everyone involved. This ties into clean code by emphasizing how is an integral component of software development and can only be maintained with practice. This comes with less team frustration and allows for any teammate to manage the code. Clean code is just not a statement of keeping the code tidy tightly but more of a form of communication that can be understood by everyone thoroughly. Software companies make big investments into clean code by hiring someone and paying them around $60-$100 an hour because of how vital it is for long-term success. An effective strategy to implement clean code is by grouping similar functions, utilizing whitespace, and “one idea per line” and “one action per statement”. To tie it all together your code must be consistent to adhere to agreed-upon team coding standards. Decisions that will help in the long run would be to add meaningful names, maintain simplicity, and apply comments effectively. 

With this article, I was able to learn a new term “Spaghetti code” that is self-explanatory and can remind me to keep my code simple and clean. I was able to connect many teachings from class including using meaningful names, abiding by team agreements, and utilizing whitespace. All these are valuable pieces in writing clean code that should always be in your mind when writing any piece of code. I was surprised at how much software companies invest in clean code and wasn’t expecting them to get paid that high. My main takeaway from the article was to keep my code consistent and simple. You may not think about these things but wanting to make things more complex can be a determent to all your previous work so being consistent will not only help you but your team as a whole.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

The 9 Principles of GRASP | Part 2

There are many parts that make up well designed code. One of these is the management of responsibility, whether in classes, functions, or databases.

GRASP (General Responsibility Assignment Software Patterns) is a set of principles that programmers use to make code that is “responsible”.

In the previous article, the first four principles of GRASP were discussed:

  • Information Expert
  • Controller
  • Low Coupling
  • High Cohesion

These four principle, in short, say that code should be written with as little dependencies as possible to reduce the effects of change (low coupling), meaning that classes with similar responsibilities and dependencies should be connected not directly, but through an interface, or otherwise simplified into one class (high cohesion).

Furthermore, system events should be handled through a single class that manages and coordinates the system behavior using the processes available in other classes (controller). Classes that handle processes should be those assigned with the most responsibility (information expert).

The final five principles of GRASP are the following:

  • Creator
  • Indirection
  • Polymorphism
  • Pure Fabrication
  • Protected Variations

As in the previous post, I will be referencing In10se’s article Mastering GRASP Design Principles for Better Software Design.

  1. Creator: This principle states that classes that require objects should be responsible for their creation. This not only simplifies the creation process, but also supports the high cohesion principle in unifying classes with similar responsibilities.
  2. Indirection: For processes that are used by multiple classes, the principle indirection says that an intermediate class should be created from which other classes may reference (i.e. a notifications class from which classes email and SMS reference).
  3. Polymorphism: This pattern is same one stated in the core principles of Object-Oriented programming by which classes with similar attributes and methods are grouped under a super class where similarities can be inherited and modified accordingly.
  4. Pure Fabrication: There may be cases when there are no classes in which a particular function may fit. In this case, to maintain high cohesion, a new and separate class can be created to handle these functions. However, should too many of these exist, that may indicate that responsibility is not being handled optimally.
  5. Protected Variations: Classes should be responsible for handling their processes; but sometimes, especially for classes that deal with modifying sensitive data, the changes should be encapsulated behind a stable interface to increase the overall system’s robustness.

GRASP taught me a lot about how to better design my code. Looking back at the code I’ve written, I can see that my code would definitely benefit from higher cohesion and lower coupling. Many of my classes and functions are dense with responsibilities that would be more clear if separated into their own dedicated classes.

The point of GRASP is to create cleaner code that is secure and easier to manage. I didn’t think much about programming responsibilities before reading in10se’s article, but now I will be sure to implement these patterns into my future code.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Week 12 Project Coordination

While we have been working on our projects I have wondered what we should expect in our upcoming work. That is why I searched for an article that would give me insight into the later parts of our project. Just finishing up the project set up a few days ago will help me map out the rest of the project itself. I targeted my article on projects in GitLab to have a more precise understanding rather than a broad project understanding with no correlation to our own.  Hopefully, giving you the knowledge I gained will help your journey of developing your project.

This article gives the reader an insight into how GitLab coordinates its scheduling, planning, tracking, and releasing. To decide on their release date they use the Good Docs Projects template which emphasizes two updates per year. So for GitLab, they work from Jan – May release mid-June, then a three-week break, then back to work from July to December, have a release, then another break starting the cycle over again. In their six-month work, it’s similar to scrum where the team meets up in the beginning and establishes goals. During those months they do general community meetings to see if they’re on track and assign issues by weight of importance. On release day, all the team members meet up to build the team artifacts including their zip files and tarballs. If everything goes right and all their merge requests are complete they try to make sure everyone is credited and then go on a three-week vacation where the cycle begins again all over again. 

After reading this article it showed me a new and effective way to complete a project. This way of doing a project has many similarities to scrum but in the grand scheme of things, all you need is a cycle that is effective and can be repeated. In this particular project, I can’t use their scheme but I can try to concise it into a smaller scale understanding the time constraints. I think it’s very effective to have a break after finishing a project. Some people may want to take a break in between projects but in my opinion, it’s better to finish it overall then take time for yourself. In the article, there was no research on the effects of the break but I believe their workers come back replenished and ready to work when they do come back.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

The 9 Principles of GRASP | Part 1

GRASP stands for General Responsibility Assignment Software Patterns. It is a set of principles applied to Object Oriented Programming.

There are nine principles or “patterns” which help programmers understand the responsibilities in software design. In10se on Medium writes a detailed summary on each principle in the article, Mastering GRASP Design Principles for Better Software Design.

  1. Information Expert
  2. Creator
  3. Controller
  4. Low Coupling
  5. High Cohesion
  6. Indirection
  7. Polymorphism
  8. Pure Fabrication
  9. Protected Variations

When developing code, programmers need to identify where to assign responsibility in the code. In software design, responsibility refers to two things: behavior (doing) and data (knowing). Different parts of the code have the responsibility or obligation to “do” the thing itself, such as creating an object or modifying the data.

Programmers can also assign responsibility to the data used by the code such as when the data is public or private, or when to relate data objects for reference, or how the data can be used to generate dependent data.

To keep this post within the acceptable length, I will cover the first four principles this week.

  1. Information expert: this principle states that “responsibility should be assigned to the class with the most knowledge or information required to fulfill the responsibility” (In10se).
    For example, a professor object that has access to every student’s homework and test scores should be responsible for calculating each student’s final grade since this object has access to all the necessary data to do it.
  2. Low Coupling: there should be as little dependencies as possible to reduce the effects of changes in the data and code so to keep different systems separate from each other.
    Instead of having one object be dependent on another, it would be better to create a separate interface that connects the two.
  3. High Cohesion: groups that have related responsibilities should be simplified to a single class for better clarity and maintainability. This also means keeping things that have no related responsibilities separate.
  4. Controller: this principle says that all system events should be handled through a single class that manages and coordinates the system behavior. In10se gives the example of a UserController class that is dedicated to handling user-related events like registering and logging in. However, the actual processes are in other classes.

While writing code is certainly difficult, I find designing the code the hardest part. Just as being fluent in a language doesn’t make me an excellent author, so too does knowing a programming language well not necessarily mean that I can write software that is efficient and effective.

Designing software requires a strong understanding of how to assign responsibility in the code. GRASP contains principles that help guide a programmer’s decision making when designing the software structure so to write a program that not only works, but is also secure and maintainable.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Week 11 Choosing a programing Language

I was thinking about our recent classwork activities and our own project and thought about what goes into selecting a programming language. I always assumed it was a preference but sometimes some languages have more benefits than others that can help you in the long run instead of choosing one you prefer. In addition, you gain more knowledge not sticking to one but being able to adapt to others. That is why I decided to find an article about choosing a programming language for your specific project.

This article uses a perfect analogy of how building a house is like choosing your programming language. For example the specifications of the house, what materials will you use, and where you want to build your house. You need to ask yourself similar questions like what kind of project, the development budget, and the complexity of the project. My main takeaway was to have a main objective of your project and have a clear definition of what you intend to do so you may pinpoint the type of application you want to create. Every language has a main focused application purpose like Front End Development: JavaScript, HTML, and CSS, 2D Game Development: JavaScript or C#, and 3D Game Development: C# or C++. There is a large list but being able to envision your project will prevent mistakes from occuring. For this specific project, I believe the article makes a valid point that the development time limit is a great concern in choosing a programming language. With a deadline, you can’t just slack around or try to learn a new programming language with the time constraints so choose wisely. 

Reading this article allowed me to open my eyes to each programming language’s specific uses. I knew that some languages were best suited for different things but allowing me to see the variety was eye-opening. After reading this article I am now able to choose what programming language I will use for my project more efficiently. I know it isn’t the main focus of the project but it’s a step forward. In addition made me think about the small things like security, performance, and maintainability. You may not think about these things as soon as you start but may become big concerns later down the line without the proper planning ahead. For example, performance will only be taken into account late into the project after there has been ample time placed on the project. Maybe the specific application you making doesn’t work efficiently this will hurt meeting your deadline without proper precaution.     

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.