Github has probably been the most useful tool I’ve ever used when collaborating with other team members or co-workers on projects. Even though I have used it for quite some time now there are many resources out there on the basics that still help me in figuring out the tool. One of many that I found was actually on the Github blog itself under the developer skills section which has a guide to a good amount of the basics themselves. Here is a link to just one of the sections relating to pull requests https://github.blog/developer-skills/github/beginners-guide-to-github-creating-a-pull-request/. For anyone new to using Github these guides seem incredibly useful, they include videos, pictures and recaps for everything discussed.

Just recently we went through Github in our CS-348 course and I did end up referring back to this source to help me in getting a refresher and understanding the content better. These guides go through a step by step process in explaining how each of these functions such as pull requests and merging works. Each subsection of explanations also includes pictures and videos themselves to help the reader better understand what they should be seeing when following along with the process. One of the most recent posts in the beginners section also included the setting up and securing of the users profile as seen here https://github.blog/developer-skills/github/beginners-guide-to-github-setting-up-and-securing-your-profile/. This is one of the most basic of the basics that pretty much everyone that uses the internet should know about, but you would be surprised at how many actually do not take this part seriously. Thankfully in this post the author describes the use of 2FA and how to set it up, 2FA is one of the easiest ways to secure your account much better than just using a password. At the end of each of these lessons / posts, the author includes a “Your next steps” section that allows the reader the use of a repository to test with if the lesson declared the use of a repository, or it will point you in the next direction you should take.

Overall this blog is probably one of the most effective ways for someone who is just learning Github to get used to a bunch of the basics. I only found this blog just recently but I much prefer it over a youtube video itself since it guides you through each step with a good amount of detail and it is very easy to go back any time I need to and re-read specific steps or details. Since not all of the basics have been published yet I will most likely keep my eye on this blog because reinforcing the basics if you are not sure about something is always helpful.

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

Anti-patterns are best described as behaviors or approaches to problems that conceptually may help solve the problem, but in practice are a detriment to the process of doing so. In software development, this can come in many forms, whether ‘cutting corners’ by reusing old code or trying to condense behaviors into one class/object. Ultimately these decisions we make as developers come from a place of genuine concern. When these design patterns remain unchecked, they begin to rot in our code and cause many problems, some of which are contradictory to the intention of originally incorporating them.

In the article Anti patterns in software development, the author Christoph Nißle describes several anti-patterns that occur in software development and the consequences of each. Three anti-patterns resonated most with me, as I could see how someone could accidentally implement one of them. The first of which is what Nißle calls Boat Anchor. It represents code that *could* be used eventually, but for the time being, has no relevance to the current program. By keeping this code, the developer is contributing to visual bloat. Not only does this make finding specific lines harder, but once other developers are included on the project they may have questions about how this code will be implemented. To counter this anti-pattern it’s good practice to only keep code that is prevalent to the program’s functionality AND is currently being used by the program. The second anti-pattern I found interesting was Cut-and-Paste Programming. As the title suggests, it occurs when programmers reuse code from external sources without properly adapting it to their current project. This code can also come from the same program. Under both circumstances this code will cause errors, as it’s not a ‘one size fits all solution’, furthermore the code being pasted could have errors. These can be remedied by “creating multiple unique fixes for the same problem in multiple places”(Nißle), but each unique fix requires time and this time could have been spent creating code for the specific problem rather than reusing code. Lastly, the Blob pattern is one that I have personally fallen victim to several times. This pattern has the developer trying to make objects/classes as dense with functionality as possible, but this complexity acts against the single responsibility principle. Classes (and objects) should be solely responsible for one behavior if we include too many then the function of that specific class becomes unclear. The Blob pattern can easily be fixed by dissolving the blob class into several single-responsibility classes. It’s best to catch poor practices such as the Blob early in development to minimize the amount of refactoring that’s needed to fix the code.

As mentioned before, I’ve fallen victim to these anti-patterns as conceptually they save time in the development process. However, the time often saved is eclipsed by the time required to fix errors later in development. Properly following design principles will cause development to require more time, but it should reduce the number of errors that would appear if anti-patterns were used in their place.

Link to Article:

https://medium.com/@christophnissle/anti-patterns-in-software-development-c51957867f27

-AG

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

In our work with REST APIs, namely through the HFOSS project Thea’s Pantry, we have implemented new functionality to the database by updating the HTML specifications and creating new endpoints. During this whole process I did not have a concrete idea of what an API was, nor did I understand what made REST APIs any different from their alternatives. 

In the article What is a RESTful API the authors Stephen Bigelow & Alexander Gillis define what an API is, and what components make an API RESTful, in addition to how they can be used. APIs are defined as “code that lets two software programs communicate with one another” (Bigelow & Gillis). This can be seen through our work in Thea’s Pantry as the specification.yaml file provides instructions for the commands which communicate between the backend and database. In a general flow of control the user interacts with software, this piece of software interacts with the API which then shifts control to the external software. From this point the user can directly interact with the external piece of software (in the cases of methods such as delete and put), or the user can fetch information from it which can be returned to their client-side software. REST stands for representational state transfer, this is a type of software architecture that makes communication between two programs more accessible and easy to implement (Bigelow & Gillis). Users can interact with resources from another program using HTTP requests composed of a method, endpoint, header, and sometimes will require a body. RESTful commands, similar to those of databases (get, update, delete.. etc), can be specified by the developers of the API to have unique functionality. This modularity of command functions is one of the benefits of using RESTful APIs. An alternative to RESTful APIs is SOAP. These both achieve similar functionality, but the methods of doing so are different. For example, SOAP is a communication protocol compared to REST which is an architecture style. SOAP is only compatible with .xml files, meanwhile REST can be used with .xml in addition to other file types. It is worth noting that REST and SOAP are not one-to-one alternatives and can be used together. 

APIs allow developers to extend the functionality of their programs by communicating with other programs. This can be achieved through HTML requests (in the case of RESTful APIs) and nodes (in the case of SOAP APIs). REST APIs favor flexibility and modularity, on the other hand, SOAP APIs are more rigid and require concise specifications. Due to its accessibility, RESTful APIs are more favorable in projects such as Thea’s Pantry. I cannot see SOAP being implemented in Thea’s Panty due to its rigidity as seen through the types of files it uses. REST is much preferred here as we can use javascript files to define the HTML requests that the API will use.

Link to Article:

https://www.techtarget.com/searchapparchitecture/definition/RESTful-API

-AG

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

URLs:
Article on SOLID: https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/
Video mentioned: https://www.youtube.com/watch?v=j-6N3bLgYyQ

One video has always caught my attention because it clearly illustrates why SOLID principles are so important. I will reference two sources in this post for better understanding, in case you want to explore the topic further. However, I kindly ask you to watch the video linked at the beginning for my comments to make sense.

I chose an article to complement the video because it offers a more approachable explanation of SOLID principles and, as stated, explains them in plain English. The video features a dad following instructions from his kids to make a peanut butter and jelly sandwich. The issue here is that such a task may have become so automatic for us that we no longer think about every single detail involved.

How is that related to programming and SOLID principles? Well, it’s quite similar. At its core, code consists of lines and lines of instructions written for a machine to execute. To achieve the intended goal, these instructions must be precise and correct; otherwise, we can encounter numerous issues. As the video demonstrates, the lack of precision in the kids’ instructions led to some funny outcomes: first, the dad stacked two slices of bread on top of each other without doing anything else. In another instance, he ended up with a piece of bread with a “bit” of peanut butter on it, a whole bottle of jelly, and another slice of bread on top.

Did I just make a typo by saying a bottle of jelly was between two slices of bread? No, that did happen. This highlights what occurs when you assign certain instructions—or, in programming, functions (Single Responsibility Principle)—more than one purpose or intent. While a peanut butter and jelly sandwich recipe might not fully embody all five SOLID principles, the Single Responsibility Principle (S in SOLID) alone is enough to demonstrate the importance of clear and focused design in coding.

The lack of clarity and precision in the sandwich instructions led to various unwanted results. Although the instructions made sense to the kids, they didn’t work well for anyone else. Similarly, when writing code—whether for homework, work, or even personal projects—these principles should never be overlooked. I believe following such practices is part of a developer’s ethical responsibility.

At the end of the day, even if I’m the one reviewing my code a year later, I might struggle to understand it without proper adherence to these principles. You might wonder, “How is it possible not to understand what you wrote yourself?” Well, that’s exactly what happened to me yesterday while refactoring some old code. I encountered several parts that I couldn’t make sense of, so I had to revise and apply these principles to make them comprehensible.

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.

Software testing is verifying that a software product performs the way it is designed to.  The benefits of software testing are preventing errors or bugs from being in a program. When doing software testing, it is best to do testing during the start of a build, during the build, and after the deployment or release of a program. Through doing software testing, developers and companies can ensure there are no defects, or issues before releasing or prompting a product. If there are bugs or defects in company products, there is going to be a loss in customers and money. Some of the different types of software testing include acceptance testing, unit testing, and security testing. Acceptance testing is ensuring that a coding program runs and that there are no errors. Unit testing is testing parts of a program instead of testing a whole program. In  Unix systems programming class, I was exposed to unit testing in homework projects, where I had to write parts of a program and receive a grade for each part, and couldn’t move forward until receiving full credit on a part of a program. Unit testing can lead to fewer errors than acceptance testing. It is a better practice to test your code small bits at a time than to run a whole program. Security testing is ensuring that software programs are safe from hackers that could lead to being denied access to your software, or your software working incorrectly.

Software testing was first developed after the ending of world war two. Computer scientist Tom Kilburn wrote the first piece of software by performing mathematical calculations. Debugging was the main testing strategy at the time. By the 1980’s there were other strategies of software application testing outside of fixing bugs and errors. The process of software testing includes determining a testing method to use, developing test cases or setting up requirements for the test, writing scripts or parts of a program, analyzing test results, and writing a report. For large software programs, there are tools used to complete tasks and work on running tests for different tasks, with instant feedback on what works or not works for a program. Through reporting and analytics, teams can present their results in a dashboard, which would allow everyone to see the overall result of a project. Reporting results show how testing the product leads to the result. 

Blog url: https://www.ibm.com/topics/software-testing

From the blog CS@Worcester – jonathan's computer journey by Jonathan Mujjumbi and used with permission of the author. All other rights reserved by the author.

This week, as we’ve been learning a lot more about Git and different features of it, I decided to find an article that talks about different commands that we may have not used and what they do. The article I found titled “Modern Git Commands and Features You Should Be Using” by Martin Heinz, explains some newer(ish) commands in Git that people still may not know about or just hardly ever use.

He opens up with the switch and restore commands but these are commands we’ve already learned about and used, so I’m going to skip over these.

The first one he mentions that I had not heard of is “sparse-checkout”. If you have a large repo with many different individual directories, it can cause certain commands to run extremely slow such as the normal “checkout” command or the “Status” command. With sparse-checkout, you can configure git to only checkout files in a specific directory. You would then use sparse-checkout set to download or checkout that specific directory. As you can see, this would be extremely useful in scenarios where you have a massive repo with a large amount of directories. Being able to specifically select the directories you want, rather than having to deal with all of them on more generalized git commands can be a huge time saver which is certainly a value many programmers hold highly.

Another command he mentions, which I find to be extremely cool and probably one of the most useful commands I’ve seen is “bisect”. Essentially, you run a “git bisect start” command linking a commit that does not work, as well as the last known working commit. Bisect will find the halfway point between these two commits, and you can either say “Good” or “Bad” depending on whether or not the commit is selects works or doesn’t. From there, it will keep on going halfway until it finds the exact commit where the errors that stopped the code from working started. This seems to be an extremely useful and honestly just cool command as it makes the process of finding the issues within a given program a million times easier. It is a command I will certainly be using in the future, probably a lot, and I’m very glad someone was keen enough to actually make this a working command.

Overall, the two commands I spoke about seem to be extremely useful, especially bisect, and I will certainly hold onto them for future reference in Git. Heinz also mentions the “Worktree” command but, while this command also seems quite useful, I found the other two to be much cooler as well as understandable to use. It also opens my eyes to the fact that there are also many other git commands and features that could be utilized, and I’m definitely going to look into the rest of them as I am sure I will find a few more very useful commands.

Source: https://martinheinz.dev/blog/109?utm_source=tldrwebdev

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

This week, I decided to find another Reddit post as the last Reddit post I covered I felt had a lot to take from it as it was a community of people giving their real thoughts and feelings on a certain aspect of Comp Sci. Today, I found a post on the importance of object-oriented design, and people discussing the different values it holds.

One of the top comments on the post is about how understanding object-oriented design is a great foundation for writing clean code, which is something we discuss in CS-348. It isn’t necessarily something you can just learn on the go while working, and, rather something you should try to learn about as much as you can while in school to then apply in the workplace. I’m very appreciative of reading this actually as I typically like to think most stuff gets easier to apply/learn as you’re working, but if a lot of people agree that you should understand as much as you can about object-oriented design BEFORE actually starting a job, then it’s certainly something I’m going to want to have down. The general consensus wasn’t that you won’t get better at applying these principles as you progress in your career but that you should have a strong foundation of knowledge on these principles going into your career as it is crucial to know certain aspects of it, like when one object ends and another begins or how to model object relations.

OOP is so important, many of the Redditors on this post also seem to agree that you’ll find it very hard to even get a job if you don’t at least have a base understanding of the concepts. It isn’t necessarily hard to understand a lot of these concepts as they’re pretty fundamental, but you should be able to answer questions either directly related, or somewhat related to OOP in job interviews as if the interviewer begins to think you may not know what you’re talking about, you may quickly lose your opportunity at that job. Some people did make comments explaining how it does depend on the concept of the job too such as the primary language you’ll be programming in or even the exact role of your job, but the general consensus still seems to be that you want to have at least a strong fundamental understanding of object-oriented design and the ability to apply it’s principles in your coding.

There are over 100 comments on this post that all make great points on why understanding these principles are very beneficial to you, even just a fundamental understanding of them can help you go a long way. It seemed to me that people had varying levels on how important overall understanding all of these principles are, but they all seemed to agree that knowing the basics of them and being able to apply them all to some degree in your coding, as well as being able to understand and talk about them (in interviews especially), is certainly the most important/beneficial thing you could do.

Source: https://www.reddit.com/r/learnprogramming/comments/z2fcyb/how_important_is_object_oriented_design/

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