Category Archives: Sprint 2

Sprint-2

Hello, welcome to the Second-Sprint Retrospective Blog. I contributed to the group project by working on the tasks assigned on GitLab. I chose to complete one of the jobs, but it was more difficult than I had expected. I am currently participating in an activity that calls for additional alterations, and adding more details is more complicated than I had anticipated. It is up to the team and me to decide whether to put the modifications for the necessary measures. 

After the team and I adjusted to the issue board required for the work and practice. Completing this ISSUE Weight assignment with a total weight of 3 is reasonable and practicable. 

The Issue:
backend — write a test suite for API (changes); This activity writes test in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working). 

My challenge concerning these works is researching the topic of “Chai.” It explains that Chai is an assertion library written in JavaScript with different test frameworks. It allows maintenance of your code’s functionality and checks that it follows those assertions. It has the “assertions” style comparable to Node.js’s built-in assert module, and the “expect” style uses a chainable API to create more legible and expressive tests. Chai can be used with any testing framework, including Mocha, to define test suites with a specific feature. Each test in a test suite will state how your code should act.
I learned that it has additional chai-related dependencies after researching the topic. These include additions to npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases. However, the conjunction of some codes didn’t pass due to some missing information and led to some failures. 

To improve myself, I plan to seek information regarding this kind of assignment from members of my group and members of other groups by asking questions. It will serve as a learning experience. Even though the end of the year is getting close, I have seen that my abilities to manage time have increased, and the learning steps for work are becoming the assigned time. We ran into various technical issues during the development process, which resulted in delays; the team and I had a fantastic mid-round in finishing all of the items listed on the sprint backlog. These delays are different learning experiences that require better comprehension and learning new specialties to avoid those misconceptions and repeated attempts resulting from communication breakdowns. The problems may avoid by increasing knowledge and diving into the serious issue with the other group collaborating. 

In conclusion, in the second sprint, our team had good objectives and executed them, though we succeeded wildly better after the First-Sprint. We overcame some obstacles and learned about new topics while working through the complex pipeline and completing one of the assignments.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint-2

Hello, welcome to the Second-Sprint Retrospective Blog. I contributed to the group project by working on the tasks assigned on GitLab. I chose to complete one of the jobs, but it was more difficult than I had expected. I am currently participating in an activity that calls for additional alterations, and adding more details is more complicated than I had anticipated. It is up to the team and me to decide whether to put the modifications for the necessary measures. 

After the team and I adjusted to the issue board required for the work and practice. Completing this ISSUE Weight assignment with a total weight of 3 is reasonable and practicable. 

The Issue:
backend — write a test suite for API (changes); This activity writes test in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working). 

My challenge concerning these works is researching the topic of “Chai.” It explains that Chai is an assertion library written in JavaScript with different test frameworks. It allows maintenance of your code’s functionality and checks that it follows those assertions. It has the “assertions” style comparable to Node.js’s built-in assert module, and the “expect” style uses a chainable API to create more legible and expressive tests. Chai can be used with any testing framework, including Mocha, to define test suites with a specific feature. Each test in a test suite will state how your code should act.
I learned that it has additional chai-related dependencies after researching the topic. These include additions to npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases. However, the conjunction of some codes didn’t pass due to some missing information and led to some failures. 

To improve myself, I plan to seek information regarding this kind of assignment from members of my group and members of other groups by asking questions. It will serve as a learning experience. Even though the end of the year is getting close, I have seen that my abilities to manage time have increased, and the learning steps for work are becoming the assigned time. We ran into various technical issues during the development process, which resulted in delays; the team and I had a fantastic mid-round in finishing all of the items listed on the sprint backlog. These delays are different learning experiences that require better comprehension and learning new specialties to avoid those misconceptions and repeated attempts resulting from communication breakdowns. The problems may avoid by increasing knowledge and diving into the serious issue with the other group collaborating. 

In conclusion, in the second sprint, our team had good objectives and executed them, though we succeeded wildly better after the First-Sprint. We overcame some obstacles and learned about new topics while working through the complex pipeline and completing one of the assignments.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint-2

Hello, welcome to the Second-Sprint Retrospective Blog. I contributed to the group project by working on the tasks assigned on GitLab. I chose to complete one of the jobs, but it was more difficult than I had expected. I am currently participating in an activity that calls for additional alterations, and adding more details is more complicated than I had anticipated. It is up to the team and me to decide whether to put the modifications for the necessary measures. 

After the team and I adjusted to the issue board required for the work and practice. Completing this ISSUE Weight assignment with a total weight of 3 is reasonable and practicable. 

The Issue:
backend — write a test suite for API (changes); This activity writes test in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working). 

My challenge concerning these works is researching the topic of “Chai.” It explains that Chai is an assertion library written in JavaScript with different test frameworks. It allows maintenance of your code’s functionality and checks that it follows those assertions. It has the “assertions” style comparable to Node.js’s built-in assert module, and the “expect” style uses a chainable API to create more legible and expressive tests. Chai can be used with any testing framework, including Mocha, to define test suites with a specific feature. Each test in a test suite will state how your code should act.
I learned that it has additional chai-related dependencies after researching the topic. These include additions to npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases. However, the conjunction of some codes didn’t pass due to some missing information and led to some failures. 

To improve myself, I plan to seek information regarding this kind of assignment from members of my group and members of other groups by asking questions. It will serve as a learning experience. Even though the end of the year is getting close, I have seen that my abilities to manage time have increased, and the learning steps for work are becoming the assigned time. We ran into various technical issues during the development process, which resulted in delays; the team and I had a fantastic mid-round in finishing all of the items listed on the sprint backlog. These delays are different learning experiences that require better comprehension and learning new specialties to avoid those misconceptions and repeated attempts resulting from communication breakdowns. The problems may avoid by increasing knowledge and diving into the serious issue with the other group collaborating. 

In conclusion, in the second sprint, our team had good objectives and executed them, though we succeeded wildly better after the First-Sprint. We overcame some obstacles and learned about new topics while working through the complex pipeline and completing one of the assignments.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint 2 – Retrospective

The goal for sprint 2 was to maximize our production. The team and I wanted to get more issues done, at least more issues done than the last sprint. Compared to the previous sprint, we got way more issues and weight done this time. What worked well for us this time was to look over any current and new issues and order them so that the easier/urgent epics were done first, and then we set aside the epics that would take a little bit longer. 

The first issue I started to work on was refactoring the API file directory structure and infrastructure. So the first issue I tackled was collapsing all “YAML contents in /specification to a single/specification/open API.yaml file.” After that, I worked on disabling the build stage in the .gitlab-ci.yaml, which was pretty easy for me because I did a similar issue while working on the guestinfointegration, and I also worked on modifying the test.sh to validate the open API.yaml.

The second epic I worked on was to “Convert all Docker images to build multiarchitecture images” To complete this, I had to:

 I worked on the front end while my other team member did this to the backend. We could quickly get this done using the information in multi-platform.md.

After getting these two epics done, the remaining epics we had were ones that we could only complete partially in sprint 1. The next epic we wanted to achieve was the Evaluate and Improve API epic. The work I did for this epic included the following:

Finally, we could get back to backend testing after evaluating the API. A big problem we faced was how to test HTTP methods in the first place, so while doing some research, I found a plugin called “Chai-HTTP,” which allowed us to test HTTP requests using the npm test script that Liam provided in the first sprint. While we still needed to figure out how to get the test runner to work with Docker, having the ability to work on the test without having the test runner was an excellent way to get everyone involved in this epic. I was able to work on designing a test to create guests and list guests. And the test runner that will allow us to run these issues is currently being worked on with help from Noelan from the Inventory system since they are also trying to get it up and running. While developing the test runner allowed me to get more familiar with Docker.

As an individual, I am delighted with how I did this sprint and hope to ride this wave onto sprint 3. I planned to get two or more weights done weekly and ensured a specific timeframe to finish most epics in the team. Unfortunately, we didn’t get backend testing done, but I’m more confident that in sprint three we will complete it now that the test runner is almost done. 

As a team, we need to figure out a system so that everyone can lend a hand. Especially towards the end, we only had a few issues, or sometimes we would have to stop production because of one issue. In this case, it was the test runner for the backend. I’m hoping this will be avoided in sprint 3. 

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #2

Hello blog!

Sprint 2 has come to an end and it is now round 2 of sprint retrospectives. This sprint was a little different from the first sprint, where our issues were similar amongst the five projects and we all took one project. Instead of one person having to take on all issues for InventoryAPI, they were able to take on frontend work, or whatever was available. This was a change based on what we discussed during the first sprint retrospective–that we should rotate around what we’re working on rather than being stuck in one project. 

The first two issues I worked on were for AddInventoryFrontend:

The following issue is what resulted in the greatest struggle:

I think what worked well was that in the previous sprint there was the suggestion of changing projects for teammates since they did not want to stick to one of the five projects the whole time, and teammates did swap where they were working. We were also able to help each other out well for a few issues since we all had similar things to change.

What didn’t work well was that we did not gauge well enough how to weigh the tests. We did believe that it would give us issues, but not to the extent that it did. The backend tests should have been split into manual testing and automated testing in Chai since just the manual testing was giving issues that took a long time to address. It was also an issue that almost all of us were making changes to InventoryBackend at once and getting errors from different sections that were fixed by one person but another person was not informed. 

To improve as a team, we could definitely communicate more on errors we have received and what we’ve done to fix them–as soon as we reach them. There are times when some teammates further ahead have gotten errors and fixed them somehow, but forgot what they have changed or updated. Doing so would be of great help for reference and also just good practice. We could also improve as a team by finding more time to work together, like the testing issues for example, since we were all in a similar position, and everyone collaborating on one test first would definitely push us forward. We all have busy and differing schedules so it has been difficult lately, but it can be an improvement.

On the topic of improving as an individual, I still have a fear of breaking things, so I should work on being less afraid of making changes. This sprint I’ve experimented a lot with trying to fix the errors I received trying to get my manual getApiVersion test to work. There were countless changes I made that ended up not making a difference, or would trigger the same error under different conditions. So while I did make efforts to be more “daring”, I could still use some more work on that. I think what scares me more is entering commands I’m not familiar with at all in the terminal, but that can just be an instance of reading more into them.

This sprint felt like a call to be more communicative with my team and also a call to communicate outside of the team with those who have worked on similar issues.

From the blog CS@Worcester – CS With Sarah by Sarah T 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.

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.

Sprint Retrospective 2

What worked well:

Creating branches and merge requests was smoother compared to previous sprint. We were communicating more through comment section of issues leading to better documentation on Gitlab. We were able to come up with a system for merge requests where two people who did not create the merge request would review the code or changes and then third person would write the comments indicating the author and merge the branch into main. We were able to evenly split work and issues between team members so one person was not burdened with one type of work. Even with delays and having to learn new language and concepts we were able to complete the sprint.

We also created issues for contacting AWS and IAM team members (links below). We contacted both team members via discord and tagged them to comment section of the issues that contained questions we had for them.

Personally:

Most important one is that I did not limit myself to issues only assigned to me, I was able to go over work done by my teammates and keep myself updated with new code as well as the flow of the project. API was completed so we had moved on to Backend. I created data file for cooking methods. This was difficult in its own way because we were not using MongoDB for this project. After researching backend already provided, I was able to figure out that we needed to use axios and USDA URL to call data which would return list of cooking methods or cooking methods based on its unique ID. I then wrote a main function to check if I was getting list of all cooking methods and it was successful.

Even with some setbacks, I was able to grasp the basic concepts of the new JavaScript testing framework – ‘mocha’ and JavaScript testing library ‘chai’. Since the data file and paths were completed, I created cooking method test file. With help from Jim this one completed in a week. Npm test verified that all test files were passing.

Things that did not work well:

The spring break and two consecutive cancelled classes pushed us back a little and we had a little problem getting back in sync. We were still having problems communicating and setting meetings outside of class time. Merge requests started to slow down; partly because of introductions of news framework and library – mocha and chai, verifying others work became difficult; partly because merge requests started to fail due illegal naming conventions in commits. Issue names also needed to be more descriptive with more details in sub descriptions. Issues were also not properly linked to their respective epics. We were stuck in a lot of places where we needed help from professor, and we should have been more pro-active in that situation.

We also did not hear back from the IAM and AWS team.

Personally:

I wasted a lot of time researching and reading documentation on my own instead of working with my team or asking help from professor. Also lost a lot of time figuring out how to run npm and npm test. My merge requests kept failing I was not able to figure out the reason until Dahwal pointed out that I was not using conventional commits. I kept up with other people’s code but did not get an opportunity to write an endpoint myself.

Links to some issues:

Start conversation with IAM team

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

Start conversation with AWS team

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

Test file for Cooking Methods

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/general/-/issues/2

Create Data File for Cooking Methods

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

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 2

As a team, we definitely pulled out a much better sprint this time around. Our communication was far better in our class work meetings, as well as outside of class work and coordination. I again feel like I could have done more, as the further into the project we got, the harder it was to come up with consistently good issues and epics. I personally felt a little apprehensive to add specific tasks because I was unsure of how applicable or useful it would be to the team. However, I think the team felt at least a bit similar as we really had to talk it out during the planning sessions to come to a satisfactory agreement. In addition, our ranking of weight on some of the issues and the organization of them was quite messy, which is something that we’re working to improve in the third sprint. Something I struggled with was understanding how to correctly implement the authentication token, and at one point accidentally broke our backend with sloppy implementation. In the future, I need to communicate when I add a potentially code breaking file, and I should absolutely be using branches instead of recklessly pushing it to main.

On that note, after getting more comfortable with the uses of git, I feel it streamlined the process of the work by a good amount for me. I’m still grappling with having some files pass the pipeline tests, and while I deferred to teammate help to fix some of the problems I should lean into really understanding the pipeline and how to properly upload and use the tool.

I also believe I wasted a good amount of time trying to implement the testing directory in the backend. In retrospect there was no way I should have continued to try and make it useful when there were other more important aspects of the project to finish up. In the future I should evaluate the necessity of my focus, as I straight up wasted a good chunk of some classes. In addition, I could have put more effort into getting some of the http calls to work instead of researching the token authentication. Another instance of needing to prioritize.

In my opinion I’m also not asking enough questions, and instead going to stack overflow or reddit for answers, which seem to be hit or miss. There is no reason not to differ to my teammates; this is something I should work on in general though as I don’t usually ask for help with things. I think I should also be pushing more files to the repositories, just to properly track my contributions to the project for accountability. I don’t believe my team feels like I’m not contributing, but just for the paper trail I should make it a habit.

Despite this post’s mostly critical tone, I actually think we did well this time around. I think the team was happy with what we all got done, and how we can maturely talk about disagreements. As a team, the only thing we should work on is properly creating and assigning issues, but I’m satisfied with our work aside from that.

Here is where I added schemas and paths for the token validation.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/adf1c73d94c7ca781259162377194bd39fb91ee8

While not my commit, I helped the team to get the calls functioning.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/1c9ccc965bb68d27bbb7255c1e0f39b883c255c6

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Sprint 2

I think that we as a team, as well as me as an individual, improved during this sprint compared to the first sprint. While for the first sprint we had no experience working with scrum sprints or in any sort of team development environment, so the whole thing was completely new to us, whereas at least now with the 2nd sprint we had at least a tiny bit of experience. This means that we were able to improve upon some things from our first sprint, because we could see what we did wrong and could change our plan in order to avoid our previous mistakes and optimize our workflow overall.

The first thing we optimized and improved upon was our sprint planning. From our first sprint, we could better judge what we could get done during a sprint by how much we got done during our first sprint. This way we could efficiently work on items, getting as much done as possible during the sprint and not assigning too much during the sprint to the point that we end up not getting most of it done. We could also better assign weight to each of the items because we could better judge how long it would take for us to get each item done, and better judge the importance of each item to the overall project and current objective.

The second thing we optimized and improved upon was our overall communication. We still did most of our communication in class, but we now made sure to communicate through the issues on GitLab. When an issue required additional clarification or explanation, we could leave a comment on an issue and ask the creator of the issue for more details, and the creator could easily respond right on the issue. This not only improved upon the frequency of our communication, but it also helped us to differentiate and easily see what string of communication was pertinent to what issue, helping other team members to see what was discussed respective to what issues. This way, if a team member was working on an issue similar to or previously worked on by another team member, they could easily see what kind of issues that team member faced while working on it, and that could help them work through it without even requiring more help from the team. This makes the workflow as a whole much more efficient because any communication is saved, categorized, and easily searchable.

For the team as a whole, we could still improve upon our communication. Although it is efficient communicating through GitLab issues, and it does have some benefits, it is also good to have some non-official communication that doesn’t directly relate to a particular issue. Leaving this communication on GitLab would be messy, so it would be better if we did this additional communication through discord. For me as an individual, I think I could’ve helped more with the sprint planning, and better assisted my team members. For the spring planning, I could’ve better helped with coming up with weights for issues and assigning them. Finally, I could’ve better helped my teammates by being more active responding to open issues with comments and helping them finish open issues if I’m done with all of my issues.

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