Category Archives: Programming

Version Control

Source: https://www.spiceworks.com/tech/devops/articles/what-is-version-control/

This article is titled “What Is Version Control? Meaning, Tools, and Advantages.” The main purpose of version control is to “track the progress of code across development and iterations and also aids in managing changes during the life cycle.” Records are kept of all changes with names, timestamps, and other important information. So, the process by which software code is monitored and the way in which changes are made is called version control. A huge benefit of version control is being able to look at the revision history and determine where problems originated from, and who caused them to happen. This allows for increased efficiency regarding workflow considering that the time required to locate problems is greatly reduced. Another benefit of version control is branching. “Branching is a distinct approach to version control where development programs are duplicated for parallel versions of development while keeping the original and working on the branch or making separate modifications to each.” This allows for enhanced collaboration where development is increased, issues are resolved, and code remains organized. A couple very popular version control tools are Git and GitHub. The creator of Linux, Linus Torvalds, created Git. The memory footprint of Git isn’t vast and is able to follow changes in any files. It is a very simple version control system and as a result is used by top companies such as Google. GitHub is a service that enables development teams to collaborate and keep track of all their code changes in a cloud environment. GitHub is secure and reliable, and as a result is also widely used. Through the use of a version control system the following can be achieved: “streamline merging and branching, examination/experimentation with code, the ability to operate offline, creation of regular/automated backups, communication through open channels.” Overall version control aids in the maintenance of reliable code bases and enforces accountability for effective collaborative development. 

I selected this article because we are actively learning about version control in class right now so I figured it’d be the perfect time to read up on it more. Reading the GitKit chapters has exposed me to different git commands and GitHub usage. It was interesting to read in this article about all of the in-depth benefits that version control offers and clearly showcases why even top companies such as Google use it to optimize their workflow. In future practice, whether it be at a job or while working on an individual project, I will use version control to improve collaboration and the ease of maintenance of my code.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Anti-Patterns

Source: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/

This article is titled “Anti-patterns You Should Avoid in Your Code.” It specifically mentions six of them, being: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object. An anti-pattern, in regards to software development, is an example of how not to solve a problem in a codebase. They are not a positive thing, they are examples of practices to avoid in the development process. Anti-patterns lead to technical debt, code that you have to eventually come back to and properly fix later. Spaghetti Code is the most common, it is code that doesn’t have much structure. It is called Spaghetti Code because everything is difficult to follow, files are located in random places, and when visualized in a diagram, it appears to be a jumbled mess, much like spaghetti. Golden Hammer references a scenario where you follow a certain process that doesn’t necessarily align perfectly with the project but still works well enough. This may not seem like a large issue, but is obviously not the best practice to follow because it’ll cause performance issues in the long run. You should always use a process that is the best fit for your project, even if you need to teach yourself or learn something new. Boat Anchor is when developers leave code in the codebase that isn’t actively being used in the hopes of it being needed later and thus not requiring much effort to implement when it is eventually needed. The main problem with this is when it comes to maintaining the code. It leads to the question of what code in the codebase is unused and what is being actively used. Trying to fix a bug in the system on code that isn’t even being used is a time waster. Dead code is code that doesn’t look like it’s really doing anything, but it is being called from many different places. This leads to problems when trying to modify the code because no one is unsure what is actually dead. Proliferation of Code is about objects that have the purpose of invoking a more important object, meaning it doesn’t really do anything on its own. The action of invoking the more important object should be set to the calling object. Lastly, the God Object is an example of an object that does too much. Objects should only be responsible for doing one thing, referencing the Single Responsibility principle in SOLID. 

I chose this particular source because I appreciated the way examples were clearly given along with the 6 examples of anti-patterns, and upon reviewing the syllabus the topic “anti-patterns” seemed interesting. When you’re learning computer science a lot of the time you’re learning about things that you should do and not about things that you shouldn’t do. I really enjoyed reading about these 6 examples of common mistakes that developers make in industry. It’s important to both recognize good and bad practices to ensure that your projects are properly optimized. I can definitely see myself referencing anti-patterns when designing code in the future so my code can easily be maintained. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Was it really all about frameworks?

What’s a Framework? All About Software Frameworks is an article written by Luke Stahl. I found it on dev.to, but it can also be found on the Contentful Blog. Links to both blogs are available in this post. The reason I chose this article is that I’ve heard a lot about frameworks since I started exploring web application development, and they always confused me. I used to struggle to understand what they were and what they were built for. Luke Stahl’s article answered both of these questions for me, though it also left me with a few more.

The article provides a general overview of frameworks for software development, web development, and working with APIs. However, it then pivots toward web development frameworks, which left me wondering about the differences between them. While it clearly explains the distinctions between backend and frontend frameworks, it misses covering some other differences I initially expected.

The author also includes a fairly extensive list of the benefits that frameworks bring to development, along with a brief list of challenges. For me, it’s always a bit concerning when something presents itself with so many benefits and so few downsides. Still, the benefits outlined are appealing and useful for developers.

Frameworks, as explained by Luke Stahl, are essentially blueprints or templates for a particular final product. They provide the essential building blocks and materials required to create your software or web application. A framework offers a skeleton for your application, allowing you to build functionality on top of it.

Halfway through reading the article, I began to wonder about the difference between a framework and a code library. Thankfully, and to my surprise, it seems Luke anticipated this question. He includes an explanation from two outside sources, David Fateh and Alvin Bryan. Both summarize that frameworks act as templates, while code libraries serve as tools you can use to build on top of that template.

One point that caught my attention—and that I believe is very important—is that most frameworks are FOSS (Free and Open Source Software). Being free and open source brings many advantages. Such products undergo extensive testing by a diverse group of programmers, across various applications, which increases the test sample size. This added testing leads to greater reliability, as it helps ensure that any new functionality works as intended. Another benefit of free and open-source products is the large community that often forms around them. This means that if you encounter questions or difficulties, it’s likely that someone else has already addressed them.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

GRASP

Source: https://www.youtube.com/watch?v=GcqTrlL_Htw

This video from YouTube is titled “Design Patterns GRASP // Object Oriented Analysis and Design (ICS).” As stated in the title, it goes over the design patterns of GRASP, or General Responsibility Assignment Software Patterns. GRASP is a set of 9 principles that relate to object-oriented design that help developers/engineers assign certain responsibilities to certain variables, classes, objects, etc. in software. The overall purpose of GRASP isn’t to create “fancy” code, but rather to create maintainable and reusable code/software. The 9 principles are information expert, creator, controller, low coupling, high cohesion, polymorphism, pure fabrication, indirection, and protected variations. “Information expert” places responsibility on classes that have the required information to complete it, wanted behaviors and data are put together. “Creator” places responsibility for the creation of instances of classes to classes that would use it. “Controller” places responsibility for handling system events to a class that describes the event, known as the controller. “Low coupling” states that classes should be as independent as they can be from other classes. “High cohesion” states that classes should have clear purposes with responsibilities that relate to it. “Polymorphism” is implemented so new behaviors can be added without changing preexisting code. “Pure fabrication” states that new classes should be created if there isn’t an already existing one that fulfills a desired requirement. “Indirection” states that dependencies among classes should be minimized so changes can be made without having an impact on other parts of the system. Lastly, “protected variations” encourages developers to design the system in a way that variations in behaviors are negated through encapsulation. 

I chose this particular source because we haven’t covered this topic in class yet and it seemed interesting, I found the topic from the syllabus. This video had a low amount of views and I wanted to give it a chance. After watching the video, I appreciated the fact that the information was presented in a straightforward manner and offered visual examples for each of the 9 principles of GRASP. After learning about Agile methodologies, it was interesting to learn about GRASP, because in my opinion it seems as though instead of being a set of principles of workplace improvement, GRASP seems to be a set of principles for actual work improvement. Overall, the material impacted me in a positive way because I appreciate the idea of everything in a system/software having a certain responsibility, and can definitely see how this will benefit me in the future when I work on more projects related to software development. I will certainly keep GRASP in mind for these future projects. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

The Troubles Of Learning Codebases

Often when joining a new job, you won’t be writing a new codebase from the ground up. Often we’ll have to familiarize ourselves with the preexisting codebase. Sometimes this codebase is old and needs to be updated or refactored. But how should we go about doing this? It is challenging enough to try to learn a new codebase, let alone trying to change or add to it. That’s what the question the article “Reducing The Learning Curve For Supporting Aging Codebases” by Scott Fitzpatrick aims to answer. The articles offer some dos and don’ts when it comes to trying to make it easier to learn a code base.

One of the first don’ts is to not rely on face-to face conversations and messages/email conversations. While these conversations can be helpful for developers in the moment, they offer little for someone trying to learn the codebase. Plus they can be hard to find and subject to deletion. I think the main point to take away from this article is the importance of good documentation and other resources. When it comes to making a codebase easier to understand, not just for newcomers. Having multiple avenues to try to learn from is important. Beyond just looking at the code, things like data flow and entity-relationship graphs. 

Other aspects beyond code are important too. Like good documentation on local environment set-up and system requirements/dependencies. Making these clear not only makes it easier from the newcomer, but also it helps learn about the frameworks and why they were chosen for the project. Knowing why an application uses certain frameworks and projects can help a new developer understand the reasoning and choices of the team.

Learning a new codebase is very challenging for anyone. I think this article offers good insights as to why certain practices are good and why some are bad. This also once again highlights why I think communication is the most important skill for a software developer. Being able to communicate with other developers not only through code, but through documentation is a very important skill. Making the lives of fellow developers easier by finding as many ways to communicate design and ideas. Although most developers hate writing documentation, it is a necessary evil that must be done.

I will definitely keep this in mind when writing code. Of course writing code that is readable takes precedence. But keeping up to date documentation is also vital to keep projects on track. I personally haven’t worked on a large project involving a large codebase before. So I haven’t had to write documentation for something that I didn’t write. Most of the time I don’t feel the need to write what the function or class does because I made it, so I already know. I think that’s a habit a lot of programmers have, that leads to a lot of lack or bad documentation. It’s something that I don’t have a lot of practice in, so its a skill I’ll have to start honing.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Speed Over Design

The following blog I would like to talk about is called “The Hidden Cost of Speed” by Brayden H. Hord. He begins with a quick story about a project he worked on. In this story he describes how he, in an attempt to impress his bosses and meet his co-workers needs, pushed out a product as fast as possible. This worked for the moment. His bosses were happy and he continued his work. However months later, bugs and issues are arriving daily. The software he quickly developed was being used on a daily basis, something he had not anticipated. Now all the shortcuts he had taken earlier had come back to bite him. Now he had something that was being used extensively that was built poorly. 

Now he and his team had to work laboriously to try to fix these fundamental issues. Fixing the problems but also trying to interface between management and stakeholders. The truth is that these problems could have been avoided. If he had better planned and took more time to access the needs and requirements of the project. The moral of the story is that taking time to build right saves headaches down the line. The rest of the blog goes into more detail about why planning and communication are fundamental for all software developers. 

The reason I choose this blog is because I think it highlights one of the most important factors when it comes to software development, Communication. Most software is not built by one person, but rather a team of people. What makes a good team is communication, making sure everyone is on the same page. I think this is important to remember because building without a plan is a recipe for failure. It’s easy to get excited and try to push something that works. But something built on shoddy foundations is always destined to fall. 

Sure your code may work at the moment, but somewhere down the line issues will arise. As needs and more complex architecture is needed, the holes in the code will rear their ugly head. That’s why building code that takes into account not only the needs of now, but also the needs of the future. Building architecture that makes life easier in the future, not harder. I think that this is an important lesson for any software developer to know. Because building something right not only makes your life easier, but everyone else on the team’s lives easier as well.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Understanding SOLID Principles: A Guide 

As a student learning software design, I’ve come across the SOLID principles in a few lectures, but I wanted a deeper dive to really understand how to apply them. I recently read a blog post titled “SOLID Principles — The Definitive Guide” by Midhun Vincent on Medium. This guide breaks down each of the five SOLID principles in a straightforward way, with examples and explanations that actually make sense for someone still new to object-oriented design. The article is totally in line with what we’re covering in my course, so I figured it was a great chance to see how these principles could improve my coding style now and in the future.

Summary of the Selected Resource

The article explains the SOLID principles, which are five key guidelines for designing object-oriented software that is easier to understand, extend, and maintain. The first principle, the Single Responsibility Principle (SRP), emphasizes that each class should focus on a single task, making the code simpler to maintain and update. Next is the Open/Closed Principle (OCP), which suggests that classes should be open for extension but closed for modification, allowing developers to add new features without altering the original code structure. The Liskov Substitution Principle (LSP)follows, which ensures that objects of a superclass can be replaced with objects of subclasses without causing issues in the application. Then there’s the Interface Segregation Principle (ISP), which advises against creating large, general-purpose interfaces and instead encourages smaller, more specific ones that suit the exact needs of different clients. Finally, the Dependency Inversion Principle (DIP) recommends that high-level modules should not rely on low-level modules but rather on abstractions, which reduces dependency and enhances flexibility. Together, these principles form a strong foundation for writing clean, modular code that can handle future changes more gracefully.

Why I Chose This Resource

I chose this post because the SOLID principles are really useful in building better code but can feel abstract at first. The article breaks down each principle in a way that makes them feel practical and achievable. Also, the examples in the post connect well with coding challenges we’ve faced in our course projects, especially in terms of keeping code organized and easy to debug. Seeing how SOLID principles can prevent code from becoming a tangled mess gave me a new perspective on how I approach my own assignments.

My Takeaways and Reflection

Before reading this post, I understood the theory behind the SOLID principles but not really how to implement them in my own code. Now, I can see why each principle matters and how they can actually save time by reducing the need for debugging and refactoring down the line. The Single Responsibility Principle, for example, made me think about how I often give one class way too many jobs, which then makes fixing issues complicated. By applying SRP, I can keep my classes simpler and less error-prone.

Moving forward, I’m planning to use these principles as I work on my projects, especially with the Open/Closed Principle and the Interface Segregation Principle. I can see how they’ll help me write code that’s easier to adapt if requirements change or if I add new features later. In the future, I think understanding SOLID will give me a solid foundation (pun intended!) as I move into more complex software development work.

Link to the Resource

https://medium.com/android-news/solid-principles-the-definitive-guide-75e30a284dea

View at Medium.com
View at Medium.com

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Design Patterns

Design patterns are essential tools for software developers, providing standardized, reusable solutions to common coding challenges. Rather than developing unique solutions every time a familiar problem arises, developers use these templates to write organized, efficient, and adaptable code. Design patterns are not complete blocks of code but instead serve as blueprints, guiding the structure of code in object-oriented programming and enhancing overall project organization.

according to the published article on GeeksForGeeks, the article mentions about A key advantage of design patterns which is reusability. Patterns can be applied across different projects, which saves time and effort by eliminating the need to repeatedly solve similar issues. This flexibility also allows developers to apply patterns quickly in various scenarios, accelerating development. Another benefit is standardization; design patterns create a common vocabulary among developers, which simplifies communication and collaboration within a team. By recognizing these patterns, all team members can quickly understand and follow the structure of the codebase.

Design patterns further promote efficiency by offering solutions that have been tested and refined over time. Since developers do not need to invent new solutions for frequently encountered problems, they can progress faster with fewer errors. Additionally, design patterns are designed to be flexible. They are adaptable templates, meaning they can be customized to fit specific project needs, making them a versatile tool for a variety of applications.

Types of Design Patterns

Design patterns fall into three main categories: Creational, Structural, and Behavioral.

  1. Creational Patterns focus on managing object creation to keep systems flexible and independent of object-specific creation logic. Examples include:
    • Factory Method: Allows creation of objects without specifying the exact class.
    • Singleton: Ensures only one instance of a class exists globally.
    • Builder: Breaks down complex object construction into simpler steps.
  2. Structural Patterns emphasize organizing classes and objects to create efficient, larger structures. Examples include:
    • Adapter: Enables incompatible classes to work together by adjusting their interfaces.
    • Facade: Simplifies complex systems by providing a unified interface.
    • Decorator: Adds extra functionality to objects without altering other instances.
  3. Behavioral Patterns focus on defining how classes and objects interact within a system, streamlining communication in complex applications.

In summary, design patterns help developers produce clear, maintainable, and scalable code. By adopting these patterns, developers can approach recurring problems with reliable solutions, improving collaboration, reducing development time, and creating codebases that are easy to expand and adapt. In the fast-paced world of software development, design patterns serve as a stable foundation for building robust, flexible applications

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

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

Week 18A – Python Testing

For learning about unit testing in C, I consulted this article on the subject: https://interrupt.memfault.com/blog/unit-testing-basics

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below: 

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;
}

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...
  return(0);
}

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.