Author Archives: John Pacheco

Apprenticeship Pattern Review 1: Expose Your Ignorance

This blog is the first in a series of posts that will be covering software craftsmanship patterns I find compelling from Apprenticeship Patterns by Oshineye, Hoover. With these posts I aim to summarize the pattern and explain its relevance to me and software development as a whole.

In short, the “Expose Your Ignorance” pattern is aimed at dealing with a fundamental issue with people living in industrialized society. Software developers are under extreme pressure from managers and team members to know how to use many technologies. Especially in the case where those relying on you are under the impression that you understand how to do something, it can be extremely hard to make it clear that you actually don’t know how to do that something yet. Acknowledging the fact that there is a push to reassure everyone that you know everything and going directly against this is essential to learning as quickly as possible. This is the gist of “exposing your ignorance”.

I constantly feel the pressure to reassure my colleagues that I understand whatever it is we are talking about. I’ve always felt like doing otherwise would make me seem incompetent when in reality it is a sign of maturity. Immediately after reading this pattern I feel as though it made a fundamental shift in my approach to problems. It makes complete sense that mastering this pattern would yield great benefits throughout my career. “The most obvious way to expose your ignorance is to ask questions”(Oshineye,Hoover). Being able to ask questions whenever I am unsure of something can greatly abridge the time it takes me to learn a given skill. Also, in a world where we have near infinite knowledge at out fingertips at all times, I feel that a desire to learn is a much greater skill to possess than “knowing” a lot.

I find it very interesting that the authors make a distinction between software craftsman and experts. I agree that not being able to ask questions can shoehorn a developer into becoming really good at one skill, yet never branching out into others. I personally feel like being an expert rather than a craftsman can make a career in software development grow stale. Being able to nurture a desire to learn is important not only in the context of a software development career, but in everyday life as well. “Expose your ignorance” truly is a pattern that I feel will improve my career as a software developer.


From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

From Apprentice to Master in Software Development

Having read and enjoyed other books written in the same “pattern” based format, I was excited to start reading Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. Over the summer I stumbled upon the Art of Game Design: A Book of Lenses by Jesse Schell, and after seeing how much Christopher Alexander’s books The Timeless Way of Building and A Pattern Language influenced him I decided to read those as well. Not only was Schell, a pioneer in game development, influenced by Christopher Alexander’s work but I have also read many other books written in a similar format such as the Gang of Four’s Design Patterns book. When Christopher Alexander wrote A Pattern Language he clearly stumbled upon a formula that works.

Humans have an amazing ability to spot patterns and using that ability to our advantage when trying to create guidelines for others to follow no matter the subject matter makes complete sense. A book like Apprenticeship Patterns hands the reader a bunch of scenarios where each pattern can be applied. Rather than going into a situation blind and, in hindsight, realizing the inefficient mistakes you are making , the reader can then pull a pattern out of their metaphorical “tool-belt of patterns” that fits the situation and use that to gain an advantage. These patterns are not picked out of thin air, rather they should be crafted from detailed observation of problems that seem to arise often and can be tackled using the same solution repeatedly.

While so far I have only read the introduction chapter and the intro to each chapter of patterns, it seems as though the authors have given the idea of apprenticeship in software development an extreme amount of thought. I have read other writings about software craftsmanship that seemed to have a romanticized view of the medieval model of craftsmanship in their head when talking about software development. As Oshineye and Hoover stated, “We do not wish to repeat the mistakes that moved this model to the margins of modern society”. There are clear reasons as to why this way of developing a craft no longer is prevalent in society today and it would greatly benefit us in our discussion of software craftsmanship to acknowledge this and instead take pieces of the craftsmanship model and the standard practices in the industry in order to build a hybrid of the two. Not only do I feel that the authors take a realistic approach to software craftsmanship, but I feel as though they also chose patterns that greatly benefit myself and others at the beginning of their journey as a professional in software development.

After reading the introductions to each chapter I feel as though all of the chapters will be highly beneficial to me as I become a software craftsman, yet I can’t help but feel as though many of my shortcomings as a developer are talked about in chapter 2 “Emptying the Cup”. Throughout my life I have always been afraid of showing weakness or ignorance, something that has definitely hindered my learning potential in the past. This chapter focuses on making sure your pride as a developer never gets in the way of learning. The patterns I am most interested in studying are “Expose Your Ignorance”, “Confront Your Ignorance”, and “The Deep End”. Learning how to be unafraid to show that I don’t know something and then moving past that in order to learn seems like it is one of the most important ideals of a true software craftsman. Not only that, but “The Deep End” seems to be a pattern that is relevant to me today. In my Software Development Capstone, the class I am writing this for, we are getting thrown into the deep end when it comes to the system we are developing. I have been having a lot of stress about not messing this opportunity up, but if instead I look at it as an opportunity to learn I feel like some of that stress will be relieved.

I am extremely excited to absorb as much information from Apprenticeship Patterns as I can during this class. Not only do I plan on reading it through, but I plan on keeping it in the stack of all of my other “pattern” books as a reference that I can look to if I ever feel lost or need help getting on “The Long Road” towards becoming a software master.


From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

My Intro to Open Source Development

For my Software Development Capstone, my class is working in tandem with students from other schools to contribute to the LibreFoodPantry open source project. I honestly can’t contain my excitement to get started on this project as it is my first real exposure to programming on a team and using all of the knowledge I have about Agile and Scrum to develop software. I hope that my team and I can successfully collaborate to make meaningful contributions to the project we are working on.

We are going to be developing software to aid our school’s food pantry, and because it is open source, hopefully aid many other food pantries. While reading the information on the librefoodpantry community website I found most interesting the values presented on the site. The list of FOSSisms, that is linked was a very interesting read and helped eased my stress about working on an open source project. In creating open source software we are engaged and joining a community of developers working towards a common goal. Not only that, but we have the ability to work on a project whose scope is larger than any one person could comprehend, forcing us to work as a team in order to make headway on the project. It is a public codebase which forces us to show craftsmanship in order to maintain readability and professionalism.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Software Development Capstone Introduction

Finally I have made it. Today marks the first day of my final semester in my college career. I am going to be writing posts on this blog related to my Software Development Capstone class, CS-448. This blog post is just a test in order to make sure that this blog links correctly to the aggregate blog for this class.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

The Flavors of Software Testing

Recently I took a final in my Software Quality and Assurance class. While I think the final went relatively well there was one question that has been haunting my dreams, hiding in every dark corner of every dark room I find myself in. The question was one so simple yet for reasons unbeknownst to me, I froze. A concept that, at a former point in my life in the not so distant past had been second nature to me. The question was “What is the difference between static and dynamic testing?” Since I failed myself and my professor on that test I felt like I should use this blog as a way to freshen up my understanding of both types of software testing.

I found myself seeking elder guidance on the matter and landed at the doorstep of Lakshay Sharma on the ToolsQA blog. A very short and simple read later I felt the rush of knowledge come back to me and I feel comfortable that I can talk on the matter of static vs dynamic, white vs black box testing. The blog made it very easy to understand the concept because it is laid out in a simple format: the first section explains static testing, and the second black box. After both sections there is a small graphic that shows the differences between the two. So, what is static testing anyways?

Static testing refers to software testing that is done without running the program. This testing is also called white box testing and is done prior to running the code and can help sort out a multitude of issues within the program. Things such as code structure, and code pathing can be tested at this stage and without the use of unit tests. This type of testing is beneficial because it forces developers to take a step back and review the code they are writing. If you’ve ever gotten into a groove while programming and then taken a step back to see the mess you just created you would know why static testing is such a good tool to have in your software testing tool belt. Static testing is full about preventing errors in the first place, and as the age old saying goes: an ounce of prevention is worth a pound of cure. While that prevention is great, in the event that you do get sick, you are going to want that cure as fast as possible and as strong as possible to get you back on your feet. This is where dynamic testing comes in.

Dynamic testing is the act of testing code while its running. Although while creating dynamic tests you may be able to see the code, dynamic testing falls under the umbrella of black box testing because the tests themselves do not care about the inner workings of a program. Dynamic testing tests behavior such as input/output. The good thing about black box testing is that tests can be written prior to developing code and give programmers an easy way to determine if a program is working as intended. Dynamic testing requires more time to set up than static since it involves actually creating test cases.

Just as life is made up of thesis and antithesis and one cannot exist without the other, static testing and dynamic testing go hand in hand and to use only one is to cheat yourself of the best possible work you could be producing.


From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Are you Mocking me?

The idea of mock objects used for testing makes me very excited. After struggling through an assignment on mocking in the very class I am writing this blog for, my excitement started to waver. Luckily I was able to get everything working after messing with gradle dependencies and the locations of files within the project and it was really a joy to see just how powerful mocking could be. I decided to look at mocking in greater detail for this blog post, because while the assignment we did in class did set up a good introduction, I feel like most of the assignment was spent setting up mockito, a really handy java mocking framework.

I found a really thorough article about mock testing written by Michael Minella (over a decade ago!) over at While this article is ancient in terms of how quickly technology changes, I feel like all of the information given is still very relevant today, even if frameworks have changed a bit since then.

In the real world it is almost impossible to program without having to use dependencies. Mocking is one way to make sure that tests are only testing what needs to be tested, rather than testing the method in question and all of its dependencies. It allows you to create “Mock” objects that return desired outputs for their methods since tests should assume that any other methods that need to be called are working as intended. To reiterate what was said in the article, If a method has a dependency that returns an ArrayList, you most likely aren’t testing that ArrayList works as intended. You should assume that it works and test the method under that assumption. Mocks are proxy objects that only return what is necessary, eliminating any potential issues where the dependency could have an issue that would muddle the usefulness of the tests.

The article doesn’t go into detail about any specific frameworks but does talk about the how exactly the different types of frameworks work. According to the article, Mocking frameworks that use proxy objects, objects that are injected into the test file without modifying any other code, are far more popular than any other types of mocking frameworks.

This article is a must read for anyone looking to start using mocking in their unit tests. I feel like dealing with dependencies in my unit tests is something that I find myself struggling with and Mocking is most certainly a good solution to that.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Should Tests Drive Development?

After spending many hours reading about the benefits of TDD, Test Driven Development, I thought for sure that anyone attempting to program any other way was putting themselves at a huge disadvantage. I mean, who wouldn’t want to get work done faster, cleaner, and with more test coverage? While searching the internet for information about TDD I stumbled upon Robert C. Martin, one of the founders of Agile and writer of Clean Code‘s, blog. On his blog he wrote a post about a study done on TDD that actually proves that TDD brings no benefits into the workplace. As someone who read both Clean Code and Clean Coder I thought that Martin would disprove the study with an iron fist, yet that wasn’t the case.

Martin’s blog post was written in dialogue format which does make it pretty easy to follow along with his main points. Martin doesn’t outright deny the claims made by the writers of the study, rather he claims that their study wasn’t really testing two different ways of programming. The study had two groups work by programming in small chunks while one writes unit tests before, TDD, and the other writes their tests after, TLD, or Test Last Development. While it may seem like both of these ways of programming would yield massively different results there is an inherent problem with the way the study was carried out.

In order to program in small chunks, no matter when the tests are written, one has to think about the tests before writing the code. It is nearly impossible to know what a “small chunk” is for testing unless a test is already in your mind. This is the problem with the study. Both groups were essentially doing TDD except one group was writing the tests prior and one group was committing to the tests that would be written later prior.

The study shows that TDD doesn’t make you any faster or less prone to error than TLD, yet it seems like the two groups that were being studied were both doing a form of TDD, just one was using a less formal version. If there is anything that it seems one could take away from this test its this: writing code in small chunks, even if you aren’t writing the tests before, is the most efficient way to program. This study didn’t disprove TDD, rather it proved that one of the most important principles of TDD, writing code in small chunks, is extremely beneficial to all programmers.

One of my biggest issues when programming, and something that I find happens to me all to frequently, is I’ll have an idea for a way to solve a problem and I’ll chug away writing code until I think I have the whole problem solved. One “full send” later and a couple erroneous outputs and I’m lost as to what I should change in order to make my code passable. I feel like even if I am not using TDD completely when programming for things such as programming challenges, I should try and write in small chunks with the tests I will be writing in mind.

Overall a very fun read by “Uncle Bob” Martin. I am extremely glad I stumbled upon his blog because I enjoyed reading his books a great deal.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

The Great Pyramid of Software Testing

They all warned me that this was a horrible idea, yet here I am, guided only by the determination to find the uncovered truth lying behind the stone walls erected by our ancestors centuries ago. I walk across the endless sweltering sea of sand, my skin boiling and the contents of my canteen running dangerously low. I continue for what feels like an eternity in the direction I had estimated the pyramid to be in, although after days of walking I am starting to have my doubts. As the last drop of my strength gives way I find a small dune to rest on. Hours pass as I bake in the desert sun knowing that I may never find the truth I am searching for. I open my eyes to find Martin Fowler reaching his hand out to me silently expressing his infinite knowledge of the desert I find myself in. Fowler hands me his flask of water and I feel my energy and determination replenish and we walk through the desert speaking very little, yet I know now that we will find the Great Pyramid of Software Testing.

To anyone reading this, I am deeply sorry that you had to read that little prologue, but I mean, how could I not make a desert journey scene when talking about the software testing pyramid. Anyways, fluff aside, I decided to read a post that Martin Fowler made in 2012 that is still extremely relevant today. As I am taking a software testing class currently I thought it would be interesting to see where the type of testing we have been doing fits into the actual pipeline of software development.

In Fowler’s article he talks about the differences between low-level unit tests, high-level UI driven tests, and everything in-between. The pyramid has unit tests on the bottom, acting as the base and where the majority of tests should be. Then, just below the GUI driven testing, comes service layer tests. These are tests that are generally API driven that don’t suffer from many of the problems that UI driven testing has. Lastly, the tip is where the UI tests are, these tests can prove to be useful but have many drawbacks.

UI tests are the most brittle of the three types of tests as many times moving an element of the UI can result in having to refactor most of your tests. Fowler describes high-level tests as a second line of defense. This can prove to be useful because if a high level test fails it can expose underlying holes in your unit tests.

With test-driven development being so prevalent today with Agile frameworks, it makes sense that Fowler would recommend that unit tests are created whenever a high-level test exposes a bug as it makes it much easier to focus on squashing the specific bug that was found in the high-level test. Fowler also makes a case for always trying to use tests that lend themselves well to the type of application you are developing. If it is a javascript program it is best tested using a javascript testing framework like Jasmine.

Fowler’s article is filled to the brim with useful and topical information about testing. unit tests are the most flexible and powerful test type so it makes sense that anywhere a unit test could be used it should be. While the other two types of testing are less agile, they can provide benefits when usability is taken into account and only tests that make sense for UI level test are made.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Back to your regularly scheduled programming

Time to dust off the old blog, I have yet another class that requires weekly blog posts. I am hoping to gain much useful knowledge from the class that I am writing these for. It is a software quality and testing class and as of yet I have no formal test creating training. Since reading The Clean Coder by Uncle Bob I have realized how useful and important test driven development is. Hopefully by the end of this course I will be a TDD expert and will go forth in my career following those principles. One of my main issues when developing is I tend to get overwhelmed by what it I need to write in order to complete my goal especially as a code base increases in size and I feel like test driven development will help immensely with that issue. With a curriculum written by a professor whom I have a great deal of respect for I have no worry about whether the content will be engaging and relevant.

As for where I am in my career currently, I am a senior now. Soon I will start my search for a winter internship so that when I graduate in the summer I will have some experience working in the field. While I enjoy classes I feel like the amount you learn while actually doing the work yourself is exponentially greater than that learned in a lecture. I enjoy programming a great deal yet I find it hard to focus on what exactly to make and I would love the guidance of an internship.

My college years are ending just as quickly as they started. I have matured greatly since the start and I hope to make this year the best one yet.


From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Demystifying REST for myself

To preface this post I would like to say that this is the last blog post I will be writing for a little bit. I hope to return to this blog with a new outlook on the process of writing blogs and hopefully with more freedom in what I can post, the frequency and quality of posts will increase. In this post I have decided to do some research on REST in order to fully understand it so that going forth in my career I have a firm grasp on REST. Before reading this extensive article on about REST pretty much all I knew is that REST deals with http requests and http stuff.

First thing I learned when reading the post was that REST is more of a blanket term for any interface between systems that allows for the transfer and editing of data over multiple formats. This idea is so important because it vastly increases the scalability and functionality of products being created. It has become the standard in creating web applications and is used by most of the top sites such as YouTube, Twitter, and Facebook. The writer then goes into detail about the features that make REST special and why we all love it. A great feature of rest is the fact that everything is manipulated through the URL, keeping applications very uniform in how they access objects. They also talk about how it is a layered system which helps organize large applications. They then go into the benefits of using REST. Using REST separates the clients and the server which allows for scalability and ease of migration to other platforms. REST is also always independent of type of language being used which also increases options for migration and ease of development.

I enjoyed this read and while I feel as though it could have delved a little deeper into what REST is it was a quick easy read that helped me understand REST. Using REST in our assignments and project I had been emulating what I had seen without truly understanding what REST was. If you are like me and was having trouble grasping the concept of REST I would recommend reading this post.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.