Category Archives: Sprint 2

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Sprint [2]

During Sprint-2, my focus was on contributing to the tasks assigned to me through GitLab. These tasks included Issue 4 and Issue 2. Both were critical components in ensuring the functionality and reliability of the fake frontend module in the LibreFoodPantry project. As the sprint progressed, I had the opportunity to reflect on the highs, the challenges, and the lessons learned. Here’s my summary of the experience.

Evidence of Activity on GitLab

  • Issue 4: Task to implement functionality improvement in the fake frontend. This required debugging and making updates to enhance module performance.
  • Issue 2: Debugging and addressing existing issues with edge case scenarios in the fake frontend module.

These activities provided me with valuable experience in problem-solving and adapting to unexpected challenges, which were prevalent throughout the sprint.

What Worked Well

One of the key successes during Sprint-2 was the level of collaboration within the team. Regular communication ensured that tasks were clearly defined, and support was readily available when needed. I found that breaking down complex problems into smaller, manageable components made debugging much more efficient. Issue 2, in particular, benefited from this approach, saving considerable time and allowing me to focus on improving code reliability. Additionally, Issue 4 was completed with minimal revisions thanks to the clarity of the requirements and prior preparation.

What Didn’t Work Well

However, Sprint-2 also presented its fair share of challenges. Initially, unfamiliarity with certain aspects of the codebase slowed my progress. The intricate structure of the fake frontend module required extra time to understand before making meaningful contributions. Furthermore, testing processes revealed several edge cases that were not anticipated during planning, leading to some delays in resolving issues. These experiences underscored the importance of early preparation and thorough testing.

Changes to Improve as a Team

Reflecting on the sprint, there are several improvements the team could make to enhance our efficiency:

  1. Knowledge Sharing: Organizing sessions to familiarize team members with the codebase would help reduce delays caused by a lack of understanding.
  2. Proactive Testing: Incorporating more comprehensive testing during the earlier phases of the sprint could catch edge cases sooner.
  3. Clearer Documentation: Providing detailed documentation of tasks and processes can ensure everyone is aligned and reduce ambiguity.

Changes to Improve as an Individual

At a personal level, I identified several areas for growth:

  1. Skill Development: Spending dedicated time learning tools and frameworks used in the project would enhance my ability to tackle tasks with confidence.
  2. Proactive Engagement: Being more proactive in seeking clarification when tasks feel ambiguous would help minimize initial slowdowns.
  3. Time Management: Allocating focused work periods for specific tasks could improve overall productivity.

Apprenticeship Pattern Selection: “Expand Your Bandwidth”

  • Summary: “Expand Your Bandwidth” is a pattern that emphasizes the importance of stepping outside one’s comfort zone to learn new tools, techniques, and frameworks. By actively seeking opportunities to grow, developers can broaden their capabilities and handle more complex challenges.
  • Relevance: This pattern directly relates to my experience during Sprint-2, where unfamiliarity with parts of the codebase initially caused delays. By expanding my bandwidth through dedicated learning, I could address similar tasks more efficiently in the future.
  • Impact on Behavior: If I had read this pattern before Sprint-2, I would have approached the unfamiliar codebase with a proactive mindset, dedicating time to research and practice before diving into the tasks. This preparation could have prevented the slowdowns experienced during the sprint and improved my overall contribution.

From the blog CS@Worcester – aRomeoDev by aromeo4f978d012d4 and used with permission of the author. All other rights reserved by the author.

Sprint Two Retrospective

This sprint pushed us out of the setup phase and into the real struggles of implemenation. Our focus was on certificate configuration, domain integration, and establishing a stable server environment capable of supporting frontend and backend communication through Docker Compose. We encountered technical challenges that required a lot of trial and error, especially with NGINX, RabbitMQ, and SSL certs, but we made real progress and learned a lot along the way.

Key Work Accomplished:
  • SSL Certificates: After experimenting with self-signed certs, we shifted direction and enabled Let’s Encrypt with Certbot. I verified auto-renewal functionality using a dry run, ensuring long-term reliability.
  • Domain & NGINX Setup: Switching from IP to domain access opened the door for proper HTTPS handling and better routing. We spent time researching NGINX as a reverse proxy and adjusted our configuration to support this change.
  • RabbitMQ Troubleshooting: I spent time debugging why connection.createChannel in messageBroker.js fails during Docker Compose builds. The issue appears tied to the container configuration or startup timing, which I plan to isolate in the next sprint.
  • Documentation: Added notes and resources for Docker Compose Watch (for future CI/CD use) and contributed to team documentation related to server setup and troubleshooting steps.

This sprint tested our patience and problem-solving skills. Even when progress felt slow, I stayed focused on learning and finding answers. I also made it a point to keep the energy positive in the team, especially when the same problem stretched across multiple weeks. I think maintaining that morale helped keep us all engaged and moving forward. One area I’d like to improve is how I manage my research time. It’s easy to get stuck digging through forums or chasing edge cases, so next sprint I want to be more intentional about how I explore solutions and when to pivot. I also want to get better at helping guide conversations to a technical conclusion more efficiently during group work. My top priority going forward will be testing subsystems and verifying proper communication across containers. I also want to finalize our server hosting and make sure the front end is accessible through the domain without errors. Overall, I’m proud of our persistence. This sprint was about learning and solving problems within the systems we’re building.

Apprenticeship Patterns: The Long Road

This sprint reinforced the mindset behind Apprenticeship Pattern: The Long Road—that true growth in software development comes from persistence, patience, and a long-term commitment to learning. While troubleshooting issues like Docker container problems and RabbitMQ errors was frustrating at times, I stayed focused on understanding the root causes. Each challenge became an opportunity to learn. I’ve started recognizing that even slow progress is part of the journey to achieving the goal. This pattern will help me stay motivated and positive, even when things don’t go as expected. Moving forward, I want to manage my time better when diving into technical problems and continue building habits that support my learning and my team. There is still a lot of work to complete for our team, but I think we expect this and we will hit the ground running for the last sprint.

From the blog cameronbaron.wordpress.com by cameronbaron and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

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:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/documentation/-/blob/main/Documentation/Secrets.md?ref_type=heads

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.