Apprenticeship Pattern Blog 7

 This blog is an extension of chapter 6 of the apprenticeship patterns which talks about creating your own curriculum. The message is that the software apprentice should come up with a plan on how they want to progressively learn and continue with their journey and profession. This is information I sincerely wish I had learnt earlier as I started programming. Over the years, I’ve used different frameworks to solve problems without really going deep into the specifics of those platforms. I just wanted to meet the software requirements of the particular project and move on to something else. Over the years, I have discovered knowledge gaps especially when I participate in projects that I did not build from group up. I've found myself in a situation where I can not confidently state what languages and frameworks I’m truly good at. However, after reading this chapter, I plan on making a “curriculum” of technology stacks I want to learn and master.
 
The writers are very considerate to mention that the number of books we need to read are increasing faster than we can read them. This is so true, and I would also add that the technologies being used are changing by the second as well and we need to stay relevant in this field. They also mention that some knowledge can only be found in physical paper version rather than the world wide web. Paper books require a certain amount of attention if someone is really serious about attaining the knowledge in them. I remember reading my first book on C programming by Paul and Harvey Deitel. I learnt a lot from it because I was excited fully immersed into acquiring the knowledge that was within. After this experience, I moved on to watching YouTube tutorials to enhance my knowledge and actually learnt a lot about other technologies.
 
Software craftsmanship is a journey of continuous learning but also rewarding to when you see the system performing as it was intended in the requirements. The book advises that we should pick books that give a broader understanding of the topic in question and then selecting books that drill down into the specific aspects of our interest. There exists plenty of free sources for some books and videos and it’s within our best interest to put these to use. This is my journey to take and I'm happy to be on it.

Sprint 3 Retrospective

 Sprint 3 was a much better experience compared to the previous two sprints. We had clear focus on what issues and epics needed to be completed to meet our goals. After completing my task of restructuring folders, it was time to move on to other things. I got a chance to learn about testing in chai. Chai is a node js library that can be used with other platforms such as Rails to perform software testing. It’s lightweight and easy to play and experiment with.

 

We were determined to put in all our efforts to achieve the tasks that were ahead of us, and I was given the task of creating a test runner for docker image. I wasn’t quite sure on how to approach this, but I asked for help from the other team that had done something that closely looked like what I would work on. Docker is an open platform for developing, shipping and running applications in a containerized environment. This means that even with different endpoint being used to develop software, they’ll all use the same specifications and environments. This helps to resolve issues whereby dependencies arising from being on a different operating system might cause incompatibilities leading to development delays and other undesirable situations. With docker, all developers use the same version numbers of required dependencies and environment.

 

The test runner runs tests on each commit that’s pushed to the branch via docker before it’s reviewed and merged to the main branch. This test phase helps to catch potential bugs and also ensure that the software meets the standards that have been set. Below is the link to the merged request of the test runner for docker images:

·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/19

The next task I had to work on was integrating the test with the pipeline. The pipeline was a major obstacle at first because it wasn’t working so all our tests failed miserably. We later discovered that our own server in the Reporting System was crushing on startup. The database kept running but the server was down. With this in the way, we couldn’t really get far, until one of our teammates got to fix the issue. Also, with the help of the Professor, we found out that our openapi.yaml file was in JSON format instead of YAML format. How did we get here? We were baffled by this but were able to get it under control. The link below is to the merged request of integrating the test to the pipeline:

·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/20

Such seeming minor details caused significant delays on how much we could accomplish as we couldn’t tell the reason why the system was behaving the way it did. We have learned to work closely as a group but also open to ask for help from other groups and the professor. Without their input we probably could have given up after a certain time. I congratulate my teammates for such great collaboration. 

 

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.

Sprint 1 Retrospective

Sprint 1 was huge learning opportunity for me especially as it incorporated the concept of a scrum master. Leading and working in a small team sounds like an easy task to do but that’s not always the case as we’ve explored throughout this semester. Each individual possessed different skills that we planned to exercise in making contributions to the project. Thea’s Food Pantry, an open source project runs on a micro-services architecture with several components. The three major components include; Reporting, Inventory and Guest Info System. Our group was assigned the Reporting System and I was assigned the task of mostly working on the backend portion.
 
Inside the backend service itself there were other pieces that had to be put in place such as development containers commonly referred to as devcontainers, updating from vanilla JavaScript to modern JavaScript connotations through the ‘use strict’ keyword and changing variable declarations from ‘var’ to ‘let’ or ‘const’ where applicable. Up to this point I had not encountered any significant obstacles as I’m about to elaborate. Below is the link to the issue that I worked on;

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/97 

 
We got introduced to the command ‘git squash’ which combines multiple commits into one. This was something new I had never encountered as a casual user of git. The general commands I had worked with previously included git add, git commit -m “Commit message”, git push, git status, git checkout, git reset –hard, git pull etc. Squash came in pretty handy when working on a branch and submitting multiple changes as one.
 
The next major thing I learned was working with the issues board and merge requests. In the beginning, theses were slightly hard to navigate as far as identifying what part of the code needed to be modified to satisfy and solve the issue at hand so it could be moved from in-process to needs review. Also, identifying what branch or version of the main source to work with was a major obstacle for me that I later learned to do correctly. We discovered that the proper way to contribute to the main project was by creating merge requests. Git merge requests automatically creates a branch that you can work on so you do not need to manually create one. This was valuable information we wish we had learned earlier. However, since this wasn’t the case, we had several manually created branches that ended up being a bit quirky to merge with the main project. Below is the link to the merged request I worked on;

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/16/diffs

 
Something I plan on being better at for this next sprint is to correctly examine and weigh issues and tasks that I assign myself. I had imagined that we would complete this project within three quarters of the semester and use the other quarter to make cosmetic changes to the software, but this hasn’t been the case. I also commit on closely working with my peers, by communicating effectively what and how I’m doing  as far as the project is concerned. My hope is that Sprint 2 will be much smoother and faster compared to Sprint 1.

Apprenticeship Pattern Blog 4

Chapter 4 of the apprenticeship mentions about developing new technical abilities, honing existing ones and building a strong foundation of technical knowledge. The authors mention that “The talented and hard-working apprenticeship must not become self-satisfied with his success”.  It is exciting to be proficient in a technology environment and build things while having fun with it, however, it’s more important that we do not become complacent in our abilities and stop learning about other frameworks. Versatility and flexibility are attitudes the craftsman should always possess. An example where I’m currently applying this is the containerization using Docker. For long I misinterpreted containerization to be the same as git version control but they’re actually different. In basic terms git is more about collaborating with others on a project while docker is more about applying the same development environment specifications across multiple end devices.

 

We also learn that the software craftsman should look out for opportunities to collaborate with exceptional developers in strong teams. Surrounding yourself with developers that are better than you helps identify areas you need to work on and introduces you to new ideas. I plan on attending coding hackathons in order to experience and see ideas other developers are working on.

 

The authors also mention about working on open-source software projects as a vital method for gaining technical knowledge. This also gives the opportunity to collaborate with seasoned engineers, learn about various technologies, and take part in a projects that will actually have an influence on the world. Newcomers start by contributing to simpler tasks as they learn and become more skilled, then slowly graduate to larger, more complex tasks. In Thea’s Food Pantry project, we’re continuing where other students left off. This is giving me an opinion of how future open-source projects could look like. We don’t have to start from scratch as the building blocks have already been put in place.

 

We also learn that humility and exposing our ignorance are great foundations of being a successful craftsman who's open and honest about what we don't know so we can learn from others.

 

To summarize the chapter, it goes like this: it’s important to continually learn and improve to gain the skills expected out of software craftsmen, to seek challenging projects, work on open-source projects and receive feedback and criticism from senior developers.