Skip to main content

Sprint 2 Retrospective

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

Here is the Link to the repositories that contains everything we worked on Sprint-2. Backend, Frontend, Event system, and Keycloak.

RabbitMQ Docker container:  Created a Docker container for Reporting Team

Learn how to get messages from Queue:  Learned How to send and receive messages using JSON object

Meeting with other Event System Team:  Met with the other teams to discuss the format and schema

Review CSS and HTML:  Reviewed CSS and HTML for the Frontend design.

Work with Backend/Database for MQ: Worked with Database and Backend to figure out the Receive file.

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object.

What worked well / did not work well

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object. I noticed that working together with the team has improved our work productivity significantly and working together helped us to solve problems as a team. For this Sprint there were still a lot of confusing elements. Especially, we had a hard time understanding how the report worked and what the data was involved in the report. Also, the issue description on Gitlab was not precise enough or was not broken down into steps. We were lost in some aspects and did not know what questions to ask. However, it is almost the end of the semester and everyone is busy with exams and project from other classes

What changes could be made to improve as a team?

As a team, we should be communicating more with each other and the professor whenever there is confusion or questions regarding the materials. Also, breaking down the task into small issues will help the team tackle problems one by one. I think it will be great for our team to talk with the other group for example all the FrontEnd people can meet and talk more about the issues and problems they are facing. The same goes for the backend, this will help improve as a team. We also need to add more info to the cards which solve the issue of any confusion regarding who is doing what task.

 What changes could be made to improve as an Individual?

As an Individual, I should be talking with my team more rather than just doing the issues that are assigned to me. If I am struggling with something, then I should ask my teammate or the professor for help rather than just waiting and trying to figure out myself. Since it towards the end of the semester and since every class, I have a project, I should be planning or a schedule to work on individual tasks rather than doing everything at once.

Overall, this was a great learning experience. I think the second sprint was a success and we got a lot of working parts done for the project. I’m looking forward to seeing what the reporting team will accomplish towards the end of the semester.

Comments

Popular posts from this blog

Apprenticeship Patterns Blog – Learn How you Fail

For this week’s blog post, I read the section “Learn How You Fail” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The quote beginning of the section is what stood out to me the most. It says, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.” The section talked about how sooner or later you may face failures but the right thing to do is push forward at the boundaries and learn to overlook the mistakes you have faced. In our field, we face many failures but that is not holding us back to accomplish the goals we have set for ourselves. The author mainly talked about becoming conscious of the things that trip you but allow yourself the choice of working to fix the problems that are cutting the losses. One of the most important things to do when you face failure is to accept it and investm

REST API's

This week on my CS Journey, I want to look closely at the topic of REST API Design. I know We have been doing several activities regarding the topic in class and the homework assignment is associated with it, however, I wanted to be very knowledgeable on the topic, so I decided to do more research. REST is an acronym for Representational State Transfer. A REST API is a way for two computer systems to communicate over HTTP in a similar way to web browsers and servers do. Let start by looking at what An API is,  An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer generally creates the API on the server and allows the client to talk to it and the REST determines how an API should look like. Now let’s look at the anatomy of a request is, An API request has four main important parts: The endpoint, The method, The headers, and The data or body. When an API interacts with another system, the touchpoints of that commun

Apprenticeship Patterns Blog - A Different Road

For this week’s blog post, I read the section  “A Different Road ” from chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how taking a different road could be a risky or life-changing event.  Despite this risk, I believe that one should be not afraid to do something different with your life. A change no matter whether they seem good or bad at the time will teach you something new or a new experience that can drive you to push forward. The author started the section by talking about explaining how saying goodbye to the craft can be risky, but  “Even if you leave the road permanently, the values and principles you have developed along the way will always be with you” I think this is very true, no matter the change, the principles you have acquired so far in the career will always be there for you. Currently, I want to talk about the sad reality and risk one may face when one changes a craft. The author talked about how a per