Author Archives: erockwood

Software Apprenticeship Post #4

Today I will be focusing on the Apprenticeship Pattern “Use the Source”. This pattern talks about reading other people’s code to learn by their example of how to do things, so that you have a solid foundation of where to go when you actually start writing the code. As if your code disagrees with your intentions, it will never work.

The pattern also talks about how the “Practice, Practice, Practice” pattern will only reinforce bad habits if you do not know any good ones to practice by. This is important as habits can be hard to break, so it is best to start with good habits rather than bad ones that you may need to break later on.

A good idea is to start by reading code for applications and tools that you use every day and learn by their example. This helps you learn how the other programmers code, and helps you understand the thought processes that create the infrastructure of the programs and tools that you use. Another good idea is to download open source projects, downloading them from the current version of the source code, using source control, to learn the history of how it has changed and so you can learn how future changes are affecting it.

You can then also try to refactor the codebases to try to understand why the programmers made the choices that they did, and also any consequences there might have been if you were the one writing the program instead. This helps you further understand the projects, and it also helps you to build the projects as well.

However, during your exploring you will eventually come across some decisions you may disagree with. It is important to ask yourself if the developers knew something you did not, or vice versa. It is good to realize that maybe there were things outside of the developers control that required them to make those kinds of decisions.

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

Sprint 3 Retrospective

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint was primarily getting the local Kubernetes demo to run.

For this sprint we tried to evenly distribute the workload as much as possible, so that no one was doing too much or too little. Since we had a total of 25 weight to complete this sprint, we tried to get everyone to do around 5 points worth of work, since 25/5=5. We did not put too much focus on how those 5 points were distributed, however, so someone could have done 2 2 weight issues, and 1 1 weight issue to get their 5, they could have done 1 2 weight and 3 1 weight, etc. All that really mattered was getting everything done and done well.

Overall, I cannot say much that did not go well, as everything went pretty smoothly throughout the sprint. I feel that if we continue with what we are doing going forward we will do well as a team.

We tried to communicate as much as possible during the sprint, and when we were not able to communicate in class, we either talked through Discord, or had Zoom meetings to talk and discuss. I feel this helped a lot throughout the sprint so that we all had a good idea of what was being worked on, where everyone was on what was being worked on, and what still needed to be worked on.

While it seemed to be somewhat the same for everyone else, I felt the workload balance of the work I did was very well balanced. I did not feel too overwhelmed at any given point, nor did I feel I had too little to do at any given point either. Everything felt just right, and I hope that we are able to continue with this type of workload balance going forward in the future in future sprints. I know that this sprint was primarily the research sprint, and that the future sprints will be heavier with more work than research, so I hope that we will still manage to find a good balance with the work that we need to do in those remaining sprints.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/demo-deployment/-/issues/1

The above link takes you to my GitLab page that I did for deploying the Kubernetes cluster locally. Overall it was pretty easy and straightforward and did not require too much configuration to make everything run nicely.

I also started but was unable to finish writing the README for the demo, but since we were unable to finish the proper demo before the end of the sprint, I had to scrap the README. Unfortunate, but I did not spend that much time working on it so not too much time was wasted on it.

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

Breakable Toys

This week’s Craftsmanship Pattern is another important one, breakable toys. This stands for the idea that experience is built upon failure just as much, if not more, than success. This idea is very good, as no one wants to fail, but failing is one of the best ways to learn, as if you are always successful, it is much more difficult to learn what does not work and what to avoid. The idea of never failing means you will never take any risks. To quote one of my favorite memes, “You didn’t grow. You didn’t improve. You took a shortcut and gained nothing. You experienced a hollow victory. Nothing was risked and nothing was gained.” While the above is pointed at cheating in a very difficult video game instead of “Gitting Gud” (intentional spelling) to pass a difficult task, I feel like the same idea applies here as well. It is important to learn what to do to succeed from what does not work, and what does work to continue using it.

To help with this growing, and similar to last weeks, it can be good to set up a private space where you can seek out this failure to learn from the experiences. For projects that you can fail on, try to build you own minor application, maybe a calendar or address book, for example. Things that are not too big, but still good enough to allow for failure without negatively impacting you. One highly recommended thing to do in the book is to create your own personal wiki, as you can use it to record what you learn. They are also nice since they can be simple, but still allows you to learn about things like HTTPS, REST, parsing, web design, etc. Sticking with this long enough will teach you about many things you many not have been exposed to otherwise, again creating an overall positive experience, because you will have some failure along the way, but how you overcame the failure is important. The book shows an email that Linus Torvalds saying that he is making a free OS based loosely off of minix, and those who know know where he went with this, and that is where we got Linux.

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

Expand Your Bandwidth

Similar to prior weeks, you have a basic set of skills, and your understanding of software development is narrow and small. Expanding your bandwidth allows you to further expand your horizons and learn more. The best step to solve this is to take in new information, but it is important to do so carefully, as it is easy to be overwhelmed in the information intake.

Some examples of ways to gather the new information is through following software development blogs, following software developers on social medias like Facebook and Twitter, and subscribing to a software development mailing list, just to name a few. There are also many hundreds of online courses and videos as well, so there is no shortage of information to be had. Following software developers can key you into new technologies before they become widely popular, which can give you a head start into the game before others. There are also national conferences that you could attend as well, and another great thing to do is to read any books some of the speakers have written in the past, so you can help get an idea of what they will be talking about and their software development history.

However, it is just as important to know when to expand your bandwidth then just how to as I explained above. It is possible to get stuck with the gathering of information, and it can easily happen where you get stuck researching and learning and never go back to creating any software. It is important to use this skill to accelerate your learning, but it is also important to not get stuck with the learning, learning is a means to an end, you must come back when you are done with the learning. Usually it is recommended to not spend more than a few months with this learning process, as that allows you to not get stuck in the learning process, as it is not too long, but it is also not short enough to the point where you do not learn much of anything at all.

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

Apprenticeship Patterns Blog Post 1

This week I would like to look at the “Confront Your Ignorance” pattern. I feel like this is always a good one to look at as despite how good of a programmer you might be, there is always something more to learn, and there is always something you don’t know.

This pattern means there are things you still need to learn/know, and some of these things are things that many others may already know, so it is expected of you to also have this knowledge.

I feel like it is always important to confront your ignorance, as there is still much to learn, even when you have seen a lot. This pattern is very similar to the “Expose Your Ignorance” pattern, but this one is about learning in private, so you do not need to hurt your pride by making others aware like in “Expose Your Ignorance”. However, it is still important to know to expose that ignorance as well, since always learning in private can have some negative side effects, like having failure be unacceptable instead of just another step of the learning process. You need to be able to learn and grow in a way that will positively affect you and those around you.

But should you choose to not learn in private, a great way to confront the ignorance is to ask questions, as many people may have already had the problem you are currently facing, and are hopefully happy to help you overcome the issue. A common cause of ignorance is focusing too heavily one one particular skill or context, which causes you to become ignorant of the other skills. One must be able to learn, and identify the areas of ignorance, and actively work towards reducing those areas.

You must also always be able to admit your faults, in this case admit that your knowledge is lacking, as how will anyone know your knowledge is lacking unless you tell them? This way, everyone can work together to achieve better learning. Of course, it may hurt your pride in the short term, but it is always better to be known for your willingness to learn more, than to know a lot about a few things.

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

Sprint 2 Retrospective

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint was primarily research, in particular the interactions between worker nodes and pods, and figuring out how we can install Keycloak onto our Kubernetes cluster.

For this sprint we tried to evenly distribute the workload as much as possible, so that no one was doing too much or too little. Since we had a total of 25 weight to complete this sprint, we tried to get everyone to do around 5 points worth of work, since 25/5=5. We did not put too much focus on how those 5 points were distributed, however, so someone could have done 2 2 weight issues, and 1 1 weight issue to get their 5, they could have done 1 2 weight and 3 1 weight, etc. All that really mattered was getting everything done and done well.

Overall, I cannot say much that did not go well, as everything went pretty smoothly throughout the sprint. I feel that if we continue with what we are doing going forward we will do well as a team.

We tried to communicate as much as possible during the sprint, and when we were not able to communicate in class, we either talked through Discord, or had Zoom meetings to talk and discuss. I feel this helped a lot throughout the sprint so that we all had a good idea of what was being worked on, where everyone was on what was being worked on, and what still needed to be worked on.

While it seemed to be somewhat the same for everyone else, I felt the workload balance of the work I did was very well balanced. I did not feel too overwhelmed at any given point, nor did I feel I had too little to do at any given point either. Everything felt just right, and I hope that we are able to continue with this type of workload balance going forward in the future in future sprints. I know that this sprint was primarily the research sprint, and that the future sprints will be heavier with more work than research, so I hope that we will still manage to find a good balance with the work that we need to do in those remaining sprints.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/39

The above link will take you to my research about how worker nodes and pods interact, and how a pod is a part of a node.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/30

The above issue here explains how we would configure our Kubernetes cluster to add Keycloak to it.

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

Sprint 1 Retrospective Blog Post

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint were adding files to our Documentation Repository, researched Ingress & Gateway, & researched RabbitMQ.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/3

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation

The above links will take you to the issue to add the files to the repository, along with the repository with the files added to it.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11

Here is the issue to research Gateway & Ingress, what they do and how we can take advantage of them.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/5

Lastly, I researched RabbitMQ and what it does and how we could use it.

I cannot think of much to add with regards to change, maybe add a bit more detail to my research posts, but otherwise I think everything was solid.

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

Apprenticeship Patterns, Chapter 1 & 2-6 Introducions

From the beginning of chapter 1, it does not surprise me that Google lists 61,800 references to the phrase “software craftsmanship”, with only a few of those being usable definitions. So many times when trying to look something up we have to parse through the search results and try to find what we actually want, because what comes up first and the rest might not exactly be what we are looking for. I also agree with the sections about being an apprentice, journeyman, and master, as to show that there is progress from where you started, and what it might look like as you continue to learn and grow throughout your software practices.

An apprenticeship pattern, as we learn, is an attempt to offer guidance to someone working with a model in ways in which they are trying to improve progress in their career. I like this definition, as it describes a pattern that we use to learn and grow throughout our software careers.

In the beginning of chapter 2 we read a story about an apprentice learning from a master, and how whenever the master would try to teach the apprentice something, the apprentice would cut off the master saying what he already knows about the subject. The master later tells the apprentice after overfilling his tea cup saying “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”. This is an analogy to how when learning from someone with greater experience than yourself, it is best to just learn from the master, and not try to interject with what you already know.

In the beginning of chapter 3 we learn about someone named Dave, who has certificates certifying that he knows what he was doing in various programming languages. We then learn about how Dave found some hackers online, and learned about their expertise in the field. Despite having certificates showing that he knew a lot, he felt his knowledge paled to the hackers’ knowledge. This shows, similar to the previous chapter, that there is always something to learn, not to get discouraged by feeling like you know so little, and always be inspired to learn more from others.

In chapter 4 we learn about having accurate self assessments. It is important to not become self satisfied with your success, as it is easy to feel like you are slightly better than most others in the field, and become discouraged from continuing to improve and get better. I like this, as I can easily see how most people can get absorbed in self satisfaction, and not want to continue to grow and improve.

In chapter 5 we learn about how in software development, there should be two activities, learning and communication. In this, it is important to always continue learning, and to always communicate with others in the field, as they can often see things you cannot. This allows you to be familiar with your weaknesses, which allows you to improve more and more.

Lastly, in chapter 6, we learn about how you yourself should be constructing your own curriculum through the vast, ever expanding resource of the internet. One must always be learning and practicing. It should not be up to others to assign what you must read and learn about, it should be up to you to continue on your path to always continue to learn and improve.

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

Thea’s Pantry

I found the architecture used in Thea’s Pantry interesting. It was nice to see the UML diagrams as they help tremendously with understanding how the architecture works. It is also nice seeing the individual pieces of the system, and then seeing them all together at the end, seeing the entire system come together. I also found the workflow interesting as well, having a new branch for every feature/fix/refractor, each being associated with a merge request when the branch is created. Then, using conventional commits, and commit merging. It is good to see this level of organization in the workflow process.

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

LibreFoodPantry

I found something interesting on the LibreFoodPantry website was the Code of Conduct. It was nice to see examples given of positive behavior, negative/unacceptable behavior, and the enforcement responsibilities, along with the scope and the enforcement of the Code of Conduct. It shows that there is enforcement in place to keep people of negative intentions out of the project. It is also nice to see Enforcement Guidelines in place to help correct any negative behavior, so that everyone gets the same things enforced, so there is no pick and choose. It shows that the community behind the LibreFoodPantry is good, in my opinion.

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