Category Archives: Week 13

Week 13

We started to work in the front end I became more curious about front-end developers. They are often the key if someone will even use a website to begin with. You can have a fully functional site but if it isn’t engaging it can lose people. In the past, this wasn’t something you had to deal with but there are so many things taking people’s attention that just doing the bare minimum isn’t enough. There are things that we don’t even think about that are key to a successful website. A main common feature now is dark mode if a website doesn’t come with this theme it can scare away users. Even simple things like where the search bar is placed are key for the navigation through the site. This week I decided to find information about front-end developers and how they achieve success.

The article starts by explaining what a front-end developer does. They create the graphical layout of a website or application. Front-end workers are usually hired by someone looking to build a website. They can create a site layout to give the buyer an idea of what their website could look like. It can save people a lot of money and hassle if their vision can reasonably be imagined by a front-end developer. A front-end developer’s main focus should be to place everything to benefit the user it should be simple and intuitive for the user. There are several job opportunities in this field from working in industry or having the freedom to be a freelancer. This is a job that offers a lot of challenges but with critical thinking, a solution can always be found. Many big companies hire this position including Microsoft and Meta are always looking for new front-end developers.

Reading this article showed me a new field in this space. There are many fields in Coding there are so many I find a new one every year. This field uses different coding languages including HTML, CSS, and javascript to name a few. I liked how this was a problem-solving job that there has to be actual decision-making need to be successful. This is a job that is engaging while trying to engage others to use your product. The key for a great front-end developer would probably have to be to not forget about the little things. This article reassures that keeping a user-friendly UI is the key to having a successful website.

https://www.coursera.org/articles/front-end-developer

From the blog CS@Worcester – DCO by dcastillo360 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.

Connecting “Copyrights in AI” to Copyright and Licensing Homework

In the rapidly advancing world of artificial intelligence (AI), the intersection of technology and law has become increasingly complex. One of the most pressing legal issues is how copyright laws apply to AI-generated content. This is exactly what the article, “Copyrights in AI: Legal Overview” from HackerNoon offers, the author discusses the implications of copyright laws in the context of AI, focusing on whether AI can be considered an author of creative works, and how this impacts the rights of those who use AI to create content.

The article provides a clear overview of the current state of copyright law as it pertains to AI. Traditionally, copyright laws have protected works created by human authors, but with the rise of AI-generated content, it led me to ask: “can an AI be considered an author in its own right, or does the copyright belong to the human who programmed the AI, or the user who directed its output?” I learned that, under current law, AI cannot be considered an author in its own right, and the copyright typically belongs to the human creator or the user of the AI. This reflects a fundamental principle that we explore in our class, especially when considering software licenses. For example, when choosing a license for a software project, it is essential to understand the ownership of contributions and the rights of the contributors.

I selected this resource because the legal implications of AI are an area of particular interest to me, especially as AI continues to grow in influence and application across various industries. In one of my other classes, Computing Ethics, we talked about the ethical responsibilities and legal dilemmas surrounding the use of AI. The context being medical fields or business, how would the use of AI affect the users using it. This article connects those themes by highlighting the legal aspects of AI usage and authorship, which I had not fully considered before. It helped me understand that as AI technology becomes more sophisticated, the law may need to adapt to address new challenges.

By exploring “Copyrights in AI: Legal Overview” and reflecting on the licensing aspects discussed in my homework, I have gained a deeper understanding of how AI-related legal issues intersect with software licensing. In our Copyright and Licensing Homework, we focus on understanding different licensing models and the implications they have on the use and distribution of software so understanding who owns the rights to AI-generated works is critical to deciding how those works can be shared, modified, or distributed.

I expect to apply this knowledge when working with software projects, ensuring that the terms and conditions of any AI tools or systems used are clearly defined. As AI continues to grow in capabilities and its integration into software development increases, I believe this knowledge will be essential to navigating the complex legal landscape.

Link to the resource: HackerNoon article: Copyrights in AI: Legal Overview

From the blog SoftwareDiary by Oanh Nguyen 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.

Code Security First: Tackling CVEs in Your Development Workflow

In the ever-evolving landscape of cybersecurity, Common Vulnerabilities and Exposures (CVEs) are publicly disclosed security flaws that pose a significant risk to software systems. These vulnerabilities, if left unchecked, can be exploited by malicious actors. Developers, therefore, play a critical role in defending their code against known CVEs, ensuring secure software development from the very first commit. The article “Defending Your Commits from Known CVEs” explores a tool that developers can use to safeguard their work, integrating security seamlessly into the development lifecycle. This blog post reflects on the key insights from the resource, what I’ve learned, and how I plan to apply these practices in my future as a software professional.

The article emphasizes the prevalence of open-source components in modern projects and warns about how these components can add vulnerabilities to your project. This article particularly stresses the use of the tool Git Guardian Software Composition Analysis to catch CVE’s before they are added in a commit. Git Guardian SCA is a vulnerability scanner made by Hacker News to catch risks early.

I selected this article because it connects directly to our course discussions on open-source development and using Git. Understanding how to mitigate CVE risks is essential in order for us to be modern developers, and this article provides a useful tool to enable us towards this goal. It also touches on the use of open-source software.

From this article I learned that the open-source movement has a profound place in current development. It blows my mind that 96% of current projects have open-source components and that anywhere from 70% to 90% of any given modern software is open-source components. I don’t know if I should be happy that the world is working together so much or sad that apparently a lot of software development is not as much coding as I initially thought. It also explained how you can automate the tool’s use with Git hooks which was a new resource that I was introduced to. It allows the developer to automatically trigger actions at different points of gits execution.

Going forward I will be much more vigilant in using any piece of open-source software since apparently a large number of those projects could be using CVE’s. I will also try to expand this vigilance to the rest of any future teams I am a part of. I will probably also look into making my own tools to integrate with git hooks.

link to the article :
https://thehackernews.com/2024/05/defending-your-commits-from-known-cves.html

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.

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.

What is Clean Code?

Once you’ve moved past coding your first “Hello World” and learned some foundational concepts, your programs will naturally grow more complex. Without proper structure, they can quickly become cluttered and hard to follow. To avoid this, it’s crucial to keep your code organized, readable, and understandable—not just for yourself but for others you’ll collaborate with as a professional programmer.

This is where learning about “clean code” becomes essential. Writing clean code focuses on maintaining consistency, clear formatting, appropriate line counts, and effective use of comments, whitespace, and methods. To deepen my understanding, I read an article called “A Deep Dive into Clean Code” on Codacy.com, which explores principles and methodologies that help developers write better code. Here are the key takeaways I learned from the article that could help other studious coders out as well:

1. KISS (Keep It Simple, Stupid)

Simplicity is key. Avoid unnecessary complexity to make your code more readable and maintainable. Simple solutions are easier to debug, modify, and adapt, reducing the risk of introducing errors during updates or when new developers join the project.

2. DRY (Don’t Repeat Yourself)

Eliminate redundancy. Repeated logic scattered throughout the code increases the chances of inconsistencies and bugs. By consolidating repeated logic into functions, methods, or classes, you streamline updates and make the codebase more efficient and maintainable.

3. SRP (Single Responsibility Principle)

Each class or function should serve a single purpose. This modular approach makes code easier to test, debug, and update. With clear responsibilities, changes in one part of the code are less likely to cause unintended effects elsewhere, ensuring stability and flexibility.

4. Meaningful Naming

Descriptive names for variables, functions, and classes make the code self-explanatory, reducing the need for excessive comments. Clear naming improves communication and helps everyone on the team quickly grasp the logic and purpose of each component, especially in collaborative projects.

5. Improved Testing and Maintenance

Clean code principles directly enhance testing and maintenance. With organized and readable code, bugs are easier to identify and fix. Additionally, by minimizing technical debt, you can adapt the code for future features or changes without major overhauls, ensuring long-term project sustainability.

Incorporating these principles into your coding practices leads to better software and a smoother development process for everyone involved. By focusing on simplicity, eliminating redundancy, maintaining clear organization, and using meaningful names, you not only make your work easier but also set the stage for collaborative success.

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