The
article examines the question, “is clean code by Robert Martin still matters?” From
author’s 16-year coding experience, he writes about reality in writing clean
code and its criticism. He acknowledges that t in the end meeting the deadline
with functional and bug free code is more important then elegant code following
the principle of clean code. However, he argues in the end as a developer,
trying to integrate small aspects of clean code into your code base is going to
make your skill improve as an engineer in the long run even if many people will
not care about it.

I selected this
article as it addresses some uncertainty that I had with clean code. All the
code I have written feels like I got pressure to deliver functional code as
quickly as possible and now I’m supposed to write elegant, maintainable code so
I wanted to see the real live example from experience if clean code was that necessary.
The author’s real-world experience and practical approach toward the subject made
it an interesting topic to delve into deeper.

This article showed
that clean code is not something you have to write all the thing following to
it, it is about finding the right balance between quality code following the
clean code and functional code. I feel like clean code still matters in a bit
as we want to write a code in time but needs to make it modular to be abled to be
easily refactored for later uses. Not only that, this article advice to start
small feels realistic and something I can do to grow as a programmer.  The hierarchy of what matters in the software
part will be my checklist in the future as it is the basic outline of how the
code needs to be structured. When writing code, the working code always comes first,
then make it without bug and if there is bug, you should be able to be fixed
easily then I will try to add instance of small parts of clean code in. I want
to make the code a bit modular because I spent hours trying to refactor code sometimes
and finding which part of the code went wrong took a long time because my code
was always a mess. Therefore, I feel like idea of clean code by Robert martin
is not dead but only small part of it is still alive to become better
programmer. As the most important thing for programming is to make software
that is easy to maintain, adapt and scale.

Article
link : https://tommcfarlin.com/who-cares-about-clean-code/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

A blog that recently caught my attention was GitHub Engineer Sarah Vessels, “How to review code effectively: A GitHub staff engineer’s philosophy”. Vessels focuses on code review every single day which has brought her to create her own strategies for successful code review to ensure we are building good software. Though code review can be done in different ways I selected this blog because it directly involves code review via pull request reviews on GitHub which aligns perfectly with our classwork over the past couple of weeks learning to manage Git properly.  

One large part of Vessels job as a code reviewer is having an open discussion with the author of the code posing questions that may have not yet been considered. The phrase two sets of eyes are better than one comes to mind here as we can very frequently catch other’s coding mishaps, but we might miss our own. The writer stresses that acting as a reviewer for another teammate benefits both parties as the reviewer is constantly seeing someone else’s logic and new code, while the author of the code is gaining a new perspective – this exchange of knowledge is extremely valuable. 

This blog also provides tips and tricks of how to manage a queue of pull requests properly providing simple Slack queries to organize new requests by team or outstanding requests that require attention. Another tip from the writer is ensuring the reviewer team stays small – this benefits the development team overall as there is clear accountability for who is to review the changes. Vessels also commented on the benefit of specifying code review requirements/frameworks to ensure a seamless, consistent review process amongst teams.  

The writer also provides samples of good code review feedback and poor code review feedback to highlight the main differences between them. Good feedback should include specific details, references to specific issues/lines, provides a possible solution, and provides reasoning. This blog post also offers vital information related to how to give a good code review. Some of the tips seem like common sense like offering affirmations and asking questions, but an important tip Vessels shares is to be aware of biases and assumptions. The writer highlights that even the most-senior programmers can make mistakes so only you (as the reviewer) have the opportunity to validate the work and catch any issues before deployment.  

GitHub Engineer Sarah Vessels shares her invaluable experience with code review through this blog post which discusses fine-tuning the review process, good vs bad reviews, how to give good reviews, and how to get the most out of a review. As a student, it is often my own code that I must turn back to and review to enhance, but after this reading I am feeling encouraged to seek opportunities to study others code with a focus on the exchange of knowledge and getting experience on my own for how to review code for a development team in the future. 

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

This week I found a great blog titled, “Mastering Design Patterns in Java”, that delves deep into design patterns specifically in Java. This piece of work aligns with our course topics and focuses on a programming language that many of us are most comfortable with. The writer, Dharshi Balasubramaniyam, discusses six notable design patterns in software engineering: 

1. Singleton 

2. Factory 

3. Builder 

4. Adaptor 

5. Decorator 

6. Observer 

The focus of the discussion is how to implement these patterns using detailed examples and how they can be used to deal with common coding scenarios like creating objects, managing inter-class relationships, and optimizing object behavior. 

Our work in our course has focused on some of the design patterns that are discussed in this blog, but the rich examples provided here are incredibly valuable when trying to gain a complete understanding of the patterns and learning when to use them. A great example of this is the mention of the Singleton pattern – I am already familiar with this one, but the example being used made the concept easy to remember and understand. The example references the simple idea of the clipboard. If we had more than one instance of the clipboard being accessed by the user of a device, it would be very likely to have conflicting data saved – to avoid this issue we can apply the Singleton pattern to ensure that there is only ever going to be one clipboard instance at any given time. The writer provides the code which enables this example and shows the value of using this design pattern. 

One new pattern I learned about was the Builder pattern which focuses on simplifying object construction with required and optional properties. The pattern works to manage the parameters by using a constructor with the required properties and different setter methods with optional properties by using an object class and an objectBuilder class. This pattern provides flexibility for the object being created – the given example creates a user with required properties of name and email and optional properties of phone and city. In the case of the example, we can note that the properties will have their own functions for setter methods which return an objectBuilder object – if the function does not get called to set a new value all optional parameters will contain the string “unknown”. This technique makes the code easy to understand and ensures we are not getting errors due to missing parameters as they will always contain some string.  

Using this blog to practice and learn from new examples is extremely helpful and will contribute to the enhancement of my skills as I continue to learn and get more comfortable with writing good, clean code the first time. By implementing the examples shown in the article, I can start noticing opportunities to apply these design patterns in my own work avoiding hours of refactoring code later.  

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

Hello WSU blog! In this post I am going to talk about what I learnt in class in regards to software licenses. We watched an informative video on it in class, and then we worked in groups to practice with the information from the video. I actually learnt a lot of simple things about copyright that I never noticed until this class. One thing I learnt was that there is actually an automatic copyright for things that you don’t license. This means that if you want someone to be able to legally use your code, you HAVE to license it, and pick the permissions that they have to use your code. When you license your code, you do not in fact give up your copyright. The copyright will always belong to you, however licensing it lets other people use your code in certain ways.

In this activity we also compared two different licenses. We compared the MIT License, and the GNU General Public License. The MIT License is simple and permissive, meaning that it allows the users of the code to do more things with it. On the other hand, the GNU General Public License has a few more conditions, such as disclose source, same license, and state changes. An extra permission for the GNU license is Patent use. We also briefly looked into non-software licenses as well.

The blog post I researched for this week’s blog is linked here: What is a Software Copyright?

I chose this blog to research because it was pretty simple and easy to understand, while also being very informative. This article mentioned HOW exactly your software is protected due to copyright licenses. It talked about points we covered in class, such as the automatic copyright, which is put into play as soon as the software “is created and saved in some way.” The way the software is written is protected by copyright law, and the owners of the software can give other people access/permission to use their code with the use of licenses. The article also concluded by emphasizing the importance of software licensing and how essential it is for people who want to create or use shared software.

Overall, I think that learning about this stuff while we are still in college is important, and I am glad my professor took the time to include this in the content of this course. Copyright and Licensing is important, and it prepares us a little bit more for the future and real-world applications.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

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.