This last sprint did not go as smooth as the previous, we encountered a bunch of roadblocks with the backend that sort of disturbed the plans and dynamic established previously. We were able to get to a decent and somewhat better end product then what we started off with but we didn’t quite reach some of our main goals.

What didn’t work well

As a team:

The biggest issue was the backend not running. We started the spring with all the endpoints written down but we had an issue with connecting it to the database and getting it to work. About half the issues of the sprint were solely related to the backend and now that we could run or test anything, a lot of us were left with not much to do, or not knowing what to do. Consequently it led to a lot of not really productive time.

Individually:

Going into the sprint, my task was supposed to be testing and fixing the two endpoints that I wrote and that didn’t end up happening because of the backend not running. Since there was already two other members actively working on the backend, I found myself not working on anything for like half the sprint. At point, I would join in with the backend work but it turned out to be us three doing the same test so I decided to look inside the folder to see if there was something else I could do.

I also think that this sprint being toward the end of the semester, I ended up focusing my energy on another project since I couldn’t find anything to do.

What worked well

As a team:

We were able to fully refactor the front-ends for the most part, we updated all repositories with all the necessary add-ons (commitlint, RabbitMQ tutorials,…). The backend was created and is running. It’s not working yet and consequently the endpoints are not tested yet. In general, we accomplished over 80% of what the goal was for the semester so it was indeed a success.

Individually:

The one good outcome was that I learned a little bit about automation testing. There was a Testing folder inside the microservices example with classes like axios.js, chai.js api.js and so on. It was a bit confusing but I discovered a bunch of links (blogs and videos) that helped a bit. I pushed a document with all the links in the documentation folder for the other teams to refer to it.

Changes to be Made

Most changes that need to be made are for the next team. They can work on the following:

• get the backend to run, it is very close to being ready as it is working already;
• Take a brief moment to modify the user interfaces for check inventory and add inventory to prevent user error;
• Test and fix all endpoints;
• Develop the front-end calls based off what was set up in the backend and connect it to the web pages for testing the frontend containers with the backend

Links:

Add document with Information on testing folder(backend) (#39) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryBackend · GitLab

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

During Sprint three we ran into issues that bottle necked our project. But in the end we were able to overcome these obstacles and make some good progress.

What did not go as well was the planning of our issues, and not knowing how long each issue would take. One of our issues was connecting our API to our backend, and building our server. This issue ended up taking three people from our group more than two weeks. And we were unable to meanigfully test any HTTP calls until our backend was running properly. Looking back, we should have starting working on this during sprint 2.

What did go really well this sprint was working together to get the app running. We spent one class, all working together. Working through docker errors and making progresss that way. Chirstian made progress on his own as well. He made a docker file and reused the shell scripts from last semester to get the server running. The issue we ran into was that even with the server running, we could not execute any http call, without getting a connection error. This was the status of the issue for about two weeks.

I tried to work through the connections errors using stack overflow and other online resources, but to no avail. I then asked Jared, and sent him a screen shot and he said they ran into a similar issue in his group. Then, Duwal, Jared, and I jumped on a discord call and together we got the server running, so that we could call our http methods wihout connection errors. This was a huge break through for the team.

Another issue we ran into as a team was meeting to make our video presentation. We had a hard time picking a time in which everyone was free. Because classes had ended, and group members had finals and other engagements. The solution we came to was that everyone filmed their part and sent the video to Christian, who is going to edit it together and submit.

One thing I can do to improve as an individual is learning to ask for help, outside of the normal avenues. Once I asked Jared for help, he knew where to get started on our problem. So I learned that sometimes I need to ask an outside opinion for help. There is a limit to how much I can figure out by debugging and googling on my own. And sometimes an outside perspective, or somebody that has encountered this problem before can make all of the difference.

Below are the issues I worked on this sprint:

I added access token capability to the API repo. I added a schema for a 403 response. And I added that response to every path in the API repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/12

I researched endpoint testing standards and created a template js file in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/29

I debgugged tbe connection / server problems in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40

I helped Duwal with the test file for returning the API version. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/25

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

During this sprint my previous work in getting the front ends linked to each other for testing would finally be quickly integrated for the two front ends addInventory and checkInventory.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/6

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/8

While figuring out how to properly implement it into checkoutGuest front end, it was found to be not properly set up like the other projects and would require setting it up to be the same as the other front ends in terms of their vue formatting.

I was spending the majority of my time learning more about vue and how to set it up within an already created project and managing the new changes when I decided to take a peek at the previous branches as the way this project was currently setup didn’t match the others and I considered the possibility of something in development perhaps being left behind.

I found a branch called updatedFunctionality, and in it was a project formatting exactly like the other front ends and I knew then and there that we needed to integrate it within our current branch. My professor recommended that before we merge it into the main one to do a merge into a test branch to simulate what it would be like between the two and see what conflicting merges we would have to deal with. He also preferred that we didn’t just erase the main branch’s development as to not leave out the work created by previous students.

I successfully merged the two branches and got approval to merge the main and this branch and deal with the conflicting merges of which there was not too much. With some help from my fellow group member Fadi Akram the branch would be merged and my I would implement the changes needed to connect this front ends to the others like I did at the start of the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/11

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/10

Afterwards I would spend my time testing and working on the user interaction portion of checkoutGuest as it involves a point in which the user of this station will be scanning or manually entering in student ID’s to record items being taken out of Thea’s Pantry. Working on previously established work from Professor Wurst, I modified the user interface to accept ID from both keypresses, scanning, and manually entry by keypress in the same format as it being scanned. I also made sure to prevent future issues by preventing negative values being submitted and locking the text box for user ID when a proper value is entered to prevent further changes if there was a mistake made. I also added a clear button should the user desire to make a change as they have entered the ID, should it not match the one they have typed.

There is still some modifications that should be made to the interface like allowing during manual entry to delete the desired values and modifying the value of the idnum variable to match. It would be just checking for the backspace or delete keypress and modifying the value, but it would require testing and I can’t say I am certain if that would work perfectly just from that idea.

Overall this was a far more productive sprint for myself than the previous ones. The efforts made in the previous ones helped me to succeed in this sprint thanks to understanding vue and html better.

During this sprint my team was primarily focused on fixing the backend and had I finished my work sooner I would have been working with them as well trying to debug it. My team did come together well to focus on that issue but our ability to work on testing the backend was limited by it not being able to startup and work.

I did struggle with some of the JavaScript coding while refactoring it a bit and that is definitely one avenue I need to take to improve on my own skills. It’s fairly similar to other languages I have used but some of the syntax did in a sense fight back against me, like how JavaScript handles operands with their weird truthy and falsey system. While creating conditional checks some would still pass through as it was still considered “truthy”.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

This past week, my development team in my Software Development capstone completed our third and final Scrum sprint for the Spring 2022 semester. We completed our final Sprint Review on April 28^th and have officially stopped working on the project. This was my first experience working in an Agile environment, along with my first time working on a Humanitarian Free & Open-Source Software Project.  

There were several areas in which our team excelled. The team did an excellent job of labor division, as through the entire semester, all team members were contributing equally to the advancement of the project. We also worked well together as a group; we were able to concurrently work on code very effectively, combining the knowledge of everyone to solve problems we couldn’t as individuals. Throughout the semester, we improved our workflow, increased efficiency of standup meetings, and improved the organization of our source control and merge processes.

There were some areas to improve for our team. We struggled to create appropriate issues in Gitlab to work on – we often found that we were creating issues that were too vague, too large, or duplicates of another issue. We also could have done a better job of maintaining the Epics board in Gitlab; we focused primarily on the issues and not on the Epics they were attached to.

As an individual, I worked well throughout the semester. I was the Scrum master for my team, a position I had never held and was not confident in. I challenged myself to help the team stay organized and balanced in our Scrum meetings and saw improvement throughout the semester. During the first sprint, we would often get sidetracked during standup meetings talking about problems team members were running into and were using more time than necessary. I was able to help the team keep our focus on the current meeting and save other discussions for after, increasing the efficiency of our utilization of class time.

I believe the semester went well both for the team and for my individual work, but there are areas in which I can improve. First, I found myself feeling disorganized occasionally throughout the semester from making too many changes at once – I would like to get better at treating issues as small, independent tasks that are fixed alone on a branch and then merged, instead of completing several small changes in the same issue and branch. This will make it easier to stay organized with what I am working on and will make the source control system more effective at tracking the work I did on each issue.

I contributed to the project in several ways in the final sprint. The major hurdle we faced was getting the backend and API to connect so HTTP calls can be made to the API. I spent the majority of my time trying to debug the various errors we were running into, such as connection errors and socket hangups https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40 . This issue is a great example of our misuse of issues – while only one issue was listed, it consisted of many hours of work and many changes to files —  Javascript files, the bash scripts responsible for starting the server, and the API itself. While I was ultimately unsuccessful in completing my fix, I was able to gain a more complete understanding of the project and how each file and component fits into the larger picture of the system.

I would consider the sprint and the semester successful overall. Essentially, we have a working and validated API, most backend code, and have linked the two together. The next steps for next semester’s group will be to continue to develop testing, along with incorporating Identity and Access Management and deploy the server on Amazon Web Services. I feel much more comfortable working in an Agile environment and working on smaller pieces of large HFOSS codebases, and I feel far more capable of working as a developer professionally in the coming year.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

As the third and final sprint for the semester, and with that my involvement with the N.I.C.E project, has come to an end, it is time to reflect on the progress that has been made, as well as what has changed with respect to team and personal work compared to the previous two sprints. The difference between this and the previous two sprints is that this sprint was the proper beginning of actual implementation of the features that we had been brainstorming as a team over the previous two sprints. With this being the case, we were no longer at the stage where we struggled to find some footing regarding the project’s infrastructure; we had actually begun laying the foundation that this project will be based on. In simpler terms, this is the sprint where we were no longer working on spike solutions, but actual source code. This meant that we were overall working with a more hands on approach to this project.

Though admittedly not perfect, this sprint proved to be the most productive sprint both in terms of actual productivity, given how we had to work over 42 issues, and well as individual and team growth. During this sprint we as a team had a much clearer direction in what we thought needed to be implemented, as well as how we would approach said implementation. This meant that members of both the Docker and the Source Code groups were more independent, which helped make some very good progress. That is not to say that all team members were working in complete isolation – on the contrary, there was by far more communication taking place across both Gitlab and Discord between team members during this sprint. This was especially prevalent in the Source Code team, which I was part of, as I made time to meet independently with my fellow team members to discuss or collaborate on certain issues. In my case, I was assigned to work on the following issues:

1) Implement file parsing to implement a question into a card component
2) Implement a method to make multiple copies of the single question preview component
3) Implement the component that contains a single question preview
4) Build a page that shows previews of the questions for the interview
5) Fix the visuals for the card components on the question previews

Sadly, we did not manage to implement certain issues exactly as we had envisioned them either due to bugs occurring or due to lack of time, though we still managed to make some satisfactory progress despite it all. Moreover, unlike the second sprint, there has also been improvement with respect to time management during meetings, something that we had reflected on and had problems with in earlier sprints. Though there were still cases were the conversation would veer off topic, we as a team were more conscious and thus put more effort into returning to our topic of discussion. This was also affected by our documentation; given that we begun to put more effort into documenting the development process into the appropriate issues on Gitlab, it has been easier for team members to be on the loop and communicate any misunderstandings outside of meetings. Moreover, I feel like my own working process has improved as a result, especially my weakness in properly gauging an issue’s proper weight. During this sprint, I feel like I have improved in taking the proper care to dissect and break down a goal into smaller goals so that implementing a feature is easier in terms of what steps need to be taken towards implementation, as well as seeing how my issue could be connected to another team member’s issue. Thus, instead of panicking to implement a vague issue, I noticed that I made better progress by implementing smaller and clearer issues.

As I mentioned, this sprint was by far the most productive sprint for the course. Though there may have been some occasional flaws or problems in productivity, these flaws were not as significant when compared to the second sprint. Overall, as a team we have noticed that we had finally gotten on a steady and clear path.

Direct links to issues:
1) Implement file parsing to implement a question into a card component: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/42
2) Implement a method to make multiple copies of the single question preview component: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/41
3) Implement the component that contains a single question preview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/39
4) Build a page that shows previews of the questions for the interview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/28
5) Fix the visuals for the card components on the question previews: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/48

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

This last sprint I feel as though I went backwards. I am not too happy with my results. I spent the majority of my time working on semantic-release for the backend, frontend, and api branches, which I was only able to partially complete. Reflecting on this sprint, I should have absolutely given up and started work on something else. If I had given up someone else might have tried, and one of my team members might have had a different way of approaching the problem and solved it. If I were to look at this optimistically, its good that I messed up in class rather than in a real job. I was also able to write my findings in the issues I was working on so that the next student to take up the issue won’t be starting from scratch.

When working on the backend and api branches I was getting errors that did not make sense to me. I believe that there is something wrong with the repositories since that should be the only difference between the backend and api. I communicated this in my issue descriptions.

If I had to say something good about myself I really do like my issue descriptions. I am not sure if it will be helpful for the next students, but I really hope it is. I even tried to suggest possible solutions I was thinking of. I knew that I had to try hard to write good documentation because when we inherited this project from the previous group, there was little documentation for us to go off.

Something I think my team could have done better is to check in with each other more often. Sometimes I did not know what my teammates were working on, which is something you never want when working in agile production development. We slacked off on our daily standup meetings; if we didn’t I could have communicated my struggle with semantic-release. We could have made more of an effort to perform out standup meetings correctly, and I know that would have definitely helped me, and probably others as well.

Something that I could have done better relates to communication as well; I could have asked for help. I am not sure why, but throughout my struggles with semantic-release I did not ask my group for help at all. I did ask other people, but if I had gone to my group they would have known about my problem, been thinking about solutions, and they would care about fixing it since it directly relates to them. For whatever reason I kept believing that I could solve it myself since I got it working on the frontend, but now I realize this was a mistake.

I am not going to lie to myself; I did worse this sprint compared to sprint two. I think it is important to look at your own work objectively and critically in order to improve. Like I said before, I am grateful for this learning experience while still in college. I know that an employer will expect me to make mistakes, but I am not the kind of person to be satisfied producing sub-par products. I will do my best to learn from this experience and try to not repeat the same mistakes in the future.

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

With the conclusion of our last sprint, I’ll start by reflecting on the team performance. I think we went into this sprint pretty determined to get the backend fully up and running. Those of us who were involved in the backend development started working on trying to get the backend running in order to test each of the endpoints. Though the container was running, we were unable to use http calls to test any of the endpoints. We realized that there was a bigger issue than what we initially thought, resulting in us spending most of the sprint trying to get the backend server running. Another thing I would like to point out was that we had issues that were a bit too ambitious. We structured our sprint around the idea that we were going to have the backend running fairly quickly. And because of this we were essentially unable to do a good amount of issues because they required the backend to be running.

Reflecting back on my performance, I would say that I communicated well with the team at the start of the sprint. I discussed with my team during the sprint planning, helping the team structure what needed to be done for the upcoming sprint. At the beginning of the sprint, I assigned myself issue #31 in the backend, which was to test the removeInventory endpoint. I spent time trying to test with http calls but I was not getting any response. I then learned that we were having issues getting the backend to run, which explains why I was not getting a response. I think when it came to this point, I started becoming unproductive due to the fact that my assigned issue depended on the backend running. 

As a team, we definitely could have improved in the communication aspect. At some points during the sprint it was a bit unclear as to what everyone was working on. Most of our progress came to a halt by the issues with the backend, and I think we should’ve put all hands on deck to look into the issues. I do also think we could’ve come up with more manageable issues. For example, a task such as implementing keycloak into the inventory system is something that we can’t gauge the weight of until we actually start working on it. We could’ve come up with issues to get the backend running as opposed to things to do after the backend is running.

Coming away from this sprint, I will need to remember to communicate with my team, engaging with them to see if they need help with anything. I think I should’ve spent more time looking at the entire structure of the project to get a better understanding of how it should work, that way I can look into issues as to why things aren’t running. I will also need to consider setting realistic goals and understanding what things can be done in certain time frames. I still learned a lot from these past three springs and I look forward to applying this knowledge to my professional career.

issue #31: Troubleshooting the removeInventory.js endpoint which was unsuccessful due to the backend not running as intended.
issue #3: Bundle items-api.0.1.0.yaml to be used in the backend.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.