Apprenticeship Patterns Blog 6

 Chapter 6 of the Apprenticeship Patterns titled Construct Your curriculum was very insightful to me. It teaches ways on how to keep track of the progress that an aspiring software craftsman is making over a period of time. I believe that perhaps if I had received the knowledge shared in this chapter, I would have been better organized and learned much more than I currently do. The chapter starts off by recognizing that one can learn everything at once but instead by making smaller progressive accomplishments to achieve a huge task.
 
The first concept shared was creating a reading list. This helps the apprentice to keep track of the books they’ve read, currently are reading and what they plan on reading next. Personally, I’ve read several programming books but never really thought about keeping track of them, however, I plan on maintaining a reading list so I can plan systematically and be able to test myself on the knowledge I acquire in the material read.
 
The author also encourages that we read constantly and focusing our thirst for learning on consuming as much of the written word as possible. Blogs, podcasts, audio books are also good, but emphasis is highly placed on the physical books. I believe having a book in your hand reduces the chances of distraction compared to the other forms especially audiobooks where the listener is tempted to multi-task on activities. This eventually reduces productivity and retention of the information being shared. This concept coupled with creating a reading list look like a great way for me to go.
 
Moving on to digging deeper, I agree with the author that we live in a world of tight deadlines and complex software projects that use a multitude of tools and we find ourselves not having enough time to learn enough a given platform that we are working with. Instead, we resort to selecting a handful of tutorials and libraries to come up with a solution. This works most of the times, but we’re actually limited when other issues arouse from the said solution we created. An example I interfaced was when I worked on a project where we had to access data using an id of the object in the database. The id would be passed into the URL of the http request in plain text which was a security vulnerability for the database. We were successful in accessing the data but exposing the id of the data object was not a prudent idea at all. This amount of technical debt is dangerous but happens too often as project managers want to quickly ship products to the client. The major problem, however, is the difficulty that comes with maintaining such code as it may turn out that corners were cut and simplified complex issues, the author noted. I agree with this, and that things could also turn out worse in case of clients’ data being leaked resulting into unfavorable situations such as lawsuits.

Spring 2 Retrospective

After completing Sprint 1, receiving feedback from my colleagues and learning more about the system, and git I felt more confident with my contributions to the overall project. In line with what I did during the previous sprint which was restructuring the backend folder, this time around I would restructure the API folder. Below is the link to the restructuring issue. You’ll realize that we used the same issue for backend as well. That wasn’t intentional but we stuck with it.
·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/97
 
Restructuring is quite a sensitive job and requires special attention in my opinion since the changes submitted would literally affect everyone’s work. I’ll give an example that we went through as a team. During my work, I made a poor judgement about a file named package.json and deleted it. This file contained specifications of some of the development and release dependencies. At the moment, I thought this wasn’t a much-needed file hence the reason I removed it.
 
After several other modifications, moving of files and folders I created a merge request for my branch. This merge request did not pass the pipeline. I shared this with my colleagues, and we mostly thought it was because the pipeline hadn’t been customized to correctly analyze our work. Later on, my work would be merged despite the pipeline failure. This was a terrible mistake and I’ll explain how we got it fixed. We collectively decided to revert this merge and take a closer look into the issue. This was the first step into the right direction. The reason why I had pushed for this request to be merged was because I thought it would be great for everyone to work with an updated file structure.
 
We started taking pipeline failures seriously, and later one, a teammate would figure out how to fix the pipeline and everything worked better from then going forward. This was a great breakthrough even though my commits were failing, it was nice to know that other’s had theirs passed.
 
With further investigation and reading through the logs produced by the pipeline, I noticed that I had skipped a statement that said, “…couldn’t find package.json file…” It was at this moment that I realized that deleting the stated file was a bad idea and now had to reinstate it. All teammates who had pulled in the latest changes except one, had already lost this file because my previous merge had deleted it. It was from him that I got the package.json file again and reinstated it. The pipeline stopped failing and started passing with all my commits that followed. We were in a better position than before where it was completely failing. Below is the link to the merged request;
·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/merge_requests/15
 
Moving on, I plan on assisting my teammates who seem to be having a little struggle with their portion of the system. Specifically, I want to participate in the creation of tests using Chai Script. I believe it will be a great learning experience for me.
 
In conclusion, Sprint 2 has been a great experience for me especially by being caution when it comes to restructuring development files and folders.
 

Apprenticeship Pattern Blog 5

From chapter 5 of The Apprenticeship Patterns by Dave Hoover and Adewale Oshineye we see that most of the software craftsmanship patterns are inter-related. This chapter is titled ‘Perpetual Learning’ to mean that software developers must continuously work towards gaining and improving practical, crucial skills to build confidence, value and progress in the field. I agree with this approach, and I plan on investing time in the mastery of some of the programming languages we’ve been taught at school such as Java, JavaScript. It’s often said that a journey of a thousand starts with the first step. Therefore, daily practice for me is that first step in my software craftsmanship. The author beautifully lays it by saying, “…concrete skills, an apprentice must also learn how to learn, for the transition to journeyman will certainly not remove the need for learning…” I agree with this approach and as I've mentioned in other blogs, it is challenging sometimes but worth the pursuit.

 

We also see that identifying skills that are required in one’s craftsmanship facilitates setting up clear targets to be achieved. Technical skills can be hard at times to comprehend but with dedication anything can be achieved. For instance, since I’m interested in created in APIs, web systems and user facing applications, it’s relevant to learn Java, JavaScript and VueJS. Knowing that these are the requirements, I can efficiently dedicate my time towards platforms that achieve the set objectives. Practical learning solutions offered include signing up for Google Reader or another blog aggregator, following some software luminaries on twitter, subscription to moderately high-traffic online mailing lists, joining a newly formed local user group that is excited about new technologies. I personally, I'm a fan of the Software Engineering daily, however, adding Google Reader would also be a great addition.

 

We’ve seen in previous patterns that simply taking on simple tasks and fully mastering them before tacking complex projects continues to be very helpful. I'd say that documentation is always the first place to start when it comes to learning a new platform or technology. I intend to use this pattern to learn more about document-oriented databases such as MongoDB since they have faster transaction performance and data persistence. I know that with continuous practice comes resistance but it’s encouraged within the book to retreat into competence by taking a step back from overwhelming challenges and focusing skills in a specific area.