Category Archives: Week 1

Craft over Art

For this week’s pattern I have chosen “Craft over Art”. It describes of the pattern where you are given a problem and you are solving it for a customer. You can do it the simple and tested way or create a new solution that will let you express yourself as a programming artist and will look nice on the resume. It describes the conundrum of making something simple and useful right away or making something beautiful and complicated and not usable right away.

I have chosen this pattern because I have struggled with it many times before in my professional career. Many times have I been given a problem to solve for a customer and I had to decide to make it the quick and easy way that I already know will work, or should I do it some new, more complex way that can possibly save some time in the long run. The way that the “Apprenticeship Patterns” describes it should be done with a mix of both solutions, make it somewhat easy but tested way but with possible improvements. I think this is a good approach but there is a catch to it in my opinion, what is acceptable to the customer? Can they wait for a different, nicer way or quick, not totally efficient way will suffice? I think in the moments like that it is up to a Project Manager or the customer to decide and anybody working on this should act accordingly.

We as programmers and developers are in the end a service providers, unless we work for ourselves and do not have any hard deadlines, we need to stick to timelines and or project deadlines. What works and is tested very often is the right solution because time spent on implementing new solution can be something that ultimately may cause a project to fail and nobody wants that. The book also says that we as craftsmen need to provide at leas a minimal level of quality, and I think that if something is well defined and tested and works has that kind of quality. Why go for a new fancy way that might now work 100% of the time, or it requires a lot of time to be understood by somebody else. My boss likes to remind me that “if it is not broken do not fix it, because you will only cause more headaches to yourself and somebody who will work with my code later”.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

CS-499: Independent Study Introduction

This semester, I’m building an Android app for an independent study.

The Proposal

After building a breadboard computer and beginning to understand electronics, I started to learn about audio electronics. This sparked (or reignited) a latent interest in audio processing. Working in a call center selling audio equipment is actually the reason I was motivated to return to school to study computer science, so I feel there is good reason to pursue it in my final semester.

I also began with Python, and moved to Android apps in my early programming learning process, so I’d like to refresh these skills and dig deeper. This project will serve as a constant reminder to how far I’ve come from those early struggling days.

So the app will use Python machine learning libraries to analyze user audio data and provide the user feedback based on this data. I am purposely being vague; not because I think I have the next big idea on my hands, but because I expect many changes as I struggle with the machine learning model.

Regardless of where the model winds up, this is a software development independent study. I will have a working, professional app within the next 4 months, using the technologies I have proposed.

The Motivation

Why, though? As an independent study, with an already-busy schedule, I’m going to have to set aside time each week when I work on this project, no matter what. Originally, I wanted to take Robotics this semester and I was signed up for it originally, but unfortunately there is not enough time in my schedule. On Tuesdays I’m sure I will find my mind wandering, dreaming of playing with robots instead of struggling through machine learning and Android Studio.

But that is part of my reasoning. I want to find the motivation to do things with a self-imposed deadline. These are tools I want to learn, to create and potentially sell a product. At the end of this degree, I want to be able to show a project to future employers that say, “this is what I did. Not because I had to, but because I enjoy it”. I want to be able to have users who give me unfiltered feedback. I want to fail, figure out why I failed, and eventually succeed.

Of course, I have done all of these to some extent already. But this is my following my current interests and goals.

The Progress

I have made a couple small spike projects to begin relearning Android and get started with Tensorflow. I have already built the back-end and gotten an app to communicate with it. I’ve also done basic user authentication.

When I first proposed this project, I set a schedule of features and tasks to complete. Due to other projects which used the same technologies and flashes of motivation I’ve already worked ahead a bit, but I still plan to complete each portion according to the schedule, as best as I can. The machine learning model will be concurrent work as I adjust it.

Next week, I will go into more detail on the tasks I’ve completed so far.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Introductions

After reading the Apprenticeship Patterns book introductions and a few of the patterns, I have to say they are very straightforward, which the book itself admits. The utility in reading them is that is is very easy to forget these ideas, or never apply them to your work.

I was ready to condemn the book from the beginning, as it introduced the idea of apprenticeships in medieval through industrial revolution times. I thought to myself how naive it is to write a book about such bad situations, and that the authors must be romanticizing this time. This thought was immediately shut down as I read the line, “we believe it is possible to reject the romantic fantasy”, in favor of something better. This served to drive further points home, as I had just fallen victim to some of the behaviors it warns against.

This book describes patterns that “are tools that solve one set of problems and create new ones.” And it says that “the trick is to use your judgment to choose the problems you prefer.” I love this idea because it illustrates the fact that one doesn’t need to be able to solve every problem if you can figure out how to solve it with the tools already at your disposal.

At the same time, it provides a framework for learning more tools. The idea of “exposing your ignorance” stands out most, because most of us want so badly to be intelligent and competent. Having spent some time in the workforce without a degree, I have become sensitive to this: trying hard to prove that I’m not “dumb”. Maybe it was actually that, that had slowed me down.

On “Emptying the Cup”

It’s always a good reminder that you might not know as much as you think. Or if you do, that you might be biased and closed to new ideas. I am very proud of some of my work, having had moments where I feel like a programming God, and in the face of a new technology, I am always humbled. But I feel that I run the risk of using my past professional and education experiences get in the way of new methods.

On “Accurate Self-Assessment”

I had to read some of these patterns, because I tend to self-assess in the negative direction. I already usually assume I’m “the worst”, or that my work isn’t good enough, and seek improvements. Still, the patterns themselves are useful, describing how to solve this problem. I tend to spend too much time assessing. I need to consciously tell myself to move on to new things, rather than dwelling on what has been done and how it can be done better.

…And Onward

My capstone team has been discussing learning some new technologies, and these introductions have lessened the fear of diving in and trying them. At the end of my college career, I have been reflecting on what I could have done differently, or how I could have done it faster, so this book comes at the perfect time.

Haven’t we all sometimes wanted a chance to start over again? How exciting to have a chance to be at the beginning of something.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Introduction for CS-448

This blog will be following my cs-448 class for this spring 2020 semester.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

What’s That smell?

A topic that caught my eye when looking over the syllabus for my CS-343 class was Code Smells, so I decided to delve deeper into the topic. I read a blog post titled “CODE SMELLS THAT ARE FOUND THE MOST” by Ekaterina Novoseltseva, which talks about commonly found design flaws in code and how to address them. Ekaterina goes through a list of those design flaws like the bloater which are code, methods, or classes that are too large or have grown too large making them difficult to work with. Another mentioned design flaw would be the change preventer, which as its name implies prevents change by making the coder change multiple places in order to fix/change one section of code. There are many more examples of code smells that are explained in the blog.
One of the code smells that stood out to me was long methods because for a while that was something I would do while coding and it made my code almost impossible to track and understand, as well as, made it hard to trouble shoot where my issues where when my code did not pass test classes. Having long methods made coding extremely difficult and created more problems than it did good. another code smell that really hit home was duplicate code, even though it is easy for me to just copy and paste the same code into multiple methods, it makes more sense to create a single method that can be used in multiple places. simplification of code is something that I have been working on because it makes coding a lot smoother and easier to adjust and make changes to in the future. The last code smell that really spoke to me was dead code which is code that is not being used. Too many times I find myself writing code that is too complicated or doesn’t work, and then commenting it out or saving it for future changes and usually forgetting about it which makes it all the more confusing for some one reading or looking at my code. learning more about code smells has given me the confidence and knowledge to avoid them in the future and to make simpler and cleaner code. Design of all things is meant to be efficient and useful to both the designer and the user, so to practice and understand good design a person must understand bad design as well.
Link to the Blog Referenced in this post:

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Software Quality-Quantity Trade-off

Programming was extremely hard for me at first. Once I discovered that programming isn’t just typing code, I spent so much time worrying about getting the perfect design, imagining what could go wrong, and researching alternatives that I rarely actually coded anything, at least for a brief period. While this concern may have taught me a lot in my research, I know better now. There’s a trade-off between time spent designing and time actually making software work.

Likewise, there is a trade-off between creating high-quality software and adding more valuable features, as Martin Fowler discusses in this blog post. Fowler is a software developer and author who has written extensively on the topic of software quality and design. In this blog post, he poses the question “is high quality software worth the cost?”.

Short answer: yes it is. To go further, Fowler believes that the question really doesn’t apply to software because high quality software is cheaper. He also makes the distinction between internal and external quality in software. For example, users notice a quality user interface, but have no idea which design patterns were used.

Internal quality is the goal of quality assurance and testing, and while it isn’t directly visible to the user, it makes it so much easier to provide a user with additional features by adding to an existing code base. In my last post, I wrote about SOLID and a podcast by Coding Blocks. They discussed how good patterns take a lot more code to write in the beginning, because things are broken up into smaller classes, with more, smaller methods. But as Fowler describes, the initial work more than pays off in the long run when code is easy to read and understand.

Anyone who has learned to program has spent hours looking for a mistake on a small project. These get harder to find as a project grows, especially when there are hidden dependencies among poorly-formatted code. Now imagine you wrote the code 2 years ago. And you can’t even fix it because you’re on vacation, but it’s preventing users from accessing their accounts so your coworker has to. Quality code and tests will drastically improve the chances that the problem is quickly patched and your users are happy. Take it one step further: this problem could have prevented entirely with sufficient testing and more focus on quality.

Most time is spent reading code rather than writing it. Fowler mentions this, but it is also an important theme in Clean Code by Robert C. Martin [1]. If you write quality code now, you can write even more quality code in the future.

[1] Martin, Robert C., et al. Clean Code: a Handbook of Agile Software Craftsmanship. Prentice Hall, 2016.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

SOLID: Laying the Groundwork for Design Patterns

At the core of software design must be basic principles. Following basic principles allows us to make sure we are on track with a standard. It creates consistency and makes it easier to maintain our code in the future, because we will know what to expect.

Following a single principle might be easy, but there are many object-oriented design principles. Sometimes, it is quicker to hack a solution together than to think up an elegant solution. These solutions may then be built upon, and the project will slowly stray from its original intent. Gaining the intuition of when and how to apply these principles is necessary to ensure that a project doesn’t become a mess of spaghetti as these quick-fix solutions add up.

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

– Steve Jobs

Coding Blocks Episode 7 discusses these topics in the context of five of the most important design principles, known as SOLID. This podcast is great and I highly recommend it: it is hosted by professional programmers who discuss and debate the topics of each episode.

Each of these principles likely warrants its own podcast, and one or more blog posts to describe them in detail. Below is a short description of each one.

S: Single Responsibility Principle

  • An object should only do one thing.

O: Open Closed Principle

  • Code should have the ability to be extended, but it shouldn’t have to be modified.

L: Liskov Substitution Principle

  • Replacing an object with one of its subtypes should not break the code.

I: Interface Segregation Principle

  • Smaller, more specific interfaces are better. If an interface is too broad, an object may need to implement many methods it doesn’t need.

D: Dependency Inversion Principle

  • Within a class, you don’t want to depend on an implementation. Instead, a higher-level class should depend on interfaces, which are implemented by lower-level classes. Don’t have an abstraction relying on an implementation. Have the implementation relying on an abstraction (interfaces).


The biggest takeaway from this podcast episode was that even professional programmers do not follow all of these principles all the time. Some of the concepts are confusing and contradict other principles. Some of them should only be applied when refactoring code after it is working, with the goal of improving your code.

However, when learning these principles, projects should be created with the sole goal of implementing these principles. Mentally solidifying these concepts by focusing on each one and converting it into code will help a developer to predict issues that may come up in the future when implementing production code. Knowing the context of the system, code can be written that mostly follows these principles right off the bat, and improvements can be made later as code is added and the patterns emerge. Most importantly: the foundation will be SOLID.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

Beginning My Summer Research Project

This summer I will be conducting research under the Aisiku Undergraduate Research Fellowship which is awarded to STEM projects for students at Worcester State University. The goal of this project is to research and select the best version control software to use for the LibreFoodPantry projects which fall under the category of Humanitarian Free and Open Source Software. I will be looking at the GitHub Free, GitLab Free, and GitLab Gold packages and selecting which one out of these three is the most suitable for contributing to and maintaining the LibreFoodPantry projects. I will be writing weekly blog posts to keep track of what I learned and did during the week while working on this project throughout the summer.


This week I began the project by looking at the features of GitHub Free, GitLab Free, and GitLab Gold. I created a table in a document with a column for each one of these and started listing out the features that are provided in the product comparisons page for GitHub and GitLab. Once I listed out all the provided features for all three of these I started to do a comparison between the features listed for the GitHub and GitLab plans. The comparison for GitLab Free and GitLab Gold is easier since GitLab Gold has the same base options as GitLab Free in addition to other advanced features which are listed in the plan comparison page. I then started going through all the features listed in GitHub Free’s plan page and seeing if the GitLab versions had them and if they were similar features. I kept track of differences by highlighting the text of the features in the table with different colors. I ended up finding that most of the GitHub features were comparable to GitLab such as having code owners or project boards. I found out that GitHub has a couple of features that both versions of GitLab we are looking at doesn’t such as an apps marketplace. GitHub also has a couple of features it does better than GitLab such as offering repository insights. There were also a couple of features that GitLab does do better such as having built-in continuous integration and continuous delivery. Overall I found that I started to prefer the GitLab platform by the end of the first week and their website offers better and more thorough documentation for its features than GitHub’s does. At the end of the week I had a meeting with my faculty advisor for the project to go over my progress and findings so far. In the beginning of the meeting we both came to the conclusion that the research being done for this project is applicable outside of the scope of just the LibreFoodPantry projects and can be used for other open source projects. We decided that I would continue looking at the features between the platforms during the second week. My advisor also created testing groups on each of the platforms and added me as an administrator so that we can start testing workflows after I finish comparing features. We also discussed the details about an upcoming meeting for LibreFoodPantry (which should help refine the workflows we will be examining in this project) and my involvement in this.


From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

To go through the long road of Software Craftsmanship we should be eager apprentices, so a superior enthusiasm should be with us since the first day of the long journey. Enthusiasm is the first factor that will accelerate your learning. Being a software developer you cannot avoid working with a team in your workplace. As … Continue reading Unleash Your Enthusiasm

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

B1: Learn How You Fail

          The book describes the “Learn How You Fail” pattern by talking about failure in general throughout a developer’s life. It explains that everyone fails at some point in their life and it shows the potential of growth. The blog continues to say that identifying where an individual specially fails can create better self-knowledge for their habits and behaviors. The main goal of this pattern is to then learn from these habits and behaviors to correct the ones that limit your potential. It brings to light the importance of creating an accurate self-assessment and awareness of weaknesses to find a realistic goal that can be accomplished. The book gives an example for coding where the programmer should try to use a text editor to implement a binary search in any language. Then write the tests for that search and run through it without a compiler manually to find any possible error you have made. You can compile the code after doing this to find any remaining errors that you may not have picked up.

          I found this pattern very interesting and informative in terms of self-understanding and creating reasonable goals. The way the pattern explains how habits and behaviors can become second nature which eventually leads to errors that we make unintendedly was very thought provoking. I enjoyed following the logic behind this and understanding how this can affect me in the long run as a developer if I don’t look for these errors now. This pattern has caused me to value my failures even more by teaching me more about learning from them. I always went with the logic that if I failed, I should simply not make that mistake again. However, this pattern showed me that instead of avoiding mistakes, I should naturally make them and learn from them in detail. This learning experience could provide me with deeper insight on how I will learn in the future and plan for my profession in a much easier light. I don’t disagree with the pattern at all, in fact, I thoroughly enjoyed every part of it. I especially enjoyed the example given using the text editor as a IDE to find mistakes in writing and compiling code.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.