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.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/47
Create MongoDb Docker Container

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/50
Setup Rest Api Endpoint to Add to MongoDb

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/31
Implement methods in weight-entry component to communicate with REST API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/30
Add checks for remaining weight allowed based on previous transactions

During our third and final sprint our teamwork and role designation really benefited our workflow. We applied ourselves to areas of work that we each had the most knowledge with (Rest Api, Mongo, Web UI, and Docker) and focused our workflow individually in those subjects. While at this juncture in the project most of the work is overlapping in order to connect either through Docker or with specific method calls we were all exposed to each other’s work. This way we each had an opportunity to learn about the different parts of the project and all had a deep understanding of our own work. Having such deep understanding of our own work allowed us to explain it to each other and to overcome obstacles when finalizing the connection between everything either locally or via Docker. So whereas in previous sprints we worked solely on our own part of the project, this sprint really started to blur the lines of our issues. 

For example, many of our Rest Api Endpoints needed to be set up to work properly with the Front End Angular Methods. Issues like Issue 50 Setup Rest Api Endpoint to Add to MongoDb became a three part issue. We need to make sure the Rest Method could add correctly to our MongoDb, but also this needed to be tested with the Front End code before it could be finalized. While working on this issue I found that roles were often switched and juggled between my teammate and I as I worked on Front End Angular code and they worked on some Rest Api Backend code.

There isn’t much that didn’t work well in this Sprint but I feel that keeping our Merges to Master on Git up to date and correct was sometimes a problem. We did not alway communicate code correctly and would send snip-its in discord that we would copy and paste instead of sharing it through git. Sometimes certain important code segments would get merged and then someone with old code from copy and pasted work may merge and we would lose that important segment of code in our most recent commit.

As a team we could improve our Git presence and organization. We should have been using it to solely share code instead of copy and pasting in discord. If we used Git only certain things would not have gotten lost in translation and confused. Overall, if we worked more cleanly on git we would have saved quite a bit of time on the project.

As an individual I could improve my knowledge and understanding of the parts of the project I wasn’t assigned to. Sometimes if an issue would arise with a field of familiarity like the Rest Api I would feel compelled to help my teammates with the problem. However, I could have designated some of that time to look over things like the Docker containers more and familiarize myself with their function better. Docker would not work on my computer so the only exposure I had with it was when working with my team members. I feel I could have learned more about the Rest Api and Angular Docker containers as opposed to just the Mongo Container.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Here is what I worked on during Sprint 3:

• Determined the design of the front end components
  • Comment on issue detailing the design
• Designed and implemented a simple header component
  • Merge of implemented header
• Implemented the data-service in the Web UI
  • Merge of refactored data-service
• Collaborated on implementation of the guest-list component
  • Final merge of guest-list component
• Implemented the Web UI in a Docker container
  • Branch with Docker implementation
• Created Docker container for Approve Guest SQL server

Sprint reflection:

In my personal opinion, this sprint was truly when my team and I started to get into the flow of collaboration. For this sprint, rather than each working on a separate service, such as the API or front-end we all collaborated on a single front-end. What I noticed with this was we had a lot more discussion and it really felt that we were working together towards the goal of getting all of our issues we started the sprint with done. Unfortunately, this was the last sprint of the semester, but it was good to feel that we were all working collaboratively and using discord and GitLab to communicate any issues and roadblocks that were stopping us from achieving. As I talked about in my last retrospective blog, the transition to fully remote was a pretty tough one since we are a relatively new team and haven’t really had the time to form the communicative skills that a seasoned team would have. It felt at times like the fully remote nature felt made it more difficult than it was previously to reach out for help while working. Maybe it was the quickly approaching deadline that made the difference, but I think we all worked really well together on this last sprint. All members of the team used discord messaging extensively and we had our fair share of discord calls to talk about implementation and problems. As for things that could be improved, as there always will be, I felt like work wasn’t being pushed to GitLab as frequently as it should have been. This made helping with implementation a pretty slow process. There is really nothing that we can do to help collaborate if we don’t have that code up on GitLab. I also feel like we still had the issue of keeping way too many things in the needs review column of our Kanban board. This also slowed down implementation greatly because there were many times where I couldn’t start working on another component until a feature was merged and sometimes it would take days for that to happen. In the end, we implemented a lot more than I originally thought we would have and we did it as a team. We even got to working with Docker on the Dawn of the final day and while it was a scramble I learned a lot about containerization and Docker implementation.

Going Forward:

It did take my team a fair amount of time to gel together and feel comfortable collaborating, but I feel like we pulled through in the end. This project has been a huge learning experience. Not only did I learn a ton about how developing on an Agile team feels, but I also got a feel for being a Scrum master. I know that this experience is one that I will look back to throughout my software engineering career. There were failures and frustration, but it was extremely informative to be part of this project from the idea phase all the way through to the implementation, albeit not a finished implementation. Having the experience of transitioning to working fully remote is an experience that has already helped me in my professional career. If any of my team members read this, thank you guys for sticking it out with me and I know you will all succeed in life.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Hello dear readers. Welcome again to my blog. This blog won’t be for the patterns I have been writing about, but for the progress of me and my team in our Capstone Class. It is exciting to see that things are progressing and we are moving forward with this project.

As I mentioned at the end of the last blog, (AMPATH-WSU Sprint 2 Retrospective) we received videos and actual output samples of how the new application should look like. I think that this is a very important step and want to say that I think it should have been sent earlier to us, as for a long time we kept researching about the tools we were gonna use and to be honest it got a little bit boring as I was really was looking forward to this part of the process. It’s true that in order for you to start working on a project you should know the tools and systems but I also believe in the theory where you also learn while working on it.

So during this sprint we took our time to watch the videos and after we made sure we all had seen and understood the videos and the requirements, we created Zeplin accounts. For all of you who don’t know Zeplin, Zeplin is a collaboration tool for UI designers and front end developers. It goes beyond the design workflow and helps teams with the design. I had never used Zeplin before but I found very useful in sorting the project and handling off designs. Recommended if you ever do front end development!

A Github section was created for all WSU participating in this project and each of the teams created their own branch. We discussed if each of us should have their own branch but we ended up in the conclusion that it would be very messed up for each of us to have their own branch pulled from master, so a branch per team was the final decision. However, each one of us could create its own branch from the team branch and that would be great in case any of us wanted to experiment. we left the option available  to whoever wanted to do so.

After we created our branch we choose our task to do, which is a search bar.  Something I really would like to point out is the team environment we have. We all are very communicative and express ourselves and our opinions. For us it was easy to agree on the search bar as a start up to do task for this project.As a lot of steps on this process don’t depend on us I would say that everything is going fine and I wouldn’t change anything if I was back in the same situation.

While working on the search bar we keep checking with our teammates and how is the progress going. I am really glad we haven’t really been facing any major issues and our team is working strongly together. I am really looking forward to getting the search bar done and move on to the next task. Stay tuned for my next blog post to see what happens. Until then..Have a good time

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