Performance differences between Node.js on Alpine and Debian

A few days ago, I was working on a project that required me to use Node.js. I
was helping a colleague set up the Docker container used to run the project,
and we had to choose between using the Alpine or Debian image for my Docker
container. I was heavily against using Alpine, and had to explain why to my
colleague. I decided to do write this article to share my stance and explain the
rationale behind it, and as an exercise in collecting detailed proof of my POV
on the matter.

## What is Alpine?

If you don't know what Alpine is, don't talk to me. Alpine Linux is a lightweight Linux distribution that is designed with security
and simplicity in mind. It is known for its small size and minimalistic design,
making it a popular choice for containerized applications. Alpine Linux uses
`musl` as its standard C library, which is known for its small size and
performance optimizations.

## What is Debian?

If you don't know what Debian is, consider a career in carpentry. However, for the sake of
completeness: Debian is a popular Linux distribution that is known for its
stability and large package repository. It is widely used in production
environments and is a popular choice for server deployments. C code compiled on
Debian systems is compiled against `glibc`, the GNU C library, which is known
for its feature-richness and compatibility with a wide range of software.

## Who cares about the standard C library used in a Docker container?

You might've read the previous sections and thought, "Who cares about the
standard C library used in a Docker container? I'm not a kernel developer, I'm
just trying to run my Node.js application." And you'd be right. For most
applications, the choice of standard C library doesn't matter. However, if you
know me at all, you know that I care about the nitty-gritty low-level details
of software development. And I won't let my application run on anything that I
ignore the implementation details of.

Node.js is a C++ application at its core, and it interacts with the operating
system through system calls and the standard C library. The choice of standard
C library can have an impact on the performance of the application, especially
when it comes to I/O-bound operations, and thinking that a JIT-compiled language
like JavaScript is immune to these low-level details is naive.

[break](#)

Syscalls and I/O operations are the most common ways that a Node.js application
interacts with the operating system. `glibc`'s implementations of most of them
(I'm talking `malloc`, `memcpy`, `printf`, etc.) are heavily optimized.
`malloc`, for example, is implemented in a way that makes it fast and efficient
for allocating and deallocating memory different than `musl` in several aspects.

[break](#)

Why is important? Well, `malloc` is our key to the magical heap.

### Heap? What's that?

The heap is essentially a list of memory regions that a running program uses to
store data on, dynamically.
When we access memory on the heap, the operational the speed is OFC slower
than when handling the stack because in a stack frame, data (or instructions) is simply
pulled/pushed into memory in a sequential, atomic fashion. This creates no need
specifically seek out particular memory addresses. On the heap, however, the
program must search for an empty memory block that is large enough to store the
data. I don't need to tell you that this is a much slower process than the stack
operation, so the way memory allocators optimise the de/allocation of memory
blocks is crucial for the performance of the program.

[break](#)

Since the stack is much faster than the heap, then why we would even need the
heap? Because  sometimes we need to allocate memory dynamically in the program.
Therefore the heap is designed to cope with our need. The data stored in heap
regions are requested during runtime. This also means when we don't use
functions like  `malloc` in the program, heap will not be initiated in the
memory zone.

## A bit of history on musl vs glibc

`musl` and `glibc` are two different implementations of the standard C library,
and they have different design philosophies.

`glibc` has been around for a long time (since 1987, probably older than me and
you) and is known for its feature-richness and compatibility with a wide range
of software. It's accumulated a ton of triage and consequent optimizations over
the years, and it's the default C library on most Linux distributions. However,
`glibc` is also known for its large size and memory footprint, which can be a
problem for resource-constrained environments.

`musl`, on the other hand, is a newer (its first release was in 2011)
implementation of the standard C library
that is designed with simplicity and lightweightness in mind. It is known for its
small size and minimalistic design, and it is optimized for static linking,
which can result in developers being able to ship applications as small, single
binaries with faster startup times, keeping their runtime memory footprint low. 
A godsent for embedded systems and IoT devices. `musl` is the
default C library on Alpine Linux, and has become a popular choice for containerised
applications because of its minimalistic design philosophy.
However, `musl` is also known for its lack of compatibility with
some software that expects `glibc`-specific behavior (or maybe `glibc` is knowing
for doing sh!t its own way) and for putting simplicity
over tunability, and this has a certain impact on the performance of some  
applications compiled against it.

## Breaking down the performance differences

Well, now you know the difference between `musl` and `glibc`, and you might've
guessed that the choice of standard C library is what makes the difference in
performance between Alpine and Debian. But how does it actually affect the
performance of a Node.js application on a practical level? The internet is full
of theories with no practical examples, but you know this blog's existence is
entirely devoted to clearing the fog of confusion around software development, so
let's provide some straightforward explanations.

### glibc

`glibc` uses the `ptmalloc` ("pthreads malloc") implementation of `malloc`, a 
modern derivation of `dlmalloc` that is optimized for multi-threaded applications.
It uses sorted lists instead of binary tries in bins for large blocks, plus a 
special array of fast bins for blocks of memory. When freed, these blocks are kept marked as used
and put into the appropriate fast bin. Allocation is satisfied using exact fit
from fast bins when possible. Fast bins are emptied under multiple heuristic
conditions. The big difference between `ptmalloc` and `dlmalloc`, though, is in support for
**concurrent allocations**. The `ptmalloc` allocator maintains multiple
[arenas](https://en.wikipedia.org/wiki/Region-based_memory_management).
Each arena is an independent instance of the allocator protected by a lock.
Upon allocation, the thread invoking the allocator attempts to lock an
arena, starting with the one it used last. If an arena is locked successfully,
it is used to satisfy the allocation request, otherwise a new arena is
allocated. `ptmalloc`'s architecture avoids lock-contention as much as possible.
But its strength is (as always in cases like this) also in a much better API,
which makes supporting slabs and array or struct elements super neat via
`independent_comalloc` ([here](https://code.qt.io/cgit/qt/qt.git/tree/src/3rdparty/ptmalloc/malloc-2.8.3.h#n214)),
which speeds up my compiled code by ~20%. Its thread stack size is variable, 
depending on resource contraints, but can be set to up to ~10MB, making it
suitable workloads split into a large number of concurrent threads.

### musl

`musl` uses the `dlmalloc` implementation of `malloc`, which is optimized for
simplicity and minimalism. It uses a single heap for all threads, and it
doesn't have the same level of triage as `ptmalloc`. It uses a binary trie
structure for small blocks and a sorted, doubly-linked list for large blocks.
**It doesn't support concurrent allocations**, with a single lock for all threads,
which can lead to lock contention in multi-threaded applications. Memory
management is differentiated for large and small blocks of memory:

- For small (< 256kb) blocks `brk` - a kernel-level memory allocation call - is
used, even though there's a detail: more memory than needed will be requested.
It's gonna be used for later allocation without diving down to the kernel level.
For `free`s, it won’t free the memory directly at the kernel level, but just
mark it as free.

- For large (> 256kb) blocks `mmap` and `munmap` are called, so no more caching 
is needed. This is a good thing, because it's a lot faster than `brk` for large
blocks. But it can also be a bad thing, because it's a lot slower than `brk` for
small blocks. 

Its thread stack size is fixed at ~128KB, which is a lot smaller than `glibc`'s
default. This can be a problem for workloads that require a large number of
concurrent threads, as the stack size can be a limiting factor.

## Conclusions
With all that said, it's clear that the choice of standard C library can have a
significant impact on the performance of a Node.js application. 

Most web applications do heavy string processing, I/O operations, and/or depend
on delegating workloads to native dependencies, all factors which can be affected
by the memory management and thread allocation strategies of the standard C library
used a few layers below the Node.js runtime. 

[break](#)

In general, if you're running a Node.js application and want to maximize its
runtime performance, expecting a high number of concurrent threads, then
`glibc` is the way to go. If you're running a Node.js application in a
resource-constrained environment and want to minimize its memory footprint and
startup time, then `musl` is probably the way to go for you.

Node.js on Alpine vs Debian: Performance differences

 Navigating Italy’s Socioeconomic Contradictions

## Italy's economics cannot be studied

In Italy, a curious (and frustrating) dynamic permeates our understanding of poverty and wealth. Much of what we perceive in official studies and data doesn’t, in my opinion, align at all with what we experience in everyday life. This is why I think that at this point in history, **Italy's microeconomics cannot be studied**, and **have never been studied in a way that hasn't been proven completely flawed**.


## Tourists of poverty

I see this firsthand when I run into old schoolmates —now in their thirties— most of whom are highly educated, with university degrees, expensive and exclusive master’s qualifications, and even more advanced training. The majority claim to earn just a fraction of what I make, despite their higher qualifications, and they do: **they earn too little, they earn so little that their lifestyle choices don't add up**.

[break](small)

**On paper, they appear to be part of Italy’s struggling young workforce**, dwelling through unpaid internships and low-paying, precarious jobs, but what’s odd is the **disparity between what they report and the life that they lead**. 

[break](small)

I drive a modest 10-year-old city car, a cheap one that you could get for a few thousand euros at the time, which gets me from point A to point B. And that's enough for me. But I regularly see luxury cars parked outside in the street. If I look out of my balcony window, I can see my 10+ old berlina parked in the same line as four Teslas.
This place is full of **people with financial backing from families** so wealthy that they can casually open and close businesses for their children without concern. They live in houses I can’t afford and drive cars I could only dream of purchasing — even if I **could** afford to do it, because **what I save is all I have**.  

[break](small)

I call them **“tourists of poverty”**. These are **people who technically fall into the category of the underpaid but whose personal wealth makes them anything but poor**. They are shielded from the real financial struggles that their income alone would suggest. It’s no wonder that I distrust many of the studies around poverty and economic hardship in Italy. From my experience, especially here in the South, higher education often serves more as a status symbol than a pathway to financial success. A lot of youngsters are basically "gifted" university degrees both from families willing to pay for their studies indefinitely, and from an instruction system which is notoriously turning into a degree mill. __Education is no longer the great equalizer it once was; it’s often a marker of privilege, not a tool for social mobility__.


## Hidden Wealth, Debt, and the Disappearing Proletariat in Modern Italy

I’ve long suspected that **the official data about poverty in Italy is misleading**, and I believe several indicators support this view. First, there’s the **enormous amount of unreported wealth that exists**, particularly in the South. Many professionals —lawyers, doctors— seem to declare low earnings on paper, but they’re also the ones **pocketing cash payments under the table**, avoiding taxes, and quietly amassing wealth. This system allows them to live better than the honest surgeon who pays nearly half of his income in taxes. I've never once in my lifetime been able to pay a doctor with my card, and when confronting them on the subject I've been met with an endless stream of lamentations about how they're "oppressed by our unfair tax system, struggling to make ends meet".

[break](small)

I’ve been the poorest person in my social circles since childhood, yet many of my friends came from families that officially qualified for the lowest ISEE (Italy's Indicator of equivalent economic situation) brackets. Despite this, they showed up to university driving brand new cars, with the latest iPhones and MacBooks. It wasn’t just one or two; this was the norm.

## The financially illiterate

A major part of the problem is that **financial literacy is severely lacking in our culture**. People with half my salary spend triple what I do. I know someone, for example, who splurged on expensive accessory goods like an iPhone, various Apple accessories, a new car, a super expensive Dyson hair straightener, plus several subscription services, all with her first paycheck. All of this was financed through absurdly long payment plans that distort the true picture of her finances. It’s the same story all over here, where you see long **lines outside stores selling iPhones in low-income neighbourhoods** on the day of a new release.

[snip](youth-unemployment-data-2020)

## Scrooge McDuck meets John Locke 

**This isn’t just an economic issue—it’s cultural**. **The concept of the proletariat, a class of people who are economically struggling, seems to have disappeared**. Financially unstable people often spend and incur debt at levels equal to or greater than the wealthy. The result? **The traditional class divide has blurred, **making it harder to discern who is truly poor. If **the poor spend like the rich** and **the rich pretend they're poor as a means of virtue signalling** (and tax avoidance, of course), how can we even begin to accurately measure poverty? Data fails to capture the truth in such intricate circumstances.

[break](small)

I feel like living in a society that's still moving among **blurred lines of aristocracy and bourgeoisie**, where the new artistocrats live off monumental riches amassed in the dark by their wealthy families, while still applying for low-paying jobs to keep alive the symbolism of work as a source of virtue, and the poor simply never come to terms with their situation, because our society is so deeply rooted in the idea that **the rich are superior to the poor**, to the point that every effort in equalisation ends up in making debt, not freedom, more accessible.


Italy's illusion of poverty

 Navigating the world of I/O multiplexing is like choosing the right dance partner.

I’m pretty sure I’m not the only multitasker here. Hell, even my computer is one. Ever wondered how it efficiently juggles multiple tasks like downloading files, handling network requests, and reading user input, all at the same time? Enter the world of I/O multiplexing, a clever technique that allows a system to manage multiple input/output operations simultaneously.

Think of I/O multiplexing as a sort of traffic cop for your computer's data flow. It ensures that different tasks can be processed without any one of them hogging all the attention. This is crucial for applications that require responsiveness and efficiency, from web servers to gaming systems.

Navigating the world of I/O multiplexing is like choosing the right dance partner for a tech tango. Each option — `select`, `poll`, and `epoll` — comes with its own style, moves, and intricacies. Let's dive deeper into the mechanics of each to help you make an informed decision.

## Select: The inclusive socialite 🕺💃

Select is akin to the socialite who invites everyone to the party, regardless of their dance skills. It's the oldest method in the book, compatible with most platforms, and can handle a moderate (≤ 1024) number of file descriptors.

### Internals:

- Select uses a linear scan to check which file descriptors are ready for reading or writing. This means it sequentially goes through each descriptor, which can lead to inefficiencies, especially with large sets of descriptors.

#### Pros:

- Portability: `select` is compatible with a multitude of UNIX and UNIX-like OSs.
- Straightforward: It's relatively easy to implement and understand.
- Supports all descriptor types: `select` accommodates various types like sockets, pipes, and more.

#### Cons:

- Limited scalability: Due to its linear scanning approach, performance can degrade as the number of descriptors increases.
- Inefficiency: The entire set is scanned, even if only a few descriptors are ready, which can be a performance bottleneck.

### Signature

```c
int do_select(int n, fd_set_bits *fds, struct timespec *end_time)
```

[break](small)

## Poll: The balanced ballroom dancer 💃🕺

Poll is like the ballroom dancer who gracefully balances across the floor. It's a step up from Select, offering improved scalability and efficiency.

### Internals:

- Poll uses a bitmask to track file descriptors, making it more efficient than Select. It's also based on a polling model, which allows it to handle larger sets of descriptors.

#### Pros:

- Improved scalability: Poll can handle a larger number of file descriptors efficiently.
- Efficient algorithm: It uses a bitmask to track descriptor states, which is more efficient than the linear scan of Select.
- Widely compatible: While not as universal as Select, Poll is available on many platforms.

#### Cons:

- Portability: Not supported by all UNIX-like OSs.
- Performance plateau: While an improvement over Select, Poll's performance may start to plateau with extremely high concurrency scenarios.

### Signature

```c
static unsigned int poll_schedule_timeout(struct poll_wqueues *wait)
```

[break](small)

## Epoll: The breakdancing prodigy 🕺🎵

Epoll is like the breakdancing prodigy, capable of handling the most complex and dynamic moves with finesse. It's Linux-specific, tailored for high-performance, high-concurrency applications.

### Internals:

- Epoll uses an event-driven model. It waits for events to occur and then efficiently notifies the application. This minimizes CPU cycles and provides detailed event information.

#### Pros:

- Exceptional scalability: Epoll excels in scenarios involving a large number of file descriptors. It has an O(1) complexity versus the O(n) of Select and Poll.
- Efficient event-driven model: It only reacts to changes, saving significant CPU resources.
- Fine-grained control: Epoll provides detailed event information, allowing for precise management of descriptors.

#### Cons:

- Linux-specific: Epoll is limited to Linux systems, so it's not a universal solution.

### Signature

```c
static inline void ep_set_poll_callback(struct epitem *epi, poll_table *pt)
```

[break](small)

## Final words

Choosing the right I/O multiplexing technique depends on the size and demands of your tech tango! Whether it's a small gathering, a balanced mix, or an extravagant bash, understanding the internals of Select, Poll, and Epoll will help you make the right choice. Remember, there's no one-size-fits-all solution, and sometimes, a combination of techniques may be the key to a flawless performance. So, lace up your coding shoes and get ready to multiplex your I/O with style! Happy coding! 🕺💃


The dance of I/O multiplexing

Personal staples of human-centric software engineering

Staples of human-centric software engineering

Tiltable cards are everywhere, let's recreate them from scratch in React!

## Introduction
![Meme](https://i.imgur.com/7pNeWYql.png)

These days it looks like tiltable cards are all the rage, and I wanted to see
how easy it would be to implement them from scratch in React.

I'm going to be using the bare minimum of external dependencies to implement this (namely just
`framer-motion` to interpolate animation values smoothly, but using 
alternatives such as `react-spring` should be pretty straightforward).

## Step 1: Designing the card
We're gonna lay down a very rough card design, just to get things started.

[break](#)

Let's start by creating a card component that will contain the content of the card.
Inside of it, there will be a single, centered paragraph of text:

```jsx
<div
  style={{
    width: "240px",
    height: "320px",
    backgroundColor: "#C2B8F0",
    borderRadius: "0.5rem",
    boxShadow:
      "0 0 0 1px rgba(0, 0, 0, 0.105), 0 9px 20px 0 rgba(0, 0, 0, 0.02), 0 1px 2px 0 rgba(0, 0, 0, 0.106)",
    position: "relative",
    display: "flex",
    alignItems: "center",
    justifyContent: "center"
  }}
> 
  <p>LIGMA</p>
</div>
```

We should end up with something like this:
[snip](1-1)

This sets the basics for our card. Now, let's add some tilt effects to it. 

[break](#)

## Step 2: Implementing the tilt effect

We'll start by adding some dedicated CSS properties to the card:
```
transformStyle: 'preserve-3d'
transformOrigin: 'center'
perspective: '320px'
```

Let's break down their meanings:
* `transform-style: preserve-3d`: Indicates that the children of the element should be positioned in their own 3D plane, or be flattened to their parent's.
[snip](1-5)

[break](#)

* `transform-origin: center`: Sets the fulcrum for the element's transformations.
[snip](1-6)

[break](#)


* `perspective: 320px`: Determines the distance between the z=0 plane and the viewer in order to give a 3D-positioned element some perspective. In this case I found the card's height in pixels to be the sweet spot.
[snip](1-7)

[break](#)

#### We're now ready to implement the tilt effect!
[break]('#')

In order to do that, we'll need to keep track of the mouse position on the card, plus the card's animation state:
* `rotations`: We'll use this to store the current tilt angle(s) of the card.
* `isAnimating`: We'll use this to keep track of the animation state of the card.

React's `useState` hook will be perfect for this:
```
const [rotations, setRotations] = useState({ x: 0, y: 0, z: 2 });
const [isAnimating, setAnimating] = useState(false);
```

Now we're gonna have to handle two separate interaction events:
* `onMouseMove`: When the mouse is moving on the card, we want to do some calculations to determine the tilt angle.
* `onMouseLeave`: When the mouse leaves the card, we want to reset the tilt angle to 0.

Let's look at their implementations:

> Some logic is getting implemented for now on, watch the comments! 👀  

#### onMouseMove event handler
```jsx
// Put these anywhere you wish, I personally put them into a dedicated `utils` file.
export function round(num, fix = 2) {
  return parseFloat(num.toFixed(fix));
}

export function distance(x1, y1, x2, y2) {
  return Math.sqrt(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2));
}

const handleMouseMove = (event) => {
  setAnimating(true); // We're animating the card.

  // We're getting the bounding box of the card.
  const rect = event.currentTarget.getBoundingClientRect();

  // We're getting the mouse position relative to the card.
  const absolute = {
    x: event.clientX - rect.left,
    y: event.clientY - rect.top
  };

  // We're getting the mouse position relative to the center of the card,
  // in percentage, starting from x, y 0% 0% top-left, ending in 100% 100% bottom-right. 
  const percent = {
    x: round((100 / rect.width) * absolute.x),
    y: round((100 / rect.height) * absolute.y)
  };

  // We're getting the tilt angle of the card, calculated on the
  // percentage of distance from the center, going from
  // -50% to 0% to 50% left to right, top to bottom.
  const center = {
    x: percent.x - 50,
    y: percent.y - 50
  };

  // We can now set the tilt angle(s) of the card. Note that the
  // divisions here (/ 12, / 16, / 20) are used to stabilize the
  // rotations using smaller values. Play with them and experiment
  // you perfect fine-tuning!
  setRotations({
    x: round(((center.x > 50 ? 1 : -1) * center.x) / 12),
    y: round(center.y / 16),
    z: round(distance(percent.x, percent.y, 50, 50) / 20)
  });
};
```

Before we go any further, let's break down what's about to happen for the `onMouseLeave` event:
* We're gonna set the `isAnimating` state to `false`.
* We're gonna set a timeout to reset the tilt angle(s) to 0 after 100ms, to stop the card from abruptly stopping its animation.

We're gonna have to check for the `isAnimating` state in the `onMouseMove` event handler,
but having to do that inside of a `setTimeout` callback is not ideal. In order
to access the current `isAnimating` state in this case, we'll need to create a
**closure** around the object. 
The reference to the object will always be the same in the closure function but 
the actual value stored by the object will be changed each time the callback 
function runs.

[break]('#')
A solution to this issue is to use the `useRef` hook:
```
const isAnimatingReference = useRef(isAnimating);
```

We can now proceed to implement the `onMouseLeave` event handler:

#### onMouseLeave event handler
```js
const stopAnimating = () => {
  setAnimating(false);

  setTimeout(() => {
    if (!isAnimatingReference.current) return;

    setRotations({ x: 0, y: 0, z: 2 });
  }, 100);
};
```


Now we have all the pieces we need to tilt the card. Let's bind our states and event handlers to the card component:

(if you haven't already, install the `framer-motion`, so we can use the `motion` component to smoothly transition between different values)

[break]('#')

```jsx
<motion.div
  // Mouse interactions events handlers.
  onMouseMove={animate}
  onMouseLeave={stopAnimating}
  animate={{
    // Rotation values used to tilt the card.
    rotateY: rotations.x,
    rotateX: rotations.y,
    transformPerspective: rotations.z * 100
  }}
  style={{
    width: '240px',
    height: '320px',
    backgroundColor: '#C2B8F0',
    borderRadius: '0.5rem',
    boxShadow:
      '0 0 0 1px rgba(0, 0, 0, 0.105), 0 9px 20px 0 rgba(0, 0, 0, 0.02), 0 1px 2px 0 rgba(0, 0, 0, 0.106)',
    display: 'flex',
    alignItems: 'center',
    justifyContent: 'center',
    transformStyle: 'preserve-3d',
    transformOrigin: 'center',
    perspective: '320px'
  }}>
  <p>LIGMA</p>
</motion.div>;
```

We should end up with something like this:
[snip](1-2)

Fantastic, the card tilts smoothly on mouse hover! But we're not done yet. 
As you can see, the card's tilt angle creates an optical illusion due to the lack of perceived depth, caused by the absence of shadows/highlights.
We can fix that by applying some CSS magic to the card's children to make them appear as if they're on the card's surface.

[break](#)

## Step 3: CSS magic dust
As we previously said, we're gonna add visual depth to the card by adding a 
translucent layer to it, but -trust me- this is really all that's left to do in
order to get the card to look like it's floating in thin air!

The card's structure is gonna be like this:
* Card 
  * Card transulcency layer
  * Card children

```jsx
<motion.div
  style={{
    // Place above the rest.
    zIndex: 2,

    // Use an overlay blending mode to make the effect more realistic.
    mixBlendMode: 'overlay',

    // Use absolute positioning.
    position: 'absolute',

    // Always keep in front of the card in the 3d plane.
    transform: 'translateZ(1px)',

    // Cover the whole card's area.
    width: '100%',
    height: '100%',

    // Same border radius as its parent.
    borderRadius: '0.5rem',

    // We already know about this ;).
    transformStyle: 'preserve-3d'
  }}
  animate={{
    // This is gonna draw a pseudo glare on the card. The `50% 50%`
    // means it's gonna stay centered, for now...
    background: `radial-gradient(
      farthest-corner circle at 50% 50%,
      rgba(255, 255, 255, 0.7) 10%,
      rgba(255, 255, 255, 0.5) 24%,
      rgba(0, 0, 0, 0.8) 82%
    )`
  }}
/>
```

We should end up with a static glare sitting on top of the card like the following:
[snip](1-3)

[break](#)
Of course a static glare brings no value to our recipe, so we need to make it follow the mouse position, and if you remember,
we already have all the necessary coordinates-calculating logic inside of our `handleMouseMove` function!

Let's add a `glareCoordinates` state to our component, update it into said handler, and finally bind it to the card overlay glare's position.

#### Glare coordinates state
```
const [glareCoordinates, setGlareCoordinates] = useState({ x: 0, y: 0, opacity: 0 });
```

#### Glare coordinates update
```js
const animate = (event) => {
    /* ... All the code we previously wrote inside of the handler... */

    setGlare({
      x: percent.x,
      y: percent.y,
      opacity: 0.25,
    });
  };
}
```

#### Glare coordinates binding to the glare overlay
```jsx
<motion.div
  // ...
  animate={{
    background: `radial-gradient(
            farthest-corner circle at ${glareCoordinates.x}% ${glareCoordinates.y}%,
            rgba(255, 255, 255, 0.7) 10%,
            rgba(255, 255, 255, 0.5) 24%,
            rgba(0, 0, 0, 0.8) 82%
        )`,
    opacity: glareCoordinates.opacity
  }}
/>
```

[break](#)
## Step 4: Nah... no step 4, we're good!

As promised, we're done already. We should end up with something like this:
[snip](1-4)

[break](#)

The code to recreate this whole effect should look like the this:
```jsx
const Card = () => {
  const [rotations, setRotations] = useState({ x: 0, y: 0, z: 0 });
  const [isAnimating, setAnimating] = useState(false);
  const isAnimatingReference = useRef(isAnimating);
  const [glare, setGlare] = useState({ x: 0, y: 0, opacity: 0 });

  const animate = (event) => {
    setAnimating(true);

    const rect = event.currentTarget.getBoundingClientRect();

    const absolute = {
      x: event.clientX - rect.left,
      y: event.clientY - rect.top
    };

    const percent = {
      x: round((100 / rect.width) * absolute.x),
      y: round((100 / rect.height) * absolute.y)
    };

    const center = {
      x: percent.x - 50,
      y: percent.y - 50
    };

    setRotations({
      x: round(((center.x > 50 ? 1 : -1) * center.x) / 12),
      y: round(center.y / 16),
      z: round(distance(percent.x, percent.y, 50, 50) / 20)
    });

    setGlare({
      x: percent.x,
      y: percent.y,
      opacity: 0.25
    });
  };

  const stopAnimating = () => {
    setAnimating(false);

    setTimeout(() => {
      if (isAnimatingReference.current) return;

      setRotations({ x: 0, y: 0, z: 2 });
      setGlare({ x: 50, y: 50, opacity: 0 });
    }, 100);
  };

  return (
    <motion.div
      onMouseMove={animate}
      onMouseLeave={stopAnimating}
      animate={{
        rotateY: rotations.x,
        rotateX: rotations.y,
        transformPerspective: rotations.z * 100
      }}
      style={{
        width: '240px',
        height: '320px',
        backgroundColor: '#C2B8F0',
        borderRadius: '0.5rem',
        boxShadow:
          '0 0 0 1px rgba(0, 0, 0, 0.105), 0 9px 20px 0 rgba(0, 0, 0, 0.02), 0 1px 2px 0 rgba(0, 0, 0, 0.106)',
        display: 'flex',
        alignItems: 'center',
        justifyContent: 'center',
        transformStyle: 'preserve-3d',
        transformOrigin: 'center',
        perspective: '320px'
      }}>
      <motion.div
        style={{
          zIndex: 2,
          mixBlendMode: 'overlay',
          position: 'absolute',
          transform: 'translateZ(1px)',
          width: '100%',
          height: '100%',
          borderRadius: '0.5rem',
          transformStyle: 'preserve-3d'
        }}
        animate={{
          background: `radial-gradient(
            farthest-corner circle at ${glare.x}% ${glare.y}%,
            rgba(255, 255, 255, 0.7) 10%,
            rgba(255, 255, 255, 0.5) 24%,
            rgba(0, 0, 0, 0.8) 82%
          )`,
          opacity: glare.opacity
        }}
      />
      <p>LIGMA</p>
    </motion.div>
  );
}
```

[break](#)

# Stay tuned for more!

Tiltable cards from scratch in React

Explaining the difference in the simplest way possible.

## Introduction
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.

## Conclusions
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!

## Introduction
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.

## Implicit values
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 = {}));
```

## Integer values
When an integer number is assigned as the value, it is simply assigned instead of the default incremental integer in the example before.
```js
// Before
enum Steak {
    Medium = 10,
    Rare = 20,
    WellDone = 30
}

// After
var Steak;
(function (Steak) {
    Steak[Steak["Medium"] = 10] = "Medium";
    Steak[Steak["Rare"] = 20] = "Rare";
    Steak[Steak["WellDone"] = 30] = "WellDone";
})(Steak || (Steak = {}));
```

## String values
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
// Before
enum TestEnum {
	a = 'aA',
	b = 'bB',
	c = 1,
	d = 2,
	e = '01'	
}

// After
var TestEnum;
(function (TestEnum) {
    TestEnum["a"] = "aA";
    TestEnum["b"] = "bB";
    TestEnum[TestEnum["c"] = 1] = "c";
    TestEnum[TestEnum["d"] = 2] = "d";
    TestEnum["e"] = "01";
})(TestEnum || (TestEnum = {}));
```

## Conclusions
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' ] ]`)  


## Solution
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..

## Introduction
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.

## Introduction
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.

## Next.JS 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": {}
  }
};
```


## Conclusions
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 

I write about