Category Archives: Web Design

Sprint 3 Retrospective

            As you may hope, or expect, this final sprint is where everything really came together, and we were firing on all cylinders. We had consistent communication when needed and otherwise had tasks we could work self-sufficiently on in the meantime. Our task board was positively stuffed with tasks that expressed the minute details of our process, and we managed to complete an incredible amount of their weight considering how many there were. Having spent the first sprint unsure of what tasks actually needed doing, and the second iterating on what we had created, I believe this was the moment all the building blocks fell in place; and it felt, at least personally, that tasks were clear and specific, comprised of all the things I wished to improve from the rough iterative process mentioned in the second sprint.

            I think having finalized our UI design, or at least cemented the layout, allowed for easier improvement of said design. In many ways, having a finalized user flow in place made so that much of the non-style code could be refactored to store and manage information more effectively. For instance, as mentioned in the note above, I began with calling REST API to log transactions in the weight entry component where the necessary information would end up: student ID and weight. After refactoring, I broke both the storage and management of guests into a service which could be more easily accessed by any component and centralized any API calls made using guest information. This worked perfectly except for a single instance, where I needed this service to call another component. Services can be easily imported by components but sending information to a specific component from a service is more complicated. As I understand, the code I used subscribes the component I needed to speak to, to the service, which then can send a signal to that component, which in turn calls one of that component’s methods.

            Regarding what did not work, it is a combination of both personal and group strategy. While we each could work effectively alone on our own independent portions, it meant that we all became intimately familiar with only one or two aspects of the project. This has especially caused problems most recently with trying to move our respective portions into Docker, as I was the only one who knew next to nothing about Docker. Therefore, I could not help my group members work on any problems my front end code may have caused. I see not keeping up with my group member’s Docker progress as a personal failing. Now both in this class and in the workforce to come, I am wishing I had this knowledge of such a powerful and seemingly common framework. Otherwise, I am very proud of the work my group members did and think given some more cross-cutting training we would be that much more of an effective team. Especially given everything that has been going on we have managed to put together a site that is nearly ready to roll out. (With the caveat, of course, that it may not be absolutely perfect but can perform all the tasks necessary).

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.

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.