Monthly Archives: April 2022

Apprenticeship Pattern “The Deep End”

I decided to write a post about this section because I found very interesting. The author starts off this section with a quote from Christopher Hawkins,

“If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.”

– Christopher Hawkins, “So You Want To Be a Software Consultant”

This quote made recall an experience I had during my freshman year of college. I was meeting with my advisor in her office, talking about how I was having difficulties learning the content in one of my classes. I was debating whether to retake that class in the following semester because I thought if I retook the class a second time, I would understand it better. My advisor advised me not to and gave me this piece of advice, even if I don’t understand everything in this class right now completely, this was fine. As I took more upper-level courses, I will gain new insight and start to understand the material in previous classes a lot better and may even learn to see it in a different light. At the time, I found that piece to be very strange because I had always thought if a course is prerequisite, you need to understand in the previous course to understand the material in the next class. Now I see in later classes, you apply the information that you learn in a previous class and by doing so, can understand the ins and outs about that topic and gain a better understanding of the topic.  

In this section, the author talks about the dangers of taking it easy and taking on only tasks that you know you can complete. He also talks about how by doing so, you will not grow because their skills will not improve and as a result, they won’t become confident in their work. Whilst it is true the author wants us to step outside of our comfort zone, he also talks about how important it is to be smart while doing it. In the short story given in the book, Enrique who was challenging himself by taking a job in Nigeria, did not blindly take a leap. Before he even made the move, he connected with people who knew were already working there and so he got himself a mentor that helped ease the transition.

I agree with the points that the author brought up. One additional point that I want to add would be the author does not say it is important to make large leaps or take on a challenging problem without a mentor, it is just easy when there is someone there to guide you.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

My Second Sprint: An Improvement in the Journey

                Over the past few weeks I have once again had the opportunity to take part in developing the LibreFoodPantry software platform. From start to finish this second sprint has challenged our team in creating a solution to the question of security for this software. In this sprint we had mainly focused on how key cloak deployment would work and how we would adapt the existing web pages to utilize this security platform. We learned much throughout the sprint however we found that there was still much more to our role than just the webpages.

                Just to reiterate our goals, a group of my peers and I were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. We had previously spent the last sprint attempting to understand how this third party software functioned and what we would need to do in order to implement it. This sprint would focus on the implementation of Keycloak and what would be the least disruptive method of doing so. The goals were as follows; create a working instance of keycloak with a front page without any containerization, understand how to create and maintain users, roles, secure each new page we added within the same login system, then transition this system to a container system such as Docker.

Getting started we first focused our efforts on everyone getting an instance of Keycloak running. After ensuring that I could get it working reliably I posted my results on Gitlab for my peers to have their own working version of Keycloak with a frontend page. We were then able to move on to our other issues. I was tasked with reviewing NPM and how to adapt existing frontend pages to Keycloak as well as ensuring that permissions and logins could be carries between different pages. Others among us worked on researching the deployment of Keycloak on a Kubernetes cluster using AWS as well as communicating with other groups to begin to synchronize and ensure we were working on features that mattered for the other groups.

                The team worked well together, and we once again made a point to meet twice a week to discuss progress and synchronize ourselves outside of normal meeting times. It was worth the extra meeting times as I was able to assist group members in ensuring that they could have Keycloak working and that their computer was set up to properly install and run Keycloak and the frontend page.

                Our main problems came about once again in properly updating our work in the issues tab and a failure to properly estimate the weight of some issues we had created. I once again found that I was stuck on a single job most of the sprint trying to adapt existing pages to utilize Keycloak. It would be apt to say that I was again immersed in my own work and communicating less than would be ideal. However unlike last sprint I was able to work past this in a shorter time frame and was able to communicate this to my groupmates. With this out of the way I had started work on adapting this system to work in containers such as those found in Docker or in a Kubernetes cluster.

                At the end we had started to make more progress quickly but by that time the sprint had come to a close. While this was not an ideal sprint, it was definitely an improvement over the last and I feel that we had done better in estimating the weight of certain issues although not solving this problem entirely. We hope to continue practicing working in the Scrum format and improving our grasp on what issues need to be created and how much weight they should carry.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

For this sprint my focus was to get the frontend and backend talking to each other. This worked well and now they are communicating and sharing data as seen from the commit below. During the sprint we like during the last one was on teams of three, three assigned to the frontend and three assigned to the backend. Like last time this team dynamic worked well as we were able to complete a lot of issues in a timely manner.  Also, I found that the new commit scheme using commitlint made commits much easier to read. Due to the way you must commit a message, it made it so much nicer and easier to read know what type of commit they were sending such as a feature, fix, etc.

During the sprint however I did think that there was an issue with the team dynamic. On the frontend we didn’t have a lot of issues for this sprint. This sprint was mainly to focus on integration and adding files to make commits and other applications work well. For this it was mainly me and Sandesh who were working on this. Brendan did some work as well, but I thought to my self what the best team dynamic as Brendan when he would finish his issue most of the other issues were already assigned. Also, during this sprint, the backend team had their hands full with issues such as rabbitmq and making sure that it integrates with no issues. They managed to get most of the issues done as their team dynamic is structured very well and they all have a passion for working on the backend. Like the last sprint, I think that if the teams changed to 2 and 4 then every group member would have things to work on as the backend team normally has many more issues to work on during a sprint then the frontend team.

Apart from the team dynamic, I found that there were no other things that could be improved as a team. From an individual standpoint, there could be some things that could improve. Like last sprint I am still experiencing issues with too many commits. It has definitely gone down but every once in a while, when I commit work, I sometimes accidentally leave my test objects in the code which if not explained to other group members could confuse them. Due to this, I find myself sending a “fix” commit to remove all these test objects. What can be done to remedy this is to read all my code again before submitting. Like if were taking an exam, double checking my answers would ensure that every test object is removed form the code before any commit is sent through. Apart from that I really enjoyed this sprint and the work that I was submitting.

Commits

Added Commitlint to frontend repository: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/6179634a126b7dadb3e2edb193a87195a9aa6281

Change frontend skema to match backend: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/cc60a90c708823c01d47e705946363d7cf94c274

Make gitlab.ci file for frontend: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/57cca658ba91a8707934a246d31912dc63f8a19d

Frontend docker container with nginx: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/5842bad96d66457b3574bd54d48096e0ad2938d7

Fix container to reload and not crash: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/59a5599f7d3440f8472c4a5adc4f8abdb7b89e24

Integrate frontend image with backend:  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/321de2c87834105dabf1ecdb185cda3e699705d0

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

CS-448 AP Blog 9 (Read Constantly) – Reading Faster Prevents Coding Disaster

When you have read deep enough into “Apprenticeship Patterns” as much as I have, you start to notice a key feature of the book: many of the practices found within it are pre-requisites or co-requisites to other practices. Similar to a tech-tree structure found in a video game, proper software programming practices go hand-in-hand – this allows one to become proficient in many skills at once.

As usual, I have found that “Reading Constantly” is actually a practice that I already engage in. However, in contrast to the book, my level of “daily reading” is much smaller; I read for about 5-10 minutes each day, and it may not necessarily be related to the programming practices I need to study on. However, the book does state that reading during down time (even standing in line) is beneficial – perhaps, in an attempt to disagree, I was corrected by my own reading. This reinforces the idea: read, read, read!

I agree with Apprenticeship Patterns, and must also state that you should have a “queue” of books lined up; as you finish one, immediately start another. Tying in with “Practice, Practice, Practice”, constantly reading will keep you well-informed and up-to-date on problems that are relevant in today’s programming era.

When it comes to professional applications, “Reading Constantly” does not simply involve reading to obtain more knowledge. It also consists of:

  • Reading to acquire new connections within the academic community
  • Reading to apply skills from previous experiences
  • Reading to non-verbally communicate the idea that we are willing to improve ourselves

So, by taking some time to read every day, I am essentially performing both a “working” and “recreational” activity. I am able to boost my workplace performance in an enjoyable manner. Similar to the ideas found in the coding dojo, reading should come at ease, with information effortlessly flowing in like a gentle stream. Forcing yourself to learn new information is both un-enjoyable and ineffective.

Overall, I think that everyone and anyone who is considering an advancement in their career to read constantly. In a way, it makes us similar to our machines – we take in new input, compute it within our brains, and create solutions as output for our audiences. It’s a beautiful cycle, and it all starts with a good book.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Unleashing your Enthusiasm

For this week’s blog post, I have decided to look at the apprenticeship pattern “Unleash your Enthusiasm”. 11this chapter is all about you as a programmer being very excited about the craft of software development. However, you find that you are holding back and being more enthusiastic about the work your colleagues are doing. Fear not, as your enthusiasm and love for the craft does not go unnoticed. Because of your inexperience, it brings some unique attributes to the team, including that infectious enthusiasm and an unfettered imagination. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether or allow it to manifest only outside of their day jobs.” (Dave H. Hoover, Adewale Oshineye Pg. 22).

Essentially because of you being a newcomer you tend to try and acclimate to the rest of the group and start to lose that newcomer enthusiasm and begin to try and become unnoticed. The yare risks however that come from unleashing your enthusiasm. One of these risks are that if the morale is low or the team is not welcoming, you will likely get some eye rolling from your enthusiasm.  Another risk that could come from unleashing your enthusiasm is depending on the team, they may not enjoy that you are exposing your ignorance and where your knowledge stands.

From reading this chapter I found it to be an interesting take on when you begin working in a job setting with a new team. I liked that in the chapter it talks about both the positives and negatives of unleashing your enthusiasm. Although this chapter did not really change the way that I think about programming and my enthusiasm when I would get a new job. Knowing who I am as a person and my personality, I am not one to “unleash” my enthusiasm on a new group of individuals, so I don’t see this chapter as being helpful in that sense. However, if I were to train a newcomer and they brought this enthusiasm to the table, I now know what they could bring to the table, and I will not disregard it now.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Sprint2- Retrospective Blog

For this sprint, my team, team-1, have worked with two epics, which are refactoring backend and adding commitlint to gitlab-ci.yml for all projects which are reportingAPI, reportingFrontend, reportingBackend. We have finished the epic of adding commitlint to gitlab-ci.yml for all projects by following the instructions. However, the most important goal that our team wants to achieve in this sprint is to make the backend work as expected. First of all, we checked the code to see how they were written, and to see if they were written correctly. However, after I found many errors in syntax and some logic implemented incorrectly in the old code. I decided to create the new backend instead of spending time to fix all of those bugs. As a result, we divided our team into three subunits to work independently with the backend. One would try to refactor or fix the old code as much as they can, one would try to create the new backend, and one would create the test for the backend.

My role in this sprint is to create the new backend and refactor it in the new style. I worked with a docker file and index.js to create a backend server. Then, I created a docker-composed.yml containing node image, mongodb, and rabbitmq, to ensure all the services work correctly. After that, I used javascript to generate all possible methods that can be used to make required http requests, endpoints. In the end, the new backend worked as I expected. It has Rabbitmq service and Rabbitmq functions used to receive all messages from a queue. Then, the backend will store those data into mongodb as two collections, guestInfo and Inventory. Finally, this backend will generate the .csv report when we send the required http request.

As for the results of this sprint, I believe our team has achieved its primary goal which is to make the backend work. However, it is not perfect. There are still some issues that we need to solve in the next sprint to meet the customer’s requests, such as creating a function that automatically consumes messages using Rabbitmq, adding some more required columns to the report, change the _id property in the fake data to studentID. On the other hand, we have also created a test for this new backend even though it is not completed yet. We are planning to complete it in the next sprint.

In summary, there are some differences in how things work in this sprint. We have worked independently on the same problems but in different ways. This sounds like we wasted our time having multiple people working on the same problem. However, for this project, I think it makes sense to do it this way. That is because we all do not have enough knowledge to solve the problem, so there is no guarantee that we can successfully create a new backend. So, we decided to keep it safe by preserving and refactoring the old code while working on the new code. I think this is one of the disavantages of this sprint and needs to be improved in the next sprint. In the next sprint, we will back to work with the regular way, each person should take care of different issues to use their time effectively. For myself and my entire team, we have made some improvements comparing to the first sprint. The only thing I think our team should improve more is that we need to communicate more to understand the project deeply, to be ready for the presentation.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.