Summary

The authors introduce this pattern of Exposing your ignorance, in this pattern they talk about the expectations that the world has especially those in the workplace have of you. They expect you to have a degree of competence and boldness of the tasks that you are assigned. However, deep within you lack the expertise and the know how of doing what you have been tasked to do. You therefore land in a cross-roads. In this cross-roads you have an option to shed light to your weakness through asking questions and letting your team members and others around you to know that you are learning or, you have an option of hiding your inadequacy.

As we discover new technologies and have to let go of all that we have learnt we become exposed as we are making new paths in our lives. The authors recommend that the best way to overcome your ignorance is to ask questions. Even though asking question might point that you are incompetent it give you an opportunity to learn. Learning to learn allows people to see you in you journey as you grow from apprentice to master.

By following this path of exposing your ingnorance you will be able to learn so much more technologies and expose yourself to more skills. The authors then call us to action to list down five things that don’t really understand about your work.

Reflection

I like the principle of this pattern as it encourages us to face our weaknesses and faults. Something that most of us are not used to doing. I believe that exposing our ignorance allows us to learn the right way. By exposing our ignorance we get a chance to understand waht we are dealing with right down straight to the root of the problem be it internal or external problems.
I belive that this will be an important principle heading into the work world and even as we ascend the height of our careers. It will give me an opportunity to grasp core concepts and even the ability to do better even as I continue to progress.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Summary

This pattern addresses the call to dive deeper, to challenge our selves to do that which we have not done beofore in order to get out of the mundane. As we continue to progress our skills we get to a point where we become proficient but the positions that we have been placed in only continue to focus on specific skills that we have gained leaving the rest to “decay” as they are not practiced. Jumping in at the deep end asks us to present our selves to opportunites that might seem challenging or beyond normal for us. A quote that summarizes the authors point well is, “Risks are opportunities seen through the half-shut eyes of fear.” Despite the lack of ability that might seem to hinder us we should give these opportunities a try. But we should try wisely, as the author advices that we should think of a way to escape when the water level get above our heads. Using other patterns such as finding mentors, kindred spirits and feedback loops this allows us to navigate out of situations where we are drowning. The author calls us to actoin by asking us to gauge the projects we have done so far and for the next project, step it up a notch to enable us to get to our next level.

Reflection

The author’s offer valid points as to how important it is to challenge ourselves by putting ourselves in the playing field. By putting ourselves in situations that we have not been in before we bring to life other areas of our lives and allow ourselves to discover potential within us that has been hidden by fear. The idea of having a checkpoint/safepoint where you can head back to when all crumbles is also very important. It is like having a lifeguard watching the pool as you jump into it.

It is a concept I see fit in my journey as I grow from an apprentice into higher roles of that of a craftsman and master. Once in a while I will jump in the deep end and discover my abilities and hope to grow from them even in failure or success.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

At the end of the first sprint our team has become more united and have continually learnt how to work together. Some of the activity that I did on my gitlab include, merging and approving request as in the link https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/3, https://gitlab.com/dashboard/merge_requests?scope=all&state=all&assignee_username=11kaizen this allowed the changes made to the branches of the reporting backend to be consolidataed and put into the main branch. I also used gitlab in picking up issues and checking the status of other issues that were begin worked on https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/-/boards

I was really impressed of the way we communicated with each other throughout the sprint. Despite this being the first time that we worked together, for most us. We were able to have healthy communication. This helped us overcome challenges that had faced most us during the sprint. Utilizing platfroms such as discord and personal chats also allowed us to know when one of the members would not be able to make it for the class session. We also relied heavily on each other when we encountered any road blocks as we worked on the issues assigned to us. In an example, the pipeline which had a number of us stuck required almost all of us to jump on that one issue before we continued with the issues that had been assigned to us. We also shared prior knowledge especially in gitlab and its working which allowed us to all be on the same boat when it comes to saving the work that we had done using commands such as git stash among others. Also students like Anesti and Andrew who had stayed for a while since doing their software, design and architecture class were able to catch up on the structure of Thea’s Pantry thanks to assistance from all the other team members.

Generally we did well, but I belive that we could do a better job in the distribution of tasks. We could have specific people work on roles that are related, example one person could specialize in tasks related to the Api, front end or backend. Also our lack of experience cost us in minor ways such as breaking down the epics into issues and also the in the process of assigning weights of issues. We were also over ambitious as we thought that we could accomplish more issues than we acutally could. Some of us ended up taking too many issues which eventually we had to return as we couldn’t work on them all. I also realized that not most of us are not active and frequent users of Discord, some of the updates shared would be realized slightly before we met which led us to preferring to create a chat group instead.

Having completed the sprint short of the number of weights that we took, I expected myself to have closed more issues considering my understanding of the tasks at hand. I spent more time in class assisting my classmates rather than working on the issues that I had assigned myself. Also, I would have accomplished closing more issues if I had dedicated more time outside class to work on the issues that we had been assigned as a team. Now that I am now more familar with the structure and the working of the reporting system I expect myself to handle most of the issues that we had in the first sprint faster and more efficiently.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

At the end of the first sprint our team has become more united and have continually learnt how to work together. Some of the activity that I did on my gitlab include, merging and approving request as in the link https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/3, https://gitlab.com/dashboard/merge_requests?scope=all&state=all&assignee_username=11kaizen this allowed the changes made to the branches of the reporting backend to be consolidataed and put into the main branch. I also used gitlab in picking up issues and checking the status of other issues that were begin worked on https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/-/boards

I was really impressed of the way we communicated with each other throughout the sprint. Despite this being the first time that we worked together, for most us. We were able to have healthy communication. This helped us overcome challenges that had faced most us during the sprint. Utilizing platfroms such as discord and personal chats also allowed us to know when one of the members would not be able to make it for the class session. We also relied heavily on each other when we encountered any road blocks as we worked on the issues assigned to us. In an example, the pipeline which had a number of us stuck required almost all of us to jump on that one issue before we continued with the issues that had been assigned to us. We also shared prior knowledge especially in gitlab and its working which allowed us to all be on the same boat when it comes to saving the work that we had done using commands such as git stash among others. Also students like Anesti and Andrew who had stayed for a while since doing their software, design and architecture class were able to catch up on the structure of Thea’s Pantry thanks to assistance from all the other team members.

Generally we did well, but I belive that we could do a better job in the distribution of tasks. We could have specific people work on roles that are related, example one person could specialize in tasks related to the Api, front end or backend. Also our lack of experience cost us in minor ways such as breaking down the epics into issues and also the in the process of assigning weights of issues. We were also over ambitious as we thought that we could accomplish more issues than we acutally could. Some of us ended up taking too many issues which eventually we had to return as we couldn’t work on them all. I also realized that not most of us are not active and frequent users of Discord, some of the updates shared would be realized slightly before we met which led us to preferring to create a chat group instead.

Having completed the sprint short of the number of weights that we took, I expected myself to have closed more issues considering my understanding of the tasks at hand. I spent more time in class assisting my classmates rather than working on the issues that I had assigned myself. Also, I would have accomplished closing more issues if I had dedicated more time outside class to work on the issues that we had been assigned as a team. Now that I am now more familar with the structure and the working of the reporting system I expect myself to handle most of the issues that we had in the first sprint faster and more efficiently.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Summary

This is one of the patterns that the authors recommend in the second chapter of the book. The white belt refers to the lowest level in ranking in certain competitions, the highest being a black belt.

The authors use this analogy when one is trying to learn something new within their field of expertise. The learners have to bring themselves to a point of starting the learning process all over again forgetting any prior knowledge that they may have in that field.

This allows them to learn how to work with the new concepts in the best way possible and not limiting themselves due to prior knowledge. Another advantage the authors mention is that it helps you learn faster. You may look foolish for a while even though you are skilled but in the long run you will be able to become a better master of the new skill that you are learning.

The example of the program given was a great example of how wearing white belt may help your understanding of the new concepts. The algorithm was designed to print a set of six distinct number from 1 to 49. Going in with prior knowledge the algorithm made would have been much longer compared to when you have a new white belt approach to learning the language.

In the action part the also shows how important it is that we have others who have gone ahead of us guide us as we learn the new skills in our misunderstanding.

Reactions

The pattern described is very important and vital to growth, growth in the right way as you learn new skills and add to your skill set. It might be hard for you to become foolish for a short while but the gains are more benficial in the end run.

This pattern can be widely applied not only in programming but life in general. Most times we end up learning how to do new things but due to knowledge that we have prior it limits us from fully learning and embracing the new skill. A white belt approach enables us to learn faster and have a better understanding of the topic at hand.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

##Summary
This pattern talks about the ups and down of the journey to be a master at the craft of programming and how to remain on the long road despite the many challenges I may face. Sometimes “working in hte trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently over chaotic or constraining.”

The author prepares us by telling us that there will be days that we will expect days where we have an easy time programming. In other times we will be going through a lot in some nasty projects that we undertake, your commitment will be questioned. It is important to remember what motivates you for the long road. For some it is motivation by titles and money, for others the enjoyment of programming will be their driving motivation, for others working on open source softwares will improve their reputation within the programming community.

After a couple of examples the authors ask us to rediscover our motivations by listing them down and using that list of motivations to keep us going even when times get tough.

##Reflection
Sustainable Motivations are important especially when the journey is long, i believe that this will be an important part of my career journey to constantly remind me as to why I am doing what I am doing. That pattern has reinforced the importance of me understanding why I do what I am doing. On the point of having money as a primary motivation in you career I find it had to accept it. I think it would be foolish to run after money as you will end up loosing so much more in pursuit of money. As the author mentions follow your passions and then money will come to you effortlessly.

It is important to remember the how sustainable motivations can continually recharge and re-energize us for the long journey that is ahead of us.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Summary

The long road addresses the microwave nature of the generation and times that we live in. We all expect to get good or be ready within a short time, we are not instant noodles though! The authors talk about realizing the journey that is ahead of us as developers. They challenge us to look to growing our skills rather than running after money, positions and titles. Being a master craftsman requires dedication and commitment similar to how Linus Tovralds came up with unix. The author re-iterates that the “long road” is not for the faint hearted and it requires a lot fo commitment and dedication. It is commitment and dedication that we will be able to do what is considered extraordinary. Realize the journey ahead of you and start the process of boiling to get the best broth out of you! However, it is important to notice that the long road is not for everyone and the authors offer a different pattern for those who will not be able to go for the long road.

Reactions

It is good to focus more on the bigger picture, the journey that is ahead of my self rather than looking to instant gratification. The activity at the end of the pattern was quite thought provoking. In my future I would mostly think about stability in different areas of my life, that activity made me think about my skills rather than the positions or the titles that I am hoping to gain by then. It was also interesting to learn that the same way we are loosing culture and due to mordernization, we are also loosing important lessons that veterans in our field have learnt. Floods of people are rushing into computer related fields just for the money and the importance of building skills and experience is now becoming something of the past.

My future will definitely change as a result of the pattern that I have learned today. Realizing the long road that is ahead of me I will focus more on growing my skills and expereince rather than running after positions and titles.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Just from reading the first chapter of the book my desire to go further into going deeper into Computer Science was rekindled. The book is really well organized and very well curated. The length the authors go just to explain how they came to choose the word apprenticeship as well its definition is very well done. A couple of things stood out to me as I read the first chapter, first of all is that the authors are really well experienced and unlike conventional writers, they give a good oversight of what is need out in the job market and how best to prepare ourselves. Also they have really weighty insights that really apply to us as students, to be pragmatic rather than dogmatic and to always continue to grow and advance. Finally, Apprentice, journeyman and Master analogy was very helpful to understand the various levels of growth.

As I read through the introductions of the chapters 2 – 6 i was challenged by some, if not all, of the concept that the authors had come up with. Being an apt learner the quote, “Be the lion’s tail rather that the fox’s head,” really pushed me to think beyond the level that I am in. I have become, overtime, comfortable in the “pond” i am in forgetting that there are many other ponds out there and potentially bigger fish than I.

At the point that i am in Chapter 2 would be most relevant to me. The authors breakdown principles that seem really relevant to me especially as i establish myself within the field of computing. It is easy to feel content having learnt so much but it is important to always seek new ways of learning and improving thy self. The concepts shared in the book are too importatnt to disagree with they all are important to my growth as a scientist.

Finally, a important concept that I am reminded of in the book is that of community over individuality. No man is an island and we are all dependent on others be it better than ourselves or those following in our footsteps. In teaching we learn better, in learning we grow more so it is important to be a part of group or a community that grow together.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

I chose to write about licensing because it is a topic that is least explored by most students. Since Libre Food Pantry is an open source software its licensing is pretty much similar to Linux’s licenses. Libre Food Pantry is formed on the foundations of General Public License, that are reffered to as the four freedoms. The software remains free to all no matter the modifications or changes in ownership that are made to it. GPLv3 is an improved version of the original GPL to keep ip upto date with newer policies such as the Digital Millenium Copyright Act.

First of all I am impressed by how well documented the software is, the explanations within the readme are concise. After exploring the architecture of Thea’s Food Pantry, I am curious to see how we will be able to intergrate our work together considering that we are three different groups working on standalone components of the software. The workflow section was also fun to read about. The sequence of events were the actual ones that we took as we did the first activity in class. I think that overall it will be a great experience working on Thea’s Pantry as it will prepare us for real world application I look forward to a productive semester!

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Why I chose this post

This post intrigued me as it talked about microservices and since we had worked with the microservices that are makeup Thea’s Pantry it was a great opportunity to learn something new concerning microservices. Saga pattern was also a new concept that I had not heard or implemented before. Considering earlier posts that I had done with Friedrichsen I was sure that he would give good and relevant examples to understand the topic.

Summary of the post

Friedrichsen begins by introducing the concept, saga pattern. He describes it as, “if you have a transaction that spans multiple services and thier database, do not use distributed transaction. User the Saga pattern instead: Call the affected services in a row – tupically by using events for activity propagation.”

The author then goes to explain how the saga pattern might lead to limitation within a microservices systems due to technical errors. Despite the ability of the saga pattern to cover roll backs, Freidrichsen talks about how if a roll back fails it might lead to larger errors which cannot be solved. The main technique used to handle technical errors is to have a copy of the changes that were to be applied, go back to the last checkpoint by loading the last snapshot and then retrying application of the changes while avoiding the potential error that initially led to the technical error.

Saga’s pattern strength is in recovering from business error rather than technical errors. Friedrichsen states that recovering from technical error invovles a two layer approach where there is a lower layer which is hidden from the upper business layer. Also Friedrichsen cautions that if the saga pattern is used too often there might be an existing design smell within the system.

Reflection and Applicaition

As I have learnt about how important it is to consider the limitations and the advantages of using certain design patterns. In this case the strength of the saga pattern was in handling business errors but its downside was in handing technical errors. Also frequent application of a certain design might be a sign of an underlying problems which might require diagnosis. I also learnt of how the business and the technical layer can interact and work together and how to hide the functionality of the technical layer from the business layer.

I would apply the concepts that I have learnt from this post as I design systems which involve microservices. I will be careful to examine the pros and cons that different technologies might have before implementing them and relying on them to carry out roles within the entire system.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.