Category Archives: Capstone

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.

Share What You Learn: Sharing is caring

While applying this pattern to my experience feels a little presumptuous, considering people do not “look to [me] as a source of knowledge”, I have tried to share what little knowledge I have as I gain in hopes of helping my classmates with any troubles they may have. Like Kindred Spirits before, I have had good luck attacking a new topic in our individual ways first then comparing notes and filling in the gaps in our knowledge others have covered. As well, this topic reminds me of Breakable Toys as well and my misunderstanding of it, where I concluded that writing a wiki may be a helpful personal learning tool but through the lens of this pattern, sharing it could provide a collective learning tool. While I have yet to go as far as creating that wiki, I have been willing to share any knowledge I have with my classmates.

I also got a great opportunity to brush up on our major’s most difficult subject and then test my knowledge of it by being a peer assisted learning mentor for Data Structures. I realized how much I missed the first time I took the class, and when explaining it I had to shed to convenient mental tools I used for more thorough methods that I could then share with the students. I remember specifically trying to explain how to rank program running times, without taking the derivative of the function that represented the run time; as many of the students had not, and likely would not, take calculus. By the end I did feel as though I was better acquainted with the material but felt sometimes like I needed to go deeper as I had difficulties explaining some concepts well.

Another time, I remember having to give a mock lecture to another student who missed a lecture. It really pushed my understanding of the material to the limit because I could recite what I had copied into my notebook but if he needed to ask a question I could have fallen apart had I not been confident in the material, or had a good understanding of it. The book says that you may feel that “someone more experienced [should] put themselves forward”. However, many people can feel intimidated by professionals and may not be willing to ask vital questions for fear of looking foolish; as opposed to the camaraderie of peers. I think that pushing ourselves to interrogate our own knowledge of material in the presences of peers offers an excellent opportunity for growth.

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.

Dig Deeper: Finding the Marianas Trench of knowledge

This particular pattern is quite resonant with me, or at least the context section of it, considering it describes my entire academic experience in computer science fairly well. An excellent analogy would be a lake a mile wide but a foot deep; or at least it would be but a foot is very generous to the depth of my knowledge and a mile is delusional considering the limited scope of languages and tools I am familiar with. However, the sentiment expressed in this section still holds: “You learn only enough about any tool to get today’s job done”. I’m ‘you’. It is not for a lack of interest, at least not in all the subjects we have covered, that I do not go very deep into them – it’s exclusively a matter of time and mental resources. I have found that I have only had the time and energy to cover a subject as much as it takes to complete the require work or project associated it.

An example that comes to mind was last semester when working on both a REST API and Angular web front end – and by working on, I mean learning frustratedly as quickly as possible while working with both for the first time independently. There felt like so little time that I had to at one point neglect the JDBC features built into the Spring Initializer because I simply did not have the time to dig through the documentation. I had to instead use a less efficient and redundant method I knew well. Additionally, on the front-end side, I was able to brute force a lot of scalability because it was easier to use the limited knowledge I had to write ngOnInit and onResize methods to handle window sizing; as opposed to learning built in scalability tools or utilizing CSS more effectively.

To learn these methods would have taken a considerable amount of time that I simply did not have. Luckily this semester the pace at which the site is being built is much more manageable, as is the distribution of work amongst four people. So, with this time I hope to gain a better understanding of the tools and techniques I wish to utilize, before I do so. The pattern suggests writing a blog post, unfortunately this one does not fit that prompt. Speaking of which, I find the idea of going back to read a technological paper from 1976 to be a massive waste of time – but that’s just me. Regardless, and as always, I will seek a more reasonable middle ground between the pattern and what I find effective.

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.

Practice, Practice, Practice: No, not that Dave Thomas

While this pattern is excellent advice, as the title suggests, I could not help but get distracted by the quotes and advice offered by Dave Thomas. Of course, it was nothing substantive that he was saying just that I could not get the Wendy’s founder, also Dave Thomas, out of my head. As for the actual substance of this particular section, it falls into the category of things I am trying to do more consistently in my academic life. Despite being kind of nerdy romanticized, and potentially misapplied, karate jargon; it is effective enough in conveying the idea of lessons, or more accurately patterns, that should be practiced often. Obviously, the linchpin of these lessons is that they are done in private where you can fail gracefully, a common concept in many of these patterns.

Regarding how I apply these patterns, I use a site called codewars where these exercises are also called kata but are done in a web IDE and can be checked for functionality within seconds. As well, all the solutions done by users can be searched, so one can “compare notes” with other users and see what, often insanely truncated, solutions others reached. This fulfills the dojo aspect of these coding exercises as well. If ever you were looking to apply a pattern most directly, this is it – and I hope other students will use this resource. While I don’t believe the site allows users to create their own kata like the pattern says, they do have a suggestion section in the forums. After long hours of honing your skills you could dream something up to really test yourself and others.

This pattern is related to a favorite of mind, Breakable Toys; and not unreasonably so, many of these exercise are incredibly difficult and I have found myself dropping them into my own IDE to finish off at my own pace apart from the web IDE. As mentioned previously, the school and work schedule I maintain makes it a little difficult to keep up with these exercises, or completely them consistently enough. However, I believe that have read this pattern, being set to graduate, and barreling towards my graduation and subsequent career, I do not want to neglect any practice I can get.

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.

Use the Source: how to numb your mind faster than a lobotomy

Perhaps it’s just naturally a trait of mine, a coincidence growing up, or perhaps I more broadly reflect societies supposedly shrinking attention span; regardless of the cause, I have very little patience for reading documentation. Instead, I often like to open a sample project, usually the placeholder created by default, and see what happens when changing things around, or how information is passed between files. As such, I oftentimes find roundabout ways of completing tasks in a new language or framework. This results in less than ideal code, even if functioning, that does not follow best practice or any convention the language/framework may have. So therefore, the “Use the Source” spoke to a weakness I have in software development.

It states that one should choose a complex, and necessarily open source, project in the language you are hoping to learn to fork and pore over. In doing so, one can internalize as many of the lessons this code may have to teach, the ways experts write in this language, the “tricks of the trade” if you will; and, as a result, be inspired to apply these concepts in ones own project. This unfortunately, sounds terribly boring. It’s hard enough for me, and many other students I know, to pick apart our own code only months after writing it. I can’t imagine trying to parse years of work by developers with an incredible knowledge of their chosen language. This seems like a recipe for frustration. I could easily see a student not unlike myself throwing themselves at a new language in this fashion and coming away discouraged and maybe even completely overwhelmed; to the point where they may shy away from learning that language at all.

Instead, I would propose a healthier middle ground. I find that in messing with the code you can find little victories where your exploration paid off – victories that, for myself at least, keep me motivated. However, as mentioned previously, learning completely on ones own may waste valuable time and internalize bad or inefficient habits. As such, I think one should push their abilities as far as they can manage, then seek guidance from communities online. There exist thousands of YouTube tutorials and stack overflow threads where more than one solution is reached to nearly every problem; so, unlike the open source project, you can pick a solution that has a logic you understand best and can implement. I may have no patience to dig through years of documentation, but I don’t lack the patience to instead experiment and ultimately learn the language/framework.

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.

Kindred Spirits: Programming inspired by Anne of Green Gables

When reading the kindred spirits apprenticeship pattern, I was immediately reminded of my first real programming class, CS140, wherein I met some of the friendly faces I would spend the next two years becoming a programmer with. A few of these faces were a part of my group in that class’s lab and with them we challenged each other in the subject and helped fill each other’s blind spots. While this is hardly unique, I’m sure, it exemplifies what the pattern is all about: finding peers who you can learn and grow with. Now with those two years nearly behind us and the end (of our education) is in sight, those same friends have been amazing resources.

As new learners, we tend to go in all different directions, not favoring any set method because we have yet to find the path of least resistance or best practices. Subsequently, we create puzzles pieces with our bits of knowledge that we all can combine to get a clear picture of a language, framework, et cetera. I have found as well, that what was often very useful was the ability to politely disagree – read: bicker like an old couple – with your peer and push back and forth on each other to really challenge one’s knowledge or understanding of something. It was through this back and forth that many of the solutions we were so desperately searching for came about; which is something the pattern even addresses, stating that it is imperative to avoid group think and challenge each other.

I remember distinctly have an erratic mass of code segments and illustrations of a particular data structure, the exact one I cannot remember, all over the board in the Science and Technology center study rooms. Data Structures, our major’s trial by fire, has crushed fledgling programmers of far greater skill than me. I can say with no doubt, that had it not been for these brain-storming sessions I would not have passed that class or even completely the projects thoroughly in the way that I eventually did. As I look forward to internships and even jobs after graduation, I hope to keep those around me who I have learned so much from and find new kindred spirits to take on this next chapter of my programming career.

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.

Craft Over Art: or how I learned to stop worrying and love my ugly UI

As I mentioned last week, I have a tendency to try to make products out of projects; meaning I can’t just have something to tinker with for fun, it needs to essentially be a rough draft for the actual project I have to work on. In the same vein, I have another hang-up on wanting things to be clean and pretty to start. Now, of course, one should strive for well formatted code following best practices, but specifically for those projects with a user interface I try to go straight to a finished product from the start. As a result, the Craft Over Art Pattern was illuminating, bringing into focus where my priorities should lie especially in contrast to where they are currently.

In sum, this pattern emphasizes that you have been charged with creating a functioning product, not necessarily a pretty one. The line, “the things we build for customers can be beautiful, but must be useful” says it all. I realize in constantly polishing a project before its feature complete, I end up throwing away a lot of work spent on “dolling up” features or elements of the user interface that may change or not even be used. I even caught myself making the same mistake even on a personal project using a different web application language, where I did not even attempt to make any forms or methods that communicated to the backend, instead spending time adding libraries for user interface elements that look nice and animate well. While there is certainly a place for those things, this pattern helps one understand that is when you have all of the parts of your application finalized.

I should have learned this lesson last semester with my final project. I spent so much time fiddling with the color palette and page animations, that the content on those pages was barren, or poorly formatted. It is nice, I think, that my webpage looks and animates nicely, but when pages break upon reloading then it hardly matters. If there is constantly some expectation of failure with a project, then the font you choose is hardly relevant. I think that is what this pattern helped me realize most about this weakness of mine; utility is the most important aspect of software, everything else is so much fluff.

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.

Breakable Joys: what I was missing in my breakable toys

As I picked through the list of Apprenticeship Patterns one of the earlier ones jumped out to me, as it seemed fairly obvious from the name what it was. Upon reading the description I was correct in this assumption and further I had experience with this particular pattern – even if outside of an apprenticeship. That description being a “toy system that [is] similar in toolset, but not in scope to the systems you build at work”. If you were to insert “school” instead of “work”, then I have built breakable toys for the same reason the book describes: to try and fail in private so that your successes can be applied to a real project using the same technologies, but your failures do not come at the expense of said project.

I have a sense already that many of the patterns I pick this semester will be those that I either have experience with or involve skills I feel insecure about. This being a pattern I feel familiar with I hoped to see if I was applying it correctly, and I wasn’t, at least not completely. First, the book stresses that a breakable toy should be like any real toy, fun. I think this is at least one hang up I have had with my own toys is that I try too hard to make them into potentially repurposable that I can use in whatever project I am training for. Instead, I think moving forward I will try first to make something fun, but overengineer it like the book says, such that I can gain as much experience possible from some silly little program.

Additionally, the book mentions making a little wiki as your toy, and this I had never thought of. Initially, I had read this as meaning thoroughly documenting the toy you are building. It makes perfect sense and follows logically one of the best points that has been made to me about learning, which is that the best way to do so is to teach. However, upon subsequent readings I realized they meant developing a wiki with your selected tools. While this certainly would help foster an understanding of yours selected tools, it would clash with the previous goal of being fun, at least in my mind. Instead, despite it being a misunderstanding, I think much could be gained from documenting one’s progress on a breakable toy. Considering I have a spike project to work on currently, I think I will apply these lessons as I begin.

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.

A series of relatively unconnected thoughts about the Apprenticeship Patterns readings

This blog contains mostly random thoughts as I did the reading. Nearly each paragraph is a new thought, but they all build to a whole that is effective strategies I hope to adopt or observations about the way the contents relate to my current place in school and work. Please take note as you read this.

I find it interesting that not only did they take the time to address what you should expect to do as an apprentice, but in outlining how your responsibilities change as a journeyman and eventually master they set you up for what you should expect from your mentors and what to strive for as a mentor. They do make a point of saying it is not their intention to write this book to make effective mentors, but I think despite their protestations it does provide a decent lens for the breadth of experiences, however brief their descriptions may be. While I may still be hardly able to envision my life as an apprentice let alone something higher, I hope to remember at least some of these lessons.

As well, one portion stood out to me very specifically as in the process of writing internship applications I had a cover letter I was very confident in, but realized that I could come off as too confident in it and had not emphasized my willingness to learn and accept new techniques. As a result, I will be going back to revise that letter again.

Unsurprisingly, much of these introductions is spent telling you to get out of your comfort zone for a deeper learning experience, but this should be understood innately, so it feels redundant. However, one good idea was to pick up a lesser documented language and try to write the documentation on your own. You could even do this exercise with an already well-established language to solidify your knowledge of it. In fact, more than just languages this is a great idea for any subject, as the old adage goes: “the best way to learn is to teach”. I have found for myself that tutoring a class while here at school was an amazing refresher for the material that I had forgotten since I had taken it so long ago and I picked up new knowledge that I had missed previously.

One thing that did confuse me a little was these chapter’s seeming insistence on remaining a developer rather than moving on to a leadership position or some other “higher ranking” position. Or rather, the utility of this book to those who wish to remain in software development, which makes a little more sense. With the mention of difficulty in keeping or finding good developers, despite a deluge of mediocre ones, made me worried about proving I am worth hiring or having a team that is uninvested in the work or does not possess anything close to mastery over it.

I was particularly struck by the quote at the beginning of Chapter 6, as I have a lot of trouble finding personal motivation without the structure and reward of grading found in school. Therefore, the advice of keeping a reading list is very pertinent to me as perhaps one way of building my own internal mechanisms for remaining engaged in my field and becoming self-motivated.

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.