This Apprenticeship Pattern deals with a beginner programmer trying to enter the field by learning his first programming language. The pattern suggests various ways the beginner programmer can increase his experience, including but not limited to: learning a programming language from a friend, reading books based on it, and or joining a community around that language.

One of the things I find particularly surprising that is mentioned in this pattern is utilizing “test-driven development techniques”. While I have used testing before as I was learning my first programming language, it may have helped me learn features about the language and development in general that I haven’t yet thought of. For instance, if I create a class and I need to test it, creating test cases allows me to break down a class that I understand and view it from a different perspective.

This pattern has somewhat changed the way I think about my profession. Much of the changes in my thought about my career have to do with an explicit acknowledgement from reading this pattern, especially in relation to things I’ve known but never completely acknowledged. Mastering a programming language really does make the most sense to me, and it is something I’ll recommend when others who want to get into programming ask me.

I do disagree with two parts of this pattern. The first is in relation to which programming language one should choose. This may cause difficulty due to the issue of a complete beginner not having appropriate context to the uses of a language, and thus if left alone he could make a decision that could limit his beginning programming experience, and thereby causing a ripple effect down his career. 

The select part I disagree with follows up from the first. If he decides to learn a programming language based on his friends, this may cause a similar issue. If he decides to learn JavaScript from his friends, which he could eventually master, he could have a hard time contextualizing other features present in other languages. Thus, even though the pattern mentions not to be pushed towards a “one-size-fits all approach”, learning a more general programming language like C++, though fairly dense, can give more context to other languages, from JavaScript to x86 Assembly. 

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.

Throughout this semester, the most interesting topics to me are those relating to how to produce good code. While I like learning about and implementing API requests in either the frontend or backend, regulating code utilizing something like the SOLID principles is interesting to me because it can be applied in many different situations and programming languages. We discussed the SOLID principles earlier in the semester, and while I walked to discuss them on this blog, I never got a chance to.

The Single Responsibility Principle states that a class should only have one job. The below article uses the example of shapes, namely a square and a circle. The Square class has the length of a square, and the Circle class has the radius of a circle. Another class, AreaCalculator, contains the logic that deals solely with adding the area of the different shape objects.

The Open-Closed Principle states that “Objects or entities should be open for extension but closed for modification”. If a programmer would like to take an existing class and add functionality to it, the existing class should be developed in such a way as to allow easy inheritance, and the programmer should add his implementation in an inherited class. In the article’s example, the author adds an area() function in the shape classes to calculate each shape’s respective area, then changes the design to implement a shape interface, which is implemented by the shape classes. The AreaCalculator then checks the instances of Shape Interface, and calculates that way.

The Liskov Substitution Principle states that every child class should be substitutable for their parent class. This means that a child class acts in the same way as its parent class, in this case, providing similar functionality and returning in a similar format. The article uses the example of a class called VolumeCalculator, that inherits from AreaCalculator. Both VolumeCalculator and AreaCalculator must be consistent, such that its implementation is the same.

The Interface Segregation Principle states that a client should never be forced to implement an interface that it doesn’t use, or depend on methods they don’t use. Building on the author’s example, if we needed to calculate the volume of a sphere, a class shouldn’t manage both a circle and a sphere, but segregate them into two different classes.

The Dependency Inversion Principle states that “entities must depend on abstractions, not on concretions”. In the author’s example, one class connects to the database, whereas another class depends on the connection class, thus they cannot decouple. Instead, we should implement a class using an interface, which is the parent class of the connection class. Abstraction is now applicable in both high-level and low-level classes.

Going through this article has been informative. I would also like to practice implementation and classes in Java or C++ to gain a better understanding of these principles.

Link:

1. https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

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.

Since we’ve been using JavaScript for the past several weeks in class and in homework, I thought it would be beneficial to help run through some elements of JavaScript I found weird or difficult at first. I’ve noticed some people have a harder time understanding JavaScript’s syntax or how its variables work, so I wanted to make this as a sort of reference.

Types

JavaScript contains primitive and non-primitive types. A variable can be declared with “var”, “let”, or “const”, more on const later. The main primitive types are¹:

• Boolean: true, false
• Null: null
• Undefined
• Number: 72, -174.21
• String: “Hello, ”, ‘world’

For an object type, objects are very loose and can for the most part be defined with relative ease. 

Let’s take a simple object, named “car”.

This object has three properties, wheels, year, and color. When declaring or assigning properties, the syntax shifts from the typical use of “var num =”, to “num: ”. These properties in an object are pairs: “wheels” and “4” are a pair, specifically a key-value pair as well as an object. This means that there is more than one way to access an object’s properties. 

The second one looks suspiciously similar to a map, specifically one in C++. Objects may be iterated through using a for-loop directly.

Functions

Functions may be defined in a few ways. If inside of an object, the function would be defined as:

Else, it may be defined as the following:

The bottom function declaration is known as arrow notation. A function with arrow notation is not bound to an inherited constructor or the keyword “this”, and its usage with scopes may be troublesome. Its parentheses may be dropped if there does not exist any parameters, such as “getProps => {}”².

JSDoc

JSDoc is a markup language used to comment JavaScript code, and is similar to JSDoc in many ways. JSDoc may be created by typing “/**”, then pressing enter upon this pop up:

JSDoc is, in my opinion, very useful in declaring classes, functions, objects, types, or declaring types. This is especially important with JavaScript, since types are handled dynamically.

JSDocs can use the following my pressing “@” inside of the comment, revealing a large list of descriptors, with users being able to make any and anytime³:

Upon creating a simple JSDoc annotation:

Hovering over the object “car” will read:

For our function getValue:

This is rendered as: 

Hopefully, this post can be helpful. JavaScript was odd for me when I first started, with these topics being some of the things that took me a while to get used to. The sources contain a wealth of information that I have and will continue to refer to and learn from, and hopefully they can help you too.

Links:

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures (Types)
2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions (Arrow Functions)
3. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html (JSDoc)

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.

In class, we’ve been using vue.js. Vue.js seems to have many similarities to React, so I thought it would be informative to briefly discuss how to implement React components. Vue.js seems to also use components, so I thought it would be helpful to explain a common concept that seems to exist between the two.

I open visual studio code, and open the terminal. To create a react app, I typed the following commands:

• npx create-react-app reactapp
• cd reactapp
• npm start

After React finished installing, I changed my App.js to this:

This component’s render() function will display the content on the webpage using JSX¹. There is currently nothing but an empty screen. Instead of writing everything inside a component, we should segregate the information into separate components, that would then be called in this central component.

For this example, we’ll create a webpage with four parts: a header, a navbar, a side pane, and a main pane. Each component will contain its own js file. Since we’re making a very simple web page, the header will be a simply designed bar. I created a blue bar in Paint, and I imported it using CSS. The header will contain a title, and compose the top of the web page.

Below the header should be the navigation bar. For the sake of example, the navbar here will just display the formatted text on it. The navbar would in practice function as a transition between web pages.

Next is the side pane. This side component on a website could function as a way to automate section traversal, as is done on a wikipedia page. If the main section has a title such as “Lorem Ipsum”, it would list “Lorem Ipsum” with the ability for a user to highlight and click on it. Like the navbar, we’ll only create a very simple display.

The final component is the main component. This component will be where we put our text. I created a title called “Lorem Ipsum”, with some body text.

We now need to add our components into our previous App.js file. The top will contain the header and the navbar, and the body will contain the side pane and the main pane.

Finally, we need to create the CSS. For my design, I am using this inside of the App.css file, which is then imported into App.js.

For our product, we get this (the bottom part was cut in the screenshot for space):

While it’s not winning any awards, it’s a draft of a simple website design. This illustrates how components work together, in a library like React, and I hope this helps with understanding vue.js too.

Link:

1. https://www.youtube.com/watch?v=w7ejDZ8SWv8 (For discussing how components and JSX work, so I could make this guide!)
2. https://reactjs.org/tutorial/tutorial.html (ditto)

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.

In our most recent class, one of our in class activities mentioned asynchronicity for a JavaScript function. This function required us to use the “await” keyword for us getting data. I’d thus thought of doing a post on concurrency, but in my experience in using concurrency, I’ve noticed myself and others struggling with the difference between concurrency and parallelism. Hence, in order to clearly understand concurrency, I wish to also describe parallelism. 

An application that is neither parallel nor concurrent is one that is processed sequentially, typically one “where it only has a single job that is too small to make sense to parallelize.¹”

Parallelism is simply the separation of a task into multiple sub tasks. These sub tasks are simply parallel if they are worked on sequentially. If two or more sub tasks are being worked at the same time, the program is implementing both parallelism and concurrency.

Concurrency is the act of an application working on two or more parts of an application at the same time. One thread could be running through an array, while another is doing a separate calculation. If an application is running without implementing parallelism, then it is working on each part of the application.

An application that is both parallel and concurrent can partition parts of the application and executes the program’s sub tasks concurrently. It may also include programs that divide a subtask into further subtasks and run those concurrently too.

I picked this particular source because it articulates the difference between concurrency and parallelism, rather than just one or the other. It also has a section that shows the permutations of implementing concurrency, parallelism, both, or neither. Even though I know about parallelism and concurrency, this article in particular helped me visualize them. I did not know that one could implement concurrency without parallelism. 

I feel as through this article will help me understand some elements of homework #5, because it will likely include functions that are asynchronous, and therefore require us to acknowledge it by properly implementing the “await” keyword. While this article was oriented towards locally run applications, this will also aid with applications that are executed to and from servers, by which the topics of parallelism and concurrency will still render useful.

I have also created a program that attempts to implement concurrent execution between multiple sub tasks that exist from implementing parallelism, which this article helped me understand. Specifically, I generate a vector with integers, then split the vector into subtasks which are then run concurrently. Each vector sub task gives the average sum of their respective sub task. 

Links:

1. http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html (the proper article sourced for the information)
2. https://github.com/Chris-Archive/Vector-Parallelism-Concurrency (my GitHub repository of the example I used above in C++)

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.

Over the course of the semester, we’ve discussed servers, databases, and monolithic and microservice architectures. We’ve discussed and are currently working on rest APIs which allow us to send and receive information to and from the Internet. While working with rest APIs and doing research on my own, there are elements that exist in what we’re doing that we have yet to discuss. These different elements are paraphrased from parts of the articles linked below.

“REST” stands for “Representational State Transfer”. It is a style of architecture that allows proper interaction with web services that are “RESTful”. In a microservice architecture design, there exist different elements in the software, e.g. one service could manage a consumer’s payment, whereas another service can handle a company’s product/service. In this separation of different systems, there exists a need to communicate these different services together. 

REST APIs function as the glue between different services. However, this requires further inquisition: why would we use different services? Wouldn’t the separate systems just use more memory by saving redundant information? This question brings us back to the “S” in “REST”, namely “state”. When sending information from or to another service, an object’s data is not saved in the service as the request, more specifically, the information in each request is “separate and unconnected”¹ This concept is called “statelessness”.²

Another aspect about microservices is serialization. Serialization is the act of transferring an object with variables and their respective mutators and accessors into a stream of bytes. This stream can be of binary data or a string. Information about an object that is passed through various services requires serialization, which can then be compared with other streams for object comparison, and eventually deserialization.³

We’ve previously discussed docker, characterizing it once as “lightweight”. These aforementioned aspects are the ingredients that can allow containerization and their containerizers such as Docker to be so lightweight.

I decided to talk about this subject because state / statelessness, serialization, and architecture design will be an important part of a future job. A lot of my research so far is applicable to what we’ve been doing, and I think the concepts and their implementations are, to me, novel, interesting, and important. This information is to my current understanding, and it has the risk of being incorrect, due to me still learning about them. However, I still decided to talk about these topics because understanding the anatomy of how everything comes together and operates is interesting, especially with what we’ve done in class.

Links:

1. https://www.redhat.com/en/topics/api/what-is-a-rest-api
2. https://www.redhat.com/en/topics/cloud-native-apps/stateful-vs-stateless
3. https://dev.to/njnareshjoshi/what-is-serialization-everything-you-need-to-know-about-java-serialization-explained-with-example-9mj

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.

Several of our classes have discussed two different forms of software architecture. Due to my intent to graduate with both Software Development and Big Data Analytics concentrations, this topic especially interested me. On one hand, I need to know the software architecture designs to best plan an implementation for, and on the other hand, I need to know how to deal with massive data sets. These two factors combined peak my interest as an intersection point of both fields.

A server-side application has several components, namely presentation, business logic, database access, and application integration. The Monolithic Architecture will package these components linearly, resulting in ease of development, testing, deployment, and scalability. However, its design flaws include limitations in size and complexity, difficulty in understanding, and application-wide redeployment.¹

The Microservice Architecture is split into a set of smaller and connected services, each with its own architecture. Each service performs a given task(s) which is then, in one way or another, linked back to the other services. Microservice Architecture is characterized as faster to develop, independent deployment, and faster and independent scalability. However, its disadvantages include added complexity, increased difficulty in testing, and increased inter-service change difficulty.¹

With these things in mind, questions such as “should I implement a Microservice Architecture or a Monolithic Architecture”, and “should I always use one or the other” arrive. What I’ve learned is that despite the fairly detailed description of both of these architectures there isn’t a uniform consensus of when to apply them. Martin Fowler says a Monolith Architecture should always be implemented first, due to the fact that the Microservice Architecture implies a complexity that may not be needed. When the prospects of maintaining or developing a monolithic application becomes too cumbersome one should begin transitioning into using Microservice Architecture², Stefan Tilkov disagrees, however, stating that building a new system is when one thinks about partitioning the application into pieces. He further states that cutting a monolithic architecture into a microservice architecture is unrealistic.³

Would I start using Monolithic Architecture, or would I start using Microservices Architecture for software? While thinking about this problem, I know that different parts of the application are doing different things. One deals with users placing orders, which in turn requires the user to have their own UI, API, Database, and servers; and the other requires the approvers to have their own UI, API, Database, and servers. This is convincing in favor of not beginning development with a monolithic architecture design, since planning an application’s design should be thought of immediately. Therefore, I agree with Stefan Tilkov more on this issue, based on the knowledge that I have as a student.

Links:

1. https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
2. https://martinfowler.com/bliki/MonolithFirst.html
3. https://martinfowler.com/articles/dont-start-monolith.html

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.