Category Archives: Worcester State Blogs

Apprenticeship Patterns Chapter 1

The first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye wasn’t really what I was expecting to be honest. Typically books for college classes are very factual and focus on learning new concepts, where they should be used, etc. This book, the first chapter at least, reads more like a career advice books. The authors are speaking from experience to try and provide insight and advice to people who are about to step into the field of software development (a.k.a. Computer Science seniors like us) or to those who are just getting started in it. I found the piece on Dave’s story to be particularly interesting. I always find it fascinating to see how people got to where they are in their careers, because the path taken is typically not what you would expect. In Dave’s case he got his foot in the door by essentially teaching himself Perl and proving to be he had what it took to be a programmer. He did that at age 26, so it wasn’t like he got a Computer Science degree, went right into the field, etc. It was an unusual path. He had to find another way to get his foot in the door. People who take the more difficult road often have the best advice, so I am particularly interested to see what he has to say throughout this book.

Now, more focus on what the purpose of this chapter was, which I feel was to provide an overview of what it takes and what it means to be a “software craftsman”. He goes on to provide a lengthy list of what “software craftsmanship” means, but I’ll point out a few that stood out to me:

  • “A willingness to experiment and be proven wrong” [AP] I feel this is very important. You simply won’t learn anything if you aren’t willing to try new things. This is applicable to all aspects of life, not just software development.
  • “A desire to be pragmatic rather than dogmatic” [AP] This is something I agree whole heartedly with. To have a program be absolutely perfect you will be working on it forever. Companies care far more about getting the job done in a timely and efficient manner than having it be perfect. If it gets the job done, they aren’t going to care how it got done in most cases.
  • “A need to always be adapting and changing based on the feedback you get from the world around you” [AP] Speaking from the experiences I’ve had at my software engineering internship, there are times where I’ll spend a week working on something and it will be scrapped because something changes late in the game. Or I’ll get halfway through writing a piece of code and realize there is a far better way to approach and I’ll have restart from scratch. You have to be willing to change and adapt to any situation at any point in time.

He then goes on to talk about three different stages of expertise in a craft: apprentice, journeyman, and master. I think it is safe to say most people taking CS448 are in the apprentice category. We all have so more to learn. Obviously, the goal is to eventually be a master at this craft, and hopefully this book along with the “apprenticeship patterns” it discusses will help get one step close to obtaining that goal.


Link to book:



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

CS448 Test Post

CS448-02 Spring 2018 semester test blog post.

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Java Testing Tips

Since I would consider myself a novice with Junit and java testing, I decided to take it upon myself to try a learn a bit more about it since we have been using it in class. I found a blog on by David Salter that discusses a few tips on this topic, which I found to be quite insightful, so I am hoping to relay those tips to you.

The first tip is to follow the AAA pattern when writing tests. That is Arrange, Act, Assert. Arrange the conditions at the start of the method, act on the system, and then assert that the results are what you expected them to be. I am always a fan of easy ways to remember things, so I really like this acronym. It a nice easy way to remember what a good java code test should include.

To go along with the AAA, there is an important thing to remember when using the last of the A’s, assert. Although assert is a cool and powerful feature, you must be careful as to where and how often you use them. One should be careful that they are not testing things that the method wasn’t intended to test. It is also important to make sure you are not testing too many things in one method. This cause headaches if a tests fails, because it requires debugging multiple methods/classes, rather than being able to focus on just one. This tip really stood out to me because I think one can easily go down this rabbit hole thinking that they are making their lives easier, while in reality they are making it harder.

The last item I want to discuss is important to testing, but it is also important with regular development as well. Take advantage of what the software has to offer you. It can make your life a lot easier in the long run if you take the time to learn a new feature or two. Although you have to invest time upfront learning how it works, you can save a lot of time because that feature makes it easier for you to develop, debug, etc. For example, libraries like EasyMock and JMockit allow you use a mock object. This allows you to “mock” objects that do not exist yet. The example used in the blog us mocking a security system that controls who can access what, depending on the user logged in. Because you are able to create a mock one, you are still able to test your product, even though a key component is missing.

Obviously there a lot of different tips a whatnot to help make us better testers. This really is just the tip of the iceberg, but I hope it was as useful to you as it was to me.



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Some Traits of Smelly Designs

In the past, I have talked about Code Smells. However, did you know there is also a Design Smells theory? What’s the difference? Well, according to the CodeOps blog, “Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.”. In other words, the difference between code and design smells is Design Smells focus on the design quality and principals (the architecture of the code) while Code Smells focuses on poor coding practices (what bring the architecture to life). The blog mentions a couple of red flags to look out for the may be an indication of Design Smells that I feel are worthy of discussing. Since I know I have perhaps accidentally or perhaps out of laziness have done some of the thing mentioned in this blog, I figure it can a good learning experience for both myself and the readers of this blog.

Violation of design principals: They use the java calendar class as an example. Not only does it support dates, but it also supports time. Since it has multiple roles, it is in clear violation of the Single Responsibly Principle (the first of the SOLID principals discussed a few weeks back). This is known as Multifaceted Abstraction smell. When you think about it, violating design principals is clearly a bad idea. The principals are there to promote better design and coding, so going directly against is clearly not the brightest idea.

Inappropriate use of design patterns: This one is on the opposite end of the spectrum. Instead of complete ignoring common practices to promote better code, you force it upon yourself. Just because the design pattern could be used in whatever situation you might be in, it doesn’t mean that it should be. Don’t feel obligated to use them if you feel if it will do more harm than good.

Language Limitations: Sometimes languages force you to do thing you don’t want to do, and often times it can be out of your control. Java is used as an example again. Because java does not support primitive types, if you need to take in different primitive types, you will need repeat the code, with the type taken in being the only difference. While I agree that language limitations can promote bad practices, I don’t know if it is fair to considered this to be a trait of a smelly design since unless you were able to pick the language, there is largely nothing that can be done about it.

Viscosity: This is basically taking the easy way out. Sometimes there is a hacky way to solve a problem that may be prone to errors, isn’t modular, etc., but it saves significant time and resources. Because developers are often under a time crunch, they often resort to this. I know I have, but I also know it will come back to bite you. Avoid the hack if possible.

Obviously, there are various other causes of smelly designs, but I hope this short list gave you a good idea of what Design Smells is all about.


From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Unit Testing Tips and Tricks

First of all, what are unit tests and why are they important? The meaning behind them is kind of given away in the name. They are designed to test individual features/components (a.k.a. units) of code to makes sure it is working the way it is supposed to. This helps eliminate external factors like other features affecting the one you want to test. Unit tests are used anywhere and everywhere whether you are aware that you are using them or not. I can say that we use them on a regular basis at work and I use them when writing any sort of software, even if I might not specifically think “Lets unit test this piece”. With unit testing being so important, I thought why not see if there are ways to improve them, and luckily Stormpath has a blog with tips on it that I found quite useful and intend to use in the future.

The first thing they suggest is to use a framework for testing such as Junit. To put it simply, these frameworks just make life easier. They help setup, organize, and run your tests and I cannot agree more that frameworks both make tests easier and help improve testing. Next on their list is to use test driven development. This basically means that your write the tests before you write the code. Assuming the tests are written based off requirement, this forces you to make sure you hit those requirements and it provides a more complete, modular product in the end. I generally agree with these, but I do believe there are times where this can be difficult. Sometimes the customer may not know what they want to end product to be. What happens if the design shifts in the middle of development? Then you might have to rewrite all of the tests. If possible however, test driven development is a good approach to use. They then suggest to check how much code you are covering. In other words, are you testing every line of the unit you are testing? If not, you are leaving yourself open to bugs. Stormpath discussed a couple of other suggestions as well, but they have one that I feel is particularly important, so I am going to devote my time to that one, which is to tests negative situations and edge cases.  Sure, you’ve tested all of your code and it works as long valid data has been entered. However, your program doesn’t live under a rock, so it is going to be exposed all sorts of situations. This can include users putting in invalid data. You have no control over what they are going to do with it, so your program needs to be able to handle those situations. I would argue that testing edge and invalid tests cases might be more important than normal test cases, simply because you can probably predict how it will be have when the user stays in bounds, but who knows what could happen if they don’t.



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

DRY, KISS, and YAGNI Design Principals

This week I have decided to continue with the discussion about design principals from last week. I like design principals because they generally provide important things to keep in mind while coding and are written in a fashion that is easy to remember (typically an acronym of some sort), which is why I’ve continued to discuss them. This week there are three I want to discuss: KISS, YANGI, and DRY. Now, you might be asking, why three? Well, these principals all focus on keeping things as simple as possible, so they kind of go together. Jonathan San Miguel has nice blog that discusses the basics of these principals.

First in the queue is DRY. Don’t Repeat Yourself. Another way of putting this would be to say, “don’t reinvent the wheel”. Have you ever been looking through your code or someone else’s code and realizes that there are similar or identical pieces of code in different parts of the program? Well, following this design principal will help eliminate that. You shouldn’t have to repeat code, and if you do, the original piece should be redesigned so you don’t have to waist your time writing the same thing over and over again. I always find it frustrating when I find similar code because I have to spend time trying to determine if they are exactly the same, why there is a need to have it twice, what is the little variation in it that made them write it twice, etc. So to summarize, unless you have a clear, distinct reason for repeating code, don’t do it.

Next up is KISS. Keep It Simple Stupid. This one is kind of self-explanatory, but basically it means don’t make your code more complicated than it needs to be. Keeping code simpler makes it easier for others to read, easier to modify, and easier to look back to later on. I especially agree with being able to go back and modify later on. At the time, the complicated code you wrote probably made perfect sense to you, but if you go back to it a year later to make some adjusts you may end up asking yourself what the heck you were trying to do with that piece of code for the next two hours. I know I’ve done it. Miguel also suggest avoiding using language specific features. By avoiding this, it can allow other people that aren’t familiar with the language to still understand what is going on.

Last on the list YAGNI. You Aren’t Gonna Need It. If you don’t need a feature at the point in time of writing it, don’t include it. You don’t need it now and you probably won’t need it in the future. You are simple wasting your time and other people’s time as well as probably causing some confusion.

I hope you found these principals insightful and useful. I know I did and will keep them in mind when writing code.



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

What Is Needed to Make Automated Testing Successful? Some Basics…

Testing software can take up a lost of time. One way to reduce the time spent on testing is to automate it, meaning that a person doesn’t have to run each individual test manually. Automated testing is the way of the future, and there is information everywhere on it. Bas Dijkstra of discusses some of the basic principals of automated testing in his blog post, “5 Pillars of a Successful Test Automation Implementation”.

The first of the five pillars is the automation tool. Everybody has to have some sort of tool to help organize and run automated tests. Testing teams often overlook the tool and just go with whatever is available on hand. By doing this, they may be making their own lives more challenging. Take the time to make sure you have tool that fits your needs. I agree that this is an important first step. If you pick or are forced to use a tool that is poorly designed or doesn’t meet your needs, you are putting yourself behind the eight ball to start.

The second and third pillars discusses test data and test environments. Depending on how broad the scope of the tests are that are being run, data can become a pain to maintain. You want to make sure that you have this situation under control or you are asking for trouble. It is easy to imagine how out of hand and disorganized this could get in large scale testing. To go along with test data is the test environment. Have an environment that is as realistic as possible. Make sure it has everything you need to complete your testing and if possible, make it easy to replicate. This can allow you to run multiple tests is independent environments and/or continue with develop in one of the environments. Nothing is more frustrating that not having an environment to do you work on, whether another team member is using it, it is down for maintenance, etc. and one that is easy to duplicate can help eliminate this problem.

Next is reporting and craftsmanship. Reporting is vital as it allows others and yourself to analyze test results. Dijkstra suggests that a good report should show what went wrong, where it went wrong, and the error message that went with it. This can relate directly to craftsmanship as testing can be challenging if the correct skills aren’t available. There should be someone who has experience creating reports, for example. Make sure the correct developers, engineers, etc. are on hand to answers questions and help when needed.

My experience with automating testing is limited, which is why I have started to investigating it. From experience with manual testing, I can say that what Dijkstra discusses certainly applies, so I see no reason why it wouldn’t apply to automated testing too. I hope continue reading about automated testing as I feel it is an important and necessary tool/skill to have.



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.