What is clean code, and how do I make sure my code is clean?  These are the questions I had when first hearing the term “Clean Code.”  In my quest to answer these questions, I found a blog (https://codingsans.com/blog/clean-code) transcribing Karolina Tóth’s interview with Robert C. Martin (Uncle Bob) who literally wrote the book Clean Code.  The main topics covered in the interview are clean code, developer and manager communication, and code ethics.  Focusing on what Uncle Bob has to say on the importance of clean code while including my personal experiences. 

What is Clean Code?

Uncle Bob quotes Michael Feathers saying, “Clean code always looks like it was written by someone who cares.”.   Which makes sense, as I have taken pride in having simple aspects of Clean Code such as clearly named variables and proper indentation in my code blocks.  In contrast, as a tutor, I was asked to review code written with neither of these aspects by a student who openly expected not caring about the class. 

How Can You Measure Clean Code?

Looking at the functions reveals a lot about the code and how clean it is. Uncle Bob states that you can measure the size of a function, and that going above six lines of code they become too large.  Naming the functions properly will also create cleaner codes as Uncle Bob points out that having smaller and more specific functions will require more specific names.  This combined with the if and while statements will create easy to read code that is close to english.  

Importance of Clean Code

Understanding the importance of clean code starts with examining the consequences of having dirty code.  Uncle Bob emphasizes that everything goes slower when you are working with “dirty” code.  Developers commonly believe that quick and messy code is faster upfront, however the slowdown happens a lot faster than most realize.  The example given by Uncle Bob is someone writing bad code in the morning and after a simple lunch break they will be lost in what they wrote.

“Slow Is Smooth, Smooth Is Fast”

“Slow is smooth, smooth is fast,” is a quote drilled into my head from my highschool soccer coach.  Take your time with your movements, make them deliberate, and the result will be smooth.  Going slower and executing a move is better than going too fast and failing.  It feels slower to stay disciplined in writing clean code, however the time saved by having easy to read code will immediately and only grow over time.

Using Clean Code Moving Forward 

Listening to what Uncle Bob had to say about the flow of functions and how they should create sentences really sticks with me. As someone who never saw the need for “the flood of functions”, having easy to read sentences in my code will make returning to projects significantly easier.

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

As I approach the point in my professional development where my code is going to have to be presented, it’s best that I have my code prepared for the eyes of other people.  This means having clean code, and as mentioned in my previous blog, I am guilty of not using functions to their fullest potential.  To fix that, I will look into refactoring my code with the help of the blog Code Refactoring: Meaning, Benefits and Best Practices By Nuradil Alymkulov (https://maddevs.io/blog/code-refactoring/).  Alymkulov covers refactoring in depth by explaining what refactoring is, why it’s important, how to refactor, when to refactor, different methods of refactoring, and best practices.

What is Refactoring and Why Should You Do It?

Writing code is much like writing an essay.  Essays require going back and rereading the content to ensure it is written correctly and that it flows in an organized manner.  When writing code the first attempt at solving a problem or adding a feature may be functional but, like an essay, could do with revisiting for organization and cleaning up.  Refactoring is revisiting old code and making edits that do not alter functionality but, instead, are meant to help with readability and restructuring.  Having readable code will significantly help in finding bugs.    Doing this will encourage programmers to be more thoughtful with their future code, including these refactoring practices in the initial code.

What About My Code Needs Refactoring?

Code blocks should be easily visible, so a good place to start is proper indentation and formatting.  Another large part of refactoring is removing unused or duplicate code.  Renaming your variables and functions may make unused variables or duplicate code more noticeable.   Variable and function names should make sense and form pieces of a sentence when put together.  Reducing the size of each function will encourage developers to name functions in a way that helps form these readable segments of code.  Once the code is restructured, a final clean up of comments that were needed in that past may be self explanatory due to the renaming of functions.

Refactoring Code Moving Forward

There have been countless projects that I would think about an additional feature I could add.  Only to never revisit them due to the idea of having to reread my old code before I could even begin working.  After learning the importance of refactoring code I can approach these projects with the mentality that not only will I clean up my code, but I will learn better practices for future code.  Refactoring my old code will prepare it for future features and give me the tools to write better code.

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

Software licensing is everywhere in the technical world, and for good reason. Without it, our current copyright laws would make it impossible to distribute software in ways that are both beneficial for the user and developer. Fernando Galano does a great job explaining what software licenses are and how they are used in his blog, “Understanding Software Licensing” (https://www.bairesdev.com/blog/understanding-software-licensing/).

What is a Software License?

In short, a software license is a legal contract between the developers of a software and its users. We, as users, have all been asked to check a box in the past agreeing that we have read and agreed to the terms and conditions.  These terms and conditions are called an end-user license agreement (EULA) and spell out the rights and liabilities of both the user and software provider.

What Does a Software License Cover?

EULAs are typically large documents that contain information on how the end-user may install, modify, copy, or distribute the software. These are the more common things to find, however, they are not limited to this.  EULAs may also specify time of use, pricing, and support. These documents are usually very large because of the extent of topics they cover. 

Different Software Licenses:

Public Domain License:

• Software under a public domain license can be used, modified and distributed freely with little to no restrictions. Not all free software has a public domain license.

Copyleft License:

• Software under a copyleft license may be modified and distributed providing the modified software is distributed under the same terms as the source code.

GNU Lesser General Public License:

• Software under a GNU Lesser General Public License may have its code altered or used in other software and distributed under a different license. 

Permissive License:

• Permissive licenses are open sources licenses with requirements on how users may modify, reproduce, or distribute. This gives developers control over what happens to their code.

Proprietary Software License:

• Typically used for commercial software. Provides the greatest restrictions for users and typically are not allowed to modify, copy, or distribute. 

Using Software Licensing Moving Forward

Quoting the first line from the blog, “Your product could be phenomenal, but before you deploy it, you need to grapple with the legalities surrounding the distribution and usage of your software.” (Fernando Galano).  It is clear to see that without a proper grasp of how software licensing works, development of software can only get so far. The next step in being able to distribute work is to license it properly for its intended use.

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

Diving deeper into exploring APIs I found a great blog on RESTful APIs called “REST APIs: How They Work and What You Need to Know” (https://blog.hubspot.com/website/what-is-rest-api) by Jamie Juviler. Juviler does a great job explaining what makes an API RESTful, why they are useful, how to use them, and provides a few examples from popular  websites like twitter, instagram, and spotify.

What are APIs?

Application Programming Interfaces (APIs) allow two software applications to communicate and send data between them. They define how requests and responses will be formatted.

What is REST?

A Representational State Transfer (REST) involves a client sending a request for a resource from a server and the server responding with the current state of the resource. This means responses will vary based on the current state of the resource.

What makes an API RESTful?

Juviler states there are 5 guidelines an API must follow to be considered RESTful, with one option guideline.

1. Client-Server Separation:
   • Communication in a REST architecture is only ever initiated by a client. A request is only ever sent from a client to a server, followed by the response being sent from the server back to the client.
2. Uniform Interface:
   • Every request and all responses must follow a common format. This is through the use of HTTP language. HTTP has become the standard for REST APIs and with it, the use of endpoints. All requests are formatted to contain two pieces, the HTTP method, and the endpoint. Endpoints are used to access specific resources on a server.
3. Stateless:
   • All communications with a server are independent from each other. A request needs to contain everything required to complete the interaction. There is no memory on the server to store or access previous requests. 
4. Layer System:
   • Additional systems, like layered servers, may be added for security, but should not alter the format of messages between client and server. Requests and responses should always follow the REST architecture regardless of backend code.
5. Cacheable:
   • REST APIs allow for caching responses. This means APIs can have larger resources saved on the client for faster access.

Using REST APIs Moving Forward

APIs are a necessity in the software development world, and exploring RESTful APIs in the future will allow me to develop software that can communicate and interact with software around the world. Understanding the REST architecture will greatly improve my ability to create functional, organized, and scalable APIs.

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

As a teen, I remember the first time a video game prompted me to share an achievement with my friends through facebook.  How could a game not related to facebook in any way communicate with the servers to make a post?  Connecting applications together is vital for keeping up with the expanding technical world.  This is done with APIs.

Jason Johl does a great job explaining what APIs are and how they are useful in the real world in his blog,  “What Are APIs, and How Does an API Work?”. (https://blogs.mulesoft.com/learn-apis/api-led-connectivity/what-are-apis-how-do-apis-work/#:~:text=Share%20post&text=API%20stands%20for%20application%20programming,the%20response%20back%20to%20you)  He starts of by explaining the importance of APIs and how they enable speed and agility in software.  Then, gives a great example of how APIs can relate to a real life waitstaff at a restaurant.  Followed up by examples of actual APIs used in booking a flight.  Finally, listing different types of APIs, specifically the Web APIs, which I will be exploring more in detail later.

What is an API?

API stands for application programming interface, and is a messenger between software that handles delivery of the request and response.  Much like how a waitstaff in a restaurant is trained to take a customer’s order to the kitchen and then return with the food.  Kitchens take orders a certain way and it is the waitstaff’s job to translate the customers order into a format designed for the kitchen. Customers can’t interact directly with the kitchen, and must use the waitstaff to handle the requests. 

How are API’s Used?

Travel sites are a great way to visualize APIs in work and how they are useful.  The travel site collects information from a user on the client side and is able to take that information and search all different airlines databases to compile available flights.  To do this, the client, in this case a web browser you are using to access the site, sends an individual request to each of the airlines servers through the use of an API.  Then, the API in the airline servers takes that request, and returns all flights that match the fields such as dates and airports.

Common Web APIs

APIs can be designed and used for any software such as Java APIs allowing two objects to communicate with each other.  In most cases, I will be working with Web API’s that communicate between a client and server.  The most common Web APIs are Representational State Transfer (REST), Simple Object Access Protocol (SOAP), and Remote Procedure Call (RPC).

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

The first step down my professional development path to become Agile involves understanding different Agile methodologies. The two most popular being Scrum and Kanban. Cassidy Knight does a great job comparing the two Agile methodologies in her blog, “3 Differences Between Scrum and Kanban You Need to Know.” (https://www.cprime.com/resources/blog/3-differences-between-scrum-and-kanban-you-need-to-know/) Knight starts the blog off with an easy to read table illustrating the three main differences are found in team roles, work boards, and the scheduling/cadence of the workflow.  She breaks down Scrum and Kanban individually for better understanding of how they are similar, before diving deeper into the three differences.  The blog finishes up with explaining that there is no clearly defined better methodology, but rather that they each have things that work better for different teams. 

Scrum

Scrum consists of breaking up large projects into small manageable tasks to be completed through several scheduled iterations called sprints.  During these sprints the Scrum Team, consisting of a Product Owner, Scrum Master, and Developer work together to design and build new features for a project.  Each new feature is broken into story points that are prioritized by the Product Owner in the project backlog.  The Scrum Master then selects what points will be moved to the sprint backlog to be worked on in the following sprint based on the priority and size of each point. 

Story points are tracked through the sprint on the Scrum board. The Scrum board breaks down workflow into columns, starting from the backlog, to work in progress, to completion. Each story point is given a limited amount of time to be worked on during the sprint. Scrum boards only show the work done for that sprint and are wiped clean after each sprint. Work produced by a Scrum team is evaluated at the end of the sprint and is found successful if all of the story points have reached the team’s definition of done.

Kanban

Kanban, unlike Scrum, does not work in scheduled iterations.  Instead, the workflow in a Kanban is limited by the amount of story points in each column of the work board.  Instead, each team may be made up of specialists that only handle work from the board that suits them.   The work board in a Kanban is like the one found in Scrum with the major difference of each column having limits to how many story points may be in each.  This means a “work in progress” point must be finished before a new one may be opened.

Using Scrum and Kanban Moving Forward

As I continue to learn how to work in agile environments, I will learn what parts form each of these methodologies that work well for me and my team.  Applying practices from many methodologies to create a hybrid methodology may be the best way to move forward. It all depends on the project and the team.

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

And How is it Useful?

As I work on more and more assignments I am constantly hit with the same error while starting up my work for class:

The fix to this is very simple; Start up Docker. This error simply means that my VS Code is attempting to open a container, but I don’t have Docker running to do that. As this reminder started to get me in the habit of making sure Docker was open before attempting to work in a container, I started to ask myself, “What is Docker actually doing and what is a container?”.

I found an excellent post that breaks down what Docker is and how each of the individual parts of Docker work together. The blog, “Introduction to Containers and Docker” by Liam Mooney (https://endjin.com/blog/2022/01/introduction-to-containers-and-docker) provides great information of how Docker used containers with an example of a dockerfile and how to build your own container.  Mooney starts off with explaining what a container is and how they vary from virtual machines. Containers and virtual machines are both ways of creating an isolated environment on a computer, however, virtual machines are bulky and slow in comparison to containers. This means they can both be used to create stable environments to run software in, however, virtual machines require an image of an OS to be installed on a host computer. This OS also needs to be installed every time you start the virtual machine. This paired with taking up a lot of space and CPU resources by having two OS’s that share a lot of features leads to much longer start up times and slower runtime. Containers use the capabilities and features of the host OS to run the environments. This makes them much lighter, only needing select software and dependencies to be included in the environment.

This blog goes on to explain how Docker is able to use containers to create environments in seconds. Docker uses dockfiles, which are a list of commands the docker daemon will execute to build the image you wish to run for your environment. Docker daemon is a background service that builds, manages, and runs the environment by being the middleman between the container and the host OS. Once the image has been built, it can be opened in any number of containers that are all independent of each other.

The examples given by Mooney are great for understanding exactly how you would create a simple container. Giving me a better look at what Docker is actually doing when I am working in VS code and its opening containers for me to work in. Although I don’t see myself designing my own containers anytime soon, it is great to know how the software is executing and managing these environments.

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

If you search online for Agile methodology blogs, you will find a lot of them mentioning what it means to be Agile by referencing the 4 main values and 12 principles from the Agile Manifesto. (https://www.agilealliance.org/agile101/the-agile-manifesto/).  While these core values and principles define what it means to be Agile, I was looking for more of a general definition. In my quest to discover what it means to be Agile in today’s software development world, I have come across a blog that, in my opinion, does a great job in explaining that. “What is Agile methodology? (+ how you’re already using it)” (https://www.lucidchart.com/blog/what-is-agile-methodology) starts off by giving a great, simple, explanation of Agile methodology: “Agile methodology breaks the developmental process into iterative steps and encourages flexibility, testing, and change throughout the life cycle of a project.”.  The simplicity of this definition really drives home how intuitively flexible this methodology is and how so many different frameworks are able to adopt Agile methods.

How To Adopt Agile Methods:

The blog has a great analogy for Agile methods being like a detailed to-do-list. Prioritizing must-have features to add to a project is the first step in being Agile. Step two involves estimating the time required for each feature and adjusting priorities as needed. Lastly, step 3, involves setting up a schedule for a sprint.

Importance of Iterations:

Sprints are typically two week periods where the team has prioritized features they are working on. The goal of each sprint is to have a working product that has been tested by the end. Having a working product at the end of each sprint allows the stakeholders to have input on the current development and the future plans. Further emphasizing the need for flexibility as a project can shift focus at any point in development. 

Agile Frameworks:

There are so many Agile frameworks already designed, such as Scrum, Kanban, and XP, just to name a few. With so many to choose from, where do you start? The beauty behind the flexibility of Agile methodologies is that no framework is rigid either. This means each team can adapt processes that work for them. 

Using Agile Methods Moving Forward:

As I will be working in Scrum teams, I hope to develop skills to maintain an agile environment for me and my team. Staying flexible to change while following the values and principles of the Agile manifesto will help me develop skills needed to work in a professional environment.

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

Have you gone to open an application on your computer and were given a prompt saying your software is out of date?  Some of these messages even tell you what version you are running compared to the latest available.

For example, I opened Notepad++ and received the message above.  You can see I currently have version 8.4.7.0 installed, and the available version 8.5.7.

This is an example of Semantic Versioning.  The article “A Guide to Semantic Versioning” by Suemayah Eldursi (https://www.baeldung.com/cs/semantic-versioning)  clearly breaks down each segment of a Semantic Version. Semantic Versioning is a scheme for labeling versions of software using meaningful numbers to represent what was changed.

Major Update :

The first digit refers to the major updates.

• Updates that involve changes that break API functionality and are not backwards compatible.  

In my example, you can see the current major update matches the available.

Minor Update :

The second digit indicates minor updates.  

• Updates include new features that are backwards compatible and will not break anything in the API.  

In my example, you can see the current version is one minor update behind the available version.

Patch : 

The third digit describes the number of patches. 

• Small bug fixes and changes that don’t add any new features, are backwards compatible, and don’t cause any breaks in the API.  

In my example, the current patch number is irrelevant because of the minor update, however, we can see that there have been 7 patches since the minor update.

Pre-Release and Build :

Semantic Versions may also include a pre-release label and build number.  Pre-release labels, such as alpha and beta, and build numbers would look something like “1.0.0-alpha.4”  These are used to let the user know that it is a pre-release build and may have more use for developers to identify additional version information as needed.

Updating Your Version :

Being able to read a version number is important for users so that they can know what changes have been made to the software or if it’s backwards compatible.  Therefore, updating the version number correctly is just as important.  The article “Introduction to Semantic Versioning“ by Parikshit Hooda (https://www.geeksforgeeks.org/introduction-semantic-versioning/) provides a great illustration that demonstrates what type of update you should choose and what the version number would look like after:

In this example, you can see how a bug fix would only change the last digit from an 8 to 9.  It’s important to note that a minor or major update resets all following numbers to 0.

Using Semantic Versioning Moving Forward :

Maintaining proper documentation of your updates through Semantic Versioning is vital for both the user and developer. As a developer, keeping an organized record of each update and communicating what changes were made to users.

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