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 entrypoint.sh, 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:

Calls

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/34

Backend Debugging

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40

Modification of files

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/41

Cooking Method test

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/28

Cooking tip test

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/42

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.

Commits:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/7ddbba9a43a71fa588c8b34f3ca1a16d43c39709

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

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/c0a121daa6e5d45ec00fa01642289677119d658a

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 README.md. 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.

Sprint 3 Retrospective

In our final sprint, our team focused primarily on finishing our demo, communicating with other teams about their projects and how they will fit into the cluster, and creating a schematic of the final cluster. I think our final sprint went really well. While we did not finish everything we set out to, we were able to get a significant amount of work done, and I think we have left the project in a good place for whoever will be picking it up next.

I think a lot of things went well in this sprint. Similar to our second sprint, we had a much clearer understanding of what we wanted to accomplish in this sprint, and that made it much easier to divide work into manageable tasks. Unlike the last sprint, much of this work could happen concurrently, so team members were blocked less often by the issues other team members were working on. Additionally, I think we were all much more comfortable communicating with each other, and this allowed our work to go much more smoothly.

The only thing that didn’t go well was how much work we wound up getting done by the end of the sprint. We initially planned for thirty points of work, and by the time the sprint had officially ended we only got through about half of that. I think we underestimated how long some of our issues would take to complete and wound up falling behind. Regardless, I feel that we got a substantial amount of work done.

Our team worked very well during this sprint, but there is always room for improvement. I think we could improve on our time management a little bit. We spent a lot of time discussing how we would like the sprint to go, and this left less time to actually work on our issues. Still, I don’t think this impacted us too heavily; I am happy with the work we did get done.

Personally, I think I could improve on the way I write documentation, especially summaries of research I’ve done. I tend to get overwhelmed by whatever information I’m reading and will forgo some details in my retelling. I want to be able to write more detailed documentation since that would be more beneficial for my team members.

Contributions:

Research Helm – I spent time looking into Helm, which is a package manager for Kubernetes. I researched what it is, how it works, and whether it would be worth using in the final cluster for Thea’s Food Pantry.

Communicate with Team 1: Inventory System – I informed the Inventory System team about our work, and I made sure we understood how their project is structured.

Communicate with Team 3: Food Keeper – This is similar to the previous issue. I informed the Food Keeper team about our work, and I made sure we understood how their project is structured.

Communicate with Team 4: nest Guest Info – This is similar to the previous two issues. I informed the Nest Guest Info System team about our work, and I made sure we understood how their project is structured.

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

Sprint 3 Retrospective

(I’m sorry if some sentences are hard to understand. I am pretty sick at the moment, and it’s hard to make sense sometimes)

Our third sprint had two end goals, deploying a demo locally using minikube then hosting it using AWS EKS, and discussing with the other teams on what they’re working on so we can make a schematic from their work in a hosted Kubernetes Cluster. We ended up discussing it with the other teams and were able to create the final schematic. We were also able to deploy a local demo of the Kubernetes Cluster, but we had issues deploying a demo on AWS EKS.

What worked well was discussing with the other teams to get information on how the final schematic would look like, and how our team worked together in organizing the information from talking with the other teams (1). There were also many regards while working on the final project where we came together as a group to set up a schedule, how we’re going to do the presentation, and when we should do it. Afterwards, we were able to use this information to create a schematic illustrating each of the different team’s works inside of a deployed Kubernetes Cluster (2).

I think part of the reason the third sprint was the most difficult was that it was the last sprint in the semester. For example, I and some of my other teammates had a lot of projects we had to get done while due dates were getting close. This made it harder to focus a lot of time on working on the project. Maybe if we focused more time on this project, we would’ve been able to get a demo out, but it isn’t a guarantee that it would’ve happened.

As a team, I think we could’ve been more communicative and dedicated more time to working together on the project. There was a lot of not knowing towards the end on whether or not someone was working on something because communication on some level broke down, especially when some people in the team were busy with other things. This led to troubles with communication, especially when working on the final project. There were times where we agreed to finish work by a certain deadline, but not everyone finished by it.

As an individual, I was constantly trying to push myself to be more active in communication with my team members about updates. However, this does not mean that I was good at it, or I did it without flaws. From my role as a scrum master during this semester, I think that I need a lot more experience in communicating with my team members and being more assertive in initiating conversations and keeping planned dates we agree on in check. 

Links:

  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/49 – An organized compilation of six issues from our team members’ discussions with the other teams.
  2. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation/-/issues/1 – Final Diagram of a Kubernetes Cluster hosting the docker images worked on by the other teams.

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 3 Retrospective

Our third sprint was definitely the toughest, and we ran into some issues throughout the sprint that really slowed us down. We started out at fixing problems for the project from the end of the previous sprint, then moved on to the last issues we put in the backlog. One issue in particular would take a lot of time to solve and prevented some of the other issues from being completed.

Starting with what worked well, we were doing better at communicating with each other and finished with enough weight for the review. When we were having problems with the issues, we were keeping in touch with each other, and most of us were working together on the main issue that was holding us back. Some of us were having more success than others, but it was eventually completed and the other issues that were relying on it were being finished too. We were also able to finish the presentation on time, and had a plan for putting the presentation together with slides and an outline that we put together.

Our main problem for this sprint wasn’t a problem with the team, but with one of the issues we were working on, which had to do with building the backend server and getting it working for everyone. Along with getting the server working, some of us had different issues that others weren’t getting. We spent a lot of time working on this issue, and had to rush through the last issues in the last week. Aside from that, we were still trying to improving on keeping up the merge requests up to date. We managed to get all the merge requests done in time, the requests would just build up over a few days. Aside from that we had some days where team members would not be there in person, but they would join online and were able to join in the in-person discussions through the discord chat.

I think I did well at continuing with the improvements I was making as a team member by communicating with the team when working on the project and the presentation, but there were a couple times when working on the presentation that I missed out on some discussion. I would later join in the discussions, catch up on what I missed, and do my part in recording for the presentation. When waiting on the backend server issue being completed, I had the idea of setting the api tests up with a template for the test files, so that they would be mostly done by the time we are able to use the api. That way, the issues could still be completed while dealing with the backend server. I got this idea from a template file that we had made in the previous sprint for the data files, and a template file for api testing that was created during this sprint, and figured we could have something similar for the api testing methods while waiting. In the endpoint api templates, the testing methods were set up for the api to accept sample valid and invalid calls that worked for samples we had, so when we would be able to use the api for the testing, we could just make new calls to put in those positions and then adjust based on testing results.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/28

Resolving the problems with the category test file so all tests passed.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/33

Template for the category api testing that was created while waiting for the backend server.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/36

Template for the product api testing that was created while waiting for the backend server.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows

The first question that interviewers ask candidates these days is about team experiences. They look at many different factors but working as a team is always an important one. If that person cannot work with a team, that is going to be a red flag. There is a saying that “if you want to go fast, go alone. If you want to go far, go together”. Team work gives people the ability to improve their communication skills, to be more efficient in building products and also to motivate each others.

We may have mentors and kindred spirits that we meet along the way, but people tend to think that software developers usually work independently. The problem is what if the product has reached its limit, the learning is struggling and the feeling that there are superior techniques and approaches to the craft that are eluding us.

The best solution is to find a way to sit down, have a talk with colleagues, and work together on a project. There is always something that we could learn from each other. The case that was mentioned in this “Rubbing Elbows” is Dave, who found an ally in Roman and then literally rubbed elbows over lunch as they learned together about technologies like the Ruby programming language and Eclipse plug-in development. Even though Roman could have not been that kindred spirit but Dave would still have benefited by working next to a talented programmer. There is always a certain technique that we could learn from others because we are not perfect. Therefore, it’s critical for us to be open to learning and willing to take it in. While paring programming can be an excellent technique for learning, it’s a complex activity and is not always an inherently positive experience. And sometimes it is a pain. If we feel chronic behind, week after week, and we’re beginning to despair, then it’s time for a change. The rotation may help jiggle us out of trouble. Ping-Pong programming to increase our participation is also a good way.

The final thought is to find someone we know who has already expressed an interest in starting an open-source project. Spend one day or an evening a week working together on that project. See how things would go, and seek motivation from each other. If motivation never return, it is up to us to seek new partnership where we can learn new thing. Because the best way to stay in workforce of this industry is to keep up with new technology.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Software Apprenticeship Post #4

Today I will be focusing on the Apprenticeship Pattern “Use the Source”. This pattern talks about reading other people’s code to learn by their example of how to do things, so that you have a solid foundation of where to go when you actually start writing the code. As if your code disagrees with your intentions, it will never work.

The pattern also talks about how the “Practice, Practice, Practice” pattern will only reinforce bad habits if you do not know any good ones to practice by. This is important as habits can be hard to break, so it is best to start with good habits rather than bad ones that you may need to break later on.

A good idea is to start by reading code for applications and tools that you use every day and learn by their example. This helps you learn how the other programmers code, and helps you understand the thought processes that create the infrastructure of the programs and tools that you use. Another good idea is to download open source projects, downloading them from the current version of the source code, using source control, to learn the history of how it has changed and so you can learn how future changes are affecting it.

You can then also try to refactor the codebases to try to understand why the programmers made the choices that they did, and also any consequences there might have been if you were the one writing the program instead. This helps you further understand the projects, and it also helps you to build the projects as well.

However, during your exploring you will eventually come across some decisions you may disagree with. It is important to ask yourself if the developers knew something you did not, or vice versa. It is good to realize that maybe there were things outside of the developers control that required them to make those kinds of decisions.

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