Recently, my team completed our third and final Sprint. In this Sprint, I focused mainly on the design on the CheckInventory frontend once again. In the last Sprint, I had updated the header and the footer of the page, so this Sprint, I updated the information display portion of the page. I looked for some inspiration, which I found at the bottom of the WSU Thea’s Pantry page, where they used a white box floating in a gray background. I thought it was a decent design so I interpreted it. I kept the initial box design, except I upsized everything, and removed the title. I put the title floating above the box, bolded and in a dark blue. I increased the size of the font inside the box, and highlighted the weight itself in red. I gave the bottom and right side of the box a small shadow, to give it the illusion of floating. Finally I made the background a soft gray, which eases the eyes a bit better compared to a white background. I created a merge request for this issue, which would allow my teammates to use the code from it and update their own frontends. The last issue I tackled was the navigation bar. Originally, it had links to go to ‘Home’, ‘Check Out’, and ‘Check Inventory.’ I had removed these links from my navbar when I added it as they did not work, but it left the bar a bit bland, and we would need it eventually, so I put back the ‘Home’, and added a ‘Add/Donate.’ I made it so that it underlines when a user hovers over them. When the page is resized, the navbar collapses in a hamburger button. A user should be able to click on this button, which could drop down the options from the navbar. The button did not work, so I spent a bit of time trying to figure it out, only to realize it took eight characters to fix, but regardless it works, and on a mobile phone view as well. I went ahead and fixed some things about it, having it so that the options drop down on the right side of the page instead of the left. The ‘toughest’ part was fixing the design of the hamburger button itself to match the rest of the page. I had to create my own hamburger button in Canva, imported it as an svg file, and then I was able to change the button. I made a merge request for this as well, which allows my teammates to take the svg file and use it on theirs too.

What worked well was communication, we were quick with answers when someone needed something, quick on reviews and merging, etc. It was something we’re always good with, which is good. What worked well for me was still working on the frontend design, again it felt more like something I wanted to do rather than work. I wanted it to look good, and so I gave it my all to make sure it would look nice. Something that didn’t work well was making good use of my time. With the issue about the hamburger button, I had researched a lot and played around with a lot of solutions to get it to work until one did.  Felt like I could’ve figured that out faster, but I didn’t.

I don’t think there’s a lot we can improve on as a team. In my last blog, I suggested a stand up to clarify what we were doing individually, but since we have solidified ourselves into certain parts of the project, we all just knew what each of us were doing. Individually, I could improve on doing more, I felt like I was not doing enough work compared to my fellow teammates. 

A pattern that I can relate to during this Sprint was ‘Read Constantly.’ It basically means although I’m learning all these new and difficult things, there are more difficult things beyond that, and I feel like I won’t be able to catch up. After researching and reading about my issues, I felt this way, not just in this Sprint, but in the previous ones as well. If I had read this pattern before, I don’t think it would’ve changed anything. I still have to read and research my things, ultimately that’s how I grow.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Last week, my team completed our second Sprint. Like the first Sprint, we did a good job. Each of us stuck to the parts we left off after the first Sprint, so with me, that meant continuing with the CheckInventory frontend. The issue I wanted to get done by the end of the first Sprint was connecting the backend to frontend, so that instead of displaying a hardcoded value, it would pull from the backend. By doing so, the frontend would have its full functionality. However, that was easier said than done, as I spent almost two weeks trying to figure it out, only for my teammate to figure it out before me. They had created a shared network for their frontend that connected to the backend. I ended up using the same shared network with no problems. I created a method that called ‘GET’ from the backend in order to display the value. The next issue was figuring out how to call this method upon mounting the page. I spent a week trying to solve this, until it was suggested that I try calling it through a button press, as that had success with my teammate’s frontend. I tried that, but the button simply refreshed the page. Later, I tried a different button, which ultimately worked. However, I was not satisfied with that, so I did some more research and found a ‘beforeMount’ method, which solved the problem. I committed, and made a merge request for both the shared network, method and mount issue. With a week left of the Sprint, I spent time playing around with the design of the frontend, as there was discussion in the visual identity team. I refactored the frontend in order to call the header, CheckInventory, and footer components in the App.vue file, instead of using a router, like it was originally. I then fixed the footer to sit properly, and used the appropriate colors and fonts, according to the school’s guidelines. I completely overhauled the header, using the ‘Thea’s Pantry’ logo, adding a navigation bar, and adding a yellow strip to the bottom. Additionally, I used the correct colors and fonts, once again complying with the school’s guidelines. I was able to commit and merge those changes before the end of the Sprint, and present them to the client.

What worked well was still communication. We all communicate really well, and when we need something from someone, or someone to review something, it’s done fairly quickly. Our chemistry has also become more friendly, we’re more open and joke around with each other, while also being strict with our work. Speaking of work, something else that worked well was solidifying our roles in a way. Since we all stayed working with stuff we worked on during the first Sprint, we knew what we were doing from the beginning, instead of figuring out everything from scratch. Personally, what worked well for me was being proactive, especially with the design part of the frontend. I felt motivated to make it look good, and it felt less like work. However, something that did not work for me was again the expectation of doing enough. Towards the end, I felt like I was, but I felt most of the time I wasted a lot of time researching. It is not exactly my fault, but it also is.

As a team, there’s not much we can improve on, as communication is good, chemistry is great, and we have done a lot of work and progress. Something I suggested in the last blog post was clarifying what we are working on, like a stand up at the start of class. We had done this one time. Although I do not think it’s necessary, it could be a way to clear up confusion if there is any. Personally, what I want to improve on myself is using my time better. I feel I spend too much time researching, and although I cannot just speed that up, I could do it more efficiently.

The Apprenticeship pattern I chose for this Sprint was “Retreat into Competence,” in layman’s terms means I am overwhelmed by how dumb I am. This is referring to the fact that I have to spend time researching in order to fix my issues. There is nothing wrong with doing that, it is just that I spend too much time doing that. If I had read that before the Sprint, it probably wouldn’t have changed anything.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Last week, my team completed our first Sprint of the semester and presented our work to our professor and the client. Overall, as a team, we did a great job for having not done or been a part of a Sprint before. Each one of us was assigned an issue at the start of the Sprint to work on over the period. One of these issues was evaluating the frontends, so I reviewed each of them and found that two of them, AddInventory and CheckInventory, did not run properly. It was determined that it was a server/deployment issue, so I contacted a member of that team through private messages. The team was aware of the issue and were working on it, so I suggested to my team that we focus on the backend for this Sprint. However, we decided that it would be better if we try to fix it ourselves instead of waiting. So I was given the CheckInventory frontend. In class, another member was able to get the AddInventory frontend to run, so I asked for their help outside of class, where we determined that the frontend was unfinished. So my task for the next couple of weeks was to fix that, and I did so by comparing it to the AddInventory and CheckoutGuest frontends. I then “borrowed” files that were missing from my frontend, and edited and fixed ones that did exist. This consisted of organizing some files into new folders, copying over frontend-prod-build and frontend-dev-up commands, index.html file, and much more. After I got it to run, I edited it so that it would match the AddInventory frontend. After all of that, I committed, pushed and made a merge request. The pipelined failed with that, due to a yarn lock issue, so I fixed that, linted, and then committed and pushed again. 

What worked really well was communication between the team. I felt that whenever someone had an issue or needed something done, someone answered within the day, which is really good. I think the team chemistry was also really good too, it did not feel too serious but also not too laid back. We also helped each other whenever we could, which is good. On the personal side, what worked well for me was just working in general. Like this whole thing is something that I have not experienced before, so just being part of a team to get work done for someone else kind of gave me fuel to work and make this a good thing. However, something that did not work well for me was the expectation to get enough done. For each week we plan for something to get done, but every time for me, I felt like I did too little or not enough. Maybe it is something in my head, or I am setting the bar too high, but that ghost pressure was not nice. 

There is not a lot that I would say we can improve on as a team, mainly because our communication is good, the atmosphere is great, we help each other and we get things done. What we could do, just as a minor thing, is clarify what we are working on. Although I do not think this is an issue, it has been expressed by members of the team, so this can be a good way of getting some bearings. As an individual, what I can improve on is just getting more done. Although I did finish my part of the Sprint by the end of it, it did not feel enough to me, so going forward I want to do more. To go with that, I would like to be more open about what I did do, some of my teammates were not aware of what I did in some of the past weeks, so I would like to improve on.

The Apprenticeship pattern I have chosen that resonates with me this Sprint is “Confront your Ignorance,”  which is basically not knowing the information needed for the work at hand. I chose this one because it describes what happened to me during this Sprint. I realized very quickly that I did not understand many things in the frontend and the Inventory system overall, which was scary and discouraged me. If I had read about this pattern before the Sprint, I do not think much would have changed. I still would need to do a lot of research regardless.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.