Category Archives: CS-343

POST #1

Hi, my name is Abdullah Farouk and this is going to be my first blog post for CS343 class. We are learning about Rest API and I was out this week of class so I thought it would be a great idea to read and learn more about it on my own. I am using a post from free code camp that I found online to reference this, I will post it down bellow for you all to give a read. For those of you who don’t know much about Rest API, I will explain must of what you need to know about it in this post. The word REST stands for representational state transfer and API stands for Application programming interface and if you don’t know what that means, it basically find a connection between programs so they can transfer data. Rest is a software architecture that sets constraints and conditions to how the API is supposed to be used. This lets us interact with the data that is stored on the webservers. Companies love to use REST API for a lot of reasons like it’s effectiveness and how it makes client-server interactions better. The REST API make it easy for us to communicate with the servers by giving us HTTP request methods to use. request methods including GET, POST, PATCH, and DELETE which we saw in our classwork assignments that the professor wrote. GET lets us get the information and read the data. POST is used to create a data, like creating a new client. PATCH lets us update the data that is on the server while DELETE obviously deletes the data. The post that I read, that I will have the link to down below, gives us an example on how to actually use these methods. It is really helpful and I suggest everyone to give a read.

reference article: https://www.freecodecamp.org/news/what-is-rest-rest-api-definition-for-beginners/

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

Week 7: CS-343

Object Oriented Programming Principles

In object oriented programming there are four basic principles: Encapsulation, Abstraction, Inheritance, and Polymorphism. These principles are fundamental such that they are referred to as the four pillars of object oriented programming.

Encapsulation

Encapsulation is hiding or protecting data about a class. This can be achieved by restricting access to public methods. Variables within a class are kept private, while accessor methods are kept public in order to access the private variables.

Encapsulating data helps prevents unauthorized modifications of data by only allowing access to the data using the defined accessor methods. For example, when adding variables to a class rather than accessing/modifying them directly, one would create “getter” and “setter” methods that would still be able to access the data. These methods would allow users the same functionality, but without the risk of undesired changes.

Abstraction

Abstraction is showing only relevant data of classes. Abstraction enables working with high level mechanisms of a class rather than the specific details of implementation, thus reducing complexity.

Picture a system storing different types of vehicles. Rather than creating different concrete classes for each type of vehicle, abstraction can be applied to create one class, ‘Vehicle’, that has the frameworks of basic behaviors and attributes that all vehicles have. These could include methods and attributes such as ‘start()’ and ‘stop()’, and ‘make’ and ‘model’. Then classes for each type of vehicle can be made to extend the ‘Vehicle’ class. Classes that extend ‘Vehicle’ can add specific implementations to the methods and attributes, depending on the vehicle.

Inheritance

Inheritance can be defined as having a “is-a”/”has-a” relationship between a parent class and it’s child classes. The child class derives all methods and attributes from the parent class, enabling reuse of code, but also allowing the addition of unique attributes and methods.

Imagine a system for a college representing faculty and students. A parent class, ‘Person’, is created for common data among all people at the college such as ‘name’ and ’email’. Child classes of ‘Person’ can be created such as ‘Faculty’ and ‘Student’. Both child classes would inherit ‘name’ and ’email’ from the ‘Person’ class, while unique information can be added to each of the child classes. Unique attributes could include ‘gpa’ for ‘Student’ and ‘salary’ for ‘Faculty’.

Polymorphism

Polymorphism can be simply put as reusing code with different types of objects, reducing code redundancy.

Using an interface called ‘Shape’ with method ‘calculateArea()’, different types of shapes can implement ‘calculateArea()’ and change how the specific shape uses the method. For example a square would calculate the area differently than a circle. However, both can still use ‘calculateArea()’ due to polymorphism.

Conclusion

As we learned earlier in the semester, many of us did not have a complete understanding of the four principles above, which is why I chose to learn more about them. After reading the blog, I now better understand the differences and why each of the principles are important. I will be implementing these principles into all future projects.

Resources:

View at Medium.com

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

YAGNI

YAGNI is an acronym for You Ain’t Gonna Need It. It’s a principle from extreme Programming that says that programmers should only add functionality once it is definitely necessary. When coding if you are sure that you will need a piece of code or a feature later on, you don’t need to implement it now. Maybe you wouldn’t even need or add it because you might need something else. This is why you don’t want developers to waste their time creating extra elements that might not end up being necessary and can slow the process. YANGI helps save time and avoid spending time on features that might not be used, the main features of the program are developed better, and less time is spent on each release. When you have a problem that you can’t solve, you won’t be capable of making the best choices when coming up with a solution. On the other hand, when you know what is causing the problem, you can come up with a better plan to solve it. In software development, you can think about creating a system that can deal with everything but would only use a few features and could need attention and upgrades.

YAGNI can be implemented by development teams from small to large, so it isn’t limited to only small projects or large enterprises. This principle can help set up a task list of do’s and don’ts. Always try implementing the selling feature and get the app ready for end users. After the app is functional you can start adding extra features in the next version. Waiting to add any additional features will save a lot of time and effort for developers to help them meet project deadlines. Once your app is live you should keep up with its updates and be able to make the app better. By delaying the app’s updates to add more features can give opponents a chance to take your users. The first version of the app doesn’t need to be perfect, if it can just do the simple things and still fulfill its intended purpose then that is enough. With time you can add in all the add-ons you need later on instead of just cramming it into one version. The you ain’t gonna need it principle is very time effective and efficient for developers so that we could get our projects done on time, not adding anything that isn’t necessary at the time, and make sure that developers don’t feel stress by making sure all of the add on features needed to be added. This principle is time, stress and cost efficient for developers, which is why this principle should be used constantly.

https://www.techtarget.com/whatis/definition/You-arent-gonna-need-it

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

Navigating Software Complexity: The Principle of Least Knowledge (LoD)

In the labyrinthine world of software design, where complexity can quickly become a daunting challenge, a guiding principle emerges as a shining beacon of simplicity and maintainability. This principle, known as the Principle of Least Knowledge or the Law of Demeter (LoD), serves as a valuable compass for software architects and developers. Its primary mission: to minimize dependencies between objects and foster a more modular and maintainable codebase.

At its essence, the Principle of Least Knowledge encourages developers to reduce the interactions between different parts of a software system. This reduction of dependencies simplifies the code and makes it more robust. The LoD suggests that an object should only have limited knowledge of other objects, specifically, objects that are directly related to it. In simpler terms, it advocates for keeping the communication between objects focused and minimal.

By adhering to the Principle of Least Knowledge, developers can significantly enhance the maintainability of a software system. When objects have limited knowledge about other objects, changes in one part of the system have minimal impact on other parts. This isolation of knowledge not only reduces the risk of unintended consequences but also facilitates easier testing and debugging.

As software systems grow in complexity, the LoD remains a steadfast ally. It ensures that each component knows only what is essential for its immediate tasks, fostering a more modular and less error-prone codebase. With the Principle of Least Knowledge as their guiding star, software developers continue to navigate the intricacies of software design, simplifying the path to robust and maintainable systems.

References:

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Semantic Versioning

Have you gone to open an application on your computer and were given a prompt saying your software is out of date?  Some of these messages even tell you what version you are running compared to the latest available.

For example, I opened Notepad++ and received the message above.  You can see I currently have version 8.4.7.0 installed, and the available version 8.5.7.

This is an example of Semantic Versioning.  The article “A Guide to Semantic Versioning” by Suemayah Eldursi (https://www.baeldung.com/cs/semantic-versioning)  clearly breaks down each segment of a Semantic Version. Semantic Versioning is a scheme for labeling versions of software using meaningful numbers to represent what was changed.

Major Update :

The first digit refers to the major updates.

  • Updates that involve changes that break API functionality and are not backwards compatible.  

In my example, you can see the current major update matches the available.

Minor Update :

The second digit indicates minor updates.  

  • Updates include new features that are backwards compatible and will not break anything in the API.  

In my example, you can see the current version is one minor update behind the available version.

Patch : 

The third digit describes the number of patches. 

  • Small bug fixes and changes that don’t add any new features, are backwards compatible, and don’t cause any breaks in the API.  

In my example, the current patch number is irrelevant because of the minor update, however, we can see that there have been 7 patches since the minor update.

Pre-Release and Build :

Semantic Versions may also include a pre-release label and build number.  Pre-release labels, such as alpha and beta, and build numbers would look something like “1.0.0-alpha.4”  These are used to let the user know that it is a pre-release build and may have more use for developers to identify additional version information as needed.

Updating Your Version :

Being able to read a version number is important for users so that they can know what changes have been made to the software or if it’s backwards compatible.  Therefore, updating the version number correctly is just as important.  The article “Introduction to Semantic Versioning“ by Parikshit Hooda (https://www.geeksforgeeks.org/introduction-semantic-versioning/) provides a great illustration that demonstrates what type of update you should choose and what the version number would look like after:

In this example, you can see how a bug fix would only change the last digit from an 8 to 9.  It’s important to note that a minor or major update resets all following numbers to 0.

Using Semantic Versioning Moving Forward :

Maintaining proper documentation of your updates through Semantic Versioning is vital for both the user and developer. As a developer, keeping an organized record of each update and communicating what changes were made to users.

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

CS-343 Week 6

With the constant updates that software can endure, there have been schemes that help track each update. Software versioning is the process of assigning either unique version names or numbers to unique states of computer software. This allows programmers to know when changes have been made and track them. There are several different types of versioning schemes, including name versioning, basic versioning, and internal and external versioning.

Name based versioning identifies software with words and labels rather than a numerical value. This is usually less structured than some of the numerical versioning systems. A basic versioning scheme uses simple, numeric values to track changes. While it is simple and easy to understand, it may not provide detailed information about the nature of the changes with previous versions. Internal versioning, also known as internal build numbers, is used within an organization or for internal purposes to track and manage different iterations. This is separate from external versioning, which is used to communicate with users. The versioning scheme we have started to learn about in class has been semantic versioning. This is a format that I have seen before, but personally did not know much about how exactly the scheme works.

Semantic versioning, also referred to as SemVer, is a versioning system that has the ability to provide a universal way of versioning software development. It is represented by a 3-component number (X.Y.Z) to represent the three different software releases. The Z value indicates the releases for bug fixes, with no functionality changes coming in these updates. Y shows a minor version update where a new functionality is introduced. When increasing the Y value after an update, you must reset the Z value back to 0. The X value denotes a major version, which breaks the current API. It is helpful to split up the different updates that the software endures in this manner so that the user knows the importance of each change.

There are advantages that SemVer brings to software development. It is a fairly simple scheme which provides the ability to track every transaction and help manage dependencies. This also helps the user to identify the risk of taking on the updated packages. It is a very valuable option for version management, especially when it relates to open-source and collaborative development environments.

Semantic versioning and impact of breaking changes in the Maven repository – ScienceDirect

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

The DRY Design Principle

In this week’s blog post, I will be discussing some of what I learned about the DRY design principle from the article “The DRY Principle: Benefits and Costs with Examples” written by The Valuable Dev. I initially chose this particular article because it perfectly aligns with the DRY design principle topic within the syllabus. This article discusses what DRY is, as well as why you shouldn’t always use DRY. I personally found the author’s use of humor to be very refreshing. I feel many of the blogs I have read so far have seemed to be robotic in how they are written.

The article says that DRY is primarily about a repetition of knowledge first and foremost. “Therefore, the logic of this shipment should only appear once in the application. Why? Imagine that you need to send shipments to a warehouse. You need to trigger this behavior in 76 different places in your application. No problem: you repeat the logic 76 times. After a while, your boss comes to you and asks you to change this behavior. Instead of sending shipments to one warehouse, you need to send them to three different ones. The result? You’ll spend a lot of time on your shipment logic since you’ll have to change it in 76 different places! This is a waste of time and a good way to produce bugs to piss your boss off.” The author suggests instead of repeating the logic that you are using, and it would be better to use abstraction to prevent the kind of issues that the example given causes. This would not only allow for changes to be made faster but also minimize the risk of bugs being created because you are only changing code in one area instead of 76 different places.

The author also discusses a situation where DRY doesn’t apply. In this example, the author is working on software for a VOD (video on demand) platform that both filmmakers and content teams would use regularly. The author was considering creating abstract classes to use instead of the current implementation that was being used due to many classes being almost copy-pasted, as well as seemingly having similar utility for both filmmakers and content teams. “In many cases, we knew that the interface would evolve differently in the future. We would have created a lot of conditionals in the controllers’ actions if we had created one set of controllers for both applications. Nobody wants a forest of if statements; the resulting code would have been way more complex. Additionally, the controllers shouldn’t contain any business logic. If you recall the definition of the DRY principle, it’s this knowledge and business logic that should not be duplicated.” As both classes would become more developed in the future, they would differ significantly. If they were made into an abstraction, the code needed for them to work for filmmakers and content creators would have been messy and complicated to manage.

Article: https://thevaluable.dev/dry-principle-cost-benefit-example/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

CS343 Blog Post for Week of October 16

SOLID Design Principles Explained: The Single Responsibility Principle

This week, I wanted to further research software design principles and guidelines. In my past coding projects, there wasn’t any set framework or model I would stick to when writing my code. This led to creating classes that depended on each other too closely, and methods that attempted to accomplish too many tasks at once. To create better functioning software, I’m going to need to learn the best design practices to abide by at the outset of the project.

A popular set of design principles among software professionals are the SOLID design principles. Named by Robert C. Martin, SOLID is an acronym for 5 design principles that lend themselves to efficient, functional software. These 5 principles are:

  1. Single Responsibility Principle
  2. Open / Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. Dependency Inversion

This blog post from the Stackify website focuses on the Single Responsibility Principle and its role in the software development process. Robert C. Martin describes the Single Responsibility Principle as “A class should have one, and only one, reason to change.” Abiding by this principle may help avoid unintended consequences from future updates to the software, as fewer interactions may break as a result of changes to the code.

Even small-scale software projects will likely change significantly over time, and keeping the Single Responsibility Principle in mind will prevent your classes from being encumbered by unnecessary dependencies on each other. If a single class is called upon by many other classes within your software, changes to that class may break the functionality of any classes dependent on that parent class.

Making an effort to keep components of your program independent of one another also has the benefit of keeping your project simple for a human to understand and explain. When a piece of software can be understood by the developer or team of developers working on it, the flow of productivity is so much greater since fewer effort is being spent on deciphering how the software functions. Updates and new features can also be released more quickly and consistently when the structure of the program is easier to modify without compromising the interactions between its components.

Abiding by the Single Responsibility Principle does not mean only creating classes with a singular function, however. This approach can lead to the same problem of too many classes becoming dependent on a singular parent class, and unnecessarily complicates the structure of your program.

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

The Vital Role of Documentation in Programming (Week-6)

Programming, for the uninitiated, may seem like a realm of arcane symbols and inscrutable logic. But at its heart, coding is about communication. It’s a dialogue between the programmer and the computer. Yet, there’s another layer of communication that’s equally crucial: the dialogue between the programmer and any other human who might interact with their code. This is where documentation comes into play.

What is Documentation in Programming?

Documentation refers to explanations and comments that accompany computer code. These can range from simple inline comments that explain the purpose of a specific line or block of code to comprehensive manuals for software libraries or applications.

Why is Documentation Important?

  1. Understanding the Why and How: Without documentation, another developer (or even the same developer, months down the line) might have a tough time understanding the rationale behind certain coding decisions or the functionality of specific sections of the code.
  2. Facilitating Collaboration: In software development teams, collaboration is vital. Comprehensive documentation ensures that every team member understands the code’s workings, making teamwork smoother and more efficient.
  3. Reducing Onboarding Time: When new members join a project, well-documented code helps them get up to speed faster, understanding the project’s nuances without constantly querying the original developers.
  4. Ensuring Code Longevity: Projects can span years, and original developers might move on. Proper documentation ensures that the code remains understandable and maintainable for future developers.

Types of Documentation in Programming:

  • Inline Comments: These are short explanations placed directly within the code. They can explain variables, functions, or the logic behind specific code blocks.
  • API Documentation: This is vital for libraries or frameworks. It explains the functions, classes, and methods available, along with their expected inputs and outputs.
  • Software Architecture Documentation: This gives a high-level view of the software, explaining the system’s structure, data flow, and more.
  • End-user Documentation: This is intended for the software’s users, explaining how to use the software, highlighting its features, and troubleshooting common issues.

Best Practices for Documentation:

  • Be Clear and Concise: Documentation should illuminate, not confuse. Aim for clarity.
  • Regularly Update the Documentation: As code changes, so should the documentation.
  • Use Tools: Tools like Doxygen or Javadoc can auto-generate documentation, making the task more manageable.
  • Encourage Peer Reviews: Just as code benefits from reviews, so does documentation.

While it’s tempting to think of coding as the solitary act of instructing a machine, it’s fundamentally about communication. Documentation is a testament to this fact. By ensuring that our code speaks clearly not just to computers but also to humans, we contribute to more sustainable, understandable, and collaborative software development.

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

Semantic Versioning

Summary: Semantic Versioning (SemVer) is an essential system for versioning software. This blog post explores its core components, including major, minor, and patch versions. It also delves into pre-release and build parts and how version precedence works in SemVer. At the heart of SemVer lies a structured approach to versioning. It all starts with three fundamental numbers: major, minor, and patch. Each of these numbers carries specific meanings, making them the building blocks of compatibility and change management.

Reason for Selection: I chose this resource because semantic versioning is crucial in software development, and I wanted to gain a deeper understanding of how it works. This is also in line with what we are covering in class and in the development of Thea’s Food Pantry.

Comments on Content: The resource does an excellent job of simplifying the concept of Semantic Versioning. It provides a clear explanation of how version numbers are structured and the significance of each part. I now understand that the MAJOR version indicates major, potentially breaking changes, while MINOR versions introduce new features in a backward-compatible way. PATCH versions are for bug fixes.

One aspect of SemVer that I found particularly enlightening was the discussion on pre-release and build parts. Pre-release versions, marked with a hyphen, are often used to share software informally for testing. They may not be stable and might not satisfy compatibility requirements implied by the normal version. Build metadata, indicated by a plus sign, is used to record information about the build process, like who made the build, build machine, and more. This is especially valuable for tracking software development. I could

Understanding the precedence of version numbers is crucial for managing dependencies effectively. The resource explains that version comparison in SemVer is done from left to right. Versions that only differ in the build part are considered equal. Pre-release versions have lower precedence than their standard counterparts. Numeric identifiers always have lower precedence than non-numeric identifiers. This knowledge has provided me with a better grasp of how to choose the right versions when managing project dependencies.

Personal Reflection: This resource has clarified many of my questions about Semantic Versioning. It has demystified what can be a complex topic, making it accessible for developers at a beginner or intermediate level of experience like my own. Now, when I encounter version numbers, I can make informed decisions about their compatibility and the potential impact on my projects. As a software developer, I anticipate that this knowledge will be invaluable in ensuring the smooth integration of various software components and libraries. It will help me avoid compatibility issues and streamline the process of managing dependencies, ultimately saving time and effort in the development process.

Link: Semantic Versioning Resource

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.