Gitlab Deliverables:
- Issue Board Maintenance => Throughout Sprint #2 I was responsible for creating and tracking tasks within our group. Additionally, I reviewed the syllabus and noticed that we missed a Backlog Refinement session during our first Sprint, so I allocated two dates (one for each remaining Sprint) for Backlog Refinement sessions. I led the discussion in reshaping our scope and adding/removing tasks in accordance to that scope.
- Secrets/Docker Compose.yaml Research => This task was inspired by a component of Docker Compose I researched very late into our first Sprint. I completed my research and created documentation on this feature once I was able to implement it in a testing docker container. The main goal of implementing this was to securely hide the certificates we’d use (and mention) in our Docker Compose file. Unfortunately, we pivoted away from the self-signed certificate in favor of using domain, which completely discontinued the use of this research
- Link to Documentation:
Compared to Sprint #1, Sprint #2 has felt like much more substantial progress has been made. During the beginning of the Sprint, we pivoted our approach from using a self-signed certificate to using a domain to create a secure connection. With this newly acquired domain, we acquired a certificate that allowed us to securely connect to the FrontEnd’s services. I was unfamiliar with the process of applying for the certificate and renewing it at the time, but our team discussed how this would work which helped me learn new aspects of networking. Just before we acquired our domain, I finished my research on Docker Compose Secrets, which at the time I thought would work perfectly with our self-signed approach. Ultimately this work will go unused as we soon ditched the self-signed certificates in favor of using the domain. I decided to keep the documentation, as future teams may need this information for this project or to learn more about Docker Compose.
Beyond that set of documentation, I would say my most successful contribution to this Sprint was setting up the Reverse Proxy to the FrontEnd service. On the surface the Reverse Proxy was only implemented by using ~3 lines of code however, I spent a couple of hours learning what a Reverse Proxy was and which ports were being occupied by the GuestInfoSystem. Looking back at the time I spent implementing this I wish I made two specific changes to my approach. First, I wish I recorded which ports were being occupied. During my first 30 minutes of testing the reverse proxy, I was able to have a running FrontEnd connected to our domain, at the time I didn’t think this was the desired result so I soon spent another hour or two trying to see what other ports were occupied (and which services they led to). This oversight of not recording port information would not have only saved me time but could have helped provide a visual to the team illustrating what port we would need to access for a specific service. The second change to my process I wish I changed was not creating documentation. Looking back at the time I spent learning what reverse proxies were, I wish I set aside a small list of my findings. Once I had the reverse proxy working, I gave my team a quick walkthrough, but future teams might need this information. To resolve this I plan on adding a section to the Onboarding documentation, which I will write during Sprint #3, discussing the reverse proxy I created and how to find/change it.
I’m continuing to learn and apply the apprenticeship pattern “Be the Worst” from Sprint #1, but I’ve begun to focus on another pattern “Create Feedback Loops”. One thing that I pride our team on is communication among peers and shared knowledge. If we find something new such as a new approach to solving a problem or an interesting bit of research, we do our best to share it when we meet during the beginning of class. By contributing to our group’s wealth of knowledge it creates a feedback loop that not only encourages other team members to find new information but also reinforces what you have learned individually. This apprenticeship pattern encourages the developer to take a metric and see how much of that they, individually, provide to their team when compared to other team members. Our feedback loop helps keep me on my toes, as when I don’t feel like I’ve contributed to our knowledge (or by extension progress), I develop an internal drive to take on something out of my comfort zone. During this Sprint I chose to learn about Reverse Proxies to contribute to this feedback loop. Not only would my findings be applied, but I could then further encourage and enable the work of my peers.
The last note thing I would like to note is our team’s performance over this Sprint. I have learned a lot by tackling the issue of connecting our FrontEnd service as a group, but moving into Sprint #3 I want to see how more effective I can become in tackling individual issues. During our class meetings, we typically focus on one goal and research it together. I’ve learned that I have a hard time keeping up when new information and approaches are being tested. The best way I can word this struggle is the sense of there being ‘too many cooks in the kitchen’, so moving into Sprint #3 I want to refocus my effort on my personal work. In doing so, I hope I can become a much more effective team member.
-AG
From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.