3: Sprint Retrospective

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.

Sprint 3 Retrospective

At the end of last week, we finally conclude our third sprint in our development process of the LibreFoodPantry, aiming at a deloyable environments so that they all are isolated in their own space. This is also our last sprint so we tried our best to wrap it up as much as possible, so that the team after us can easily pick up from where we left off. We were able to work together more this time, comparing to us having to separately work on our own stuff in the previous sprint. We finally got a working, operational and deployable user interface as well as a fully implemented, buildable and deployable backend system with REST API and mySQL database. We were also able to adapt with the online communication and worked more effectively with each other.

List of what we accomplished during the last sprint:

       – Successfully integrate Docker into frontend UI and the REST API, allows them to communicate with the existing mySQL container with configurable parameter in config.json file (REST API Docker, ApproveGuestWebUI Docker)

–         –  Having an operational admin page user interface or ApproveGuestWebUI, although without actually data fed from backend systems, but mocked with data points (ApproveGuestWebUI Epic)

–         – Having a mocked or stubbed backend for the frontend to test connections establishing mechanics (Registration Stub)

It seems that we did not do a lot for this sprint, but it was actually much more challenging for us because of more advanced technologies that we have to research on and a lot of new barriers that we have, such as us having more things to do for our career and other classes, voice and video communications became harder as the internet becomes unstable, for me at least, etc. Despite all of that, I think we did a very good job wrapping up all the work we have done from the sprint and even make it deployable, so the next group can just skip the hard part of Docker and focus more on the part of developing operational products for the food pantry. We think that is much more important than to waste time on getting them to be able to run on an actual server, so I heavily prioritized to get it done, both on Docker Desktop and Docker Toolbox. I would say that out of all the sprints, this one is pretty boring since I personally had to read a lot comparing to the two last one that all I do is setting up systems, coding, and a whole lot of checking on people if they can run the same system and if they need some help.

For future improvement, if we have a chance to work more on the project, I think it is better to centralize our work source into either backend or frontend, then move on to another. I believe it is better that way so all the team member can know what other members are doing and learn both the backend and frontend stuff. Another improvement that our team can use is more official communication and well documenting our steps of implementing. It is the same problem that persists from the last run, but we did make sure to have more transparency in what we do this sprint, which I think is a major effort from us.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

SPRINT RETROSPECTIVE #3

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.

Sprint 3 – Retrospective

Sprint 3: 04/08/2020 – 05/04/2020

Sprint 3 preparation started on 04-08-2020. Since Sprint 3 was the final Sprint we were planning to get work done as much as possible. We proposed too many issues that were all appropriate, but we wouldn’t be able to finish them all on time, so we all agreed to keep the most important ones. Our top goal for this Sprint was to have the UpdateGuest service work as a whole.

These are the issues we came up within our Sprint 3 planning (we had more in our backlog):

  • Create MongoDB database for UpdateGuestService
  • Implement WebUI in Angular App
  • Decided which type of Angular form to use for Web UI
  • Learn about Angular Testing
  • Create endpoints in backend
  • Learn how to create tests for backend endpoints
  • Learn Docker
  • UpdateGuestWebUI: Create Docker Configuration
  • UpdateGuestService: Create Docker Configuration
  • Implement requested endpoints from registrar team
  • Decide what needs to be tested in the frontend
  • Implement endpoints in Frontend
  • Implement Angular form in WebUI.

 During Sprint 3 I worked in multiple issues and supported the team with issues discussions and merge requests’ review:

1 – This issue was part of Sprint 2, but we had some minor changes that needed to be done before we merged the merge request.

2 – We had to decide which Angular Form we were going to use, and as a team, we decided to use Reactive Forms.

3 – This is issue was more about learning. The first thing learned was that the latest version of Docker cannot be installed in a Windows Home edition unless you are using it as an enterprise. Docker in Action was a great resource to learn Docker.

4 – I have reviewed, approved, and merged the merge request for this issue.

5 – I created the Docker configuration of the UpdateGuestWebUI using the NGINX proxy server, which by default will run at PORT 8080, using the Docker container IP.

6 – We had a couple of merge requests for this issue. I have reviewed the merge requests of my teammates and implemented the Age&Employment component.

What we needed to do less

We should not focus only on the issues we get ourselves assigned to. Reviewing each other’s work is very important.

What worked for us as a team:

  • Reviewing each other’s work helped a lot with our progress because of the feedback we gave and received.
  • Helping each other through Gitlab Discussions and during our class meetings.
  • Checking GitLab constantly as we decided on our working policy helped us be on the same page.

What we need to improve 

There is always something that needs to be improved, especially when the team is determined to constantly make progress and succeed. In our case, we should improve the way we manage our time. 

Conclusion

I think we finished Sprint 3 successfully. We managed to work together even better than Sprint 1 & 2. The reason for that is because we were able to communicate, discuss, share, and collaborate with each other the whole time. In the end, we all feel satisfied and accomplished with the progress our team had.  

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

Retrospective #3

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.

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.

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.

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.

A Different Road

Many times the plan that people have laid out for their lives are almost never the same as what actually happens. In this pattern, A Different Road, the author discusses that sometimes it is okay to step away from The Long Road that you were taking to becoming a software developer. This simply means that its okay to step way from this, whether it be permanent or temporary, you should always carry the skills that you learned with you into whatever it is you do next. Then expanding from that, if you do return, you should keep those unique experiences and bring them back into your next job.

This pattern speaks to me personally because I have had many different jobs ranging from warehouses, Dunkin Donuts, meat shops, landscaping etc. The point being is that I have had the privilege to be able to experience this firsthand. Many of these jobs were basic minimum wage jobs that left me desiring for more, and to be able to actually use my brain. However, these jobs all were able to give me something back that I have been able to carry with me throughout my life. For example, most of these jobs gave me the motivation to constantly be trying to reach a better place in life and work. I know how it feels to be sitting in a job and feel like my brain is melting from boredom. Going through these times grants me the motivation to not have to return to them.

The pattern also discusses that often times with a desired job in the software field, HR will see the other jobs as simply lack of experience. However, through the many jobs that I have had it is very obvious to me that this does not constitute for lack of experience because all jobs tie together in different ways. Because I simply was not doing software strictly at the time, does not mean I am not capable of a software job. This is where it all ties back to the pattern. If you are able to take away good, beneficial lessons from where ever you are, you simply have to be able to prove these “skills” to whoever is doubting you.

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

Apprenticeship Patterns: Draw Your Own Map

The final Apprenticeship pattern I would like to discuss is titled “Draw Your Own Map.” This pattern is written for developers who feel that none of the career paths their employer provides is a good fit for them. It reminds us that it is up to ourselves, not our employers or anyone else, to determine what the next step in our careers should be. The pattern recommends that we develop possible career maps made up of small, specific steps we want to achieve. If our maps conflict with our employers’ expectations, we should simply seek out other opportunities that better fit. These maps are never set and can be altered as our circumstances change, but they will always help guide us towards the career we want.

As I’ve gotten closer to finishing college, I’ve become increasingly worried about my future. I don’t have any definite goals or plans for my career, and I don’t know how to create these plans or put them into action. I chose to read this pattern because it seemed like it might help me figure out a plan for myself. After reading the pattern, I at least think it provides some useful advice. I like that the pattern emphasizes the importance of achievable steps and advises against high-level goals. This makes me think differently about my lack of long-term goals, as I now understand that it is easier to succeed by planning short-term steps. Additionally, the pattern helped me realize the importance of following my own plan instead of one set by my employer. I have had miserable jobs in the past which I felt trapped in due to a sense of obligation towards my employer, but reading the pattern pattern assured me that I do not have this obligation.

One problem I had with this pattern, which also applies to the other patterns I read, is that it assumes the reader is already employed as a developer. For this reason, the pattern doesn’t quite provide the help with actually creating goals that I was hoping for. Despite this, I think the pattern gives a crucial piece of advice in the second paragraph, where it emphasizes the importance of taking a first step. Even without a clear plan, taking a step is crucial for building momentum that can lead to success. Despite not having clear goals for my future, I already know I want to work on regaining my passion for programming in the short-term. After finishing college, I should focus on pushing myself to take this step. Hopefully, I will develop the motivation to keep programming and eventually be able to draw a map for myself to follow.

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.

Sprint Retrospective

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.

Finishing Up The Patterns

The final pattern I will be writing about from Apprenticeship Patterns is “Retreat into Competence”.

The “Retreat into Competence” pattern describes how to solve the problem of when you begin having issues as you start working outside of areas you are comfortable in.

I like the ambiguity of the opening quote by Robert Pirsig, I find that it is comforting while being vague at the same time. I agree with the quote about not knowing where I currently am but what I’ve done so far seems to make sense to me. I like the idea and I think I need to think more about what I’ve done so far as a computer science student to find what my “pattern” is so I can use the advice Pirsig seems to suggest and apply my own “pattern” going forward.

The topic that the pattern covers is something that makes me think about what I’ve learned as a computer science student as I am reaching the conclusion of my work for the major. In particular, it makes me think back to a conversation I had with Dr. Wurst and especially when he mentioned the fears of not knowing enough as I approach graduation.

I particularly connect to the idea that the pattern mentions of a deadline problem. The deadline problem was something that I thought would happen on Monday with my work on the UpdateGuest project and I wasn’t completely sure if our group (and I) would be able to finish our project before our review meeting. Additionally, I was having a hard time figuring out how Angular worked towards the end as I was trying to finish the issues I needed to for the project to be done. I got past the problem though with the help of my teammates and one awesome article my teammate found which helped us to get our Angular form implementation working.

I think the advice offered in the pattern is important and I agree that it is good to occasionally remind yourself of what you’ve learned and what you can already do, especially when you can’t solve a problem you are working on.

I found the “Retreat into Competence” pattern to be a fitting final pattern to write about as I finish up my work in the software development capstone course and as a computer science student. I am making it a goal to finish the rest of the patterns in the Apprenticeship Patterns book over the summer as I have found the advice to be helpful and I am curious about the remaining patterns as they are frequently mentioned in the current and previous patterns I have read.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Improving as a Developer

Today’s first pattern in Apprenticeship Patterns is “The Deep End”.

“The Deep End” pattern describes how to avoid getting stuck at the same level of being a developer and how to take risks to improve yourself.

As far as the “Context” area of the pattern goes, luckily, I don’t think I’m in a “rut” right now. Currently I’m still learning about lots of new things and tools at the same time and although I would like to make more progress, I think I’m still moving forward.

The “Problem” section makes more sense to me than the “Context” area and I agree, and I would still like to improve my knowledge and keep on learning about the tools I am currently working with. I agree with wanting to have additional projects I have worked on for when I apply for a job and I would like to have these shown on my GitLab account.

I think the part of the “Solution” for the pattern that describes “Waiting until you’re ready” is one of the most relatable parts of any of the patterns so far. I agree with that statement and I feel like I should just start learning new tools or adding work to a project instead of continuously waiting until I really feel like doing it. I feel that I should schedule regular times for learning or working on implementations to help avoid the problem of not feeling ready.

The example provided with Enrique’s email is especially impressive. I don’t think I’m quite ready to do something like Enrique did, however I do think that the email illustrates the success that following the pattern can get you and that there was a lot of value in including it.

Answering the “Action” questions I think the largest project I’ve worked on as far as team size goes is with my current work on the UpdateGuest project. As far as size goes, I think my own personal project might have the most amount of code (although the size may be tied close with UpdateGuest). I think the idea of different project “metrics” is interesting and I think some other useful ones could be total time spent working on a project and how automated the project is as far as CI/CD goes.

I think that the pattern offers valuable advice, especially with avoiding a “rut” and I would especially like to think of more and keep track of the different project “metrics” as I continue to work on old and new projects.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.