Sprint 2 Retrospective

-

At the beginning of this week, we finally reached the end of our second sprint, once a again, completing the back end for the LibreFoodPantry Approve module. My thought on this sprint is that our team did fall behind quite a bit on the goals we set out to finish at the beginning of the sprint due to the fact that we ran into much more problem than we expected and we don't really have much time to meet up with each other like the last one. Nevertheless, we were still able to achieve a decent amount of goal and almost reach the point to be deployable as a product for just the back end.

List of what I accomplished during the last sprint:

- Successfully implemented CI/CD in every main repositories and get it up and running to check for merge requests build (ApproveGuestService, isApprovedWebUI, ApproveGuestWebUI)

- Adding all the required endpoints for the REST API system and set it out as a base for the front end to access data (ApproveBetween, getGuestInfo, approveUpdate)

- Successfully established connection between REST API and mySQL database on each member's machine with a customizable config file to fit with multiple server setup (Backend connection, JSON REST API configuration file)

- Completely overhaul and clean up code for REST API to be more optimized and modular (Fixing date format in Java code)

- Front end wise, John and Kevin was able to make a few basic component to display guest information, made a lot of effort to learn about Material design, and experimenting with communication with the REST API

With a lot of work putting in developing the back end, I learned a lot about how to make connection between REST API system and mySQL. There are a few small things that I can pick up through this run too, like the differences between Docker Desktop and Docker Toolbox, making CI/CD script with different images, and so on.

During this run, it went really smoothly and we only ran into multiple communication issue, and small things during the development process like the date and time is behind when data point is fetched from the database because of timezone differences for some reason, or having to deal with numerous bugs that the default date object in Java caused. Other than those, I think we've done it pretty well.

What we can do better for this run, I believe we can still do a lot better communication wise. We could have made a better use of the Gitlab development board to communicate more effectively on the problems in a related ticket, instead of through Discord direct messages and group chat. I also felt like the UI team and the backend were separated as we did not know much about another group’s progress and whether they need our help in researching anything in particular. If we can develop this in a much longer period, I would like to get more involve in the user interface stuff, as the frontend team was struggling with getting only one UI up and running.

Comments

Post a Comment

Popular posts from this blog

Software Quality Assurance Introduction

-
Hello again everyone, I am taking Software Quality Assurance class and once again, I will be using this blog to summarize about what I've learned through articles and podcast throughout the semester. I've been doing internship the whole summer about software quality assurance on both UI and unit testing and I learned a lot from it, and now hopefully, this class will help me expand those knowledge even further on this area.
Read more

Reflect as you work

-
For this week Apprenticeship Pattern, I chose to read about “Reflect As You Work”. When I read the title, my first thought is that this habit is pretty necessary, but it should not be too hard to have a chapter dedicated to it and turns out I was entirely wrong about it. The pattern starts with putting out the question of whenever a developer can consider themselves as “experienced” and how would that process be in order to reach that destination. The author then went straight to the point to explain how just reflecting our own work would be a best way for us to gain more experience. He explains several techniques like making a Personal Practice Map, which would involve writing down all the practices that we do during the development process and share with others, and mimic what they do in order to be better in the field. I think this particular technique would greatly help a lot of new developers in the field who does not know what to expect when developing and would end up doing wh
Read more

Static testing and Dynamic testing

-
Static testing and Dynamic testing is two different approaches to testing available for developers and testers in the software development process. In order to get the most out of these tests, this has to be chosen carefully and it is important to understand the benefits and the limitations of each one. Static testing is a test method where code are not being executed and it can be done manually or using a set of tools. This type of testing would check the syntax, required documentation and design of the code. Static testing also includes security testing to analyze the software for potential errors, code flaws, or vulnerabilities. This method can be start in the early development stage of the program, and it can be done on work documents like specification documents, design documents, web page contents, etc. Static testing techniques include: -  Inspection: The main purpose of this is to find defections. This task can be reviewing the check lists, work documents, or code walkthroug
Read more