My Third Sprint: A Lesson in Legacy

                With the ending of my last sprint in my capstone class I have completed my first of many cycles of development. Throughout this series of three sprints I have gained a better understanding of what I can expect of myself and how I can begin to improve my performance in an actual working environment. This last sprint, like the previous two before, taught me new concepts that I had not previously considered when going into the sprint. Throughout this sprint, especially in the last two weeks, the mains idea that stuck out to me was that of legacy, and what our group leaves behind for those who are coming next.

                When beginning this sprint, I had first focused on what was laid out during the planning session, involving the implementation of docker and containerization in general on to our identity access management system. The system worked when running on the operating system without any overhead so the next step was to get it working with docker to later be adapted to the Kubernetes clusters being used to host the Libre Food Pantry system. On the second of three weeks into this sprint, it had occurred just how close we were to the end of our journey and I began looking at the other spring backlog items. The one that struck me as most important was working on refining existing tutorials within the GitLab repository for the next group of developers to be easily able to get up to speed on what has been done and what needs to be done.

                As in previous sprints, time estimation, while once again improved, was a problem for us. This was especially noticeable as the end of our journey loomed closer.  While we had not gotten as much done as we would have liked to, we had made a concerted effort to condense our findings into the important information and save it to the GitLab repository for future groups to pick up on.

                Our group was tasked with creating a presentation for the end of the semester and this helped us to filter unnecessary information and include only the most important parts that applied to the project at hand. To go along with this I myself had even created a tutorial video that exemplified all of my own findings which would allow new groups to create a secured application with key cloak. Despite being a basic webpage, it is better to start with this than with nothing like our group had.

                As a group we can still improve not just on our time allocation but also our recording of information. Being able to properly record our finding as we make them is important in allowing both the group and future developers to have easy access to pertinent information regarding this project. I myself could have made this a focus as I performed research from the very beginning and would have had a library of information for it.
                Aside from this however, I still have a long was to go in making an effort to communicate with my peers. I often find myself “suffering in silence” whenever I run into a roadblock and, just as before, I tend to withdraw and become distant which benefits no one at the end of the day.

                Overall however I can say with certainty that there is a foundation here for future developers to work on. Our legacy will have an impact on future progress and provides a point for future groups to jump off of in order to finish what we started. The updated ReadMe created in the repository will hopefully hold useful information to users that takes away from the research that would have been spent on getting key cloak working in the first place.

GitLab Contributions: · KeycloakWithoutDocker · LibreFoodPantry / Common Services / Identity and Access Management System / Keycloak Research · GitLab

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

“Study the Classics” Apprenticeship Pattern


This pattern is based on newer programmers that have not had as much experience in the field not having reference to earlier works that were instrumental in the development of the field of software development. The newer programmer will have less reference in understanding the context of how things are the way that they are in the industry, and will be surpassed by his colleagues who know the literature and understand laws and phrases used.

What I find most useful about the studying of classics in a field like software development is emphasis on trends of the industry. Programming languages and projects can come and go, but if classic literature can be used regardless of the time period that is read it implies that there is general education that can be done that transcends simple programming or development.

This apprenticeship pattern has somewhat changed the way that I think. I know that I would probably have to learn terminology that is important to software development, especially when working with teams. This apprenticeship pattern has, at the very least, made me more interested about learning classical literature in the field. Although on the other hand, it seems a bit difficult to me to disambiguate which type of classical book to read, and which type to not read. The pattern references “When you pick up a book and the first thing you wonder is how out of date it is, you’re reading the wrong kind of books”, but I’m not entirely sure how to come to that conclusion. Although I’m assuming that I can gain proper reference via an article.

I do disagree with this pattern a little bit. Studying a lot of classical literature seems to me like a dedication that can take a lot of time and energy. I think if I want to expand my education on classical matters such as Brooke’s Law, it may be more beneficial to read a second hand source that aggregates classical laws and their contexts rather than reading some of the classics cover to cover. While my view here might be ignorant since it is only based on this short pattern, it is the impression that I get from it.

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

Sprint Retrospective 3

The third sprint for my software development capstone class was on an honest note a bumpy road. The purpose of the sprint was to start the next level implementation of creating test files using mocha and chai and also making sure the API is validated and can be bundled properly. Through the first part of the sprint, the team has been very productive in keeping up with the issues we made for ourselves. After Spring break, our productivity started to plummet since we did not accomplish issues the following, we did not have our class meetings.

As for my team members and I, we have faced great issues that we started to come across that stumbled all of us. Due to facts of, lack of knowledge, merge requests, and was not able to accomplish all our issues for the sprint. First, when it came to merging requests, I admit we have gotten better at how Git operates. But when it came to approving the request assigned to us. We had a pile of request that was not merged and had to spend our class meetings squashing all of the time to keep the main repository up to date as soon as possible. Secondly, our productivity has plummeted since our spring break, we did not have to work on anything which was completely optional. However, the following week there was no class reunion and I made no effort and treated it like another extension of spring break. Third, as I gained a deeper understanding of the problem, I didn’t know how to deal with some of the issues. The other issues couldn’t be resolved and were interrelated, so we had to address them in the next final sprint.

Our team decided not to undermine our productivity. Especially if the third sprint is the last race in the podium category. We decided and wanted to be more active and help each other in the workspaces when there are things we don’t know or understand. Talk about gathering information on all the advice our professors can give us to put us on the same page.

As for me, I have done good things, but of course, I could have made better improvements and made a better contribution to our team. I wanted to know more about how the Mocha and Chai tests were implemented. However, I have decided to do more key pieces to solve the problem. However, in the next problem, we will use one or more of the problems we created to create a more robust test file that will pass all tests. Talk to team members who have done an extensive research to see if they can help you with modifying and implementing test files that have already been created. At least the experience provided.

Sprint 3 Issues

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Sprint-3 Retrospective

Sprint 3 was a bittersweet moment for us. We were proud of the progress we had made. On Gitlab, we officially had tons of content regarding Keycloak. Including multiple branches of code, research written in our own words, and documented tutorials. As well as demo apps we successfully secured with Keycloak. But it also signified the end of our work in the class. We now had to allocate our attention to preparing the next class to continue work on the project. Which meant, a decline in our progress to the final product and the end of our work in teams. Which saying goodbye isn’t always so easy.

                Our first Sprint required us to provide massive amounts of research. Which made Sprint 3 smooth sailing. From the start we were geared to creating documentation. Therefore, many of our issues in Sprint 3 was not anything new for us. We had to continue making documentation. And that’s what we did. We wanted to get the next team on the same page we left off on as soon as possible. So, the team worked to create documentation explaining how our tutorials worked, and how to get them to work on any machine. We also wanted the next team to skip a lot of the speedbumps we came across. There was so much information I personally studied during all three Sprints that was not important to our team’s issues. Not that the information wasn’t good, it just wasn’t important for us. And it slowed much of our process down. Having that in mind really set Sprint 3 up in a way that left us feeling like we need what we needed to do.

I created documentation for our team’s history. ( ) As well as documentation for Docker Compose File Examples ( )

                For things I could have done better? Communication is extremely important. I was really locked in on this “Deploying Keycloak on AWS” tutorial during the beginning of the Sprint. I came across a couple speedbumps during my run, and I was awfully silent about it. That was a big hurdle to attempt alone, and I didn’t ask anyone for help. Not only did I neglect this information from the team, but I ended up abandoning that tutorial entirely. Which ultimately burnt my time and wasn’t beneficial for anyone. This is something I need to work on with myself for the future. That was a huge over-estimate of my own ability. And instead of being open about it, I was silent. At the time I was just sorry that I was not successful in completing the tutorial. But now I feel sorry that I simply was not communicating with the team during that time. For myself, I can’t let that fly. I need to be better.

                As for the team? I truthfully don’t have much to critique. I think my team is a great group of students and I am thankful for their work this semester. We always found the time that worked for everybody to get together and get the work done. Of course, we could always have better communication. But I only say that because I saw it happening within myself. This was honestly the most open and communicative team I have been a part of. Something that could’ve helped us a little more. Probably taking more advantage of screensharing software. I feel like watching things happen live on someone else’s screen could’ve been beneficial. I don’t think we did that enough.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Sprint retrospective 3

Here in sprint 3, things seemed to have progressed smoothly with the project in that we have finished most of what we have added in the product log although there were some areas of difficulty. The cohesion of the group has improved with better communication on what is to be done and the planning together seems to have gotten better. There are still improvements to be made but overall, the project is in a good state right now. The presentation also seems to be going well and should be alright. The quality of the sprint overall seems to be up and is providing good results.

On what has worked well, we have managed to get to the end of the semester and be able to finish a good amount of work on the project. We added more calls to the backend and continuously updated the API with new changes. The backend is set up with the proper semantic versioning. The android nest tester is functional and everything that we have built looks to be solid. The communication in the group looks to have improved as people communicated on what they did and were working on more than in previous sprints. The team also seemed to have gotten together more often to work on issues. The group stuck to what was planned pretty well and followed the timeline agreed upon. The issue board moved along more than the last sprint, issues were moved across the board compared to last sprint where nothing was moved until the last day.

On what has not worked well, there was unfinished work at the end of the sprint that now has to be sent over to next semester. This means that we have made mistakes during our planning on the difficulty of the work on the issues. The planning of getting the presentation done also could have been better. There probably should have been more dedicated time to get together and figure out the presentation as it felt a bit odd at the end figuring out what topics to do.

We could improve as a team by firstly, we could have worked together more regarding the issues regarding key authentication that we were unable to implement. There could have been chances to get together and try to figure out what was wrong and get it done by the end of the sprint. We could also improve as a team in our planning and plan more effectively on what can be done this sprint. We also could have been more planning with the presentation and knowing what exactly what portion each member was contributing with.

I could improve personally by putting in more of my input and getting my ideas out there. I also could have contributed more on different issues within the project. I also could have done better with working together with the group members such as when we were working on implementing the range call where it felt like backseat coding and I could have contributed more.

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

Sprint Retrospective 3

Everything under source (src) in backend was written except for the final test files and API was also complete. We were waiting for more information about access tokens and Gitlab access keys from the IAM team. We were also waiting to hear from AWS team on templates for Kubernetes system but did not get any response. We were at the same time researching on how to import API bundle into backend so we could start building the backend server and to at least test if everything from our side was working properly.

We needed to bundle our API before we could export the file to backend and ‘npm run bundle outfile.yaml` was not working. After fixing minor issues in the API, we got our bundle file. Even after a lot of research, readings and experimentation, we were not able to connect API bundle to backend, something would not work and kept getting different errors. At this point we decided to copy the bundle file and paste it into backend lib folder manually. Since we were not able to import the bundle file, we decided to not work in main and created a separate branch called ‘issue10’.

We made a lot of mistakes from this point on. We were all working on this branch instead of making our own branch based on the issue10 branch. We also worked only on one team member – Christian’s system. We added and modified a lot files like, package.json, package-lock.json, docker-compose.yaml, Dockerfile, etc. We should have created branches based on issue10 branch, then created specific issues with proper weight assigned to them. After making all the modifications we could think so, we still were not able to build our backend server.

At this point, Dr. Wurst pointed out that we do not have frontend, which means that our docker file will not be copying yarn file and running yarn install but instead copying the package-lock file and running npm install. After making changes in the Dockerfile, our backend server was finally able to build but still could not stay up. After going over docker container logs we finally came to the conclusion that the problem for this was in the port. We had not specified proper port in many files. Once those modifications were made the backend server was up. Till this point, we were all still working on Christian’s system, without any proper issues, comments and documentation for modifications that were being made.

I created my own branch based on issue10 and then wrote calls for cooking method. However, when I tried to build the server, I got the error that docker-compose is not installed even though I have used it many times before. Using the solution, I found on stackoverflow I was now able to build the server but the process would hang up on the attaching stage. I tried running docker-compose up command after opening the branch in container. This led to an error saying ‘docker not found’. Another team member Jeffery had the same problem as mine but was able to find a solution for it and then was able to make calls. However, the same solution did not work for me. After trying everything I could find on the web till 4 am, I finally gave up.

In the next meeting I shared the calls I had written for cooking methods with the team so they could be added to the project. Noticing that I was the only person who was working on a windows PC I decided to run the project on a friends MacBook and surprisingly it worked. I did not research further into why it would not work on my system since I had limited time with the Mac.

I worked on cookingMethod.js and cookingTip.js test file. I set three constant variables: getAll, getOne with valid ID and an invalid ID. getAll would check for ‘200’ response and data in form of array. getOne with valid input would check for ‘200’ response, ID, object and value. getOne with Invalid input would check for ‘404’ response.

Links to issues:


Backend Debugging

Modification of files

Cooking Method test

Cooking tip test

P.S. – I apologize for this retrospective being more like a summary. It proved difficult to classify the process in what worked and what did not work sections for this sprint.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Sprint 3

For this third and final sprint, we were the most efficient and organized thus far. It is really neat to look back to the first sprint and see how much we improved as a team. From us in the first sprint not really knowing much about how to work as a team in sprints, to now working well together as a team for many weeks and understanding the sprint structure pretty well. Though the structure seemed somewhat daunting at first, I have grown to like the sprint structure and the entire workflow throughout my time of working on the Reporting System. I think that the best way to learn anything, especially for me, is through experience, so diving right in and getting first-hand experience with sprints, sprint planning, sprint retrospective, etc. really helped me to understand how it works, not only in theory, but in a practical sense.

The first thing that we improved upon over time, and even more so with this sprint, is the sprint planning. At the beginning, judging what we thought we could get done during a sprint was mostly just guessing work, but as time went on of working on issues, we were better able to judge how long an issue would take to work on and the weight that should be assigned to each issue. However, even with the first sprint, and definitely now, we were good about finishing as much as we wanted to during each sprint. This means that we did a good job of judging how long it would take to work on each issue, and how much we could get done.

The next thing we improved at over time was the sprint retrospective. This ties into how we were able to do well with the sprint planning, because only through discussing what we did well, and what we could improve upon during the sprint retrospective could we focus our efforts upon improving specific areas and keeping up with what we were already doing well. This is why I think that the sprint retrospective is one of the most important parts of the process. This is because even if team members are individually good, only by discussing with other team members about your strengths and weaknesses can you assist each other, and improve as an individual, as well as overall as a team.

I think that the most impressive thing about our achievements over the 3 sprints is that we now have either a working, or very close to working system. While at the beginning of the sprint we only had some of the backend, we now have a working backend, frontend, and API. Additionally, we have the endpoints and functionality in place for the ultimate goal of the system, generating a report. It is really neat to think that we as a team achieved the goal of having the system generate a report, and all the components coming together to do so, as well as the functionality in place for RabbitMQ to interface with the other systems. It is also really neat to think that future teams will be building upon what we did, using the code that we wrote, and using the documentation we wrote as a roadmap. In this way, we had an impact upon the future of the Reporting System, and the whole food pantry project as a whole.


Updated backend to include more detail, including the containers and images used, and the endpoints available.

Updated API to include the methods for the endpoints, as well as what parameters are required.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

Expand your bandwidth is an apprenticeship pattern that teaches the idea that as well as learning and improving at tasks that we are comfortable and familiar with, we need to be able to learn about completely new and novel ideas in order to excel in our fields. The pattern mentions signing up for online blogs, newsletters, and online forums as a way to learn about new ideas. The authors also mention that while this pattern is important in order to excel in software development, its also important to know when to use it, and when you should instead focus your efforts on the task at hand. Their approach to this is to try to designate time every now and then to learning new things, but don’t spend more time than necessary on that learning.

I agree with this pattern and I think it is a good approach to the idea that people are meant to be lifelong learners. It isnt realistic to expect us to always be learning new things, as that constant influx of new information can be jarring and oftentimes unnecessary in the things we are currently pursuing. This approach teaches us that its important to set aside time for learning new things, but not in a way that it interferes with our current tasks. As a college student I have been introduced to plenty of novel concepts throughout my undergrad program, so I understand the importance of learning new ideas. Likewise, once I go out into the work force I will most likely specialize in a specific set of tools, and my learning will narrow down to mainly encompass those tools that I will end up using. Looking forward into this future I can see the issues that the authors mention in this pattern, where not expanding your knowledge base can prevent you from becoming the best you can, and I agree that the solution is to periodically go out of your way to learn about new ideas and concepts.

I have not really applied this apprenticeship pattern much in my life as of yet. A lot of my learning has come from my undergraduate program, and as such I have had the privilege of being exposed to a wide knowledge base. I do however, plan on incorporating it in my future career, since I believe that acquiring new knowledge will be important if I want to have a successful career as a developer.

From the blog CS@Worcester – Sebastian's CS Blog by sserafin1 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Personal Retrospective

This final sprint was much more of a struggle than the other two prior sprints. Since we got a lot of progress done in achieving our goals throughout the past two sprints, we figured that this sprint would let us bring everything together and finalize everything we have worked on up until this point. Unfortunately due to unforeseen issues, we were unable to reach all of our goals, an we were instead stuck on one task for a vast majority of the sprint. Our goal this sprint was to test the backend and the endpoints to ensure that they can all work with each other in the way that we planned. We initially thought that we had solved many of the issues with the backend that have been plaguing us in the past sprints, but unfortunately that was not the case. In order to test the endpoints we needed to be able to run the backend, and when we attempted to do that we realized that what the previous group had left us was not configured correctly and was also missing a lot of important code. Upon realizing this, Kurt and I went to work trying to figure out what exactly was missing and preventing the backend from running correctly. This debugging took up a vast majority of the time, and in the end Kurt was able to figure out what the main issues were and managed to get the backend partially running. This was still not enough for us to get our endpoints tested however.

Given that this sprint was more of a challenge than initially expected, there are definitely things that we could have done better as a group in hindsight. One of the bigger mistakes I believe we made was that we didnt have everyone working on the backend problem. Since this was the priority, it should have been a team effort to try to solve it and get it running as fast as possible so that we can test the rest of our code. Unfortunately since in the beginning we didnt realize the scope of the issue we never organized the work in that way. Many of the team members were forced to wait until the backend was complete before they could try to do the tasks that they were assigned. However since the backend never ended up getting fully completed these team members did not have as many opportunities to contribute.

Given hindsight about my performance in this sprint, and knowing what the issues we faced were I can look back and see that there were definitely things I could have done better. One of the main things that comes to mind is my initial approach to trying to solve the backend issue. At first I simply attempted to brute force the problem, moving code and files I thought might be affecting the issue around in the project to see if that changed affected anything. This proved to be a useless exercise in the end and resulted in me wasting more time than I should have. If I could do it again I would approach the issue more slowly, reading through all the relevant code and researching what issues may cause the kinds of problems that we were experiencing.

I do not have any gitlab links to share, since I was unable to get the backend working and therefore had nothing to push. As I mentioned a majority of my work was brute force trial an error where I attempted to figure out the issue.

From the blog CS@Worcester – Sebastian's CS Blog by sserafin1 and used with permission of the author. All other rights reserved by the author.

Sprint 3- Retrospective Blog

For this sprint, my team, team 1, managed to complete all the epics that we had, which were .gitlab-ci.yml, fixing API, modifying backend, finishing frontend, and completing documentation project. I believe my team is done with the API, backend, and frontend. A small portion of the gitlab-ci.yml and the documentation project are still in progress.

In this sprint, I have worked with backend and frontend projects. For the backend, first of all, I modified the API to reduce the number of endpoints from 5 to 2 which getReport and getVesion. Then, to send fake data without using any endpoints, I created a folder named send_Fakedata_RMQ. This folder contains two files, one is used to contain dummy data and the other one is used to create rabbitmq connection and send those dummy data to a rabbitmq channel. So, whenever we use the command of node ./src/send_Fakedata_RMQ/sendData.js, we are sending dummy data to rabbitmq. These data are used to test how the entire backend works. To automatically retrieve those data from rabbitmq and store them into mongodb, in the index file, I added a new method called RabbitMQ_service(). In this method, I used setInterval() function to repeatedly retrieving data from rabbitmq every day. The fixed time used to delay between each call should be converted from day to ms, 86400000.

For the getReport endpoint, I’ve added two new properties called new_household and new_people, which represent the two columns of the Newsince field in the example report. Furthermore, I also edited the csv.js file to make the getReport endpoint return the report in text form instead of downloading it directly to the computer.

For testing, I created two tests for this backend. One is used to test the response status, the other one is used to test the response data. To test the response data, I added a new file called expectedResult.js in the testing/test/lib folder. This file contains a string where each value in this string is manually counted based on dummy data I sent to Rabbitmq. This string is supposed to be my expected result which I am using to compare with the actual result recieved from the system.

One of the problems of the backend is about what should be stored in the guestInfo collection. Since I misunderstood the properties of the guest variable in json, I stored each guest as a unique guest in the collection without the “date” property. The requirement of this collection is that every record of each guest must be stored with a date and time, so this issue must be fixed in order to produce an accurate report in the near future.

For frontend, I added the same folder named send_Fakedata_RMQ from the backend to send dummy data to check whether the frontend is working or not. In getReport.vue, I added a method called downloadCSVfile(data) to download a file named WCFB_report.csv, when the “Submit” button is clicked. I also added a simple instruction of how to run the frontend in I believed we are done with the frontend and it works fine as expected.

For this sprint, we all focused and worked on different topics to perfect the reporting system as much as possible. Most of the time we worked well as a team, but there were still some points that I think we should improve in the future. Like what I just said, each team member worked on a different topic, so it is hard for us to keep track of all topics at the same time. Team members should actively share the problems they are facing so that the whole team can look at it and help them as soon as possible. Don’t stay silent and wait until the last minute without giving any reason to the team. I mean each team member should be aware of his/her responsibilities to the whole team. On the other hand, for myself, I think I should learn more about teamwork skills to ensure that every team plan is completed by every member before the deadline; or at least I can come up with some solutions to deal with similar situations.

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