PREVIOUSLY ON MPEKIM.CODE…

So far, we have come to the conclusion that it is okay to not know everything. It is also alright to even be “the weakest link” of a team. What matters the most is the enthusiasm, the drive to learn more about our projects and programs. For Apprenticeship Patterns, this means that newcomers can be useful to a team if they provide morale and enthusiasm to expose and attack their ignorance.

To start, I believe that the book stating the idea of “repressing enthusiasm when it is not welcomed” isn’t entirely incorrect. However, I do believe that, unless an enthusiastic apprentice is drastically creating dire consequences for the team, then the members with lower morale should lighten up a bit. No one starts out “creating the next Linux”; if seasoned professionals are not held up to these high expectations, then it seems ridiculous (to say the least) that the newcomers will be held to it.

Interestingly enough, the controversial idea of repressing enthusiasm is supported by a factor of the pattern that I do enjoy: the idea of “experiencing diversity”. According to “Unleash Your Enthusiasm”, teams actually have the most efficiency when they consist of members who each have various amounts of experience. “Old farts” who have seen it all will likely be numbed and unaware of an issue that a newcomer will notice with their “fresh eyes”. Likewise, the more experienced will create sorcery, solving programming problems that the newbies weren’t even aware of.

As far as the future is concerned, I can say that I apply this pattern on a daily basis. While the book helps to reinforce this ideology, I am no stranger to “pumping up a crowd”. Unleashing enthusiasm is not only the idea of providing positivity and workplace morale, but it also involves taking the initiative. Even if they get shot down, we should always put our ideas out there – scribbles, doodles and random notes are never irrelevant. Some of the greatest ideas were the result of an accident (caused by an enthusiastic dreamer).

So far, in the grand scheme of my selected patterns, here is what I see as a “list” or “chain”:

• Find a team that you are the worst on.
• Discover and acknowledge your weak points.
• Take the initiative and enthusiasm to work on these issues.
• Give yourself the breakable toys needed to grow from mistakes.
• Practice correctly, with feedback from professionals.

In retrospect, I find it amazing to take my previous blogs, and discover a path within them (similar to a graph data structure). Now, we must take the time to implement it….

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 is better to be honest about your skills and fail to land a job, than it is to lie and put yourself in a situation that’s over your head.” – Someone, probably.

That quote, while partially meant as a joke, does have some truth behind it. Unfortunately, in this world of ever-increasing job requirements, it seems enticing to claim skills that you don’t actually have. This, however, can lead to an avalanche of constantly falling behind on work, and procrastinating/struggling to keep up with the rest of the team. Tapping into my previous entry (“Being the Worst”), we can see that is better to be honest about ignorance than to “shove it under the rug”, as one would say.

“Apprenticeship Patterns” essentially states that for this pattern, we must face a very difficult aspect of our lives – admitting that we are not the best at everything, and that we need to ask for help. Similar to “Being the Worst”, I find this philosophy to be familiar, but fascinating nonetheless. While it took me more time to confront my ignorance than to challenge my skills, I understand that both of these processes will make me a better programmer (and a better person) in the long run.

The most useful aspect of this pattern is the idea that, regardless of what we do with our lives (from scientific advancements like coding software to artistic talents such as playing guitar), it is more important to learn how to learn, than to “learn towards a goal”. To phrase this with better clarity – if we can understand the most effective way to learn, it will make our challenges much easier to overcome than trying to simply take on the challenge directly.

While I don’t think that this pattern has changed my thoughts about professional programming, I do believe that it has emphasized the importance of brainstorming, “thinking outside the box”, and other important factors of discovering unknown material. Most importantly, exposing ignorance shows that, as programmers, we know that we don’t have the solution that our client desires (yet), but we are also searching for it.

Maybe it’s because I’m no stranger to shame, but I must say that I disagree with the idea that there is “tremendous pressure to satisfy clients, regardless of one’s actual competence”. For me, the best way to satisfy clients (and pacify my own anxiety) is to select the most reasonable long-term solution – in this case, admitting my ignorance. “Dodging the bullet” during the sprint planning might provide short-term anxiety relief, but the problems avoided remain unchecked, building up far more anxiety in the long-term.

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.

For this week, I am going to cover another type of “new material” that I have learned within my software design class. This “new material” is known as the REST API. As per usual within my blogs, I always try to find some connection to a past experience or previously learned material; for REST APIs, the closest materials would be other web design tools such as HTML and JavaScript.

In a nutshell, APIs are used as a way for clients and servers to interact with each other; these interactions can involve exchanging data or performing behaviors with that data. Languages that involve APIs are: JSON (JavaScript Object Notation), Python and HTML, to name a few. The interactions that APIs perform with these languages are often done in class using modules called “endpoints”.

These endpoints are “sub-containers” that perform interactions with items or collections of data. Examples of endpoints include: GET, POST, PUT and DELETE; whether or not the endpoint works with a collection or a single item is dependent on additional parameters (such as an “id” for an object). Connecting REST APIs to additional parts of the class, API “calls” (similar to functions in other languages) involve setting up ports to connect to a host server; once connected, the call will attempt to perform the requested endpoint interaction with the data found at that port/container.

Linked below is a website that will get anyone interested in REST APIs up to speed on how they work, why they’re important, and other applicable knowledge about the topic. I chose this article, as well as the topic of REST APIs in general, due to the fact that I still struggle with the process of working with them; I hope that with further study, I can become proficient with the material. It seems as though REST APIs, alongside the other material within this class, follows a similar theme; in addition to being based around software design, these topics are related to creating “inter-connected” projects. This makes sense, as very few projects are done in isolation nowadays.

When moving forward, I hope to gain two benefits from learning about REST APIs. In the short term, I would appreciate using this newfound knowledge to help complete my homework assignments. As for the long term, it has been discussed that REST APIs are a profitable market in the computer science field; by being proficient in this aspect of programming, I will be in a class by myself among other programmers.

Link: https://www.edureka.co/blog/what-is-rest-api/

https://www.redhat.com/en/topics/api/what-is-a-rest-api

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.

In my previous entries, I have been taking topics (such as REST APIs, coding smells, and so on) and merely providing general applications of the subject. This is not to say that the posts are simply summaries; rather, they provide a little bit of coverage on a lot of ideas within the subject. This time, I’m going to something a little different – I want to cover a specific issue involving REST API calls. This issue involves the return messages from the calls, specifically the “200” success message vs. the “404” failure message.

To summarize, a “200” return message is essentially an “OK” message. It means that, when trying to access data, that data can be found to some degree (even if its value is zero). For example, even when trying to access an empty list, it will return a “200” despite having no items within the list. In contrast, a “404” error is commonplace on the internet, to the point where even those who aren’t tech-savvy at least understand the general idea – it means that requested data cannot be found. in short, it doesn’t exist (at least not to the server).

A good way of discerning the difference between these two is to take a shelf of soup cans. If we have an empty shelf, then we will get a “200” message – the shelf exists, but there are no soup cans on it. Meanwhile, a “404” would mean that we cannot get any soup because the shelf does NOT exist.

The blog associated with this reading is short, sweet and to-the-point; it briefly explains the “200” and “404” messages, alongside some other return messages (and even some images of cats!) I chose this reading due to its brief, yet informative nature – these topics are not difficult, and don’t require too much explaining. The cats also make for a humorous touch, allowing the learning process to be more “fun” and “easy going”.

While a smaller detail, this distinction between “zero” and “null” is not to be taken lightly. I plan on using this knowledge in future practice, as it will reinforce good coding practices; it is not enough to say “we have no soup” and be done with the problem. We need to know exactly WHY we don’t have any soup, otherwise this faulty coding can lead to smells and other issues down the road. It is always important to not only understand what the result of a program is, but also how it gets that result. We also need to ask ourselves if this result is obtained “properly” – meaning that it is done in a way that works smoothly with the res of the program.

Link: https://blog.short.io/status-codes/

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.

So I’m going to have to be honest with my readers, and also I’m going out on a limb here: I am not the most experienced with Git. This is especially detrimental when I am taking a course that requires regular usage of Git, and that course is a limited time offer. What am I going to do? In my general theme of learning, I am going to practice over and over again until I finally “git gud” (as the kids would say) at Git.

Git is a version control software used to create different “branches” of a project. These branches can be local or remote; they also can “pull” information from other branches, and “push” or “merge” this information back as well. Other important controls include: rebasing, location arguments (such as HEAD) and “status-checking”. These commands, and many more, are used to ensure that software can be created or polished in separate branches while the “main” branch is still operational. When the changes are tested and ready to be added to the program, they can be “merged” back in.

As a way of “branching off” from my traditional form of blogs, I have decided to link a unique source. Instead of an article or a YouTube video, I have linked an interactive tutorial called “Git-It”. This is because I believe that the best way to learn Git is by practicing it over-and-over; similar to a “traditional” programming language, hands-on experience with Git will take a programmer further than any abstract knowledge will. In a nutshell, this tutorial will teach you all the basics needed to understand Git. These basics include, but are not limited to:

1. Creating, modifying and deleting repositories
2. Pulling and Pushing data from other repositories (both local and remote)
3. How to clone material from a remote repository to a local computer
4. Creating and merging branches

Not only is Git going to be essential for completing homework assignments, but it is practically unavoidable in the software workforce. Similar to Singleton/Strategy refactoring, Git allows for different branches to create different implementations, while all still referring to one “global, main” branch. Branches can also be used for various SemVer levels in a project; should changes need to be made, progressing or regressing a project (through committing or reverting, respectively) can be done.

Most importantly, I feel as though Git is a great tool to help me understand the concept of continuous integration. As mentioned before, Git allows for multiple branches of software; these branches can then be “forked” or “cloned” to private servers or local computers. This gives the programmer a copy of the project to work on, while the actual project is still running for its customers. This “language” combined with Docker containers, emphasizes the class theme of being able to work with software on different platforms, thus maximizing versatility.

Link: http://jlord.us/git-it/challenges/get_git.html

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.

While working with YAML files is a relatively new concept for me, I must say that the structure is somewhat similar to another style of coding I am more familiar with: CSS. The two are not exactly the same, however the “key: value” format makes coding with YAML files that much easier. As noted later on, the importance of indentation in YAML reminds me of Python, a familiar programming language.

As part of the title, I have decided to make my own acronym for YAML: (Y)ou (A)lways (M)ake (L)ogs. This is because I view YAML files almost like logs for a certain state of a project; each one consists of all the different elements that make up a certain level of a SemVer state. In fact, YAML files consist of all the different materials that have been seen in this course before; ports, images and more make up a YAML file. In addition, these files are often used with preview software (such as Swagger) to create visualizations of APIs.

In the link below, one can find a video that explains the structure of YAML files. This information is alongside applications of the files, and even a tutorial for setting up a YAML extension in Visual Studio Code. I have chosen to watch this video on YAML files for two reasons: first, I need more practice with YAML, and in my opinion, increasing my exposure to it is the best way to gain more experience. Second, videos are a preferable source of educational media in my opinion; having visual examples helps to get the idea across better than simple discussions.

YAML files can be simple, like the one shown above; they can also be thousands upon thousands of lines of code. Traditionally, they start with the version number, and are also dependent on proper indentation (similar to Python). Features of a YAML file can be as significant as a docker image, such as nginx; features can be as focused as making an element “read-only” within an API endpoint.

Among everything else, it is important to emphasize and take away this lesson from YAML files: these files are a core component of software design, connecting several familiar aspects together. By learning about YAML, I can figure out a way to run images, map ports and even more, all within a single file called by the “docker-compose up” command. Personally, I feel as though YAML will be an invaluable resource in future IT endeavors; while software such as Git focuses on the level of version control, YAML focuses on what exactly goes on in that level.

Link: https://www.youtube.com/watch?v=fwLBfZFrLgI

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.

Whenever I played video games in the past, I would always be aware of a weird looking number, often resembling something along the lines of “1.2.3”. Even back then, I was aware that this number meant that I was using a certain version of a software; however, the idea of a value having multiple decimal points was perplexing to me. Upon doing some research, and performing a closer, more careful analysis behind the meaning of the number, I now understand why: this value is part of a system known as “SemVer” (Semantic Version).

SemVer is a special kind of number used to provide programmers and clients an awareness of a certain version of software. Basically, it is broken down into three different parts: MAJOR.MINOR.PATCH. A “MAJOR” number is incremented when code is added to a project that is not backwards compatible with previous versions. This kind of update will force users of the software to adapt in some way to the new changes.

On the other hand, a “MINOR” number is incremented upon creating (as the name implies) rather minor changes that do not result in breaking the program. All changes that result in a MINOR increment can work with previous versions of the software. Finally, the “PATCH” number receives an increment when very minor changes are made to a program. These changes often involve fixing bugs or other errors found within the MAJOR and MINOR releases.

Linked below is a YouTube video describing SemVer in detail, and it was made by a user known as “Inedo”; I chose this video simply because of the fact that it allows me to indulge in my favorite social media (YouTube) while also learning about SemVer. I guess I also chose this video in particular due to the fact that it is mainly audio; this is an easier video to play in the background as a “radio” during work than a normal video (which requires sitting down and paying attention).

Going forward, I plan on using my knowledge of SemVer for two purposes. First, when enjoying video games, I can now have a greater understanding of just how complete the product is (compared to when I was a kid). SemVer allows me to know just how much time and effort companies put into their software; while a higher SemVer number isn’t necessarily a hint of a better product, it does show that more time was dedicated to perfecting the craft. Second, I can use SemVer in my own coding adventures. Instead of making one program and being done with it, I can now create different versions of the product (for example, version 1.0.0). This knowledge will be especially useful when combined with collaborative software tools such as git and Scrum.

Note: The numbers in the title are NOT random. See if you can figure out what it means!

Link: https://www.youtube.com/watch?v=Si3eWq1yHXs

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.