This week I decided to write about the Breakable Toys pattern because the last pattern that I wrote about mentioned this pattern, and it was in the See Also section of the last pattern as well. From the title, I have gathered that this pattern is about just random coding projects that have no consequences and the programmer can just experiment with the code and try out new things.

After reading the Context section i discovered that this pattern involves failure and learning from those failures in order to become a better developer. The problem of this pattern basically says that you work in a field that doesn’t allow for failure, but your individual growth depends on failure. This makes sense because there isn’t a lot of room for mistakes in a real work environment because mistakes can lead to much bigger issues.

The solution to this problem is as I mentioned earlier with slight differences. Rather than coding just random projects, you should code projects that “are similar in toolset” (Oshineye, Hoover). The authors recommend using Wikis as your breakable toy. They say this because of their simplicity. They also mention that they can be great for learning HTTP and REST which I thought was interesting because our Capstone involves both HTTP and REST, so maybe I should start working on a wiki on the side. Another breakable toy idea that they suggested that one of their ex-colleagues used is creating games. This is a cool tool because it is a fun way to learn how to code because at the end you are given a product that you can play with way after the fact. Realistically, you could just look up Tetris on the internet, but it is much cooler if you are playing something of your own creation. Lastly, they mention how this pattern is similar to Be The Worst which is actually what I plan on writing about for my next blog.

The Action section basically just tells the programmer to create a very simple wiki, and add features into it as you continue with your career. I like this method because there are no repercussions if you mess up and you can learn from these mistakes. I think that I will actually use this pattern in the future, and my internship has kind of done this for me too. The projects that are assigned to me are projects that they use in their day to day life, but I have freedom to make mistakes and learn from them.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Failure is an acceptance of what you are capably of. Not in a means of saying that you can not but in terms of stating that being aware of what you are missing. This prevents the boundaries that you are creating, such as giving up for being stuck at only one thing that you already know.

Failures are a big part in order to be successful. I have experienced it many time when learning my first programming language. I even decided to change my major to Business. 

At first it seemed really interesting and i was curious to learn more about how functions, objects and data works n java. I practiced and started ding the same problems again and agin until i had an idea of what the code was doing. But when I had a similar problem but it it was conned in different way I was lost. I ended up belly passing.

I then met one of my class mates, she was a minor and had better experienced then me in programming. She was really good at explaining. She taught me an easy was to adopt new skills. She told me which text editor to use, how to consume your time,being tim efficient, and which programming language is easier to understand.

“Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and a constant searching for new solutions.”

Atul Gawande, Better.

I applied those skill. I was still failing but was making progress, i was understanding what Mistakes I was doing. I was only missing out minor mistakes or I was sometimes rushing. But pointing out my mistakes I was ale to prevent myself to stop giving up on programming, 

Now as a senior I am not afraid to take th risk. I take failed as a new learning experience wirer I am able to apply my understanding in much more effiecnt way.

That is what the author is trying to tell. Many people see fair as a negative condition. However, It is a part of being successful. 

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

For my blog this week I choose to write to about the template design pattern. Picked it because I was recently learning about what design patterns were. So I was google and and came along a list of different ones and I liked the template design pattern because it seemed to be useful and fairly simple so I picked it.

The article first talks about how the template design pattern is used for the base of an algorithm where the steps always happen in the same order and sometimes some or none of them are the same most of the time. Then they talked about an example of an algorithm to build a house were the steps are always first to build the foundation then to build the pillars. Next to build the walls and last to build the windows. They also said that these have to built in the same order every time. Then they started talking about the first class which was an abstract template with the first method being a method to build the house which its self called all of the other steps in the process which were abstract methods. They also said the since the method to build the house was the algorithm to build the house it should be final so it cant be changed. They also you leave the step methods unimplemented or not if they are mostly going to be the same. Then for each type of house you create a new class to build it extending the template class while overriding the unimplemented methods or any methods you need to change.

This design pattern helps with the repetition of having to type the algorithm over and over for each subsequent class you make. It also lets you make reuse so of the steps if they never change. It does have some disadvantages though like how you cant change the order of the main algorithm and that you have to override most of the methods everything. So even if several of the implementations use the same step you still have to rewrite them anyway. I learned a lot from this article first of all I learned a completely new type of design pattern. I think this pattern is very useful especially with algorithms as they said. I also learned just by looking at the list on the website that were far more types of design patterns then I originally thought.

Template Method Design Pattern in Java

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

For this week’s blog, I have decided to go over the SOLID set of design principles. The blog article “SOLID design principles: Building stable and flexible systems” by Anna Monus describes SOLID and gives solid examples of each design principle with code and UML diagrams.

Single responsibility

Each class should only have a
single responsibility, such as handling data or executing logic. While this
increases the number of classes in a program, this will allow easier
modification of the code and code clarity.

Open/Closed

Classes should be open to extension
and closed to modification. This means that new features should be introduced
through extension and not through modifying existing code. The open/closed
principle allows programs to expand with new features without breaking the old.

Liskov substitution

Named for its creator Barbara
Liskov, the Liskov substitution principle states that a subclass should be able
to replace its superclass without breaking the properties of the program. This
means that a subclass shouldn’t change its superclass’ characteristics, such as
return types. Following this principle will allow anything that depends on the
parent class to use the subclass as well.

Interface segregation

Interface segregation states that
classes should not have to implement unused methods from an interface. The
solution is to divide the interface so that classes can implement only the
desired methods. I found this principle to be easier understood from a visual
example and I found the article’s UML diagram for interface segregation useful
for this.

Dependency inversion

High and low-level modules should
depend on abstractions. It is common to think that high-level classes should
depend on low-level classes, but this makes expanding the code difficult so
it’s best to have a level of abstraction between the two levels. The article’s
UML example for this principle shows how the abstraction level allows for easy
expansion.

The SOLID principles are important for code architecture as
it makes code expansion simple and easy to understand. I have found myself
applying SOLID principles to a project I have been playing with, a simple GUI
animation. Originally, I had drawn objects handling their own draw and movement
methods, but by using the single responsibility principle I separated the
movement-based code to its own class and used composition between classes. This
allowed for me to be able to use the movement code (contains position,
velocity, and acceleration values and methods) for all the different objects
that I make. I also made use of the O, L, and D of SOLID to handle the drawn
object hierarchy allowing my frame class to depend on an abstraction of all my
drawn objects. I use a loop to cycle through all drawn objects in a linked list
that’s type is an abstraction of all drawn objects. I can tell that the
structure of the code has made adding new functionality easy and intuitive.

Article Link:         https://raygun.com/blog/solid-design-principles/

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.

What is the RESTful architecture style and what is it good
for? Well I am here to break that down for you. REST stands for representational
state transfer, and it is an interface that can be implemented in order to help
with abstracting resources. In order for a system to be considered RESTful,
they must implement 5 guiding principles. The first principle is client-server
which deals with the separation of user-interface and data storage. The next principle
is that it must be stateless, meaning when information is requested, all the information
must be present and cannot be stored on the server. The next principle of REST
is that the data must be labeled either cacheable or non-cacheable. If the
information is cacheable, it is stored on a client cache. The fourth principle
deals with having a uniform interface. The next principle is the layered system
which allows for a hierarchy of layers to implement constraints.

Now that the principles have been laid out, the next main
part of REST is the information and data it deals with. A resource in REST is
the abstraction of information. Resources can be anything containing a name from
documents, pictures, and so on. REST then uses resource identifiers to be able
to find what resource is needed. Resources contain resource representation,
which is a timestamp of the resource containing the data, metadata, and hypermedia
links. REST contains resource methods which can be used for working with the data.
Many people associate REST with HTTP methods of GET/PUT/POST/DELETE however
since REST has a uniform interface, the user will be able to decide which
resource methods to use. However, with REST you are able to utilize these HTTP
methods in order to help with resources. The most common implementation has GET
to retrieve resources, PUT to change or update a resource and POST to create a
resource. Obviously DELETE is used to delete resources.

RESTful API’s are very beneficial when working with cloud
computing and working with the web. Because REST does not store any information
between executions; is stateless, this allows for the for scaling. This also
means that the if anything fails, it will be easy to re-work since nothing was
stored on the server. This makes it particularly useful for websites as well because
a user will be able to freely interact with the website while not storing any
information with-in it. If you want to read more on REST and RESTful API, look
into these two websites.

https://restfulapi.net/

https://searchapparchitecture.techtarget.com/definition/RESTful-API

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

I thought the title of The Long Road would make for an interesting pattern to read, so I chose it for this particular post. This pattern describes the path that a craftsman will have to take to become a master throughout their career. This is specific to becoming a master of software development and not particularly for what is traditional success in a career path that we as newly graduating software engineers are “expected” to follow.

For this reason, I honestly disagree with the general idea of this pattern completely. The pattern does make it clear that this is the path specifically for people whose life goal is to become the best at software development and does not seek anything else out of a career in software development. I don’t see this as the norm, or generally good advice in any regard. I also feel that it is important to state that this is merely my opinion, but also one that I strongly believe in. From everything that I read about software developers who stick strictly to software development throughout their careers, they often burn out but also feel that it is too late in their careers to do anything else. These are engineers in their late 40’s and 50’s who have been working for the same company for well over a decade and feel that their knowledge in software development is so narrow because of a lack of exposure to other tech and other business domains. While this is not always the case, this is just what I’ve read and have been exposed to personally.

The pattern also preaches how admiral it is to stick to this strictly developer mindset and how money and promotions should not be a focus for you. While I think that this is important to not be the only focus in a career, this is just silly. Promotions and salary should not be a measure of your success but they should be something we all seek, and a goal for people to strive for throughout their careers. The way this pattern is worded, it seems to try to even nudge readers away from positions like architects where you aren’t specifically writing code on a day to day basis. It wants readers to avoid big picture positions and exclusively stick to coding. There is always more to learn in coding and we should all do something we love, but coding should not be the only aspiration for our careers. For that reason, this article has not changed how I will approach my career, but possibly reinforced the goals I previously had.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.