Explaining the difference in the simplest way possible.

We IT people *LOVE* tinkering with new tech stuff, and Docker is no exception. As a matter of fact,  Docker was ranked as the #1 most wanted platform, #2 most loved platform, and #3 most broadly used platform in the [2019 Stack Overflow Developer Survey](https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted), and  #1 most wanted platform, #2 most loved platform and #3 most popular platform in [the 2020 edition of the same survey](https://insights.stackoverflow.com/survey/2020#overview).

If you've bumped into this article, chances are that you have been bamboozled by the ~~[fruit doggo](https://i.pinimg.com/originals/3d/d6/ee/3dd6ee6d8b5c9979e0cbe1d7daafada9.jpg)~~ difference between the `CMD` and `ENTRYPOINT` instructions defined in a Dockerfile, used to describe how a Docker container should be run.

### But what's a Docker container?

Containers are lightweight, standalone, executable packages of software designed for running specific tasks, no matter if short-lived or long-running. Therefore, a container's lifecycle depends on the ongoing process inside of it. 

> Once the process stops, the container stops as well.

### Ok, but what role is our Dockerfile playing here?

Containers are dependent on images and use them to construct a run-time environment in order to run an application. A Dockerfile is a script which role is to define the process which leads to the creation of a final image, and how to run a container bound to said image.

The process of creating a Docker image usually begins with a `FROM` command, defining a base image to build our image upon. We usually follow up with a bunch of `RUN` instructions, used to run commands which modify the underlying filesystem.

> Each `RUN` instruction creates a new image layer that contains a modification to the filesystem.

### Fine. Now what about the CMD vs ENTRYPOINT stuff?

`CMD` and `ENTRYPOINT` are two different types of instructions used to define how a Docker container should be run. 
Let's dive into the details of each one:

### CMD

A `CMD` instruction defines the default command used to run a Docker container from an image.

Given a simple image like the following:

```docker
FROM alpine
CMD ["echo", "Hello, World!"]
```

Running it with:

```docker
docker container run my-container
```

Will yield the following result:

```docker
Hello, World!
```

> A Dockerfile can contain multiple `CMD` instructions, but every single one of them, except for the last one, will be ignored.


A `CMD` instruction can be overridden by the arguments passed to `docker container run`, like:

```docker
docker container run my-container echo "Hello again!"
```

Will yield:

```docker
Hello again!
```

### ENTRYPOINT

`ENTRYPOINT` instructions define, just like their CMD siblings, the default command used to start a container.

```docker
FROM alpine
ENTRYPOINT ["echo", "Hello, World!"]
```

Will yield:

```docker
Hello, World!
```

### Cool, so... what's the difference at this point?

Well, the main difference is that, if both a `CMD` and `ENTRYPOINT` instructions are defined inside a Dockerfile, the `CMD` instruction will be concatenated to the `ENTRYPOINT` one:

```docker
FROM alpine
ENTRYPOINT ["echo"]
CMD ["Hello, World!"]
```

Wil lead to us seeing:

```docker
Hello, World!
```

Also, while `CMD` instructions are, by design, made do be easily overridden by passing arguments to `docker container run` commands, `ENTRYPOINT` have purposely been made harder to override manually, by forcing user to use a `--entrypoint` flag.

### This leads us to a pattern

This design leads us to a consistent pattern. And we like patterns, patterns are good for our mental health:

We can use `ENTRYPOINT` to define a base command which always gets executed, and `CMD` to  define default arguments for this command, easily overridable by passing custom args to `docker container run`.

Docker CMD vs ENTRYPOINT: explaining the difference

Listing all the possible values in Typescript ain't as easy as it seems!

Today I have spent quite a few hours trying to contribute a P.R. to a project I really like, and often use in my day-to-day work, the excellent [`class-validator`](https://github.com/typestack/class-validator).
The problem I was trying to solve consisted in listing the possible values for a given enum, in order to let `class-validator` print them in its enum-related error messages.

> The main problem is that enums get transpiled differently, based on their contents and the way they're declared.

When values are not specified, an incremental integer is assigned to each key, so the transpiled JS looks like the following:
```js
// Before
enum Steak {
    Medium,
    Rare,
    WellDone
}

// After
var Steak;
(function (Steak) {
    Steak[Steak["Medium"] = 0] = "Medium";
    Steak[Steak["Rare"] = 1] = "Rare";
    Steak[Steak["WellDone"] = 2] = "WellDone";
})(Steak || (Steak = {}));
```

When an inteer number is assigned as the value, it is simply assigned instead of the deafult incremental integer in the example before.

When a string value is assigned, though, the transpiled JS code looks a bit different:
```js
// Before
enum Steak {
    Medium = "MEDIUM",
    Rare = "RARE",
    WellDone "WELL_DONE"
}

// After
var Steak;
(function (Steak) {
    Steak["Medium"] = "MEDIUM";
    Steak["Rare"] = "RARE";
    Steak["WellDone"] = "WELL_DONE";
})(Steak || (Steak = {}));
```

These transpilation differences lead to obvious inconsistencies when attempting to retrieve an `enum`'s list of possible values when using the common `Object.values()`, `Object.keys()` and `Object.entries()` methods. By fiddling with an heterogeneous `enum` like the following:
```js
enum TestEnum {
	a = 'aA',
	b = 'bB',
	c = 1,
	d = 2,
	e = '01'	
}
```


The following conclusions can be drawn:
* `Object.values()` returns an array containing all the possible values for the given enum AND the keys for the properties which have integer numbers as values (`[ 'c', 'd', 'aA', 'bB', 1, 2, '01' ]`)
* `Object.keys()` returns an array containing all the enum's keys plus all of the integer values defined (`[ '1', '2', 'a', 'b', 'c', 'd', 'e' ]`) 
* `Object.entries()` returns an array of [key, value] arrays, plus N [value, key] entries for N of the enum's properties which have integer numbers as values (`[ [ '1', 'c' ],
     [ '2', 'd' ],
     [ 'a', 'aA' ],
     [ 'b', 'bB' ],
     [ 'c', 1 ],
     [ 'd', 2 ],
     [ 'e', '01' ] ]`)  

  
So, finally, the solution I came up with is:
```js
Object.entries(TestEnum).filter(entry => !parseInt(entry[0])).map(entry => entry[1])
```

Which starts from `Object.keys()`'s results, filtering out all the redundant [value, key] entries.

Listing all the possible values for an enum in Typescript

A nice and clean setup to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..

In this post I'm gonna quickly go over a nice and clean setup I use to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..


### PREPARATION

As a first step, we want to make sure that **all** of our accounts use SSH keys to authenticate connections between our machines and the cloud providers. Nowadays the process doesn't require much fiddling, and can be simply done using our providers' web UIs. I won't go over this part because the specific way to set this up would be vendor-specific, and I don't consider this step to be complicated enough to require any explanation.
\
Let's suppose that at this point we own two different GitLab accounts, each bound to a dedicated SSH key stored on our machine:
```sh
user: first
email: first@myemail.com
private key: ~/.ssh/first/id_rsa
public key: ~/.ssh/first/id_rsa.pub
repository name: first-project

user: second
email: second@myemail.com
private key: ~/.ssh/second/id_rsa
public key: ~/.ssh/second/id_rsa.pub
repository name: second-project
```

### Configuring SSH
If not present, a SSH configuration file needs to be created:
```sh
cd ~/.ssh/
touch config
```

We are going to use said file to tell our machine to use different credentials depending on the host we're trying to connect it to. 

This could lead us to a question: 
> We just assumed both our accounts are gitlab.com accounts. How do we use different credentials if the host is the same?

The answer is straightforward:
ssh can be configured by using host alias names, which will basically allow us to treat the same underlying hostname as two different hosts, while still resolving the correct hostname. 
Let's see how to take advantage of this feature
```sh
# Gitlab.com - "first" account
Host gitlab.com_first   # <-- this could be any alias     
HostName gitlab.com     
User git    
Preferredauthentications publickey    
IdentitiesOnly yes    
IdentityFile ~/.ssh/first/id_rsa

# Gitlab.com - "second" account
Host gitlab.com_second  # <-- this could be any alias     
HostName gitlab.com    
User git    
Preferredauthentications publickey    
IdentitiesOnly yes    IdentityFile ~/.ssh/second/id_rsa
```

### Configuring Git
Our job is pretty simple now: we need to let git use our alias hostnames in order to provide the correct SSH credentials when trying to authenticate  (using only our "first" account for brevity):
```sh
# If the remote repo is still not cloned locally
# we just need to provide our alias hostname
# when cloning
git clone git@gitlab.com_first:first/first-project.git

# If the remote repo is already cloned locally
# we need to update the remote's hostname. Here# we're assuming "origin" its name.git remote remove origin
git remote add origin 
git@gitlab.com_first:first/first-project.git
```

----

## DONE
We're done with our configuration, now the correct credentials will be used when connecting to each remote.

Handling multiple Git credentials the easy way

A simple guide to get up and running with the NextJS + TypeScript + TailwindCSS + Storybook combination.

Following is a simple guide to get up and running with the NextJS + TypeScript + TailwindCSS + Storybook combination, a task which took me a lot more time than I originally estimated, due to the unexpected lack of specific guides on how to deal with this particular scenario plus the sparse nature of the information I had to look up to set everything up as desired.

### NEXTJS SETUP

`yarn create next-app`

That's it. Done. A fully-functional NextJS app will be created using the official starter kit.

---
### TAILWINDCSS SETUP

1. `yarn add -D tailwindcss postcss-preset-env` to install the TailwindCSS library and some useful PostCSS polyfills
2. `npx tailwind init` to generate a `tailwind.config.js` file.
3. Edit the TailwindCSS configuration file we just created to enable and configure the built-in CSS purging process. (Notice how I'm using the ".tsx'" extension here, since I already know I'm going to use TypeScript for this project)
```js
module.exports = {
  purge: ['./components/**/*.tsx', './pages/**/*.tsx'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}
```
4. Create `postcss.config.js` to configure PostCSS in a minimal way, like the following
```js
module.exports = {
  plugins: [
    "tailwindcss", 
    "postcss-preset-env"
  ]
};
```
5. Create `/styles/index.css` and populate it using the `postcss-import`-friendly `@import` directives (instead of using `@tailwind`)
```css
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";
```
---
### TYPESCRIPT SETUP

1. `yarn add --dev typescript @types/react @types/node`
2. `touch tsconfig.json`
3. `yarn next` to start NextJS, which will automagically recognize our newly created `tsconfig.json` and inject a valid configuration json into it
4. Create a `/pages/_app.tsx` file
```jsx
import React from "react";
import "../styles/index.css"; // <- applied everywhere in the NextJS application scope

const MyApp = ({ Component, pageProps }) => {
  return <Component {...pageProps} />;
};

export default MyApp;
```
---
### STORYBOOK SETUP

1. `yarn add @storybook/react babel-loader @babel/core awesome-typescript-loader react-docgen-typescript-loader -D`
2. `mkdir .storybook`
3. `cp ./tsconfig.json ./.storybook/`
4. Edit `/.storybook/tsconfig.json` to suit your Storybook-TypeScript integration
```json
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "react"            // <- important!
  },
  "exclude": ["node_modules"],
  "include": [                // <- important!
    "../types.d.ts",
      "../next-env.d.ts",
      "../**/*.stories.ts",
      "../**/*.stories.tsx"
    ]
  }
```

6. Create `/.storybook/main.js` and feel free to copy the following configuration
```js
const path = require("path");

module.exports = {
  stories: ["../components/**/**/*.stories.tsx"],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      use: [
        {
          loader: require.resolve("awesome-typescript-loader"),
          options: {
            configFileName: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
        /* 
          ** OPTIONAL ** 
    						 
          Basically a webpack loader  used to 				 
          generate docgen information from TypeScript React components. 
The primary use case is to get the prop types 
table populated in the Storybook Info Addon.
    	*/
    	{
          loader: require.resolve("react-docgen-typescript-loader"),
          options: {
            tsconfigPath: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
      ],
    });

    config.resolve.extensions.push(".ts", ".tsx");

    return config;
  },
};
```

7. create `/.storybook/preview.js` and use it to import our stylesheet as follows
```js
// The preview application is essentially just your stories with 
// a framework-agnostic 'router'. 
// It renders whichever story the manager application tells it to render.
// In this case we just use it to import the stylesheet and inject it 
// in the context of our stories

import "../styles/index.css";
```

8. Update `postcss.config.js` to use an object-based format. This is super important in order to solve any issues Storybook's webpack process may encounter while resolving the dependencies!
```js
module.exports = {
  plugins: {
    tailwindcss: {}, 
    "postcss-preset-env": {}
  }
};
```
---
# DONE

Now you will be able to create your component stories in your own component's folders (ex.: `/components/button/1-button.stories.tsx`) using this powerful toolset.


> P.S.: If you wish to organize your Storybook stories using a different folder structure, you'll need to do no more than editing the `stories` property inside the exported configuration in `/.storybook/main.js` using your desired glob patterns 