Sprint 1 Retrospective

Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I created a sample frontend using vue.js and learned how to build up the environment and set up a sample project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I learned how to create a climate for vue.js on Udemy and Youtube to set up my vue.js settings. I used my tutorials to build my first sample project.

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

I am working with Migena for the Small Frontend, which is going to test the login feature with keycloak. We will use vue.js to build the Frontend and the third-party system, keycloak to test it. We will see how a real example of securing our system with keycloak. Our goal is to build a simple frontend to test keycloak.

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

I will keep meeting with the other teams working on the Frontend to discuss the Frontend's style, format, and other components.


Reflection on what worked well?

The reflection on what worked well is that we work together with the team members we have worked with before to complete the project plan. Because we have worked together in the same group before, we have a deeper understanding of our teammates and are more accustomed to each other's habits. There will be a relaxed and happy working atmosphere in the group, and the chemistry between the groups will encourage each other and push the project forward.


Reflection on what didn't work well?

The reflection on what did not work well is that we didn't know much about the project initially and thought it was a big project. When faced with the unknown challenge, we were a little confused at first. As we got to know each other and started to move forward with the project, we found that labor division was not reasonable. Because in many issues, Frontend and backend are related. Being responsible for each task affects productivity. So we have overlapping project leaders working together to complete the job, which leads to increased efficiency. It was difficult or challenging to push the task forward, but we encouraged each other through the ZOOM meeting after class.


Reflection on what changes could be made to improve as a team?

As a team with cooperation experience, smooth communication, and tacit understanding among team members are the basis and key to improving our team's cooperation level. We would discuss the project after class and give some constructive suggestions about each other's tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members' tasks. Each knew the other's project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress together.


Reflection on what changes could be made to improve as an individual?

As an individual, I need to improve my understanding of the Frontend more quickly to help my team better connect Frontend and backend. I need to arrange my group tasks more reasonably to help promote the whole group project's completion. Besides, I also need to make clear my work objectives, continue to follow up on the team's project, and make my part and the whole develop simultaneously. 

Comments

Post a Comment

Popular posts from this blog

Breakable Toys

 We can all benefit from writing random "toy" programs to push ourselves to the limit by setting artificial limits. -- Donald Knuth, The Art of Computer Programming If you can learn as much from failure as you can from success, you need a relatively private space to look for the loss. In balling acrobatics, a performer who tosses three balls will never progress if he has never tossed five. Those who spend hours picking dropped balls until their back hurts eventually get good at it. The same lesson applies to software, where software workers often need to step out of their comfort zone to try something they're not good at it. It is by taking bold chances again and again that you improve your skills, that you learn and grow from failure after failure. Just as a three-ball-tossing performer does not throw five balls in a formal performance, software developers often make mistakes in new areas. Software developers also need a safe place to make mistakes. It's terrible not
Read more

What is Rest API

  API is short for Application Programming Interface (API), which describes a class library's characteristics or how to use it. Your personal library may contain "API documentation" of available functionality. A REST API in API Gateway is a collection of resources and methods integrated with back-end HTTP endpoints, Lambda functions, or other AWS services. You can use API Gateway features to help you with all aspects of the API lifecycle, from creation through monitoring your production APIs. API Gateway REST APIs use a request/response model where a client sends a request to a service and responds back synchronously. This kind of model is suitable for many different kinds of applications that depend on synchronous communication. When many people refer to API documentation these days, they often refer to an HTTP API that might share your application data over the web. For example, Twitter provides an API that allows users to request tweets in a specific format to easily i
Read more

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program's source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them. Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data. The program under test is treated as a black box, without considering the internal structure and characteristics of the program
Read more