A quick but necessary recap on Boundary and Equivalence Class Testing

This week in class we covered what is Boundary Value Testing/Analysis and what is Equivalence Class Testing/Partitions and what are each of its subclasses.

After finishing the activities in class, I feel like the assignment really did a good job teaching us how to do each type of testing but it does not really explain why we should use each of these testing techniques.

What is Boundary Value Analysis and Equivalence Partitioning?

While I think knowing how to conduct each of these testing techniques is important, the essentialist within me cannot stop thinking about the logic or the origin of these techniques. In this blog post, Mr. Eriksson gives a recap of the topics we covered in class and gives a couple short and easy to understand examples to work through. Also in this post, he gives a short explanation of the main ideas of each technique. The reason why I chose this specific blog post wasn’t because I wanted to introduce new information about the topic but because I wanted the topic a quick once-over and really nail down the topic. This blog post gives a really nice summary about what we covered in class and serves really nicely in filling the blanks in our understanding of the topic.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen 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.

Breakable Toys: Improvement Through Experimentation

Photo by Polesie Toys on Pexels.com

In software development/programming related projects, much of the time making a mistake can feel like the end of the world, or at the very least a major inconvenience to everyone else around you. Yet by failing we often tend to learn more than we do by succeeding, since success seems to come most often from familiar and comfortable subjects or ideas which we might already have preexisting experience working with.

This is why I find the Breakable Toys pattern, described in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman as a way to work within a “safe space for failure” to be an interesting and largely relevant idea in the context of software development. The pattern describes the practice of building “breakable toys”, these being smaller, self-contained projects making use of the same toolsets you might use during professional or otherwise high-stakes development.

The pattern suggest building simple games or programs as a way of learning a new programming language. Building simple games such as Tetris or Checkers in order to get to grips with the language seems like it would be a fun experience, I think game development is an extremely interesting field, and focusing on your interests is an effective way to speed up familiarization with a new language by making use of something fun and engaging as a sort of “practice project”.

I have always enjoyed the idea of self-building software; the idea of having a usable program or application which is self-built is appealing. Similar to how a woodworker might feel sitting in a rocking-chair hand built from their own shop, the idea of building something which is demonstrably useful, or even just as an experiment to see what happens is a great opportunity to express creativity and explore a new topic. The added benefit of experience and potential to learn something new makes it a worthwhile experience in my opinion.

In terms of putting this particular pattern into practice, my first course of action would most definitely be to make a few simple games and applications, an image editing program or simple web browser seem like reasonable small-scale projects to work on as a learning experience.

Building something out of personal interest can make learning the required skillset a relatively painless experience, as by the end of it you will likely have something which you can be proud of and enjoy for many years to come.

Text Referenced: https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

While it is a likely contender for the most self-evident of the Apprenticeship patterns, I have found “Practice, Practice, Practice” to be the most inspiring thus far. The context that the particular pattern describes is a situation I found myself in quite frequently in my previous undergrad; there is a need to get better at your craft, develop your skills but it feels as though you’re constantly in performance mode. While there may be some merit to having a mirror by my side checking my posture and a metronome in my ears pushing me to increase my words per minute, it’s far more likely that the deliberate practice the authors allude to has more to do with firing the synapses dedicated to problem solving rather than strengthening the myelin sheathes governing my ability to put a stick to the head of a drum.

I enjoyed the reference to K. Anders Ericsson’s research on the matter but was predictably bummed out when the authors pointed out that reality is not in fact perfect and that we, as apprentices, do not have a readily available pool of benevolent masters who will take us under their wing. As someone who was raised primarily to throw a baseball and complete schoolwork assignments put in front of me, the idea of mastery never crossed my mind; talent was something I was born without and that my success in life would largely have more to do with my ability to follow orders and do necessary tasks linearly than anything else. As a latecomer to this world of musical craftsmanship I lacked not only the pedigree but also the prior mentorships that allowed my peers to sail through and seek out additional opportunities. I recognize in hindsight the benefits of a mentorship but also know that with mindful practice I was able to catch up to my peers and even succeed where some of them failed.

My ability to successfully achieve competency happened not because of strong mentorships (which I never received) but rather because of slow, concentrated practice much like the katas of the dojos mentioned. My favorite prescription presented by this article is at the “Action” section, to carve out some additional time to do mindful practice, as practice makes permanent.  I have several exercises in mind and once I finish a few more homework assignments I look forward to practicing!

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 1, a Retrospective

Mired by a litany of confusion and growing pains our group managed to come out on top. Actually, that is a boldfaced lie; our group disbanded but I assure you these two things have little to do with each other! All joking aside, our plan at the outset was to learn about utilizing the information access management software known as Keycloak. As it was our first sprint working with completely unfamiliar technologies, the sensible thing seemed to be to read the darn manual and document our findings. While this worked for reinforcing our individual assigned topic from the official documentation, I have to wonder if it really helped us deliver a tangible product or just slowed us down. To elaborate, it seems as though we read a lot about the technical aspects of Keycloak but at the end of the day there was little to analyze and report other than that the documentation seemed to be thorough. In hindsight, I believe the better approach would have been to work together as a group and walk through the configuration process, documenting the whole thing. Moreover, we should have raised questions about the size and scope of user volume and based on those factors decided on a configuration (cluster versus standalone comes to mind) to attempt. While configuring Keycloak and WildFly on our local machines certainly gave us insight, we would have discovered that learning about WildFly and its subsequent installation may have been completely pointless depending on which configuration we decide on going forward.

Given our approach I found that the best work was done when we were collaborating together. I touched on this concept earlier when I was describing how – with the benefit of hindsight – our group ought to have approached the assignment, but synchronous communication and action taken towards configuration yielded drastically better results. It was during these sessions where the team was able to best overcome technical hurdles (such as versions of Docker mismatching) or discover some steps might be superfluous (such as installing and configuring WildFly when not using a local instance of Keycloak). It pains me to say it but it seems as though, of the work we got done, a very small portion of it ended up being useful and that our approach seemed to be driven more by how we could fit our work into the agile framework and not how the agile framework could best help us implement our work. This isn’t to say the framework is of no value or inherently a hindrance, nor is it an indictment of any particular person, but it seems as though our group was not able to mesh well with the framework to get results.

Individual improvements can mostly be derived from the same tired critiques in the vein of rugged individualism whereby things such as losing power, health problems, email harassment must not dampen one’s spirit and certainly, above all else, not their work ethic. Perhaps if I had instead made a measured effort to calculate how many hours of autodidacticism I could throw out so that I may stay in the low C range (as opposed to the upper range) of a non-major class, I may have been able to find more time to commit to exploring Keycloak. Is it unprofessional for a student like me to complain on an assignment for my personal blog? Perhaps. I would argue it’s at least as unprofessional for a teacher to underperform in their profession and that students should have to internalize that as an individual failing.

Links to work done on our team’s wiki:

This wiki entry is the reference page I accidentally wrote on the Authorization Services.

This wiki entry is the reference page I created for WildFly.

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 1 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/14

This was easily accomplished by everyone. This was learning the issue board.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/1

This was us choosing a Scrum master. We decided on Tim Drevitch.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/25

This was our review of the LibreFoodPantry website which was to get an idea of LFP.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/24

This was creating the requirements for the GuestInfo EventSystem, in which I linked resources and described the requirements.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/9

This was the most time-intensive task. I linked multiple tutorials for Vue.js, all of which I completed. This encompassed most of the first two weeks of the sprint for me.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/17

This is the repository I made which contains all of the simple examples we created for small Vue.js, Express, and MongoDB applications to pull from.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/26

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/13

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/11

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/12

These 3 activities are encompassed in the GuestInfoSystem section of Thea’s Pantry. There is a repository for frontend and backend work. It has basic files for each which is taken from the WNE example.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/15

This is created a sample Vue.js project, which is on the example work repository.

            Overall, I think we worked quite well as a group, and I would attribute a good deal of it to how well our sprint planning went. We were thorough in going through topics which we felt we needed to cover and created individual cards for everything so that all of our tasks were tangible. Furthermore, we were fair in our division of labor and honesty in what we wanted to do while still taking on enough responsibility as individuals to support the team as a whole. What worked well towards the end of the sprint was also when we focused on what we hadn’t yet finished and allotted the work evenly. Not only this, but we had also made enough progress that I found it to be helpful to have a sort of progress report session in class. We were going through with our Scrum meetings daily, but it was more in-depth, and we were able to articulate what we had done and where our progress was taking us. This was very helpful and perhaps we could incorporate this into our Scrum meetings, allowing us to have a better stream of communication.

            There weren’t many things that didn’t go well for us, but a few include some lacking communication at times and a lack of due dates. As I articulated previously, I was only able to notice any lacking communication when we did communicate better. It wasn’t that our communication was impeding our progress, but it definitely helped to have a clearer picture of the project as a whole when each of us was clearer about our individual progress. As far as a lack of due dates, we became a little rushed towards the end of the sprint since we spent a little too much time completing our learning tasks. If we set limits on these tasks, because they were more open ended, we could have gotten some of our more rushed late sprint activities done faster.

            As far as changes to be made as a team, I would focus on making the changes I stated previously. To get better communication, we should make better use of the cards on the GitLab issue board. Each card should have documentation of information learned and progress made it on it. This makes it much easier for everyone to read the cards instead of having to check Discord or wait for the in-class meetings. Also, we should start putting due dates on the cards for our own sake. This would keep us on track better.

            Individually, I should plan out my time more. I was feeling lost with Vue.js so I spent a lot of time on it. I got into stuff that, later on into the sprint, I found out that I didn’t even need. I need to be better at setting due dates and creating more incremental tasks. I took a couple longer tasks and rather than breaking them down, would try to accomplish a couple things at once which could have been subdivided. This, along with better documentation on the GitLab cards, should put me in a better spot for success in the next sprint.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #4

The fourth pattern that I plan on discussing is titled “expose your ignorance” in the book. The reason I want to choose this pattern to learn next is because I believe that it relates to me one hundred percent of the time I am in school. The idea behind this pattern is that if you do not speak up when you are lost, you will inevitably hurt your learning process. Many people, including myself, get into the habit of not vocalizing questions and concerns for fear of being disruptive, time-wasting, and possibly getting even more confused. It is very easy to simply keep your head down and struggle through a course or project without getting everything you need out of it. Basically, in situations where you do not know what you are doing, protecting your pride is often a bad solution, and exposing your ignorance is likely your best option. The book does a great job explaining why this is and it has good examples of times where it is a needed apprenticeship pattern to pick up. Even in jobs, it is important to expose your ignorance. The easiest way is by asking questions. Not only will it help you learn faster and more, but it will also ensure that you are doing everything right and in the way that your employer expects you to get your work done. The book has other solutions for this as well. In fact, the main action that it tells you to carry out is to “write down a list of five things you really don’t understand about your work. Put that list where others can see it. Then get in the habit of refreshing this list as your work changes.” Personally, I feel like in my years of schooling I have not reached out enough with questions for fear that I would look like I do not know what I am doing. It is not going to get any easier for me when I try to get real jobs, so it is important for me to learn to put my ego aside and expose my ignorance in a way that will allow me to learn and get better everyday.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Record What You Learn – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Record What You Learn” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is design towards people who end up learning the same lessons over and over again or going through the same experiences or failures but can never get the details or reasons to stick.

The solution suggested is to create a blog, notebook, or wiki that you can treat as a journal and record important things that you learn. This is not to write down and forget about. Throughout your career you should return to this journal to review it and make new connections in your memory. When reviewing you should update what is written as more knowledge and experience is accumulated over time. The authors even suggest creating two blogs, one a public record and one a private. This allows you to share the lessons you have learned and also get feedback on what you have written with the public record and be able to be brutally honest with yourself in the private record. Internal and external feedback allows you to have an honest and accurate self-assessment. The main goal of this pattern is to keep a journal of your path to mastery so that you can reflect on and learn in the future.

I found this particular apprenticeship pattern interesting because this morning I was thinking about starting a notebook in which I can keep any important lessons as well as important details. This way I would be able to look back on it frequently and grow as a developer. This could include important concepts, design patterns or failures that I can learn from as I move forward. This book has provided a useful structure in which I can follow and also has inspired me to follow through with it since I have said I was going to do it a few times already but never have. Also, it has given the idea of two journals in which one can be private and one public. Maybe also different journals for different topics such as one for design patterns, one for lessons learned, one for important topics, etc.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Your First Language

I always feel that if you are better at the first language, the easier it is to learn the next one.

I learned Java in my sophomore year, and then I went to learn C, which felt easy. Because the logic of computer language is interchangeable. For example, if you learn English well, you will find some similarities between French and Spanish. Although French and Spanish maybe your second language, you will learn them much faster than non-proficient English learners. I think this applies to computer language learning as well.

Each language gives you the opportunity to use different patterns to solve problems. In the process of moving beyond your first language, you should look for opportunities to learn languages that approach problems in very different ways. Apprentices who are comfortable with object-oriented languages should explore Functional’s programming language. Students of dynamic typing should delve into static typing. Apprentices comfortable with server-side programming should take a look at user interface design.

You should not be “married” to any particular technology but should have a broad enough technical background and experience base to be able to choose the right solution for a particular situation.

Many people say Java is good because it is suitable for many kinds of software programming. Some people also say that C++ is good because its language is more advanced than Java; there are also people who have learned that learning C++ to learn Java or very simple. I personally hate to talk about what language is best, every use situation has a language that works best for it. Or if you have learned your first language well, mastering it is also a good option. But there are certain situations where C really has the best solution than Java, so we write our software in C. At this point, there is no need to stubbornly think that I am good at Java and I have to use the language I am good at to solve this problem. 

The spirit of craftsmanship is that you strive for the best in what you are good at, but in certain situations, we can’t stick to the rules. Modern society is a utilitarian society, we need to maintain the spirit of artisans while learning to adapt to the society.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Your First Language

I always feel that if you are better at the first language, the easier it is to learn the next one.

I learned Java in my sophomore year, and then I went to learn C, which felt easy. Because the logic of computer language is interchangeable. For example, if you learn English well, you will find some similarities between French and Spanish. Although French and Spanish maybe your second language, you will learn them much faster than non-proficient English learners. I think this applies to computer language learning as well.

Each language gives you the opportunity to use different patterns to solve problems. In the process of moving beyond your first language, you should look for opportunities to learn languages that approach problems in very different ways. Apprentices who are comfortable with object-oriented languages should explore Functional’s programming language. Students of dynamic typing should delve into static typing. Apprentices comfortable with server-side programming should take a look at user interface design.

You should not be “married” to any particular technology but should have a broad enough technical background and experience base to be able to choose the right solution for a particular situation.

Many people say Java is good because it is suitable for many kinds of software programming. Some people also say that C++ is good because its language is more advanced than Java; there are also people who have learned that learning C++ to learn Java or very simple. I personally hate to talk about what language is best, every use situation has a language that works best for it. Or if you have learned your first language well, mastering it is also a good option. But there are certain situations where C really has the best solution than Java, so we write our software in C. At this point, there is no need to stubbornly think that I am good at Java and I have to use the language I am good at to solve this problem. 

The spirit of craftsmanship is that you strive for the best in what you are good at, but in certain situations, we can’t stick to the rules. Modern society is a utilitarian society, we need to maintain the spirit of artisans while learning to adapt to the society.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.