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.
Sunday, May 14, 2023
Thursday, May 4, 2023
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:
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:
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.
Subscribe to:
Posts (Atom)