For the final stretch of our allotted development time working with the InventorySystem component for the Thea’s Pantry project, we focused largely on getting all the frameworks (frontend, backend, database) into a functional state for the next team taking over on the project. I focused much of my time on getting our frontend components pushed to the container registry for the project on Gitlab: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/50, https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/49.

Originally I had wanted to implement automatic uploading to the container registry using a Gitlab-CI file, but encountered numerous issues related to the file-structure of our frontend projects, Gitlab’s continuous integration system not being able to find certain files, and problems during the build stage throughout the deployment process. As a result of this I eventually decided on using Docker-Compose to push the components to the container registry. While this won’t be able to execute automatically in the same way as a CI file, It was more important to have working containers pushed to the registry for the next team to be able to work with.

Throughout sprint #3, we were able to finish off some of the outstanding issues which were leftover from previous sprints, we finalized parts of the backend framework and implemented partial functionality https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/42, finished setting up all three frontend frameworks for future polish and development https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/26 , and were able to implement a basic database for storing inventory-weight https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/52, as well as some further polish/refinement of the API https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/8.

Additionally, one team member worked on the Identity Access Management system used for the project, Keycloak, and was able to create working frontend and backend environments for using the system to verify users/determine whether someone has appropriate permissions to access certain pages/fields: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/40. Everyone seemed to accomplish a lot this sprint, and I think that we were able to leave the InventorySystem at a good starting point for the next group of people who end up working on it.

If I could have done anything different, I would likely have spent more time on trying to get the CI-file working as intended, as automatic integration/deployment of the project would be more convenient for developers than having to manually push to the container registry each time changes are made. Also, I think that the Vue components for each of the frontends I worked on could have been polished some more (add features such as slideshows, responsive page design, stylized buttons/appearance) but those would very much have been low-priority issues to be focusing on.

Each of the three sprints had different focuses, with the first sprint being focused on learning the tools we were working with, and the second sprint being centered around building the foundational aspects of the project as a framework for future functionality and development.

This third sprint felt like finishing off all of the frameworks, some polish, and getting everything ready to be worked on further. I think that we accomplished a lot as a team over the course of around three months; this was a great learning experience which felt essentially like working in a professional development context. I look forward to the next opportunity I have to work in a similar environment, and wish my teammates well in their future endeavors.

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

It is hard to believe that I am writing the final blog post for my capstone already, it feels like I was feverishly reading through Keycloak documentation only weeks ago. This final sprint did not exactly go according to plan, but I am not entirely upset with the results. Overall I felt that my team did well on this sprint, but again felt like I should have been further ahead on my own work with the IAM System to allow myself to help more with the Inventory System. But there was some needed bug fixing and research done into different aspects of Keycloak itself that should be helpful further down the line.

As stated, I felt as though the Inventory System team all seemed to make steady progress in developing the different parts of it. There was progress made on the API in addition to the various front ends needed for the Inventory System and it seems that there is a whole skeleton system now in place that can be iterated on later. As for the work on Keycloak, when meeting with Cam and Migena we managed to work out some errors I had made in the setup of some attributes needed to connect Keycloak to Professor Stoney’s basic front end. In addition to this, we discovered that our Keycloak docker image could have a backend with persistence set up relatively easily, with a variety of choices listed here https://hub.docker.com/r/jboss/keycloak/. The other major focus for myself this sprint was on figuring out how to get user information from tokens by making calls from an Open API, as I knew this would be needed for implementing Keycloak into the Inventory System, and potentially others. In doing this I did manage to get authentication tokens, but did not make more progress past this. Once again I felt as though none of this should have taken as long as it did, throughout the sprint I feel like I would get bogged down by one issue and could have handled this a bit better.

I feel as though there are not many changes that could be made for our team to improve, as we simply ran out of time to start compiling all of our work together. As stated I feel like the Inventory System team did get a significant amount of work done, but there just was not enough time to truly start to work together with all of the different systems we had worked on. As for my own performance, I simply feel like I could have done more had I spent more time working. Time management has been a skill I have slowly developed over the course of my time at school, and it has certainly come a long way. That being said, there were still multiple times this sprint where I could have buckled down and simply focused on getting more work done. In summary, I feel as though the work that was done will provide a solid foundation that can be expanded on, but could have been fleshed out a little more had I managed my time more efficiently.

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

The third sprint went fairly well. For the third sprint I did most of the backend from the get request endpoint to the response that returns the CSV report. To do this I first created the endpoint which gets two query strings from the request: start and end date for which I use as a date range for the data to put into the report. I then send the query strings over to the Report module which has all of the functions to create the report. In this module I first turn these query string dates into ISO dates and then query the guest and inventory data collections for any records between those dates. Then I make it search both object arrays returned by each collection for matching IDs and merge each of those objects with matching IDs into one object in an array. Then, turn that object array into a string with CSV format, have it create a file once that is done with the CSV text, and send a response back to the front end with a download of that file. After creating methods to do all of that, I connected the backend with Haoru’s beautiful front end and tested the system fixing any bugs.

What worked well this sprint was my gained knowledge and experience with Node.js and MongoDB. This allowed me to complete more complex operations with them and create what was needed. Because of this, I was able to finish most of the backend conforming with most of the requirements. Also what went well was how smoothly it integrated with Haoru’s front end, only needing a few tweaks, I wasn’t sure what to expect initially.

What didn’t work well was our teamwork. I would say that our teamwork depreciated since our last sprint due to the amount of work that was needed to get done. Since we all had stuff to do we didn’t have much time to merge everything together. For example, Derin worked on dockerizing our application, but needed more discussion to put it all together than either of us had time to give. Another example was with Migena’s keycloak system, where again, there wasn’t enough time to merge with the main application. Our production was higher than last sprint but at the cost of communication.

What we could have done better as a team was time management. Since we sacrificed how much we got done last sprint in order to work on teamwork, we had a lot of work to do this sprint. If we had organized our time a little better we could have had more time to combine our work this sprint and as a result would have a more complete system.

What I could have done better this sprint would have been to take some extra time to work with Migena and Derin. We came very close to our goals for the end of the semester, with one more sprint I believe we would easily have finished the base idea of what the system would be. Although I was very busy with the backend, I’m sure it would have been doable to combine our progress if I we took an extra 2-3 hours over the course of the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend – link to the main application with the modules spoken about in this post.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/38

Implementing the frontend for guest registration was the overarching goal of mine during the sprint; this encompassed all of the smaller individual parts.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/53

This was fulfilling the specifications for the guest registration page, including collecting a new guest’s information and displaying/changing an already registered guest’s information.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/41

This was in order to allow ID input from a card scanner swipe (within a text entry of the frontend page)

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/52

This was collecting a guest ID for lookup; employed the getGuest method, which made a backend request for a guest with the specific ID.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/49

This was connecting frontend to backend methods, which was completed with the use of Axios.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/29

This was creating the HTML structuring for the guest info page.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/30

This was applying CSS styling for the guest info page; not much was completed here except for button styling and putting individual borders around each entry for the age of a member of the household.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/backend/-/issues/6

This was changing the backend getGuest method in order to return an empty object in the case of no guest found instead of a 404 status. Also, not totally included in this but involved is the refactoring of the guest object in the backend openapi.yaml file to match what was best for frontend functionality.

Overall, I feel I was able to get a substantial amount of work done during this sprint. Actually, I felt this was the most I got done in any sprint. I think part of this was feeling totally settled into the sprint cycle but also because I was undertaking something I had never done before in building the frontend for the system, which was a very large part of the system and had a limited number of examples to work off of (at least, examples that were applicable). Not only was I having to learn on the fly, but I also had to then apply this knowledge to HTML and CSS (totally new to me, only having lightly dabbled in HTML) and JS (very limited experience as well). Getting through this was difficult, and I definitely should have asked for more help earlier on.

This was actually my main downfall during the sprint; I was trying to figure things out on my own for so long that later on, when help was needed the most, I felt there was not a good way to delineate the work, especially because it would take a great deal of time to explain the functionality of everything up to that point. More communication was definitely necessary. I felt during this sprint, our team was the most divided amongst their own work, with limited crossover, so communication suffered and sometimes it seemed work might be stagnating.

As a team, I still think we worked well. Although there were rough patches and points where I wasn’t sure how we would get to our respective endpoints, I think we did fairly well. Had we teamed up on more work, I think we could have gotten through cards/tasks faster. I also think there could have been a better division of labor. I felt the frontend was too large a task for me to be completing on my own, but there were other circumstances. I was the one who studied Vue.js, so I don’t know how much knowledge others had. Also, I should have been more vocal in asking for help once I realized the size of the task I was taking on. Better communication on a more consistent basis would have solved this, I believe.

Personally, I was happy with the work I completed. I went from feeling lost on most parts of the frontend to having some solid understanding of each part. This was good for my sake, but not optimal for delivering working products, since dividing responsibility might have limited the amount of hands-on work I had but would have brought results faster. Working mostly alone was not something we did much in past sprints, so I should have spoken up more in order to help coordinate our work.

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

For the third and final sprint of our project for this semester, we had the biggest list of tasks to complete. Not only did we have a tremendous amount of tasks, but almost all of them where big and difficult tasks. In our previous sprints, we had a lot of tasks that were smaller or that related to learning rather than creating. This made this sprint much more difficult for everyone. Some cards that I had to complete by myself were not too bad. One of them was simply to update the frontend example that I produced in sprint 2. We changed some things on it in order to have a smoother experience for the user when they are a returning customer. The questions that could be skipped if a returner logs in now will be autofilled in (with the availability to change their previous answers). Many other tasks I worked on were much bigger and were not solo tasks. Before the end of the sprint, I was able to help with tasks such as implementing the GuestInfoDB. It was extremely important for us to get as much of our tasks done as possible before the end of this semester so that future students could used what we have worked on to improve or even finish it all next year. We tried to write as much as we could in the cards themselves on GitLab in order to help anyone realize what we were trying to accomplish. Even if we failed to finish some cards, starting them and writing what our thoughts where will help future students when they get to the steps that we got to. We were able to utilize work from previous students this semester in the same way. By the end we were able to get a basic frontend working to an extent that ended up not being too bad in my opinion. Even the cards that we did not end up completing should be very helpful for future people working on this project, whether it be Capstone students or WSU employees. Before moving on from this project, we were instructed to add our thoughts and ideas to cards that we had not yet completed for that exact purpose, and from what I have seen from my group, that should be pretty useful in the future. It was nice being able to work on a real life example for this class, and it is something I actually wish I had done more often throughout my undergrad. Everything this semester, especially for this course, definitely helped improve my understanding of how projects would be worked on in the real world, and I am thankful for being able to learn in that way!

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

The main things we did for this sprint were dealing with the database connections along with cleaning up code and setting up docker. More specifically we learned how to connect the database to the rest server. We chose JDBC to do this. After that we coded the connection. Next we converted the endpoint and the whole rest server to use the database using JDBC. This was done by creating a class to access the database containing a method for each one of the endpoints. Then making each endpoint call the corresponding database access class method. 

At the same time other members of the group were installing docker and doing tutorials for it. Along with reading about docker. After that we each tried to write our own docker files. That went fairly well. So we got the angular app is-registered running in docker container. Along with the angular app register running in docker container. In addition to the rest server running in docker container also the get database running in docker container. After that we worked on cleaning up the code for the is registered app. We also worked on cleaning up the code for the register app. We also figure out how to call another endpoint from the rest api. We did this using the web reactive framework. After that we started working on connecting the docker containers. We tried creating our own bridge and using the container IP’s we also tried using docker compose and using the container names and IP’s. none of this worked and the angular app was still getting CORS errors. The connection to the database couldnt connect either. We tried talking to the other teams about it but we were still unable to get it to work.

For this spring I personally focused on the rest server and the docker connections.  First I looked at what another team member had one for connecting the database and worked off of that to finish it and add methods to it to do all of the operations on the database that were needed. Next I converted all the endpoints in the controller to use the method that i created in the database access class. After that I worked on learning how to call the update modules endpoint. I learned about the web reactive framework and it seemed to be good. I was able to call one of our endpoints from another as a proof of concept. However i was having trouble understanding how the update groups endpoints worked so i moved on to the docker connections after that. I spent the rest of the sprint trying to get the docker connections to work. I first created the docker file for the rest server. Then I tried manually creating a bridge and connecting the rest and angular containers and running them. Then I tried using docker compose. Neither worked. That was all I did for the sprint.

I thought overall the sprint went well. I think we did a good job with the planning meeting. I also thought we did a good job with working together on connecting the database to the rest server. I also thought we did a good job using zoom to work on stuff together. I thought we should have communicated closer when we were all working on docker stuff. I feel like we just all worked on it independently and didn’t really talk about what we had tried and what progress we had made. As a team we could improve on communicating when more than one of us is working on the same issue. As an individual I should have done a better job of communicating my progress on the docker communication.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service

The register guest service

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Register-guest-deployable

The docker compose file

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/tree/working-on-conection

The work on connected the docker container in the is-registered app

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service/-/tree/working-on-connecting-containers

The work on connected the docker container in the register guest service

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

Recently we finished our last sprint. This was our 3rd sprint. During this sprint my team and I worked on setting the registerGuest app together. We mainly focused on databases and getting the docker working. Each one of us spent time on learning about docker. Most time was spent on the database as we were having some trouble running it and Docker because no one was familiar with Docker. However, we managed to get the database working for the app. Everyone was familiar with the components of the project, besides docker. But we are happy that we got the docker containers running. Overall, the team did a good job in reviewing each other’s work which helped progress the sprint. Zoom meetings, constant discussion on errors via texts were helpful. Main thing was keeping track of gitlab issues that were created and working on them kept everyone on the same page.I believe we did a great job as a team contributing toward the project.

My contribution:

This sprint was quite challenging for me. I started off by researching more on Docker. After reading about Docker I tried to install docker desktop. Unfortunately, the Docker desktop was not supported by windows 10 and MacBook version 10. I started to research more on installing docker. One of the helpful resources I found was from Docker Hub. I followed the tutorial from Docker Hub and installed Docker toolbox. I followed up with Shams, because she and I both installed Docker toolbox form there. I experimented with Docker toolbox and tried to run by creating a new angular app. I was struggling for a while but looked at Shams and did a zoom meeting on how she was able to get it running. We both discussed what error I was getting.

When docker toolbox was working, I worked on helping my team connect the docker containers together. Again, it was challenging because the angular app was able to read each other individually but the servers were unable to connect to each other. We are able to open the shell inside docker and run the app but due to the servers not being connected to each other we were unable to run the project with docker. However, discussing and having 6 meetings on zoom about the problems we were facing we got each part of the app running inside the docker container locally.

After everything was running properly, I reviewed, approved some issues on gitlab. Also, after shams made some adjustments to is-register-webui, I went back to gitlab and clean coded is-register-webui, fixing the padding, the window size, borders and WSU logo position and pushed the final results.

What didn’t went well:

Things that did not go well for me was running docker properly and using Angular materials.

I was curious and excited to work on docker and angular materials. I spent more time researching docker and Angular material. I was not able to use Angular material on this project because it was time consuming to get it working on time and I knew it would take more time since the deadline for the project was near. However, with CSS and HTML code I am impressed how the design came out. 

Docker was not friendly. I was not familiar with it and neither one of my teammates were but the team managed to run the app locally. 

Improvement?

What we could have done was focusing on main things and being organised a little more. I felt everything seemed scattered. I was lost sometimes. Interacting more with each other on certain problems and discussing with each other what they are planning on doing and how they will be doing it would have been helpful.

Individual improvement?

Some areas where I feel like I could improve would be time management and keep track of the project progress. Due to lack of knowledge on docker and angular material (what I wanted to work on since I was done with is-register-web-ui) I spent more time in research and sending links and notes to my teammates about those two, I spent less time in contributing on gitlab issues. It would have been better if I were introduced and have resources about docker and angular materials.

The Project:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest

Is-registered-web-ui:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui

Issues:

• Learn about Docker:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/issues/58

• Experiment with Docker:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/issues/59

• Running the Angular App in Docker container:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/issues/48

• Dockerfile:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/Dockerfile

Cleaning code Links:

• is-registered-web-ui- app.component.ts:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.component.spec.ts

• is-registered-web-ui-app.component.html:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.component.html

• is-registered-web-ui-app.component.css:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.component.css

• is-registered-web-ui-app.module.ts:

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui/-/blob/master/src/app/app.module.ts

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

What we did as group  for sprint For this sprint we worked on two main things: the database and the docker, we spent 4-5 zoom meetings expermanting with docker until finally we managed to run the angular apps in the docker containers individually. The database part took the most time to get it work but … Continue reading SPRINT RETROSPECTIVE #3 →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

The semester has finally come to an end, and that means that it is time for my third and final retrospective blog. This sprint was probably our best sprint in terms of communication, but it is weird because while we got a lot of work done, we ultimately had to resort to running the project locally due to issues with Docker. Below are the links to the progress that I made this sprint.

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/registerguest

This is the link where I created one overall project with a Docker compose file because I was testing Docker compose and getting the containers to all run at the same time under one default network.

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service/-/blob/master/src/main/java/register/guest/service/DataBaseAccess.java

Here is where we were (finally) able to connect the database to the REST server. We used the JDBC connection driver to connect to the database from a Java application to add to the database from the application.

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-data-base/-/blob/master/Dockerfile

This is the Dockerfile that allows the database to run in a Docker container. I included the registerguest.sql in this to be able to create the database within the Docker container.

During this final sprint, I felt as though I was able to do a lot more than the previous sprints because there was a lot of experimenting with the database that had to be done this time around. For example, we had to try ways to connect the database to the REST server. I also had to figure out how to use Docker and get the database running in a docker container during this sprint. Our GitLab use was more or less optimized this sprint as we were using our cards, and commenting on our issues. We used the “block-by” feature much more this sprint. Our communication was also much better this sprint as we were meeting on Zoom much more, and texting among ourselves more about issues we were having.

I would say that the only thing that didn’t work well for us was our Docker use. We were all getting so many different, unforeseen errors that seemed like they had no solution after hours of research. I believe that the issue could have been that I was using Docker Desktop while the others were using Docker Toolbox, however, when I switched to Docker Toolbox, I couldn’t even start it up due to virtualization issues that I couldn’t find the solution too. Besides that, I’d say my only other issue was procrastination as I was still getting things done at the last possible moment rather than giving myself more time to work through all of the issues that we were facing which only led to more pressure on myself. Although, last sprint, I said that I wanted to get the database connected to the rest server, start my work on Docker, and have more Zoom meetings. I was able to do all of those things, so I am not too upset with how this Sprint turned out.

While we don’t have any sprints left for this semester, I still think we could all benefit from improvements because everybody can always improve. For example, whenever I work on a group project again at any point in my career, I will be sure to communicate more with both my teammates and other groups if it is applicable. I will also be working on my procrastination issues as I begin my career.

Dr. Wurst said that although we didn’t get an entire project working, that it was still very impressive that we were able to do what we did from scratch and have a functioning project to present. He also said that we should be proud of our work, and I completely agree. I don’t think what we did was easy by any means, and I am honored to have worked on a project like this for my last school assignment ever.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.