Category Archives: Quarter-4

Vue.js and How it Works

 

This article, An Introduction to Vue.js:
Understanding the Framework and Getting Started, is a good starting point for
people who want to use vue.js, a JavaScript framework that is used to make User
interface. It lights major features of vue.js; components, directives, instance
and router and how they work.  It then goes
into deeper topic of vue.js , stage management in vue.js from beforeCreate to destroyed,
introducing vuex which is the state management library. It explains the
structure of Vuex (state, mutations, actions, context) and demonstrates how
Vuex can be integrated with Local Storage and Session Storage to persist
application state across page reloads or browser sessions. It continues on to
reactions and even handlers, showing how computed values react automatically to
data changes and how event listeners allow components to respond to user
interaction. Last thing it explains about server-side rendering, what it does
and how it used to improve performance and SEO optimization This article concludes
stating that vue.js is a powerful and popular framework for web development,
offering a versatile and intuitive approach to building interactive and dynamic
user interfaces and simplifies the whole process of building and encourages
continued learning through documentation and community resources.

    I chose this article as I usually did my front-end work
based on html, CSS and JavaScript while learning how to use react(typescript). Vue.js
seems to decrease a lot of jobs of adding things, especially fact that it helps
with performance and Seo optimization route which must be taken in
consideration making the website. Also, with the fact vue.js is more
lightweight than other frameworks like angular and react and heard a lot about
ease of use, so I thought I need to give it a try and this article was the best
introduction of how vue.js works.  Ending
with some interesting state management library with different coding then other
ways. With the current knowledge that I got, I expect to apply this knowledge
by organizing my projects around reusable components, using lifecycle hooks
more intentionally for initialization and cleanup, and relying on Vuex when
managing complex state across multiple parts of an application. Not only that, I
plan on trying to make a website just using things I learned about vue.js in
this article and trying to compare with other plan html,css, javascript that
brings in library, another one built out of React typescript( a basic one that I
have built as test) based on performance, lightness, seo etc for the long run.

 

https://medium.com/@phamtuanchip/an-introduction-to-vue-js-understanding-the-framework-and-getting-started-d0ad0f3a6c01

 

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.

Cohesion and Coupling

In this blog post, we will highlights some important details between Cohesion and Coupling. The definition of the two concepts can be difficult to understand at first, but then it is helpful to imagine a picture of how elements are interconnected, leading to further understanding as Cohesion and Coupling are correlate to each other.

In the blog summary, first of all is how they clarify the complicated definition of these two concepts. Cohesion is about how elements belong together, but it does not depend on the number of connections between elements, which is what coupling is all about. The blog post also shows the pictures that helps us imagine of how loose and tight the elements are, which can be ideal when figuring out the correct way to organize module. In other words, it should leads to high cohesion and low coupling. And finally is how to sum up to the point that why high cohesion does not only make the system easy to understand and change, it also reduces the level of coupling.

I personally choose this post because it is helpful to understand how to apply these two concepts carefully. In object-oriented programming, for example when making a class in Java, we should know when we declare too many properties that could make the class ultimately “do everything”. For example, declaring a bookstore class that do the following properties: add, remove, sale, and receipt. As we create multiple properties like this, we notice that there are properties shouldn’t be necessary, such as sale and receipt, and instead should break down into each individual class. That’s what affect the cohesion, where breaking each properties into each individual class will promote higher cohesion and lower coupling. Therefore, we call each classes a cohesive class.

This concept of Cohesion and Coupling also makes me imagine of how to organize properties in one class that looks easier to maintain. In my experience, not always when declaring a class is a cohesive class, as I can’t determine if some related properties in that class should breaks down into new classes. Therefore, it’s difficult to maintain for larger projects, making it look complicated at a glance. What I learned about these concepts is helpful to me so I can visualize how I should organize classes and properties, by applying the definition of cohesion and coupling, as high and low for each can affects future maintenance and for the overall functionalities of the project.

Source: https://blog.ttulka.com/how-cohesion-and-coupling-correlate/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

CS343-01: Fourth Quarter

Interface, Not Implementation Programming

According to what I recently learned, programming to an interface and not an implementation is one of modern software development’s “most powerful design principles.” And this is a key to building some flexible, maintainable, and professional software systems. In this blog, I’ll go over the key characteristics of this idea.

To understand this idea, the source says that programming to an interface and not an implementation is about separating what the program does and how it accomplishes the tasks it’s performing, or will be performing. The primary characteristics include abstraction over specificity, decoupling components, enhanced flexibility and extensibility, ease of maintenance and testing, and finally, polymorphism and reusability.

Abstraction over specificity means that when programming to abstractions (like interfaces), the behaviors should be without detailing the exact implementations taking place. “This approach allows for multiple implementations that fulfill the same purpose but differ in internal workings.” 

For a note: coupling in software design is where it measures the interdependence between modules or components which indicates how much they rely on each other. Low coupling is desirable. The second characteristic is Decoupling components. This means that those components become less dependent on specific implementations that cause loose coupling. “When components are decoupled, they can be easily replaced or modified without impacting other parts of the system.”

Enhanced flexibility and extensibility is where the developers introduce the new functionalities significantly changing the code and they can also swap out different implementations that “adhere to the same interface.”

Ease of maintenance and testing is the fourth principle or characteristic of “Programming to an interface, not an implementation.” This is where the testing can become simpler since the interfaces now allow for creations of mock or stub implementations. “This isolation helps developers verify each component’s behavior independently, supporting faster maintenance cycles.”

And finally, the last characteristic is Polymorphism and reusability. This is where the objects are more interchangeable, which in turn, enhances the polymorphism when focusing on interfaces. It leads to reusable code which helps a lot when the same interface can also support different implementations for various scenarios it could encounter.

This is important to know since these principles are applied to different programming paradigms. Programming paradigms are fundamental styles or approaches that are used for structuring and writing computer programs. They’re like blueprints when building a building except with problem-solving. And “programming to an interface and not an implementation” is often associated with Object-Oriented Programming, OOP, one of the different types of programming paradigms. Some of the other paradigms that this principle can be applied to are functional programming or FP and procedural programming.

Source: https://medium.com/@Masoncoding/programming-to-an-interface-not-an-implementation-024d01815070 

, ,

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-02: Quarter Four

The Vulnerabilities of Git

We use Git for a lot of things from collaborative projects to personal ones. So security threats are a topic that must be taken into account on any given day, especially for important projects. And in the article posted in July 2025, there are seven distinct security vulnerabilities that had been added, all that affect prior versions of Git.

The first of these vulnerabilities of Git is CVE-2025-48384. This includes that while reading a configuration value, Git will take off— or strip as the article says— trailing two things: carriage returns or CR and line feed or FR characters. “When writing a configuration value, however, Git does not quote trailing CR characters, causing them to be lost when they are read later on.” The article mentions how if something called a symlink exists between the stripped path and the submodule’s hooks directory, then it’s an opportunity for an attacker to “execute arbitrary code through the submodule’s post-checkout hook.”

A symlink, upon further research is also known as a symbolic link or a soft link. It’s a special computer file which refers to either another file or a directory by storing a path to it. This makes an alternative access path which doesn’t duplicate the content of the target. These links can break if the target is either moved or deleted.

The second vulnerability is called CVE-2025-48385 which happens when a repository is cloned and (optionally) Git can fetch a bundle. This allows the server to offload a porting of the said clone to a CDN or Content Delivery Network. The client of Git in this situation does not validate the advertised bundle or bundles properly which allows for “the remote side to perform protocol injection. When a specially crafted bundle is advertised, the remote end can cause the client to write the bundle to an arbitrary location, which may lead to code execution similar to the previous CVE.”

There is also a Windows only vulnerability which is a CVE-2025-48386. This is where Git uses a credential helper to authenticate the request when an authenticated remote is cloned. One of these credential helpers is Wincred which uses Windows Credential Manager to store credentials, but it also uses the content within a static buffer. This static buffer’s content is used as a “unique key to store and retrieve credentials. However, it does not properly bounds check the remaining space in the buffer, leading to potential buffer overflows.”

There are also vulnerabilities in Git GUI and Gitk, some of which are specific. CVE-2025-27613 and CVE-2025-27614 are for Gitk. CVE-2025-27613 is when running Gitk in a specifically crafted repository, Gitk can write and/or truncate arbitrary writable files when running Gitk without additional command-line arguments. CVE-2025-27614 is when the user is tricked into running a gitk filename where the filename has a very specific structure and they may run arbitrary scripts that are provided by the attacker.

Over all, always upgrade to the latest version.

Source: https://github.blog/open-source/git/git-security-vulnerabilities-announced-6/ 

, ,

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.

The Power of Linters

For my final self-directed blog of the semester, I decided to dive deeper into linters and their function. In class, we had briefly gone over linters, specifically their use to correct non-inclusive or problematic language. This is useful when creating any form of documentation because we want it to be as neutral and non-problematic as possible. I found a blog post from Codacy regarding information about linters, their benefits and drawbacks, and some popular linters for different programming languages.

The article starts by detailing the history of linters, they were created by computer scientist Stephen C. Johnson in 1978 as a tool used to find errors within written code. The name was a reference to the lint trap in a dryer, which was designed to catch the unwanted lint in the machine during the drying process. The linter is a useful tool for static code analysis, which is the process of examining errors in code before executing the code. According to the article, linters can help find “coding errors, stylistic inconsistencies, bugs, violations of coding standards, and potential security vulnerabilities.” It does this by checking your code against a predefined set of rules.

The benefits of linting are that it will reduce the number of errors written into code, it creates a consistent standard for coding practices, and can help improve the objectivity of code. Some argue that the downsides of linting include too many false positives and can negatively affect the performance of programmers in the early stages of development. However, it is generally accepted that linting is a useful tool and is adopted by many development teams.

Prior to this course and the activity we completed in class, I was not aware of linters or what they could do. Most of my code errors over the years would get cleaned up by the debugger in my IDE or by any error messages that came up upon execution. I was not aware of this as a tool that I could use in my development. Though I do not program often, or plan on pursuing it as a career path, I enjoy learning about all aspects of the field. The next time I have to do any kind of programming project, I will be adding a linter to my IDE so I can have a more consistent program with less errors. I enjoy learning more about all aspects of the field to become a more well-rounded academic and professional.

, ,

Source Article: https://blog.codacy.com/what-is-a-linter

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Writing Clean Code

Clean code is about writing software that humans can easily read, understand, and change. Not just about making something that compiles and runs. The main idea is that code should communicate clearly to other developers so the intent of each part is obvious without needing to dig through the entire project or guess what the … Read more

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

Learning Front End in a Microservices World

This week we learned a lot about front-end development. Working through the microservices front-end activities (MS07–MS09) really helped me understand what the front end is all about. As a CS student who loves full-stack development, the activities offered a structured approach to seeing how a front end fits into a bigger system rather than just … Read more

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

Best Practices for Naming REST API Endpoints

For my fourth blog, I read “Best Practices for Naming REST API Endpoints” from the DreamFactory blog. The article goes over why having clear and consistent endpoint names makes a huge difference when you’re building a REST API. It talks about keeping things simple, using nouns instead of verbs, and organizing paths in a predictable way so the front end always knows where to send requests. After doing last Thursday’s activity in class, this article made even more sense because we actually saw the front end using the backend endpoints in real time.

The article explains that endpoints should describe resources, not actions. So instead of naming something /createGuest, the path should be /guests and the HTTP method determines what happens. That lined up exactly with how our project is set up. When we ran the front end with Vite and used the Lookup page, the browser sent a GET request to /guests/:id. When we registered someone, it sent a POST to /guests. Seeing those requests in the Network tab felt like watching the article play out right in front of me.

In class, we also looked at the front end state diagram, which shows the Lookup page, the Not Found modal, the Registration page, and the Registered modal. Each button or action sends a request to the backend. The article helped me understand why that flow works smoothly the backend has clean, predictable endpoint names. If the paths were messy or inconsistent, the front end wouldn’t know what to call, and the whole flow would break down.

When we opened the developer tools and watched the requests being sent, it was easy to follow what was going on because everything was named clearly. GET pulled data, POST created a record, and PUT updated it. The article talks about how important this kind of consistency is, and now I get why. It’s not just about writing code that looks nice. It’s about making the API something the front end can rely on without confusion.

I picked this article because it connected perfectly to what we did in class. Seeing the front end interact with the backend made the concepts feel real. The article basically put words to what we were experiencing: clean endpoint design makes everything easier for developers, for debugging, and for keeping the system logical as it grows.

My main takeaway is that backend decisions show up everywhere, even on the front end. Good naming makes the whole system easier to understand, and after Thursday’s activity, I see how important that is when everything starts working together.

Link: https://blog.dreamfactory.com/best-practices-for-naming-rest-api-endpoints

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

Understanding Software Licensing

Software licensing is a crucial part of the software development process. It is vital to establish a license to set the legal precedent for the work that can be enforced. This blog post from “Click Up” focused on different types of licensing and monetization models.

Software licensing outlines the terms under which a program can be used, shared, modified, or accessed. Different licences can have more restrictions or more freedoms than others.

Types of Licenses from the blog

Propriety: Commercial-based, normally only gives access to use the software and does not allow any further rights. An example is Microsoft Office.

Open Source: Gives large rights for modification, sharing, adaptation, and selling of further forms of software. Some examples are GNU GPL and MIT.

Free and shareware: Freeware can be used for free but may have limited features. Shareware is software that has a free trial version to push the user into buying the full version to either access all the content or continue allowing usage. An example of this is the Adobe suite.

The blog also outlines potential terms of monetization for software and the main forms being used. The types are

Perpetual: One payment with complete ownership of the software. Maintenance may be a separate plan

Subscription: Lower upfront and user-decided cost, but recurring cost with less control and no complete ownership for the user

Usage-Based: Monitor consumption and charge based on usage. Requires metering

Pay-for-overage: User pays base fee and more if they exceed a threshold of usage. Often used in conjunction with usage-based or subscription

Device: Restricts to one or a certain paid for number of paid-for devices

Concurrent/Floating: After paying, you have a set number of uses for the software

I chose this topic due to the coverage in class on licensing topics. While we mainly covered why licensing is important and what the main types are, I wanted to learn more and look into what the other forms of application are. It was good to be able to learn more about how people work to monetize their programs and work through their licenses. One of the biggest things that I learned from the blog and to consider in my future works is in terms of licensing. While I would normally favor open-source for my own projects, in a work environment, I know that the revenue stream from the software must be considered. I now have a greater understanding of potential licenses to consider with software and what the user will be getting when they pay. I found perpetual licenses to be most appealing, and then pushing updated forms to the users or simply selling new yearly versions, as was done in the past with software before switching to a subscription-based model. This is due to my desire to have the user still owning the software while not needing a constant internet connection.

Works Cited:

Team, E. (2024, September 28). Types of Software Licenses and Models Explained | ClickUp. ClickUp. https://clickup.com/blog/types-of-software-licenses/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.

REST API Design

For this blog, I chose the blog “REST API Design Best Practices Guide” from PostPilot. I chose this resource because our course directly works with REST API, focused on backend development, and how different software components communicate through REST API. Since REST APIs are one of the most common ways to build websites, I felt it was important to reinforce what I learned in class about how to work with REST API.

The blog explains the core principles behind REST, including having a stateless server, a client server relationship, caching, and interfaces. It then goes into the basics for building APIs that are easy to understand. One of the first practices it suggests introduces designing resource based URLs using nouns instead of verbs and making them simple and plural such as users or orders. It also emphasizes the importance of properly using HTTP methods, like GET for retrieving information, POST for creating data, PUT or PATCH for updates, and DELETE for removal. The guide goes deeper by discussing when to use path parameters versus query parameters, especially for filtering data and explains why good responses help developers with context and confusion.

Something I found especially insightful was the explanation on versioning and error handling. The blog explains why APIs should include versioning so that future updates don’t break existing clients. It also explains why providing consistent and descriptive error responses are important so that developers can debug what went wrong rather than guessing. It also talks about security requirements such as using HTTPS and authentication tokens, as well as using tools like Swagger to make the API easier for other developers to use.

This blog improved my understanding after reading it, I’ve noticed that good planning and design are crucial, especially when multiple people use the same system. I noticed that the HTTP method already conveys the idea, so keeping endpoints focused on resources makes everything cleaner.

Hopefully, I can apply what I learned in future API work, particularly when working with backend development. This blog’s information will definitely be helpful when designing good and useful APIs rather than messy and unreadable designs. This blog has made me more aware and informed of how important API design is, not just for functionality but for maintainability and ease of use. Reading this guide along with that I’ve picked up in class gives me a strong foundation to understanding REST APIs, if not at least be a little more informed on the topic..

https://www.postpilot.dev/blog/rest-api-design-best-practice-cheat-sheet

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