Author Archives: cboylecsblog

The Final Sprint Retrospective

The most headway came when multiple sets of eyes were on issues. This first proved to be true when the IAM System Community of Practice was working together to establish the logout functionality and to ensure that the user sessions properly expired to prevent unauthorized modification of the database.

This also rang true when Tim Drevitch and myself were finally able to free up time and address out standing issues. As per my comment here, and his comment here, we were able to spin up a docker instance of a database and pretty quickly figure out how to start adding to the database just shy of setting up the specific documents we needed to store individual users/entries. It was three hours of troubleshooting together, researching different aspects, and then explaining them back to each other over voice chat, but we made substantial head way where there was otherwise none (despite it not being a card assigned to either of us).

While there are obvious constraints to having green undergraduate students try to develop software on a very part-time basis, it became very obvious that not all the teams were created equal. When I would meet with the IAM community of practice we would discuss what our groupmates needed of us and I would routinely report back to them that my group had made no mention of any code, functions, methods, etc that they needed from me nor intended to integrate any time soon, much to their surprise. This signals to me an overall unfamiliarity with the tech stack which is not a judgment on them, they’re doing their best given the limited amount of time in the day and the craziness of navigating online learning. That being said it was often the bottleneck within team discussions.

What was within teammate control and —seems to be the modus operandi students within the Worcester State University Computer Science Program— very unacceptable was the lack of communication. I would consistently ask teammates what they were working on and how it was going only to get no response. In fact, there was one teammate who I had never heard talk until three weeks until working with them; it’s anyone’s guess as to why, but my experience with my fellow computer science students has been largely marred by radio silence. My biggest change I would have made to the team was to force my teammates to communicate by instead of asking them “what is stopping them” in the standups, ask them “what is something they encountered that they didn’t understand while they were working”.

My personal failings in the last sprint came largely from my pivoting away from schoolwork to build out skills that would help me attain a summer internship as well as applying to said internships. I became more focused on learning the practical skills gained from sites such as Tryhackme.com and studying for the eJPT certification so that I may pursue a career in information with an emphasis in exploit development and malware reverse-engineering. My ability to engage with school work may have declined but it was a necessary sacrifice to (hopefully) make myself a more viable job candidate.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Silent Killers of Quality

Candice Coetzee’s article titled, “Eliminating the Silent Quality Killers in Your Organization” on Software Testing News covers several corners that companies often cut in order to bring their product to market which inevitably created bad organizational habits and setting them back in the long term. These silent killers of course all linked back to the Quality Assurance process and this article signals the necessary steps and organization can take to remediate these failures.

The first failure that the author points out is not having a software Quality Assurance strategy in the first place. She suggests making sure that every facet of your business has QA strategy from project management to development to operations. Another silent killer listed that could be business destroying is skimping on the software architecting process. The author insists that with thorough planning and implementation of things such as regression testing, debugging and logging a lot of the downstream failures will be reduced or virtually eliminated.

We increasingly hear more and more about products attempting to be agile but launching prematurely; Coetzee suggests that “building in some fat” around the QA time window can pay dividends down the road and minimize panel beating and fighting ever-growing fires of customer dissatisfaction with your customer service teams. She describes how these post-launch quality failures may not only be costly to a company’s bottom line but may cause irreparable brand damage. Sounds like a reason to always put quality first!

Read more about the article here!

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Cloudy Future for Mobile Testing?

Eran Kinsbruner’s article at DevOpsOnline.co.uk titled, “Testing Mobile Apps in the Cloud” discusses the recent push, advantage, and necessity of testing mobile applications in the cloud. Prior to the pandemic there was already a struggle to comprehensively test on all of the varieties of existing operating systems. Between unique vendor operating system variants for Android devices (Samsung, LG, Google, etc) and Apple devices (iOS, iPadOS) it was difficult enough to get these devices into the hands of every developer for testing in a single given office but with office spaces being shut down it became even less practical to do physical testing on these systems, queue cloud-based testing.

While there are many benefits to this cloud virtualized testing, the first I found to be the most impactful was the scalability of the operation. Being able to effortlessly spin up thousands of device instances to stress test is far more practical than buying however many of those devices. Not to mention testing the interoperability of varying operating system versions. Rather than having to keep multiple devices with older operating systems or rolling back to test compatibility one can simply boot up an instance with the older version.

Kinsbruner also points out the improvement to team communication and hand offs that come with cloud collaboration. By having a centralized cloud repository, it’s much easier for members in the production, testing or QA teams to observe and monitor program changes in real time using synchronous development environments so they can estimate what their task will be by the time it gets to them. It seems that this remote development and testing in the cloud may just be an integral part of the future of software.

Read the full article here

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

“Sweep the Floor” is perhaps an Apprenticeship Pattern that I’ve seen most closely paralleled in the real world. The pattern proposes that the price of admission onto a team may be that the newly crested member start by doing the unglamorous jobs —hence the title of the pattern—, often this will be things such as differed maintenance or writing reports. This is manyfold: it proves capability, builds trust that you can work independently, allows for controlled and low-stakes contribution to the project, and will free up the more vested members’ time to teach you higher stakes tasks.

As I alluded to, this ritualistic humbling seems to be inevitable in any profession, particularly in what gets oft classified as skilled-work. When I was a mail processing mechanic, the first thing we new recruits were delegated was daily maintenance tasks such as changing rubber belts on a feeder assembly, or changing drive belts that were in the lower tiers of the mail processing machines; the latter considered the most uncomfortable —sometimes downright painful— task to work on. While I don’t suspect that updating documentation or eliminating technical debt will be nearly as dirty as being covered in paper shreddings and ink dust I felt this quote in particular was a very powerful way to bind the metaphor of back to software development:

“These sorts of fringe tasks benefit the team, but they will also benefit you as an apprentice, because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. This experience will serve you well as a journeyman too, because any master who takes you on will understand how valuable it is to have someone to do the unglamorous work. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.”

The authors made sure to mention my primary criticism of this learning style which is what they have called becoming the team’s gopher. If it were not apparent, a quick definition of a gopher is one who has become known to absorb the menial or painful work and thus gets typecast into that roll permanently, condemned to the strictly utility work which creates a lag on your understanding of current developments in the code base and hurt your chances of upward mobility. The authors’ prescription is relentlessly advocate for yourself, Nurture Your Passion, and Unleash Your Enthusiasm.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Draw Your Own Map

The “Draw Your Own Map Pattern” is chiefly about assessing your current role in an organization and looking forward to your next professional endeavor, be it within that organization, or externally. The Problem section explicitly defines the situation such that your current employer does not have the position you’re looking for in your organization. The proposed solution, in summary, is to put careful thought into your future external position and then create a plan with micro steps to get you there; these steps will help keep your sights on the potential position.

The pattern seems to coincide very much with the steps I’ve taken in life. I’ve personally undergone a very windy path to get where I am now and will certainly be considered having an unconventional path in any career I manage to land outside of college. While I don’t always have scheduled periods of reflection in my career, I find that periodically discussing with coworkers what they want to make of their careers inspires them to pursue their goals and also forces me to look inward and re-evaluate if I’m happy with my career at that point.

Perhaps my favorite takeaway from this pattern was the activity provided in the Action section at the bottom. For the unacquainted, the activity requests the reader to make a map of three jobs that could be logically pursued beyond their current one. The authors then insist that the reader do this with the web of three jobs for each of the previous branches and assess if any of these roles would satisfy them. The exercise implores that the branching is done one more time and this final iteration should be roughly representative of your total career prospects. I found that engaging with this exercise left me feeling hopeful and optimistic about my potential career paths —which is to be expected as a student— and would specifically recommend it to others looking to make a change who may be a bit more pessimistic about their prospects. As someone who has hopped careers, the hesitancy to reconsider one’s career comes from a fear of needing to take drastic action but by using this exercise I think those in a similar situation to my own would realize that they’re not as far from their destination as they may seem.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog Post

This second sprint has been a bit better in terms of actionable steps; this was aided greatly by the mock front and back end. The mock allowed us to test configuring a realm to a container locally which was the floor for proof of concept. Unfortunately, the lack of architecture made further progress confusing as I didn’t understand why all images couldn’t be on same container network. After it was determined that the architecture called for further subdivision, it became unclear what microservices should be on which image and/or network. For instance, it was more or less determined that Keycloak should be on its own separate container (presumably with WildFly) but at the beginning of sprint I wrongly believed, based on previous internet searches, that NGINX should be on the same image as Keycloak but this was later discovered to be unnecessary as the mock front end contains NGINX within our system.

On that same note, the task breakdown and codification into issues for the respective boards suffers from an incongruity where ignorance of the matter begets ignorance in the approach and then future work is inaccurately reflected in the process. This isn’t necessarily an issue with the approach as whole but it seems as though, for the past two sprints, this unfamiliarity with the microservices and their implementation into our architecture forced me into a series of micro pivots which quickly evanesced away from the originally declared issues. If the goal of scrum is not to constantly be inundated with creating issue cards, updating them, and closing the now obsolete ones, then perhaps it would behoove us to reconsider the amount of research time necessary or have a much more closely-guided approach to issue construction. If this rapid pivoting away from cards is acceptable (and their grades reflect this) then that’s not particularly bad news for students. However, we have to be honest with ourselves and have the hard conversation that Scrum in this setting does not accurately map to what Behr, et al. would refer to as WIP (work in progress).

The low-hanging fruit of constructive team feedback would be the necessity of more frequent external meetings. It certainly was not for lack of trying; the most charitable reading of the situation was that I found there to be no strong consensus on when the team schedules would align. We also would have benefited from more frequent contact internally. Barring all real-world, unforeseen, obligations that took team members away from us the scattering of the team into groups caused our reviews to be staggered resulting in the loss of two full class periods of collaboration. My prescription for this would be that those who come after us should successfully drill down on establishing a running prototype before splitting off into the other groups.

My individual criticisms to my work flow largely still touch on the externalities I’ve lamented in a prior blog post but, if I must touch on them briefly, they’ve stayed mostly the same. It’s quite apparent that certain teaching staff in the university have struggled to pivot to remote teaching and, if I’m to attribute to ignorance and not malice, they seem to have bequeathed those struggles to their students. To those teachers I would like to remind them that Monday holidays are not a surprise and certainly not an invitation to delegate away your teaching responsibilities because you’re lagging behind curriculum milestones. If these teachers cannot grade in a timely manner, then my deepest sympathies, but please do not complain that the bulk of your students keep getting concepts incorrect and you have to re-grade their assignments and/or assign extra credit to help inflate grades. I’m a commuter student with one semester until graduation so I will stay here at Worcester State; if I was a commuter student with two semesters left, I would have transferred out.

https://gitlab.com/nanuchi/techworld-js-docker-demo-app
When paired with their “Docker Tutorial For Beginners” has been an invaluable resource to teach myself Docker and use continuously as a reference.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The explicit context of this pattern is that you’re a developer on payroll and you have been tasked with successfully delivering an artifact of software to your employer but unfortunately you have not previously developed software with some requisite technology for the project ahead of you. The solution prescribed in this Apprenticeship Pattern is a bold one that leans on previous rapport with your superiors; it insists on radical honesty where one admits that they do not presently know all of the information necessary to deliver on the project and to appeal to their previously established competency and ability to learn new technologies.

What I find most elegant about this approach is not only the ability to tailor current expectations using honesty but also the renewability inherent in this approach:

“In this way, your reputation will be built upon your learning ability rather than what you already know.”

The implication there is that if you stick the landing on delivering the necessary code, you will have created an evergreen approach to setting expectations and earned yourself the reputation of being not somebody who is valued for their finite pool of knowledge but rather their ability to tap into an infinite pool of knowledge. The authors cite Carol Dweck’s work, particularly how the need to appear competent is a mindset (no pun intended) that has proliferated throughout industrialized societies and is hard to break through. They insist that, while this embarrassment may be hard to overcome at first, your peers will have to notice your rapid progress and moreover they may find that by you forcing the issue they may have new realizations about their intelligence; after all people like to solve problems and feel intelligent.

I enjoyed the juxtaposition the authors make between those who become experts as a result of the perhaps not being as inquisitive or less confrontational with their inadequacies and so-called craftsmanship-seekers who become experts just by virtue of interest. While the first group may not be as ambitious or aggressive in their pursuit of knowledge there is no need to disparage this group and I appreciate that the authors did not decide to punch down where many other snobbier tech experts certainly would have.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

A Review of: You Still Don’t Know How to Do Unit Testing (and Your Secret is Safe with Me)

Erik Dietrich’s article “You Still Don’t Know How to Do Unit Testing (And Your Secret is Safe with Me) was an amusing and informative read about what Unit Testing is, what it is isn’t and how the average developer can go from creating incorrect tests to effective, bonafide Unit tests. He leads the article with a remark that, since 2002, he has seen unit testing go from an esoteric skill for quirky developers to something of an industry standard that, as it has been ushered in into popularity, has also pushed some developers into the cracks; this article is for them. Dietrich starts by making several important distinctions on what a unit test is not starting with tests that he describes as being able to “fail when run on a machine without the “proper setup”.” He next brings up a concept which I had not heard of before called “smoke testing” which seems to be testing cases that cover the most essential parts of a program to determine if it’s launch ready. Whatever the case, this is certainly not unit testing. Lastly Dietrich states that a unit test, under no circumstance, should be something that works your system from end to end. He gives the example of a user opening a terminal and testing output; he classifies this as an end-to-end test. In the author’s words the concept of Unit Testing is by most accounts circular but with some good reason (to transcend programming language). The example given was programming methods in C# and their respective test methods. The first example is testing with an “add” method from a calculator that checks to see if the arguments passed successfully add or, if they do not, that they properly throw an error; for this case it is the Invalid Operation Exception. For more practical detail check out the original article here.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Reflect As You Work

The “Reflect As You Work” pattern in Apprenticeship Patterns has much to do with developing a methodical and concrete approach to introspection within one’s software development career on both a macro and micro level. On the micro level, Hoover and Oshineye make the recommendation to consider your day-to-day practices when programming and to take notes on the practices of more senior team members to see what makes them so effective. On a macro level they describe what amounts to a hotwash or after-action review of the operation (to borrow government idioms) but caveat that a certain level of trust by management is necessary for the approach detailed and that may not always be the case.

One of the exercises in this Apprenticeship Pattern I finally found to have immediate utility in my life is accounting for the things that I do or do not do adequately in regards to programming. The exercise as described by the authors:

“If there is something particularly painful or pleasant about your current work, ask yourself how it got that way, and if things are negative, how can they be improved? The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways.”

Like many of the Apprenticeship Patterns and the exercises contained within them, much of the immediate implementation is lost due to the apprenticeship patterns pre-supposing that the reader is currently writing a meaningful amount of code to have established a personal pattern. Despite that fact, I’m able to use this exercise to dissect my personal habits prior to entering college which were things such as poor commenting, not adopting to the bracketing style of the language, not using tests, not using git, and CI/CD. What was pleasant about my past work was my consistent use of the Microsoft Visual Studio IDE to debug and step through my programs. Unfortunately, I’ve been able to write substantially less code since I made the choice to return to college but look forward to using the exercises that I learned about in this apprenticeship pattern to maximize the value in learning from my mistakes.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Test Precisely and Concretely: A Review

While much of the content was beyond my comprehension, I found Kevlin Henney’s article “Test Precisely and Concretely” article at Medium.com to be elucidating and enjoyable. Kevlin is known for his efficacious brevity in software and so it should come as no surprise that this translates to his writing. He comes right out of the gate with a strong opening sentence:

“It is important to test for the desired, essential behavior of a unit of code, rather than for the incidental behavior of its particular implementation.”

– Kevlin Henney @ https://medium.com/analytics-vidhya/test-precisely-and-concretely-810a83f6309a

While the first half of the quote describes the obvious end result that we as programmers are aiming to achieve, our desire to do write effective tests certainly doesn’t preclude us from making the mistake of the latter. There may be diminishing returns on the profundity of this statement but, as an amateur programmer who has only just begun to learn proper software testing, I’ve found myself writing software tests that give true outcomes but do not necessarily verify that the program itself performs accurate and verifiable calculations. For instance, when I was creating additional instances of an object in a recent assignment I was testing to see if additional objects were consecutively constructed in the sense that memory was allocated for it but I was not properly verifying that the objects upon their creation were given consecutive, uniquely identifying numbers which is where the real meaning of its creation lay. Simply put, it was the software testing equivalent of begging the question.

From my understanding, Kevlin’s prescription to the aforementioned issue is to understand that the conditions which are necessary for your test to pass are not always sufficient for their real use cases and born from this is the realization that programmers ought to more carefully examine the literal meanings of the postconditions they’re testing for. Furthermore, he states an accurate condition does not make for a good test, a “good test should be comprehensible and simple enough that you can readily see that it is correct.” In the spirit of the article, and perhaps even Kevlin himself, I will avoid verbosity and recommend that everyone check out what makes for a good software test here.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.