Category Archives: Week 6

Learn How You Fail – Apprenticeship Pattern

Today I will be writing about the “Learn How You Fail” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for everyone. Everybody has failed at something and will again in the future. If you are not failing then you are not pushing the boundaries of your capabilities, and/or you are overlooking these failures.

The problem addressed in this apprenticeship pattern is that you have enhanced your success through learning, but failures and weaknesses remain. The solution to this is to gain an understanding of the habits, behaviors, and patterns that has led you to failure. With self knowledge, you can make conscious choices to avoid these behaviors/habits or to break them and give you an idea of your limitations. As explained in the book, This can help you make a decision whether to fix a problem or cut your losses. If something is going to be a disproportionate investment of time and money only for a small improvement, it may be time to improve on something else instead. Excepting your limitations is important, seeking for perfection will only disappoint. This could mean letting go of some areas of expertise that cannot benefit you as much if you do not have the time to maintain those skills.

A method recommended by the author is to keep a list of your current skillset and boundaries. This way you can have an organized view of these boundaries and decide which areas you would like to push/explore. I found this interesting because it is similar to the “Record What You Learn” design pattern that I had written about in my previous post. By writing down your experiences, you can gain a greater understanding of what is happening. This way you can grow as a developer. Writing down your habits, actions and patterns which cause you to fail, can help you move forward from the endless loop of repeated actions leading to failure. I like this pattern because it accepts that you will fail sometimes, but whats worse than failing is to not push your boundaries. This pattern helps you understand and map out your boundaries so you can push them in an organized, thoughtful way.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Your First Language

For this week’s blog post, one pattern that stood out to me the most was “Your First Language” I believe that the first language will be the most important one for our careers because for the next few years this will be the main language, we use to solve problems or practice to improve.  My first language technically was HTML that I learned back in a web design class at High School, but my first official language is Java from our CS 140 class. From that class and onward I have been using java for almost everything even for personal projects or in other classes.

As I was reading the rest of the article, I came across a sentence how the author states, “For several years, your first language will be the framework against which you learn other languages. The better you know your first language, the easier it will be to learn your next language.” I believe this is very true, your first language will be the foundation for the rest of the languages you will be learning. I remember when we had the CS 282 class in which we learned the C language, it was much easier for me to learn the concepts faster because I had a good understanding of the first language. Another concept that I thought was interesting is about how your first language can prevent you from learning and using other languages, the author states that “One danger of digging deep into your first language is getting stuck. It likely will remain with you throughout your career as your native tongue.” I agree with this statement, having good proficiency in one language can indeed prevent you from learning and using other languages. However, it is good to have a diverse knowledge of languages, especially in software development as each language provides an opportunity to solve problems using different paradigms.

I agree with all the statements about this pattern, it is important to look back and see that starting from “your first language” now we are all learning and getting used to different languages. Especially for me, I have been trying to learn Python since most of the companies use it nowadays and, R to analyze different types of data which I find quite interesting.

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

Your First Language – Apprenticeship Pattern

Our first programming language can be similar to the first language we learn to speak or our native tongue. What this pattern talks about is to first pick a language and start to master that language by practicing and solve problems in the specific language. It also talks about having some mentor or asking questions to someone more experienced so they can help guide you along the way of learning the programming language, but also at the same time not becoming dependent on them to solve your problems.

I found this chapter to be very interesting because whenever I think about coding and solving problems, the first syntax or code to use that comes in my mind is Java. The reason for this is because it is my first programming language that I learned and I have the most experience with it. This pattern has led me to confirm my belief that we need to first become better programmers in a specific language. A lot of people try to jump from one language to another and think it will be more beneficial. However, what this results to is not thorough understanding of a programming language, and more simple knowledge of each one. It is much more efficient to pick up a specific language based on your preference, and broaden your knowledge with it. Try out different problems to solve and keep on practicing. Once you feel you are at a level that you are content with, then move on to another language and broaden your knowledge about different types of programming. If you started with an object-oriented language, then learn about a functional programming language. Also, what this does is help moving from one language to another a lot better as well as understand the differences of each. With more experience in languages, we can start to see what languages are better for certain tasks and can examine advantages and disadvantages. In essence, the goal of this pattern is to take things a lot more slowly and in a more efficient way. It will be much better taking time to learn critical details then having front level knowledge. Overall, be open minded when it comes to languages as well and don’t just stick to one and decide that is it.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Breakable Toys: Improvement Through Experimentation

Photo by Polesie Toys on Pexels.com

In software development/programming related projects, much of the time making a mistake can feel like the end of the world, or at the very least a major inconvenience to everyone else around you. Yet by failing we often tend to learn more than we do by succeeding, since success seems to come most often from familiar and comfortable subjects or ideas which we might already have preexisting experience working with.

This is why I find the Breakable Toys pattern, described in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman as a way to work within a “safe space for failure” to be an interesting and largely relevant idea in the context of software development. The pattern describes the practice of building “breakable toys”, these being smaller, self-contained projects making use of the same toolsets you might use during professional or otherwise high-stakes development.

The pattern suggest building simple games or programs as a way of learning a new programming language. Building simple games such as Tetris or Checkers in order to get to grips with the language seems like it would be a fun experience, I think game development is an extremely interesting field, and focusing on your interests is an effective way to speed up familiarization with a new language by making use of something fun and engaging as a sort of “practice project”.

I have always enjoyed the idea of self-building software; the idea of having a usable program or application which is self-built is appealing. Similar to how a woodworker might feel sitting in a rocking-chair hand built from their own shop, the idea of building something which is demonstrably useful, or even just as an experiment to see what happens is a great opportunity to express creativity and explore a new topic. The added benefit of experience and potential to learn something new makes it a worthwhile experience in my opinion.

In terms of putting this particular pattern into practice, my first course of action would most definitely be to make a few simple games and applications, an image editing program or simple web browser seem like reasonable small-scale projects to work on as a learning experience.

Building something out of personal interest can make learning the required skillset a relatively painless experience, as by the end of it you will likely have something which you can be proud of and enjoy for many years to come.

Text Referenced: https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

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

Apprenticeship Patterns Blog Post #4

The fourth pattern that I plan on discussing is titled “expose your ignorance” in the book. The reason I want to choose this pattern to learn next is because I believe that it relates to me one hundred percent of the time I am in school. The idea behind this pattern is that if you do not speak up when you are lost, you will inevitably hurt your learning process. Many people, including myself, get into the habit of not vocalizing questions and concerns for fear of being disruptive, time-wasting, and possibly getting even more confused. It is very easy to simply keep your head down and struggle through a course or project without getting everything you need out of it. Basically, in situations where you do not know what you are doing, protecting your pride is often a bad solution, and exposing your ignorance is likely your best option. The book does a great job explaining why this is and it has good examples of times where it is a needed apprenticeship pattern to pick up. Even in jobs, it is important to expose your ignorance. The easiest way is by asking questions. Not only will it help you learn faster and more, but it will also ensure that you are doing everything right and in the way that your employer expects you to get your work done. The book has other solutions for this as well. In fact, the main action that it tells you to carry out is to “write down a list of five things you really don’t understand about your work. Put that list where others can see it. Then get in the habit of refreshing this list as your work changes.” Personally, I feel like in my years of schooling I have not reached out enough with questions for fear that I would look like I do not know what I am doing. It is not going to get any easier for me when I try to get real jobs, so it is important for me to learn to put my ego aside and expose my ignorance in a way that will allow me to learn and get better everyday.

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

Concrete Skills

The “Concrete Skills” pattern in Apprenticeship Patterns can be understood, at a baseline level, to be the process of obtaining skills to achieve acceptance into a group of software professionals. This pattern elaborates on how the acquisition of skills has both intrinsic and extrinsic value in differentiating you as a potential candidate for the position in question.

Upon reading the Context and Problem section of this pattern, my brain immediately conjured up a preconceived notion as to what I should expect from the rest of the article to follow. In many respects that notion was correct; I was anticipating a description of the courting ritual between the gatekeeper(s) and the applicant. In the previously mentioned ritual, the applicant admits to humility but shows sufficient competence and desire to improve to the gatekeepers who either make an affirmative judgment leading to the conditional induction of the neophyte, or a rejection leading to the applicant walking away with redoubled determination to step back into the fiery crucible of honing their craft so that they may be better prepared the next time for the acceptance ritual. I embraced this struggle personally in my desire to create music; having been composed of solely aspiration and perspiration, I fell below the musical competency threshold during the audition process several times but I came back with a vengeance and was able to squeak out acceptance.

In the context of software development, Hoover and Oshineye are designating the in-group as a software development team who has a hiring manger that will be vetting your technical skills rather than several bandmates vetting your musical chops. The authors make mention of the concept they borrow from someone else called “day care”, and this is to illustrate the mentality of the gatekeeper who will ultimately be held responsible for the hiring and subsequent failings of the neophyte in an environment where time is software and software is money. I also appreciated that, aside from the intrinsic nature of possessing the technical skills, the authors made sure to mention that the need to develop these skills is also for the extrinsic value of passing human resource applicant filters and “managers who construct teams by playing buzzword bingo”.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

What’s that smell?

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.[1][2] Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.
The term was popularized by Kent Beck on WardsWiki in the late 1990s.[3] Usage of the term increased after it was featured in the 1999 book Refactoring: Improving the Design of Existing Code by Martin Fowler.[4] It is also a term used by agile programmers.[5]
(From Wikipedia, the free encyclopedia)

During her presentation at RailsConf in 2016 called Get a Whiff of This, Sandi Metz talks in depth about code smells, the practical effect of recognizing them and doing refactoring. My reason for choosing this particular source of information was because she gave real life examples and comparisons that helped me to better understand problems within codes that were humorous and I found her explanation of the types of code smells and how to fix them entertaining, easy to understand and very useful. Sandi presented examples of code she herself had written and demonstrated through diagrams and easy to follow steps how to refactor the code to make it neater. At the end of her presentation Sandi gives reference to a static analysis tool called Reek that you can run on your code and it will tell you what to go look at, so you don’t even need to go figure it out yourself.
This presentation really boosted my confidence as a programming student and gave me higher hopes as a future programmer. While watching this presentation video, I learned that most code is a mess, even the best coders can have messy code, and when given difficult or complex code, it can be broken down and easily fixed even if I am not able to understand everything within the given code. Going forward, I will definitely be referring back to this video to help me spot and correct any imperfections within my own code or any code I am given.

The 5 different categories of code smells are:

  1. The Bloaters – these make code bigger than they should or need to be.
  2. The Object Orientation Abusers/Tool Abusers – these are ideas that are available that you can misuse.
  3. The Change Preventers – these make change hard.
  4. The Dispensables – these represent something unnecessary that should be removed from the source code.
  5. The Couplers – these come as a bundle, they represent the attraction behavior of two classes which could be called excessive.

    (https://youtu.be/D4auWwMsEnY)

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Facade Design Pattern

This week we practice docker a lot bout docker Activity, but we havent learn all about patterns so I choose to write one more Main Design Pattern call Facade Design Pattern. in my homework 3 I picked Decorated design pattern but I have’t learn more about Facade Design Design Pattern. This is really help full in programing becuse it have high level interface that make subsystem easier to use.

Facade design pattern provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.Facade pattern is one of structural design pattern among other Gang of Four design pattern. The facade pattern is appropriate when we have a complex system that we want to expose to clients in a simplified way. Its purpose is to hide internal complexity behind a single interface that appears simple from the outside. Facade also decouples the code that uses the system from the details of the subsystems, making it easier to modify the system later.

To understand the facade, let’s take a very simple example of a desktop computer machine. When we have to start a computer, all we have to do is press the start button. We really do not care what all things go inside the computer hardware and software. It is an example of Facade pattern.

In Java programming, we must have connected to a database to fetch some data. We simply call the method dataSource.getConnection() to get the connection but internally a lot of things happen such as loading the driver, creating connection or fetching connection from pool, update stats and then return the connection reference to caller method. It is another example of Facade pattern in the programming world. Similarly, we can find a lot of more examples which hide lots of internal complexities and provide simple to use interface to the programmer to work with the system. All such are facade examples.

Remember facade does not reduce the complexity. It only hides it from external systems and clients. So the primary beneficiary of facade patterns are client applications and other systems only. It provides a simple interface to clients i.e. instead of presenting complex subsystems, we present one simplified interface to clients. It can also help us to reduce the number of objects that a client needs to deal with.

When you call a shop to place a phone order, an operator is your facade to all services and departments of the shop. The operator provides you with a simple voice interface to the ordering system, payment gateways, and various delivery services.

Source:

https://refactoring.guru/design-patterns/facade

https://www.tutorialspoint.com/design_pattern/facade_pattern.htm

From the blog CS@Worcester – </electrons> by 3electrones and used with permission of the author. All other rights reserved by the author.

Adapter Design Pattern

 

    This week On my Blog, I want to talk about a design pattern. The One I want to focus on is Adapter Design Pattern. Adapter design pattern Convert an interface of a class into another interface clients expect. The adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. The adapter design pattern is a structural design pattern that allows two unrelated/uncommon interfaces to work together. In other words, the adapter pattern makes two incompatible interfaces compatible without changing their existing code. Now Let’s take a look at an example that shows how the design works. From the blog, I used it provided a diagram that I think is helpful to understand the design pattern. In this diagram, Socket wrenches provide an example of the Adapter. A socket attaches to a ratchet, provided that the size of the drive is the same. Here a Ratchet is ½ in size and the socket is ¼ without using an adapter you cannot connect the ratchet and socket together. 



    Now let us take a look at the benefits and liabilities of using the adapter design pattern. The first benefit is that you can let any two unrelated classes run together. Second, Improved the reuse of classes, it Increased the transparency of classes and it has Good flexibility. Now for the Liabilities, the Adapter design pattern takes Too much use of adapters will make the system very messy and difficult to master as a whole. For example, if an interface A and B are implemented and interface B is adapted internally. If too many tasks are running in A system, it will be A disaster. So, if it’s not necessary, you can simply refactor the system without using an adapter. Also, in object-oriented programming especially in JAVA it inherits at most one class, it can only adapt to one adapter class at most, and the target class must be an abstract class.

    A real-life example that I found was about the card reader ACTS as an adapter between the memory card and the laptop. You insert the memory card into the card reader and insert the card reader into the portable computer. The memory card can be read from the portable computer.

    This source is helpful to understand the design pattern even more. I would suggest you take a look at the website because it goes into further detail about the Adapter design pattern, including various examples using diagrams and JAVA codes. 

 

Source: https://sourcemaking.com/design_patterns/adapter#:~:text=Intent,class%20with%20a%20new%20interface

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.