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.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/54

We collectively hopped on a discord call and discussed how we wanted the front end to look and how we wanted it to act.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/38

Created the guest-list component that would be displayed on our ApproveGuestWebUI.

Our sprint team did an exceptional job at coming together towards the end of this semester to put together what we have done. What did not work well originally was the loss of face to face communication. I believe our team did a great job this time around of constant communication and problem solving through discord. I believe what helped us thoroughly with this was the split between the data base and the WebUI. This allowed for Khoa and Tyler to be able to work through any of the problems that arose with the data base but had no effect on what John and I had been working on with the WebUI until the very end in which we needed to communicate between the two. By going about it this way, we were able to make huge progress by bouncing ideas of the other while working collaboratively on our respective pieces. I am happy that I was able to turn myself around from the previous sprint and be able to have an impact on what was created. This also led me to have a greater appreciation and enjoyment on Angular which used to be my kryptonite.

The thing that gave us the most problems and what seems to be the most problems for other teams was running everything inside Docker. Due to people having two different “types” of Docker, one Docker Desktop and the other Docker Toolbar, there were often conflicts. Another difficulty was the communication between the other teams, whereas previously we could simply go over and look at what the other teams were using and developing to allow for us to fit into everyone’s schema better. We had to communicate through discord and on gitlab, which to our credit, I believe was done well.  Nonetheless without face to face communication, there were definitely a few hiccups that were caused along the way.

If we were to go back and do this whole project over again, I believe the biggest change for our team would be where we direct our focus. It was difficult in the beginning to know exactly what is going to be vital, what can hold off and what is needed to be completed in order to move forwards. Towards our last sprint, we were able to get a better grasp for what was necessary, and I believe it really streamlined our progress.

Lastly, if I were to do this all over again, I would try to invest my time better than what I did. Often times I spent too long on something that would not be necessary until much later. I still often hold myself accountable for not contributing as much as I would have wanted but I am able to walk away from this sprint happy with what my team and what I was able to accomplish. The way our team came together in the end for the last push was remarkable.  

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

It’s time for this project’s last sprint retrospective. At the end of the last sprint, I had started implementing our needed endpoints for our API and had rough versions working. So, my first focus for this sprint was getting the API working [link]. Our definition of done requires testing for an issue to be considered done. Thus, I made learning how to automate tests for the API a priority [link]. I ended up finding automated testing through Postman and it’s CLI. Using the Postman IDE, I started writing tests for our endpoints [link] and this allowed me to become better acquainted with how endpoints should behave. Postman’s built in test system made creating the tests relatively simple, as it supplies common test code snippets to use. The tests I wrote check for correct response status, response time to be under 200 milliseconds, request has content type header, and returned data. At this point, the work on the backend was nearly done and was awaiting review.

While the API server was under review, I started working on learning Docker. [link] Since I had worked mostly on the backend, I started with getting the server containerized. Once I had the dockerfile written for the server, I then had to figure out how to use docker-compose to link the database and server in containers. [link] Then I started to split my attention between fixing up the server, writing docker configuration for the backend, and reviewing work.

Most of the backend work was writing up documentation. Our team had a dockerfile written for our frontend, so I started writing a compose file for the entire module. This worked well except I could not figure out how to obtain the backend container IP for the frontend. I have since found it has something to do with the nginx proxy we used in our frontend dockerfile.

Once the planned work for the backend was done, I had some time to address the additional requested endpoints from another team. [link] After completing the endpoints, I reviewed work and assisted where I could. The final issue I worked on was implementing the endpoints in the frontend. [link] This was a last-minute scramble that started a day before review. Thankfully, the entire team came together, and we were able to get the reactive forms implemented and connect their data with the endpoint call before the review.

When this sprint was first being started, our team had a heavy workload if we were to finish everything we had planned. Considering this and the additional unplanned work, our team performed quite well. We communicated better and more often. Our individual work had started to heavily overlap each other’s. I believe this led to increased team cohesion. I, however, had a minor problem with our backend endpoints issue. Since our definition of done required testing, this issue required two other issues to be completed before or with it that had not been started. This only affected my estimation of work-to-time ratio, and I do not believe it added extra work. Overall, I am quite satisfied with my team’s accomplishments and all we were able to complete.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

I think Sprint 3 was the most effective sprint of the semester. I think the success of this sprint was largely due to the team improving our GitLab use and our communication with each other. Unlike the last sprint, the new issues we put on our board for this sprint were specific and clearly defined. Most of the new issues were created with a new template that included sections about how the issue would be worked on and what would be produced as a result. This made it much easier to understand what needed to be done, helping us make more progress. I also think we were more open to communicating with each other, both during our meetings and while working separately. We spent more time in our meetings answering each other’s questions and sharing our progress, which personally helped give me a better understanding of things that confused me as well as the overall state of the project. We were also more active on GitLab outside of our meetings. Every team member participated frequently in discussions on issues and merge requests, which helped us complete issues and merge changes efficiently.

Although this sprint was very effective overall, we still faced a few problems. I think the main troubles we encountered were coordination and time management. Although we were all more active on GitLab, we didn’t know exactly when our teammates would be active or what they would be working on. In my personal experience, this made it difficult to make progress sometimes. Whenever I needed input from a teammate, I would simply wait to ask them in the next meeting because I didn’t know if they would be available to discuss on GitLab. I think coordination issues such as this led to problems with time management. Since our progress was slower than it could have been, we ended up having many issues left unfinished in the last couple of days of the sprint. We did arrange a last-minute meeting to work on these issues, which I thought was effective, but if we had managed our time better this would not have been necessary.

To improve as a team, I think we could’ve focused on our time management. This would’ve been difficult, since we all had different schedules and other classes to work on, but there are a few small changes I think we could have made to make coordination easier. First, we might have tried setting due dates on issues. I think this could have helped us manage time better to avoid having issues pile up at the end. It may have also increased collaboration outside of meetings by encouraging multiple team members to work on each issue at once. Also, I think we could have tried having more meetings outside of class. These would’ve been difficult to arrange because of our different schedules and may not have been necessary, but the one we had this sprint was extremely helpful. I think trying to have more meetings where we work together on issues would have helped the team get more done.

To improve as an individual, I think I should continue to work on my communication and participation. As I mentioned earlier, I frequently avoided commenting on GitLab, mainly because I didn’t want to disturb anyone when they weren’t available. This caused me to miss out on important discussions, such as those that took place during planning and on certain merge requests. I started making an effort to participate more during the end of the sprint, but I still found it difficult to do so as my other classes demanded my time and drained my motivation. If I am able to participate more in future projects, I would like to focus on contributing to discussions more and keeping myself informed. I need to stop stressing over my comments so much and just focus on saying what I need to.

Links to my GitLab Contributions:

These are issues I directly worked on, where I left comments about my progress and had discussions with teammates:

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/Plan/-/issues/32
• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/Plan/-/issues/3
• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/Plan/-/issues/33
• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/Plan/-/issues/41

I also helped with resolving the Angular Testing issue, which was left over from Sprint 2:

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/Plan/-/issues/29

These are merge requests I created to merge branches I worked on, where I also worked with teammates to resolve problems before merging:

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/UpdateGuestWebUI/-/merge_requests/12
• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/UpdateGuestWebUI/-/merge_requests/14

I also took part in discussions on these merge requests:

• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/UpdateGuestWebUI/-/merge_requests/13
• https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/updateguest/UpdateGuestWebUI/-/merge_requests/9

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/59 made a stub for registration component

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/57 Discuss with Register Guest about endpoint to get all guests

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/52 Implement register-guest-service

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/60 Create Docker container Running REST API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/35 Create Docker container Running ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/58 Style guest-list component

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/38 Implement guest-list-component in ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/55 Implement data-service in ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/61 Create Header for ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/54 Determine design for frontend component that will display guests

This was the first that was entirely online and remote and because our team now had the experience of how to work on this project online thanks to the last sprint, it went a lot smoother and we got a lot of difficult work done. Something I felt worked very well was on Mondays and Wednesdays we would write in discord what we have done since the last stand up, what we plan to do and any issues that we were facing. By using this channel consistently, our team had great communication on where we were in the sprint and where we were heading with the time remaining. Schedules and situations affected our ability to meet in zoom at the normal class time, but we all compromised and tried to make time for one another to answer questions and work together on the sprint, which to me was very thoughtful and helpful for this sprint. This sprint was our strongest sprint out of the three, in my opinion, because we were able to accomplish a lot and almost finalized what we set out to do from the very beginning which is very impressive given the circumstances. As a team, I think we could have met at least one more time outside of the normal sprint days to really get more work done and be more responsive to issues and how we could work to help one another. Our team should have made a schedule of what days and times we would meet to work on the issues rather than just spur of the moment “lets all get on and work”, not to say that didn’t work, but having a schedule would have made it easier to get work done and plan out the week. I think I should have asked what more I could have done to help with this sprint because I found myself only doing small tasks that related to the backed because that’s what I felt comfortable with and knew I could do. I should have asked to help with different aspects of the front end and tried to learn more about what they were doing and how I could help. Moving forward I will be more proactive with other aspects of a sprint and ask about how things work even if I am not directly working on it, so that if I do need to work on it, then I can just get right into the work that needs to be done. I also feel that I got complacent and lazy due to being at home and surrounded by distractions and no motivation to get work for the sprint done. If we had another sprint and more time to work on this project I would suggest that we try to stay in touch with one another more frequently, make a schedule of when to meet, and try to teach one another about what we have done on the project in more depth. Overall I am extremely proud of my team and what we have accomplished in this final sprint and I wish we had more time to work on this great project.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.