GitLab Activity

During this sprint, I contributed to multiple aspects of the project, focusing on both collaborative research and frontend development. Below are the key tasks I worked on, with links to the related issues:

1. Issue #26: Created a fake frontend – Designed and developed a simulated frontend to represent the user interface for testing and demonstration purposes.
2. Issue #20: Researched Docker architecture – Collaboratively explored and documented Docker architecture with the team to establish a strong foundation for the project’s infrastructure.
3. Issue #31: Created dummy pages for frontend login redirect – Built placeholder pages to simulate the login redirection process, enabling smoother navigation during development.

Reflection on Performance

What Worked Well

This sprint highlighted some clear wins for both myself and the team. Collaborating on Docker architecture research proved to be an invaluable learning experience. By pooling our knowledge and resources, we quickly gained a better understanding of Docker’s potential for our project. On the frontend, creating the fake frontend and dummy login redirect pages allowed me to apply and refine my skills in UI development. These tasks were particularly fulfilling because they provided tangible progress toward a functional interface.

What Didn’t Work Well

While the sprint had its successes, there were also challenges. Managing time effectively across multiple tasks was one of my personal struggles. For instance, balancing the research on Docker architecture with the development of the frontend required careful prioritization, and I occasionally found myself spending too much time on one task at the expense of another. Additionally, the lack of established workflows for testing the fake frontend made it harder to identify and fix issues early on.

Changes to Improve as a Team

As a team, we could benefit from setting aside dedicated time for pair programming or collaborative problem-solving sessions. This could enhance our understanding of challenging topics, like Docker architecture, and ensure that everyone feels confident in applying what we’ve learned. Regular check-ins or daily stand-ups could also help us address blockers more quickly and align our efforts more effectively.

Changes to Improve as an Individual

Individually, I want to work on improving my time management and task prioritization. Establishing a clear plan at the start of each sprint, with time allocated to specific tasks, could help me maintain better focus. I also aim to proactively seek feedback on my work, particularly when tackling new challenges like Docker architecture, so I can learn more efficiently and avoid unnecessary delays.

Apprenticeship Pattern Reflection

Selected Pattern: “Expose Your Ignorance”

For this sprint, I chose the Apprenticeship Pattern “Expose Your Ignorance” from Chapter 2. This pattern emphasizes the importance of acknowledging knowledge gaps and actively working to address them by seeking help, asking questions, and being open about what you don’t know.

Summary

The pattern advocates for embracing ignorance as a normal part of the learning process. It challenges the notion that developers should appear to have all the answers, encouraging honesty and curiosity instead. By exposing ignorance, individuals can learn more effectively and foster a collaborative environment where everyone feels empowered to grow.

Relevance to My Experience

This pattern resonated deeply with my experience during the sprint, particularly in the context of Docker architecture research. Initially, I felt hesitant to admit my lack of familiarity with some Docker concepts, but collaborating with the team and sharing our findings made the learning process much smoother. Similarly, while working on the fake frontend, I encountered unfamiliar scenarios where seeking guidance earlier would have saved time.

How It Would Have Changed My Behavior

If I had fully embraced this pattern from the beginning of the sprint, I would have been more proactive in asking questions and seeking clarification during our Docker research sessions. I might also have reached out to teammates or mentors for advice on frontend best practices when creating the fake frontend and dummy pages. In future sprints, I plan to actively apply this principle by fostering a culture of openness and curiosity, both for myself and within the team.

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

What worked best in this sprint was our team’s collaboration and the understanding I gained through independent research. From the get-go, our team had very few issues communicating. We checked in on each other during class and collectively made decisions on the project’s future without any conflict. Everyone seemed committed to their tasks, which allowed us to complete our sprint goals on time.
Throughout the sprint, I encountered many aspects of the project I was unfamiliar with, including RabbitMQ, MongoDB, and Docker. A lot of my time was dedicated to researching, reading blog posts, watching tutorials, and testing to understand how they worked. With the newest Sprint 2 goals involving the production and consumption of data using RabbitMQ and inserting it into MongoDB, I feel more confident handling these tasks.

What did not work well in the sprint were some complications with my operating system and a lack of documentation on GitLab. At the beginning of the sprint, I had trouble opening a port with my Mac, with my solutions working in some moments and not working in others. Eventually, that issue was fixed, but being unable to test during that time hindered my contribution. I worked locally to get things running with my Mac, testing the reporting backend and understanding how everything fits together, but I did not always push that work or create merge requests to show my progress. Much of my effort went into trial and error testing, and sometimes, my work felt redundant. I need to better communicate with the team so I can accomplish tasks more efficiently.

So far, we have been communicating well in class, and there has not been a need for constant checkups on Discord. That could change, and probably should, with the upcoming sprint. We will need to communicate effectively if our tasks end up conflicting. I could communicate better on Discord and will strive to do so in the next sprint. Working around work and school has been difficult, so I should discuss that with my group so we are on the same page.

The pattern from the Apprenticeship Patterns book that aligns well with my experience during Sprint one would be Confronting Your Ignorance. This pattern involves identifying gaps in your knowledge and actively working on them, even if the gaps are from areas people on your team assume you already know. It encourages you to fill these gaps through whatever methods work best for you, including reading, individual projects, or asking for help.
I selected this pattern because I recognized gaps in my knowledge and confronted them so I could contribute to the team effectively. I spent a lot of time getting familiar with RabbitMQ, MongoDB, Docker, and the Reporting System. I leaned on some of my teammates, who felt more comfortable with the tools, asking questions during class. I also did independent research, reading blog posts, tutorials, and documentation. These aspects of the sprint were most relevant to the Confronting Your Ignorance pattern.
I do not believe reading the pattern would have changed my behavior during the sprint. I understood that there would be different levels of expertise in a team, and not knowing something was not a weakness but an opportunity to learn. What’s important is that you take steps to fill the gaps in knowledge, which is what I strived to do during the sprint.

Link to Gitlab:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/37999a7f42ed4eb89d6f7ab2e2a4d530fec3010c

• Updating the dev container file and fixing the issue where the 10350 port would close unexpectedly.

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

To start, this was my first real team project where I felt like all of the team members were highly capable of putting something of value together. It’s been a great experience to learn and collaborate with such a good group.

We started this project basically from scratch, learning just how difficult that actually is. Over time we worked out our goals and expectations along the way. Through some facet of peer pressure and blind faith I got elected to lead the team, though each member has done something to guide all of us in one way or another. 

This leads to the topic of what worked well with our team. First, we all tried to get to know each other a little better. Aside from having the same major and concentration, a friendly connection has absolutely benefited us when it comes to communicating and holding each other accountable. It also fostered an environment of being able to ask questions and for help when it was needed. It quickly became a good time coming to class and being on time just to see each other and show our work in person. Due to instinct or pure luck, the best move we made was breaking our group up into pairs, otherwise known as pair programming. This allowed us to have 2 people focusing on each aspect of our project making progress in all areas simultaneously. 

For myself, one part I would like us to improve is being more on top of explaining the finer details of what each pair is working on. Being the leader I am seeing the big picture of the project but I do feel at times the others get a little lost in their own portions. During the sprint reviews I think we did a good job showing each other what that meant, but we could certainly get better when it comes to the day to day aspect.

All of this culminates into one of the things that really stuck out to me in the second chapter of the book Apprenticeship Patterns referenced in a previous blog. This chapter was about “emptying the cup”. This phrase is an amazing metaphor for not allowing yourself to think you know too much to be able to learn from others. Too often have I myself fallen victim to my own thinking of already understanding all there is to know about a given subject. Sometimes it’s really beneficial to go into something with a fresh and open mind.

For example, while developing the inventory back-end there were at least 5 times where I had to start completely over. While this sounds like it would be extremely frustrating I was noticing that every time this happened, I was learning something new along the way. After having worked with the guest info back-end I thought I was going to breeze through replicating it. It wasn’t until doing it over and over that I realized just how much I was missing under the surface.

Nearing the deadline I was actually becoming a little worried that it wasn’t going to work out in time. We would have to move it into the next sprint. However due to having so much practice and my partners assistance making a mock version of what i was creating. We were able to very quickly and easily put together a working prototype of the true vision we had. This prototype is also proving to be fundamental to how we continue into the next sprint.

In the end my team came together and had 3 portions of this project ready to demo for the customer and our professor. It all worked exactly how we planned and it was so refreshing to witness. We all did a great job and should feel proud for how far we managed to come in just one month working on this and knowing each other.

Here are all 3 portions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads

• This is a 2 for one. 

• The mock database itself was created by me and my pair partner Prince.

• The script to fetch data from an API we are utilizing was done by our teammate Anairdo

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend

• This directory is the front end our other teammates have been working on to pair up with our backend. Credit to Adam and Donna

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Created a separate branch from the frontend to solve the CORS/SSL issue

Created epics for larger tasks and broke them down

Organized tasks into issue boards

Prepared for Sprint 2 by adding new tasks

Documented important information regarding issues and how they were solved

In sprint 1, we were able to mostly complete everything we planned out; needing some revisions in certain areas. As a team, we performed well with eachother and communicated effectively to ensure all tasks were progressing at a timely manner. Additionally, we looked to eachother for help when we were stuck and didn’t know how to progress further, preventing teammates from falling behind in their tasks. What didn’t work well ocurred near the end of the sprint, where a teammate didn’t fully complete their task like they were supposed to, requiring one person to complete their task in sprint 2. This problem could have been solved if the team incorporated weekly code reviews to ensure that all areas of the task is looked over and nothing is forgotten. As the scrum master for the team, I plan to push for this element in future meetings.

Another improvement for the team that will be implemented in sprint 2 is better meeting time management. Since we only meet twice a week as a team, we should take this time to share progress we have made to the whole team. This could be any code written or any interesting articles that are useful to know. The primary goal of the capstone is to simulate a real development environment and solve tasks effectively. Equally important, however, is the opportunity to absorb and learn as much as possible. Something your teammates discover may prove valuable to you in your future career.

To improve as an individual, I want to get involved in other peoples tasks and try to offer my input in any way possible. Instead of being preoccupied by my own assigned tasks, widening my scope of work to my teammates tasks will allow me to grow as a developer and expose me to various tasks.

One pattern from Apprenticeship Patterns, that aligns with this sprint is “Confront Your Ignorance”. The pattern emphasizes the importance of recognizing and addressing gaps in your knowledge. Instead of avoiding unfamiliar topics, you should actively seek out challenges that push you to learn. This involves identifying areas where you lack expertise, setting goals to improve, and dedicating time to research, practice, and experiment. By taking on tasks outside your comfort zone, you develop problem-solving skills, adaptability, and a deeper understanding of new concepts. It pushes you to adopt a continuous growth mindset and helps you become a more effective and well-rounded developer. Going into capstone, I knew that I wanted to push myself to learn as much as possible, which is why for the first sprint I chose a task that I had zero prior knowledge about. In order to work on my issue, I had to research about CORS and SSL certificates, both of which are crucial concepts in web security and backend development. This process involved reading documentation, troubleshooting errors, and experimenting with different configurations to understand how they functioned. Choosing this issue to work on has also exposed me to the use of proxies, that route frontend requests to the backend. Utilizing a proxy will ideally allow the http backend url to connect to the https frontend url. In sprint 2, I plan to experiment more with proxies.

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.

After the completion of our first sprint, I believe our team performed very well. There were no issues left in the sprint backlog at the conclusion of the sprint, and, equally important, our understanding of how the Thea’s Pantry reporting system needs to work has grown significantly.

The divide and conquer approach taken worked well for us. Splitting up the issues gave us more flexibility in how we would approach our particular task. For me personally, I was able to do my research and development at a faster pace as opposed to having multiple people working on the same file. On the other hand, our team meetings were extremely useful for getting feedback and help with development issues. Having more sets of eyes to look at a problem often times got issues resolved quickly. The team dynamic in programming and software development, in my experience, is usually a balance between avoiding a “too many cooks in the kitchen” situation and making sure the team is communicating and engaged with each other. I believe our team balanced this reasonably well.

That said, I believe we should work to improve our inter-team communication. Having a good sense of what other members are working on is important if we’re going to continue to divide issue assignments. This is something I should work on specifically too. I want to avoid the habit of staying head-down in my laptop working, and do a better job of communicating on the status of what I’m doing, especially when working on my own.

My main focus for development was writing the code to create a properly-titled .csv report file to be sent and downloaded onto the user machine when the API call is executed. Here are links and descriptions on specific things I accomplished this past sprint:

1. getReport API Endpoint – Developed and tested RestAPI endpoint to retrieve report file.
2. buildReport Function – JavaScript function to build the report itself from RabbitMQ data. Currently, this generates a blank .csv file with the proper title with relevant dates of the report.
3. JSDoc API Documentation – Began setup and use of JSDoc, a markup language for JavaScript to generate developer documentation.
4. JSDoc Deployment Shell Script – Shell script to aid in building documentation files.

From the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave H. Hoover and Adewale Oshineye, the section regarding protecting one’s passion for software craftsmanship stuck out to me. Getting tired or frustrated when writing code is more or less inevitable; being able to separate those feelings from the field as a whole is key. The book mentions the idea of “Drawing Your Own Map”, a strategy for mitigating burnout. The core idea is setting limits for yourself can be as important as setting your goals. One can define the boundaries in which they allow themselves to work within, as even with short-term consequences (the book mentions missed raises and unhappy coworkers as examples), walking The Long Road rewards pace and longevity, not speed. I firmly agree with the statement made by the authors; quality craftsmanship does not come from short, intense periods of work followed by burnout, but by maintaining a steady pace forward across a decades-long career.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Last week, my team completed our first Sprint of the semester and presented our work to our professor and the client. Overall, as a team, we did a great job for having not done or been a part of a Sprint before. Each one of us was assigned an issue at the start of the Sprint to work on over the period. One of these issues was evaluating the frontends, so I reviewed each of them and found that two of them, AddInventory and CheckInventory, did not run properly. It was determined that it was a server/deployment issue, so I contacted a member of that team through private messages. The team was aware of the issue and were working on it, so I suggested to my team that we focus on the backend for this Sprint. However, we decided that it would be better if we try to fix it ourselves instead of waiting. So I was given the CheckInventory frontend. In class, another member was able to get the AddInventory frontend to run, so I asked for their help outside of class, where we determined that the frontend was unfinished. So my task for the next couple of weeks was to fix that, and I did so by comparing it to the AddInventory and CheckoutGuest frontends. I then “borrowed” files that were missing from my frontend, and edited and fixed ones that did exist. This consisted of organizing some files into new folders, copying over frontend-prod-build and frontend-dev-up commands, index.html file, and much more. After I got it to run, I edited it so that it would match the AddInventory frontend. After all of that, I committed, pushed and made a merge request. The pipelined failed with that, due to a yarn lock issue, so I fixed that, linted, and then committed and pushed again. 

What worked really well was communication between the team. I felt that whenever someone had an issue or needed something done, someone answered within the day, which is really good. I think the team chemistry was also really good too, it did not feel too serious but also not too laid back. We also helped each other whenever we could, which is good. On the personal side, what worked well for me was just working in general. Like this whole thing is something that I have not experienced before, so just being part of a team to get work done for someone else kind of gave me fuel to work and make this a good thing. However, something that did not work well for me was the expectation to get enough done. For each week we plan for something to get done, but every time for me, I felt like I did too little or not enough. Maybe it is something in my head, or I am setting the bar too high, but that ghost pressure was not nice. 

There is not a lot that I would say we can improve on as a team, mainly because our communication is good, the atmosphere is great, we help each other and we get things done. What we could do, just as a minor thing, is clarify what we are working on. Although I do not think this is an issue, it has been expressed by members of the team, so this can be a good way of getting some bearings. As an individual, what I can improve on is just getting more done. Although I did finish my part of the Sprint by the end of it, it did not feel enough to me, so going forward I want to do more. To go with that, I would like to be more open about what I did do, some of my teammates were not aware of what I did in some of the past weeks, so I would like to improve on.

The Apprenticeship pattern I have chosen that resonates with me this Sprint is “Confront your Ignorance,”  which is basically not knowing the information needed for the work at hand. I chose this one because it describes what happened to me during this Sprint. I realized very quickly that I did not understand many things in the frontend and the Inventory system overall, which was scary and discouraged me. If I had read about this pattern before the Sprint, I do not think much would have changed. I still would need to do a lot of research regardless.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

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

This is my merge request for my finished task of implementing nodemon into InventoryBackend in order for developers to utilize hot-reloading and for the correct port to be added for the database.

For Sprint 1, what worked well for me as an individual was my experience with nodemon itself, and being able to incorporate that experience to get a head start on the issue. Although it took me longer than expected to complete the implementation, having some background knowledge allowed me to be more confident in the changes I was making. The familiarity of the subject gave me some peace-of-mind.  

As a team, what worked well for us was our communication skills and being supportive and helpful of each other during class time. We kept ourselves organized with our issues and our Issue Board, which allowed for a clearer understanding of the tasks at hand. Our in-class environment as a team was very open and transparent with our problems and what we’re working on. Our communication from within Discord improved over the course of the Sprint, and we were able to keep each other up to date whenever we ran into a problem, made a merge request, or needed a question answered. 

On an individual level, what didn’t work well was my silence at the beginning of the Sprint. I struggled with incorporating and fixing nodemon, but I wasn’t asking for help early enough. Once I did ask for help, I was able to make great progress thanks to the assistance of my teammates and Professor Wurst. As one of my teammates had noted, if I had asked for help sooner, I might have been able to finish my issue faster. 

On a team level, we did lack in communication here and there, such as a lack of response on Discord, or others not being included or involved as much as they could have been. The Issue Board was too vague from the beginning, which made it hard to choose our issues and perhaps led us to bite off more than we could chew.

To improve as a team, we should be narrowing down our Issues and specify them more clearly, so that our Issue Board and plan for the next Sprint is more refined and achievable. I think we should also start to do stand-ups at the beginning of each meeting to inform the team of what we’ve been working on and the status of our progress. Also, although this applies to mostly me, I think asking for help whenever we’re stuck would be a great improvement. 

To improve as an individual, I, as previously mentioned, should speak up when I am struggling to try and get assistance from my teammates. It’s always good to have alternate perspectives and fresh viewpoints, so someone else may see a problem or solution that I wasn’t seeing. I could do a better job at keeping up with my teammates’ work, as I sometimes don’t confidently, fully know what they’re currently working on. 

Although there are a few Apprenticeship Patterns that would apply to me, I’ve chosen to discuss “Retreat into Competence”. This pattern describes a situation where you are beginning to realize how much you don’t understand about the work you’re doing, what you’re expected to do, or even the work going on around you. It eventually becomes too overwhelming, and to fix it, you revisit your “comfort zone”; you involve yourself in your area of expertise to gain confidence back and to take a quick break. 

I selected this pattern because I often feel weighed-down by an overwhelming sense of ignorance from all of the languages, frameworks, and other factors of programming that I do not understand. It makes me lose confidence in my ability to code, as it emphasizes my weaknesses. In terms of this Sprint, although I chose an issue that I had a little bit of experience with, the roadblocks I hit made me realize how much I didn’t fully understand about nodemon and especially docker-compose files, connecting to databases, images, and the like. Finding my ignorance in these areas reduced my confidence in my ability to program and get this issue solved. 

If I had read the pattern before or during the Sprint, I would have stepped back, worked on something utilizing my strengths, and gained my confidence back. It’s good to remind yourself of what you’re capable of.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.