Category Archives: Week 8

Learn How You Fail

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 constant searching for new solutions.

—Atul Gawande, Better

Learn how you fail is the second blog I’ll discuss from the Apprenticeship Pattern book. I’d like to begin this piece with a quote from Morihei Ueshiba: “Failure is a key to success, each failure teaches us something”.  Everyone wants to be successful, but not everyone is willing to accept failure. However, I will add that my greatest life achievement thus far has been learning to accept my failures. This is, at the end of the day, motivation.

Failure, according to Atul Gawande, is unavoidable since it will happen to all of us at some point. I hold the same viewpoint. We won’t be able to learn if we never make mistakes. We are called losers when we fail at something, but victors when we learn from our mistakes. Failure serves as a reminder that we are all the same, and that success is earned through hard effort and determination

It has been the same for me. I accept that I make mistakes and that I have learned from them. I didn’t understand how programming worked well enough. But I learned by doing, and I’ve made a few blunders along the way. I knew that to be an effective programmer, I needed to mix knowledge, attitude, and technical capability with soft skills when I initially chose my future job would be. I needed to apply my talents, which are methods and processes that supply computers with instructions on which action to execute, to prepare myself to be a computer programmer. But the most important thing I prepared for was that I would fail a few times until I arrived at the conclusion that I will be a decent coder.

One other thing that I would like to talk about, is also the solution given to this pattern. It is a good choice that when we are becoming conscious of the things that trip us up, we allow ourselves the choice between working to fix these problems or cutting our losses. I totally agree and for sure that we have to accept that there will be also some things that we are not good at. Also when we encountered by failing this “thing”, it will be a lesson on how to prevent it in the future. Only in that way we won’t fail again. But the most important thing we need to know is that the only thing we learn from is a failure and not success.

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

At Least They Have the Spirit

PREVIOUSLY ON MPEKIM.CODE…

So far, we have come to the conclusion that it is okay to not know everything. It is also alright to even be “the weakest link” of a team. What matters the most is the enthusiasm, the drive to learn more about our projects and programs. For Apprenticeship Patterns, this means that newcomers can be useful to a team if they provide morale and enthusiasm to expose and attack their ignorance.

To start, I believe that the book stating the idea of “repressing enthusiasm when it is not welcomed” isn’t entirely incorrect. However, I do believe that, unless an enthusiastic apprentice is drastically creating dire consequences for the team, then the members with lower morale should lighten up a bit. No one starts out “creating the next Linux”; if seasoned professionals are not held up to these high expectations, then it seems ridiculous (to say the least) that the newcomers will be held to it.

Interestingly enough, the controversial idea of repressing enthusiasm is supported by a factor of the pattern that I do enjoy: the idea of “experiencing diversity”. According to “Unleash Your Enthusiasm”, teams actually have the most efficiency when they consist of members who each have various amounts of experience. “Old farts” who have seen it all will likely be numbed and unaware of an issue that a newcomer will notice with their “fresh eyes”. Likewise, the more experienced will create sorcery, solving programming problems that the newbies weren’t even aware of.

As far as the future is concerned, I can say that I apply this pattern on a daily basis. While the book helps to reinforce this ideology, I am no stranger to “pumping up a crowd”. Unleashing enthusiasm is not only the idea of providing positivity and workplace morale, but it also involves taking the initiative. Even if they get shot down, we should always put our ideas out there – scribbles, doodles and random notes are never irrelevant. Some of the greatest ideas were the result of an accident (caused by an enthusiastic dreamer).

So far, in the grand scheme of my selected patterns, here is what I see as a “list” or “chain”:

  • Find a team that you are the worst on.
  • Discover and acknowledge your weak points.
  • Take the initiative and enthusiasm to work on these issues.
  • Give yourself the breakable toys needed to grow from mistakes.
  • Practice correctly, with feedback from professionals.

In retrospect, I find it amazing to take my previous blogs, and discover a path within them (similar to a graph data structure). Now, we must take the time to implement it….

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.

Object Oriented Programming

OOP is used to structure a software program into simple, reusable pieces of code blueprints (usually called classes), which are used to create individual instances of objects.

Building blocks of OOP:

  • Classes are where we create a blueprint for the structure of methods and attributes. Individual objects are instantiated or created from this blueprint. For example, we can look at Duck class covered in class activity.
  • Objects are instances of classes created with specific data, for example rubber duck is an instance of duck class. It is crucial to remember that class is a template for modeling (a duck in our example), and an object is instantiated from the class representing an individual real-world thing (a rubber duck in our example).
  • Methods perform actions; methods might return information about an object or update an object’s data. The method’s code is defined in the class definition. In simple terms, methods represent behavior. For our Duck example, ducks had methods like fly() and quack(). Duck’s had different behavior. Rubber duck did not fly and did not quack but squeaked. These behaviors are specified in methods.
  • When objects are instantiated, individual objects contain data stored in the Attributes. State of objects depend on data in attribute. For example, Rubber duck is handled differently than a mallard duck based on the information in attributes.

The four principles of OOP:

  • Inheritance allows classes to inherit features of other classes. Basically, child classes inherit data and behaviors from parent class. In our example, Rubber duck inherited display() from duck class.
  • Encapsulation is containing information in an object and exposing only selected information to other classes. Private methods and properties are accessible by other methods of the same class. Public methods and properties are accessible by methods of other classes too.
  • Abstraction is using simple classes to represent complexity. It uses simple things to reduce complexity. Abstraction means that the user interacts with only selected attributes and methods of an object. Abstraction is used in interface. In FlyBehavior we had abstract fly() which was defined in concrete classes as flyWithWings or flyNoWay.
  • Polymorphism uses inheritance. Objects can override shared parent behaviors, with specific child behaviors. In method overriding, a child class can provide a different implementation than its parent class. In method overloading methods or functions may have the same name, but a different number of parameters passed into the method call.

Abstraction reduces complexity and constant overriding of method. Inheritance gives reusable structure across program. Polymorphism allows for class-specific behavior and objects of different types to be passed through the same interface. Encapsulation helps us prevent unwarranted change of important data by developers. Also, Prevents greater security risks like phishing that we face today.Advantages of OOP will never die out. Therefore, I have written this blog explaining OOP and I hope it has been useful.

Sources

https://codecoda.com/en/blog/entry/object-oriented-programming

What is Object-Oriented Programming? OOP Explained

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.