Almost at the finish line!

We were able to achieve four to the five steps within the epic. Step 2 and 3 were very closely related and I managed to do them within one step. Creating the ordered list in config.yaml file allowed us to determine the order in which the features are installed rather than depending on the numbers that were prefixedin the indvidual feature files.

The final step, splitting the GitKit repository into KitDeploy and GitKit, is where I am at and it is quite challenging.

I decided to clone the GitKit into my on personal profile by making a repository, KitDeployTrial. KitDeployTrial would contain the eventual file structure that I would have in KitDeploy. After successfully doing this I came across a major roadblock which would not allow me to create new docker images as the pipeline structure had to be setup within the repository.

So I decided to abandon KitDeployTrial and create a new KitDeploy repository within HFOSSedu so that full functionality may be possible with the pipeline. I then moved the necessary files into the repository and the pipeline worked. I then pushed the changes to the GitKit repository but realized that the pipeline was not updating the image in the container repository.

With Professor Stoney’s and Professor Karl’s help I was able to understand how images worked and used the docker pull command to manually update the local image. I was therefore able to update the KitDeploy image locally and begun working on changing deploy.sh

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

This week I was able to make more progress in refactoring the Git Kit.

I was able to separate kit specific features from general features and I also managed to have deploy.sh read the features from the config.yaml file. Both of these while maintaining functiona
lity of the kit which I tested by deploying on git hub.

When it came to separating kit specific features from general features, I created a new folder to contain the kit specific features in the top-level directory. Afterward changes were made to
the deploy.sh so that it could look for the kit specific features in the kit specific directory rather than the general features directory. After making these adjustments, I deployed the git kit on GitHub and it worked successfully.

Having deploy.sh read the ordered list from the config.yaml file was slightly more challenging. After figuring out the order into which the features are installed, I replicated the same order in the config.yaml file. I separated them based on which function name. The next step was figuring out how yq reads the ordered list. After researching I figured out I could bring the ordered list as an array, I then created a for loop to iterate through the file names and then install the features through the deploy.sh file. After a couple of hours figuring out all this I tested the new structure and it worked!

It was a successful week, and I am glad that I continue to make progress in refactoring Git Kit.

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 am making progress!

Last week’s fresh start prooved to be more beneficial than I expected.

It made this week’s progress much easier. I was able to move deploy.sh to the top level directory which worked well after testing by deploying the FarmData2 GitKit on GitHub. After this worked I also moved the features directory to the top level directory and after minor changes in the deploy.sh file in the pre-install-features and install-features functions, I got it working. It was a huge step.

Having completed these tasks I am now complete with the first step within the epic that we had created.

I also managed to update the gold.raw image that is used in testing, as well as reinstating the original json files that were within the the features 6 and 7 directory. Finally I squashed all my inital commits into a single commit which has a message stating that i completed the first step in the epic.

The next step will now go deeper into separating the git kit specific feautes from the general features. Heading into some choppy waters!

New Lesson learned in scripting:
$(…) ${…}.
Parens are command substitution. Curlies are variable substitution.

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

Hit the first major obstacle in the project.

In my previous blog I had indicated that I would begin manually testing the GitKit by deploying it on Github. The first step was to look for the corresponding container to deploy from the registry. The professor he showed me exactly where the container was, it was tagged by my branch name. A new container is always generated when the pipeline is built with the same tag as the branch name.

At this is point is where I hit the roadblock. After trying to deploy the container I experienced errors. Considering the changes that I had made in trying to merge the deploy.sh files, I realized that I had started off on the wrong foot. I needed to start again, I needed a clean slate. After more retrys of deploying the container I realized that I had to make the tough choice of starting all over again. I deleted my branch and deleted the local files. I created a new branch.

A fresh start.

Rather than using the local test on the GitKit repository, I decided that a successful deploy on GitHub would by my means of testing. I immediately got to testing the new branch I created without making any changes, which worked. I then proceeded to merge deploy.sh, after careful evaluation I realized that the only important variable in the high level deploy.sh was KIT_PROJECT_PREFIX which I redefined in the FarmData2/deploy.sh. I commented out the original deploy.sh and pushed the changes.

I tested. It worked.

The next step I decided would be to begin working on the yaml file that would contain the configurations of the GitKit. After looking at the link that Prof. Stoney had recommended, I learnt how to use yq, a command line YAML processor, and implemented it in deploy.sh [export TARGET_ORG=”${yq ‘.TARGET_ORGANIZATION’ config.yaml}”]. After multiple tries to deploy the Git Kit I kept on running in to an error. I tried manipulating deploy.sh in various ways but it was unsuccessful. It wasn’t until I met with the professor that I realized that I had been trying to configure the wrong variable. TARGET_REPO,TARGET_COMMIT were the variables that I was to include in the configuration file. And after trying it worked!

I also managed to cut down the testing time by reducing the number of labels and issues being created in the JSON files under the features directory.

Despite it being a challenging, journey I feel like I am generally getting to understand the Git Kit system and making progress in refactoring it. The next step is now to move deploy.sh into the top-level directory as I progressively move the features directory to the top-level.

“Furthermore, it is an honors project” – Its going to be challenging

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

Over the week I began working on refactoring the Gitkit project. In the two weeks prior to this I worked alongside Prof. Karl and Dr. Stoney in developing the path I would take in refactoring the GitKit as welll as understanding the project itself. For the first sub-epic that I created link, I intended to create a new configuration file written in YAML, the first issue within the sub-epic was to work on the merging the deploy.sh files. One on the high level directory and the other within the FarmData2 directory. After reading through the code within both files and figuring out other areas in the de that had calls I proceeded to merge the files. The build command worked and so I proceeded to commit my work thinking I had aced it in one but the problems began….

The pipeline failed due to the wrong commit message syntax as well as a failed test. After checking previous merge requests done by other collaborators in the organization, I discovered that the commit messages had to be written in a conventional manner. Luckily, I remembered the syntax that we used earlier in my Software Capstone class and after using git commit –amend the pipline succeded. However, my tests would not pass, and so I spent the rest of my time trying to learn how the testing worked.

Today in my meeting with Prof. Karl today we were able to trouble shoot the testing and we resolved by moving the features directory into the highest level of the working directory. We also discovered that we should change the naming convention of the git kit environment. I will come up with a way to append the name of the project before the kit name so that we can have GitKits follow the [project name]-kit methodology. Back to testing, we realized the importance of the gold image in testing and ended up generating a new gold image which acted as a kind of checkpoint to ensure that we have a reference point as I make adjustments to the code. As we tinkered with the testing technique it led us to discover that at some point during refactoring the project I would have to do manual testing on the project to ensure that everything works and the gold image is right.

Overall, it was a good learning experience and a good refresher into the world of collaboration and opensource software. I hope to achieve more as the semster progresses.

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

Retrospect

The third and final sprint was much shorter than the first two sprints, however it is in this sprint that I achieved more that I could have expected. I worked on one issue that seemed to be more involving than I would have expected. On this issue I jumped on to help out Andrew Lam who had been experiencing some challenges on with Chai testing. link I also assisted in validating some merge requests that had been created and assisting in closing issues link2. These are some of the activities that I did on Gitlab during the course of the sprint

Something that worked really well during this sprint was the collaboration that took place. We all joined hands in the sprint to overcome the challenge that had been facing us with Chai. It was only shortly after that we realized that the Chai test were functional and correct and that it was the server that had an issue. We all joined hands and collaborated and scanned through the code and the file systems that we had and it was long after that we were able to get our server back up and running. That took us quite sometime and finally we got the test to validate correctly what the calls were requesting. Also our determination and focus to overcome the challange was something that worked really well. We utilized Discord and met outside class times inorder to make progress with the Chai issue.

I think that we would have done a better job as a team in understanding the role of the reporting system. Over the course of the two earlier sprints we got used to the idea of copy and pasting what was in the GuestInfo System. I believe this caught up to us when the server did not start up. To my realization, most of the critical files for the reporting system had been deleted and I had to go back into previous commits in order to retrive this files. We should have been more keen on understanding the function of the system in order to avoid removing the files that were important. This would also have been caught at the review stage as we validate a merge request but it also slipped through that filter.

Overall we did well as a team. Since the sprint was for a shorter duration and we had become more well versed with the system, there were no major challenges that we faced as a team. Our scrum master did a great job and we also communicated challenges that we were facing and jumped on to assist each other where need be. It has been a great experience working with the team this far and I have really leanrt how to work with agile in a team and work with a team in agile. I couldn’t have asked for a better team.

One thing that I could make better about myself is teaching others what I have been able to learn. Learning how to document how I was able to solve a task or complete an issue is something that I think will be beneficial not only to me but others as well. By documenting what I have learnt others might be able to learn some troubleshooting skills such as using breakpoints with debuggin tools. For others, it might be a light bulb that might allow them to break through the bug that they are facing. This is one thing that I think working on will allow help others in their programming tasks.

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

Retrospect

The third and final sprint was much shorter than the first two sprints, however it is in this sprint that I achieved more that I could have expected. I worked on one issue that seemed to be more involving than I would have expected. On this issue I jumped on to help out Andrew Lam who had been experiencing some challenges on with Chai testing. link I also assisted in validating some merge requests that had been created and assisting in closing issues link2. These are some of the activities that I did on Gitlab during the course of the sprint

Something that worked really well during this sprint was the collaboration that took place. We all joined hands in the sprint to overcome the challenge that had been facing us with Chai. It was only shortly after that we realized that the Chai test were functional and correct and that it was the server that had an issue. We all joined hands and collaborated and scanned through the code and the file systems that we had and it was long after that we were able to get our server back up and running. That took us quite sometime and finally we got the test to validate correctly what the calls were requesting. Also our determination and focus to overcome the challange was something that worked really well. We utilized Discord and met outside class times inorder to make progress with the Chai issue.

I think that we would have done a better job as a team in understanding the role of the reporting system. Over the course of the two earlier sprints we got used to the idea of copy and pasting what was in the GuestInfo System. I believe this caught up to us when the server did not start up. To my realization, most of the critical files for the reporting system had been deleted and I had to go back into previous commits in order to retrive this files. We should have been more keen on understanding the function of the system in order to avoid removing the files that were important. This would also have been caught at the review stage as we validate a merge request but it also slipped through that filter.

Overall we did well as a team. Since the sprint was for a shorter duration and we had become more well versed with the system, there were no major challenges that we faced as a team. Our scrum master did a great job and we also communicated challenges that we were facing and jumped on to assist each other where need be. It has been a great experience working with the team this far and I have really leanrt how to work with agile in a team and work with a team in agile. I couldn’t have asked for a better team.

One thing that I could make better about myself is teaching others what I have been able to learn. Learning how to document how I was able to solve a task or complete an issue is something that I think will be beneficial not only to me but others as well. By documenting what I have learnt others might be able to learn some troubleshooting skills such as using breakpoints with debuggin tools. For others, it might be a light bulb that might allow them to break through the bug that they are facing. This is one thing that I think working on will allow help others in their programming tasks.

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

Retrospect

The second sprint in my view was more efficient than the first. Because of a good understanding of how the systems worked together and the end goal of the project we were able to work smarter as a team and fasted on individual tasks. Some of the activity I did was jumping on my tima members issues to assist, link as well as link2. I also worked on reviewing merge request that other team members created link3 this among others gave me a better understanding of the reporting system and how the different parts fit in together.

Again our communication carried us through most of the sprint. The stand up meetings, chats on discord and our activity on Gitlab allowed us to make the most of the sprint. Through communication we were able to share what we had learned, which in turn helped those who were going through related challenges to come up with more ideas on how to tackle the problem at hand. Communication also allowed us to jump on others issues and assist them. At the moment I am working with Andrew on a issue that has been challenging him for a while. He was able to share the knowledge he had gained so far which helped me understand what has worked and what has not. Through collaboration we have been able to achieve much more. I also got assistance from Scott as I was working on the updating the pipeline/CI and he helped me understand more about how docker is involved in the pipeline/CI process. Finally we also worked on more issues outside class which we had agreed to do during the last retrospective. This improved our velocity greatly!

Some of the limitations we had came in while testing, specifically chai. Our unfamiliarity with chai got the better of us as we spent more time trying to understand how chai works than actually implementing what we learnt on our sub-system. Also as I had mentioned earlier, understaing how docker is involved in creating images as well as the managing the pipleine took us quite sometime as we had to learn how the tools under Libre Food Pantry are used.

We worked generally well as a team throughout the sprint. This being our second sprint I believe that we worked exceptionally well as a team. Now that we are more familiar with the system that we are working on, I believe that we can do a better job in breaking down epics into sub-epics and issues as well as weighting them. This has been a challenge initially as we did not understand how the system worked. But now I believe that we can do a better job in assigning weights to the issues. When we failed to break down the issues into its core components, it slowed us down as we had to reorganize ourselves in understanding what truly we are working on. Over weighted issues gave us a false sense of progress while under weighted issues gave us less that we had put into learning about the issue.

As an individual I believe that I could do better on my productivity and understanding. Working through the issues as soon as I got a breakthrough I would not go deeper in understanding more about the concept and how it works. All this ties to my productivity that even though I di d well, I believe that I could do better in aiding the team in achieving success in the long term.

The second sprint was very productive overall and I am glad to have gotten a hang of things especially concering scrum and how it an agile framework where you learn as you 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 applies to those who have continued to master their skills. They have been noticed by the management and because of working exceptionally they are offered a promotion, a reward that takes them higher within their company. Even though the opportunity looks lucrative there is a downside to the open door. You end up programming less and you get diverted from your goal of becoming a master at your skills. The author’s recommend sticking to your current position. Instead of accepting opportunities that might lead you further away from your goal, you can request for a pay rise or become an “internal consultant”. This will allow you to still follow your goals while at the same time accepting reward for your hard work. Even though it might seem selfish for that duration it might help you become a more experience programmer and you can in turn help out more workers. As an alternative you can take up the position and work with the other pattern, using your title. Either way you have to have the end goal in mind of where you intend to be.

Reflection

Staying in the trenches was a pretty unique pattern advising us to go contrary to what might look attractive or flashy. In this age that we live in being promoted or going higher in rank especially at your work place is considered a big step. However, being determined enough to focus on what is coming ahead and saying no to a promotion is of a more honrable course. The lure of success might easily lead one from fully realizing their potential. It is improtant to make the right call at different point in your life and this is determined by what your goal is. It’s therefore a good reminder that based of the goals that you have set in life you might be required to make huge sacrifices including saying no inorder to lock in on the goals that you have set in life It’s therefore a good reminder that based of the goals that you have set in life you might be required to make huge sacrifices including saying no inorder to lock in on the goals that you have set in life.

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

T## Summary
Ever got stuck? Need that extra umph to carry you through the rough patch that you are in? Feel like you don’t know what you are doing anymore? This pattern can be the solution to your problem! The authors introduce us to this pattern that could best be summarized as, “Someitmes you need ot take one step back in order ot take two steps forward.” In those moments when you feel that you are not doing enough the authors recommend that you go back, back to that which you are good in doing. They recommend using this pattern especially when you feel as if you have streched yourself thin. Taking a step back allows one to remind themselves of the accomplishments that they have made in the past and gives them some extra motivation to carry on with the challenging part of the project that they are undertaking.

However, the author warns us that this pattern if not carefully managed might lead you futher back that you had initially intended. Instead of the two steps forward that is the ultimate goal of this reflection. One might go back and find it very hard to move forward if you don’t relaize what you went back for. It might lead to double the trouble compared to actually reducing the roadblocks that are currently in your way.

Reflection

Another important concept not only in the programming world but life in general. As we continue to progress with our careers in Software development, roadblock are unavoidable. In times when new ideas or new projects come up it is a huge challenge to learn something new while still making advancements at the same pace. Sometimes it might require a pause and rewind button. The same way we look through our journals at various points in our lives to lead us through a tough time or reminding us of how far we have come. Therefore it will be important at certain point in our careers to go back to that which we feel comfortable and well apt in.

Learning through what others have overcome or what we have personally overcome are great motivators into leading us into our next level. Empowering us to unearth that hidden strength, creativity and vigour that stays dormant within 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.