Sprint 3 Retrospective

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint was primarily getting the local Kubernetes demo to run.

For this sprint we tried to evenly distribute the workload as much as possible, so that no one was doing too much or too little. Since we had a total of 25 weight to complete this sprint, we tried to get everyone to do around 5 points worth of work, since 25/5=5. We did not put too much focus on how those 5 points were distributed, however, so someone could have done 2 2 weight issues, and 1 1 weight issue to get their 5, they could have done 1 2 weight and 3 1 weight, etc. All that really mattered was getting everything done and done well.

Overall, I cannot say much that did not go well, as everything went pretty smoothly throughout the sprint. I feel that if we continue with what we are doing going forward we will do well as a team.

We tried to communicate as much as possible during the sprint, and when we were not able to communicate in class, we either talked through Discord, or had Zoom meetings to talk and discuss. I feel this helped a lot throughout the sprint so that we all had a good idea of what was being worked on, where everyone was on what was being worked on, and what still needed to be worked on.

While it seemed to be somewhat the same for everyone else, I felt the workload balance of the work I did was very well balanced. I did not feel too overwhelmed at any given point, nor did I feel I had too little to do at any given point either. Everything felt just right, and I hope that we are able to continue with this type of workload balance going forward in the future in future sprints. I know that this sprint was primarily the research sprint, and that the future sprints will be heavier with more work than research, so I hope that we will still manage to find a good balance with the work that we need to do in those remaining sprints.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/demo-deployment/-/issues/1

The above link takes you to my GitLab page that I did for deploying the Kubernetes cluster locally. Overall it was pretty easy and straightforward and did not require too much configuration to make everything run nicely.

I also started but was unable to finish writing the README for the demo, but since we were unable to finish the proper demo before the end of the sprint, I had to scrap the README. Unfortunate, but I did not spend that much time working on it so not too much time was wasted on it.

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

Sprint 3 Retrospective

Our third and final sprint for the semester was our strongest sprint to date. Everyone in the team could feel that we were really hitting our stride and solving issues as they were being created. We were able to look at what went wrong in our prior sprints and not get trapped in the same pitfalls that we encountered early in the project.

The Good

We were laser focused on what we needed to do. Our productivity and communication levels were at an all-time high which really helped in the amount of work we were able to produce. We were also able to realize when an issue was more than a bite-sized problem and successfully broke them up into smaller issues as needed. We had a clearer vision of the direction we wanted to take the application in and for the most part we met the expectation we set for ourselves this sprint: A demo application that highlights its main functionality.

The Bad

I mean… There wasn’t too much that really went wrong with our workflow during this sprint. I think the feeling that we performed very well was very tangible to anyone watching us operate as a team or looking at our team’s activity on the project repository. The only bad thing that would come as a result of this sprint is that we are concluding our work on our application that we witnessed grow from inception.

What could we have done better?

I feel like the only thing we could’ve done better was perhaps having a longer discussion on how we envision the app to look in the future. Leaving better instructions for the next team of students who will work on this project is the only thing that comes to mind when I think about anything we might have lacked in.

Contributions that I added to the application include

Writing Portion:

Create a writing page for an examinee to record the prompt they heard from the proctor. They will type out what they heard instead of using their finger or a stylus to write it out. The current version of this feature is a temporary solution until a way to implement the correct functionality is discovered.

Create a page that holds all the prompts the test proctor will ask the examinee to write(type) in English. A .csv file named “sentences” was added into the projects assets folder. The Prompts.js file reads from and parses the sentences from the file into a list which is then displayed in a ScrollView on the page.

Adding React Native Paper styling to Writing and Prompt pages. We decided to use React Native Paper styles throughout our application. In order to remain consistent with the application design, I added card features for the elements on each page.

Merging of Writing page and Prompt pages. After the pages were created a teammate suggested that we merge the pages instead of having to navigate too much. This was a great idea because it was much easier to implement than having to move from page to page as well as improving the UI.

Reading portion:

While working on my own issues, I aided my teammates in working with our app’s counterpart to the writing portion. The bug we encountered involved displaying a question from a list of questions on a separate page. While we couldn’t resolve the bug itself, we were able to verify that it is possible to display another question successfully on a “new page” but do not have the means to display the correct one at the moment.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

As many of the others in my group have said this was probably the best Sprint, we have had this semester. What specifically went well this semester was right when the Sprint started. That was a problem we had the last Sprint because we had a slow start because of Spring break. When this semester started, a lot of us were in the middle of working on issues so when this Sprint started, we continued working on the issues. A big problem we had last Sprint was we did not do enough documentation. Towards the end of the second Sprint and the beginning of this Sprint, our group made a big change. We decided that we would do little to no work in class and instead focus on updating the group on what we are working on, cleaning up our issue board, resolving any major issues that we encounter before that class, and documenting the progress we made in and out of class. This is because we made the realization that most of us in the group worked better alone, but when we ran into issues none of us were shy about bringing them up in the group meetings. We also did not have any issue asking others in the group for help. This was one of the most successful changes we made to the group. When we made this change, it caused the productivity of the project to skyrocket.

What I think did not go with this sprint was how ambitious our group was this sprint. We planned to get a lot complete in a short time and it did not all get done. For example, we wanted to complete the cards.js file and the display.js file as well as the prompts.js and writing.js file. We also wanted to add theming to our project so that it would look neat and professional. We ended up finishing the cards.js file but did not finish working out all of the bugs for the display.js file. In terms of the writing portion of the project, what we wanted to use at the start of the sprint did not end up working and we ended up adding a placeholder with some functionality so that we could have something to present.

I think we did not have too much to work on this sprint as a team. For the most part, I think it worked out very well. I think as a team we really improved our documentation this sprint. What I think we can improve a little is our individual documentation for issues and other small features that we worked on. Towards the end of the sprint, our documentation was a little lacking compared to the beginning of the sprint because we were rushing to the finish.

During the sprint, what I worked on was leftover from the previous sprint. In the previous sprint, we made a display page, but it did not properly transfer information from one page to another.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/30

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/55

So, for a while, I contemplated how to move forward in the project and considered restructuring our project or looking at other ways to transfer information from one page to another.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/51

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/54

How I fixed these issues was by simplifying our structure and moving screens to their own respective files.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/61

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/60

Before this change, our app.js file did too much and was handling the navigation for the project as well as creating multiple screens. Moving things to their own files simplified our file structure and fixed some of our earlier navigation issues as a result.

When I did this change to restructure our project, it made creating the display page a lot easier and I was able to get it working to an extent. We can transfer information and display it on the screen but it currently does not display the correct information.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/65

This is not because our function is wrong but because our logic is off. The function displays whatever we pass but we have a hard time figuring out what to pass. I was really stubborn at first when I encountered this issue and did not want to ask for this last issue. I have the issue at a weight of 2 but it is definitely more. Even when we had three people working on it, it was not done. So, what I need to improve on is to be less stubborn and ask for help even if it’s last minute.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Reading List

Summary:

Reading List pattern recognizes that as software developers/apprentice we need to start learning the next thing, but how do we choose from the vast ocean skills and information available. The pattern recognizes that its not only hard to decide which language or area we want to master next but also which book or books will be the most appropriate for that step. The pattern recommends the simplest possible implementation that is to create a reading list. Reading list could be just a text file with a list of all books that have been read, books currently being read and books we plan to read.

Why this pattern?

Reading List pattern helps answer one of the most difficult questions, what next? Now that I am done with college, the obvious thing to do next is to find a job. However, the list of the things I have barely managed to scrap the surface of in the last year, specifically the two capstones, its like I have a bitter after taste in my conscious. The pattern has covered every possible question I can have. Which book do I start with? Ask help from a mentor like a professor or pick a book that covers a broad spectrum of the topic I want. Which book next? If I want something in the same area, I can go deeper. For example, after software development, now maybe I can focus on web development or mobile application development. If I want to learn a new language, I can google the most in demand computer language and chose from there. Sometimes I can find our next book within the bibliography of the current book I am reading. If I want to expand my horizon and read something outside of computer science; I can publish my list online and ask my peers and more experienced community members to guide me.

The pattern also recognizes that sometimes in order to keep the list updated, the order of the books will keep changing. Moreover, sometimes due to priority changes or simply advances in technology, some books will keep dropping down in the suggested column and we might never get an opportunity to read them.

Where I disagree:

Nowhere, unless there is a pattern out there that can control a person’s mind and force them into start reading.

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

One More Sprint (CS-448 Sprint Retrospective Blog 3)

INTRODUCTION: As the final Sprint of my team’s Software Development Capstone project introduces its conclusion, I feel as though it is a good time to reflect on the results of this sprint. Going further, some aspects of this blog (specifically the conclusion) will involve reflection of the project in its entirety. To start, I believe that this sprint may have been weaker than previous ones. Factors supporting this argument include the idea that we now have experience from the previous sprints and that we should be more prepared; factors against the argument include non-work related considerations (such as future semester set-up).

POSITIVE FACTORS: During the final sprint, these favorable events had occurred:

  • Our team had made progress on getting Keycloak into a Docker container. Hopefully, futures semesters will be able to complete the project for us (allowing connection to the AWS Team, and other teams in general).
  • Speaking of progress, our Product Owner (our Instructor/Professor) has mentioned that the team has made an impressive amount of progress in general. Factors involved with the amount of progress include comparisons to previous semesters’ work, and consideration of the fact that our team had quite literally started this project from scratch.

NEGATIVE FACTORS: As much as the team has improved, there were still some bumps in the project’s road. These bumps include:

  • To contrast the statement in the “Positive Factors” section, work on the Keycloak Docker container has been completed, but we do not have a final product yet. However, in our defense: part of this sprint was spent setting up the project for the teams that will work on it in the future.
  • As mentioned in the “Self-Improvement Suggestions” section below, this team has done quite well during this sprint (considering the fact that the Scrum Master was not as involved as previous sprints). I understand that Scrum Masters do not have a drastic amount of authority over the rest of the team; at the same time, too little involvement with the team’s work essentially makes them a facilitator “in name only”.

TEAM IMPROVEMENT SUGGESTIONS: Even though we have no more sprints left for the project, it is still a valuable form of criticism to discuss where the team can improve. Factors involve:

  • I believe that additional dedication to Sprint Planning would be beneficial for the team. While our first two sprints involved research of our issues (in other words, we didn’t know what we needed to do), having a clear idea of the end goal will make for more efficient work. This is opposed to issues being brainstormed and abandoned like darts thrown at a board.
  • In addition to Sprint Planning, having a better structure for our Sprint Review/Demo classes can help. While we get our work done, it’s also important to know how to present it in a neat, organized manner that is easy for the Product Owner to interpret.

SELF-IMPROVEMENT SUGGESTIONS: In addition to team improvement, there is always room for self-improvement. Some ideas for my own improvement are:

  • Since I was the Scrum Master for this sprint, I must say that I was not as involved with the role as I would have liked to have been. In future projects, I would like to dedicate more time to the role; hopefully, outside commitments won’t weigh me down like they did during this semester.
  • In future Scrum work, I would also like to be more involved with Gitlab issue board work (this factor ties into my criticism of my Scrum Master performance). I feel as though reviewing and commenting on issues isn’t enough; taking the initiative and creating issues is a key factor of being a leader on the team.

Considering the project (and its semester) as a whole, I will say that I appreciate my teammates and the work that they have done. We have all made this Capstone project a pleasure to be involved with; in fact, due to how pleasant the overall experience was, I have shown interest in working with the LibreFoodPantry software outside of the class. To be honest, there’s no reason not to be involved – working with LFP has varying levels of commitment. Regardless of the commitment level, the work is a great way of acquiring work experience and keeping Software Development skills fresh.

LINKS TO GITLAB ACTIVITY:

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Just Gotta Keep Sprinting… (Sprint Retrospective Blog 2)

INTRODUCTION: Compared to the first sprint, “Sprint 2” has gone better in some ways. However, in other ways. we definitely have dropped in performance a bit. It’s no one’s fault; part of working within these sprints is figuring out what needs to get done now, and what can be done later.
POSTIVE FACTORS: Here are the following improvements since the last sprint…

  • We have set up a form of “login” based on Keycloak software. This Keycloak login has also been set up via JavaScript to act as a “re-direct” from the barebones frontend that we had created during the first sprint. I often refer to this “connected demo” as a HTML/Keycloak/VUE App or project. This is because that’s exactly what happens with the current demo: a user will start in the HTML index file, and then click on a button that redirects to a Keycloak login. Once credentials are entered, the Keycloak login will take the user to the VUE App.
  • The group has figured out how to work with Keycloak – in particular, we understand how to create users, set up privileges for users, and group them within a “realm”. We also understand the hashing algorithms used to make JWT Tokens, alongside the structure of a token when de-coded.

NEGATIVE FACTORS: The following factors, as of this sprint, should be worked on…

  • The group has reached out to other groups, as well as LibreFoodPantry staff. Still, I feel as though communication is key; the more communication that our group can make with other staff, the better.
  • Our team’s organization of the Sprint board could have been better. Specifically, I feel as though moving issues to the “Needs Review” section as they are completed would be preferable to moving them all at once.

TEAM IMPROVEMENT SUGGESTIONS: Here are some ways that the team can improve for the third, final sprint…

  • I have made the suggestion that the team could benefit from “POGIL-Style” roles, where each team member performs a specific task for the group. As emphasized throughout this blog, the role that comes to mind is “communications”; while not very “programming-heavy”, this role involves reaching out to other teams and staff. This keeps everyone “in the loop” so that they can plan their sprint work accordingly for the eventual project integration.
  • Similar to my discussion within the self-improvement section below, I feel as though the group can benefit from work that is focused towards issue/epic progression. While we are making progress, it seems as though we have to scramble to figure out exactly what is done during our sprint review.

SELF-IMPROVEMENT SUGGESTIONS: As for myself, here are some factors that I need to work on for the future…

  • I need to dedicate more time to this project. I have made this issue clear in the last retrospective blog, but failed to work on it. This project, and this class, are extremely important for my professional reputation. Having “outside factors” as a reason for why work isn’t done can only be justified for so long. Eventually, one side has to give: either the outside factors, or the project.
  • I feel as though “issue-focused” work would be better for long-term progress. While it’s great that I seem to be making progress with Keycloak, my work is scattered. This issue reflects itself in the progress made on the gitlab issue board.

When creating this blog, I took a quick look back at my first Sprint Retrospective blog; I wanted to make comparisons on mistakes that have been amended during the first sprint. Unfortunately, having this blog posted on time is not one of those amended mistakes. Looking on the brighter side, I feel as though focusing on these blogs is not as important as I make it out to be (this was a mistake that I made during Software Architecture).

LINKS TO GITLAB ACTIVITY

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

My third and final sprint for my software development capstone has come to an end. Here is what I did, and my thoughts on it.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/6#note_911958619

This represents my thoughts on this file after looking it over. There’s probably still room for improvement but I didn’t think it was the best use of our time.

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

Changed the API to swap out json for plain text, since we want to return a .csv file.

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

Removed this because the previous commit made it unnecessary.

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

Some minor restructuring of the API.

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

Fixed a typo in the filename of the .yaml file mentioned above.

I think everyone had a pretty good work ethic. While individually we may have struggled, we collectively knew what we were doing.

As far as things that didn’t go well, I think we’re still struggling with assigning correct weight point values and issue granularity. Most things I did felt either too easy or too hard for their given point values, mainly the former.

The issues we made mostly felt to me like they were too specific. Sometimes this meant they were too easy, but not necessarily. I think it caused unnecessary confusion, since what should be one task might get split up into three, done by three different people. There’d then be no way for any of them individually to check their work.

There’s the possibility of coordinating the issues so that it’s clear they’re dependent on each other, but I think it would be simpler to just have them all be the same thing. I wouldn’t coordinate issues in this way unless they were clearly separate tasks, but still related.

One thing I think we could have done as a team is coordinate more. I think communication was our biggest weakness. I always felt like no matter what I was doing, I was always kind of going off on my own. At the start of the semester, we agreed to take turns being the scrum master, but as it went on we focused less and less on procedural concerns. I think we could have benefited a lot if someone had stepped up to be the team leader.

As far as things I could have done to improve, I could research more. My biggest roadblock was not really understanding how all the moving parts fit together. I think I overestimated my skills a lot. Also, in the context of a college class, there’s a strong incentive to just do the bare minimum to pass, with any independent study taking away from other classes and out of school activities. I did manage to get a little bit of independent study about the tools we were using in, but not nearly as much as I’d have liked.

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

Sprint 3 Retrospective

For the last sprint, the main objective, from a frontend perspective, was adding some final touches to the code and making documentation for next years group. My biggest objective however for this sprint was to get semantic versioning to work. Semantic versioning, in simple terms, allows us to make version tags for any ne code that is pushed to the main repository. For example, if I pushed something new to the main branch that is a new feature, it will tag this as let’s say “v2-0-1” and it will make a container as well with this tag. This is helpful to us because if we ever need to go back to an old version of the code, it will be easy using the tag container in our docker-compose file. This for a few days was giving me issues until I found what the cause was. The main issue was our docker compose version. Throughout the sprints we have been using version 3.8 but for semantic versioning to work I need to add a docker compose apk to the ci and change the version to 3.3. This allowed the versioning to work and tag.

For this sprint I though everyone worked well together and got a lot done on both the frontend and the backend. Like the other sprint we did a divide and conquer style of completing the issues the were left for us to finish in this sprint. Everyone had a final hard task to do in both the frontend and the backend which gave us more hands-on knowledge that we all can take to our future workplaces.  The only thing that I think didn’t work well for this sprint was people doing task but not assigning themselves the issues. We had an issue where two people were working on the same issue which caused confusion between the two. A compromise was eventually found, and the issue was complete but in the future people should not be doing this as it could lead to a bug or error In the code from different algorithm styles.    

As a team, besides what I talked about above, I found that there is not much we can improve on as a team. I found that this sprint went very well and am proud of the work the was complete during this time. Also, this being our last sprint we will not meet again to be able to improve together. As an individual like last sprints, I had some issues with commits again. For semantic version I had roughly 30 commits trying to test the pipeline and find the errors. I could not find a way to test the ci locally, so I swamped the commit log with tests. In the future I need to either find a way to test ci locally to make changes before clogging the system or I need to e better about error tracing so there is only like 5 commits compared to 30.

Commits:

Update guest data to new datapoints: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/5de3e0c143b3cabb9a517839257be9a3adec33d4

Updated port numbers in code: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/94d4e5e98e17f1f37e3ec87dc5f307b69d1cc762

Updated README: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/8edbb8c6b24592bea5da04418032c49f03469638

Semantic versioning: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/82ce990f6d689810a6bab6ad7e31f89ab8614a28 and many more commits in repo for testing

Fix v-show bug: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/b3cdca325396169af224897768dd80d1d069e2b8

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Retro #3

With this being our last Sprint for the semester, it couldn’t have ended on a better note. Cooperation between the team members and communication continued to be effective. Everyone seemed stepped up and the work ethic was beyond that I could imagine. Comparing to other team/group projects I have been on in the past.

During this sprint, I worked on creating a key for the endpoint authentication. We were still waiting on the actual key from the IAM team so in the meantime, I created a code that will give authorized individuals in the LibreFoodPantry access to their sites. Such has if a guest has access to the LibreFoodPantry portal, once they put in their login credentials, they will either be authorized or unauthorized. This was by request of the client.

Some of the issues that we faced was the getRange API calls. This method required additional coding to the NestTester, API and the backend. Once that was completed, we were able to move on from this project.

I think over the past two sprints, our usage and knowledge of GitLab Epics and Issues board just continued to improve. One issue we faced in the beginning was apply the proper weight to each ticket. As the sprints continued, our distribution of the weight continued to get better. We ended having a better workflow and a more balanced and shared workload.

With a good portion of our task completed, we mostly spent this sprint communication with the IAM team to get a better understanding of when they need to integrate security mechanisms into our remote function calls. We concluded that this will not be complete this semester and will have to be pushed to next years Capstone class.

We were giving the option to continue to work on this the rest of the summer to better improve the progress that we have. This is not a bad option since technically this is for a real work client that is expecting some type of prototype. Joe has decided to stay on and continue to work on this while myself, I have opted not to. With this being my last year, I have other opportunities that I will be pursuing to better myself in this field.

As the conclusion to this spring, the group decided that each member will record a portion of the project and prepare a video presentation. I’m overseeing the consolidation all the recordings and preparing a video presentation for Dr. Wurst. We broke down what needs to be discussed and each member will pick what they would like to talk about. I will take what’s left over to check off all the topics that we would like to discuss/present.

The capstone was a good experience and helped be become a better team member. Being able to see each member grow from the first sprint till now is always something that I am proud of because I know they each learned and took something away from this class. Not all was smooth, and we definitely had some bumps along the way but in a real world scenario, that is what happens and you have to learn how to adjust and get over those bumps. Theirs always a solution to any problem, isn’t that was coding is, solving problems.

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Retro #2

For the end of Sprint 2, I would say the team really came together to help each other out. We were able to see each other’s skills and start coding. The communication seemed to improve throughout, and the group decided to let Joe continue to be the scrum master for the rest of the semester since the first Sprint he couldn’t really apply scrum master duties. This time around we were more focused and ready to tackle this sprint and give our best work. For this sprint, we assigned fewer task to people with higher weights because we knew it was going to take up some time to build the backend. We were able to produce an OpenAPI for the requested endpoints. We used the yaml file provided that helped us write, build and then test the endpoints in our backend. Then these methods were tested using Visual Code Studio to launch the HTTP request from the guest.http and the qs.http.

During this sprint, while building the backend, we ran into some issues on how to get the calls. http POST, GET, PUT to work for our guest information code. First, we assigned each call to a member in the group. I oversaw creating the get DELETE which was giving us some issues. The error ended up being just minor coding grammar on my end that was easily fixed. Unfortunately, I was operating under a different branch so every code that I sent or corrections to the code that I made, was being pushed to another section of the LibreFoodPantry. Once that was corrected, I was able to continue to help my team. Another issue that we ran into was our Questionnaire call. The reason we were having issues is because Mongold gets created and returned on a post. Any record access after that must pass with a key for that item. Another issue we faced were that the Android app was producing a Timeout Error which we sought counsel from Dr. Wurst on how to correct that in the next sprint.

Overall, I was really impressed with my team since we accomplished two of the major goals that we had. First, was to improve the skill-set of the team members. The first sprint was all copy and pasting documentations. This sprint we all had to show our coding abilities and was able to learn from one another if was lost. Second, was that we were able to help the general progression of the LibreFoodPantry.

For the next sprint, I believe we are starting off on a good start. We were able to fix all the errors that had with our backend, all of our calls are now working with no errors and has a team we have better communication and organization. Joe has really stepped up and lead us to a good position.

Links to my tickets:

API: add endpoint to return current version (#21) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / API · GitLab

HTTP Get Range of Questionaire Submissions (#19) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / API · GitLab

backend: set up devcontainer.json for extra tools needed (#2) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / Backend · GitLab

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.