“Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been considered to be an acclaimed read by many of my fellow students. After giving the book a try, I can also see why it is such a big hit. In essence, this book speaks to programmers on a “relatable, spiritual” level on how to turn their passion for software development into a lifelong process of constant improvement.

To be honest, the most interesting part of the reading for me was found in Chapter 4: Accurate Self-Assessment. This is because it is instrumental to my learning style that I am “the worst of a group”, or that I am always in a zone that I need to focus on improvement. Throughout my college career, I have been the type of person to rant and rave about how “I’d rather get a ‘C’ and master two programming languages, than receive an ‘A’ and still show evidence of struggling with one.”

Considering my own views on how I work with software, I feel as though this book has been mainly a “rehash”, or a reinforcement of my beliefs. This is due to several factors, including the “Be the Worst” philosophy as mentioned in “Accurate Self-Assessment”; this can also be seen in “Chapter Two: Emptying the Cup”, where they state the importance of becoming extremely proficient with your first programming language.

Unfortunately, as amazing as this book is, I cannot say that I agree with every last line of its code. One spot where a “warning of disagreement” occurs is when “Chapter 6: Construct Your Curriculum” does just that – it tells me how to create my own study plan (outside of college classrooms and office hours). Perhaps this makes me contradict myself with my own “unorthodox schedule”, but I learn best when I don’t feel like it’s forced. Instead, my most efficient learning is recreational; it seems as though material sticks with me the best when I ingest it in the same way that one would ingest a juicy diary or a football roster.

For me, I found the chapter “Walking the Long Road” to be the most useful for continuing my career as a software engineer. This is due to the fact that it acts as a reason for using the philosophies found in “Accurate Self-Assessment”. By this, I mean that people (including myself) need to understand that becoming a master craftsman, and especially a master programmer, does not “just happen” overnight. it takes years upon years of grinding, of constantly “being wrong” and being challenged to find alternative solutions to problems.

Overall, “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been a fun, yet informative read. As mentioned before, I agree with most of the book; even in times of disagreement, I can see where the authors are coming from. I am looking forward to the applications of this book in my career as an aspiring software developer.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

It seems as though across several different environments, people have come to an agreement that “being at the bottom” actually isn’t as bad as one may make it seem. Rap music often makes references to “starting at the bottom” and “creating a grind for the paper”; Harvard University, despite its reputation for requiring high GPA scores, has an urban legend of “failing new students on their first semester”. Whether or not these previous statements are framed in facts or anecdotal assumptions, the idea remains that we as a society understand that “there is always room for improvement” – every day that you don’t make yourself stronger, you make yourself weaker.

This brings me to my first pattern of self-assessment from the Apprenticeship Patterns book: “Be the Worst”. In a sentence, the pattern explains that if we have nothing/no one to challenge us, then our knowledge level plateaus or even weakens; it is always a good idea to surround yourself with people that are better than you. This gives you the ability to learn from them and become an even greater programmer.

To be honest, I am glad that I started with this pattern. While I cannot say that it’s interesting per se (since I have always had this philosophy in mind), I can say that it is useful. I get where the book is coming from, and I would like to always be the “weakest link” as it ensures that I am in good, professional company.

As I stated before, the pattern has not really changed my way of thinking, since I have already held this idea of “being the worst” near and dear to me. However, I must say that it is nice to see a professional textbook reinforcing my beliefs – while it goes against the philosophy, being correct before a confirmation is a good dopamine rush. I also cannot say that there is much to disagree with, since the pattern hits every nail on the head:

• Join a team in which “you are the worst”.
• Work harder than the rest of the team; don’t “be a passenger” or have people carry you.
• Provide as much help as possible, even if these tasks seem “menial”.

Could this pattern be an excuse for my procrastination at the start of this semester? Maybe – I think the “early start” didn’t help either (and some burnout from constantly taking classes to boot). However, in the end, I am glad that I have a great team to work with, and a bit of “set back” in order to keep myself on my toes for these upcoming classes. If this setback is my “rock bottom”, then I can only imagine how great it will be at the summit.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

OBJECT ORIENTED PROGRAMING:

Object-Oriented Programming (OOP) is all about creating “objects”. An object is a group of variables and related functions. These variables are often referred to as properties of the object and functions are referred to as the behavior of the objects. These objects provide the best and most straightforward software design.

Principles of OOP.

Object-oriented programming is based on the following principles:

• Encapsulation. 

This principle states that all important information is in the object and only selected information is disclosed. The implementation and state of each object is done privately within a specific class. Other objects do not have permission to access this class or the authority to make changes. This characteristic of data encryption provides more software security and avoids unexpected data corruption.

• Abstraction

Objects only display internal mechanisms that are necessary for the use of other objects, to hide any unnecessary implementation code. The resulting class can be extended its functionality. This concept can help developers to make additional changes or additions more easily over time.

• Inheritance.

Classes can reuse code from other classes. Relationships and small bridges between objects can be handed over, enabling developers to reuse common logic while continuing to maintain a unique bridge. This OOP property compels more detailed data analysis, reduces processing time and ensures a high degree of accuracy.

• Polymorphism.

 Objects are designed to share behavior and can take up more than one form. The program will determine what meaning or use is necessary for each implementation of an item from the parent class, thus reducing the need to repeat the code. Then a child class is created, which enhances the functionality of the parent class.

Advantages of using OOP

1. OOP Allows parallel development.

If you are working with software teams, then everyone can work independently once the standard classes have been resolved. That allows a relative level of parallel growth that would not have been achieved otherwise.

• Module classes can be used again and again.

Once module classes are created, they can be reused in programs or other projects. Sometimes, little-to-no adjustments are necessary for the next project. That gives the team more flexibility as it crosses the starting point.

• Coding is easy to maintain.
• With OOP, because your coding is centralized, it is easy to create a code that can be maintained. That makes it easier to store your data when you need to make updates.

Disadvantages of using OOP.

1. It can be ineffective.

Targeted programming tends to use more CPUs than alternative options. That can make it an inconvenient option when there are technical limitations involved because of the size that can be exhausted. Because of the duplication involved, the initial coding may be larger than the other options as well.

• It can be very large.

If OOP is left unchecked, then it can create a large number of complete, unwanted code. When that happens, costs go up and that makes it harder to keep costs down.

REFERENCES:

1. https://info.keylimeinteractive.com/the-four-pillars-of-object-oriented-programming
2. https://medium.com/@cancerian0684/what-are-four-basic-principles-of-object-oriented-programming-645af8b43727

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

SOLID

 SOLID is an acronym that stands for five key design principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle. All five are used by software engineers and provide significant benefits to developers.

Principles of SOLID:

• SRP – Single Responsibility Principle

SRP states that, “a class should have one, and only one, reason to change.” Following this principle means that each class does only one thing and each class or module is responsible for only one part of the program functionality. For simplicity, each class should solve only one problem.

Single responsibility principle is a basic principle that many developers already use to create code. It can be used for classes, software components, and sub-services.

Applying this principle simplifies testing and maintaining the code, simplifies software implementation, and helps prevent unintended consequences of future changes.

• OCP – Open/Closed Principle

OCP states that software entities (classes, modules, methods, etc.) should be open for extension, but closed for modification.

Practically this means creating software entities whose behavior can be changed without the need to edit and compile the code itself. The easiest way to demonstrate this principle is to focus on the way it does one thing.

• LSP – Liskov Substitution Principle

LSP states that “any subclass object should be substitutable for the superclass object from which it is derived”.

While this may be a difficult principle to put in place, in many ways it is an extension of a closed principle, as it is a way to ensure that the resulting classes expand the primary class without changing behavior.

• ISP – Interface Segregation Principle

ISP principle states that “clients should not be forced to implement interfaces they do not use.”

Developers do not just have to start with an existing interface and add new techniques. Instead, start by creating a new interface and then let your class implement as many interactions as needed. Minor interactions mean that developers should prefer composition rather than legacy and by separation over merging. According to this principle, engineers should work to have the most specific client interactions, avoiding the temptation to have one large, general purpose interface.

• DIP – Dependency Inversion Principle

DIP – Dependency Inversion Principle states that “high level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details.  Details should depend upon abstractions”

This principle offers a way to decouple software modules. Simply put, dependency inversion principle means that developers should “depend on abstractions, not on concretions.”

Benefits of SOLID principle

• Accessibility
• Ease of refactoring
• Extensibility
• Debugging
• Readability

REFERENCES:

1. https://www.bmc.com/blogs/solid-design-principles/

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

The year was 2005. I was a young child in elementary school, and eventually I was exposed to a little-known strategy game known as Warcraft III. As I championed the human race in my epic quest against the Undead Scourge of Lordaeron, I came across a sorceress ability known as “Polymorphism”. This powerful spell allowed its caster to turn an individual target into a harmless sheep. While entertaining and useful to say the least, little did I know that Polymorphism itself would take on a new form in the years to come…

Fast forward to 2021. I am being exposed once again to Polymorphism, this time as an essential feature of Object-Oriented programming. This would mark the third time that I am working with this concept (the other times being 2016-2017, and 2019 respectively). Polymorphism, in theory, isn’t very difficult: we take one idea (such as a function/method), and give it “many forms” (hence the name) among its various classes that use the function/method.

Listed below is an article about polymorphism from GeeksForGeeks, one of my “personal go-tos” when it comes to learning about programming practices. Specifically, “runtime polymorphism” will be more applicable in my software design class, due to its usage of method overriding. When using the “Strategy Design” of refactoring, we will create various interfaces and have them implemented using respective classes; these classes will then create their own version of the method.

Strategy design refactoring seems to provide an edge over “simple inheritance”, which would involve having a single base class (that all subclasses inherit off of). This “edge” is the removal of inherited methods that serve no purpose in certain subclasses; when the interface is implemented by the class, we can choose exactly what we want and don’t want from polymorphism.

However, having too many interfaces, or not enough data within the interface can cause its own problems. In addition, an interface is just that: a “top-down” view, with nothing beneath it; the methods need to be designed by the class using it. Meanwhile, inheritance may have redundant data, but at least you get all that and a bag of chips. In other words, inheritance provides one portion of functioning methods, plus whatever else is added on in the subclass.

I hope that I can use the idea of polymorphism, alongside interfaces, to reduce the amount of redundancy and complexity in my programs. There is no need to turn a program into a headache with unnecessary amounts of inheritance. In addition, part of this unnecessary material could be redundant – brought along for the ride, but not used during run-time.

Link: https://www.geeksforgeeks.org/polymorphism-in-java/

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Michael Feathers is a software developer, founder, and director of R7K Research & Conveyance. R7K Research & Conveyance is a company located in Miami Florida. Specializing in software design, they use the importance of the need of the business and intensive planning to meet company demands, plus on top of that to be able to design software where you are aware of the code to make adaptable adjustments in the long run such as, adding new features that are newly needed vs features that are easily removed to make room for new upcoming changes which is referred to as planning. 

He helps other teams and developers to refactor code to improve its performance without rewriting the existing code. Gives best practices to maintain their software with ease such as making test programs as you can optimize it at the same time to keep tabs on it. 

I chose this blog because he provides helpful tips whether they are in Java, Python, C++, etc. and leaks information from his Book “Legacy Code”. Also mentions UML which I could learn more in depth of when we progress further into CS-343. 

In one of his blogs about code refactoring, he discusses that before we make tests for our own code we write, we must evaluate and rethink towards ourselves whether if it is going to fail. He stated, “As you make any change, know with every edit whether that edit changes behavior.” https://michaelfeathers.silvrback.com/testing-yourself, meaning we can’t compile code if it is incomplete, if there is something going wrong, we must figure out the missing piece of the puzzle. I could’ve used this type of thinking back in my other core classes like Data structures, or intro to programming class, because it can only take a small mistake to make your entire code and/or program to fail. Another reason is that Michael gives an example about when working in groups, and the type of challenges you may face such as having trouble putting heads together, not seeing each other’s perspectives. Providing tips and trick to get around obstacles like these. In CS-343, we do POGIL activities when we come into class, each member has roles of their own to keep the teamwork intact, but as he exemplified before we may also “glitch” and we have to figure out why and what can do about it. Depending on how we think and how we get ideas.

Reference blog resource: https://michaelfeathers.silvrback.com , https://www.r7krecon.com

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

APIs play an integral role in the development of modern-day applications. Whether you are writing your API or integrating someone else’s, it is crucial to understand their functioning. There are many APIs, but the most common types are REST APIs that operate using HTTP and HTTPS. I chose to write about REST APIs because we will be working with them in this class. They are essential to understand for most development projects. The blog post “Best practices for REST API design” discusses the basics of a REST API, how they work, and development practices. The post also provides code examples using NodeJS with the ExpressJS library showing how the concept of a REST API is implemented.

According to the article, a REST API follows a set of standard design principles that allow users to quickly be able to work with the API. For example, a REST API should include method endpoints such as /GET /POST /PUT and /DELETE. These endpoints are used to send and receive data between the server and the client. The difference between the endpoints is the operations they perform. Sending a request to a GET endpoint will send the client data, a POST request will add data, and a DELETE request will remove data.

Although there are a set of rules a REST API must follow, there are many best practices left up to the developer that they should follow. For example, a REST API should send and receive data in JSON. JSON makes working with data simpler because it is in an easily transferable and structured format. The API should also run over HTTPS rather than HTTP to add an extra level of security between communication.

A REST API closely resembles the structure of a URL where each method is separated by a forward slash. To pass a parameter, a question mark is used followed by the variable name equal to a value. In order to be readable, the developer must name and structure the API paths wisely, based on the function an endpoint is responsible for. For example, a GET request to find a user by ID could look something like /user/findOne?id=120. In this example, the findOne method is prefaced by /user/, and we know the user id we are finding is 120. If the API replaced the word user for record, then the developer using the API would not know what type of data to receive in the request.

Finally, a REST API should be versioned, meaning the highest level path of the URL structure should be the API’s version number. Using the find user example, a versioned API would read /v1/user/findOne?id=120. If we made a change to our API, we could modify that in the v2 API without breaking the code written using the v1 API.

I will definitely use these tips while developing a REST API in the future. One of the most important guidelines I learned was to always send and receive data in JSON. In the past, I have made a REST endpoint return a single value such as a number. Without any context, the data from the API would be hard to understand. If the values were named in JSON then it would be easier to work with and manipulate.

Reference blog resource: stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.