Tag Archives: Quarter-4

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.

Blog Post #4

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.



From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Blog Post #4

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.



From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Using environments to develop software

Different environments in software development, outlining the roles of Development, Testing, Staging, and Production environments.

So you want to get started with developing a piece of software but aren’t quite sure where exactly you are meant to do that. Well luckily for us we have environments created specifically for developing software.

Introduction to development environments

Put simply, it is an environment which provides developers with a workspace that features programming software and other resources and processes required to develop source code for an application.

Some key components of development environments can include:

  • A physical or virtual machine, including an underlying operating system, database system, and so on.
  • Development tools, including development environments, compilers, and libraries.
  • Data management solutions
  • Associated services, including internally hosted resources and external environments, such as those running in the cloud.

Environments must be able to support a few things like:

  • Writing code
  • Debugging
  • Testing
  • Version control

The importance of these environments

All developers can find benefits to using these environments. It helps improve productivity, stability, reliability, and more towards development. The usage of these environments speaks for themselves as to just how beneficial they truly are to software developers.

Integrated development environments (IDE):

An overview of Integrated Development Environments (IDE), highlighting key features like writing, debugging, and running code.

IDEs are a very popular form of Software development environments. Some popular IDEs, a few of which you have almost guaranteed heard of, include:

  • The JetBrains environments (CLion, GoLand, PyCharm, RubyLand)
  • Visual Studio
  • Eclipse
  • XCode
  • Android Studio
A bar chart displaying the most popular integrated development environments (IDEs) from 2004 to 2019, highlighting Android Studio and Visual Studio as top choices.

What makes these environments to attractive is that they are fairly user friendly, with a little practice of course, and paired with the fact that they can be extremely customizable therefore giving a software developer the freedom to focus on other things related to their developments.

Final thoughts

Doing my research in development environments taught me just how many different development environments there are, all useful in their own respective ways, and many open-source as well. I am used to using a few IDEs like Eclipse for Java development or Visual Studio for general development but expanding my knowledge of environments is very useful for specialized projects. If you wish to learn more I would highly suggest reading this article from devzero.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

The art of REST API design

Something I have personally never worked on as a developer is REST API. AWS is a piloting force in the sphere of web development so there was no better place to read up on this subject than there. Going through you can really see why REST API is so vital to the modern web.

An overview of REST API design principles, methods, and benefits, illustrating key concepts for web development.

What is an API?

API stands for Application Programming Interface, this defines the rules you must follow to communicate with other software systems.

API is a gateway betweek:

  • Clients: Users who want to access information from the web
  • Resources: The information that different applications provide to their clients.

What is REST?

REST stands for Representational State Transfer, this is a software architecture that imposes conditions on how an API should work. It was originally created as a guideline to manage communication on complex networks. As a result one architecture developers can use is RESTful API.

Here are some of the principles of the REST architectural style:

  • Uniform interface
    • Indicates the server transfers information in a standard format
    • 4 architectural contraints:
      • Requests should identify resources
      • Clients have enough info in the resource representation to modify or delete the resource if wanted
      • Clients receive info about how to process the representation further
      • Clients receive info about all other related resources they need to complete a task.
  • Statelessness
    • A communication method in which the server completes every client request independently of all previous requests
  • Layered System
    • Client can connect to other authorized intermediaries between the client & server, and it will still receive responses between the server
  • Cache-ability
    • Able to store some responses on the client or on an intermediary to improve response time
  • Code on demand
    • Servers can temporarily extend or customize client functionality by transferring programming code to the client.

Benefits to REST API:

Here are the few of the benefits AWS includes:

  • Scalability
  • Flexibility
  • Independence

How it works:

The basic functions are similar to browsing the internet, here are the general steps towards any REST API call:

  1. The client sends a request to the server
  2. The server authenticates the client and confirms permissions to make request
  3. The server receives request and processes it
  4. The server returns a response to the client.

The client request contains these main components:

  • Unique resource identifier
  • Method
    • GET
      • Access resources at URL
    • POST
      • Send data to server
    • PUT
      • Update existing resources on the server
    • DELETE
      • Request to remove resource
  • HTTP headers
    • Data
    • Parameters
      • Path: Specifies URL details
      • Query: Requests more info about resource
      • Cookie: Provides authentication

Final Thoughts:

My understanding of REST APIs was very limited but leave it to the best in the business to have all the information necessary to learn. I definitely think it would take time to implement nonetheless but having this basic understanding is important in the end. If you want to learn more yourself visit this page on AWS.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.