Category Archives: Programming

What is up with Error Codes for HTTP Methods

Photo by Vie Studio on Pexels.com

Hello Debug Ducker here, and I have a question. I am sure you are familiar with a 404 error code, as you may have run into it while surfing the web. 404 Not Found means that the server on the other end couldn’t find what it was looking for, and this is cause the URL is not recognized. This can happen when the webpage is no longer available and you tried connecting to it. 404 is quite the common error, that I believe many have seen at least once but would you be able to tell me what other errors you may have encountered in the web, there is quite a few and some obscures ones you may have never seen.

Perhaps you also wondered why 404 is even an error number, why the number is the way it is, why use those specific numbers. Well you see 4xx is specifically for client errors, which means they are errors on your end and not the server. If a server would to have an error than it would use 5xx instead. For example, there is the 500 error code that is an internal server error which just means something messed up in the server and sent you that as a response. Basically each response code are in different categories, with the error categories coming entirely from 4xx and 5xx.

Now here are ones you know and some obscure ones

400: Bad Request, as in the server could not process the request, either because of a syntax error such as misspelling something

402: Payment Required, says what is on the tin you need to pay, not often used

409: Conflict, the request conflicts with something within the server

414: The URI too long, the URI is long and the server is not willing to handle it

418: I’m a teapot…yeah I don’t understand this one, and yes this is real

There are many of these errors code for 4xx and I would recommend you check it out with the link below.

There are also some 500 server errors, that are interesting such as

501: Not Implemented, as in the request has not been implemented, so exactly what it says

503: Service is Unavailable, just means the server are down.

And Many More.

Thre are a fascinating amount of error codes for some interesting stuff and I reccomend you see a bunch in the link below.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Anyway have a nice error free day day.

MozDevNet. “HTTP Response Status Codes – HTTP: MDN.” MDN Web Docs, developer.mozilla.org/en-US/docs/Web/HTTP/Status.

“HTTP Status Codes: All 63 Explained – Including FAQ & Video.” Umbraco, umbraco.com/knowledge-base/http-status-codes/#http-status-code-categories.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Week 14

We have collaborated on the backend for the last few weeks. It is the central workload of our work, so I wanted to find an article about it. It very much intertwined with what were doing in class and outside of class with the homework. It is a great opportunity to see other people’s experiences working in the back end and real-life experiences. You can understand more things that we didn’t dive into the class by doing research and expanding our knowledge. That is why this week I found an article that specifically goes into detail about backend development.

The article starts by mentioning the importance of the backend and how it’s often overlooked because most of the spotlight is on the front end. The back end is like what is under the hood of a car you are happy when it works without having to open the hood. That being said the front end and back end work in tandem it’s not always necessary but for this scenario yes. The front is more the user-facing elements of a website. Like the text that is being displayed, graphics, buttons, and or anything the user interacts with.While the backend focuses on the behind-the-scenes work to make the website function. Outside of a car is the front end and its engine and other components are the back end. The backend is important to complete any user request by being safe and efficient. Security and efficiency are key processes of the backend for the user experience. This is why both backend and frontend developers must work in unison to create successful applications. The main importance backend developers should go for is innovation. Technology is always evolving and people must adapt to it becoming stagnant won’t be successful in this field.

Reading this article made me understand more about backend development. Backend development has so much more to it with data and security. It makes sense because security is often overlooked at times. The more information is stored online the more we have to make the effort to secure people’s data. Nobody will want to use your application if there is a breach of security. My main takeaway was their statement about innovation. Their final message to the reader was a hopeful one stating that a developer must change with the times because they are in the epicenter of it. Technology goes far out including healthcare solutions that might not be important to some but are highly integral to a lot of people.  

https://www.ciat.edu/blog/understanding-backend-development/

https://www.ciat.edu/blog/understanding-backend-development/

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

Semantics Antics

Recently, I came across an interesting blog post titled “A Beginner’s Guide to Semantic Versioning” by Victor Pierre. It caught my attention because I’ve been learning about software development best practices, and versioning is a fundamental yet often overlooked topic. The blog simplifies a concept that is vital for managing software releases and ensuring compatibility across systems. I selected this post because, in my current coursework, semantic versioning keeps appearing in discussions about software maintenance and deployment. I’ve encountered terms like “major,” “minor,” and “patch” versions while working on team projects, but I didn’t fully understand their significance or how to apply them effectively. This guide promised to break down the topic in a beginner-friendly way, and it delivered.

The blog explains semantic versioning as a standardized system for labeling software updates. Versions follow a MAJOR.MINOR.PATCH format, where:

  • MAJOR: Introduces changes that break backward compatibility.
  • MINOR: Adds new features in a backward-compatible way.
  • PATCH: Fixes bugs without changing existing functionality.

The post emphasizes how semantic versioning helps both developers and users by setting clear expectations. For example, a “2.1.0” update means the software gained new features while remaining compatible with “2.0.0,” whereas “3.0.0” signals significant changes requiring adjustments. The author also highlights best practices, such as adhering to this structure for open-source projects and communicating changes through release notes.

Reading this blog clarified a lot for me. One key takeaway is how semantic versioning minimizes confusion during development. I realized that in my past group projects, we sometimes struggled to track changes because we didn’t use a structured versioning approach. If a teammate updated a module, we often didn’t know if it introduced breaking changes or just fixed minor issues. Incorporating semantic versioning could have streamlined our collaboration.

I also appreciated the blog’s simplicity. By breaking down each component of a version number and providing examples, the post made a somewhat abstract topic relatable. It reminded me that software development isn’t just about writing code but also about maintaining and communicating it effectively.

Moving forward, I plan to adopt semantic versioning in my personal projects and advocate for it in team settings. Using clear version numbers will make my code more maintainable and professional, especially as I contribute to open-source projects. If you’re looking to deepen your understanding of software versioning or improve your development workflow, I highly recommend checking out Victor Pierre’s blog. It’s a quick, insightful read that makes a technical topic approachable.

Resource:

https://victorpierre.dev/blog/beginners-guide-semantic-versioning/

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.

Learning Git Part 1

CS-348, CS@Worcester

During the semester, it took me a while to understand git. I had to break down the concepts. Then, I started from there. I learn this way because I play games for my hobbies. These include fighting, MOBA, and card games. In these games, you learn how actions have trade-offs. You understand the actions you take or need to take.

While I was learning git, I wanted to learn it differently. I aimed to approach it like how I would learn fighting games as a small experiment. 

In my personal time, I would try to learn the purpose of git. I want to understand why it is necessary for programmers. In my interpretation, git is used for programmers to share and change code. Git can also be used locally on your computer. This way, you can manipulate your version of the code without altering the main repository.

Then I would spend time trying to understand what are the core tools needed in git. I went from learning the concept of git to the primary tools. Understanding the building blocks of code is better with knowing what it does. 

I try to learn from my mistakes when I study coding or fighting games. I analyze why it was a mistake. In my opinion learning through mistakes, especially in coding, is because coding mistakes can happen constantly. If you know why then it will be easier to fix that mistake in the future. Just like learning in fighting games, people constantly make mistakes. Once they understand why they made those mistakes, they can focus on what to do differently. They can then avoid making the same mistake in the future. 

From the blog CS@Worcester – Site Title by Ben Santos and used with permission of the author. All other rights reserved by the author.

Enhancing Development with Software Design Patterns

“Design patterns represent common software design problems and well-tested solutions to those problems.” This is a line from my class’s first exercise introducing us to design patterns. In it we learned that in order to have scalable code, certain types of solutions, design patterns, are used. They are the culmination of previous developers’ struggle adding functionality to already existing code.

When we learned about design patterns in class and the homework, we handled singleton, strategy, simple factory design patterns. This GeeksforGeeks article adds onto the classwork by first separating their list into Creational, Structural, and Behavioral types. Creational patterns address when objects are made by separating how the object is formed from how it is implemented. Included in this type are the Factory and Singleton patterns we had already seen as well as new patterns called the Prototype, Builder, and Abstract Factory patterns. Under the Structural category are methods that handle class/object composition, so they utilize inheritance and help to structure efficient interfaces or implementations. Here they included the Adapter, Bridge, Composite, Decorator, Facade, Proxy, and Flyweight patterns all brand new to me. Finally came the Behavioral patterns that at first brush sounded like it was primarily focused on solely on the responsibility of objects and classes but actual include how these objects and classes communicate with each other. In this section returned the strategy design pattern along with Observer, State, Command, Chain of Responsibility, Template, Interpreter, Visitor, Mediator, and Memento patterns. At the end of this article is an FAQ section where they explain things such as how you can compare algorithmic solutions to design patterns in terms of computational solutions and structural solutions.

I chose this article because it showed me an entire new category of design patterns that tackle interface creation, something that I personally find to be a weak point in my understanding of OOP design. I actually clicked into the Bridge design pattern because it allows for abstraction and implementation to be developed separately. So when you have multiple subclasses of subclasses, their example used ProduceBus and AssemblyBus under the Bus class under the Vehicle class, you have an issue any time you wish to modify the middle level (Bus) class. The Bridge pattern says to separate the Produce and Assembly bus implementations into their own subclass of an interpreter called Workshop that works on objects of the Vehicle class. This way changing the Bus class doesn’t directly change how the Produce and Assembly portions work, which thus saves time.

I have thus bookmarked this page so that until I can pull these patterns from memory I can make use of these numerous proven solutions. It is an amazing resource since it has links to more in depth explanations of each design pattern so that readers can truly grasp just how these tricks work in practice.

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

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Discovering Design patterns

Hello Debug Ducker here again and have you ever thought about how your code is structured? I mean you probably have been doing simple code etiquette, but have you ever thought about how you could make it less say more manageable and neater to save yourself the trouble

Here is an example of a code design on UML from a programming assignment

The basic gist of this is that we are making ducks and applying qualities to them. As you can see there are different types of duck especially my favorite the rubber duck. But I am sure you can see a problem with this. Despite them being all ducks, not all the attributes of a duck can apply to certain ones as shown with decoy duck and rubber duck. Their quack and fly methods would be different, So we have to override them to do something else. This can get tedious especially if we were to add more ducks. Also makes the abstract class feel pointless because of this. So this is where Design Patterns are implemented

Instead of overriding the fly and quack methods in the different types of ducks, we add functions that can apply the behaviors themselves without needing to modify methods within ducks. The Relevant design pattern here is known as Strategy Pattern, and that’s when we get into the real meat of things. 

Design Patterns as the name suggests are designs that programmers can utilize to fix certain problems in their code, whether it’s readability, managing the code, or streamlining a process. Strategy Pattern is the design pattern that splits the specifics of a class into other methods, such as the example of the fly and quack behaviors which were originally a part of several other ducks with different qualities. This helps us whenever we want to add a duck with a different behavior, one of the behavior methods could be applied. There are several other design patterns out there such as factory design which creates objects through what called a factory method, for example, if the rubber duck method is made then an object with rubber duck qualities will be made

Here is code of an example of what a factory method would look like

There are a lot more patterns to choose from that can help you with all your coding problems. Geeksforgeeks has a great article explaining them and even more of the patterns to show

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

Design patterns can be useful for many coding problems, whether It’s to restructure your code to make working on it easier or refactor it to make the functionality better. I can see myself using theses whenever I would encounter a problem.

“Software Design Patterns Tutorial.” GeeksforGeeks, GeeksforGeeks, 15 Oct. 2024, http://www.geeksforgeeks.org/software-design-patterns/.

Guru, Refactoring. “Strategy.” Refactoring.Guru, refactoring.guru/design-patterns/strategy.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

How Much Formatting is Too Much?

https://www.steveonstuff.com/2022/02/09/nitpicky-code-reviews-are-are-drag

This post from Steve Barnegren discusses his issues with the current state of team code review. Specifically, the blog takes time to point out the issues with being overly obsessive about nice formatting. It is one thing to point out flaws in logic and potential failures the system may have, giving feedback on how it might be improved or fixed, and another to, for example, say a ternary operator should be used instead of an if-else. The argument is made that a majority of ‘formatting issues’ of the variety I’ve given do not give enough value for the time they take between maintainers and developers.

Personally speaking, I like to have my code in a very consistent format. If just one thing is in a different format, it seriously bothers me. It wasn’t until recently when I started working on a project as a member of WSU’s Computer Science Club that I personally had to work in a team larger than two people, and in doing so I found out pretty quickly that many people do not hold the same standards to their code.

One team member very specifically does not care at all about how the code is formatted, focusing solely on efficiency and output. At the beginning of the project, I gave pushback on this, believing that the code he was writing was very poor if we wanted to maintain standards, but I was assured it wasn’t a big deal. All of us were working on different parts of the project and generally were disconnected from one another until it came time to connect things. I specifically was on my own creating the GUI of the project. However, the issue finally came when it was time for me to start working on the backend. What I found was a disaster, not in terms of functionality necessarily; there were definitely errors in output, but that wasn’t my concern. The real disaster was the cleanliness of the code. Trying to figure out what was going on, how things were calculated, what and where things were stored, it was a lot of tracing. 

By the time I finally understood what was going on, it took me very little time to do what was asked of me, but the process to get there should not have taken that long. The person who originally wrote the backend is now working to create extensive documentation so that way people don’t have to go through that process again. If there had been consistency in the formatting of the code, clear demonstration of how things functioned, and precautions taken to make sure things did not get out of hand, I feel it wouldn’t have been nearly as bad. 

Although I hear this blog’s thoughts, I hear them echoed in the person who originally said it wasn’t a big deal. In my opinion, the condition for a team to have code reviews like the one Steve recommends must be that all team members already agreed and showed the capability to write code that is clean and makes sense, or else you get the horror I had to go through. Generally, I think code reviews should be unique to every team, because the same rules don’t work for everybody, and that the nitpicks have their place in teams.

From the blog CS@Worcester – CS ZStomski by Zachary Stomski and used with permission of the author. All other rights reserved by the author.

Code Review

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

This article is titled “What is a code review?” As clearly stated by the title, the article explains the processes of code reviewing. “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Code reviews help in the identification of bugs, increase the overall quality of code, and enhance understanding of the source code. Code review, as suggested in the name, happens after a software developer has finished coding. Code needs to be checked before it is merged into an upstream branch for bugs or conflicts. A code reviewer “can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, two experts should review the code.” Adhering to a solid code review process allows for continuous improvement of code and aims to ensure that faulty code isn’t being implemented for customers/users to see and use. This process isn’t just important for the code itself, but also for all of the team members of a software development project. Whilst reviewing the code, meaningful knowledge of the source code is shared between team members to ensure that it is being implemented properly. The main benefits of the code review process are: the sharing of knowledge, discovering bugs earlier, maintaining compliance, enhancing security, increasing collaboration, and improving code quality. Code reviews allow for maintaining compliance because different developers have different backgrounds and thus different personal processes when they are developing. Code reviews allow these people to get together and maintain a standard coding style. Security is enhanced because “security team members can review code for vulnerabilities and alert developers to the threat. Code reviews are a great complement to automated scans and tests that detect security vulnerabilities.” There are many benefits to code review, but there are some disadvantages, including: longer time to ship, focuses being pulled from other tasks, and large reviews mean longer review times. These can be described as necessary evils due to the sheer amount of positives that code reviews offer in software development.

I chose this article because it was published by GitLab, a software that we are heavily using in class for version control, and I thought that it would be interesting to read this specific topic from the syllabus. Version control softwares such as GitLab allow code reviews to happen, so diving deeper into the topic in an article published by this popular software company was tempting. Before reading this article I understood that code reviews were important to pinpoint any bugs or difficulties before merging code into the upstream, but I never really thought about the implications of security or different development styles. I’ll definitely keep this information in mind during future code reviews on the job to remind myself that bugs aren’t the only important thing during a code review.

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.

Why Git

Why is it always git

Photo by RealToughCandy.com on Pexels.com

The version control system that every programmer uses. Even in my computer science class, we had lectures dedicated to Git, the commands in Git, how Git is used, what Git is used for, and just so much Git. The funny thing, is there are other version control systems such as Mercurial, but they aren’t ever brought up they are there but feel overshadowed by git. So the question I am asking now is why Git. So I did some investigating.

The question: what does Git do that is so special compared to other version control systems? Now version control systems can do all sorts of things such as allowing developers to see what has been changed, enable collaborative work, and branch and merge changes to a repo. If multiple can do this, then what does git do differently? An article from Geeks For Geeks lists several. Git can be worked on offline and is resilient because multiple developers can have copies of the repo, and any local repo can be used to restore a project. It also comes with conflict resolution that’s allows one to handle merge conflicts by providing tools to solve those problems. So what about the other systems. Well, GFG got that covered. Here are some comparisons.

Subversion

Compared to Git, the architecture is centralized, one single central repo

Fewer branching and merging options

Better performance

Mercurial

Smaller community compared to Git

Not as much flexibility as Git

Perforce

Can handle very large code base

Not as flexible as Git in terms of merging

Git is Open Source and Free, while Perforce isn’t

That is a decent amount of reasons to use Git over other VCS. I think the community part is important for such a popular system, because if you aren’t too familiar with the commands that come with Git, then you have a lot of people that can help. There are a lot of forums and articles about Git tools out there if you ever need it.

I also feel that the collaborative aspect of Git is, very helpful. A lot of projects have a lot of people working on them, so having something like Git that can handle it and make the task easier is great. Also, the fact that it is accessible helps with that too.

Git being so popular makes a lot of sense now, accessibility, community, and collaboration are what a lot of developers require, and I have to say Git provides that well.

GeeksforGeeks. (2024, September 19). Git vs. other version control systems: Why Git stands out? https://www.geeksforgeeks.org/git-vs-other-version-control-systems-why-git-stands-out/

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

AI Is Not A Software Engineer

In this blog, the author discusses how much the times have changed for new CS graduates. Reminiscing about how little they knew and how easily they got a job. Then talks about how much more prerequisite knowledge is needed to even sniff a job. The topic of the article is how now more than ever it is easier to get code that works. Thanks to AI, code is now more plentiful than it ever was before. However, all code is not good code. This leads to them discussing how despite how much code there is these days. Having people capable of understanding and able to build software are still very necessary. 

Although AI can now code for us, the coding wasn’t the hard part in the first place. The hard part was building software, and making good software. It’s easy to throw a bunch of code snippets together that accomplish something. But it is something entirely different to build specialized software that fills certain functions and meets certain criteria. AI cannot replace people, even though it may take away some jobs. At its heart, AI cannot build unique software. Teams of capable developers are still needed. The nature of how people code is changing. It’s becoming more important to be able to harness AI, but still oversee and build functional software.

I chose this article because I think it relates to team building. Like the article said, you need people who can understand code, not so much write it. Writing code is easier than ever, but finding people who understand how to build software is harder than ever. When using these tools it’s important not to rely on them too much. Discerning who can actually code these days is probably one of the most important skills for employers these days.  I think it’s important for me and everyone to keep in mind that AI is a tool. Tools dont make up for lack of knowledge. Tools are used best by people who know how to use them and maximize their use. One tool can’t solve every single problem. At the end of the day, knowledge is the most important part of being a software developer. 

Citations

https://stackoverflow.blog/2024/06/10/generative-ai-is-not-going-to-build-your-engineering-team-for-you/

By Charity Majors

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