Author Archives: Kelvin Nina

Sprint-3 Retrospective

Going into Sprint 3, we completed a majority of the issues that we wanted to get out of the way except for backend testing. We had already put in a lot of time and effort trying to get the test-runner to work but it was still facing some issues. 

It was having some issues running on other computers and sometimes the test would fail because it would start too early for the backend server thus we had to implement a way to delay the test-runner container so that the backend server could finish processing.

Despite the goal of the sprint is to clean up any loose ends, it was still important for us to finish any issues started and close off any issues that we couldn’t get to. Stepping back from backend testing I decided that it was best for me to finish the “Set up GuestInfoIntegration” Epic this meant I had to:

After getting those finished it was time for me to get back to working on some testing. The test-runner was still having issues, and it was difficult for me to find a solution so that the test-runner script wouldn’t start too early while the backed server was loading, but eventually, the team thought it was best for both docker-compose files to be put together. Doing this, I can insert a health check on the test-runner container so that it can check if the backend or the Mongodb was completed before running. Before we had inserted a “sleep” right between the docker-compose running the backend server and the docker-compose running the test-runner container. This was in the test. sh. I decided to work on some tests as well, In the test-runner remote branch that we merged in the main, I made sure that the test will return the right status code and error messages. It’s worth noting that the test was implemented when working on the issue “Add HTTP request testing using npm test script”. But have been revised in the test-runner branch to better fit our designs list on the issues below:

The listed issues also have been designed so that when the next group picks up the project then they will be able to see what we as a team were planning when looking at our test.

The test-runner merge is also modified to work with the pipeline and the test stage will react if something is wrong with the test. 

When it comes to clean-up we went ahead and finished up all the issues that were working and closed off any other issues that weren’t going to get into. Any branches that were left over have been deleted and merged and all the finished epics are closed off while the unfinished ones have been moved to open.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Sprint 2 – Retrospective

The goal for sprint 2 was to maximize our production. The team and I wanted to get more issues done, at least more issues done than the last sprint. Compared to the previous sprint, we got way more issues and weight done this time. What worked well for us this time was to look over any current and new issues and order them so that the easier/urgent epics were done first, and then we set aside the epics that would take a little bit longer. 

The first issue I started to work on was refactoring the API file directory structure and infrastructure. So the first issue I tackled was collapsing all “YAML contents in /specification to a single/specification/open API.yaml file.” After that, I worked on disabling the build stage in the .gitlab-ci.yaml, which was pretty easy for me because I did a similar issue while working on the guestinfointegration, and I also worked on modifying the to validate the open API.yaml.

The second epic I worked on was to “Convert all Docker images to build multiarchitecture images” To complete this, I had to:

 I worked on the front end while my other team member did this to the backend. We could quickly get this done using the information in

After getting these two epics done, the remaining epics we had were ones that we could only complete partially in sprint 1. The next epic we wanted to achieve was the Evaluate and Improve API epic. The work I did for this epic included the following:

Finally, we could get back to backend testing after evaluating the API. A big problem we faced was how to test HTTP methods in the first place, so while doing some research, I found a plugin called “Chai-HTTP,” which allowed us to test HTTP requests using the npm test script that Liam provided in the first sprint. While we still needed to figure out how to get the test runner to work with Docker, having the ability to work on the test without having the test runner was an excellent way to get everyone involved in this epic. I was able to work on designing a test to create guests and list guests. And the test runner that will allow us to run these issues is currently being worked on with help from Noelan from the Inventory system since they are also trying to get it up and running. While developing the test runner allowed me to get more familiar with Docker.

As an individual, I am delighted with how I did this sprint and hope to ride this wave onto sprint 3. I planned to get two or more weights done weekly and ensured a specific timeframe to finish most epics in the team. Unfortunately, we didn’t get backend testing done, but I’m more confident that in sprint three we will complete it now that the test runner is almost done. 

As a team, we need to figure out a system so that everyone can lend a hand. Especially towards the end, we only had a few issues, or sometimes we would have to stop production because of one issue. In this case, it was the test runner for the backend. I’m hoping this will be avoided in sprint 3. 

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

The Key To Having Competence

When I was in trade school, I had a carpentry teacher who always emphasized the importance of having some sort of competence in whatever is being taught. Having this knowledge is the difference between knowing what to do in a certain project or being absolutely lost. The teacher would advise the other carpentry students, and even myself, about recollecting knowledge of what has been learned or what is fundamental. This pattern talks about what someone can do when faced with being overwhelmed by a project. For the most part, what I learned back in trade school is similar to how this pattern is explained. Although the statement that this pattern is for people who have stretched themselves far beyond their abilities is something I disagree with. In most cases, this can be applied to almost anybody, whether they are an apprentice or journeyman.

Even though it’s hard to put an apprentice in a position that sees them stacking opportunities, it’s not impossible. From there, it is fair to assume that the apprentice is not completely lost in the water and must come back to some prior knowledge to complete the task at hand. Many times I’ve been faced with a project, especially one that seems outside my expertise, and for the most part, all I needed to do was recollect everything that I know, and it usually ends up working out. I’m sure that I haven’t stretched myself far beyond my abilities, but it’s also possible that I’m misunderstanding what the author is trying to say when it comes to explaining how much knowledge one can have to be considered competent in any area of the craft.

It is worth mentioning that the author also keeps checking one’s limit and how far one should retreat once they are met with a challenge that is far beyond their comprehension. This is a good point because, believe it or not, this does happen from time to time. For example, the finance application that I worked on some time ago involved a lot of skills that I wasn’t quite familiar with, such as how to implement an API or how endpoints work. It was quite a lot to understand, but it also taught me to back off when necessary so that, once I’m ready to come back, it will be more familiar.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Falling Down the Deep End

I’ve always had this feeling of wanting to do more and challenge myself to reach the potential that I so desperately want to reach. In this pattern, the deep end is one that all aspiring craftsmen want to reach, and any apprentice or journeyman needs to gain that experience or take on a project that will finally take them to the next level. I know when I’m faced with a new challenge it can sometimes grow into fear because I’m not going to lie I have a really bad case of Atychiphobia, well it’s not that bad but failing in any task can put me down and so it’s easier for me to take an easier task when I can rather challenging myself in something that will benefit me in the long run. The most reassuring thing that’s even mentioned in the book itself is that when working in the field, taking risks will rarely result in destroying one’s career, especially when it comes to the IT world. So, reading this out loud makes me feel better about failing a task, no matter how I perform, I will still end up learning something in the end and I can take my failures in stride to create better solutions for the next big challenge.

Although taking some risks should be encouraged to take one to the next level, it is important to recognize whether the risk will pay off for the individual, it’s important to communicate with other people or a mentor and get their feedback on whether or not it’s wise to take on the risk and whether the benefits outweigh the disadvantages. The book will emphasize that if the risk and challenges seem to be too out of the ordinary then it’s important to create a “Feedback Loops” the options are laid in from of you when need be. And for me especially, I tend to fall back on this quite often when trying to make big decisions for myself. It’s also important to save yourself once taking the risk. As the book refers to it as “drowning”; being able to bounce back when things don’t work as the plan is important hence why the feedback loop is Important.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Retrospective Post For Sprint 1

Sprint 1 of working on the LibreFoodPantry was a nice dip in the water of how the scrum framework works. So far, I understand why this framework is very important to the software development process and the added organization it brings when it comes to producing software.

The first thing I worked on in sprint 1 is “added use-strict to the backend” (Link 1). Before working on this issue, it was important for me to understand what “use-strict” was used for. I found out that the “use strict”; line is used to define that the JavaScript code is in “strict mode.” When JavaScript code is executed in “strict mode,” it means that non-existing properties, variables, and objects will throw an error. This was very simple, and it didn’t take too much time to understand the issue and how to resolve it.

Another issue I worked on was “removing the MongoID schema in the GuestInfoBackend” (Link 2). This was also very easy; it consisted of changing the OpenApi.yaml, which included a MongoID schema. The MongoID is unused in the GuestInfoSystem; thus, it must be removed. The biggest problem was merge conflicts. One team member had made a change in the OpenApi.yaml file in the backend in one branch while I was making a change to the YAML file in another branch, and Git didn’t like this. In the future, I think it’s important for us to recognize when issues will show a merge conflict; it’s important to understand them too. I spent some time figuring it out, but then I ended up watching this video on YouTube that perfectly explained the point of merge conflicts. Anyways, I will be able to resolve this better in the future.

The third issue was to “create docker-compose.yaml for the guestinfointegration” (Link 3). I’ve never worked with Docker, so this was a big task for me. I had to attempt to understand Docker the best I could. When I try to read over documentation of another system, I tend to get very frustrated because I’m only left with questions. I think the best thing to do when it comes to this is to take it slow and grasp all the information that makes sense at the moment, then take it from there. Also, it’s best to ask a lot of questions whenever possible. I tend to try and figure things out on my own when I don’t really need to. I have all these resources and people I can go to, and I’m not capitalizing. Despite this, I learned a lot about Docker, and I will definitely come back to it whenever I need to.

The final issue I worked on before ending the Sprint was “Configure guestinfoIntegration” (Link 4). When going into this issue, I didn’t know exactly what the guestinfoIntegration was used for, but from my understanding, it is used as a mock repository showing how the GuestinfoSystem works. Configuring the file wasn’t hard; the only thing I had trouble with was understanding that the Integrations had no build image, thus no build meant that I needed to change the Git testing pipeline. It seems like I should invest more time into looking at the resources that have been presented in the LibreFoodPantry common services. I spent a lot of time getting the pipeline to work, which is good because now I have a better knowledge of how it all works. My concerns are that I take a significant amount of time on issues that can easily be resolved, so it’s my job to look at all my options before scrambling for a solution.

As an individual, I spent a considerable amount of time working on these issues and learned a lot about certain aspects of the project. I want to be able to better organize my findings and solutions in the next sprint. I also want to get a significant amount done between classes. This means setting deadlines so that I’ll have one issue done between each class.

Regarding the team, we have decided that we need to better space out our issues so that no one is doing too much and spending a lot of time on a certain issues, as this could be a problem for productivity. We have also decided that we need to capitalize on local branches before merging, which could help when it comes to merge conflicts. Heading into Sprint 2, maximizing our productivity is the goal.

Link 1:

Link 2:

Link 3:

Link 4:

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Exposing The Ignorance?

Exposing ignorance is apart of the learning process, and assuming that the person that this pattern is for is a apprentice, it’s safe to assume that having ignorance is apart of the learning process. What I disagree on when it comes to this pattern specifically is that it is hard to imagine that if your an apprentice, it would be hard to be in a situation where the fellow co-workers or employee assume that you have everything under control, that’s if the pattern in context is being aimed at apprentices. In my opinion, this pattern seems to be more for the journeyman if anything. A position where a person has the experience of a craftsman, but doesn’t know everything about the craft or like the author mentions, they will mistaken expertise for good craftsman, which seems to be two different things.

Although, what I do like about the pattern is that the author emphasizes that learning how to do something isn’t enough- its about how one learns the task that is more important than anything really. In his quotes alone the author explains that “Expertise is a by product of the long road we’re on all on, but it is not the destination.” This make me have a different perspective of the learning process, it can be a tough road, but that seems to be the point. Many times I tend to find shortcuts of how I can get something done faster because, like anyone, it’s relief to know that something is completed and out of the way, but I never end up truly understanding the task. Sometimes getting things done faster and without obtaining substance is a good thing, and needs to be done with good reason, and with that being said if I’m in a situation where I have to get something done, then afterwards I’ll spend some of my free time trying to fully understand it. Learning how to fully take advantage of the learning process is how one becomes a good craftsman.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

The Importance of Building Concrete Skills

Being able to build a set of skills that could be one day used by a team of craftsmen is crucial when walking into any profession. Although it’s a little hard for anyone to go into a job that requires one to know a set of skills. It should be clear-cut on the application. But I do agree on attempting to get assimilated on those skills whenever possible because in some cases, these employers want to be able to rely on the fact that you won’t be a liability to the workflow. This goes for a lot of jobs once again. I used to work a construction job when I was 17-18 years old, it was when I wasn’t so sure if I wanted to pursue a career in software craftmanship and I already had a lot of knowledge in the construction trade, four years of knowledge to be exact. The man who acts as a “master” figure to me told me that competence is everything in the professional world, and having little competence is better than having no competence.

It’s also important to expand the competence because it could expand one’s reputation of being a good craftsman for other employers to look at. I would also like to add that being able to work on the skills that one might lack is also important to expand one’s value to the team. Interviewers or hiring managers want to be able to understand your worth in a company, being able to list off certain tasks that can be done to an issue is invaluable, and being able to apply the knowledge that one has is more important. From experience, it also helps to have an experience that proves that you have the concrete skill, no days it’s not enough for employers to see that you know a certificate or course that you might have taken.

It’s more important for the employer to recognize that you have applied the skill set to other, similar jobs or projects. This pattern is a very general one that will be brought up countless times in apprentice’s come-up but, non the less it’s a very important pattern that can be applied to more than just software craftsmanship.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Expressing Enthusiasm in the Workplace

This is one of the more interesting patterns in the book. It’s a pattern that discusses the interpersonal relationships between the apprentice the masters or journeymen. I try to portray a lot of enthusiasm when it comes to the workplace. Currently, I work at a sub shop. It’s not my preferred job, but it’s a job, nonetheless. It’s different when comparing this pattern from a software development setting because I feel that I’ve exhausted everything I’ve been able to learn from this job. I try to develop some enthusiasm when it comes down to it though because it’s easier to go through a rush when everyone is in a better mood.

The same thing could be said when it’s time for me to work with a software development team, I can imagine. It’s easy to find people who don’t exactly feel enthusiastic because as the book mentions, they have been working at their job for way too long, they are caught up in many projects and deadlines, and they have no time to stick behind incompetence. After working a couple of jobs, I’ve seen this happen more then I could count, and it’s not a good feeling to conform to everyone else’s mood of dread and pain about a task or subject when feeling the complete opposite.

This pattern can be applied to almost anything in life. The young and incompetent apprentice who feels very enthusiastic about their job is once again shut down by their team. They might feel rather timid in trying to discuss or propose ideas to the team because they are afraid that the team will shut down their enthusiasm. When I’m going through this, I usually began to talk to people I feel that I can express my ideas very clearly too, who won’t attempt to shut them down, or who I feel won’t react negatively toward them. It’s easier to be told wrong by one person than by a bunch of people, and if it ends up being a good idea then I start by telling more people about it until I feel confident that it should be proposed at a more public level.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

The White Belt

I have a very strong idea that there is always something new to learn or that there is always something to learn. This is how I can keep myself busy for hours at a time. I haven’t hit a point in my life in which my abilities of self-improvement has fallen short because I’m unable to acquire new skills because once again even If I know everything about a certain subject will always try to perfect what I know or dive into something else that hasn’t been explored yet. Like when I was 17, I played this videogame for almost 4,000 hours. I had been playing it since I was 10 and some people considered me good at the games because I put in the time to learn everything about. But while playing with people who also did the same, I realized that my game was flawed, and I still needed to work on some stuff. This is what I mean, being ‘good’ at programming isn’t good enough.

In this pattern, the author puts the reader in the context of them being quite good at the job. You are the go-to for any solution or situation that happens, and you are so good that you find it difficult to improve any more than what you already know.

What I find interesting about this pattern is that the author explains the problem as not being a problem. As I described in my first paragraph, it’s hard to know everything about a certain subject, because there is always something to learn. The author goes on to explain that having the mindset of not knowing enough should be the objective. Being ignorant about knowing everything, especially at such an early stage in your life, is only going to halt your abilities to improve more and to adapt. I’m not at this point in my programming journey yet, but I know that at some point I’ll get there, and so I feel that once I feel like I’m at this point of my career, it is best to come back to this pattern as a reminder of what I should do next in my journey.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

How To Become Better at my First Programming Language.

Learning a language is really difficult, not only is it really hard to get started with one but once you have a good understanding of the syntax then learning certain methods of how that language can be used can be quite time consuming to learn. The problem I tend to have is that it can be difficult for me to implement a specific method in my work. For example I could go in and look at an example of a design pattern like the factory method, and I could know how it works and what it does, but I would have a hard time trying to implement it in my work.

Now, one of the first patterns that is introduced in Apprentice Patterns puts the reader in the context that they are starting out as a programmer and that they have a shallow understanding of the languages they know. The problems that we are introduced to are that since we have such an unlettered understanding of the language, it is difficult for us to create quality programs and solve problems. The solutions to this is that we must pick a language and take the time to become fluent in the language. The drive of wanting to learn and solve solutions for that language should be enough to guide the learning process.

While reading about this pattern, It was safe to say that this wasn’t the first time I’ve been exposed to this information of how to become fluent in a language. What really captivated me was how the author made a good point in learning the fundamentals and not just syntax, I feel that at this point in programming journey I could string a couple lines of code together because I’m to familiar with the syntax of my language, but the potential that I can create in that language is close to none. I wouldn’t know the first thing to do to start a project. The author put an emphasis on learning fundamentals, learning how to solve solutions with the chosen language, and how to use testing to your advantage. It’s important to open every and any feasible avenue when working to understand the language. As the author mentions, it must click. There is a difference between learning how to write a piece of code and absolutely knowing every purpose of that code. My goal is to find someone that knows more about the language I’m trying to become fluent in and to learn as much as I can from them, almost like a master. It’s a lot easier for me to acquire someone else’s wisdom rather than figuring it out on my own.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.