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.
