Category Archives: CS-343

The problem with old GPU supply

CS-343, CS@Worcester

As we all know, graphic cards have been getting more expensive over the years. This is because of tariffs and product costs. As a result, gpu manufacturers need to increase prices. They do this to break even from the costs of production. We also have to consider that many graphic card chips originate from TSMC. This company is a semiconductor manufacturer. It supplies Nvidia and AMD gpu chips. These gpu chips are being made in Taiwan. They are finished being built in other factories around the world. Consequently, tariffs would apply to these products due to the tariffs on China’s products being exported to the U.S.

The next issue with these products is the increased cost in prices. It just becomes not worth it for average consumers to purchase these products. Currently, Nvidia, AMD, and Intel want to sell their newer products. These products are better than the current graphic cards in the market. They offer a performance increase ranging from 10%-20%. Living expenses are high, so many consumers have not being able to buy the current gpu’s in the market. During the holidays, they aimed to cut prices significantly. Their goal was to sell as many units as possible before launching the new products. 

According to the rumors AMD is going to try to sell the new gpu’s in different quarters in 2025. While Nvidia is trying to sell their new gpu’s separated time between the next low tier product. I believe they will not try to change this. It has worked by lowering stocks in the market. Consumers would either have to wait for the product they want or get the best one initially. 

For AMD new gpu’s are apparently going to have improved FSR by significant margins in comparison to RDNA 3. Let me explain further FSR is called FidelityFX Super Resolution. It is a program that will render games at higher quality frames. Additionally, it boosts the performance of the graphic card. AMD uses software like this to compete with Nvidia’s DLSS (Deep Learning Super Sampling). DLSS does the same thing for Nvidia graphic cards but performs way better. In some cases, it achieves around 30% better performance and image quality in frames. There is a gap between them because Nvidia created a gpu with DLSS first. It was able to refine DLSS more and more since the rtx 2000 series cards. 

Currently Nvidia gpu’s are more expensive due to using DLSS as the main feature to sell their gpu’s. Nvidia does not want to sell increased performance. If they did, it would cost too much to produce enough gpu’s to meet market demand. They increase the performance of cards by 10% to save on production costs. They improve DLSS by 20%-30%. This makes consumers not consider the base performance difference between previous generations gpu’s.

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

What is Vue and Why is it Popular?

Link to blog: https://medium.com/js-dojo/how-is-vue-js-making-the-javascript-world-a-better-place-b3dc39ba4fe7

It’s the end of the semester, and the last thing we covered in class was a bit of front-end structure and how things work. Of course, there’s your HTML and CSS, and I understood that. But we were using Vue in our examples, and I got curious. I’ve heard of Vue before but never used it, so I was interested in its purpose. Such curiosity led me to Fotis Adamakis’ blog post How is Vue.js making the Javascript world a better place. We’ll be discussing the contents of this article today.

Adamakis’ blog post is quite in-depth compared to past articles we have covered. He believes Vue is quite beginner-friendly, as learning how it works and beginning to write code could only take a couple of days to a week (as long as you have some knowledge of Javascript, HTML, and CSS). Adamakis dives into some interesting parts about Javascript frameworks and how Vue approaches them.

Routing can be a potential challenge when it comes to tasks such as custom scroll behavior, nested route view mapping, and more. Vue has its own Router, and it configures the routes before any components are rendered. 

Vue’s approach to the architecture of a site supports component-building. To be more efficient, it includes single-file components. This is a beneficial feature of Vue, as it can contain HTML, CSS, and Javascript all in a single file. Adamakis also mentions Vue’s high satisfaction rating, with the majority of developers wanting to use it again! 

Adamakis mentions that Vue is great for testing too, as it has built-in support for Mocha and Jest unit testing or end-to-end testing with Cypress or Nightwatch. 

Adamakis concludes by stating that he feels Vue has combined all great parts of other Javascript frameworks into one, being easy to use with great documentation.

I selected this resource because it educates me more on why Vue is so popular and what it does well. It also has example videos to highlight the reasons and is well-written and easy to understand.

I found this to be a solid article for learning more about Vue and why it’s preferred. I also learned how Vue’s state management works. It’s interesting that with Vue, you can incorporate HTML, CSS, and Javascript into a single file. Perhaps it’s beneficial for the simplicity or organization of different web pages/parts of a page? Having all of the pieces of a component on one file is probably quite helpful. I hope to apply this to new web pages I might try and build (I would like to get more into building websites!).

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Backend Architecture

Back-end architecture serves as the backbone of modern web applications, enabling ideal and flawless user interactions and efficient data management. The Codecademy article “Back-End Architecture” provides an insightful overview of the fundamental components and design principles that make up the back end of web systems. It summarizes the key takeaways from the article, reflects on its relevance to software development practices, and outlines its implications for aspiring software engineers.

The article begins by explaining the primary purpose of back-end architecture to manage the behind-the-scenes functionality of web applications that the user can’t see. It underlines the importance of servers, databases, and APIs in creating a solid infrastructure. This is what the article key topics covered:

  • Servers: These handle requests from the front end and deliver the necessary responses. The article discusses server setups like dedicated, shared, and cloud servers.
  • Databases: Central to storing and retrieving data, the article explores relational databases (SQL) and non-relational databases (NoSQL), emphasizing their use cases and advantages.
  • APIs: Acting as the glue between the front end and back end, APIs enable seamless communication between various components of an application.
  • Scalability and Security: The article addresses the importance of designing scalable systems and implementing robust security measures to safeguard user data and maintain application performance.

One reason I chose this article is that we are currently learning about REST APIs in class. I wanted to deepen my understanding of how APIs are used in developing web applications and their role in back-end systems. As a Computer Science student, I aspire to build more complex projects in the future where I can apply this knowledge. The article’s clarity and engaging presentation made it both interesting and easy to understand, which further motivated me to select it as a resource.

Reading this article deepened my understanding of how back-end systems operate and how they connect with front-end components. One key takeaway was the example it provided about how a client makes a request to the server. The article gave a detailed yet digestible explanation of this process, which was different from the visual and interactive activities we did in class. For instance, the explanation of what happens during a client’s GET request clarified the flow of communication between the client and the server, making the concept more relatable and easier to grasp.

What I learned from this article will help me approach back-end development with confidence. For my upcoming project, I plan to focus on designing a system that effectively integrates APIs and databases. Ensuring scalability and security will be a priority to make the application robust and user-friendly. These insights will serve as a foundation for building more complex projects in the future.

Source:
https://www.codecademy.com/article/back-end-architecture

Citation:
Codecademy. (n.d.). Back-end web architecture. https://www.codecademy.com/article/back-end-architecture 

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

Enhancing Development with Software Design Patterns

“Design patterns represent common software design problems and well-tested solutions to those problems.” This is a line from my class’s first exercise introducing us to design patterns. In it we learned that in order to have scalable code, certain types of solutions, design patterns, are used. They are the culmination of previous developers’ struggle adding functionality to already existing code.

When we learned about design patterns in class and the homework, we handled singleton, strategy, simple factory design patterns. This GeeksforGeeks article adds onto the classwork by first separating their list into Creational, Structural, and Behavioral types. Creational patterns address when objects are made by separating how the object is formed from how it is implemented. Included in this type are the Factory and Singleton patterns we had already seen as well as new patterns called the Prototype, Builder, and Abstract Factory patterns. Under the Structural category are methods that handle class/object composition, so they utilize inheritance and help to structure efficient interfaces or implementations. Here they included the Adapter, Bridge, Composite, Decorator, Facade, Proxy, and Flyweight patterns all brand new to me. Finally came the Behavioral patterns that at first brush sounded like it was primarily focused on solely on the responsibility of objects and classes but actual include how these objects and classes communicate with each other. In this section returned the strategy design pattern along with Observer, State, Command, Chain of Responsibility, Template, Interpreter, Visitor, Mediator, and Memento patterns. At the end of this article is an FAQ section where they explain things such as how you can compare algorithmic solutions to design patterns in terms of computational solutions and structural solutions.

I chose this article because it showed me an entire new category of design patterns that tackle interface creation, something that I personally find to be a weak point in my understanding of OOP design. I actually clicked into the Bridge design pattern because it allows for abstraction and implementation to be developed separately. So when you have multiple subclasses of subclasses, their example used ProduceBus and AssemblyBus under the Bus class under the Vehicle class, you have an issue any time you wish to modify the middle level (Bus) class. The Bridge pattern says to separate the Produce and Assembly bus implementations into their own subclass of an interpreter called Workshop that works on objects of the Vehicle class. This way changing the Bus class doesn’t directly change how the Produce and Assembly portions work, which thus saves time.

I have thus bookmarked this page so that until I can pull these patterns from memory I can make use of these numerous proven solutions. It is an amazing resource since it has links to more in depth explanations of each design pattern so that readers can truly grasp just how these tricks work in practice.

Link:
https://www.geeksforgeeks.org/software-design-patterns/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Code Smells

In software development, creating high-quality apps requires keeping code neat and effective. The blog “What is Code Smell & How to Avoid It” provides a thorough review of code smells, which are signs of more serious problems in a codebase that may hinder readability, performance, and maintainability despite the fact they are not errors. The blog carefully explains the definition of code smells, their most prevalent kinds, and practical solutions. It is a great resource for learning how to maintain high-quality code because of its structured approach.

Code smells are indicators of design flaws in a program, which might result in technical debt and vulnerabilities down the road. Tight timelines, inadequate evaluations, or insufficient experience are frequently the causes of them. Typical examples include excessive parameter lists, overly long functions, incorrect naming standards, and duplicate code, all of which make the codebase challenging to maintain. Along with highlighting smells like middle-man classes, data clumps, and primitive obsession, the site provides practical guidance on how to spot and address each. In order to prevent code smells, the blog highlights techniques such as using automated code review tools, implementing continuous integration/deployment (CI/CD) workflows, and regularly refactoring.

I chose this blog because it breaks down the concept of code smells into digestible pieces, discussing each type in depth while linking them to actual solutions. Additionally, the topic strongly reflects our course, Software Construction, Design, and Architecture, which stresses developing maintainable, scalable systems. This objective is directly supported by knowing code smells, which also serve to reinforce the fundamental ideas covered in the syllabus.

As I thought back on the blog and what we’ve learned in class, I realized how crucial it is to proactively find and fix code smells throughout the development process. The emphasis on techniques like refactoring caught my attention since it can be easy to overlook their wider importance beyond tackling immediate issues. Recognizing certain scents like “feature envy” and “primitive obsession,” brought to light how small problems may turn into big ones, affecting collaboration and a project’s ability to grow. For instance, I intend to use the strategy of condensing lengthy parameter lists into objects by grouping related data together. This will make the code in my upcoming projects cleaner, easier to maintain, and easier to read.

This blog improved my knowledge of software architecture and design by relating theory to real-world development issues and helped cement the content we went over in class. By putting the knowledge I’ve received to use, I hope to create software that is more reliable and maintainable, laying a solid basis for my future work in software engineering.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

API Documentation

This week, I decided to discuss Application programming interface (API) documentation. API documentation is essential for developers to understand how to use the API, integrate it into their applications, and fix any issues that arise. The article “How to Write API Documentation: Best Practices and Examples” highlights the importance of API documentation and discusses practical insights into creating a better developer experience.

The article starts with an informative video discussing the API economy, what API documentation is, and how to write it. It also shows some examples. The article moves on to the common issues developers have with APIs, like being too long, too much technical jargon, un-updated, or inaccessible without registration. The author discusses several ways to remedy these issues by emphasizing that good API documentation needs to be user-friendly, clearly explained, and given examples with FAQs or tutorials. One of the strategies presented to accomplish this is called spec-driven development(SDD), where you generate the documentation while developing the API. We are also given several tools to help create and maintain API documentation, like Swagger and Postman.

I chose this article because APIs are discussed and used thoroughly in our course. The appropriate next step was understanding how developers make software accessible to users and, in doing so, become more accustomed to APIs.

Reading this article gave me several strategies to think over and included great explanations for why they are used. I was unaware of strategies like SDD and writing for entry-level users, but they made a lot of sense after reading the article. Creating the documentation after developing API can lead to errors and inconsistent documentation, frustrating developers. Having the documentation evolve with the creation of the API makes more sense. The explanation for writing with entry-level users in mind was great, too. You might think that all software developers understand API documentation, but each developer has their own experiences, specialty, and knowledge. Tailoring the documentation to everyone is impossible, so aiming for clarity at the entry-level will make it understandable for most developers. It is one thing to hear how to improve your documentation, but seeing data on the main features developers want and issues they get frustrated with makes me feel like the strategies will have a greater impact on the users.

In future projects, I plan to use spec-driven development to ensure my API documentation grows with my project, allowing developers to follow along without confusion. I will also aim my documentation at entry-level users so the resource is accessible to most developers.

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

Discovering Design patterns

Hello Debug Ducker here again and have you ever thought about how your code is structured? I mean you probably have been doing simple code etiquette, but have you ever thought about how you could make it less say more manageable and neater to save yourself the trouble

Here is an example of a code design on UML from a programming assignment

The basic gist of this is that we are making ducks and applying qualities to them. As you can see there are different types of duck especially my favorite the rubber duck. But I am sure you can see a problem with this. Despite them being all ducks, not all the attributes of a duck can apply to certain ones as shown with decoy duck and rubber duck. Their quack and fly methods would be different, So we have to override them to do something else. This can get tedious especially if we were to add more ducks. Also makes the abstract class feel pointless because of this. So this is where Design Patterns are implemented

Instead of overriding the fly and quack methods in the different types of ducks, we add functions that can apply the behaviors themselves without needing to modify methods within ducks. The Relevant design pattern here is known as Strategy Pattern, and that’s when we get into the real meat of things. 

Design Patterns as the name suggests are designs that programmers can utilize to fix certain problems in their code, whether it’s readability, managing the code, or streamlining a process. Strategy Pattern is the design pattern that splits the specifics of a class into other methods, such as the example of the fly and quack behaviors which were originally a part of several other ducks with different qualities. This helps us whenever we want to add a duck with a different behavior, one of the behavior methods could be applied. There are several other design patterns out there such as factory design which creates objects through what called a factory method, for example, if the rubber duck method is made then an object with rubber duck qualities will be made

Here is code of an example of what a factory method would look like

There are a lot more patterns to choose from that can help you with all your coding problems. Geeksforgeeks has a great article explaining them and even more of the patterns to show

https://www.geeksforgeeks.org/software-design-patterns/

Design patterns can be useful for many coding problems, whether It’s to restructure your code to make working on it easier or refactor it to make the functionality better. I can see myself using theses whenever I would encounter a problem.

“Software Design Patterns Tutorial.” GeeksforGeeks, GeeksforGeeks, 15 Oct. 2024, http://www.geeksforgeeks.org/software-design-patterns/.

Guru, Refactoring. “Strategy.” Refactoring.Guru, refactoring.guru/design-patterns/strategy.

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

Semantic Versioning

One of the earlier topics we went over in this course was Semantic Versioning and how many companies or groups will use it to keep track of their development. Sometimes shortened to “SemVer,” Semantic Versioning describes a versioning structure that will better communicate “implications of new versions, such as breaking changes, new features, or bug fixes” (Victor Pierre). It allows developers to have some comfort in knowing what changes will be made or have been made and whether there is some level of risk in moving to a new version. This risk lies mostly in software that have some sort of dependency, such as libraries or frameworks as updates to those can lead to dependent softwares having to update some part or most of their work, and the software not working otherwise. 

Semantic Versioning employs a three-part version number in the format, MAJOR.MINOR.PATCH, with each part signifying a different impact of the release.

  • MAJOR: Incremented when making incompatible changes or introducing breaking API changes.
  • MINOR: Incremented when adding new features or functionality in a backward-compatible manner.
  • PATCH: Incremented for backward-compatible bug fixes or patches.

This is the basic structure for Semantic Versioning but there are many more rules to follow and other cases that will slightly change how the format will look (Victor Pierre). More details can be found on the official Semantic Versioning site (https://semver.org). 

When this topic was first introduced, I recognized it and was quite excited because it’s something I’ve seen quite often in the games I play or in other things related to games. The very first thing that came to mind was modding, especially in Bethesda Games. The Elder Scrolls Series and the Fallout Series are some of the most modded games ever, one of the reasons for this is the fact that Bethesda, some time after the release of a game, will implement modding support and tools. I connected Semantic Versioning to how Bethesda will rarely release a major update to Skyrim or Fallout 4, two of the most modded games ever despite how old they are now. These rare updates will cause the modding community to blow up as nearly every modder will have to update their mods in order to be compatible with the new version. After 10 or so years of these rare but destructive updates, many modders have simply stopped updating their mods, moving on to better things or just not caring enough to do so. It’s come to the point in which people have come together to make “downgraders” to play on an older version of the game to have access to a wider variety of working mods. 

That was a bit of a long story but overall, I think Semantic Versioning is simple but intriguing and most of all, extremely useful. I look forward to seeing changes, patches, updates for games and other software that I use and having access to an easy-to-follow log of just further cements my liking for Semantic Versioning. I’m not so familiar with other ways to keep track of development but this seems like a staple for developers and companies, and one that won’t be replaced so easily.

https://victorpierre.dev/blog/beginners-guide-semantic-versioning/

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

DevOps vs. Software Engineering

As I wrap up my last blog for the semester, I find myself still contemplating the career path I’ll take after completing my computer science degree. With so many options available in tech, one question that often occupies my thoughts is whether to pursue a role in DevOps or traditional software engineering.

Both fields are integral to the software development lifecycle, yet they have distinct focuses. Software engineering is primarily about designing, building, and maintaining software systems, while DevOps combines development and operations, emphasizing automation, collaboration, and the seamless delivery of software.

To better understand these roles, I explored the article Developer vs. DevOps engineer similarities and differences from TechTarget. This resource provides a clear breakdown of the responsibilities, skills, and career trajectories associated with both paths.

 Why I Chose This Resource

I selected this article because it connects concepts from CS 343; Software Design Principles . It also highlights the distinct mindsets and tools used in these roles, making it easier to relate the information to my interests and career goals.

What I Learned

1. Core Responsibilities: Software engineers focus on writing, testing, and debugging code, while DevOps engineers prioritize streamlining the software delivery process through automation and operational stability.

2. Skill Overlap: Both roles require proficiency in programming languages and version control systems, but DevOps engineers also need expertise in infrastructure-as-code (IaC) tools like Ansible and Terraform.

3. Collaboration: DevOps engineers work closely with both development and operations teams, emphasizing teamwork, whereas software engineers may work more independently or in smaller coding teams.

One point that resonated with me was how DevOps integrates continuous feedback loops into the development process, improving software quality and delivery speed.

Personal Reflection

Reading this article clarified the complementary nature of these fields. I’ve always enjoyed problem-solving and creating efficient solutions, which aligns with the goals of both software engineering and DevOps. However, DevOps’s focus on automation and system-level thinking piqued my curiosity, especially since I’ve been exploring tools like GitHub Actions in my personal projects.

This resource also reinforced the idea that adaptability is crucial in tech. Whether I choose software engineering or DevOps, learning skills from both domains will make me a more versatile professional. For example, I plan to experiment with IaC tools and practice creating CI/CD pipelines in my future projects.

Final Thoughts

Choosing between DevOps and software engineering is not just about job titles it’s about aligning your strengths and interests with industry needs. This exploration has helped me better understand what excites me about each field, and I feel more confident about preparing for either path.

For anyone considering a similar career decision, I highly recommend the TechTarget article. It’s a great resource for breaking down complex topics and understanding how different roles fit into the broader tech ecosystem.

Resouces:

https://www.gsdcouncil.org/blogs/devops-engineer-vs-software-engineer

https://www.techtarget.com/searchsoftwarequality/tip/Developer-vs-DevOps-engineer-similarities-and-differences

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

How the Frontend and Backend Connect in an API: A CS Student’s Guide

Since we’re diving deeper into web development, understanding how the frontend and backend work together is a must. It might sound like a techy tug-of-war, but it’s actually a smooth partnership—thanks to APIs (Application Programming Interfaces). Here’s how the magic happens, dumbing down.

The Frontend: The Face of Your App

The frontend is what users see and interact with. It’s all about the visuals and user experience. Imagine buttons, forms, and animations—that’s the frontend at work. Developers usually use HTML, CSS, and JavaScript frameworks like React or Angular to build this.

But here’s the kicker: the frontend is mostly clueless. It can show pretty pages, but it needs help to fetch or save data. That’s where the backend steps in.

The Backend: The Brain of Your App

The backend is like the brain. It’s where the logic, data processing, and database interaction happen. Built with tools like Node.js, Python, or Java, the backend handles all the “boring” stuff the user doesn’t see, like authenticating a login or storing a comment.

The frontend and backend don’t just shout at each other directly—they use an API to chat.

The API: Their Translator

The API is the middleman that helps the frontend and backend understand each other. Think of it as a menu at a restaurant(you would know if you read my previous entries). The frontend (the customer) picks something from the menu and places an order. The backend (the kitchen) cooks it up and sends it back. The API defines the rules of this exchange, so everyone’s on the same page.

Here’s how this plays out in real life:

  1. Frontend Sends a Request: The user clicks a button to log in. The frontend sends an HTTP request (usually via POST) with the user’s credentials to the backend API at something like /api/login.
  2. Backend Does Its Thing: The backend gets the request, checks if the credentials are valid, and prepares a response—like a token if the login is successful.
  3. Backend Responds: The backend sends the token (or an error message) back to the frontend in JSON format.
  4. Frontend Updates the UI: If the login worked, the frontend can now display the user’s dashboard. If not, it’ll show an error message like, “Try again, champ.”

Why This Connection Matters

APIs keep the frontend and backend loosely connected, so they can evolve separately. For example, you can upgrade your UI (frontend) without messing with your database logic (backend). Plus, APIs make your app’s backend reusable, other apps can connect to it too.

TL;DR

The frontend is the face, the backend is the brain, and the API is their translator. Together, they create the seamless apps we use daily. So next time you log in, search, or post, know that there’s a whole tech orchestra working behind the scenes. And now, you kind of know how it plays its tune!

References
https://www.geeksforgeeks.org/frontend-vs-backend/
https://medium.com/@adityagaba1322/streamlining-backend-frontend-integration-a-quick-guide-145eca3cca05

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.