Category Archives: Week 5

Record What You Learn – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Record What You Learn” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is design towards people who end up learning the same lessons over and over again or going through the same experiences or failures but can never get the details or reasons to stick.

The solution suggested is to create a blog, notebook, or wiki that you can treat as a journal and record important things that you learn. This is not to write down and forget about. Throughout your career you should return to this journal to review it and make new connections in your memory. When reviewing you should update what is written as more knowledge and experience is accumulated over time. The authors even suggest creating two blogs, one a public record and one a private. This allows you to share the lessons you have learned and also get feedback on what you have written with the public record and be able to be brutally honest with yourself in the private record. Internal and external feedback allows you to have an honest and accurate self-assessment. The main goal of this pattern is to keep a journal of your path to mastery so that you can reflect on and learn in the future.

I found this particular apprenticeship pattern interesting because this morning I was thinking about starting a notebook in which I can keep any important lessons as well as important details. This way I would be able to look back on it frequently and grow as a developer. This could include important concepts, design patterns or failures that I can learn from as I move forward. This book has provided a useful structure in which I can follow and also has inspired me to follow through with it since I have said I was going to do it a few times already but never have. Also, it has given the idea of two journals in which one can be private and one public. Maybe also different journals for different topics such as one for design patterns, one for lessons learned, one for important topics, etc.

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.

Your First Language

I always feel that if you are better at the first language, the easier it is to learn the next one.

I learned Java in my sophomore year, and then I went to learn C, which felt easy. Because the logic of computer language is interchangeable. For example, if you learn English well, you will find some similarities between French and Spanish. Although French and Spanish maybe your second language, you will learn them much faster than non-proficient English learners. I think this applies to computer language learning as well.

Each language gives you the opportunity to use different patterns to solve problems. In the process of moving beyond your first language, you should look for opportunities to learn languages that approach problems in very different ways. Apprentices who are comfortable with object-oriented languages should explore Functional’s programming language. Students of dynamic typing should delve into static typing. Apprentices comfortable with server-side programming should take a look at user interface design.

You should not be “married” to any particular technology but should have a broad enough technical background and experience base to be able to choose the right solution for a particular situation.

Many people say Java is good because it is suitable for many kinds of software programming. Some people also say that C++ is good because its language is more advanced than Java; there are also people who have learned that learning C++ to learn Java or very simple. I personally hate to talk about what language is best, every use situation has a language that works best for it. Or if you have learned your first language well, mastering it is also a good option. But there are certain situations where C really has the best solution than Java, so we write our software in C. At this point, there is no need to stubbornly think that I am good at Java and I have to use the language I am good at to solve this problem. 

The spirit of craftsmanship is that you strive for the best in what you are good at, but in certain situations, we can’t stick to the rules. Modern society is a utilitarian society, we need to maintain the spirit of artisans while learning to adapt to the society.

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

Expose Your Ignorance

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye covers multiple patterns important to being an apprentice. One of these patterns is called “Expose Your Ignorance” and centers around the issue of not knowing enough about a topic kind of important to the task at hand. Many people’s first instinct is to feign competence in order to avoid worrying their peers and suffer through embarrassment. The pattern instead suggests that people admit their shortcomings and ask questions. It might be hard to do but the benefits far outweigh the risks like learning important information sooner rather than later for example. Doing this has the added benefit of developing the learning ability through enforcing a “not knowing” mentality which just means to approach a situation if you were a novice. This mentality pushes an individual to broaden their horizons rather than becoming an expert on a single subject in a specific context. It also allows one to form strong relationships since this will be showing others your learning ability and flexibility.

I’ve had trouble “Exposing My Ignorance” for most of my life since again, most people’s first instinct is to feign competence. And of course, that wouldn’t work out since people would get mad at me for not knowing something and I’d end up barely learning anything. But I would still keep up this behavior until either late high school or early college mainly because there were some people in my life that would get mad at me for even asking questions. The reason why I broke out of that habit is because as I got older, I realized that there was so much I had no clue of doing. So, I started asking questions without caring what other people thought because I wanted to learn. For example, I wanted to learn to do my laundry so I just asked my mom to teach me and now I still do my own laundry. The same principle applies to software development; If you either don’t know something or aren’t confident in your knowledge on a subject, ask questions since there’s no real harm in doing so.

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

Concrete Skills

Concrete skills are something I feel as though I have an abundance, and simultaneously, a lack of. I guess this depends on what kind of skills are being referenced. If data structures, algorithms, or Leetcode is in question, I have some confidence. Not only are these topics I enjoy, but I also have solid knowledge in these areas. When it comes to automating tasks, or something more applicable to my current capstone situation, such as getting a strong grip on Docker and how each part of the project can be integrated with it, I feel… less qualified. 

The problem is, I think I can get to the technical knowledge I have, but only via the technical knowledge I am lacking. These barriers become apparent when working on a large project like the capstone. I look at the backend components, and I feel solid, even with little JavaScript experience. But picking up Vue.js makes me feel like I’m swimming in circles. There’s no point in making a backend without a frontend to support it, and I know this, but I’m not happy to confront it as it means abandoning my comfort zone for some crazy new frontend world.

          The learning pattern on concrete skills puts some much-needed pressure on me. It points out that I can have all the knowledge of theory and all the ability to learn quickly in the world, but if I can’t put real technical skills on a resume, I’ll never make it past the first round of hiring interviews. Rather than trying to find ways around the difficulties I face in everyday software development life, I should highlight my weaknesses and mark them down as learning opportunities.

          There has been a plethora of times in my CS career at which I confront a problem I have been avoiding and the knowledge I gain suddenly seems to apply everywhere. For example, last semester I learned the state design pattern, and because it came with some confusion, I dropped it quickly enough. Now, as I tried to make a Markov chain simulation in Java for my Math Modeling independent study, I realized a state pattern was a perfect fit. It took a couple hours, but I got it down and it feels great not only to have learned and used something new, but to know I have the knowledge to use whenever I need it going forward.

          I think my first focus should be some more surface level skills. As the chapter points out, the question, “If we hire you today, what can you do on Monday morning that will benefit us?” is one of the most important questions of the interview. If my best answer is, “Try really hard to get up to speed,” I’ll be job hunting for a long, long time. My new goal is to collect the skills I don’t know or feel uncomfortable with that are more common and focus my spare time on them. It will make daily life as a developer easier and take me further in my career faster.

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

Breaking Out the White Belt (Disambiguation)

As someone who has been a caddy, industrial mechanic, butcher’s assistant, retail manager, letter carrier, web development intern, substitute teacher, and referee over the course of my life, it’s safe to say that I’m no stranger to breaking out the white belt. The chapter sets up the scenario wherein you’re a competent programmer with a narrower-than-desired field of knowledge and although your competency allows you to feel confident in your day-to-day operations, this coziness with your language or technology stack has limited your ability to wrestle with the novel in a meaningful way. The suggested solution is to embrace the unknown and throw away your preconceived notions about what it means to program or write software, actively avoiding the temptation to relate your previous world to the task at hand. The authors call this mindful approach to limiting context “maintaining a not knowing stance”, an ethos that I would argue is truly the heart of science and fundamental for discovering something new. The case here is that we (the readers) are software developers and the personal discovery is the new world of idioms, approaches, and paradigms that we will hopefully be able to synthesize and, upon achieving contextual competence, apply.

The pattern certainly confirms to me what I already know; being humble is an evergreen approach to learning, however the authors chart territory that I do not know in the chapter and that is the premise given at the outset where one hits a level of competence and plateaus there. I’ve not really been able to wrestle with any technology stack or programming language long enough where I feel competent or fluent to meaningfully contribute, let alone act as a guiding beacon for peers. While I may not be ready now to apply what I’ve learned in the pattern, if I imagined myself a competent C++ developer accustomed to the object-oriented programming paradigm, I would then make an attempt to learn a declarative paradigm, perhaps functional programming. Ultimately one’s next foray in software development will tend towards whatever is productive for their endeavors, occupational or personal and should likely reflect the adage of “picking the right tool for the job”.

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.

Apprenticeship Patterns Blog Post #3

After completing my apprenticeship introduction blog post and two different patter reviews, I am excited to keep reviewing more. For the next pattern from the textbook that I have chosen to review, I chose the “concrete skills” pattern. The book describes a situation in which you are trying to work with a group or at a job in which you do not have a very strong background in yet. This is ofter one of the most inconvenient thing when looking for starter jobs. Most jobs want individuals who have a good background so they know you will be a good fit for the job. The book also supplies us with a great solution to this problem however. Basically, it states that you will have a better chance getting the job if you can prove that what you lack in background work, you make up for in your ability to learn quickly and work hard to learn new things on your free time as well. The more jobs and projects you can accomplish/work on, the better your portfolio and background becomes overtime. Eventually you will find it easier and easier to get where you want to get, and it all starts with your first several projects/jobs. This specific apprenticeship pattern resonated with me primarily because I personally do not have a great background yet and am trying to create a good one. The advice from this section was super powerful, and to be honest, this might be one of the most important concepts discussed in the entire textbook!

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.

Software Frameworks

https://techterms.com/definition/framework

            The link above leads to a website article that explains what a software framework is while giving some examples. The two main reasons I chose to write about this topic is because of one, it’s listed as one of the topics to be covered in class and two, I’m not too familiar with the definition of a software framework. According to the article, a software framework is essentially a set of tools that act as a foundation for software developers. These may include preset classes, APIs, compilers, code libraries, and predefined functions among other things. Examples of software frameworks include Microsoft’s .NET framework, Android Application Framework for Android, Cocoa Touch for iOS, and Cocoa for Mac OS X.

            From the definition given, the practicality of a software framework seems pretty apparent to me. Rather than creating classes and functions from scratch that will most likely see reuse, set them together in a ready to use package in order to save time and effort. It’s similar to how someone would buy ingredients at the supermarket rather than making each one from scratch. I’d imagine that software frameworks also have the added benefit of increasing portability for software that uses a specific framework. Take for example my computer which has .NET framework on it. If I were to create a piece of software using .NET, then another machine which has a similar version of same framework would be able to run my software with no additional setup needed. To be fair this is only speculation on my part; I haven’t checked whether or not this is true yet. But then again, I remember having to install a newer version of .NET framework in order for my computer to run software correctly so I might be on the right line of thinking.

In the case of porting software to machines with different operating systems, I’m not sure what role frameworks would take. I am pretty confident that software frameworks aren’t limited by operating systems. One example being Java Collections Framework or JCF for short which, as far as I know, isn’t limited to an operating system like .NET is. When a difference of frameworks is a factor, I assume that a software developer would have to make up for a lack of a framework’s components in a machine in some way. And that’s on top of the usual changes needed for porting software between operating systems.

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

REFACTORING

As I was reading some articles, websites for my previous assignments, I came across the term refactoring a lot. However, that was not the only time seeing that as it is part of the course syllabus. I decided to learn more about refactoring and write something on it for my weekly blog post. After going through some resources, articles I finally settled on this blog post that talks about refactoring. The structure of this blog is made simple, easy to learn and understand especially for beginners and those new to the term. It also provides links to some terms, books and some other IDEs mentioned.

This blog defines refactoring as the process that involves editing and cleaning up previously written software codes without changing the function of the code at all. Blog talks about the importance of refactoring, reasons for refactoring and how to perform refactoring. It also provides some techniques on how to perform refactoring. Each technique is well explained and broken down into subtopics and/or steps with some diagrams provided. Also, blog talks about when refactoring is not needed, best practices for refactoring and general summary refactoring.

In this blog I learned that the basic purpose of refactoring is to make codes efficient and maintainable, reduce technical cost, improves readability, and help prevent future bugs. A term that I found interesting as I was reading about the importance of code refactoring is code rot. Further research from Wikipedia explained it as a software decay that is a slow deterioration of software quality over time leading to software becoming unusable or in need of upgrade. Refactoring is important as it help to avoid this code rot.

I also learn that the best time to refactor is before any update or additions to an existing code. This is so as it improves the quality of code and should be done in small steps as possible. Other practices include planning refactoring project and timeline carefully, testing frequently and involving Quality Assurance teams and striving to focus on progress.

I thought that refactoring is always needed especially dealing with very high coded software programs and systems, but I learned from this blog that refactoring is not needed when an application needs to be completely improved.

Some techniques of refactoring I learned are Red-Green Refactor, Refactoring by Abstraction, Composing and Simplifying methods. Before applying the Red-Green Refactor technique, there should first be consideration of what needs to be developed. These developments need to pass basic testing before improvements can be implemented. Refactoring by abstraction is used when there is a large amount of refactoring to be done. I learned that extraction, one of the processes in Composing method, involves breaking down of codes into smaller pieces to find and extract fragmentation. This code is then removed to a separate method and replaced by a call to a new method. This process also involves classes, interface and local variables.

I hope others find this blog useful as well.

https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/

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

More on Code Smells and Refactoring

Similar to how code and design smells were covered in class. I was interested in digging more into code smells and seeing how they influence development of code and how they can be rectified. I found that this would be a useful topic to further delve into because being able to pick up smells from your code will help prevent further mess in the future. To supplement my learning in this topic I got around to watching a seminar or conference video on code smells in java, which was hosted by Stanly Lau, a software development coach/mentor and also someone having experience of looking at companies code and giving advice on code smells and refactoring. In his seminar he basically went over code smells and refactoring techniques used to remove to code smells; in the seminar this is done by an example he goes over with the participants.

Besides going over code smells, what I really like from this seminar, was how he explains the significance of catching code smells in our code; he explains this via system diagrams to show that code smells are in a reinforcing loop relationship with bad code, and bad code is in a balancing loop with developer motivation; because of this we need to reduce bad code via refactoring. Refactoring is important because it instigates flexibility and helps to remove bad code or code smells. And flexibility is important in order to deal with change and he states “[i]f you cannot deal with change or how to improve with change easily, then you are probably in the wrong business”. The was a powerful I really appreciated, that change is inevitable in programming and in order to deal with change we must make our code more flexible, and that is where finding code smells and refactoring comes in.

I also enjoyed watching Stanly going over his example code of detecting and refactoring the code smells. His methodology appeared that he would look at the code and try to understand what is going on with the code (reading before coding) and then would see if he can detect any code smells such as comments, duplicated code, feature envy, long methods, primitive obsession, or magic number. Afterwards he would choose a means to refactor that code smell; the aspect of refactoring that he describes as ‘making small steps without breaking the code for too long’ is what I found helpful and will incorporate next time I am reviewing my code. Rather than just choosing a technique such as extraction method, I should be compartmentalizing steps to fix a problem and then work on improving on that refactoring. Overall it was a supplement for my learning in code smells as I was able to see a demonstration and also learn some more techniques use ide’s as well.

I attached the links to video as well as the diagram that explains effects of code smells in a developers environment below.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

Decorator Design Pattern

I decided that I wanted to talk a little more for the design patterns. This week I will present you another type. Decorator Design Pattern. Decorator design pattern is used to add additional features or behaviors to a particular instance of a class, while not modifying the other instances of same class.  It is a structural pattern, which provides a wrapper to the existing class. The reason why this pattern is in structural design patterns is because they show us how to glue different pieces of a system together in a flexible and extensible fashion. These patterns help us guarantee that when one of the parts changes, the entire application structure does not need to change.

What is the intent of this pattern? In software engineering, decorator design pattern is used to add additional features or behaviors to a particular instance of a class, while not modifying the other instances of same class. The intent of the this pattern is to provide a flexible alternative to sub-classing for extending functionality. This pattern is very important to understand because once you know the techniques of decorating, you’ll be able to give your (or someone else’s) objects new responsibilities without making any code changes to the underlying classes. You can attach new responsibility to an object dynamically. This is exactly the intended use of the decorator pattern. Per the Gang of Four – “Attach additional responsibilities to an object dynamically”.

When to use this pattern? Decorator Design Pattern has several requirement indicators to suggest that it is potential solution e.g.

  1. We have an object that requires the extension.
  2. Several objects that support the extension by “decoration”. Usually, those objects share a common interface, traits, or superclass, and sometimes, additional, intermediate super-classes .
  3. The decorated object (class or prototype instantiation), and the decorator objects have one or several common features. In order to ensure that functionality, the decorated object & the decorators have a common interface, traits, or class inheritance.

What are the benefit and disadvantages?

·  Sometimes we want to add responsibilities to individual objects, not to an entire class. Decorators provide a flexible alternative to subclassing for extending functionality.

·  Avoids feature-laden classes high up in the hierarchy.

·  A decorator and its component aren’t identical.

·  Lots of little objects.

There are a lot of examples and reading that you can do for this design. I would suggest you https://howtodoinjava.com/design-patterns/structural/decorator-design-pattern/ . This is a very good website where it gives details what the Decorator Pattern is and it gives you an example to understand it better. Also https://dzone.com/articles/decorator-design-pattern-in-java . What I like about this website is that it has all the important part in points. Touch only the important part without going to much in details for a beginner.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.