Category Archives: Writing

Apprenticeship Patterns – What I Learned

For my capstone course this semester, I was assigned to read and review a book from authors Dave Hoover and Adewale Oshineye, known as Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by our professor, Karl Wurst. The intention of reading this was to ready and prepare myself for the challenge within this course, specifically about my skills in a field and how to cultivate and grow within said field, or “craft” as the book puts it.

To me, the most interesting part about this reading is how they attributed software development to craftsmanship. When I first thought about it initially when it discusses it in the first chapter, I immediately went “yeah that makes sense” but upon reading further and it digging at specific concepts like “what is craft” and “what makes an apprentice an apprentice”, it made me think a lot more about what a “craft” really is. Being an art minor, this definition was one that was important to me, as art in it of itself is synonymous to craft. Being able to compare my work when coding things and my work when I physically create artwork was an interesting turn of events and an epiphany I wasn’t expecting when dropping into this book. The individual breakdowns of each part of what makes craftsmanship what it is was very impressive and made me able to stand in the shoes of the authors.

When reading, I also felt a bit called out on bad habits that I definitely do on a daily basis. For example, the story told in Chapter 2’s introduction, discussing a cup already full, it reminded me of how I tend to get carried away when it comes to discussing what I know and want to share. This comes at, unfortunately, a disregard for the new information I would be trying to learn, much like how the analogy of the story goes. Another thing I felt was important and reflected on my own actions was Chapter 5, discussing how it is important to not use the internet as your only source of learning and information. Initially, I was quick to disagree with this point, as I do NOT enjoy reading in the first place (a.e. look at how long it took me to write this up) but then I sat down and realized that was another bad habit kicking in, as well as my ADHD. While yes, its true that written works contain many important informations regarding to one’s craft, especially in software development, one must also remember that “reading” isn’t the only way to absorb this information, you could find an audio transcript, as an example. Thus did I realize that this point was actually one that was really strong and heavily agreed with.

Overall, I feel further reading may be necessary for me, as this has changed a lot about the way I am thinking not only about this class and working on a development team, but also about myself and habits that I could be working on and improving. If you also would like to read the book, it is hosted here, for free: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06.html

Until next time! (Which is, soon, because Ill be writing up another post right after this, haha)

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Test Yourself Before You Wreck Yourself

CS SERIES (14)Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.

Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.

The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.

What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.

One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.

Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.


Article: http://www.softwaretestingmagazine.com/knowledge/approval-testing/

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