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.

Retrospective 3

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.

Sprint 3 Retrospective

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:

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

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

I also took part in discussions on these merge requests:

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.

Final Sprint Retrospective

Yesterday was the last sprint review for the semester and the conclusion of my work on the UpdateGuest project (at least as required for my software development capstone course).

During this sprint our team worked on putting the whole UpdateGuest service together.

This sprint I helped to review many of the merge requests associated with my teammates branches and I worked on both making decisions and helping implement the Angular form for our frontend.

Specific issues I worked on this sprint are:

I think our team did a really good job this sprint. As Dr. Wurst commented yesterday, our team did really well this sprint with communicating and looking back at the different issues and merge requests from this sprint, I completely agree. Additionally, I was very impressed and excited about the work we accomplished during Sunday when the team met on Discord and worked together to rapidly implement, review, and merge different features.

I think that some things could have gone better too for our team. This includes improving when we work on our issues and working on issues ahead of deadlines, along with having everyone on the team working on reviewing merge requests.

There are a few areas I think I could improve on personally. This includes improved time management and keeping track of overall project progress. This was almost a problem for our team as we had a very last-minute meeting the day before our sprint review to finish our implementation of the frontend and make it work with the backend. I take responsibility for this and I should have setup a meeting to work on this much earlier than Sunday morning, especially as this was suggested by my teammates earlier in the week. Another area I want to improve on is consistently working on issues. This sprint there was a week where I didn’t do any of the work I needed to do for the project and that undoubtedly didn’t help, along with also waiting too long to work on issues. Finally, another issue I would like to improve on is finding a balance between reviewing others’ work and working on my own implementations. This sprint in particular I found that I spent a lot of time reviewing and learning about my teammates work. While I do think this was helpful and led to more refined code getting merged, I think it led to me spending much less time on my own implementations, which I am not as happy about.

Some of the areas I think our team could improve on if we were to continue working together largely relate to some of the issues I could personally improve on. I think both personally and as a team we could further improve on our ability to refine issues and improve on how we estimate the weights for issues. This problem specifically occurred with the implementation of the Angular form where I think it took a lot more time and had more issues than we originally anticipated. Additionally, I think our team could improve on keeping track of overall project progress for meeting deadlines and maybe work towards setting estimated deadlines in all issues with times and dates for issues to be completed. Again, this would help to avoid a last-minute meeting where a lot of work needs to be done in a single day to finish features (or the project). Finally, I think that everyone in our team could work on reviewing more merge requests so that this work is more evenly split and gives others (including me) time to work on their own features.

Overall, I am very happy with the progress our team made during this final sprint and I am especially impressed with how everyone worked together Sunday to finish all of the features we needed for this project to be in a good and working state.

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.

Sprint Retrospective #3

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.