For this apprenticeship pattern, I chose Be the Worst. This pattern is about joining a team with much greater skills than yourself in order to learn from them, and as to not stagnate your learning by being on par, or more knowledgeable than your other team members. The issue with this concept is that if you join a team of members much more knowledgeable than yourself, you could be seriously behind and unable to complete any of the tasks required by the team, thus becoming deadweight and dragging the team down. The solution it proposes to this problem is for you, as a less knowledgeable member of the team, to do the more menial tasks.

I think this is a really clever solution to this problem for a few reasons. First, it allows you to still help the team, and not just be deadweight or an observer. If you were actively slowing the team down, or worsening productivity, then they would want you off the team, so it’s important for you to still be contributing something worthwhile, even if it isn’t huge. Second, since you’re doing menial tasks, it’s likely stuff that other team members don’t like doing or would rather someone else do. They would be better off using their time for more advanced tasks, so by doing the menial tasks you’re helping them and saving them time. In this way, it actually leads to more productivity for the team. Lastly, by doing menial tasks, as long as they aren’t too difficult, it means that you can still conserve most of your energy towards learning from the other team members.

I think this apprenticeship pattern presents strong and useful information, and I couldn’t find anything I disagreed with. I could relate to this pattern because I have been on teams where I was either the most or least experienced, and I didn’t like either one. Being the most experienced, you will always have to help out the other team members, while you could maybe be more productive doing other tasks. Being the least experienced, you often feel like you aren’t doing or contributing enough. This pattern has changed my view, as I now think that being the least experienced is better than being the most experienced, and I used to think the opposite.

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

The Long Road is meant to temper expectations. It lays out the path to mastery of software development as one of lifelong learning, and not one of chasing wealth or position. It is about taking jobs and opportunities that will help you continue your journey to gain more experience and knowledge and to prioritize this over promotions and salary raises. It is about finding the knowledge at the heart of software development.

I think that not only is this pattern good advice to software developers but offers good life advice as well. I personally believe that life is about the journey and that new experiences and gaining more knowledge is far more important than gaining more monetary wealth. I don’t care too much about money in general and I think that having this mentality about moving forward in my career lays out a life that will leave me a lot happier and more content when it comes time for me to leave it all behind. I didn’t get into computers to take a middle management job, I came here so I could enjoy what I do and get really bloody good at it. I just found the part about growth over wealth to be such a good way of looking at software development, and I think is kind of the opposite of why a lot of people get into it. I feel like a lot of people get CS degrees because they want to make money, and not so much for the love of the craft, and I think that’s just a path to disaster. I hope I’m wrong, but if you can learn to love the journey I think you’ll have a lot more fun along the way.

However, I do disagree with the notion that this pattern (and this book, as they say) is not However, I do disagree with the notion that this pattern (and this book, as they say) is not for people that want to take different paths. I think it is entirely reasonable to believe that even those who don’t want to continue a software development career for their entire lives still want to master the craft and continue their development journey even if they choose not to continue down a career in it. There are many people who don’t pursue full-on careers in software development, but still love coding and want to continue to grow their skills. Hobbyist game designers or developers are out there, and I think that that choice is completely valid and that this pattern still applies to those that choose something else. I just don’t like the gatekeeping nature of that comment in this pattern. Mastery does not necessitate a career in development. Do what you want, and enjoy the journey.

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.

This is the first in a series of short blog posts I will be making about the book “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, discussing individual patterns from the book. This week I am looking at the pattern called “Read Constantly” from chapter six.

The scenario this pattern covers is one in which a programmer is feeling overwhelmed by new information. This is happening even in spite of a good amount of proficiency and enthusiasm. The proposal here is to read constantly in order to catch up on old developments in the field and stay ahead of new ones as much as possible. This also means prioritizing denser sources of information such as books or occasional research articles over things like blog posts, for example. The authors also suggest keeping a small (and thus easily portable) book on your person at all times to read whenever you have downtime.

I don’t really read as much as I would like to. It’d be good to do more reading, especially about the software field, so I think that is useful advice. I have some issues with the framing of this pattern, though.

I don’t fully agree with the outlook of “catching up” to people like Linus Torvalds, who the authors namedrop here, or with how the authors view people like him. I don’t think, taking Torvalds for instance, that he got where he is purely through effort. This isn’t to say that he’s lacking in talent in any way – rather that he got where he was through a combination of being a highly motivated person and being in the right place at the right time in the industry. I don’t think you can make up the latter part through sheer effort alone. I view it as sort of like the lottery – it’d be nice, and you could increase your chances by buying tickets regularly, but it’s misguided to have winning the lottery as a goal when it’s ultimately out of your control.

I think it’s good to read more, of course. I just don’t agree with constant reading specifically as a way to stay “competitive” in the software industry. I do not have the background to make this kind of claim, but I also suspect there’s diminishing returns when you try to cram as much information into your head as possible.

Having read this section, I think I will actually read more, or at least make some effort to. I’ll also probably try to read more about programming and technology specifically. I just don’t think I will take it as far as the authors recommend.

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

This week I chose to write about “Your First Language”. The problem laid out in the beginning of the chapter is that the apprentice only knows basic knowledge of a few languages. This is a problem I have spent some time thinking about. But it is difficult for me to pick, which language I want to fully dive into. I have programmed in Java, JavaScript, C#, C++, and Python. I know the Java standard library better than any other language’s library. And I know the data types, and data structures better in Java as well. Java is what I learned in Intro to Programming, and Data structures. Java is also what I use for coding interview prep. Many of my peers are language Evangelicals, but I feel like a man without a country. I have never built anything in Java, that wasn’t an academic project, or a coding interview problem. I have used JavaScript and C# do build web apps. With all of this being said, I knew I needed guidance from this design pattern.

The author suggests that the apprentice choose one language to solve problems with. And stick with that language for years. And that his first language will be the basis on which he solves problems. For me, I think I am going to let fate decide. Whichever language I need for my first job, that language will be my first language. Many entry level software job postings just say ” “proficient in one modern language” and the assessment can be taking in any language. The author suggests that the apprentice seek out an expert in the language, so he learn from the expert. When I am on the job, I will have access to experts, and a lot of time to learn. For now, I will keep practicing LeetCode in Java, and build web apps in JavaScript for this course. I don’t have time for much else. But this design pattern has made me realize how important having a strong foundation in one language is, and I am eager to start working towards that goal.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

After looking at the list of Apprenticeship Patterns, the one titled “Be the Worst” caught my attention. I was curious as to why you would want to be the worst. After all, conventional wisdom would suggest that one should try to be the best. However, after reading about the pattern, being the worst is a way to become better. The pattern explains that you should aim to constantly surround yourself by developers that are better than you. By doing so, you would give yourself room to grow. Being in a strong team gives you an opportunity to learn the effective techniques, tips, and methods that stronger developers use. The goal is not to constantly remain the worst, but rather, to work hard to climb your way up from the bottom and become equal to the other members.

However, there are a few risks with being the worst. One of these risks is feeling bad about yourself and your skills. Being the worst member of the team means you are not up to par with everybody else, and that could lead you to become even less productive. Another risk that you could run into is dragging the team down. Being the weakest member, some teams might not tolerate your weakness for long, especially if you do not put in the effort to constantly improve and hone your skills. If you fall too far behind, then you risk getting fired. The way to avoid these risks is to make yourself useful by doing explicitly doing menial tasks and by developing concrete skills to increase the amount of your contributions. Rapid growth is what these teams want to see, and it is likely why you were hired to join them.

I think Be the Worst is a useful pattern. It gives a clear idea or a method as to how developers can grow professionally and actively hone their skills. While there are risks involved in being the worst, it can be avoided with a strong drive to improve and be a contributing member. The potential benefits of this pattern are immense and it should be something that every apprentice developer should look into.

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

“It is better to be honest about your skills and fail to land a job, than it is to lie and put yourself in a situation that’s over your head.” – Someone, probably.

That quote, while partially meant as a joke, does have some truth behind it. Unfortunately, in this world of ever-increasing job requirements, it seems enticing to claim skills that you don’t actually have. This, however, can lead to an avalanche of constantly falling behind on work, and procrastinating/struggling to keep up with the rest of the team. Tapping into my previous entry (“Being the Worst”), we can see that is better to be honest about ignorance than to “shove it under the rug”, as one would say.

“Apprenticeship Patterns” essentially states that for this pattern, we must face a very difficult aspect of our lives – admitting that we are not the best at everything, and that we need to ask for help. Similar to “Being the Worst”, I find this philosophy to be familiar, but fascinating nonetheless. While it took me more time to confront my ignorance than to challenge my skills, I understand that both of these processes will make me a better programmer (and a better person) in the long run.

The most useful aspect of this pattern is the idea that, regardless of what we do with our lives (from scientific advancements like coding software to artistic talents such as playing guitar), it is more important to learn how to learn, than to “learn towards a goal”. To phrase this with better clarity – if we can understand the most effective way to learn, it will make our challenges much easier to overcome than trying to simply take on the challenge directly.

While I don’t think that this pattern has changed my thoughts about professional programming, I do believe that it has emphasized the importance of brainstorming, “thinking outside the box”, and other important factors of discovering unknown material. Most importantly, exposing ignorance shows that, as programmers, we know that we don’t have the solution that our client desires (yet), but we are also searching for it.

Maybe it’s because I’m no stranger to shame, but I must say that I disagree with the idea that there is “tremendous pressure to satisfy clients, regardless of one’s actual competence”. For me, the best way to satisfy clients (and pacify my own anxiety) is to select the most reasonable long-term solution – in this case, admitting my ignorance. “Dodging the bullet” during the sprint planning might provide short-term anxiety relief, but the problems avoided remain unchecked, building up far more anxiety in the long-term.

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.

DESIGN PATTERNS.

Design patterns provide a comprehensive solution that can be reused for common problems that arise in software design. A design pattern isn’t a complete design that can be transformed directly into code.

Types of Design Patterns:

• Creational Design Patterns
  Creational Patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. They reduce complexity and instability by creating objects in a controlled manner.

Types of CDP:

1. Abstract Factory

Creates families of related dependent objects.

• Builder

Constructs complex objects using step-by-step approach.

• Factory Method

 Creates an instance of several derived classes.

• Prototype,

 Creates a new object from an existing object.

• Singleton,

A class of which only a single instance can exist.

• Structural Design Pattern

These design patterns are concerned with arranging different classes and objects to create larger structures and provide new functionality. Structural class-creation patterns use inheritance to create interactions/interfaces.

Types of SDP:

1. Adapter

Allows for two incompatible classes to work together by wrapping an interface around one of the existing classes.

• Bridge

Separates the outline so that the two classes can differ on their own.

• Composite

Composite patternconsider a group of objects to be one.

• Decorator
  Allows for an object’s behavior to be extended dynamically at run time.
• Facade

Provides a simple interface to a more complex underlying object.

• Flyweight

Flyweight pattern takes the weight, or memory footprint, off of our objects by recycling them.

• Proxy

This pattern offers a proxy, or a substitute, to another complex object. Provides a space interface for the primary object to control access, reduce costs, or reduce complexity.

• Behavioral Design Patterns

Behavioral patterns are about identifying common patterns of communication between objects and identifying these patterns.

Types of BDP:

1. Chain of Responsibility.

Delegates commands to a chain of processing objects.

• Command.

Creates objects which encapsulate actions and parameters.

• Interpreter.

Implements a specific language.

• Iterator.

It accesses the elements of an object in sequence without revealing its basic representation.

• Mediator.

Allows for free integration between classes as it is the only class that has in-depth knowledge of their methods.

• Memento.

Provides the ability to restore an object to its previous state.

• Observer.

 Is a publish/subscription pattern that allows a number of observer objects to see an event.

• State.

Allows an object to change its behavior when its internal state changes.

• Strategy.

Allows one of a family of algorithms to be selected on-the-fly at run-time.

1. Template Method.

Defines the framework of the algorithm as an abstract class, allowing its sub-classes to deliver consistent behavior.

1. Visitor.

Separates an algorithm from an object structure by moving the hierarchy of methods to a single object.

REFERENCE

1. https://www.geeksforgeeks.org/design-patterns-set-1-introduction/
2. https://sourcemaking.com/design_patterns

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

What is YAGNI?

YAGNI – You aren’t gonna need it is an Extreme Programming (XP) key practice that’s states: “Always implement things when you actually need them, never when you just foresee that you need them.”As it stated then programmer should not add functionality until it is proven to be absolutely necessary

YAGNI Principle always recommends programmers to build the easiest solution to today’s problems. Even if you are sure you will need the feature, moreover, do not run it now. Mostly, it’ll alter in either:

1. You won’t need it after all, or
2. What you really need is different from what you originally thought.

Why YAGNI Principle is mostly relevant in Software Development Lifecycle than others?

In Software Development when software developers start implementing features they always go into practices known as FEATURE CREEP. Software developers always try to add or improve features regardless of whether they are not requested by users. For example, developers may try to add authentication to the form without first completing CRUD in the database.

Alternatively, following YAGNI in the configuration life cycle enables developers to implement features that will only be relevant for the first duplicate or demo and other future features that will work as a new version or update of software developed as recommended by users.

YAGNI Principle is safe, if …

The YAGNI principle, alone, may not be secure. Software developers can set up an early algorithm on the system and then copy-paste it all over, so when it goes wrong they spend a lot of effort fixing it. With this process in coding, YAGNI is very dangerous and may not be the best idea.

But when the developers set the quality of the design, the quality of the code, and the quality of the test, YAGNI is completely safe, as every future risk is excluded by simple design rules, and it will be easy to find and fix if it goes wrong.

Benefits of YAGNI:

• With a simple answer you can say the biggest benefit of the YAGNI Principle is to avoid unnecessary development.

Main reasons to practice YAGNI

1. It saves time as you avoid writing code that may not make sense later.

2. Your current code is better because you avoid guessing which can be bad

For two main reasons for practice, they ensure:

• That deadlines are available quickly,

• Customer satisfaction due to visible and frequent changes according to their needs or details,

• The best quality of code ordered by the fact that developers focus on small tasks (those that are currently very important),

• The code can be extended more and more (allows for updated versions),

• Reduced number of adjustments required,

• That the error is easy to fix.

REFERENCE: – 

https://deviq.com/principles/yagni

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

API, absolutely not the IPA’s beers (unless there really is the API beer) that Petr Gazarov, a software developer with more than 3600 followers on medium, mentioned in his blog, is an acronym of Application Programming Interface. Hmm, you might have heard about it but what it really is?

When we type the URL, for example, facebook.com, we send the request to Facebook’s remote server, which is a remotely located computer, and that computer, which is a server, processes the request through an API to display the webpage. From that instance, Gazarov defined that “An API isn’t the same as the remote server–rather it is the part of the server that receives, requires and sends responses.”

One example is the Object–Oriented Design, code is organized into objects, which will later be used to interact with one another. From my own experience, the first time I was aware of using the API was in the Data Structure class, the Oracle API provides specifications for the JVM Platform, Standard Edition, and the instructions on how to use those methods are documented. I was working with Stack in Java and I want to look at the object at the top of this stack without removing it, I will use peek() instead of pop() as instructed from the API documentation to request relevant operations. The Stack is the object designed by Oracle and the peek() function is a public method in that object, and a set of public methods and properties is an API. Web Server API is similar, the idea is to receive requests and responses.

The difference is the format of the request and response, in my case, it was simply just a function with a small operation, in other cases, different APIs provide flexible responses with tons of uses. One thing I learned from his blog is that to render the whole web page, the browser expects a response in HTML containing presentational code, Google Calendar’s API call would return the JSON formatted data.

Another experience that I’ve got when I was working with my friend in a web project is creating the backend of this project, which is developing the GET, POST, PUT, DELETE functions to respond to his request for his frontend application. The role of this API is to return the data, formatted in JSON, which is stored in Firebase database to the person working in the frontend in order to design the graphical user interface.

In short, Gazarov concluded” any piece of software that can be distinctly separated from its environment, can be an “A” in API, and will probably also have some sort of API”. Since this blog consolidates my understanding about API, I hope you will also find it useful.

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

Solid principles are divided into five different parts of programming and a design that addresses objects. Robert Cecil Martin or also known as “Uncle Bob”, was the one who introduced this type of anchoring or principle also called SOLID. This is one of the principles, where each letter represents a method which is represented by three letters, and which basically has a principle. When we work with software, which has a poorly managed management mode, we are dealing with a code that can become rigid, a fragile mode, and this makes this software difficult to use. When the code is rigid we are dealing with a code that is difficult to modify, it is difficult to change the way it currently works, or even more difficult to add any other features.

·  Single Responsibility Principle (SRP)

·  Open-Closed Principle (OCP)

·  Liskov Substitution Principle (LSP)

·  Interface Segregation Principle (ISP)

·  Dependency Inversion Principle (DIP)

Single Responsibility Prinnciple

The Principle of Sole Responsibility (SRP) at its core for a class not to change, there should be no more than one reason. And this results in every different class having to work with one method. However, each member in the class is related has a direct connection to what is called the primary function of the class. Unlike the example where a class has multiple responsibilities within it, in this method the possibility that it needs to be changed increases even more. And from all of this, we have an increased risk of presenting flaws whenever a class starts to modify. But by focusing only on one responsibility, this risk is even more limited.

Open-Closed Principle (OCP)

The Open / Closed Principle (OCP) means that classes for extension should generally be open, but for modification they should be closed. “Open for extension” aims to open the creation of our classrooms in order to add new functionality, while new requirements are generated. “Closed for modification” means not modifying a class after we have developed it, as it should never be modified, except to correct defects. These two parts of the principle seem to be contradictory to each other. However, if we structure our classes and their dependencies well, we can add functionality without having to reduce the existing source code.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) can be formed in a variety of ways. LSP is applicable to inheritance hierarchies. He emphasizes that we need to create as many of our classes as possible, so that client dependencies are replaced with subclasses without the client being aware of this change. For this reason, all subclasses are based on functioning in the same way as the basic classes they have. Subclasses do not have to apply only the methods and properties that the class bases have so that they are the true type of behavior. But they must also be consistent with her behavior. And this requires compliance with some basic rules.

Interface Segregation Principle (ISP)

There are some classes that have public interfaces and that are not cohesive. The principle of interface sharing (ISP) explains that clients are not tasked with dependent on interfaces that are not usable by them.

– The first rule is the existence of contradictions between the parameters of the methods that the base class has and that of the compliance in the subclasses.

– The other rule is for preconditions and unconditional. The other LSP considers invariant.

-The other rule is to limit history.

– The last rule of LSP states that a subclass should not throw exceptions that are not thrown from the other base class.

Dependency Inversion Principle (DIP)

(DIP) indicates that high-level modules should not be dependent on low-level modules. Both should be dependent on abstraction. These abstractions should not depend on the details, but these should depend on the abstractions. The idea is that high and low-level modules have, categorizes classes hierarchically. High-level classes or modules are those that deal with much larger groups of their functionality.

References

https://www.jrebel.com/blog/solid-principles-in-java

https://www.geeksforgeeks.org/solid-principle-in-programming-understand-with-real-life-examples/

https://www.educative.io/edpresso/what-are-the-solid-principles-in-java

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