Category Archives: Week 10

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post Week 10

This week, I found a Reddit post from just about a year ago on clean code. The post is asking people basically how they feel about “clean code”, so I thought it’d be interesting to hear some people’s takes on clean code and what they may like or dislike about it. The post links an article, “Goodbye, Clean Code” and while I will really just be getting the Redditor’s thoughts/opinions on the article and their overall takes on clean code, I will still post this article at the end of the blog as well.

The top comment on the Reddit post tries to sum up the article by saying it’s more or less about not passing judgment on someone’s written code without knowing the tradeoffs first. Doing a quick read through of this article confirms this, which I believe is a great point to make. Code may not ALWAYS be the cleanest, but before you go ripping into the structure of it, you may want to try to understand it first. A reply to this comment, which was the most liked reply so probably the most agreed upon point, was that coders should write comments when a line or lines of code are dirty due to a tradeoff. This, I completely agree with. If the code is recognizably dirty and it’s due to something really out of your control, I find it perfectly acceptable to write a comment explaining this so there is no confusion.

Another comment I found, which was within a thread of comments, was talking about “Clean Code” written by Uncle Bob. We learned a lot about Bob’s ideas on clean code during class, which was very beneficial. I will note though, he came across as very strict and stubborn on the rules. A comment in this thread clarifies this though by explaining how Uncle Bob, very early on in chapter one, states that people may “violently disagree” with him and that’s completely okay. So while he may be stern under his own volition, he understands where some people may draw a line.

Reading through all of these comments, I came to realize that while yes, clean code certainly is important, it’s only important to a degree. There are going to be projects where you may not be able to keep the code super clean, and you should then shift focus to keeping it as clean as POSSIBLE, and perhaps commenting on areas where it just wasn’t possible. It also is not the end of the world as some people may make it out to be, if you are unable to keep it extremely clean.

https://www.reddit.com/r/programming/comments/180evou/what_is_your_take_on_clean_code/

https://overreacted.io/goodbye-clean-code/

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

The Importance of Design Patterns for Programmers

The article I chose for my blog entry is titled “Design Patterns” from Refactoring Guru. Design patterns are tried-and-true solutions to recurring problems in software design; they act as adaptable blueprints to guide programmers on how to solve design problems effectively in code. This article introduces design patterns, breaking down what they are, their history, and why they are valuable in object-oriented programming. Additionally, it covers why design patterns have become essential for developers, offering a common language for communicating solutions to complex design challenges.

Refactoring Guru’s article is structured into several sections, including “What are Design Patterns?”, “History of Design Patterns”, “Why Should I Learn Design Patterns?”, and “Criticism of Patterns”. The website offers a straightforward breakdown of why design patterns are essential, teaching programmers how to approach various challenges in object-oriented design. By establishing common concepts and practices, design patterns create a shared language for developers, enabling them to communicate and collaborate more efficiently.

The article also categorizes design patterns into three main types: creational patterns, structural patterns, and behavioral patterns. Each category serves a different purpose in software design:

  1. Creational Patterns – These focus on creating objects in a way that supports flexibility and reusability, ensuring that objects are created efficiently and consistently to allow the project to scale.
  2. Structural Patterns – These organize classes and objects into cohesive structures, making it easier to expand and modify systems. They help parts of a system interact smoothly while staying independent.
  3. Behavioral Patterns – These improve communication and responsibility-sharing between objects, streamlining interactions to reduce complexity and make the system easier to manage.

After reading this article, I have a much deeper understanding of software architecture, especially within object-oriented design. Initially, I chose this topic because I wanted to enhance my understanding of design patterns for a homework assignment. Although we had a class discussion on the topic, I found myself struggling to grasp the purpose of design patterns fully. Learning about the intent behind patterns, including why they are named and applied in specific ways, has helped me see design patterns as as the core in building flexible, maintainable code.

In the future, I plan to use design patterns as a guideline and blueprint for project planning and implementation. I appreciate how design patterns provide a structured approach to problem-solving in software, allowing me to develop systems that can grow and change with ease. Additionally, I value how design patterns enable programmers to collaborate more effectively. By using a shared vocabulary, developers can discuss complex solutions more simply, making teamwork smoother and more efficient.

Overall, this article from Refactoring Guru has not only broadened my understanding of design patterns but also shown me how these patterns are a crucial part of becoming a proficient software engineer.

Sources:

https://refactoring.guru/design-patterns

Citation:

Design patterns. Refactoring.Guru. (n.d.). https://refactoring.guru/design-patterns 

From the blog CS@Worcester – CodedBear by donna abayon 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.