This apprenticeship pattern discusses how software developers should prioritize placing their desire to give useful products to customers over their desire to create novel and fantastic code. Given the choice between using a simpler, proven solution and taking the opportunity to create something innovative and artistic, software developers should always choose the latter. This is because if software developers are to be considered craftsmen, then they need to focus on the craft. If a software developer loses their job because they keep creating beautiful code that customers simply do not find useful, then they have left the craft. This does not mean that the software products developed can not be beautiful, they can be, but they also must be useful and provide value to the customer. This apprenticeship pattern is about how software developers should develop the ability to sacrifice beatify for utility when it is necessary.

However, this apprenticeship pattern is not only about sacrificing art for craft, but it also encompasses the idea that the craft should always maintain a certain level of quality. Every piece of software produced should meet a set of standards. Being able to hold on to these standards will ultimately help develop an understanding that beauty and utility are not opposites, but interdependent. The more important a piece of software is, the more important that the software be of high quality. To achieve quality work, software developers must constantly make tradeoffs between beauty and utility. However, the tradeoffs we make might not always be the right ones, and so learning how properly refactor and repair code is essential to fixing our mistakes and correcting the balance that is desired.

I think this is an important apprenticeship pattern to learn because every software developer needs to have the skill of being able to strike a balance between beauty and utility in their code if they wish to be craftsmen in the craft of software development. I personally never gave much thought about striking a balance when writing code before reading this pattern. However, from now on I will start reconsidering how I should prioritize my desires when writing code to try and strike the right balance between usefulness and art.

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

“You have to spend money to make money.” – Peter Griffin (Family Guy)

This quote is probably one of the most familiar antitheses to the idea of “one step forward and two steps back”. Alongside this week’s reading of “Apprenticeship Patterns”, we are going to figure out how retreating into our competent “safe zones” can actually be a beneficial way to make progress into unknown territory.

In essence, the pattern describes about finding an “acceptable limit” of disregarding challenges in order to polish up on familiar material. By finding patterns in previous progress, we can empower ourselves to embrace the challenges of the unknown. It is important to note that the “limit” is respected – going too far ahead into the unknown leads to a lack of progress from ignorance. Retreating too far into the safe zone causes another lack – from fear.

I understand that taking some time to work on an easy, familiar project is a great way to create a productive sabbatical. To be honest, I have been practicing this pattern long before reading up on it; making familiar homework assignments and simple games has been a hobby of mine. Plus, once skills are learned with a “back of our hand” level of proficiency, it makes the mind bored with these tasks – it craves something more novel, no matter how challenging.

“Retreating Into Competence” stresses that we must make the regression quickly turn into progression, otherwise we may end up in a rut. While I don’t necessarily disagree, I wonder if there is a way to “charge the catapult” for an even greater forward effect. Exactly how far can we pull back on our efforts towards familiarity in order to shoot ourselves among the star s of the unknown? Is minimizing our refreshment emphasized because the “catapult method” has a short charge limit? My interest for these questions makes me want to experiment with the pattern (this would be best done in conjunction with some Breakable Toys).

In order to use this pattern professionally, I need to start thinking about time. Every moment of the past that I can regress to, was at one point “an unknown future destination”. Figuring out the methods on reaching these past points can lead to notes for successful exploration of a project’s future. Analyzation of the past should be done as scientifically as possible; getting wrapped up in the nostalgia of success or wallowing in the failure will cause us to miss the future that lays ahead.

Fun fact: this pattern itself is a “regression”; I am doing it by using a token to go back to Week-4.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

               When working with a Java program, one of the strongest tools to ensure it is functioning is Junit testing. Junit testing makes it easy to take a glance and see if all properties of your code are functioning correctly. Despite this however, at the end of the day, the product must be able to seamlessly accept and output data in a usable form. Therefore it is important to understand how to use temporary test files when using Junit.

              Andrew Binstock’s post fits in with regards to the currently assigned homework which sees us utilizing test classes and modifying them as the code is refactored. These tests allow us to ensure that the written code is working properly. To build upon this idea the post linked below presents the idea of Junit testing with temporary files to read and write to. Within this post is sample code which creates temporary files in and out of Junit testing.

Below we can see a snippet of code from the original blog post which shows temporary files being used in a Junit test. (Andrew Binstock)

import org.junit.jupiter.api.*;
import org.junit.jupiter.api.io.TempDir;

import java.io.*;
import java.nio.file.InvalidPathException;
import java.nio.file.Path;

import static org.junit.jupiter.api.Assertions.*;

public class TempFilesJUnit5Test {

Path path1, path2;
File file1, file2;

/* This directory and the files created in it will be deleted after
* tests are run, even in the event of failures or exceptions.
*/
@TempDir
Path tempDir;

/* executed before every test: create two temporary files */
@BeforeEach
public void setUp() {
try {
path1 = tempDir.resolve( “testfile1.txt” );
path2 = tempDir.resolve( “testfile2.txt” );
}
catch( InvalidPathException ipe ) {
System.err.println(
“error creating temporary test file in ” +
this.getClass().getSimpleName() );
}

file1 = path1.toFile();
file2 = path2.toFile();
}

               Within the second homework assignment we can see that Junit tests are used to ensure that the different classes of ducks and working properly and that the data output is correct. Some of the Junit tests scan the output file and compares it against the expected output. While this is useful to ensure the code works, it is also important to consider that not everyone will want their output confined to the terminal. This program could very easily be modified to output to a text file for data collection purposes. Testing this with Junit would allow the creator to ensure that data is being retained properly before running the program in a real case scenario.

Testing with temporary files was previously an underutilized method of testing due to older hardware being much slower and older drives using spinning magnetic disks rather than modern solid state storage. In the post we see the author discuss this dated policy and encourage the use of test files to create a more thorough testing method. Some might want their output in a text file or as an output to a front end for a website. Junit tests with temporary file allow you to test for this functionality as these temporary files can be created, read from, written to, and are all deleted at the end of testing to keep drive space free from clutter.

Bibliography:

Binstock, A. (n.d.). Working and unit testing with temporary files in Java. Blogs.oracle.com. Retrieved October 11, 2021, from https://blogs.oracle.com/javamagazine/post/working-and-unit-testing-with-temporary-files-in-java.

Working and unit testing with temporary files in Java (oracle.com)

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

For this week’s assignment, exercise #2, I had an opportunity to refactor a poor design of Duck Simulator using the factory pattern. It was nice that I could approach this design pattern step by step and learned its definition by understanding why I had to create an abstract method or why I had to create a factory class. Moreover, after skimming through a long chapter, Chapter 4. Baking with OO Goodness: The Factory Pattern, although there are many important definitions in this chapter, I believe that there are two concepts that I shouldn’t miss, the factory method and the abstract factory. Both are new tools that I need to know what they are and how to apply them to a design.

Furthermore, for better understanding, I also wondered what was the difference between factory method and abstract factory. Although, the textbook has a comparison between those two concepts, but for myself, it was long and difficult to follow till the end. So, I did a few searches to see if there were any good resources that I could take a quick look at for my question. I found a good blog, called Factory Method vs Abstract Factory. In this blog, the writer makes some comparisons to show the difference between factory method and abstract factory. Through the blog and the textbook, I know that both concepts are used to encapsulate object creation, and they apply the dependency inversion principle by allowing coders to decouple code from concrete classes . On the other hand, the two concepts differ in many ways. First, the number of products produced is different. The factory method is used to create only one product while the abstract factory is used to create families of related products. Second, for the factory method, the object creation is decided by subclasses (depending on inheritance), whereas the abstract factory has a separate class to creates a family of products, then its object can be passed to client class for using (object composition). Next, it is the level of abstraction. Since the abstract factory are at higher level in abstraction, we can use factory methods to create products in factories.

For myself, this is a resource worth referring to because its concise, well-organized content helps readers easily distinguish the difference between the two concepts. Thanks to this resource, I got a better understanding of the factory pattern, especially the abstract factory and factory method, which is really helpful for my diagram design latter.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Ever since the beginning of my programming career, I have had a plethora of professors provide several sayings that were helpful to becoming a better software engineer. One particular saying was acquired only a few weeks ago, during my Software Construction course. The saying goes: “YAGNI”, or when extended beyond the acronym: “(Y)ou (A)in’t (G)onna (N)eed (I)t”.

YAGNI is a useful term when considering one particular coding smell: Needless Complexity. Novice programmers often believe that they need to somehow squish every keyword, conditional statement and data structure into one massive, impressively diverse program. Yes, it is definitely useful to be knowledgeable in all of these areas. However, an advanced understanding of programming requires that one not only knows the skills, but also when to use them.

The article listed below (created by legendary software engineer Martin Fowler) explains the various reasons why YAGNI is so important. Specifically, it explains different kinds of “costs” related with unnecessary complexity: Costs of building, repairing, delaying and carrying the software. Considering these costs is such a crucial factor due to the fact that software should be designed to be cheap for the producer, yet effective and “easy-to-use” for the customer.

Understanding YAGNI, and its effectiveness against needless complexity, is invaluable to achieving proficiency in software design. The class does not want us to build products “per se”; rather, it already expects that we can build the block from the get-go. Instead, this class focuses on “whittling away” at the back-end block to create something more beautiful and beneficial.

If anything, based on the material that Martin Fowler has presented to us, we need to take a look at our code and ask ourselves: “is this really necessary?” Do we really need this exception case if the chances of achieving the error make the lottery look like a safe bet? Are these security features needed when a simple password check can cut the mustard? Cutting down on needless complexity is a rather easy smell to work on, since the problem is based on our ability to work harder than we really need to. Instead of remembering every last line of code, we should remember the abstract ideas, and learn how to translate/implement them.

In conclusion, I believe that “YAGNI” is an essential saying that every programmer should know by heart. In addition, I strongly believe that the sooner a junior programmer can learn this rule, the better off they’ll be in the world of software design. The best way to avoid certain coding smells (such as viscosity) and technical debt is to instill proficient programming practices that avoid these problems to begin with.

Link: https://www.martinfowler.com/bliki/Yagni.html

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

After the past few activities in class I was trying to think of what I wanted to look for to do my first blog post on. The one topic that caught my attention and I wanted to look more into was Design Patterns from activity 4. The strategy design pattern that we used in model 8 to improve the DuckSimulator seemed very effective to me, and I wanted to look more into design patterns after reading a bit about them in models 8 and 9. I found a blog post that goes over the strategy design pattern and when reading it, it went more in depth with the pattern than I thought it would based on the title of the post, “Keeping it Simple with the Strategy Design Pattern”, from Bits and Pieces.

The post briefly goes over Object Oriented Programming, then it focuses on the different aspects of the strategy design pattern. The parts of the pattern that the post goes over are its basic idea, structure, examples, authentication strategy, the problems it solves, SOLID principles, how it’s used in JavaScript, and when to use it.

Some of the material was familiar to me from previous courses that I didn’t think would show up, but it made sense that it did, such as the sorting algorithms, such as bubble sort and linear search, being used for the strategies being represented based on the data and objects in the program. Diagrams used for the pattern also were very similar to the ones used in the activity to show the structure of the pattern with the implementation of context, interface, strategy, and concrete strategy.

What was less familiar to me where the authentication schemes and strategies, such as basic and digest, that are brought up later on in the post. I did not know the specific schemes brought up, but I got the idea behind their usage for authenticating data in the program. The schemes were also used in examples for the strategy design pattern by showing an interface being used to have an authentication method that is implemented by the schemes.

The main problem resolved by the pattern is the hardcoding of the program, which can make in run less smooth and more complex/complicated than it needs to be. Using a pattern prevents this by breaking down the program into different tasks and classes that keeps the algorithms more understandable and usable. This is reflected in another example with a given Printer class with multiple classes, but is also shown in the final DuckSimulator version.

In conclusion, the strategy design pattern is effective at improving complex programs, keeping the classes manageable, and keeping the methods and algorithms separated from each other.

Link: https://blog.bitsrc.io/keep-it-simple-with-the-strategy-design-pattern-c36a14c985e9

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

YAGNI has two different meanings: You Ain’t Gonna Need It or in other words, You Aren’t Gonna Need It. YAGNI has appeared differently as the main principle that has been used in the extreme program. This principle stated in a different interpretation is:

“Always implement things when you really need them, never when you just anticipate that you might need them.”

The reasons why this principle exists are various. As a start, it makes it possible to maximize the amount of unnecessary work that remains unfinished. This is a very good way to improve the productivity of the developer, but also the simplicity of the product. One thing to keep in mind, these features are very expensive, both for development and maintenance. It is also important for users, so that they have the opportunity to learn, but also to navigate around. But those features seemingly are not necessary, in fact, they are a very large source of waste.

 Yagni Advantages

Here are some reasons why YAGNI should be used:

-Save time in the same amount of money (saving time and money is equal), and this is the main factor but also the most important

-gives you the opportunity to use a much easier code, good but most importantly “thoughtless”

-makes available the deadlines

-ensures that the client is happy with the very frequent but also obvious changes that are in line with the specifications

-code has better quality, notice this from the fact that many developers focus on just one even smaller task they may be doing (tasks which are more important at the moment)

last but not least, that code has the property to be more extensible.

Yagni design principle

We will not need this program much. Extreme Programming (XP) says that a programmer should not add the functionality he has until it is considered necessary. So YAGNI translates differently – You will not need it. Extreme software is generally used in the Agile software development process. According to this principle, we should not add any functionality until the moment when it is deemed necessary, in other words, to write the code which we need in the current situation.

YAGNI in Agile/XP

Many people may remember that this principle is called “stupid” and that the requirements it has should be prepared even better. But those people who work in the slightly more advanced methodology or, as they say, “agile” should take into account the possible changes that the client’s requirements may have. For this reason, the subsequent tasks in most cases depend on the results of the current status of this project, but that over time this result may change.

If at the same time we develop many features that “maybe needed” as a start, we lose not only the time but also the effort that has been needed to complete it. There are also cases when we waste the time we spend refactoring or fixing them as these interventions may be redundant.

In general, developers should never rely on different assumptions because they are likely to prove that they are not worthy and capable of the effort and time a programmer needs.

Refereces:

https://www.plutora.com/blog/you-aint-gonna-need-it-yagni

https://jasonmccreary.me/articles/practicing-yagni/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

This week, I wanted to learn more about the design patterns we discussed in class. After completing the homework, I saw how each of the design patterns we had used could be stacked on top of each other to make more efficient programs and find solutions to common programming problems. So naturally, I decided to seek out a comprehensive list of the Gang of Four design patterns to learn more about them. While looking into this, I found a blog post by Madhura Oak entitled Design Patterns – Revisiting Gang of Four that seemed to fit the bill.

In this post, Oak explains how the “Gang of Four” came up with a list of design patterns that solve common issues within programming, and laid out these patterns so they could be used in any language, and could help software designers write maintainable and easily readable code. In this, he explains the SOLID principles by Robert Martin, and uses these 5 design principles to help explain the usefulness of each pattern. The author also breaks down the 23 Gang of Four design patterns into categories depending on how they are used and gives examples of their use, which helps put into context why we would use these patterns in the first place.

After reading about all 23 of the design patterns, and having used both the singleton and factory patterns in the homework, I feel like I have a far deeper understanding of how these patterns can be used to create more efficient and readable code. They provide a framework for so many different types of abstraction, showing ways to structure your class hierarchies to improve your ability to modify, extend, and test code without having to slog through massive classes that are full of specific use-case scenarios. Using encapsulation and inheritance in the way they are used in these design patterns, code can become so much easier to document, test, and build upon. It becomes so much cleaner and more readable.

So far in class, we have only looked at what Oak classified as “creational” design patterns, as they mainly have to do with the creation and encapsulation of objects. However both “behavioral” and “structural” design patterns are also listed here, to help bring the same principles to the structure and behavior of the programs. Mixing these together within the full structure of a project would provide great benefit to the maintainability of code in the future, one of the most important parts of software design.

Overall, this blog post was a good introduction to design patterns and the principles that they help to achieve. In the future, I hope to use these patterns to help design code that is far more abstracted, and hopefully far easier to follow than code I’ve written in the past. I really like how easily followed the patterns are, and the way the post is organized makes it easy to find what you are looking for. If you are interested in further reading about more design patterns, I would highly recommend looking through this post, at least for a general outline of what they do and how they work.

Source:

https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I’ve decided to watch a video titled, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams. This video is actually part of a series titled, “Object Oriented Design” and in the next video Derek shows how to create code from the UML design he’s created. Since I will likely be making more UML diagrams in my educational/professional life, I figured it would be good to further develop this skill.

One of the first things Derek mentions in this video is that he will be showing both the analysis and design stages for this process. The program that Derek is tasked to create for this video is a coin flipping program for two individuals. One player selects heads or tails, the other player gets assigned the other coin side, and the winner and loser is selected. Derek starts this process with something called a Use Case Description. For this description, Derek has a basic text editor open with the following categories: description, triggers, actors, preconditions, goals, not available, and steps of execution. Derek goes through each of these categories and writes in the relevant information for the program he needs to create:

1. The description describes what happens in the program.
2. Triggers mention how the program/game starts.
3. Actors include the two players, the coin, and coin game.  
4. Preconditions lists the things that need to be true for this program to run (i.e. 2 players are available, a coin is available).
5. Goals list the outcome of the program (i.e. one player wins and the other loses).
6. Not available references potential invalid inputs and extensions on how to make the program better in the future.
7. Steps of execution describes what the program will do in a numbered list (each number represents a specific task).

Although this was only one part of the 30 minute tutorial, this was still an extremely useful process for me to observe Derek do. I learned how important it is to critically think about what you want your program to do before you jump into programming. I am definitely guilty of trying to jump into coding sometimes but I can see how cleaner and clearer code can be written by thinking and mapping things out in advance.

The thing I’m happiest about from this blog entry is finding this series and Derek’s YouTube channel. He has multiple tutorials on his channel that I can see myself learning a lot from. His videos are educational and thorough (many of them are 20-30 minutes long). As I continue growing as a programmer, I will definitely be referencing him to learn more useful information, techniques, and procedures.

Tutorial link: https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.