Category Archives: Week 12

Software Architectural Patterns and Their Uses

Image for post

When working with larger projects, a unified system or pattern can be useful in keeping things organized and cohesive over time. Design patterns can be applied to general problems in software development, such as creating many similar objects with slight differences from a factory class which handles object creation within the program, or using decorators in a program to add specific attributes or behaviors on a per-object basis. But while these design patterns are helpful for solving singular problems, they often lack the scope necessary to layout and plan the entirety of a project or large program or application.

Architectural Patterns

I found an article written on the blogging platform Medium which briefly explained the concept of Architectural patterns, which refer to higher-level guidelines and decisions made regarding a piece of software as a whole, rather than one specific problem within the code. This was confusing at first, but as the article provided brief explanations (and examples) of various architectural patterns, I was able to grasp the concept more conclusively. Now I will go into detail regarding two patterns I found likely to be useful and the kinds of programs they would be most applicable to.

The Layered Pattern uses a system of layers to group together similar functionality for ease of access and organization. Layers can set access rules for other layers (layer C has access to layers A and B, layer C only has access to layer B). For example, imagine a solitaire program, one layer controls drawing and taking input for interface components (windows, buttons, score etc) while another layer could contain the logical rules of the game solitaire, mechanics and random distribution of the cards (things the user would never need to access directly). For applications where there are a lot of similar behaviors which could be easily grouped into layers, the layered pattern makes a lot of sense.

Additionally, the Multi-tier pattern also concerns layers, in this case, entire systems (complete features, ie: user-input for input related features, display for display features) are grouped into tiers. A tier is a grouping of elements within the program which are interrelated, and seem most often used in web-related capacities or in online applications with various segments to consider (web browser, web, front-end and back-end could be potential tiers). Since each component or feature can only be part of one tier, individual tier choices will need to be carefully considered. Another major drawback is the amount of setup that goes into the process of implementation, since each of the tiers needs to exist as a grouping before the components can be assigned. I think this pattern would be most useful for large projects spanning multiple languages and technologies in the real world (web-applications for example, with front-end, back-end, browser components).

While I only highlighted two of the patterns discussed in this blog post, I think that layered and multi-tier patterns will be most useful for small-medium (layered) and large projects (multi-tier) in general.

Site referenced:

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


This week on my CS Journey I want to focus on REST API Design. In my last blog, I talked about how an API request works and how to be able to read the API documentation and use it effectively. In this blog, I will be emphasizing briefly the key constraints to REST API design. There are six important constraints to the design. Which are: Client-Server, Stateless, Cache, Uniform Interface, Layered System, and Code on Demand. Together, these make up the theory of REST.

Starting with client-server constraint is the concept that the client and the server should be separate from each other and allowed to evolve individually and independently. In other words, a developer should be able to make changes to an application whether on the data structure or the database design side at the same time it is not impacting the client server side. Next REST APIs are stateless, meaning that calls can be made independently, and each call contains all the data necessary to complete itself successfully. The other Constrain is Cache, since a stateless API can increase requests and handles large loads of calls, a REST API should be designed to encourage the storage of cacheable data. That means that when data is cacheable, the response should indicate that the data can be stored up to a certain time. 

The next constrain is Uniform Interface, having a uniform interface that allows the client to talk to the server in a single language. This interface should provide standardized communication between the client and the server, such as using HTTP with resources to CRUD (Create, Read, Update, Delete). Also, another constrain is a layered system. As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility. In REST API design, the same principle holds, with different layers of the architecture working together to build a hierarchy that helps create an Application. Also, A layered system helps systems to increase flexibility and longevity and it allows you to stop attacks within other layers, preventing them from getting to your actual server architecture. Finally, the least known of the six constraints is Code on Demand which allows for code to be transmitted via the API for use within the application. Together, these constraints make up a design that operates similarly to how we access pages in our browsers on the World Wide Web.

Overall, I learned the most important aspects of REST API Design. The blog was certainly helpful to understand the key constraints very well. I have only mentioned the main important parts of it. I highly recommend everyone taking a look at the source below. 


From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Agile Methodologies

I learned about agile methodologies in one of my classes in Worcester State. At first I was confused and didn’t make sense to me but then after I read some more and started practicing with my classmates I saw the benefits of it. As Alistair Cockburn says: “Process and technology are a second-order effect on the outcome of a project. The first-order effect is the people.”

We cannot manage teams of programmers as if they were systems made up of components driven by a process. To use Alistair Cockburn’s phrase, people are not “plug-replaceable programming units.” If our projects are to succeed, we are going to have to build collaborative and self-organizing teams.

Those companies that encourage the formation of such teams will have a huge competitive advantage over those that hold the view that a software development organization is nothing more than a pile of twisty little people all alike. A gelled software team is the most powerful software development force there is.

Over the past 25 to 30 years agile innovation methods have greatly increased success rates in software development, improved quality and speed to market, and boosted the motivation and productivity of IT teams. From what I remember from my class is that we always played roles to feel that real work environment.

An agile software development process always starts by defining the users and documenting a vision statement on a scope of problems, opportunities, and values to be addressed. The product owner captures this vision and works with a multidisciplinary team (or teams) to deliver on this vision. Here are the roles in that process.


Agile processes always begin with the user or customer in mind. 

Product owner

The agile development process itself begins with someone who is required to be the voice of the customer, including any internal stakeholders. That person distills all the insights, ideas, and feedback to create a product vision.

Software development team

In agile, the development team and its members’ responsibilities differ from those in traditional software development.

There are different agile methodologies but I would say my favorite is scrum. It focuses on a delivery cadence called a sprint and meeting structures that include the following:

Planning — where sprint priorities are identified

Commitment — where the team reviews a list or backlog of user stories and decides how much work can be done in the sprint’s duration 

Daily standup meetings — so teams can communicate updates on their development status and strategies)

I learned a lot about methodologies online though a web that our professor enabled for us. Unfortunately I don’t remember the name but if you go online and search there are a lot of good websites who will give you a good explanation of how it works. One of webs that I like to read about it is the infowrold that gives you a good explanation on how these methodologies works.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Need for YAGNI

For this weeks topic, something I that I chose to learn more about and get a better understanding behind of is YAGNI; which stands for You Aren’t/Aint Gonna Need It. To supplement my understanding for this topic, I watched a small conference video about a Software Architect, Ian Thomas, who gives a talk about the importance of YAGNI in real world environments. Throughout the talk some of the main points were that YAGNI reduces costs, and he also gave fixes or solutions for promoting YAGNI in work environments; and he also gives examples from his experience to better explain the importance of YAGNI.

Throughout the talk, I enjoyed some of the quotes and references he brings up because I thought they were powerful and changed my perspective of the software industry. In his introduction he brings up a Uncle Bob quote, which was ‘the number of developers in the world doubles every five years’; and then he points out that means half the developers entering the markets have less than 5 years of development. This is actually a worrisome quote when considering that one of the less experienced developers may be working on an airplane or automobile system that I may use in the future; however, Ian brings up this point because it ties to another reason for promoting YAGNI. This benefit of YAGNI is making material easier for new hire ups to understand and pick up; he refers to this as carry costs improvement.

Out of the other costs benefits he covers, he says that reducing carry costs is an important benefit of YAGNI often not acknowledged; it is also one I was not aware about. Carry costs may refer to the impact given from writing a new feature and when YAGNI is not upheld this often means that a new feature is overly complex, which would mean that it would take someone too much time to read before adding on or working in conjunction with that feature; this would also make it harder for new hire ups to pick it up. It appears that the code smells needless complexity and obscurity are byproducts of the absence of YAGNI in code.

Rather Ian mentions something important to think about when writing a new feature. A recurring theme that he brings up is thinking about the future; and so think, about writing/refactoring in a way that it’s not going to be too hard to write later on because you’ve taken the time to leave it in a good state now. And the quote he used for this was “it’s better to do a simple thing today and pay little more tomorrow to change it if if it needs it, than to do a more complicated thing today that may never be used anyway”.

And his takeaways to keep up YAGNI were narrowed down to keep things simple, to change things in small increments and also test them so you get to understand how the system is working and what you’re doing for your customers. Also he advises having courage in being able to stand up and explain why you are doing something and need to take the time to do it.

Link to Video Below

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

Keep Your Head Down Soldier

The pattern “Stay in the Trenches” talks about how you should avoid climbing into management or other positions that don’t involve coding when offered them. The pattern suggests that you suggests alternatives, such as pay raises and other incentives that can be offered to you, if a person is offered a job in management or another job that pulls them away from coding. The pattern also talks about how taking a management job can lead to loss of skill when it comes to programming since it wont be a daily occurrence for the person in management. The pattern talks about how a person should, as the name suggests, stay in the “trenches” or in a position that involves coding directly and where they can continue their craft. The pattern hopes to convince people that they should focus on excelling in their passion of coding and find other ways to be rewarded for their work, instead of pulling a person away from coding.
I feel like this pattern makes a great point that was discussed in the pattern “Practice,Practice,Practice”, which is that when people don’t code for a while, then they will most likely see a drop in their coding abilities and lose most, if not all, of the progress they have made. I think it’s important for any person in the computer science field to do things that interests them the most, either with the work they do, a side project or both. I can see myself continuing side projects of my own as a hobby even when employed in a coding job to not only further my skills, but to do things that I find interesting, fun, or both. I don’t fully agree with this pattern and believe that if offered the opportunity to get into a higher position in a field I’m interested in, I will, most-likely, take the opportunity as a chance to further my career and myself as person. While coding will always be one of my passions, I can not stop myself or hold myself back from trying to reach higher and higher goals in my career and life.

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.

Learning how to Learn

Tonight I am continuing with my reading of the Apprenticeship Patterns with toady’s pattern being “The White Belt”.

This pattern helps to explain how to get over the obstacle of learning and implementing new information after mastering “your first language”.

This pattern feels applicable to me as I feel this is the stage I have reached with the first language I learned. I particularly connect with the problem area that describes a difficulty with learning new tools as this is something I feel I am beginning to run into (especially with Angular) while learning new tools for my work on the UpdateGuest project.

I do think that I try to take the approach mentioned in this pattern of forgetting what I know when learning new tools, but I think that now I am more consciously aware of the value of this I think it may further help with how I learn.

I also agree with the point this pattern makes about being afraid of looking bad when trying something new. I recognize that this has held me back in some of my work this semester as I did not want to commit code that I was unsure of. With the help of this pattern, I realize that I need to get over this fear and not let it hold me back.

One of my favorite parts of this pattern is the example code. I appreciate how the beginning of this is in Java, as this makes it easy for me to understand and it makes the comparison more meaningful. The real beauty of the example is how the multi-line Java snippet is condensed into one small line in the J implementation. This vastly condensed (and somewhat strange to me) implementation really helps me to appreciate and understand the point this pattern makes of needing different approaches when using new tools that are unfamiliar from what you already know. This example makes me want to take up this challenge of learning something that is new and completely the opposite from what I already know.

For me, I read this pattern at a great time, and I even wish I had read it earlier this semester as it could have helped me with my work developing for LibreFoodPantry. I am going to make a point of keeping this pattern (and the cleverly quoted advice from Yoda in The Empire Strikes Back) in mind as I continue to learn about new tools this semester.

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.

Dig Deeper

With the final sprint of the semester underway, I have had to learn several new technologies for our LFP microservice over the semester. This has led me to obtain only the necessary knowledge to move forward in the project. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,by Dave Hoover and Adewale Oshineye, has a pattern that addresses this problem: “Dig Deeper.”

“When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge. Your goal should be to understand the historical context of the concept and whether it is a special instance of something else.”

The apprenticeship pattern, “Dig Deeper,” discusses the downfalls of having a shallow knowledge base and the need for obtaining a deep knowledge of how the tools and technologies work. There are several advantages to having this level of understanding, including: improving confidence, providing a starting point when joining a new team, and improving interview skills. The pattern refers to programmers with this knowledge as “cathedral builders.” These “cathedral builders” can debug, decompile, and reverse-engineer code. The best way to obtain this knowledge is to read specifications and familiarize yourself with debuggers.

The need for this pattern’s practice is like the need to learn history. Learning the history of a tool or technology will prevent repetition of previous mistakes and illuminate the reasons for the inner working’s current state. In addition to learning the history, it is important to dive into the different layers behind the tech and learning how the system works as a unit.

I realize my current understanding of the technologies I have been using for our LFP microservice is shallow and now, I have a direction I had not thought of looking into yet, debuggers.

A problem I have with this pattern is deciding where to start, as any time used to dig deeper is time that cannot be used for learning a new tech. This problem will likely resolve itself, though, once I decide upon a career path. For now, I can just dig deeper into our LFP microservice’s technologies: MongoDb, Node.js and its packages, angular, docker, and all the testing frameworks.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

The White Belt

The overall idea of the white belt apprenticeship pattern is that when you are learning a new skill for example a new language you need to actually need to learn a new skill and a new process. You can’t just apply the old process to the new skill. That will only result in, as the pattern says in its programming example, “writing fortran in any other language”. It says you can accomplish this by unlearning some of your previous skills and starting from scratch with the new skill. It also says that many people are scared to do that because they worry about looking foolish or ignorant. In the example of learning a new programming language it’s important because if you don’t unlearn some of your habits from a programming language you already know and unlearn how to code in that old language you will end up never learning how to use some of the new features of the new language. This is the overall idea and point of the white belt apprenticeship pattern.

I like and agreed with applying this pattern and its main point. I like how it says that in order to learn something you have to start from the beginning and let go of how preconceived notions about how code should be written. I agree with how it says if you don’t do that you won’t be able to write in the new language the way it was meant to be used. I also agree with how it says also that if you dont you will miss out on some  features of the new language.

I found a lot of it interesting and useful. I found it interesting how there was a saying about writing a new language like the old language. I found it useful to remember that when learning a new language it’s important. I found it thought provoking how it says that it’s important to unlearn before you learn. It’s kinda the opposite of what you would think at first. However it makes sense. I will definitely keep this in mind and use this in my future career when learning new languages or skills. Overall I really like this pattern.

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Beginning the Patterns

This evening I began my reading of the patterns in Apprenticeship Patterns, starting with the first pattern “Your First Language”.

This pattern provides guidance in selecting the first programming language you will learn as more of a beginner and the importance of this first language. The pattern also explains how to move on from this first language to learning others.

I liked this pattern as it let me reflect about my overall usage of Java, the first language I truly learned as a computer science major. Reading this pattern has made me question my usage of this language and particularly if I over-rely on it. I am also wondering if this is the best language to continue using or if I should switch to another language as my primary programming language.

I agree with the advice given of picking a real project for helping to learn a language. This is what I would like to do more of with my side project, and I would like to use this project more for learning new tools and languages.

I liked the idea of using tests as a way to verify your comprehension of a language, instead of just testing the code. I particularly like how this idea is a different approach to thinking about testing and its usage and how to use testing when starting out with a new language. This point is definitely something I want to keep in mind when I learn new languages.

Additionally, I liked the idea of picking languages according to the knowledge the people you know have. With my experience, I agree with this sentiment and I think there is a lot of value in having someone you can go to that can help you get back on track with coding problems. At the same time though I do somewhat disagree with this idea and I think that someone should decide on which language to learn based more on the availability and quality of the resources available for learning a tool or language. The reason for this is that I would prefer to have a reliance on resources rather than having to rely on someone else.

I further agree with the notion of getting “stuck” in the first language you learn. This is something that I am afraid of doing, especially with the longer I use Java as my primary language.

This pattern has helped me to reflect on my current knowledge and usage of programming languages. It has increased my wanting to learn a new language and I will keep it in mind as I switch to learning and using new languages.

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.

Apprenticeship Patterns: Sustainable Motivations

This week, I would like to discuss the “Sustainable Motivations” pattern. This pattern explains that professional software developers often must work on messy projects with unclear specifications and conflicting demands. Such chaotic projects are exhausting and frustrating to work on, which can cause developers to lose their motivation to pursue software craftsmanship. The pattern’s solution emphasizes that developers need motivations that will adapt to the difficulties presented by these projects. Developers should have multiple sources of motivation so that, when is damaged by an infuriating situation, they will have other reasons to push through their frustration until the situation gets better. The pattern recommends writing down our different sources of motivation to help us understand which are the most important. When we find ourselves loosing the desire to continue developing software, we can refer back to this list to remind us why we should continue.

As I have explained in my past couple posts on Apprenticeship Patterns, I have really been struggling with motivation over the last few years. Many software-related projects I have worked on during college have been exhausting, frustrating, or unclear. I found it difficult to complete such projects because I simply couldn’t find the effort to work on them. This pattern resonated with me because it focuses on this very issue. I especially relate to the second bulleted example given by the solution, which describes a developer whose main motivation is their enjoyment of programming. For me, this was the main reason I decided to pursue software development, and it has been discouraging to feel that enjoyment dwindle.

However, the developer in the example continued programming due to financial motivations despite a loss of passion, and they eventually regained their love for programming. Similarly, I have continued to pursue software development because of my desire to finish college. I’ve never really considered my education to be a reason to program, but in retrospect it has clearly been my main motivation for the past several years. Clearly, reading this pattern has helped me think differently about my motivations. I’ve always thought my enjoyment of programming was the only motivator I had, but I now realize that other factors, like finishing college and gaining experience, have actually been motivating me more. Hopefully, these other motivators keep pushing me to continue programming until I am able to regain my passion for it.

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.