DEV Community: Vahid Dejwakh

Docker and the rise of microservices

Vahid Dejwakh — Mon, 14 Jun 2021 12:53:00 +0000

What is Docker, What are microservices, and Why should we care?

This article was originally published here.

As applications grow in use, the ability to scale becomes paramount. The solution often is to divide your codebase from a single monolith into multiple microservices. Why is Docker a key component in this new architecture, and what does this all even mean?

I. From Monolith to Microservices

Before the rise of complex and ubiquitous online services like Google, Facebook, Amazon, Netflix, and YouTube, the standard way to deploy a web application was to have one central codebase that handled everything, from user authentication to interacting with multiple databases to processing payments.

As you can see from image A) on the left above, all the business logic was tightly coupled in the same application, including the logic that handles interactions with database(s).

This behemoth application is called a monolith.

The monolith architecture makes growing and scaling an application more difficult. While a small or even medium-sized monolithic codebase can be copied and deployed on multiple application servers distributed geographically, larger and larger monoliths face challenges that make this process less and less appealing.

1. Requires high level of coordination

There are several reasons why deploying and growing a large monolith is difficult. First, there's the coordination aspect. Teams responsible for different parts of the application have to make sure that their changes to the codebase are done harmoniously without either creating conflicts with or worse, causing errors to another part of the application.

This requires significant coordination and communication, but also reduces the speed at which updates can be made.

2. Costly redeployments means slower upkeep

Another problem is that every single change to the monolith, no matter how small, requires redeploying the entire codebase. This can make updates so taxing and take so long that they can only happen occasionally, which means responding to changes or adding more features also takes more time.

As the codebase grows, the interval between each update may therefore also grow, as more effort goes into consolidating many updates into the same deployment.

3. Higher learning curve

Another major downside of large monoliths is that onboarding new engineers is challenging and requires more time. In order to understand how to update, fix, add, or otherwise troubleshoot a feature, an engineer may need to understand how the entire system works. If we're dealing with several thousand lines of code, this is manageable. But multiply this by a thousand, and it becomes almost impossible.

This higher learning curve means that it's more expensive to hire and add engineers to the team, since they must spend more weeks in training before they can actually start to be productive.

4. One language for all

Another problem of a monolith is that it needs to be written in the same backend programming language--whether that's Node.js, Ruby, Go, Python, Rust, PHP, Java, etc.

Languages all have tradeoffs: some are better for certain use cases over others. For example, Node.js's use of JavaScript and its large, prolific community make it ideal for small teams working on small to mid-sized applications or microservices, but its single-threaded V8 engine makes it not as efficient as Go, a master of concurrency thanks to its ability to use multiple channels, and the efficiency gains from being a compiled language.

With a monolith, you are unable to take advantage of the strengths of each language, and you have to accept the entire language for every segment of your application--even if another language might actually be better suited for a particular segment.

5. One bug means the entire application is down

Another problem of putting all your eggs in one monolith application is that if any part of the application fails, the entire system is down.

Yes, you can and should try to handle exceptions as much as possible, but you can't always predict how your code will behave in production.

When any piece fails, the entire system goes down.

6. Inefficient growth

Finally, the last main reason monoliths are not well suited for growth has to do with the fact that if one aspect of the application needs to be scaled, then the entire application--including parts that don't handle much traffic--must also be scaled.

It's like a situation where a family has a two year old, an eight year old, and a twenty year old at dinner, and the twenty year old goes through and finishes his meal very fast. Instead of allowing the twenty year old to help himself to more food, you, the parent, pour an additional 100% more food on every child's plate.

Some of that additional food is unnecessary and will go to waste!

Wouldn't it be better to be able to target each child's needs individually, irrespective of the others?

II. Microservices To the Rescue

Let's get back to the image above, and imagine that our monolith application in A) handled:

Showing and searching our company's inventory to the customer (e.g. the red heart shape in Martin Fowler's diagram),
Processing payments for an order (e.g. the green X), and
Tracking shipments (e.g. the grey blob).

As the diagram shows, all of these might require interactions with a database.

The microservices architecture in B) would instead break each of these services up into separate, independent applications, each with its own database, and each able to receive requests and respond with some information.

These microservices would then be independently scalable, updatable, and could be written in a different language entirely. They can communicate with each other over HTTP through REST-ful APIs, or some other agreed protocol.

The diagram shows, as an example, how the inventory service (the red heart shape) was scaled to two instances, perhaps because more people just search the inventory without actually purchasing. This architecture would allow that, without forcing us to also scale the other services.

Organizationally, teams could be responsible for separate services, and as long as they do not change the format of inputs or outputs of the service, they can push updates without checking with other teams.

And thanks to microservices being independent of each other, even if the shipment service goes down, customers can still look at the inventory and make a purchase.

III. Tradeoffs & New Problems

We can now appreciate why microservices are becoming more prevalent. So we should just convert every application to a microservices architecture, right?

No, of course not. For most applications, from startups to mid-size, a monolith works fine and is probably actually preferable. That's because just like everything else in tech, the microservices solution now introduces its own set of problems.

Monoliths are much simpler to understand and debug; microservices introduce more complexity. Monoliths tend to be faster, since internal function calls can happen synchronously. Now, as a result of communicating over APIs, the microservices system introduces latency and security issues.

With so many different services, deployed on so many servers worldwide, how do we deal with versioning? How do we deploy systematically? How can we automatically spin up a new instance of a service that we need to scale?

IV. Introducing Docker

We're finally at a point where we can appreciate Docker.

At its core, Docker facilitates the process of duplicating and starting an application in the same exact configured environment everytime.

A Docker container is an environment in which a bundled application runs the same versions of every layer wherever deployed.

This means that any new application or microservice can now more easily be spun up to run and behave exactly the same way as the original.

A container is different from a virtual private server (VPS) because it does not include the operating system layer, so it's smaller in size (about 10 to 100X), and more easily deployable. While a VPS might take 3 to 10 seconds to boot on a relaunch, a server running a container can reboot the container's application packages in less than a second.

Let's go through a quick overview of the Docker ecosystem and some of the most important components and terminal commands.

First, a file named [1] 'Dockerfile' serves as a config file necessary to build [2] a Docker image.

This image can then be shared remotely via either [3] a private registry (e.g. AWS) or [4] Docker Hub, which is publicly accessible and contains the official images of commonly used software and services.

To pull an image from or push an image to any remote service, and generally to run any number of container(s), the [5] Docker Daemon must first be installed and running on the end machine.

The developer interacts with the Daemon through either a [6] CLI or GUI client.

An image is used to create [7] container instances, which can start and stop to run.

Each running container must be bound to a particular [8] host port.

Containers that need to communicate together can be run inside the same [9] Isolated Docker Network.

V. Summing up

We've seen the problems of large monolith applications, and why they are more difficult to scale.

We discussed the advantages of microservices architectures, and why they are growing in popularity.

We also understand the tradeoffs of this new approach to writing software applications, and why monoliths are still probably better suited for small to mid-sized applications.

Finally, we also looked at how Docker facilitates the process of starting and deploying new instances of applications across servers worldwide. This significantly facilitates the movement towards microservices.

I hope it's been a useful read. Let me know if I left out any other important aspects of this fascinating topic, or if you have any other questions!

Encapsulation, Polymorphism, and Abstraction in Ruby

Vahid Dejwakh — Wed, 04 Nov 2020 21:28:52 +0000

This article originally appeared on https://vahid.blog/

Did you know that Ruby was good for the environment? It is, because it follows strict EPA principles... Encapsulation, Polymorphism, and Abstraction. [Ducks a volley of Tomato objects thrown at him].

In a previous post, we discussed the importance of classes in OOP, and developed the mental image of classes as providing more defined jobs and roles to our data. To summarize: classes allow us to build applications that scale well and deal with more complex and customized data structures. They do this by enabling us to store data in specific ways (i.e., attributes) and to interact with this data both internally and from the outside world, also in specific ways (i.e., behaviors, or methods).

In this article, we'll define and understand all the following terms and concepts: encapsulation, polymorphism, abstraction, method access control, class inheritance, single inheritance, multiple inheritance, duck typing, is-a relationship v.s. has-a relationship, collaborator class and collaborator objects, syntactical sugar, superclass, nil v.s. nothing, dynamically typed v.s. statically typed, interface inheritance, mixin, namespacing, collisions, composition v.s. inheritance, method lookup path, overriding inherited methods, ancestors, and classes v.s. modules.

In the process, we'll enrich and solidify our understanding of OOP principles, and more fully appreciate the many ways Ruby empowers us to write beautiful, concise, safe, and DRY code. Let's get to it.

Building Blocks of OOP

There are three pivotal concepts and building blocks of OOP in Ruby. They are:
1) Encapsulation - Protecting access to data and functionality so that these are unavailable to certain parts of the codebase is how we ensure data is only intentionally accessed and correctly manipulated. The data is thus encapsulated, or shielded.

Through the use of class objects, we can create instance variables and instance methods that are encapsulated and thus only accessed by either the object's class or the object itself, but nothing else. Through the use of method access control, we can even further encapsulate these so that even the object itself does not have access to them. Method access control allows us to qualify instance methods as public, private, or protected, which impacts how accessible these interfaces are to the outside world.

Encapsulation also enables abstraction, the third principle of OOP. We could think of abstraction as a subset of encapsulation, but it's such an important concept that many think it deserves to be a standalone principle--and I agree. Encapsulation is also itself meaty and important enough--even without its role as the father of abstraction--to remain a standalone principle.

(Also: I've been wanting to describe something as "the father of abstraction" for a while now, and this was the perfect setup. I wish it was referring to me, but I guess encapsulation is the better man. Alternatively, I could have a kid and name her/him Abstraction. Then, at last, I could claim this glorious title. What? No, she wouldn't mind.)

2) Polymorphism - Literally means "having multiple forms." When objects of different classes have access to the same interface (i.e. method), they are polymorphic. The idea is that the common method reveals and expresses itself in the many different (class) forms or objects it inhabits.

The religious studies student in me cannot help but to point out how similar this concept is to polytheism, incarnation, and manifestations of God or the Holy Spirit, where the same divinity takes on many forms, physical or otherwise.

Polymorphism can be accomplished through three main ways in Ruby: class inheritance (i.e. from a superclass, establishing an "is-a" relationship), interface inheritance (i.e. from a module mixin, establishing a "has-a" relationship), and duck typing. We'll get to each of these later.

Sidenote: some place inheritance as a standalone, fourth principle of OOP, especially in the context of Java. Doing so in Ruby makes less sense, however, because the only practical application of polymorphism as applied to Ruby is the idea of inheritance.

If we extracted and placed inheritance as a standalone principle, polymorphism would just be an empty shell. Plus, we'd also have to do away with that brilliant EPA joke and replace it with some lame E-P-A-I joke that doesn't even make sense, like:

-- "What did the Canadian Rubyist respond when he was asked to incorporate OOP principles?"

-- "API, Eh?"

See? You're welcome.

3) Abstraction - The ability to simplify complex state and sets of behaviors into one unifying entity makes a programmer's life easier, because all of that complexity is abstracted away and replaced by that umbrella entity (e.g. a class object). This allows us to more easily conceptualize what an object does, how it behaves, and how the outside world should interact with it.

For example, for a card game application, we may create a Deck class that contains, as an attribute, an array of cards, where cards themselves could be objects of a Card class. The Card class may have several attributes, including suit and face. Our Deck class may also contain several behaviors, including deal, shuffle, and count (to return how many cards are left in the stack). This makes our life easier, because we can more abstractly just think of a Deck object, and not have to worry about all of its methods and attributes, which will remain encapsulated in and "travel with" that Deck object everywhere it goes.

In this example, both the Card class and the Array class are said to be collaborator classes of the Deck class, since the Deck class incorporates them as attributes. We can think of collaborator objects as lower levels of abstraction of the owner object whose class incorporates them. We can therefore imagine scenarios of multiple nested collaborator objects, each producing various levels of abstraction.

Another example of abstraction is syntactical sugar, which is when a language offers an easier or simpler way of doing something. For example, using [] to return a specific element at a particular index in an array (or to return a value with that specific key in a hash) is a form of syntactical sugar.

Under the hood, calling some_array[4] is the same thing as calling some_array.[](4). The [] is actually just an instance method that takes an argument, which is the key or index. This [](arg1) method has been abstracted away and simplified by the smoother [arg1] method. (Note: both versions can also take an optional second argument and thereby mimic the Array#slice method, allowing us to capture a range of elements).

Similarly, doing some_array[3] = 5 is the syntactical sugar equivalent of some_array.[]=(3,5). Under the hood, we are just calling an instance method named []= on some_array, and passing it two arguments: the index number, and the value we want to set the element at that index number to. The [a]=b form is a more abstracted version of the .[]=(a,b) form.

To conclude, here's a random abstraction joke so that it doesn't feel jealous of the fact that the other two OOP principles got to have jokes:

What did the agitated but confused programmer-turned-public defender yell when the prosecutor was making an overly simplistic generalization about the defendant?

-- "Objection, your honor!"

-- "On what grounds?"

-- "Abstraction!"

I mean I could go all day.

All the three principles of OOP identified above allow our code to be 1) DRY (don't repeat yourself), 2) more maintainable, and also 3) easier to understand and conceptualize.

Now that we've defined the three main principles of OOP, let's see how classes and modules help us achieve them, and how both of these work together to create the concepts of method lookup path and ancestors.

Here's a diagram that shows the relationships between modules and classes, and some of the most common instances of these that come prepackaged in Ruby.

Classes are in the light grey rectangles, and modules are in the green clouds.

[[download diagram as PDF]](https://www.vahid.blog/post/2020-11-04-encapsulation-polymorphism-and-abstraction-in-ruby/class_hierarchy.pdf)

Class Inheritance

Ruby comes with multiple built-in classes, including String, Integer, Hash, and Array. These four classes are probably the most frequently used collaborator classes for any custom classes we might want to create.

Each class is itself an object (or instance of) the Class class, which we can think of as the primordial class, sort of like the Biblical Adam and Eve of all classes.

What is class inheritance? Every class inherits methods and attributes from another class, which we refer to as the class's superclass. Calling the class method superclass on any class will return that class's superclass. For example: puts Integer.superclass will output Numeric.

Every class has one (and only one) superclass. This is called single inheritance because a class can only have a single parent. When we create a custom class without explicitly defining a superclass to inherit from, our custom class implicitly inherits from the Object class.

In the diagram above, we see that the superclass of Numeric is Object, and the superclass of Object is BasicObject. What's the superclass of BasicObject? It's nil.

Sidenote 1: the difference between `nil` and nothing

Nil is not the same thing as nothing, however. Although nil is not a class, it is an object, an object of the class NilClass, whose superclass is Object.

Why is this distinction important? After all, if we have an array, some_array, containing 5 elements, and we call some_array[10], we'd get nil back. Doesn't that mean that nil is the same thing as nothing?

It appears that way, but it's not. The reason we get nil back is because the [] instance method, as defined in the Array class definition, is explicitly defined to return the nil object if there's no key that matches the argument (i.e. the index) passed in to the [] method.

If we instead use the fetch instance method, however, which contains no such safety measure, we'd get an error back if we try to search for a key that doesn't exist. So when there is nothing, we get an error. If there is something, even if it's nil, we get that something back (i.e. we'd get nil back). This means that nil is not the same thing as nothing.

Sidenote 2: Ruby has no Bool(ean)

Note, too, that Ruby doesn't have a "Boolean" class, which is unlike most other OOP languages. Ruby does have separate TrueClass and FalseClass classes, but there's no overarching "Boolean" class from which both might inherit--instead, those two classes each directly inherit from Object.

The reason for this has to do with the fact that Ruby is dynamically typed (as opposed to statically typed like C++ and Java). This means that in Ruby, we don't need to explicitly define what the class of a variable is. We instead dynamically (and implicitly) assign it a class, and can easily reassign it to another class (for better or for worse). A variable can therefore easily be assigned to true, an object of the TrueClass class, and then reassigned to false, an object of the FalseClass class.

Finally, as this more in-depth answer to this question argues, there just aren't enough shared behaviors between the two classes to warrant creating a common superclass. Yukihiro Matsumoto, the creator of Ruby (and affectionately known as Matz by Rubyists), has explained why he rejected calls to create a Boolean superclass.

Duck typing

The previous discussion is a perfect segue to duck typing. In Ruby, we are less concerned with what the class of an object is, and more with its capabilities, i.e. what instance methods we can call on it. If objects A and B are of different classes but they can both respond to a quack instance method, for example, then we can treat both as ducks (hence the name). If it quacks like a duck,...

To accomplish duck typing (i.e. not class inheritance), we can just merely explicitly define the same method in each class definition. Then, for example, we can call that method on any object of any of those classes, and we will get an acceptable, proper return. Duck typing is another, more explicit way to achieve polymorphism.

Is class inheritance the only way to inherit functionality? No--in Ruby, modules also allow this through interface inheritance. Let's dig into them next.

Modules and Interface Inheritance

All modules are objects of the Module class, which is itself an object of the Class class. Modules play two main roles in Ruby's implementation of OOP principles:
1) Interface inheritance - We can include the functionality of any module into any class by using the keyword include, followed by the module's name. Also known as a mixin (an abbreviation of "mixed in"), this allows all objects of that class to have access to all the instance methods defined in the module.

As the diagram shows, several native Ruby classes mix in either the Comparable or the Enumerable module. A common naming practice when creating a module that is used as a mixin is to name it with something that ends with "-able"--this makes it more easily identifiable and distinguishable from the other main type of module, used instead for namespacing.

Because there's no limit to how many modules you can include in a class, modules is how Ruby enables multiple inheritance. If a class needs to inherit two (or more) distinctly different sets of behaviors, you can't use class inheritance to do this, but you can use a mixin instead.

2) Namespacing - Modules can also double up as containers for any number of constants, classes, and/or isolated methods that don't really belong to any specific class. A great example of modules as a namespace is the Math module, which contains mathematical constants like Math::PI and methods like Math.cos (also accessible with Math::cos, though the former is the preferred way for calling module methods). This can be particularly useful when creating libraries/gems, or even when different team members are working on different features of a common application.

Namespacing is a practical way to not only organize related behaviors together, but to also prevent collisions. There's a likely possibility that more than one member of a large team (or that more than one gem or library) might name a custom class the same way, which would cause one class definition to collide with and override the other when they merge their code into the same branch, or when they combine those gems or libraries together.

Instead, they can place their class definition inside a module which could be named after their particular feature or gem, for example. That way, they can more explicitly access the class inside the module that they created, which would be distinct and encapsulated away from the same class inside another module.

For example, let's say Amanda and George both had to create a Student class for the feature they were building. However, Amanda's implementation focused on the financial side of the application and had to track how much tuition the student had paid so far, and how much they still owed, etc. George, on the other hand, was working on an academics-focused feature and using the Student class to track all the classes each student had taken, their grade for each class, cumulative GPA, etc.

Amanda can use namespacing and create a module called Finances, then define her Student class inside there. Anytime she wanted to instantiate a new student for her purposes, she could call Finances::Student.new and pass in any necessary arguments.

Similarly, George could create an Academics module, and define his Student class there. He would instantiate a new student by calling Academics::Student.new, along with any necessary arguments.

Sidenote 3: Composition v.s. Inheritance

In some OOP languages, the terms "inheritance" and "inherit" are exclusively used in the context of (and more narrowly used to refer to) when a class receives interfaces from a superclass (i.e., what we've had to qualify as class inheritance because of our broader/looser use of the term "inheritance"). While we described a mixin as an example of "interface inheritance," they would instead call it an example of a composition.

This is worth noting here only because Composition over Inheritance is a specific OOP design pattern that argues that favoring "has-a" relationships (i.e. through compositions, or mixins) ensures our code is more flexible and reusable than using "is-a" relationships (i.e. through class inheritance). This is why the Go language does not even allow class inheritance, and only uses compositions.

For our purposes, we can think of "composition" as just another term for a mixin, and appreciate that to some people, we may sound redundant when we say "class inheritance."

Method Lookup Path

Now that we've covered both class inheritance and module mixins, we can conceptualize the method lookup path. Whenever an instance method is called on an object, Ruby looks for that method definition in that object's class definition. If it doesn't find it there, it searches for it in any and all modules included in the class, from bottom up. Finally, if it doesn't find the method in the modules included in the class, it goes up the class inheritance chain and looks for it in the class's superclass.

It keeps going vertically up the class inheritance tree, then horizontally through all mixins of that class, then up again, etc, until it hits the BasicObject class, which is the last stop.

Let's look at an example. If we have an array, some_array = [3,6,9], and we then call some_array.max, Ruby will search for the definition of the max instance method first in the Array class definition, since some_array is of the Array class. Notice from the diagram that Array includes the Enumerable module, which means that's where Ruby will search next. If it didn't find it there, it would then go up to the superclass of Array, which is Object, then to Kernel, which is a module mixed in to Object, and finally up to BasicObject. Again, the superclass of BasicObject is nil, so that's always going to be the tail-end of our lookup path.

The method lookup path helps to explain the concept of overriding inherited methods. Because Ruby looks for the method in the class itself first, we can "override" a method that a class inherited from a superclass or module by explicitly defining it in the class. Ruby would therefore use that lower-level version of that method and never get to the version of the method that's defined further up the method lookup path.

In order to figure out all the modules a class includes, the class method included_modules is useful. This class method travels up the method lookup path, and returns all the modules it encounters along the way, as an array.

For example, Hash.included_modules would return an array of two elements, Enumerable and Kernel, which are the two modules that Hash objects inherit from, since Hash directly includes Enumerable, and Object includes Kernel.

Even more useful is the ancestors class method, which returns the entire method lookup path itself, also as an array. For example, calling Integer.ancestors returns: [Integer, Numeric, Comparable, Object, Kernel, BasicObject]. Note that ancestors is a class method, so we couldn't call it directly on an object. We'd have to first call the class instance method to return the object's class, and then call ancestors on that.

For example:

some_num = 4
p some_num.class.ancestors

Conclusion & putting it all together

Wow. You've made it this far--kuddos to you!

As a reward, here's a useful table to recap the three main OOP principles, and how classes and modules help us implement each one.

OOP Principle	Classes	Modules
Encapsulation	* Classes shield class variables and class methods * Each object of a class shields its own unique instance variables (i.e. state) * Method access control shields object-specific data and behavior even further by allowing us to qualify certain instance methods as private or protected	Namespacing allows modules to shield variables, constants, methods, and even classes so that they don't collide with other similarly named objects
Polymorphism	Class inheritance and duck typing	Interface inheritance
Abstraction	Instantiating objects from a class allows each object to abstract away its internal complexity through an "is-a" relationship	Including a module through a mixin abstracts away some behavior complexity through a "has-a" relationship

When should you use classes, and when should you use modules?

Here's a few guidelines to keep in mind when deciding:

If you need to create objects from the same mold, you have to use a class. Modules cannot instantiate objects.
If data type X is a more specific type of class Y, meaning that X has an "is-a" relationship with Y, then it makes sense to use a class to define X, and have it inherit from its superclass, Y
If Y and Z are unrelated classes that both need to inherit the same functionality of X, meaning Y and Z each have a "has-a" relationship with X, then it makes sense to use a module to define X, and have both Y and Z include X through a mixin.
If you want a way to compartmentalize a set of behaviors or classes, use a module.

Special thanks to the Launch School curriculum, TAs, and students who all helped me solidify these concepts.

Questions? Confused? Leave your thoughts below.

Understanding Classes in JavaScript

Vahid Dejwakh — Thu, 17 Sep 2020 12:15:44 +0000

This post originally appeared on https://vahid.blog.

Integers, floats, strings, arrays, objects, functions, loops, scope? Piece of cake. Classes? Not so easy.

Understanding what classes are, how they work, and how to incorporate them into your code is critical to developing any working enterprise application. Even more importantly, however, developing a better mental model and appreciation for classes will transform you from a mere programming hobbyist to a software craftsman demigod.

Let's get to it.

Every data structure, including all the ones listed above, is a class. Programming languages each come with your basic and fundamental class types, like numbers, strings, arrays, functions, and--for most modern languages at least--objects. Beyond these fundamental types, however, you can use classes to create your own customized data type. You can make this customized data type store whatever bits of information you need, in whatever format you want.

"Why would you I want to create a new class?" you grumble under your breath. "All I need are the fundamental data types," you explain further: "I can already store anything I could possibly want in them."

The reason, my wary but intrepid friend, is twofold: scalability and complexity.

First, there's the issue of scalability. As your application grows in size, you will have thousands, maybe billions, of variables, containing multiple data types per user, per feature, per environment (development vs testing vs production), per date, and even also per software release version.

Classes are going to serve as neat, clean, and well labeled shelves to put all your various related data into a much more organized, retrievable, and maintainable structure. Without this structure, your application might work as an MVP or prototype but would not be able to scale.
Then there's complexity. The world of data structures is so deep and profound, and you've only scratched the surface. To create linked lists, hash tables, components in React, binary search trees, and so many more interesting and complex data structures, we need classes. Without classes, we would not be able to have a working mental model of what those data structures do, nor how their instantiations (i.e. variables of a particular class) behave in the wild.

A class allows you to wrap your mind around a specific data type so that you're able to not only apply that data type to its intended use case, but to also be able to troubleshoot when an instantiation of that class is misbehaving. Think of a class as a chunk of several subchunks of data types (if that analogy didn't make sense, read this).

So, why are classes important in object oriented programming (OOP)? They bring scalability and complexity to our application.

Classes provide identity and function to data. In other words, classes allow our data to have well defined jobs. To have a functioning society, everybody needs to have a role to play--right? The better defined and specialized that role is, the more valuable each member becomes.

The same applies to our data in our application. Indeed, the fact that you need more, better, or more defined classes is usually a sign that your application is growing and becoming more competent and specialized.

Syntax Differences Between Ruby and Javascript

Vahid Dejwakh — Tue, 01 Sep 2020 21:44:42 +0000

This article originally appeared on https://vahid.blog

I've been working with Javascript for a while now, and have gotten fairly comfortable with its syntax.

I'm now also using Ruby again, which has a slightly different flavor.

Here are some of the main syntactical differences between the two languages, in table format.

1. Basics

	Javascript	Ruby
Naming convention for variables, functions, and methods	camelCase	snake_case
Naming convention for classes	PascalCase	PascalCase
Declaring variables	`let` someArray `= [`1,2`];` Although `var` was exclusively used in older codebases, `let` is now more encouraged because `let` is block scoped while `var` is function scoped and can cause unintended consequences	some_array `= [`1,2`]`
Declaring constants	`const` SOMECONSTANT `=`3.14`;` Reassigning something else to the constant will throw an error	SOME_CONSTANT `=` 3.14 Ruby will throw a warning when attempting to reassign something else to the constant, but will let you do it
Declaring global variables	Declare the variable with `let` or `const` in the global context. However, if a variable with the same name is declared in a local scope, the local variable will be usable in that scope but not the global variable	You can declare a global variable anywhere by using a `$` just in front of the variable name (e.g. `$`this_is_a_global_variable `=` 2100 )
Comments	`//`this is a single-line comment in JS `/` This is a multi-line comment in JS `/`	`#`this is a single-line comment in Ruby `=begin` This is a multi-line comment in Ruby `=end`
Print to console (automatically adding new line)	`console.log(`'hello world'`);`	`puts` 'hello world'
Print to console (without new line)	`process.stdout.write(`'hello'`);`	`print` 'hello'
Conditional Statements	`if (`someCondition`) {` `//`do this `//`and this `} else if (`someOtherCondition`) {` `//`do this instead `} else {` `//`otherwise do this `}`	`if` some_condition `#`do this `#`and this `elsif` some_other_condition `#`do this instead `else` `#`otherwise do this `end`
one-line conditional statement	`if (`condition`)` doThis`;`	do_this `if` condition
Ternary conditional expression	condition `?` doThisIfTrue `:` doThisIfFalse`;`	condition `?` do_this_if_true `:` do_this_if_false
Switch / case statement	`switch(`expression`) {` `case` x: `//` code block `break;` `case` y: // code block `break;` `default:` `//` code block `}` If you do not `break`, JS will execute every line after that case too	`case` expression `when` x `#`code block `when` y `#`code block `else` `#`code block `end`
Define a function / method	`function` someFunction`(`param1, param2`){` `//`do stuff `return` something; `}` If the `return` keyword is never used, the function will return `undefined`	`def` some_method`(`param1, param2`)` `#`do stuff `return` something `end` If the `return` keyword is never used, the method will return whatever is calculated on the last line before the `end` statement.
Keyword to refer to the current particular instantiated object	`this`	`self`
Error handling	`try {` `//` do something risky `} catch(err) {` `//` handle error here `}`	`begin` `#` do something risky `rescue` `#` handle error here `end`

2. Arrays & Strings

	Javascript	Ruby
Map / Collect method (Returning a new array of tweaked elements from an original array)	`const` newArray `=` someArray`.map(`el`=>` el * 2`)`	new_array `=` some_array`.map {
Iterate through an array's elements in one line and no need for index #	someArray.forEach(el => console.log(el));	some_array.each {
Iterate through an array's elements to perform a block requiring index #	for(let i=0; i < someArr.length; i++){ console.log(i, someArr[i]); // rest of block }	some_arr.each_index do
Delete an element at index i of an array	someArray.splice(i,length); Where i=index # to start deleting, and length = # of elements to delete	some_array.delete_at(i) To delete all elements of a particular value (e.g. 'cat') regardless of index number, use: some_array.delete('cat')
Return the unique values of an array	const uniqueArray = [...new Set(someArray)];	unique_array = some_array.uniq To mutate the original array and retain only its unique values, use: someArray.uniq!
Filter an array	const filteredArray = someArray.filter(el => el > 5); E.g. Returns all elements in someArray greater than 5	filtered_array = some_array.select {
Check if an element is in an array	someArray.includes(5); E.g. Returns true if someArray has an element with a value of 5	some_array.include?(5) E.g. Returns true if some_array has an element with a value of 5 For methods that return a boolean, a Ruby convention is to name them with a ? at the end
String Concatenation	someString = 'Hi,' + someName; If the left side of the {% raw %}`+` is a string, then JS will coerce anything that appears on the right side into a string too, even if it's a number or another data type	some_string = 'Hi,' + some_name Ruby will throw an error if you attempt to concatenate a string with a non-string. You must convert it to a string first (i.e. `.to_s`)
Convert a number to a string	`let` varString `=` someNum`.toString();`	var_string `=` some_num`.to_s`
Convert a string to an integer	`let` varNum `= Number(`someString`);`	var_num `=` some_string`.to_i`
Convert a string to a float	`let` varNum `= parseFloat(`someString`);`	var_num `=` some_string`.to_f`

3. Objects / Hashes

	Javascript	Ruby
Key-value pair data type is called	an object	a hash
object/hash creation + assignment (Literal notation)	`const` someObject `= {`key1`:` value1`,` key2`:` value2`};`	the older, symbol & hash-rocket method: some_hash `= {:`key1 `=>` value1`, :`key2 `=>` value2`}` or the newer, cleaner method: some_hash `= {`key1`:` value1`,` key2`:` value2`}`
Object/hash creation (class instantiation notation)	`const` someObject `= new Object;`	some_hash `= Hash.new`
Add key/value pair to an existing object/hash	someExistingObject[key3] `=` value3`;` or someExistingObject.key3 `=` value3`;`	some_existing_object[`:`key3] `=` value3
Iterate through an object/hash in one line	for(let key in someObject) { console.log(key,someObject[key])};	some_hash.each {
convert an object/hash to an array of sub-arrays of [key,value]	const someArray = `Object.entries(`someObject`);`	some_array = some_hash.to_a
Delete a key/value pair	`delete` someObject[someKey];	some_hash.delete(some_key)
Check if an object/hash has a key	someObject.hasOwnProperty(someKey)	some_hash.has_key?(some_key) - or - the `fetch` method allows you to get the value at the key or specify an alternative return value if the key doesn't exist: some_hash.fetch(some_key, "error message")

What's the difference between a framework and a library?

Vahid Dejwakh — Fri, 28 Aug 2020 20:15:32 +0000

This article originally appeared at https://vahid.blog.

What's a framework? What's a library? Aren't the two terms interchangeable? Is React a framework or a library? What about NodeJS? And what's Rails? Who cares, anyway? So many good questions, you have.

Answers, I shall offer you.

Let's actually answer the last question first, because it's the most important: why should you care about the difference?

Knowing the difference will help you better understand how to make sense of all the existing resources currently available for web application development, and all future resources that are sure to keep popping up.

Moreover, understanding whether each resource is a framework or a library will help you determine whether you can mix them together in the same application. For example, can you mix Angular and Express? Rails and React? Angular and React? Rails and Express?

Here's a hint: you usually cannot or should not mix two frameworks together, but you can (and usually have to) mix a framework and a library. Indeed, you usually need to combine your framework with multiple libraries, because each library does one thing well, and an application often makes use of many libraries because it needs to do many things well.

The most significant technical difference between a framework and a library is who's in control of the execution flow. With a library, you're in control: you determine when to call the library, if at all. When working in a framework, however, you write code to fill in the gaps of the framework, because the framework is in control of the execution flow. The framework calls the code that you write.

As the saying goes: you call the library -- but the framework calls you.

Both libraries and frameworks are installed the same way (e.g. as a package in Node.js, or a gem in Ruby). Both may also further be categorized as either advancing the front-end (client-side) or the back-end (server-side) of the application, or both (fullstack).

The last important distinction to make is that a framework can either be heavy or light, depending on how many restrictions and conventions it imposes on you. Using a heavy framework allows you to quickly ramp up and ship an application because the framework comes with significant pre-built scaffolding that you don't have to worry about creating from scratch. The drawback of a heavy framework is more rules and conventions you have to follow.

Using a light framework means you can customize more things, and structure them however you want, but it also requires more time and more effort. Some heavy frameworks are built on top of light frameworks--i.e., they simply add more structure on top of the original scaffolding provided by the light framework.

Here are some of the most popular frameworks and libraries, including initial release year.

Resource	Year	Language	Type	Description
Express	2010	Javascript	Light Framework	Minimalist back-end framework for web and mobile applications
React	2013	Javascript	Library	Component-based front-end library supported by Facebook
Angular	2016	Javascript	Light Framework	Component-based front-end framework supported by Google
Gatsby	2017	Javascript	Light Framework	React-based static site generator
jQuery	2006	Javascript	Library	Feature-rich library to facilitate DOM traversal
Sails	2012	Javascript	Heavy Framework	Fullstack application development following the MVC model (built on top of Express)
Rails	2004	Ruby	Heavy Framework	Fullstack application development following the MVC model
Sinatra	2007	Ruby	Light Framework	Minimalist back-end framework for web and mobile applications

That's a good list of the main frameworks for the Javascript (Node.js) and Ruby ecosystems. Note that I didn't include many libraries, but that's because there are thousands. I included React because it is commonly misunderstood as a framework, and jQuery because of its importance to the subsequent development of Javascript-based paradigms, even though this success has also caused its own demise.

A few notes:

Usually, you wouldn't mix two frameworks together. However, the exception in the list above is that you can mix Express and Angular (the "M EA N" stack)--but that's because they're both light frameworks, and they each focus on a different side of the application.
It wouldn't make sense to mix Angular and React, although one is a framework and the other is a library, because they both provide front-end rendering paradigms.
You could combine Express and React, however--and many indeed do (the "M ER N" stack).
You can mix Rails and React, since one is a heavy framework for fullstack applications, and the other is a library for front-end rendering. You wouldn't want to mix Rails and Express, however, since they both provide back-end frameworks.
Sails is just one example of a heavy framework built on top of Express. There are many more.
NodeJS is neither a framework nor a library. It's a server-side runtime environment for Javascript (i.e. running JS outside of the browser). Node is what allows and powers the JS-based back-end frameworks above.

Quiz time: could you mix Sinatra and Angular? Why/Why not? Leave a comment below.