Sprint 2 Retrospective

Overall, I think the second sprint was somewhat less effective than the first for my group. Unlike the previous sprint, we had some problems that prevented us from completing everything we expected to. I think the main issue we had was a lack of clarity regarding our goals for each issue. We have not been declaring a ‘definition of done’ for our issues, so we didn’t always know what we were working towards. The biggest example of this was the “Design frontend architecture” issue. We never had a plan for what our design needed to include or how it should be made, which caused this issue to get stuck in the ‘needs review’ column for most of the sprint as we tried to work out the confusion surrounding it. Additionally, I think many of our issues were too broad. For example, we had single issues for creating a database and implementing our UI which could probably have been broken into more specific tasks. We definitely underestimated the complexity of these issues and the time they would take, which made them difficult to complete during the sprint.

Despite the problems, there were some aspects of the sprint that worked well. I think our communication has started to improve since the last sprint. GitLab was used for discussion outside meetings more often, especially on the merge requests. I also thought that our in-class discussions were more effective. We did a better job using our time together to discuss specific problems instead of working on our own, especially after the transition to online meetings. Although the lack of clarity in our issues made the sprint difficult, it forced us to communicate more effectively so that we could help each other understand what needed to be done.

To improve as a team, we definitely need to be more specific with our issues. This would involve splitting broad issues into more specific tasks and creating a ‘definition of done’ for each issue so that we all know what to work towards. We should all look over our proposed issues to make sure they are small enough tasks, and we should add a definition of done that we all agree on to each issue. Ideally, this would be done during the planning meeting, though we can surely continue to fine-tune our issues during the sprint. If we are able to accomplish this while maintaining effective communication, I think our final sprint will be far more effective.

Individually, the main improvement I think I need to make is to keep better track of my teammates’ progress on their issues. So far, I have been completely focused on completing my assigned issues. As a result, I could never get around to familiarizing myself with the work completed by my teammates. This prevented me from reviewing their issues and approving their merge requests. It has also made me generally uninformed about the state of the overall project and where it is heading. I feel like I have not been contributing enough to the team, since I have been so focused on my own work. For the last sprint, I hope to participate more in reviewing my teammates work to both help the project progress and to keep myself informed. I think that making our issues more specific will immensely help with this. Having more manageable and specific goals would likely reduce my anxiety about completing my issues and allow me to spend more time assisting my teammates.

Links to my GitLab Contributions:

This is the main issue I worked on, where I learned about Angular testing. I left several comments informing the group of my progress and providing links to useful resources I found.

This is a repository I made to share my project where I experimented with Angular testing with the team.

These are issues that the entire team worked on. I left comments on some and moved some across the board.

I left a comment on this issue to inform the group of a meeting I had with the other teams in class.

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.

Apprenticeship Patterns: Nurture Your Passion

The next Apprenticeship pattern I would like to discuss is titled “Nurture Your Passion.” This pattern is targeted at software developers whose work environments drain them of their passion for creating software. It emphasizes that a passion for software craftsmanship is crucial for improving our skills, and that we should take steps to protect our passion if we find ourselves in such an environment. The pattern suggests several techniques we can use to strengthen our passion for software development. These include investing time into enjoyable projects, joining groups that focus on our interests, and changing our work environments.

As I mentioned in my post on “Breakable Toys,” I have struggled to stay passionate about programming since I started college. When software development became the focus of my education, I stopped working on personal projects because they took time away from more important (yet far less enjoyable) class assignments. This really damaged my ability to enjoy programming, and I think that following this pattern’s tips could help me regain some of my passion. I already expressed my desire to start working on personal projects on my own time again in my “Breakable Toys” post. While this pattern recommends this once again, it also provides several new suggestions that I think could be just as useful.

The pattern first recommends focusing on enjoyable topics while working as a way to make work less draining. This suggestion changes my perspective on how I should go about my work, as I have generally not prioritized my own interests during assignments. For example, I have recently been working on testing for my group’s project in CS-448, which has been exhausting for me since I dislike writing tests. I might try to contribute to more interesting aspects for the remainder of the project so that I can be more invested in it. The pattern also recommends joining groups and reading books that focus on topics of interest. Groups haven’t really worked for me in the past, and I’ve never been a fan of reading, but knowing that these options could help nurture my passion might make them worth trying. Finally, the pattern recommends having a list of positive ideas to talk about whenever work conversations become exhausting. Although I’m not great at conversation, I think this might be an action worth taking. Even if I never have a work environment that completely engages me, talking about my interests with others might be enough to keep my passions alive.

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 #2

In the past few weeks a lot changed in our lives. With all the global epidemic we lost a week worth of work for the semester, and with all responsibilities that all of us have, everything else pushed to the second degree of priorities. With that being said we as a team supported each other … Continue reading SPRINT RETROSPECTIVE #2 →

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 Retrospective 2

For the first sprint we did most of the programming of the individual parts of the service. The first thing we did was update the working documentation with the new information from the meeting with the food pantry. Also in the working documentation we Changed the zip code and id to string in the working documentation since they can start with zero. This was pointed out by another team. The next thing we did was to update the REST server with the new information from the meeting with the food pantry. We also updated the register application with the new information from the meeting with the food pantry. The last thing we updated with new food pantry information was the database. Also in the database we looked into how to connect the database to the REST server. Next we created a new angular project with all the different types of inputs the angular applications would need to run. This was done to help the people writing the angular applications. After that we added a register class to the register application to send over the register endpoint. We also added an error checking method to the register application so that a bad registration cant be sent to the REST server. Next we added all the input elements to the register application and connected them to variables in the typescript file. The last thing we did with the register application was to connect it to the register endpoint from the REST server. We also added all the input elements to the is registered application and connected them to variables in the typescript file. The last thing we did with the is registered application was to connect it to the register endpoint from the REST server. This was all everything we did for the sprint.

What i did for sprint

Update the working documentation  with the new information from the meeting with the food pantry

Changed the zip code and id to string in the working documentation since they can start with zero.

Update the rest API with the new information from the meeting with the food pantry

Changed the zip code and id to string in the rest API since they can start with zero.

Create an angular project with examples of the different inputs

Added register class to register application

Added error checking method to register application

Reflection on what worked well?

Planning was much better than last time

Used the boards better

Added relations to the issues

Ordered issues better

Reflection on what didn’t work well?

Did Not communicate enough during sprint

Didn’t talk to each other during two week break at all

Didn’t finish everything

Reflection on what changes could be made to improve as a team?

Try to keep each other updated on our progress during sprint better

Finish everything

Reflection on what changes could be made to improve as an individual?

Try to tell other people what i am doing more

Ask other people option more

Links to evidence of activity on GitLab with one sentence description for each

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

  • The input example project

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

  • The is registered application

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

  • The register application

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

  • The rest server

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

  • The database

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

Sprint 2

We are on our second sprint. Couple of things and changes we as a team did. We reflected on our last sprint and tried to be more organized and complete tasks on time. We updated the working documentation, changed zip code and id string to working documentation, looked into how to connect databases with new information, created an angular project with examples of different inputs, added buttons to register applications, connected buttons in the register application to variables and added an error checking method to register applications. We all tried to communicate with each other on how things are going, if someone needs help and communicated on what each member is working on.

I tried to give my best effort in helping the team. I pushed my code in branch-working, instead of master. I plan to work on connecting the endpoint with help of my teammates. I did some more research on Docker and tried to learn more on connecting the endpoint. I needed to understand what why and how I will be doing it because it is an important connection in the project.. Nothing at the moment is blocking my progress. I am trying to learn and research more on connecting the endpoint. After researching and getting some feedback from my teammates. I created the endpoints in isregister and modified the app design.

Overall, everything went well, I learned new skills and gained more knowledge. What didn’t work well was the communication. Due to lack of communication we weren’t able to complete some of the work.

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.

Second Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/25 got familiar with NGINX

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/41 Made program read MySQL login info for rest api

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/21 Implement Endpoint /needsApprove/between

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/46 Design /approveUpdate

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/22 Implement Endpoint /Approve/all

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/37 Implement guest-info Component ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/20 Implement Endpoint /getGuestInfo/{id}

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/30 Create connection between database and Rest API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/40 Create and Link Epics

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/5 Create mock database in mySQL

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/19 Implement Endpoint /isApproved/{id}

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/47 implement /approveUpdate

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/51 Install Angular Material in ApproveGuestWebUI Project

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/32 Create UI Design for ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/45 Implementing CI/CD for IsApprovedWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/44 Implementing CI/CD for ApproveGuestService

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/49 Questions to ask Joanne from Thea’s Pantry

I believe the thing that worked well for us in this sprint was constant communication and trying to help each other with issues that we were facing or that were related to one another. I think our team did a good job on staying on task and completing things at a good pace and each member was actively involved with each person’s code since we needed another person to review our code and approve it for it to be merged with the master branch. Due to the situation going on in the world around us the sprint was hindered due to the extra week of spring break and our group got a little too comfortable during the break and neglected our work. I think we had a lot of great things that we should have weighted a little differently and we had no idea that the weight of an issue can be changed during the sprint as well, so had we known that we would have readjusted a few of the weights to be more reasonable for the amount of work that was required to complete the issue. As a team we could benefit from meeting at least once more outside of the regularly schedule class period during the week to be able to complete more work and have more opportunities to figure out what works and what doesn’t. I feel that I got too complacent during the break and neglected this sprint’s work toward the end, so in the future I hope to be more focused and on task even during things like a two week spring break. I should have also spoken up more when I felt that an issue was not the correct weight, but I wasn’t fully sure since the last sprint we had, we finished all of the issues way before the end of the sprint.

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.

Sprint Two Retrospective

If the first sprint was crawling, then this sprint we moved straight to running. When considering the shorter length of the first sprint we appropriately stuck to smaller “set-up” or preparatory goals. This time, we began actually building our site in earnest. My focus, as evident from the list above, is web design and development for the UI/UX. At the beginning of this sprint, while planning, I was at a loss to quantify what exactly needed to be done. One may notice that many of these issues were posted within the last few days of this sprint. Considering I haven’t built that many websites, and none with so specific of a purpose, my thought was that I didn’t know what I needed until I had it: I would simply figure things out as I built them. This flies in the face of any good practice, and I will of course avoid such practices moving forward, but given my inexperience I had to lay the tracks in front of us as we steamed on. This manifested as an incredibly broad task, “Implement the UI from the wireframe”, with us then filling in the gaps after.

This worked, but not terribly well. It has given us a working front, albeit with some missing or broken features, but a code base desperate for refactoring. As with last semester, I often would end up learning about a useful feature after I had already beat my head against the problem and found a roundabout way of solving it. For instance, despite implementing a new directive, I did not know that services could be split off as well and shared by all components. The list of all Guest IDs, for example, would be best shared by all components instead of how it currently is implemented, which is a hodgepodge of emitters with no “real” persistence between components. It can currently pass guest IDs effectively between them, but this could be done, presumably, much easier using a service. I’m not completely certain either, it will be another instance of a new technique we’ll have to learn as we implement it, but I would have liked to have started here rather than arrive here after what will become somewhat wasted effort.

I say somewhat wasted, but in reality, it doesn’t hurt to know how to approach problems in many different ways. I believe using emitters is a valuable skill to have. Additionally, I now know at least three different ways to embed svg into a web page, with each successive one being more effective than the last but with all having their uses. I feel that I am certainly improving as a web developer, with each new misstep putting me in the direction of a better solution. However, I have a lot to learn in regard to version control systems. I caused a few headaches for poor James, who kindly walked me through all my poor practices. I know now never to push directly to the master branch for a new feature and utilize merge requests effectively. Also, never copy paste anything, because they are treated as new files even if they have the same exact content and will cause innumerable conflicts. In addition, Pawel and I ended up both independently working on the same issues, but we have discussed ways to avoid these situations moving forward. Even with all the growing pains mentioned and those involved in moving everything online, I believe we have found ways to be an effective team as well.

For this next sprint, our tasks already look much better, each containing the fine detail of work that needs to be done in order to reach our next project iteration. There are considerably more tasks, and none that are as horribly broad as many of those in this sprint. We possess a better sense of what needs to be done, and we can act upon it. By applying all the lessons learned thus far I believe we are closer and closer to something that can actually be used by the food pantry and should all be proud of that fact.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Capstone Sprint 2 Retrospective

This second sprint brought with it some challenges in moving to online classes for the ongoing epidemic, but with it a stronger grasp on communication and documentation using GitLab and Discord, both out of necessity and intentional effort. We have learned to better work with LibreFoodPantry workflow and are ready to go into our next sprint with our REST API, Database, and Frontend all working in isolation.

My contributions

Create file with definition of done.

Change to default .gitignore file for Spring and remove unnecessary tracked files from before we added the .gitignore,

Research internationalization support and decide that it is better to be saved once a more-final version of the front-end is complete.

Research Angular Testing and create a Spike project that covers most cases we will encounter.

Integrate ID scanner to get Student ID with an Angular component and create tests to have 100% code coverage.

Retrospective

For the first half of the sprint, we were still having weekly meetings to work together. One of our troubles last sprint was that we were discussing things in person and not doing well documenting the reasons for decisions we made. We improved on this even while having in-person meetings. By the second half, although we were all coping with changes brought on by moving to online classes, we did well in keeping each other updated and communicating through GitLab. In hindsight, it’s probably a good experience to be forced to do this. Especially if this epidemic inspires more software companies to promote working from home.

The biggest issue we had as a team was working with merge requests. There were a couple cases where code on a feature branch was not kept up to date with the master branch. As a result, there were a lot of merge conflicts to work together on resolving as a team. Overall, working through these together as a team was a good experience, because this is bound to happen when working in tandem with version control. However, now we will be reminding ourselves to pull changes from origin/master as we are working on our local branches.

We also improved with creating merge requests for each individual features, although this took a few weeks for us to all do efficiently. GitLab has a great feature where you can tightly-bind an issue to a merge request, but this caused a couple of problems for me. When the merge request is accepted, the issue is automatically closed. This messes with our workflow, because we want the issues in the “done” column, only to be closed by the product owner. Moving forward, the issues should be linked with their merge request but we will have to take care that the description doesn’t include a “Closes issue” tag.

Furthermore, when a branch is automatically made in GitLab, it creates a very verbose branch name, which is simply annoying if your Git isn’t configured to autocomplete branch names when pressing “tab”. In the future, I will create a new merge request and manually select my already-created branch. Then I will manually link the issue.

The team’s willingness to quickly meet over Discord about an issue we were having was the best thing about this sprint. In the few cases where something occurred outside of class time that required all of us, we were able to set up a time the same day or the next day and resolve the problem. This flexibility to schedule work within the sprint is what helped us get as much work done as we did.

The next sprint will involve combining our individual pieces into a working product that is capable of storing actual checkout transactions. There is a still a lot to learn and to do, but we are well on our way to finishing a viable product that we are proud of, albeit with much room to grow in the future. We will have to pay close attention in the next sprint to creating well-written documentation as we combine our API, database, and front end so that future developers can easily recreate what we’ve done and get it running.

From the blog CS@Worcester – Inquiries and Queries by James Young 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/38

This is the guest-approval component that I have been working on with Angular material.

In the beginning of the Spring before moving entirely remote, I believe we had a good plan set in place in order to be able to accomplish all that we wanted to do. Originally, we were going to have John and I work on the WebUI together while Khoa and Tyler would be finishing up with the database and API. We were making good progress until we had to move to remote.

Once I moved to remote, I ran into many problems along the way. The transition into all online classes caused me to lose time towards all of my classes collectively. I had still been working for a majority of the time off and needed to put more time towards my classes outside of school than I had before. From there I ended up becoming overwhelmed by the work. I had to have been doing other schoolwork trying to catch up on everything I had fallen behind on. Once I started working on the approve-guest component I ran into a lot of problems. I had a functioning component before the time of going remote but once I started working on the component again, I ran into a bunch of problems. I was able to get my code to run and load in any HTML editor but once I moved it into WebStorm, there was almost always a blank page. I went through all of the dependencies, created new projects and consulted online with many different resources.  I seemed to be incapable of providing what I needed to for my team at the time.

The only improvement I can say for our team is that we need to be able to discuss more of what is going on throughout the project. We will have to find a way to be able to piece together all of the pieces that we have on GitLab into one project.

I need to put all my effort into this next Sprint because it has not been fair for what I have contributed during this time. I was not as available as I should have been with my team. I also needed to be able to better communicate that I could use some help to get my component back to functional. During the next spring I plan on going above and beyond for my team as they have all been doing an incredible job with this project. I will try to have daily discussions with my team in order to ensure that I stay on track. I will also try to be more active on GitLab with such things as moving the issues to done, approving merge requests or creating new issues. Hopefully this next sprint, I will be able to better estimate how long each problem will require so I can set more time aside for each one. I look forward to making this next Spring into a fully functioning GuestApproval.

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

Ah The Classics

“Study the Classics” pattern is all about starting with the oldest books in your reading pile and understanding them before moving to newer books. In order to understand the things that other people in the Computer Science field, A person should ask about what they don’t understand and where they can read more about the topic. By focusing on and studying the great works in your area of interest, a person can gain a basic understanding of information on that topic and expand their knowledge at to meet the same level as others in the same profession/area. While some books may have outdated information, they might still have some important points and vital information on how things should be treated today. The pattern also talks about how it can also be a bad thing because you follow classics over more pragmatic solutions for problems.
I think there is a lot to be learned from the past since it took a lot more precision to complete even the simplest tasks of today and things like file size/code size was extremely important and coveted as something that could make or break a project. While things like systems, programs, services and so on continue to get more advanced and powerful rules from the past still apply in many cases and because of this we can still learn a great deal of knowledge from past works on areas of computer science. I Knew there would be a need to continue studying and learning in my profession, but I was unaware of to what degree I would need to take it. I feel that this pattern makes sense and helps a person to further their understanding of their area of interest to one of the highest degrees. It allows a person to understand concepts that most people in that industry/field will know and thus opens up the conversation and ability to learn even more. I think they should have also had more of a focus on how you should intermingle both the classics and the modern/pragmatic books because they are both equally important and if you only focus on only one then you are bound to run into some serious issues when faced with a challenge.

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.