Throughout the second sprint, we had a great basis to launch from for our project. We made great strides throughout the sprint and diagnosed some important issues barring our progress. Our second sprint was far more difficult than our first, but we remained determined as a team and hit some major goals. I thought we communicated in this sprint far better than before, and overall worked well on major progress blockers. The most important of these issues was an issue connecting the back and front ends and managing certificates for our server. We set fair and manageable goals despite these major issues, which were started or met by all members of the team. We were again very transparent in our communication, and our communication was frequent and on-topic. I spent my time doing three major tasks; setting up persistent data storage for our back-end, researching certificates and helping to set up SSL for the server, and troubleshooting our failing back-end at the end of the sprint.

What I thought didn’t work well in the sprint was the complexity of our issues. While I thought we set manageable and fair goals, they were complex and large. Many goals had to be reworked throughout the sprint, and were met in some capacity. Many issues got pushed to Sprint 3 due to issues we could not solve ourselves. This was a learning moment for me in particular. I would have liked to resolve all our issues on our own, but sometimes outside expertise or another team is needed to resolve an issue. Even if in our case that other team is the IT department, or Professor Wurst. 

As a team I would say that we could better work independently once again. I felt that despite our fair communication, most team work classes resulted in everyone sharing issues. This is something I wanted to avoid, but it happened nonetheless. I would prefer that we work at most in pairs on individual issues, so that major issues do not get sidelined. I felt that my previous retrospective on Sprint 1 should have been vocalized. This is where I think I could improve directly as an individual. I should be more honest in my communication and bring up this flaw sooner, rather than wait for it to improve. Going into Sprint 3 I will be more open and clear about any flaws or issues I see for us all to improve together.

The apprenticeship pattern that best describes my work in this sprint is Retreat into Competence. This fit because the work done throughout the server this Sprint was charting new ground in complex errors. The groundwork we set up in Sprint 1 helped us get our foot in the door, but our SSL certificate issues and back-end connection issues became major roadblocks. I managed these roadblocks by frequently retreating to what I had learned so far, and it allowed me to chip away at the issues and diagnose what to apply to the server.

My tasks:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/13
This was my first successful task in the sprint. I successfully connected our back-end to a local filesystem in our server and cleaned all our directories of unnecessary files. I tested persistent storage, and it works fluidly.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/18 

Most of my sprint was again spent working on the issue of SSL certificates for our server. I continued to research self-signed certificates until I decided that the best course of action would be to seek out Professor Wurst for a domain. I also worked out that there were unresolved DNS issues in the certificate that were brought to IT. Since this point we have had no SSL issues, and I have updated back-end URLs to accept https.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/25
Here I made small progress testing the back-end’s failure before we rolled over to Sprint 3. This is an ongoing issue for Sprint 3 as of this retrospective. During Sprint 2 I made progress in diagnosing the issue of RabbitMQ’s failure, and tested various methods to attempt to resolve it and prevent the back-end from crashing.

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

If there’s one thing I can say happily about this sprint, its that it went seriously better then the last one!

Lately, I’ve been focused on setting up a universal design for many of the applications that are being worked on throughout all of the groups in this class. Examples of which are show below, as well as a link to the specific GitLab issue they’re tied to.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/20

The first two shown are my initial generalized mock-ups, showing a generalized feel and theme while also showing off some elements like buttons and subtitles that would be commonplace. The last two are the two latest I’ve made, specifically for the user information group, implementing many of the design critiques that other groups and the professor have given me from the initial design.

For me, I found being able to work in an environment I’m comfortable with, that being visual design, helped a ton with my comfort and goal-setting within this sprint. I felt like I was put on-track compared to last sprint, and was able to do significant work. However, that being said, I felt like I was significantly independent and on my own for a majority of it. None of my team members were doing the same as I, and the work I was doing was specifically for the entirety of the class, not just them. So it felt like there was a bit of disconnect there, and could be fixed for next sprint.

I feel as though I did a lot better than I did last sprint, I was a lot more enthusiastic then before, but I do feel I could have communicated a bit better with my team about my new path in this sprint. I felt I left them behind a little bit, especially Jaylon, who was alone in the Frontend development. Next Sprint, I plan on improving on this by trying to split the visual design aspect of my work evenly with work for my team in specific. As for our team, I cannot really comment too much about what we could change as a group, as I feel they’ve been doing fine, I’m just the weakest link they have at the moment.

For a single pattern, I chose Your First Language as found in Chapter 2, which states that you only understand one or two programming languages, but not the ones particularly known for the job at hand. I chose this one as I felt like understanding a lot of the languages being used in our repositories are something I have minimal understanding in, and need to learn better to help my group as best I can. It suggests I toy around with new languages whenever I can, to best help and learn the ones needed. I feel as though this is something I would have already done, given my lack of time to do so, as I find myself having to juggle with work from this course with my others. However, that does not mean I’m willing to give it a shot going forwards.

All in all, I feel like this sprint was a success, and am looking forwards to the next one, which will be our last sprint. Here’s to improving where I can in that one as well!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Hi Debug Ducker here, and wow Sprint 2 came and went really fast. I have a lot to share today as well as realizations about myself and the project. Then afterwards I can say one last goodbye and sprint 3 ends, which is coming sooner than I think.

Now what I been working on these past few months was an inventory culling system that will tell the user whether or not food is past their expiration date by USDA standards. The progress on it as of now it more or less complete. It feels strange to say but we are pretty much at the finish line. This was felt after Sprint 1 were the path forward was decided and could be completed in due time. Which left the group working on the backend to not have a lot to do. Because the solution just needed time and everything would be fine.

After that we were pretty much done and I realize that some task can realistically be completed by two or less people. In a way I felt I wasn’t pulling my own weight. Perhaps I should have tried to be more involved with the process than I was and that could of made me feel that I was doing more. I guess that is the result of some projects that the seemingly big task was rather simple so now you just feel, rather empty about the whole thing.

Fortunately, I was given the task of filling out documentation, which is really important as what if the new people that work in this project need a guide. I and with some direction would be the one to write it all out. Documentation is a lot more important than people give credit, a place that can give you all the details about a project is rather handy when you are working on said project. Which I had something similar when I first started. Now I am working on clean up with another partner of mine, and we may be able to get that done soon too.

Last time I reference the book, “Apprenticeship Patterns”, by Dave Hoover and Adewale Oshineye and there is a pattern that reminds me of this situation. The pattern was emptying the cup similar to accurate self-assessment, the idea here is that if you don’t allow yourself to be willing to learn or do more then you aren’t going to do better. I feel I should have pushed myself to at least see what else could have been done with the project, instead of feeling useless.

Here is my work on the Documentation, I mostly did the readme and fixed up the instructions

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

Here is the Backend work so far in collaboration with other group members. The result was full integration with the scanner side of the project which is almost done

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

Here is the Scanner portion done by the team focus on it

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

Thank you for your time and have a nice day

From the blog CS@Worcester – Debug Duck by debugducker 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/64
                  Create a local instance of the database in order to have it perpetuate along runs of the backend during development.

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

                  Create validation in order to avoid negative quantity in inventory.

I also worked directly with one peer to help him resolve some merge conflicts with him Nodemon Implementation issue.

During Sprint 2, I went through some difficulty in getting work done in the correct way. What I mean by this is that I would produce some output to the system without first thinking about how that would affect certain areas, like not considering the physical limits of the system. This led to one of my merge requests this Sprint. The merge request to avoid negative values in the inventory was purely created because I was developing without thinking first. This led me to develop a sense of thinking first and developing second. This helped a lot more during Sprint 2, as I would have a complete and definite idea of what to code even before I sat down and typed it.

What I think did not work so well for me this past Sprint, and I believe was the reason why I produced much less than the first one, was the lack of a due date to deliver something. I have realized during this past month that, in order for me to produce anything myself, I need a due date. If I do not have any due date set to deliver something, I will most likely procrastinate. This is not related to the amount of work I had to do or the length of the Sprint at all. This is something personal, where I should have set due dates for myself in order to produce more and better. This correlates to something I spoke about in my Sprint Blog Post for Sprint 1—the enthusiasm and anxiety of delivering work. This is something that I need to get balanced out, with the use of due dates and time management.

As a team, we entered a really nice spot where we all became close, so working with each other is not an issue at all. During some classes, I would even be worried myself, because sometimes we would be the only group to laugh or have some kind of friendly conversation. Which is great, but we need to be careful that it doesn’t undermine our work. This is also something that I believe could be what is not working so well. Even though this does not happen all the time, some days the chit-chat has slowed us down.

The pattern I chose is called Retreat into Competence. It shows us that sometimes, when we find ourselves with no idea where to go, or find ourselves behind everybody else, or simply lost, we should take a step back, go back to what we know and are comfortable with, and finally launch ourselves forward just like a catapult. Sometimes, in order to take three steps forward, you need to take one back.

Retreat into Competence became a sequence to what I wrote about in the first Sprint. I dove deep, so deep that sometimes I found myself somewhere where I had no idea where to go or how to proceed. I would feel behind compared to my peers. And even without knowing this pattern, it correlates to something I learned from my first programming professor: sometimes all you have to do is retreat, leave the code aside, or go do something else related to it. And honestly, as magical as it may sound, the solution will just come to you. Brainstorming can sometimes happen in a quiet place. If I had read this pattern before, I would have applied it more often. Sometimes, even though I was familiar with such practice, I would still find myself lost.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Continuing from my last blog post for my CS-448 class, Sprint 2 has just finished. This Sprint I was assigned the issues of creating the code that mimics what the Guest Info system would handle (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/94) in putting guest info into RabbitMQ and the issue to take the data from RabbitMQ and put it into the database (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/96).

For what worked well this sprint, we as a team worked well and as we had planned to. On the backend, setting up the queue to put data into RabbitMQ was easy enough to do after reading the documentation on how the queues work which is what I wanted to improve last sprint so that I didn’t feel like I was unaware of how the systems worked. After that we started to set up the code that would take the data from RabbitMQ and put it into the database. The RabbitMQ for this part went as smoothly as the queue did, but when entering the data into the mongo database is where we ran into issues. The location of the data insert was in the dev container and so it was unable to connect to the database which is where I was stuck for most of the sprint. Another problem was that it wasn’t immediately obvious that the database connection was the problem which led me to looking for errors in places that there likely were none.

I think that for the next sprint a way to improve as a team would be two things. One would be to not assume that just because code exists for it, it doesn’t mean that it works in the context you need it to, and the other is that we should be more open to solutions to problems that may include adding entire new functionality that we didn’t specify was needed in planning but is needed to support another integral system. Individually I would want to improve by thinking harder about where my problems are and how they might affect things afterwards. I found that when I do ask questions about a particular hold up, after I solve that part, it leaves me in a place where I don’t have a direction because I didn’t think ahead after the roadblock. I have found that this really slows down my productivity and is overall an inefficient workflow.

This sprint, I think the apprenticeship pattern that is most applicable is the fifth pattern, perpetual learning. This is because this sprint I was learning new things about building a system, like the reporting system for Thea’s Pantry, only when there was an issue I was trying to fix, instead of always taking time to just learn whatever I can to build a base of knowledge that will help me when I come upon issues so I will already know what is going on. I also want to ask around for help from people who may know more about a certain system or function than me, including my group and the other groups.

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.