Category Archives: Software Dev

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.

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.

The Deep End: Taking off my floaters

The definition of many of the apprenticeship patterns in the book are all in their title, being fairly obvious or sharing language used in idioms or other expressions. However, despite this, our authors usually find a way to expand on them for at least a page or two – most often by sharing a relevant story. Which is why I was shocked at how brief this particular pattern was, just a handful of paragraphs and another for our story. The brevity of pattern however did not lessen its impact on me, and I have come away with a renewed confidence. As someone who needs structure in order to work effectively, I imagine the deep end would involve a great deal of work and specifically responsibility – which I respond to quite well also.

I had already determined to seek out an internship or entry level position outside of my home state. Further, I wanted to join a company where I, of course, could be actually hired but one that would truly test the limits of my skills. Ideally, I would want it to be an internship though, cause as much as I want to make this change in scenery, I’m still hesitant to get stuck someplace I’m miserable. I think the true test will not just be getting a position away from home but finding a place for myself in that new place and maybe even gaining the confidence to stay and accept a job at the company – in the case of an internship.

I did find one internship that states that they will make no “intern-work” and one should be expected to work as a peer with the rest of their fellow employees; and on a massively used and well-known mobile application no less. I jumped at the chance to apply for this position, and I am incredibly hopeful I get it, as it is the perfect storm of conditions I am hoping for. Enrique’s story is still a little too dramatic for me to imagine emulating, but I hope if the opportunity to work in another country even presents itself, I will have the confidence to take it.

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.

Libre Food Pantry Impressions

Upon reading the Libre Food Pantry landing page I was very pleased with the vision and mission sections, as they express the better angels of a computer scientist’s nature. Often times, I get very discouraged by the field as it seems like while many people may just not care, so many more simply want to create and solve problems – but these creations are used to exploit other workers, or invade people’s privacy. “Big Tech”, like all things under capital, takes the creative energy of its workers and uses it to enrich itself at the cost of human dignity, and oftentimes, lives. In a just society, we would value much more the contributions of these open source contributors than the efforts made to perpetuate war and mass surveillance.

…or at least that what I would say BUT if I decided to go to any other tab from the overview and then back, the contents wouldn’t load correctly. Rest assured I will be supporting a bug report.

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.

Beginning of the End: Software Development Capstone

This feed will contain blogs for my aforementioned Software Dev Capstone course, as it did for the courses I have taken previously. I’m excited to share my experiences in class as well as reflections on the reading materials this spring semester.

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.