Category Archives: Week 6

Jog at the Back of the Pack

The pattern “Be the Worst” is one that most people have heard many times and its a great life lesson that can be applied to many other situations. The idea is to surround yourself with people that are better than you and learn from them and grow. Basically don’t be afraid to not be at the same level as your peers and try to surpass them with every experience. This can also be a way to help others that are struggling or want to be better at something that you excel at. This pattern is definitely one that i could see myself using in my professional career and also in my education because the quickest way to learn something is to be surrounded by people that understand the concepts and to observe them and ask questions. Everyone has weak points and things that they wish they could be better at so finding people that excel at what you struggle with can only help you to learn and grow.
The one thing that I feel this pattern failed to make an extremely important part is that you should strive to go on and become the best at what you learn. I might just be a competitive person and this may not apply to all people, but I personally would want to become the best at whatever I do. This pattern also fails to really talk about doing the reverse which would be helping others in the same way that you want help. This pattern changed my perception about the profession of software development because I didn’t really think about how people from all over the place could be assembled to help one another understand things and it makes me think of a coalition/brotherhood rather than work or a job. The pattern talks about how it is a little selfish to join a team knowing that you are the weakest link and that you might hold them back a little, but sometimes you need to be selfish and think about yourself and what you need to grow and become better. Being selfish at times is needed to advance yourself and your career, so I’ll probably do this pattern unashamed and ready to become the best in every group.

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.

Independent Study: The Plateau, the Snag, and the Obstacle

Researching more on audio feature extraction last week gave me a lot to think about. As it settled in, I came up with great ideas for hypothesis to test and specific applications for them. The kind of ideas that lead to turning off your cell phone, skipping lunch and dinner, and get things working.

Unfortunately, as mentioned last week, I do not have the time learn audio processing algorithms to the extent that I can implement them, so I will have to make a choice on a library that will help. A further complication was getting code to run in Android. Libraries exist to run Python code in Android, but the Python libraries I’ve found for audio analysis are lacking in features and I would need to use a combination.

The most comprehensive library I’ve found is Essentia. Of course, it’s so comprehensive I won’t be able to use the code for a professional app without a commercial license. Luckily there is a noncommercial license available that will allow me to get results for the project and determine if there are commercial applications.

Essentia is a C++ library. So the good news is I get to use JNI and the Android NDK (Native Development Kit) to run C++ code. Getting C++ code to run from an Android Activity is straightforward enough, but I do worry about potential complications in running Essentia. There are a number of dependencies that I fear might cause trouble with a feature I might want in the future. These are kept to a minimum with a special flag during compilation for Android. But alas, my paranoia strikes.

Because Essentia is open source, I am at least able to see implementations of the audio processing algorithms, and the code is well-documented with references to studies. Signal processing is a degree, not just a semester-long project. I certainly appreciate that fact more over the past couple of weeks. But this will be a great overview and using the code will still require understanding of the underlying processes.

Progress was made on converting files from audio to basic byte data. When I was considering Python libraries, I was under the assumption I could use WAV files and easily get byte data (for example, with librosa). Android’s MediaRecorder doesn’t support saving WAV files, so other formats must be used.

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: Expose Your Ignorance

The first of the patterns in Apprenticeship Patterns that I have decided to discuss is titled “Expose Your Ignorance.” This pattern deals with situations where we do not understand every skill we need to use for a project. In such situations, people tend to fake an understanding of things they don’t know in order to appear competent. Rather than hiding our ignorance in this way, the pattern recommends acknowledging when we do not know something and explaining to colleagues that we are still learning about it. This makes it easier to build relationships and improves our ability to learn, which are both important skills for a software craftsman.

I chose to share this pattern because I found it relatable. During many programming projects I have been a part of, I have had trouble understanding topics that my peers seemed to have no problems with. Despite this, I’ve avoided asking questions due to a fear of appearing inadequate or ignorant, and have generally tried to answer my questions through my own research. I think that following this pattern would greatly improve my ability to learn new skills quickly. I would likely have an easier time learning new skills directly from someone with experience instead of trying to teach them to myself.

Knowing that this pattern could improve my ability to learn new skills quickly, I think it may change how I approach future programming projects. Previously, I have felt ashamed of not knowing things and have felt responsible for teaching myself in order to meet the expectations of my team members. I think this pattern will help me accept that it is okay not to possess every skill required for a project. It will also encourage me to communicate better with other developers in order to gain the skills I need. I have always had trouble asking questions and communicating in general, and I think this pattern would encourage me to get better at it. I will try to approach future projects from the perspective that it is okay to not have every skill I need, and that I should try to learn from other developers instead of keeping to myself. This communication might also help me build relationships with other developers as well as a reputation for myself that could lead to a more successful future.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Use Your Title

The next apprenticeship pattern I was drawn to has to do with the imposter syndrome. The problem comes when you obtain a title that doesn’t seem to reflect your skill level, at least in your mind.

The description of the pattern is much different than my expectation. I had imagined using a title to advance your career, but the suggestion is quite the opposite: it posits that the title is ultimately pretty meaningless as far as your skill level, but you can use it to gauge your employer.

An impressive title is tempting to pursue. It seems to prove to others that we’ve achieved success, which can be tempting for someone with parents to make proud or neighbors to keep up with. This can be completely removed from your actual success and may not reflect your actual job duties. While not explicitly stated in the book, this pattern suggest that if a company sets your title to something prestigious, and you don’t agree with it, it might be possible that the company sets the bar too low. If you know your skill is below a senior engineer, you should be somewhere where the senior engineers will help you get to their level. That’s not possible if all the senior engineers are at your level and know you don’t have the skills.

I’ve always reached out of my job title, as suggested by the Draw Your Own Map pattern I wrote about last week. As such, my job title did not reflect what I was actually doing. “Use Your Title” says that this can tell you whether you are appreciated, and reflects your employer more than your skills, and this has led me to leave jobs before.

I did have some problems with this pattern. It seems a bit contradictory, saying to not let your title affect you, but then saying to use it to decide how you feel about your company. Regardless, it sparked some thought about how I will be perceived and will help me to consider how my employer feels about me in the future.

I’m going to admit ignorance here: I don’t understand how the suggested action ties in with the description of this pattern. It says to write down a long, descriptive job description and consider how others would perceive you upon reading it. While this exercise might be useful, I don’t see how it applies to “using your title”. My only guess is that you want your actual title to match as closely as possible to your own goals. When there is a mismatch, for better or worse, it might mean you are not aligned with your company.

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 Pattern Review 5: Craft over Art

I am not lying when I say I have been avoiding delving into this pattern from Apprenticeship Patterns, for fear that it would hit close to home. Upon reading “Craft over Art”, I’d argue that this pattern is full of more enlightening information than any I have discussed so far. Oh yeah, and it also hit very close to home.

The context for this pattern is very general, as it states that you are being paid to deliver working software to a customer. The pattern argues that delivering working, useful software is paramount to building some magnificent thing in order to display skill or artfulness. We are trying to become craftsman not artists, and while there is a time and place where making the most beautiful code and software is appropriate, a line must be drawn. As explained in the pattern, it is important that a bottom line for quality is determined and met at all times, even under pressure. It is important to note that the authors argue that “utility and beauty are not opposed, but interdependent.” This means that we have to constantly choose a balance of the two that work for any given situation, and this will change constantly.

As I am an extremely creative minded person I find myself often trying to create “art” when I am trying to deliver working software, especially when I am working on self-directed projects. I find myself working on all of the frivolous parts of a project, expending all of my energy on minimal functionality. The end result tends to be me giving up on self-directed projects because I get burnt out working on all of the bells and whistles, while minimal actual functionality is present. A conversation between me and an observer tends to go like this:  “Wow that looks awesome! But what does it do?,” the observer exclaims. “Nothing but it looks cool right??,” I say, sweating slightly. My point is historically I tend to put valuable functionality lower than fancy technology and fluff. After learning about the Agile principles and Scrum frameworks I have been getting much better at reflecting and making sure what I am working on is valuable to the customer.

This pattern is packed with information that I will continue to think about in my career. It is fun to have a romanticized idea of what being a software craftsman is, but at the end of the day the most important thing is that utility is what I’m getting paid for.

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

Confront Your Ignorance

If we value independence, if we are disturbed by the growing conformity of knowledge, of values, of attitudes, which our present system induces, then we may wish to set up conditions of learning which make for uniqueness, for self-direction, and for self-initiated learning.

-Carl Rogers, On Becoming a Person

Every day of our lives, we find ourselves surrounded by people who know more than us. It is normal to not know everything. This is why we shouldn’t go hard on ourselves when we meet people who expect us to know more than we do. The best we can do is to confront our ignorance, which means to identify gaps in our knowledge and try to fill those gaps continuously. The “Confront Your Ignorance” pattern shows us different ways to approach when we find those gaps in our knowledge. Some of these approaches are: to read the introductory articles and FAQs, to love what you do in order to understand it better, to work with others who have more knowledge than you in a specific topic so you can learn from them, to learn in public and not in secret. As good as this pattern can be, sometimes the apprenticeship can become a problem for the team at work.

This pattern made me realize how important it is to confront and expose my ignorance. Sometimes I get too hard on myself, such that I forget that I am in a learning process and it is okay not to know everything. From now on I will write down everything I find it hard to understand and start working on getting better on those. It could be a skill, a technique or any topic, but that would be a good start towards a great future full of knowledge.

What got my attention is the fact that “Confront your Ignorance” and “Expose Your Ignorance” patterns are very close to each other. By doing a list of the things we don’t know, and the things we should know in the future, we’ll be able to learn where our gaps are, but exposing them to the world help us learn even faster, and get help from the others as well. Facing your ignorance alone leads to stubborn knowledge that never takes action, but reveals your confusion without seeing it as a question that must be answered as soon as possible. As a conclusion, confronting your ignorance is very important in our daily work, especially when our purpose is to be successful in our professions.

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

Integration Testing

Integration testing is the second step in your overall testing process. First off you will perform you Unit test, testing each individual component to see if it will pass. However, your testing process is just getting started and is not ready for a full system test. After the Unit test and before the system test you must run an integration test. This test is the process in which you combine all your units to test for any faults in the interaction between one another. Yes each individual unit might pass on its own but having them work together simultaneously in an integral part of the program. 

These are the many approaches one can take to Integration testing:

  • Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.
  • Top Down is an approach to Integration Testing where top-level units are tested first and lower level units are tested step by step after that. This approach is taken when top-down development approach is followed. Test Stubs are needed to simulate lower level units which may not be available during the initial phases.
  • Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-level units step by step after that. This approach is taken when bottom-up development approach is followed. Test Drivers are needed to simulate higher level units which may not be available during the initial phases.
  • Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches.

I think this part of the testing process is the most interesting. Once you have individually working components it’s like making sure the puzzle pieces fit. 

Integration Testing. (2018, March 3). Retrieved from

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

C4 Models

The c4 model is a tool used by programmers to articulate their software designs in a translatable manner. Using this model a programmer should be able to communicate their design easily to those outside the professions, say a stakeholder for example, and also to their programming team. The model should have levels and using “abstraction first” the levels should show different amounts of complexity that overall allow you and your team to implement the data. A great example of the overview of the c4 model is to think of google maps and their zoom feature. If you are looking at a country and are zoomed out so that you can see it in its entirety, then you may only see the name of the country and what is surrounding it. Then if you zoom in a bit you may see the states that make up the country. Zooming even more, you can see the cities, towns, and you may zoom all the way in to a specific location and see what is there. This allows the viewer to utilize the abstraction to avoid being overloaded with information and instead look at the data in layers of complexity. 

C4 models are implemented to represent the three levels of design. The three levels are known as:

System design refers to the overall set of architectural patterns, how the overall system functions—such as which technical services you need—and how it relates to larger enterprise contexts. System design is shown in a Context diagram.

Application design refers to the combination of the services that are needed and how to implement them. Application design is shown in a Container diagram.

Service design refers to the patterns and considerations that are involved in implementing specific services. This type of design starts to emerge in a Component diagram”.

Relating these three levels of design to the google maps example starts to make things clear. The system design would be the view of a country in its entirety without too much detail, or in other words the big picture. Application design is a bit zoomed in and could show the states that makeup the country and helps to show the relationship between data inside the big picture. Service design would be the specifically zoomed areas where you can see in much more detail and see the function of data.

This c4 model stands out to me because it helps to bridge the gap between those involved in the field and those who are not. It provides a concise and organized way of communicating project ideas and patterns to your team  and to whom you are working with that may not understand the other diagrams programmers use. For example, UML diagrams are great for programmers but you don’t want to present that to someone who isn’t a programmer. They will have no clue what they are seeing, but with a c4 model you can capture the big picture and have the details on hand as well.

(n.d.). Retrieved from

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


The latest in-class activity from CS-343 introduced me to Representational
State Transfer (REST), which is an architecture used by Client-Server APIs. The
activity was helpful in explaining standard HTTP methods which are used by REST,
specifically GET, PUT, POST, and DELETE, but it didn’t really focus on
explaining what REST actually is and how APIs that use it are structured. For
this reason, I decided to further look into the fundamentals of REST and how to
use it. While researching, I came across a blog post by Bivás Biswas titled “How
not to blow your REST interview.” The post can be found here:

While this blog does indeed give interview tips, it also helps
explain REST and the design principles it follows. Biswas focuses on five main
principles of REST that RESTful APIs follow, which include the contract first
approach, statelessness, the client-server model, caching, and layered
architecture. I chose to share this blog post because its organization of its
information on REST helped make it easy to follow and understand. For this reason,
I think the blog is an excellent resource for learning about REST, and I could
see myself coming back to it as a reference if I work with REST in the future.

I liked that Biswas opened the blog by acknowledging common
misconceptions about RESTful APIs that he has heard in interviews. One of these
misconceptions was that RESTful APIs simply follow the HTTP protocol, which is
a misconception I may have developed myself due to the aforementioned class
activity being focused on HTTP. The fact that this was immediately stated as
incorrect helped indicate to me that REST was more detailed and complex than I
understood from class.

I also thought that Biswas’ approach to explaining the five
principles of REST was particularly effective. He makes use of analogies and
examples to demonstrate each concept instead of relying on technical terms that
newcomers to the topic, such as myself, would likely not understand. For
example, he explains the contract first approach with a mailbox analogy by
suggesting that applications can get the same data without changing URIs in the
same way that people can get their mail without changing mailboxes. Similarly, layered
architecture is explained by comparing an API’s Gateway layer to a bed’s
mattress. Much like a bed frame can be changed without affecting how the
mattress feels, changing the fundamental layers of a RESTful API does not
change how applications interact with the API’s Gateway. Analogies and examples
always help make complex concepts easier to understand for me, and their use in
this blog greatly helped increase my understanding of REST and its 5 core
principles. I am by no means an expert on REST just because of this blog, but
it has certainly helped prepare me to learn more about it in the upcoming class

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.


Once again I was looking through the course topics for my CS-343 Class on Software Construction, Design, and Architecture where I came across refactoring. refactoring is the process of “editing and cleaning up previously written software code without changing the function of the code at all” by Sydney Stone in an article called “Code Refactoring Best Practices: When (and When Not) to Do It“. The technique of Red-Green-Refactor seems to be the most used type of refactoring process and focuses on the three steps of Red or consider what needs to be changed, Green or write enough code to pass the test written, and Refactor/clean up the code. Refactoring is clearly an important part of the software development process, but it is not something that I have used in my own coding experience so far. The continuous cleaning, optimizing of code, and adding of new functionality helps to ensure that the user receives the best experience using that code or program or tool. At the same time refactoring may not be the best solution due to time constraints and if the design or code is not worth refactoring because in some cases it’s much easier to just start from scratch.I have found myself in the hole of attempts to change and fix thing and I’m sure almost all people that code have fallen into this hole because its much more enticing to try to use or change something you already coded instead of starting over. I personally really like the style of Refactoring code and it seems to be more commonly used in things like games, applications, and other user based software.
I can certainly see myself using this technique in the future when working on code or being instructed to do a part of the refactoring process because it looks to be common practice in the field of Computer Science and especially software engineering. I knew that there was a process to updating and refining/adding new functionality to software but was unsure of the name or the actual process that takes place in order to yield the best results. I also had no idea that eclipse had a built-in automated refactoring support which makes me want to learn more about how to achieve this so I can apply it to my own software in the future. Testing also is an important part of refactoring so I can apply this method as I learn more about Software Testing and Quality Assurance which encourages me to learn more about good practices in both fields of Software engineering.

Link to Article referenced:

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.