This week, I decided to take a look at the “Concrete Skills” apprenticeship pattern in chapter 2. This pattern describes the problem of potentially joining a team, with the expectation that you will learn more than you already know, and the team not wanting to take the risk on someone who may not be able to contribute to the workload. It is important to acquire and develop “concrete skills.” Concrete skills serve as proof of your competence, as it more so demonstrates your ability to apply the knowledge that you have. The pattern suggested that one should always acquire more concrete skills than just the bare minimum required in an interview. It is always beneficial to have examples on hand as proof of what you can offer to the team. The examples of concrete skills provided include writing build files in various languages and having knowledge of popular open-source frameworks. And so, concrete skills help reassure your future teammates that you are capable of contributing without the need for “day care.”

My immediate reaction to the pattern was that I can see myself in this specific situation. The pattern starts with a quote from Pete McBreen, where he states, “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.” That quote stuck with me because we can spend years studying a certain topic, but your expertise shows when you apply the knowledge. And reading through this pattern encouraged me to take a deeper look at the concrete skills I have developed thus far.

For the most part, I think this pattern gives some useful tips on how to build an impressive resume and come off as a capable job candidate. The question: “If we hire you today, what can you do on Monday morning that will benefit us?” is something that I will keep in mind since I will need to evaluate myself before even applying for jobs. I do think this pattern gave me a bit more insight into my intended profession. I never really thought about the fact that teams are more likely to hire someone that can be an immediate help rather than someone they would have to teach. So I think this is more encouragement to further acquire concrete skills. Perhaps I will spend more time with frameworks, especially ones we are working with in class such as Vue.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

The White Belt

This Apprenticeship pattern was about unlearning what you already know in order to learn something new. It is important to do this because, especially with programming languages, what might be a good habit or convention within one language may be inefficient or bad practice within another. I could personally relate to this Apprenticeship pattern a lot because in high school I took an intro to programming class in which we learned the basics of python. I found python to be really confusing at first, but over the course of the school year I became very familiar with it and began to really like the syntax and structure of the language. While this class was very useful and helpful for learning programming, it made it more difficult for me being a computer science major in college.

In college, most of the programming we do is in java. Transitioning from python to java was very difficult for me because they are two very different languages, with different syntax and structure, and different coding conventions. In my experience, it is very difficult to translate from python to java, but somewhat easier to translate from java to python. Although you can translate from java to python, the way of going about things in java is very different from in python, and the direct translation from java to python is likely very inefficient, whereas code written from scratch in python is likely much more efficient in python. This means that in order to learn java, I had to unlearn what I already knew from python. Even things that I felt were general coding practice felt completely different in java than it did in python, which made it really hard to learn java. So, in order to properly learn java, I had to think about the concepts completely independently of similar concepts I knew from python. Even though this was very difficult to do, I find that it actually fortified my understanding of both languages, and helped me to think about them independently of one another.

I couldn’t find anything I disagreed with about this pattern. I think that this is sound advice in general, even outside of software craftsmanship. You can’t be afraid to fail when learning a new skill, because only through failure will you learn to improve. As the Apprenticeship Pattern mentions, this could mean that you will get worse before you get better, as you’d be much less proficient using whatever new skills you’re learning than you were with your old skills. However, the point it’s making is that it’s worth it to see it through, as only then will you expand upon your skillset.

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

If you haven’t noticed already, there seems to be a trend of various coding practices that I tend to agree with. This is not merely a case of “kissing up” to the professionals, but rather it is the fact that I know I have been taught from the ground up by well-respected individuals. Many of the practice patterns found in “Apprenticeship Patterns” are ones that I have already been aware of, or still agree with despite their novelty. An additional agreement to add to this repertoire is the importance of “Your First Language”.

For me, this “first language” was C. To be honest, I don’t feel like there is a better option to select. C is an excellent, “mid-level” language that follows many of the practices found within my studies. For example, in “Apprenticeship Practices”, the book warns of becoming stuck within your “native tongue”; I feel as though this is negated (or at least parried) by many of the practices in C. C works closely with hardware, and involves skills found in assembly language, but can also be used to emulate higher level languages such as Java.

When it comes to my professional career, “my first language” is a philosophy that has given me a greater appreciation for the diverse landscape of large-scale projects. The C language has elements similar to Python, such as arrays. While data structures are not an impressive connection (they can be implemented among pretty much any language), it does make crossing the gap easier. Once at Python, I can learn about dictionaries, “key: value” pairs that can have an ideological equivalent found in .yaml files and JSON, and so on.

Interestingly enough, despite the emphasis on programming diversity, the pattern stresses finding a first language and staying strictly to its community. I feel mixed emotions about this philosophy: on one hand, it sounds as though “bridging gaps” found between languages should be avoided. On the other hand, constant practice is the best way to learn a first language, and that practice can be boosted by feedback from a desired community around that language.

Overall, I have an appreciation for the idea that beginner programmers should stick to one language when starting out. However, if I were to make a suggestion for that first language, I would suggest C. While challenging to learn, its connections to other languages and diverse applications can make powerful programmers.

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.

For the longest time Java has been an Object Oriented programming language first and foremost however it was never purely Object Oriented in its design. There exists some objects which are immutable and cannot be changed under any circumstances. String is an example of this and works by having a new object instance created whenever changes need to be made rather than altering the object itself. This is a hallmark of Functional Programming and part of the greater trend of java being pushed to be more akin to Functional Programming languages such as C.

This is something that Ian Darwin reviewed in his Java Magazine article going over the changes Java has seen over time. In this article he asks the question “Why is Java making so many things immutable?”. Put simply the answer is a matter of security and performance with immutable objects being more resilient to attacks and better for performance. Darwin provides examples with the String object which has been immutable since the very beginning. Along with this the Date and time API  has been moved to an immutable package since Java 8.

In the early days of Java there existed Java beans which Darwin describes in the article by the original spec which states: “A Java Bean is a reusable software component tat can be manipulated visually in a builder tool”. What does this mean? It means that Java Beans are more or less Java objects with a set of requirements to be classified as such. There include having set and get methods, expecting to be serialized and implementing the Serializable Java package, and it must provide support for design-time customization. The main takeaway is that these were always mutable and ever since then Java has moved away from this as its language has overtaken servers and enterprises alike.

Why has Java attempted to move to a Functional Programming paradigm? In today’s world many businesses and enterprises utilize Java on a large scale and in general and any way to gain more security or performance in a programming language will do a lot for a language as ubiquitous as Java. The creators understood the need for security with the String class as it has been immutable from the start. We can see below an example thread by Ian Darwin that could take advantage of and break Java’s entire security model if Strings could be modified.

Good Thread: Open File xyz.
InputStream Constructor; call security manager.
Security manager – Read file xyz – Permission is OK.
Bad Thread wakes up at just this moment.
Changes file name string from ‘xyz’ to ‘/etc/passwd’
Yields the CPU
Good Thread
InputStream Constructor: pass /etc/passwd to operating system open syscall
Bad Thread examines memory buffer for useful information to steal

Beyond the security benefits that these immutable objects pose there is also a matter of being able to increase performance of Java. Java is constantly being improved and as it’s performance increases it has become apparent that it is faster to create new objects than it is to modify the properties of old ones. Java lacks the ability to use pointers like C and because of this any extra baggage that can be removed to free up resources helps in a language like Java. If you compare Java at release and Java today, you can see that a myriad of new immutable APIs are scattered across the language as it has grown and evolved. This will likely continue so long as Java is a dominant language in the programming field.

Bibliography

Darwin, Ian. “Why Is Java Making so Many Things Immutable?” Blogs.oracle.com, https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records.

https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records

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

During the early days of the web, front-end development was less complex focusing mostly on static documents, linking pages, and basic design. As time went on, more and more functionality has been given to the web browser making front-end development a major field. Front-end development is the client-side programming of a web appl

During the early days of the web, front-end development was less complex focusing mostly on static documents, linking pages, and basic design. As time went on, more and more functionality has been given to the web browser making front-end development a major field. Front-end development is the client-side programming of a web application. This type of development focuses on the design, functionality, and interaction of the webpage with the backend components. 

The structural components of front-end development takes place in HTML, which stands for HyperText Markup Language. HTML defines the layout of the webpage elements along with their content and properties. Each html element has its own tag name which separates it from others based on the functionality it provides. For example, a video element will provide different functionality than an image element or a header element.

By default, an html page is very bland. CSS, Cascading Style Sheets, is used to style an html page giving each element or a group of elements custom properties. If the background color of the website needed to be black and the text white, this would be done using CSS. 

Other than some simple animations with css, all front-end functionality of a web page comes from Javascript. A once simple scripting language designed for simple html modifications that evolved into a large front-end and back-end programming language. One use of javascript is to dynamically control html elements on the webpage. It also handles making and receiving requests from web servers. 

Originally, when data was submitted in a web application, the entire page would need to be refreshed to pull an updated html document which was common with PHP. Today, a common design architecture is to have a single page web application where the data is synchronized to the webpage without needing to be reloaded to update. 

Due to the complexity of making a single page web application, many frameworks exist to make development easier. These include react, vue, and angular. These frameworks handle linking data to components and binding the data between the server and the client. This way, only the element with updated data needs to be refreshed rather than the entire page. Handling updates in this way makes working with web applications faster and improves the user experience.

I selected this article to learn a bit more about frontend development and its current features. We will be working on client-side development in this class and I thought it would be a good topic to look into. I find it interesting the history of how the web has developed over the years. I will use this guide with its details to help me structure my projects in the future.

Resource: https://info340.github.io/client-side-development.html

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

Over the course of several weeks, we’ve been working with a modeling language called Unified Modeling Language (UML). UML is a visual language that visualizes the structure of a program using UML Diagrams so that its behavior can be analyzed by developers. Different objects and classes, such as a class hierarchy or object composition between classes can be easily represented¹. By visualizing the software’s code, the UML Diagrams allow a far quicker way for a developer to analyze its behavior and if necessary, allow refactoring in the code.

Code that is poorly designed can contain what is called Technical Debt. Technical Debt of poor design implements at least one of the seven Design Smells; Rigidity, Fragility, Immobility, Viscosity, Needless Complexity, Needless Repetition, and Opacity². Code that is difficult to change has the “smell” of Rigidity, and must be refactored in order to allow change and flexibility in design. 

In class and in homework, we’ve been given code and a UML diagram providing the structure of said code. Using the UML Diagrams, we can understand where the code is going wrong, and what to do to refactor the code to remove its Design Smells. Without the UML Diagrams, we’d only have one or two objects or classes at a time to look through, making its structure far more difficult than it would otherwise be without using them.

On the other side of development, creating software while implementing a UML Diagram is very easy to implement, even for a university student. This ease of implementation and its low cost has allowed UML to become a standard through the International Organization for Standardization (ISO)¹. As such, there does not exist a good reason why a developer would not want to document his implementation using a UML Diagram.

I wanted to discuss UML Diagrams and the Design Smells because I’ve developed software consisting of over 10,000 lines, and it is very easy to establish a confusing nexus of classes and objects. It is also very easy to lose track of the design, or hard to understand the system’s design without something like a UML Diagram. The Diagrams we’ve discussed in class and gone through in the homework is another big reason, as I understood the logic of the code and what needed to be done before I even saw a line of code. I will be using UML Diagrams from now on so I may be able to document my code for myself, maybe even for the students I help tutor that need help understanding class hierarchies.

Links:

1. https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

(Provided a good explanation of UML)

2. https://learnbycode.wordpress.com/2015/08/01/401/

(Good explanation of the Design Smells)

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

“Don’t ever leave your baby in the road.” – My First Computer Science Professor, 2015.

That came out of left field, didn’t it? However, the quote (much like YAGNI) makes a lot of sense in the world of Computer Science. Specifically, this quote refers to the idea that you should never “assume that you’ll always be careful and pay attention”, but rather you should prevent any mishaps from happening in the first place. Global variables, for the most part, should be avoided; the ability to be accessible from anywhere within the program is dangerous to say the least.

However, the “Singleton” method of refactoring seems to make an argument for the usage of global variables (provided that they still have a level of protection from modifying the data). Singleton refactoring works on the idea that having one “global” instance of a behavior class can save on memory; client classes using the same behavior can reference that single class. However, due to certain features (for example, making the constructor a private method within the class), having a global Singleton object will not endure the same problems that traditional global variables bring to the table.

This is opposed to the “Strategy” method, which involves creating new classes upon new classes for each new behavior found within a project. This way, we can create an interface for this behavior, and have it implemented by client classes that use it (this will save on memory from unused, inherited methods). Yes, the Strategy method is a step-up from mere method overriding. However, its need to constantly create new classes takes up massive mountains of memory in its own right (which can lead to poor performance).

Both ideas (the Singleton and the Strategy) are discussed within the articles linked below. I personally picked these articles due to the fact that they were my “help reference” when working on some of the homework assignments. Refactoring Guru is a great website that summarizes different refactoring strategies, as well as providing pseudocode and applications of each strategy in the real world.

I hope to use this newfound knowledge to improve upon my refactoring skills; this in turn will cut down on code smells, and create more efficient solutions to programming problems. When considering the Singleton design, we can use global variables without running into code smells such as “needless complexity” (by bringing in an unnecessary aspect), “viscosity” (by making future updates more difficult to implement), or “fragility” (by errors caused from having the data modified anywhere within the program). As for the Strategy design, we can ensure that classes only contain methods that they’ll actually use; this cuts down on the “needless repetition” coding smell (by ensuring that inherited methods don’t go unused).

Links: https://refactoring.guru/design-patterns/strategy

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

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.