Category Archives: CS-343

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.

The StackOverflow Problem

The world of Computer Programming is one that is comprised of people from every corner of the globe, from countless different social and economic backgrounds, which has led to one of the most diverse fields of study in the world. Some come from well-established foundations; utilizing the resources at their disposal to create new and innovative products. Many more come from more humble beginnings, forging their own path and transforming the world around them. Yet, across this wide spectrum of developers, researchers, and teachers, they all share one thing in common:

At some point in time, at the beginning of their studies, they had relatively no idea what they were doing.

Sure, this sounds harsh. But it’s true for quite literally every field of study imaginable. No one is born with the ability to write machine learning algorithms, develop web applications, or any other kind of work in the field. At one point or another, this knowledge was learned, practiced, and perfected.

In the world of computer programming, the amount of seemingly trivial yet incredibly difficult problems one may encounter can be quite high. They can often be hyper-specific issues where directly posing the question at hand to your peers may be the most effective way of coming to a solution. And in the modern age of the internet, an incredible medium of getting answers proves time-and-time again to be a rock-solid support for developers: StackOverflow.

Munroe, R. (2023) XKCD. http://www.xkcd.com/979

StackOverflow is a forum made for programmers to post issues and questions related to their work, and to receive answers from other programmers on how to resolve these issues. It can be astonishing how regardless of how niche or specific you think your issue may be, there’s an extremely good chance that someone else had the same problem, posted it, and received multiple different solutions. StackOverflow has the benefit of being powered by the vast workforce of the internet, where millions of people can chime in and offer their assistance. However, therein lies the problem:

The internet can be full of jerks.

Of course, I don’t mean to discredit the vast majority of users who are often incredibly helpful and welcoming to newcomers. The usefulness of StackOverflow and similar sites cannot be overstated. The core issue, in my opinion, is the vocal minority who either through arrogance or simply a lack of tact, can scare away those new to the programming field with a sarcastic attitude and an aura of superiority.

This isn’t just anecdotal either. Nate Swanner from Dice.com writes about how in 2019, after StackOverflow made efforts to convince users to “be nice” to each other, the annual developer survey reported that 73 percent of users saw no change in how welcoming the site was to new users. He acknowledges that while the vast majority of users are able to find answers to their questions, there exists a problem in how the forum treats its fellow developers.

“When you’ve got to wade through a river of ego and spite before being told to ‘Google it,‘ we start to wonder how long people will tolerate a Stack Overflow where a “cultural shift” hasn’t yet taken hold.

While one of my least-favorite things to do is to harp on a problem without offering any kind of solution, I really don’t believe there is one singular fix to this kind of issue. After all, this isn’t a phenomenon exclusive to StackOverflow, or even the Computer Science field for that matter. Sometimes, when we hear a question from someone that to us sounds trivial, our knee-jerk reaction is to think “Dude, really? THAT’S your issue?”

This is the mentality that I believe should be addressed and challenged more often in order to create a more welcoming community. The field of computer programming is growing fast. And there are definitely indications that we’re moving in the right direction. That same developer survey found that users on StackOverflow who were people of color felt more welcome than in previous years, which is a great step forward. However, fields of study are driven by the people who study them. And the more welcoming and supportive these groups are, the more a field will grow.

A quick side note: I hope this post didn’t end up being too philosophical; I had originally planned to write about a completely different topic, however after hearing about some experiences from a friend of mine who has just started his freshman year in a CS program, I felt that this was a topic worth discussing.

Citations:

Nate Swanner. “It’s Not Just You: Stack Overflow Is Still Full of Jerks.” Dice Insights, Dice, 18 Apr. 2019, http://www.dice.com/career-advice/stack-overflow-many-jerks.

From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Embracing Simplicity: YAGNI – You Ain’t Gonna Need It

In the ever-evolving world of software development, there’s a principle that often serves as a guiding light, a beacon of practicality amidst the allure of endless possibilities. It’s called YAGNI, which stands for “You Ain’t Gonna Need It.” This principle challenges developers to adopt a minimalist approach, focusing on what’s essential and avoiding the temptation to add functionality that may never be used.

At its core, YAGNI encourages developers to resist the urge to build features, components, or solutions that are not immediately necessary. It advocates for a “just-in-time” mindset, where development efforts are directed only towards addressing the existing requirements. The rationale is straightforward: speculative or preemptive additions can lead to unnecessary complexity, increased development time, and even bugs. By embracing YAGNI, developers maintain a clear focus on the immediate goals, prevent “over-engineering,” and ensure that the software remains lean and efficient. The principle not only enhances software development but also simplifies the debugging process and ensures that the codebase remains clean and manageable.

While YAGNI is a powerful concept, it’s essential to strike a balance. The key is to avoid unnecessary features but still be open to evolving requirements. Flexibility is vital, and YAGNI shouldn’t be used as an excuse to resist necessary changes. In the dynamic world of software development, simplicity, adaptability, and efficiency remain the true hallmarks of excellence.

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.

Unveiling the Blueprint of Software Architectures: The Foundation of Digital Development

In the intricate world of software development, one essential factor underpins the creation of every digital marvel – software architectures. These structural frameworks are the unsung heroes, the master plans guiding the intricate construction of software applications. They serve as the invisible hand that shapes the organization of an application, defining its key components, the relationships between them, and the fundamental principles that govern their interactions.

Software architectures, though often behind the scenes, are pivotal in crafting software that’s not just functional but also efficient and tailored to meet specific requirements. They’re akin to the architects of a grand skyscraper, ensuring that each piece falls into place seamlessly, resulting in a robust and scalable digital structure.

Understanding the diverse architectural styles empowers developers to choose the right path for their projects. It’s akin to a skilled craftsman selecting the finest tools and materials for a unique creation. The choice of architecture significantly influences various aspects of a software system. It impacts the system’s performance, scalability, maintainability, security, and adaptability to change.

Embracing the versatility of architectural styles is akin to choosing different brushes for a painting. The software architects are the artists, and the blueprint they select is their canvas. As software development progresses, these architectures are not just abstract concepts; they become the very foundation upon which the digital world evolves.

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.

Encapsulation | One of the Four Pillars of Object-Oriented Programming

There are four pillars in Object-Oriented Programming (OOP), one of which is ‘encapsulation’, which refers to the good practice of hiding the inner works of an object and its implementation details, where access is only possible through public methods. As one of the pillars of OOP, it is beneficial to me as a learning programmer to understand about the purpose of ‘encapsulation’ and how it can be effectively applied.

I realized during one of my classes — when we were reviewing these four pillars — that while I knew the principle by name, I had never learned encapsulation in detail nor how to best implement it into my code. Looking back at code I had written in the past, it was clear that I did not always follow this practice (i.e. using dangerous global variables as attributes in my objects).

The blog “The four pillars of object-oriented programming — part 1 — encapsulation”, written by Bas Dijkstra, helped better illustrate for me what encapsulation is supposed to do.

Firstly, encapsulation is all about making attributes private. By doing so, an object’s attribute is protected from being accidentally — or maliciously — altered. Instead of accessing the attribute directly, the value can and should be returned through a public method within the object, essentially making the attribute ‘read-only’.

By doing this, a programmer gains more security and control over the code, reducing the amount of unwanted behavior in the system as a whole.

Secondly, good encapsulation is the product of good design. In another blog, “Encapsulation in Functional Programming”, by Mark Seemann, which I found by looking deeper into the strategies of implementing encapsulation into code, talks about creating a ‘contract’ for each class. The contract outline three properties of a class:

  1. Preconditions — what are the minimal requirements for the object to function?
  2. Invariants — which attributes of the object do not/cannot change?
  3. Post-conditions — what are the boundaries/rules of the object after it is created?

Though the article focuses more heavily on encapsulation for functional programming, the design strategy also benefits OOP. Having these properties outlined in the contract of a class helps the programmer understand not only what needs to be encapsulated, but also how it can be encapsulated.

In addition, because of the nature of encapsulation and the amount of control it provides a programmer over the code, testing for such classes that follow the principle becomes much simpler and easier to do .

While a simple principle, encapsulation is a powerful and practical strategy that makes code secure and easy to manage by hiding the inner works of a class behind public methods.

Sources:

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

about plant uml

One of the reason I like PlantUML is that it forces me to design leveraging a common and standardized framework. It adds a level of formality to the process, which ensures I am conceptualizing my architecture correctly and communicating it clearly with concepts that everyone agrees on. It is a value I learned from the Army: we practices a standard way of making decisions and writing orders. By leveraging a standard modeling language I am not reinventing the wheel every time.

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.