DEV Community: oleg-melnic

What a perfect technical director suggests on career development

oleg-melnic — Wed, 08 Feb 2023 19:53:06 +0000

Last week, I had a conversation with a technical director. We were discussing the general stuff about software engineering. This guy really knows how all this work because is a very clever director with great leadership skill. So I decided it would be useful for you to learn some insights from him as well.

Even senior specialists cannot avoid imposter syndrome

During this conversation, I decided to complain that sometimes I’m not confident about my engineering knowledge and think that everyone around me knows something better than me. He also recollected a situation of failing a coding interview and getting anxious about this. Actually, there’s nothing strange in it because hesitation and anxiety can be quite powerful motivation boosters. Even though I have been working in my company for many years, I still cannot avoid comparing myself with others. He explained that this is normal, even if you have many experiences in the industry. You shouldn’t think that the company that hired you expects you to show the highest-quality performance on the very first day. This is because companies understand that specialists need some time to get used to a new working environment. You shouldn’t be afraid of consulting with people, instead, it’s better to show your complete commitment to learning something new in a new company.
The fact that the senior engineer can digest a piece of code more precisely than the junior, doesn’t mean that this specialist doesn’t use additional tools. When creating a code, seniors also google some basic things, such as the implementation of a hash map in JavaScript. Nevertheless, thanks to the big experience in engineering, a senior can spot the crucial piece regarding the root cause by just taking a look at a block of code. This skill can be gained through experience, so the desire to learn and grow is one of the best methods to deal with imposter syndrome, even if you already have a lot of knowledge to perform stably.

Don’t think that soft skills are useless on your way to promotion to senior

One more thing I understood during this conversation is that technical skills aren’t the only features that determine whether you will be promoted to senior. You need to be able to establish efficient cooperation with other team members. This is what differentiates juniors from seniors. Senior specialists have more advanced soft skills that help them to solve different issues more quickly.
Considering this, I realized that engineering managers pay a lot of attention to the personal well-being of specialists. Indeed, he explained to me that if an engineer is in a good mental condition, he can unlock new skills and knowledge faster, which helps to grow professionally and boost performance efficiency. That technical director suggested that engineering managers shouldn’t be too formal when communicating with engineers because casual communication helps to understand whether there are some issues that bother the performance of a specialist. Besides, an engineer will feel a friendly attitude and will understand that he can work without any pressure.

To get promoted to a technical director, help specialists under you get promoted

One more interesting insight he shared with me is that a good technical director should care not only about their own personal well-being. It’s necessary to make sure that the things you do can positively impact your team or even the entire company. It’s better to avoid things that are too complicated and have a small impact on the company's performance. This is a basic rule of time management for productive technical directors.
You also need to understand that the more good things your team does for a company, the more chances you have to get promoted. That’s why as a manager, you should pay attention to the professional and personal growth of people under you. If they show great performance and get promoted, you will move a level higher together with them. Actually, this is a way how you can grow to the position of a technical director from a position of a project manager.

Focus on learning best practices on code structure, and writing tests

I was also wondering about the most important things at this stage of my career. The technical director suggested that I should sharpen my current skills. This means that I don’t need to spend my time learning new programming languages unless I totally master the skill of code writing and composing its structure. One more thing he shared is that I should always pay attention to unit testing. These are the most important skills to develop at the current stage of my career.

Don’t be afraid of working really hard

Some specialists give up the idea of working for a certain company if they think that it cannot provide a “work-life balance”. Frankly speaking, “work-life balance” isn’t the thing you should be looking for in your 20s. You are a healthy young man who can endure such difficulties, especially, if there are great career prospects. Foremost, you should pay attention to the thing that you can gain from this company. Even though you can feel sometimes that you are missing out on your routine life, this is the way to acquire a great reputation in a company and master new technical and soft skills. If it’s too hard, you can always give up, but it would be silly not to try working without considering “work-life balance”.

Final thought

To summarize, he suggested that software engineering is the same as vehicle engineering. I took some time to reconsider what he meant and now I can say that I fully agree with it. Similar to a vehicle engineer, you should focus more on a well-defined structure and the process itself rather than different changeable components. Software engineering is all about working on the process and trying new methods. Keep this in mind and you’ll be able to focus on what is really important!

What is CRUD?

oleg-melnic — Sun, 04 Apr 2021 16:23:06 +0000

Create, Read, Update, and Delete (CRUD) are the four basic methods for a good functional model.

Create, Read, Update, Delete

When we create an API, we should provide four basic types of functionality to our model. The model should have the ability to create, read, update and remove resources. Program developers usually refer to these methods as the acronym CRUD. The model must be able to perform a maximum of these four functions in order to be complete. If an action cannot be described in any of these four operations, it should potentially be its own model.

The CRUD methods are common when building web applications because it provides a memorable basis for reminding developers how to build complete, usable models. For example, let’s imagine a system for tracking library books. In this hypothetical library, a database would be a books resource in which book objects would be stored. Let’s suppose this book object looks like this:

“book”: {
  "id": <Integer>,
  “title”: <String>,
  “author”: <String>
}

To make this library system usable, we should be sure that there were clear mechanisms for completing the CRUD operations:
Create - is the method we use to add a new library book to the catalogue. The program that invokes the function would give values for title and author. When this function is called, a new entry corresponding to this new book should appear in the books resource. In addition, a new entry is assigned a unique id that can be used to access the resource later.
Read - is the method that we use to view all books in the catalogue. This function call would not change the books in the directory - it would simply get the resource and display the results. We would also have a function to extract a separate book for which we could supply the title, author or ISBN. One more time, this book will not be altered, only found.
Update — is the method we use to change information about a book. The program calling the function would supply the new values for title and author. After the function call, the corresponding entry in the books resource would contain the new fields supplied.
Delete — is the method we use to remove a library book from the catalogue. The program calling the function would supply one or more values (title and/or author) to identify the book, and then this book would be removed from the books resource. After this function is called, the books resource should contain all of the books it had before, except for the one just deleted.

CRUD and REST

In the REST environment, CRUD often corresponds to the HTTP methods POST, GET, PUT and DELETE respectively. These are the four basic elements of a persistent storage system.
In the remainder of the article, we will recommend the response standards and codes that developers usually follow when creating RESTful applications. Conventions may differ, so feel free to experiment with different return values and codes as you become comfortable with the CRUD conception.
Imagine that we’re working with a system that tracks dishes and the relevant prices for the restaurant. Let’s see how we should implement CRUD operations.

Create

We commonly use the HTTP POST method to create resources in the REST environment. POST creates a new resource of the specified type.
For example, imagine that we add a new product to the stored list of dishes for this restaurant, and the dish objects are stored in the dishes resource. If we wanted to create a new element, we would use the POST request:
Request:

POST http://www.best-restaurant.my/dishes/

Body -

{
  "dish": {
    "name": “Meat Toast”,
    "price": 12
  }
}

This creates a new item with a name value of “Meat Toast” and a price value of 12. After successful creation, the server should return a header with a link to the newly-created resource, along with an HTTP response code of 201 (CREATED).
Response:
Status Code - 201 (CREATED)
Body -

{
  "dish": {
    "id": 1463,
    "name": “Meat Toast”,
    "price": 12
  }
}

From this response, we can see that the dish with the name “Meat Toast” and price 8 has been successfully created and added to the dishes resource.

Read

We use the GET method to read resources in the REST environment. Reading a resource should never change any information - it should only retrieve it. If you call GET for the same information 10 times in a row, you must receive the same response to the first call as the last one.
GET can be used to read an entire list of items:
Request:

GET http://www.best-restaurant.my/dishes/

Response: Status Code - 200 (OK)
Body -

{
  "dishes": [
    {
      "id": 1,
      "name": “Some Rolls”,
      "price": 4
    },
    {
      "id": 2,
      "name": “Mozzarella”,
      "price": 8
    },
    ...
    {
      "id": 1463,
      "name": “Meat Toast”,
      "price": 12
    },
    {
      "id": 1584,
      "name": “Muesli”,
      "price": 3
    }
  ]
}

GET requests can also be used to read a specific item when its id is specified in the request:
Request:

GET http://www.best-restaurant.my/dishes/1463

Response: Status Code - 200 (OK) Body -

{
  "id": 1463,
  "name": “Meat Toast”,
  "price": 12
}

After this request, no information has been changed in the database. The item with id 1463 has been retrieved from the dishes resource, and not modified. When there are no errors, GET will return the HTML or JSON of the desired resource, along with a 200 (OK) response code. If there is an error, it most often will return a 404 (NOT FOUND) response code.

Update

PUT is the HTTP method used to update information in the system.
For example, if the price of Avocado Toast has been raised, we should go into the database and update that information. We can do this with a PUT request.
Request:

PUT http://www.best-restaurant.my/dishes/1463

Body -

{
  "dish": {
    "name": “Meat Toast”,
    "price": 10
  }
}

This request should change the item with id 1463 to have the attributes supplied in the request body. This dish with id 1463 should now still have the name “Avocado Toast”, but the price value should now be 10, as it used to be 12.
Response: Status Code - 200 (OK) Body - not necessary
The response includes a Status Code of 200 (OK) to signify that the operation was successful, but it need not return a response body.

Delete

The CRUD operation Delete corresponds to the HTTP method DELETE. It is used to remove a resource from the system.
Let’s say that the world avocado deficit has reached a critical point, and we can no longer afford to serve this modern delicacy at all. We should go into the database and delete the item that corresponds to “Avocado Toast”, which we know has an id of 1463.
Request:

DELETE http://www.best-restaurant.my/dishes/1463

After the successful operation, we receive a response code of 204 (NO CONTENT) with no response body. The dishes resource should no longer contain the dish object with id 1463.

Response: Status Code - 204 (NO CONTENT) Body - None

Calling GET on the dishes resource after this DELETE call would return the original list of dishes with the {"id": 1463, "name": “Meat Toast”, "price": 10} entry removed. All other dish objects in the dishes resource should remain unchanged. If we tried to call a GET on the item with id 1463, which we just deleted, we would receive a 404 (NOT FOUND) response code and the state of the system should remain unchanged.
Calling DELETE on a resource that does not exist should not change the state of the system. The call should return a 404 response code (NOT FOUND) and do nothing.

CRUD Practice

Create, Read, Update, and Delete methods are fundamental components of a usable storage model. You have already seen above a couple of examples of how the CRUD concept can help us to design systems. Now, try using CRUD to list out routes for a new example model. Imagine that we are creating a system that tracks workout classes, including the name of each class, who teaches it, and the duration of the class. An example class object would look like this:

{
  "class": {
    "id": 1    
    "name": “Hard Work”,
    “trainer”: “Bob Smeet”,
    "duration": 2.25
   }
}

All of the classes are stored in a classes resource at www.force-academy.com/classes.
For each CRUD operation, write out answers to the following questions:
• What routes would you need to implement to provide your workout class model with this CRUD functionality and what are their corresponding HTTP methods?
• What effect would each route have on the database?
• What response body would each route return?
• What response code would each route return?

CRUD Practice Answers

1) Create
Route: POST /classes
Effect on Database: Adds the class provided in the request body to the database
Response Body: { "class": The Newly-Created Class }
Success Response Code: 201
2) Read (All Classes)
Route: GET /classes
Effect on Database: None
Response Body: { "classes": [ Array of All Saved Classess ] }
Success Response Code: 200
3) Read (One Class)
Route: GET /classes/:id
Effect on Database: None
Response Body: { "class": The class with the specified ID }
Success Response Code: 200
4) Update
Route: PUT /classes/:id
Effect on Database: Updates the class with the specified ID to have the class information provided in the request body
Response Body: { "class": The updated class now saved in the database }
Success Response Code: 200
5) Delete
Route: DELETE /classes/:id
Effect on Database: Removes the class with the specified ID from the database
Response Body: None
Success Response Code: 204
As you get more practice with designing storage systems, incorporating CRUD operations into your models will become easier and easier.

What is REST?

oleg-melnic — Tue, 16 Feb 2021 20:49:43 +0000

REpresentational State Transfer

REST is the acronym for REpresentational State Transfer. It is an architectural style for providing better and easier communication between computer systems on the web. REST-compliant systems, also called RESTful systems, are stateless and act as an intermediary between client and server. We'll take a look at what these terms mean and why they are useful features for online services.

Client-Server architecture

In the REST architectural style, the client implementation and the server implementation can be performed independently of each other. This means that the client-side code can be changed at any time without affecting the server's operation, and the server-side code can be changed without affecting the client’s operation.
Messages can be stored modularly and separately, as long as each side knows what message format to send to the other side. By separating user interface tasks from the data storage tasks, we increase the flexibility of the interface between platforms and improve scalability by simplifying server components. Moreover, separation allows each component to evolve independently.
By using the REST interface, different clients end up at the same REST endpoints, perform the same actions, and receive the same responses.

Statelessness

Systems that are based on REST architecture are stateless, which means the server doesn't need to know about the client's state and vice versa. Thus, both the server and the client can understand any message received without seeing the previous messages. This statelessness is ensured by using resources rather than commands. Resources are the Web nouns - they describe any objects, documents or things that may be needed to store or send to other services. Because REST systems interact through standard resource operations, they are independent of interface implementation.
These constraints help Restful applications achieve reliability, fast performance, and extensibility as components that can be managed, updated, and reused without affecting the entire system, even while the system is running.
Now, we’ll explore how the communication between the client and server actually happens when we are implementing a RESTful interface.

Communication between Client and Server

In REST architecture, clients send requests to find or modify resources, and servers send responses to those requests. Let's take a look at the standard ways of sending requests and responses.

Making Requests

REST requires the client to make a request to the server in order to get or change data on the server. The request usually consists of:
• an HTTP method that determines the type of operation
• a header, which allows the client to pass along information about the request
• a path to a resource
• an optional message body containing data

HTTP methods

There are 4 basic HTTP methods we use in requests to interact with resources in a RESTful system:
• GET — retrieve a specific resource (by id) or a collection of resources
• POST — create a new resource
• PUT — update a specific resource (by id)
• DELETE — remove a specific resource by id

Headers and Accept parameters

In the header of the request, the client sends the type of content that it is able to receive from the server. This field is called Accept, and it ensures that the server does not send data that cannot be understood or processed by the client. Content-type parameters are MIME types (or Multipurpose Internet Mail Extensions, which you can read more about in the MDN Web Docs).
MIME Types, used to specify the content types in the Accept field, consist of a type and a subtype. They are separated by a slash (/).
For example, a text file containing HTML would be specified with the type text/html. If this text file contained CSS instead, it would be specified as text/css. The general text file will be referred to as text/plain. However, this default value, text/plain, is not universal. If a client is expecting text/css and receives text/plain, it will not be able to recognize the content.
Other types and commonly used subtypes:
• image — image/png, image/jpeg, image/gif
• audio — audio/wav, audio/mpeg
• video — video/mp4, video/ogg
• application — application/json, application/pdf, application/xml, application/octet-stream
For example, a client accessing a resource with id 23 in an articles resource on a server might send a GET request like this:

GET /articles/23
Accept: text/html, application/xhtml

The Accept header field, in this case, is saying that the client will accept the content in text/html or application/xhtml.

Paths

Requests must contain a path to a resource that the operation should be performed on. In RESTful APIs, paths should be designed to help the client know what is going on.
Usually, the first part of the path should be the plural form of the resource. This allows easy reading and understanding of nested paths.
A path like blabla.ccc/customers/223/orders/12 is clear in what it points to, even if you’ve never seen this specific path before because it is hierarchical and descriptive. We can see that we are accessing the order with id 12 for the customer with id 223.
Paths should contain the information necessary to locate a resource with the degree of specificity needed. When referring to a list or collection of resources, it is not always necessary to add an id. For example, a POST request to the blabla.ccc/customers path would not need an extra identifier, as the server will generate an id for the new object.
If we are trying to access a single resource, we would need to add an id to the path. For example: GET blabla.ccc/customers/:id — retrieves the item in the customers resource with the id specified. DELETE blabla.ccc/customers/:id — deletes the item in the customers resource with the id specified.

Sending Responses

Content Types

In cases where the server is sending a data payload to the client, the server must include a content-type in the header of the response. This content-type header field alerts the client to the type of data it is sending in the response body. These content types are MIME Types, just as they are in the accept field of the request header. The content-type that the server sends back in the response should be one of the options that the client specified in the accept field of the request.
For example, when a client is accessing a resource with id 23 in an articles resource with this GET Request:

GET /articles/23 HTTP/1.1
Accept: text/html, application/xhtml

The server might send back the content with the response header:

HTTP/1.1 200 (OK)
Content-Type: text/html

This would signify that the content requested is being returned in the response body with a content-type of text/html, which the client said it would be able to accept.

Response Codes

Responses from the server contain status codes to alert the client to information about the success of the operation. As a developer, you do not need to know every status code (there are many of them), but you should know the most common ones and how they are used:

Status code	Meaning
200 (OK)	This is the standard response for successful HTTP requests.
201 (CREATED)	This is the standard response for an HTTP request that resulted in an item being successfully created.
204 (NO CONTENT)	This is the standard response for successful HTTP requests, where nothing is being returned in the response body.
400 (BAD REQUEST)	The request cannot be processed because of bad request syntax, excessive size, or another client error.
403 (FORBIDDEN)	The client does not have permission to access this resource.
404 (NOT FOUND)	The resource could not be found at this time. It is possible it was deleted, or does not exist yet.
500 (INTERNAL SERVER ERROR)	The generic answer for an unexpected failure if there is no more specific information available.

For each HTTP verb, there are expected status codes a server should return upon success:
• GET — return 200 (OK)
• POST — return 201 (CREATED)
• PUT — return 200 (OK)
• DELETE — return 204 (NO CONTENT) If the operation fails, return the most specific status code possible corresponding to the problem that was encountered.

Examples of Requests and Responses

Let’s suppose we have an application that allows you to view, create, edit, and delete customers and orders for a small clothing store hosted at blabla.ccc. We could create an HTTP API that allows a client to perform the following functions:
If we wanted to view all customers, the request would look like this:

GET http://fashionboutique.com/customers
Accept: application/json

A possible response header would look like:

Status Code: 200 (OK)
Content-type: application/json

followed by the customers data requested in application/json format.
Create a new customer by posting the data:

POST http://blabla.ccc/customers
Body:
{
  “customer”: {
    “name” = “Vasea Pupkin”,
    “email” = “vasea.pepkin@exemple.ccc”
  }
}

The server then generates an id for that object and returns it back to the client, with a header like:

201 (CREATED)
Content-type: application/json

To view a single customer we GET it by specifying that customer’s id:

GET http://fashionboutique.com/customers/123
Accept: application/json

A possible response header would look like:

Status Code: 200 (OK)
Content-type: application/json

followed by the data for the customer resource with id 23 in application/json format.
We can update that customer by PUT ting the new data:

PUT http://blabla.ccc/customers/123
Body:
{
  “customer”: {
    “name” = “Vasea Pupkin”,
    “email” = “vaseapupkin1@exemple.ccc”
  }
}

A possible response header would have Status Code: 200 (OK), to notify the client that the item with id 123 has been modified.
We can also DELETE that customer by specifying its id:

DELETE http://blabla.ccc/customers/123

The response would have a header containing Status Code: 204 (NO CONTENT), notifying the client that the item with id 123 has been deleted, and nothing in the body.

Practice with REST

Let’s imagine we are building a photo-collection site. We want to make an API to keep track of users, venues, and photos of those venues. This site has an index.html and a style.css. Each user has a username and a password. Each photo has a venue and an owner (i.e. the user who took the picture). Each venue has a name and street address. Can you design a REST system that would accommodate:
• storing users, photos, and venues
• accessing venues and accessing certain photos of a certain venue
Start by writing out:
• what kinds of requests we would want to make
• what responses the server should return
• what the content-type of each response should be

Possible Solution - Models

{
  “user”: {
    "id": <Integer>,
    “username”: <String>,
    “password”:  <String>
  }
}

{
  “photo”: {
    "id": <Integer>,
    “venue_id”: <Integer>,
    “author_id”: <Integer>
  }
}

{
  “venue”: {
    "id": <Integer>,
    “name”: <String>,
    “address”: <String>
  }
}

Possible Solution - Requests/Responses

GET Requests

Request- GET /index.html Accept: text/html Response- 200 (OK) Content-type: text/html
Request- GET /style.css Accept: text/css Response- 200 (OK) Content-type: text/css
Request- GET /venues Accept:application/json Response- 200 (OK) Content-type: application/json
Request- GET /venues/:id Accept: application/json Response- 200 (OK) Content-type: application/json
Request- GET /venues/:id/photos/:id Accept: application/json Response- 200 (OK) Content-type: image/png

POST Requests

Request- POST /users Response- 201 (CREATED) Content-type: application/json
Request- POST /venues Response- 201 (CREATED) Content-type: application/json
Request- POST /venues/:id/photos Response- 201 (CREATED) Content-type: application/json

PUT Requests

Request- PUT /users/:id Response- 200 (OK)
Request- PUT /venues/:id Response- 200 (OK)
Request- PUT /venues/:id/photos/:id Response- 200 (OK)

DELETE Requests

Request- DELETE /venues/:id Response- 204 (NO CONTENT)
Request- DELETE /venues/:id/photos/:id Response- 204 (NO CONTENT)

Strategy Pattern

oleg-melnic — Mon, 28 Dec 2020 14:22:57 +0000

The first step in learning this pattern is defining a problem and solving it by using a strategy pattern. Imagine that we are developing a game “Street Fighter”. For convenience, let’s suppose that a character has four different moves. They are - kick, punch, roll and jump. For each character kick and punch moves are compulsory, but roll and jump are additional. How should your classes be modeled? Considering that you use inheritance and abstract out the common features in a Fighter class and let other characters subclass Fighter class.

Fighter class will have default implementation of regular actions. Any character with a specific move can override that action in its subclass. You can see this on Class diagram below:

Which problems does the above design have?

For example, character doesn’t perform jump move. It still inherits the jump behavior from the main class. In that event you can simply override jump, but you may have to do such operations for all existing classes and furthermore, keep in your mind that future classes should be worried about that too. So inheritance is not the appropriate principle here.

What about an Interface?

Look at the design below:

It’s pretty well-ordered. Actions, which some characters might not perform, were removed out of Fighterclass and interfaces were created for them instead. It means that only characters that are supposed to jump will implement the JumpBehavior.

Which problems does the above design have?
Code reuse is the main problem with this kind of design. We may duplicate code, because there is no default implementation of jump and roll behavior. In that way we may need to rewrite the same jump behavior again and again in many subclasses.
How to avoid this?
At first sight, the most efficient way is to use multiple inheritance and create JumpBehavior and RollBehavior classes instead of interface. But due to the fact, that multiple inheritance is not supported in many languages and has too many problems with it, we cannot use it.
Here strategy pattern comes to help us. We need to learn what the strategy pattern is and then apply it to solve our problem.

Definition:

Wikipedia defines strategy pattern as:

“In computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern that enables an algorithm’s behavior to be selected at runtime. The strategy pattern:

· defines a family of algorithms,
· encapsulates each algorithm,
· makes the algorithms interchangeable within that family.”

Class scheme:

Instead of inheritance for reuse we focus on composition here. Context is made up of a Strategy. The Context delegates a behavior to Strategy instead of implementing it. The context class will require the behavior change, which can be dynamic. So we can change behavior without affecting our context, because Strategy is implemented as an interface.
To have a deeper understanding of strategy pattern we should use it in practice to solve our problem.

Advantages:

We can define a family of algorithms as a class hierarchy, which is interchangeable to alter application behavior and can use it without modifying its architecture.
We can easily introduce new algorithms complying with the same interface by encapsulating the algorithm individually.
Strategies can be switched at run-time.
We have an opportunity to choose the required algorithm, without using a “switch” statement or a series of “if-else” statements.
We can change the implementation of an algorithm without affecting the Context class because Data structures used for implementing the algorithm are completely encapsulated in Strategy classes.

Disadvantages:

The right strategy for the right situation could be selected only if the application includes all the strategies.
Normally, communication between Context and the Strategy classes is carried out through the interface established by the abstract Strategy base class. Some concrete Strategy classes might not implement all the required behaviors, although Strategy base class must provide interface for them.
The Context can be configured with the required Strategy object in most cases. Therefore, two objects instead of one need to be built and supported.

Then we will apply the strategy pattern to the problems with fighter and talk about the implementation.

The main thing is the identification of behaviors that may differ from class to class after time and then their separation from the others. For example, let that behaviors be kicks and jumps. For their separation, we will extract both methods from the Fighter class and design a new set of classes to show each behavior.

Now, kick and jump behavior will be delegated to the Fighter class, instead of using the kick and jump methods defined in the Fighter class or its subclass.

After this modification, the final class diagram will look like (Click the image for a better view):

In comparison with the definition of a strategy pattern and our design, encapsulated kick and jump behaviors are two families of algorithms. And these algorithms can be replaced with each other, as can be seen from the implementation.