Erranto RSS Feed

The try/catch/maybe story

Elvis Adomnica — Sun, 02 Mar 2025 16:55:09 GMT

import JSSnippet from "../../components/JSSnippet.svelte"

When we lean about exception handling, and the try/catch/finally statements, we are told that the finally block is guaranteed to always execute. Here is an example:

function doSomething() {

}

try {
  doSomething();
  console.log("Done!");
  return 42;
} catch (e) {
  console.error("Got error:", e);
} finally {
  console.log("Finally!");
}

</JSSnippet>

The code above will successfully execute doSomething (the function doesn't do anything at the moment), it will print Done, and then, even though there is a return statement, it will print Finally!.

Let's see what happens if we throw an exception inside doSomething:

function doSomething() {
  throw new Error("Nope!");
}

try {
  doSomething();
  console.log("Done!");
  return 42;
} catch (e) {
  console.error("Got error:", e);
} finally {
  console.log("Finally!");
}

</JSSnippet>

As expected, the exception being thrown will interrupt the execution of the try block, triggering the catch block, which will print Got error: Error: Nope!. After that, the finally block will execute, printing Finally!.

For synchronous code the finally guarantee holds true. The question is, will it also hold true for async code? Technically yes, but with a caveat. The promise that is being awaited needs to be resolved or rejected before the rest of the code can execute.

Let's return to our code examples and this time use async code.

async function doSomething() {
  return Promise.resolve();
}

try {
  await doSomething();
  console.log("Done!");
  return 42;
} catch (e) {
  console.error("Got error:", e);
} finally {
  console.log("Finally!");
}

</JSSnippet>

Just like in our first example, doSomething will successfully resolve with undefined, after which the rest of the code will execute, printing Done! followed by Finally!.

If we reject from doSomething the result will be similar with the second sync code example:

async function doSomething() {
  return Promise.reject(new Error("Nope"));
}

try {
  await doSomething();
  console.log("Done!");
  return 42;
} catch (e) {
  console.error("Got error:", e);
} finally {
  console.log("Finally!");
}

</JSSnippet>

In both our examples, the promise has settled, which allowed the execution of the rest of the code to continue. However, in the recent months, I have stumbled upon a situation where the promise never settled. We nicknamed that bug the try/catch/maybe bug. Here is how it looks like.

const someCondition = false; 
async function doSomething() {
  return new Promise(resolve => {
    if (someCondition) {
      resolve(); // never resolves because our condition is `false`
    }
  });
}

try {
  await doSomething();
  console.log("Done!");
  return 42;
} catch (e) {
  console.error("Got error:", e);
} finally {
  console.log("Finally!");
}

</JSSnippet>

It's not rocket science, but it took us a little bit of debugging until we realized that we are not resolving our promises. That's why I advice to be careful when using conditionals in the new Promise constructor handler.

JavaScript hoisting and IE polyfills

Elvis Adomnica — Sat, 05 Oct 2024 15:42:09 GMT

import JSSnippet from "../../components/JSSnippet.svelte"

It has been a very long time since I last had to deal with hoisting in JavaScript. If my memory serves me correctly, it had something to do with using ES module imports in Jest. Oh man... I have never enjoyed using Jest. It always felt like I needed to fight it to get it to do what I want. Or maybe it was just "skill issue".

Fast forward to a few weeks ago, and voilà — JavaScript hoisting strikes again. This time, it had to do with Internet Explorer (IE) polyfills. Yep, IE — that old thing that made our lives as web developers a little bit more "colorful". If you ever had to write code to support it, I bet you remember having to include a gazillion polyfills just to make it behave like the rest of the browsers.

Luckily for us, Microsoft ended support for IE 11 on June 25, 2022, and has encouraged its users to move to the Chromium-based Microsoft Edge. This means we no longer needed to include the polyfills, and we could, therefore, remove a couple of hundred lines of code from our bundle. Easy peasy — except our Cypress tests running on Chrome started to fail. Whoot?? How does removing IE polyfills make Chrome tests fail? The short answer...

For the long answer, we will have to dive into how the scope works in JavaScript, what is hoisting, and how the polyfill detection phase was implemented. So let's get started.

JavaScript scope and hoisting

Most of the bad reputation that the language gets is coming from the way the scope was implemented and how hard it is to rationalize about the value of the this reference. Up until the introduction of the array functions, it was very common to see code like var that = this; or var self = this. Anyway, it will take too much space to cover the quirks of the this keyword here, so I will only focus on simple variables and functions.

Traditionally, variable declaration was done using the var keyword. If a variable is declared but not initialized, it will by default have an undefined value.

var name = "Moo";
var uninitialized;

console.log(name);
console.log(uninitialized);

</JSSnippet>

So far, so good. We have created two variables and printed their values. The name variable was given an initial value, while we left the uninitialized variable, well... uninitialized. Things start to make less sense when you encounter code similar to the one below.

function fun(cond) {
  if (cond) {
    var someValue = "some-value";
  }

  console.log(someValue);
}

fun(true);
fun(false);

</JSSnippet>

In a sane programming language, you'd expect line 6 to throw an error like ReferenceError: someValue is not defined. Not in JavaScript, though! Before the introduction of let and const, a variable would belong to one of two scopes:

function scope, if the variable was declared inside a function;
global scope, if the variable was declared outside of a function.

In the scenario above, someValue is visible throughout the function scope even though it was declared inside an if block. This is what we refer to as hoisting: a variable declared with var is visible from the beginning of its scope regardless of the position in code where it was declared.

To make things worse, if you by mistake omit the var keyword (e.g. you misspell the variable name), you will create a global variable.

function fun(cond) {
  var someValue;

  if (cond) {
    somValue = "some-value"; // misspelled
  }

  console.log(someValue);
}

fun(true); // creates global variable 'somValue'
fun(false);

console.log(somValue); // misspelled again, prints 'some-value'

</JSSnippet>

Strict mode

One way to prevent such mistakes is to use strict mode. In strict mode, line 7 throws ReferenceError: assignment to undeclared variable somValue:

"use strict";

function fun(cond) {
  var someValue;

  if (cond) {
    somValue = "some-value"; // misspelled, but throws an error
  }

  console.log(someValue);
}

fun(true);
fun(false);

console.log(somValue);

</JSSnippet>

While I recommend to always use strict mode, it does not help us with hoisting issues. Take the following code as an example: someValue is still hoisted, and line 4 will simply print undefined instead of throwing an error.

"use strict";

function fun() {
  console.log(someValue);

  {
    var someValue = "some-value"; // variable is declared inside a block
  }

  console.log(someValue);
}

fun();

</JSSnippet>

Let and const

To fix the issues that come from using the var keyword, JavaScript introduced two ways of declaring block-scoped variables: let and const. let is used when we want to reassign the variable later, while const is used when we never need to reassign it. Keep in mind that const only prevents reassignment; it does not make the variable immutable.

const person = {
  name: "Moo"
}

person.name = "Foo"; // mutates the name property of our object

console.log(JSON.stringify(person, undefined, 2));

</JSSnippet>

Let's return to our previous example and see if const will make our code more predictable.

function fun() {
  // throws `ReferenceError: someValue is not defined` because `someValue` is only visible within its block
  console.log(someValue);

  { // `someValue` is only visible inside this block
    const someValue = "some-value";
  }

  console.log(someValue);
}

fun();

</JSSnippet>

What about hoisting, is that also fixed? Oh well, line 3 finally throws an error!

function fun() {
  // throws `ReferenceError: can't access lexical declaration 'someValue' before initialization`
  console.log(someValue);

  const someValue = "some-value";

  console.log(someValue);
}

fun();

</JSSnippet>

With let and const we are in a much better place: variables are only visible in the block where they were declared, and we receive an error if we try to access a variable before its declaration.

The MouseEvent polyfill

Now that we have seen some of the quirks of JavaScript, we can return to our main story. Back when the team had to support IE, they ran into the typical API differences that required the use of a polyfill. In this case, it was the MouseEvent polyfill, as can be seen on this StackOverflow page. One of the answers there suggest that there is already a polyfill available on Mozilla Developer Network (MDN), "except that the try catch block in that code needs to look like this":

try {
  new CustomEvent('test');
  return false; // No need to polyfill
} catch (e) {
  // Need to polyfill - fall through
}

The polyfill has been removed from the main MDN website, but I managed to find it in a GitHub repository, and it looks almost identical to the one we were using:

export default function () {
    try {
        new MouseEvent('test');
        return false; // No need to polyfill
    } catch (e) {
        // Need to polyfill - fall through
    }

    // Polyfills DOM4 MouseEvent
    var MouseEvent = function (eventType, params) {
        params = params || { bubbles: false, cancelable: false };
        var mouseEvent = document.createEvent('MouseEvent');
        mouseEvent.initMouseEvent(eventType,
            params.bubbles,
            params.cancelable,
            window,
            0,
            params.screenX || 0,
            params.screenY || 0,
            params.clientX || 0,
            params.clientY || 0,
            params.ctrlKey || false,
            params.altKey || false,
            params.shiftKey || false,
            params.metaKey || false,
            params.button || 0,
            params.relatedTarget || null
        );

        return mouseEvent;
    };

    MouseEvent.prototype = Event.prototype;

    window.MouseEvent = MouseEvent;
}

At first glance, the code looks correct, although, as one of my colleagues pointed out, "the try/catch block is trying to be a little too smart." And he was absolutely right. If we learned anything from the previous section, it's that a variable declared with var will be hoisted to the beginning of the function. Let's add a console log in the catch block and see what error we get.

function fun() {
    try {
        new MouseEvent('test');
        return false; // No need to polyfill
    } catch (e) {
        console.log(e);
        // Need to polyfill - fall through
    }

    // Polyfills DOM4 MouseEvent
    var MouseEvent = function (eventType, params) {
        params = params || { bubbles: false, cancelable: false };
        var mouseEvent = document.createEvent('MouseEvent');
        mouseEvent.initMouseEvent(eventType,
            params.bubbles,
            params.cancelable,
            window,
            0,
            params.screenX || 0,
            params.screenY || 0,
            params.clientX || 0,
            params.clientY || 0,
            params.ctrlKey || false,
            params.altKey || false,
            params.shiftKey || false,
            params.metaKey || false,
            params.button || 0,
            params.relatedTarget || null
        );

        return mouseEvent;
    };

    MouseEvent.prototype = Event.prototype;

    window.MouseEvent = MouseEvent;
}

fun();

</JSSnippet>

TypeError: MouseEvent is not a constructor — there we have it! The new implementation for the MouseEvent will hoist, and line 3 will call new on an undefined value, instead of a constructor. This meant that the polyfill was always applied, regardless of the browser used. The version of the polyfill that I linked earlier uses a different name for the polyfill implementation (MouseEventPolyfill), so the name collision due to hoisting won't happen.

function fun() {
    try {
        new MouseEvent('test');
        console.log('No need to apply the polyfill');
        return false; // No need to polyfill
    } catch (e) {
        console.log(e);
        // Need to polyfill - fall through
    }

    // Polyfills DOM4 MouseEvent
    var MouseEventPolyfill = function (eventType, params) {
        params = params || { bubbles: false, cancelable: false };
        var mouseEvent = document.createEvent('MouseEvent');
        mouseEvent.initMouseEvent(eventType,
            params.bubbles,
            params.cancelable,
            window,
            0,
            params.screenX || 0,
            params.screenY || 0,
            params.clientX || 0,
            params.clientY || 0,
            params.ctrlKey || false,
            params.altKey || false,
            params.shiftKey || false,
            params.metaKey || false,
            params.button || 0,
            params.relatedTarget || null
        );

        return mouseEvent;
    };

    MouseEventPolyfill.prototype = Event.prototype;

    window.MouseEvent = MouseEventPolyfill;
}

fun();

</JSSnippet>

Once we realized that our polyfill was always applied and that our tests were relying on its API, we reworked the tests using the Cypress trigger API, and we were happy again.

It had been ages since I last dealt with a bug caused by hoisting, and this incident reminded me of the old days of working with JavaScript. I'm glad we've come such a long way since then.

A TDD implementation of Node.js Path module

Elvis Adomnica — Sat, 20 Jan 2024 21:32:00 GMT

import CodeBlock from "../../components/CodeBlock.astro";

export function print(x) { return x === 1 ? "+" : "-"; } export const firstChange = [0, 0, 1, 1, 0, 0, 0]; export const isAbsoluteEmpty = [0, 0, 1, 1, 0, 0, 0, 0, 0]; export const isAbsoluteTests = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0]; export const isAbsoluteImpl = [0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0]; export const assertStringTests = [0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0]; export const assertStringImpl = [0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0]; export const noSeparatorTests = [0, 0, 0, 0, 2, 1, 1, 1, 0, 2, 1, 0, 2, 1, 0, 2, 1, 0, 0, 0, 0, 0, 0, 0];

How many TDD practitioners does it take to change a light bulb? They don't change the bulb; they refactor the darkness!

Introduction

I have asked ChatGPT to tell me some jokes about test-driven development (TDD) and out of 12 generated answers none included unicorns. That's a bit of a disappointment considering how similar they are. Everyone is a big advocate of TDD and how great it is but I am yet to find a team that practices it consistently.

Ironically, I've chosen to join the advocates group by documenting a step-by-step TDD implementation of the Node.js Path module. But before we dive in, you might be wondering, 'What is test-driven development?' I have asked ChatGPT to answer this question for you, and here is the result:

Test-Driven Development (TDD) is a software development approach in which tests
are written before the actual code implementation. The TDD process typically
follows these steps:

1. **Write a Test**: Before writing any code, a developer creates a test that
defines a specific function or improvement of the software.

2. **Run the Test**: The newly created test is executed, and it should fail
because the corresponding code to fulfill the requirements hasn't been
implemented yet.

3. **Write Code**: The developer writes the minimum amount of code necessary to
pass the test. The primary goal is to make the test pass, not to create a
fully-featured solution.

4. **Run Tests**: After writing the code, all tests, including the new one, are
executed to ensure that the recent changes haven't broken any existing
functionality.

5. **Refactor Code**: If necessary, the code is refactored to improve its
structure, readability, or efficiency. At each step, the tests are rerun to make
sure that the changes haven't introduced errors.

6. **Repeat**: Steps 1-5 are repeated iteratively for each new piece of
functionality.

TDD is designed to promote a more robust and maintainable codebase by ensuring
that every piece of code has corresponding tests and that new features or
changes do not negatively impact existing functionality.

Pretty straight forward, right? TDD not only fosters a more robust and maintainable codebase but also mitigates the impact of "implementation bias" (status quo bias). This cognitive bias occurs when a programmer is influenced by existing code while crafting a new unit of code.

Consider this scenario: I've created a function tasked with parsing and processing an array of strings (we will actually write that later on in the path.resolve implementation). If I initially write the code without accounting for certain corner cases, chances are high that I'll overlook those same scenarios when crafting the corresponding tests. Also, another programmer aiming to enhance code coverage may be willing to write unit tests for my implementation. Their focus could be on ensuring each statement is executed at least once, potentially achieving full unit coverage without a comprehensive understanding of the implementation details. Consequently, they might overlook the same corner cases that eluded me as the original author.

Additionally, having a test-first approach will ensure less coupling between your components, and a better design of public interfaces.

Project setup

The project is configured as a basic JavaScript module without any build steps. The initial commit introduces the necessary GitHub workflow to execute the pipeline, establishes a straightforward test setup utilizing the built-in Node.js test runner, and uses a simple forwarding mechanism for the node:path module (as a starting point):

// lib/b-path.js
import path from "node:path";

export default path;

The TDD approach

We are now ready to add our first tests and make sure they fail by swapping our forwarding implementation with an empty one. Here is how that looks like:

// tests/b-path.test.js
import { describe, it } from "node:test";
import assert from "node:assert/strict";
import bPath from "../lib/b-path.js";

describe("b-path", () => {
  describe("POSIX", () => {
    it("path.delimiter should provide the path delimiter", () => {
      assert.strictEqual(bPath.delimiter, ":");
    });

    it("path.sep should provide the path separator", () => {
      assert.strictEqual(bPath.sep, "/");
    });
  });
});

// lib/b-path.js
const posix = {
  posix: null,
  win32: null,
};

posix.posix = posix;

export default posix;

Note that we will only focus on the POSIX implementation and completely ignore the Win32 API. With that in mind, we can now move to Step 3 and write the actual code, making the tests pass. This is as simple as adding the two missing properties to our posix object.

// lib/b-path.js
const posix = {
  delimiter: ":",
  sep: "/",
  posix: null,
  win32: null,
};

</CodeBlock>

path.isAbsolute(path)

Moving on to path.isAbsolute, we'll once again start with an empty implementation and write some tests based on the official documentation.

// lib/b-path.js
const posix = {
  isAbsolute: () => {},

  delimiter: ":",
  sep: "/",
  posix: null,
  win32: null,
};

</CodeBlock>

<br />

// tests/b-path.test.js
import { describe, it } from "node:test";
import assert from "node:assert/strict";
import bPath from "../lib/b-path.js";
describe("b-path", () => {
  describe("POSIX", () => {
    it("path.delimiter should provide the path delimiter", () => {
      assert.strictEqual(bPath.delimiter, ":");
    });
    it("path.sep should provide the path separator", () => {
      assert.strictEqual(bPath.sep, "/");
    });

    // input | expected result
    [
      ["", false],
      [".", false],
      ["foo/", false],
      ["foo.bar", false],
      ["/foo/bar", true],
      ["/baz/..", true],
    ].forEach(([input, result]) => {
      it(`path.isAbsolute("${input}") should return '${result}'`, () => {
        assert.strictEqual(bPath.isAbsolute(input), result);
      });
    });
  });
});

</CodeBlock>

Step 3 rightfully emphasizes that "the primary objective is to ensure the test passes, rather than creating a fully-featured solution". As you can see, I haven't written any tests to address scenarios where the input is not a string and we must raise a TypeError. We can incorporate those tests a bit later, but for now, let's focus on making our existing tests pass.

// lib/b-path.js
const posix = {
  /**
   * The isAbsolute() method determines if input path is an absolute path.
   * @param {string} path - input path
   * @returns {boolean}
   */
  isAbsolute: (path) => {
    return !!path && path.charCodeAt(0) === posix.sep.charCodeAt(0);
  },

  delimiter: ":",
  sep: "/",
  posix: null,
  win32: null,
};

</CodeBlock>

Running all the tests (Step 4) will now output the following results:

> b-path@0.0.0 test
> node --test tests

▶ b-path
  ▶ POSIX
    ✔ path.delimiter should provide the path delimiter (0.745045ms)
    ✔ path.sep should provide the path separator (0.164463ms)
    ✔ path.isAbsolute("") should return 'false' (0.186978ms)
    ✔ path.isAbsolute(".") should return 'false' (0.125469ms)
    ✔ path.isAbsolute("foo/") should return 'false' (0.250108ms)
    ✔ path.isAbsolute("foo.bar") should return 'false' (0.204638ms)
    ✔ path.isAbsolute("/foo/bar") should return 'true' (1.390664ms)
    ✔ path.isAbsolute("/baz/..") should return 'true' (0.16196ms)
  ▶ POSIX (4.772938ms)

▶ b-path (6.41931ms)

ℹ tests 8
ℹ suites 2
ℹ pass 8
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 104.492059

The not-so-happy path

As mentioned earlier, our current code and tests only cover the "happy path" where the input is provided as expected. Now, let's address the "not-so-happy path" and consider various input types. As always, we'll start with the tests first.

// tests/b-path.test.js
import { describe, it } from "node:test";
import assert from "node:assert/strict";
import bPath from "../lib/b-path.js";
describe("b-path", () => {
  describe("POSIX", () => {
    // ...

    [undefined, null, NaN, 42, BigInt(42), {}, [], Symbol(), false].forEach(
      (input) => {
        it(`path.isAbsolute should throw TypeError if input type is ${typeof input}`, () => {
          assert.throws(
            () => {
              bPath.isAbsolute(input);
            },
            {
              name: "TypeError",
              message: `The "path" argument must be of type string. Received ${typeof input}`,
            }
          );
        });
      }
    );
  });
});

</CodeBlock>

And then proceed with the actual implementation.

// lib/b-path.js
/**
 * The assertIsString() function verifies whether the input is a string,
 * throwing a TypeError otherwise.
 * @param {*} input
 * @throws {TypeError}
 */
function assertIsString(input) {
  if (typeof input !== "string") {
    throw new TypeError(
      `The "path" argument must be of type string. Received ${typeof input}`
    );
  }
}

const posix = {
  /**
   * The isAbsolute() method determines if input path is an absolute path.
   * @param {string} path - input path
   * @returns {boolean}
   */
  isAbsolute: (path) => {
    assertIsString(path);
    return !!path && path.charCodeAt(0) === posix.sep.charCodeAt(0);
  },

  // ...
};

</CodeBlock>

path.format(pathObject)

We continue our reverse engineering process with path.format. This method takes a pathObject as input and returns a path string based on the rules specified in the docs. We'll start with the "happy path" where the input is an object and we'll deal with the rest later. Once we have completed our implementation, we can swap it back with the 'forwarding mechanism' from the project setup and check that we have the right functionality.

Documenting every single step here would occupy too much space, instead, I have tagged the commits with pre-release tags to get a better overview. The very first version is somehow naive but it does cover most of the cases, which is a great starting point.

We should now handle the following scenario: "If only root is provided or dir is equal to root then the platform separator will not be included". To do so, we need to make some changes to our tests.

// input | expected result
[
  [{}, ""],
  [{ root: "/root" }, "/root"],
  [{ root: "/root", name: "file", ext: ".txt" }, "/root/file.txt"],
  // only root is present so no separator is included
  [{ root: "/root", name: "file", ext: ".txt" }, "/rootfile.txt"],
  [{ root: "/root/", name: "file", ext: ".txt" }, "/root/file.txt"],
  // should add the extension "." if missing
  [{ root: "/root", name: "file", ext: "txt" }, "/root/file.txt"],
  [{ root: "/root/", name: "file", ext: "txt" }, "/root/file.txt"],
  // should ignore 'name' and 'ext' if 'base' is present
  [{ root: "/root", base: "base.sh", name: "file", ext: ".txt" }, "/root/base.sh"],
  [{ root: "/root/", base: "base.sh", name: "file", ext: ".txt" }, "/root/base.sh"],
  // should ignore 'root' if 'dir' is present
  [{ root: "/root", dir: "/dir", base: "file.txt"}, "/dir/file.txt"],
  [{ root: "/root/", dir: "/dir", base: "file.txt"}, "/dir/file.txt"],
].forEach(([input, result]) => {
  it(`path.format(${JSON.stringify(
    input
  )}) should return '${result}'`, () => {
    assert.strictEqual(bPath.format(input), result);
  });
});

</CodeBlock>

We may attempt to correct our implementation by adjusting the return statement to return result.join("");. However, this adjustment would lead to a failure in our dir test:

✖ failing tests:

✖ path.format({"root":"/root/","dir":"/dir","base":"file.txt"}) should return '/dir/file.txt' (2.433298ms)
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
  + actual - expected

  + '/dirfile.txt'
  - '/dir/file.txt'
         ^
      at TestContext.<anonymous> (file:///home/elvis/eadomnica/b-path/tests/b-path.test.js:62:16)
      at Test.runInAsyncScope (node:async_hooks:206:9)
      at Test.run (node:internal/test_runner/test:580:25)
      at Suite.processPendingSubtests (node:internal/test_runner/test:325:18)
      at Test.postRun (node:internal/test_runner/test:649:19)
      at Test.run (node:internal/test_runner/test:608:10)
      at async Suite.processPendingSubtests (node:internal/test_runner/test:325:7) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: '/dirfile.txt',
    expected: '/dir/file.txt',
    operator: 'strictEqual'
  }

We can address this issue by ensuring that dir always includes a trailing slash, much like how we handled the absence of a dot in the extension. Here's what our updated solution would look like:

/**
 * The path.format() method returns a path string from an object.
 * This is the opposite of `path.parse()`.
 * @param {object} pathObject
 * @param {string} pathObject.root
 * @param {string} pathObject.dir
 * @param {string} pathObject.base
 * @param {string} pathObject.name
 * @param {string} pathObject.ext
 * @returns {string}
 */
format: (pathObject) => {
  const result = [];

  const root = pathObject.root || "";
  let dir = pathObject.dir || "";
  if (dir && dir.charCodeAt(dir.length - 1) !== posix.sep.charCodeAt(0)) {
    dir = `${dir}${posix.sep}`;
  }
  const base = pathObject.base || "";
  const name = pathObject.name || "";
  let ext = pathObject.ext || "";
  if (ext && ext.charCodeAt(0) !== ".".charCodeAt(0)) {
    ext = `.${ext}`;
  }

  const dirName = dir || root;
  const baseName = base || `${name}${ext}`;

  if (dirName) result.push(dirName);
  if (baseName) result.push(baseName);

  return result.join("");
},

We'll now proceed to substitute our current implementation with the 'forwarding mechanism' to confirm its correctness. Please note that the assertIsString function doesn't yield the same TypeError message, so we'll need to comment out those specific tests. Additionally, I'll take this opportunity to write more tests and cover some other corner cases.

...

This is slightly unexpected, only Node.js v20.x tests are passing. Nonetheless, I find it okay since v20.x transitioned to a Long Term Support version last October.

As for the extra tests, I went ahead and included a few more test cases. What caught me off guard was that a trailing slash is added to the dir property even if it already exists. The only scenario where this doesn't occur is if root is equal to dir, as specified in the docs. I had anticipated that the resulting path would be normalized but it doesn't seem so. Consequently, I had to modify my implementation to match the original behavior by making the following change:

const root = pathObject.root || "";
let dir = pathObject.dir || "";
if (dir && dir.charCodeAt(dir.length - 1) !== posix.sep.charCodeAt(0))
if (dir && dir !== root) {
  dir = `${dir}${posix.sep}`;
}
const base = pathObject.base || "";

</CodeBlock>

The full diff of the TDD approach for path.format (including the input check) can be seen here. Keep in mind that the commit at the bottom of the page is in fact our top commit.

path.normalize

Before we continue with path.parse and friends (path.basename, path.dirname, path.extname), let's address one of the elephants in the room: path.normalize.

We can start by modifying the input sanity check test from path.isAbsolute to include our new method. With that out of the way, we can now think of the best approach in handling such a complex function.

I must admit that I have already done this exercise last year, but I have deleted my repository, so I will have to do this all over again. If I remember correctly, the approach I took was to split the string by the path.sep and use a reduce function to compute the normalized path. While this will work, I cannot stop and think about the amount of intermediate objects created and the time spent traversing the input multiple times. Can we do the normalization in one go? Well, I guess we can, with the good-old for loop.

...

Alright! The implementation so far is not as crazy as I would have thought, but there are definitely some unhandled corner cases that I will be adding later. At this point, there are a total of 20 commits, one of which includes a small refactoring. This is by far the biggest advantage of test-driven development: you can refactor your code as you see fit while having the reassurance that it will still function correctly. And, on top of that, we preserved 100% code coverage.

After adding the promised corner cases, there was a need for some small adjustments, mainly around how to handle navigating up from the top directory. But wait, what about some paths that make absolutely no sense? Something like:

["...", "..."], // makes no sense
[".../.", "..."], // same
[".../..", "."], // same

We are reverse engineering the existing behavior so I guess I will have to go ahead and fix those as well. Even with such a non-sense corner case, our final implementation doesn't look very complex. Of course, as the author of the code I am extremely biased on this. And actually, as I pasted the code here, I realized I can do one more improvement. This is the final final version, I promise (unless you find a bug).

/**
 * Normalize a string path, reducing '..' and '.' parts.
 * When multiple slashes are found, they're replaced by a single one;
 * when the path contains a trailing slash, it is preserved.
 *
 * @param path string path to normalize.
 * @throws {TypeError} if `path` is not a string.
 */
normalize: (path) => {
  assertIsString(path);

  if (path.length === 0) {
    return ".";
  }

  if (path.length === 1) {
    return path;
  }

  const hasTrailingSep = path.charAt(path.length - 1) === posix.sep;
  const absolute = posix.isAbsolute(path);
  const fragments = [];
  let word = "";
  let dots = 0;

  const handleFragment = () => {
    if (dots > 2) {
      fragments.push(Array(dots).fill(".").join(""));
    }

    if (dots === 2) {
      if (fragments.length && fragments[fragments.length - 1] !== "..") {
        // navigate up but don't pop an existing ".."
        fragments.pop();
      } else if (!absolute) {
        // top reached and relative path,
        // absolute path is handled in the if (fragments.length === 0) below
        fragments.push("..");
      }
    }

    if (word.length) {
      fragments.push(word);
    }
  };

  for (let i = 0; i < path.length; i += 1) {
    // duplicated sep, skip
    if (
      path.charAt(i) === posix.sep &&
      i - 1 >= 0 &&
      path.charAt(i - 1) === posix.sep
    ) {
      continue;
    }

    if (path.charAt(i) === ".") {
      dots += 1;
      continue;
    }

    if (path.charAt(i) === posix.sep) {
      handleFragment();

      word = "";
      dots = 0;
      continue;
    }

    word += path.charAt(i);
  }

  handleFragment();

  if (fragments.length === 0) {
    if (absolute) {
      return posix.sep;
    }

    return hasTrailingSep ? "./" : ".";
  }

  let result = fragments.join(posix.sep);
  if (hasTrailingSep) {
    result += posix.sep;
  }

  return result;
},

For comparison, I have found a package that contains the posix-only implementation called path-browserify, which is an extract from Node.js v8.11.1 codebase. This is how that looks like:

// Resolves . and .. elements in a path with directory names
function normalizeStringPosix(path, allowAboveRoot) {
  var res = '';
  var lastSegmentLength = 0;
  var lastSlash = -1;
  var dots = 0;
  var code;
  for (var i = 0; i <= path.length; ++i) {
    if (i < path.length)
      code = path.charCodeAt(i);
    else if (code === 47 /*/*/)
      break;
    else
      code = 47 /*/*/;
    if (code === 47 /*/*/) {
      if (lastSlash === i - 1 || dots === 1) {
        // NOOP
      } else if (lastSlash !== i - 1 && dots === 2) {
        if (res.length < 2 || lastSegmentLength !== 2 || res.charCodeAt(res.length - 1) !== 46 /*.*/ || res.charCodeAt(res.length - 2) !== 46 /*.*/) {
          if (res.length > 2) {
            var lastSlashIndex = res.lastIndexOf('/');
            if (lastSlashIndex !== res.length - 1) {
              if (lastSlashIndex === -1) {
                res = '';
                lastSegmentLength = 0;
              } else {
                res = res.slice(0, lastSlashIndex);
                lastSegmentLength = res.length - 1 - res.lastIndexOf('/');
              }
              lastSlash = i;
              dots = 0;
              continue;
            }
          } else if (res.length === 2 || res.length === 1) {
            res = '';
            lastSegmentLength = 0;
            lastSlash = i;
            dots = 0;
            continue;
          }
        }
        if (allowAboveRoot) {
          if (res.length > 0)
            res += '/..';
          else
            res = '..';
          lastSegmentLength = 2;
        }
      } else {
        if (res.length > 0)
          res += '/' + path.slice(lastSlash + 1, i);
        else
          res = path.slice(lastSlash + 1, i);
        lastSegmentLength = i - lastSlash - 1;
      }
      lastSlash = i;
      dots = 0;
    } else if (code === 46 /*.*/ && dots !== -1) {
      ++dots;
    } else {
      dots = -1;
    }
  }
  return res;
}

//...

function normalize(path) {
  assertPath(path);

  if (path.length === 0) return '.';

  var isAbsolute = path.charCodeAt(0) === 47 /*/*/;
  var trailingSeparator = path.charCodeAt(path.length - 1) === 47 /*/*/;

  // Normalize the path
  path = normalizeStringPosix(path, !isAbsolute);

  if (path.length === 0 && !isAbsolute) path = '.';
  if (path.length > 0 && trailingSeparator) path += '/';

  if (isAbsolute) return '/' + path;
  return path;
},

You can be the judge of which version is easier to grasp.

path.parse(path)

To be continued...

What does code coverage measure?

Elvis Adomnica — Fri, 03 Nov 2023 18:44:22 GMT

import CodeBlock from "../../components/CodeBlock.astro"; export const coverage = [0, 0, 5, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 1]

This week, I was having a conversation with another engineer, and they had an interesting remark. They claimed that devops should have some control over a project pipeline workflow in case we impose a code coverage threshold. Otherwise, "an engineer would be able to just lower it to pass the pipeline". There are a few issues with this claim:

The change to lower the coverage threshold would show in the review, so it is not very easy to sneak it in.
An engineer can do much more damage than cheating the code coverage threshold in an environment governed by mistrust.
If the entire dev team is "evil", even if they don't have control over the config for the threshold, they can still easily cheat the code coverage instead.

What does code coverage measure?

Code coverage measures lines of code executed, not lines of code validated, as we might mistakenly expect. To cheat, one can write some unit tests that are providing just the right input (in order to cover as many lines of code as possible) without any consideration for the results of the code execution. Take the following silly function as an example.

// foo.js
function foo(...args) {
  switch (args.length) {
    case 0:
      throw new Error("Expected at least 1 param");
    case 1:
      throw new Error("Neh, 2 would do");
    case 2:
      return 2;
    case 3:
      return undef.something;

    default:
      return -1;
  }
}

module.exports = foo;

We can easily cover each branch of the switch statement by calling foo with 0, 1, 2, 3, and 4 arguments. We can do this in a simple for loop.

for (let i = 0; i < 5; i++) {
  const args = Array.from(Array(i).keys()); // [0..i]
  foo(...args);
}

Here is how the entire test file looks like. We guarded our function calls in a try/catch, and we are only doing a dummy assertion at the end.

// foo.test.js
const foo = require("./foo");

test("test foo", () => {
  // call test function ignoring its execution
  for (let i = 0; i < 5; i++) {
    try {
      const args = Array.from(Array(i).keys()); // [0..i]
      foo(...args);
    } catch {}
  }

  expect(true).toBeTruthy();
});

To make everyone's life easier, I put all the code together on my GitHub page. After installing the dependencies and running npm run test -- --coverage, we will get a report similar to the one below. We have indeed covered all the branches of the switch statement, while all we asserted is if true is a value that is coerced to true when a boolean is expected.

// foo.js
function foo(...args) {
  switch (args.length) {
    case 0:
      throw new Error("Expected at least 1 param");
    case 1:
      throw new Error("Neh, 2 would do");
    case 2:
      return 2;
    case 3:
      return undef.something;

    default:
      return -1;
  }
}

module.exports = foo;

</CodeBlock>

Nice cheat! We didn't even care that undef.something will throw an Uncaught ReferenceError: undef is not defined exception, all the errors were caught and the test passed.

How does code coverage work?

When we pass --coverage to the test runner (jest in my case), our code is first preprocessed to include some extra code which will do the coverage line counting. Here is how a very simplified version of that would look like.

const cov = Array(18).fill(0);// foo.js
function foo(...args) {
cov[2]++;switch (args.length) {
    case 0:
cov[4]++;throw new Error("Expected at least 1 param");
    case 1:
cov[6]++;throw new Error("Neh, 2 would do");
    case 2:
cov[8]++;return 2;
    case 3:
cov[10]++;return undef.something;

    default:
cov[13]++;return -1;
  }
}

cov[17]++;module.exports = foo;
module.exports.__cov__ = cov;

We can now simulate our test coverage with the same loop we used earlier.

const foo = require("./foo-cov");

for (let i = 0; i < 5; i++) {
  try {
    const args = Array.from(Array(i).keys()); // [0..i]
    foo(...args);
  } catch {}
}

console.log(JSON.stringify(foo.__cov__));

Et voilà, it printed the same array that I've used to configure the code coverage component used earlier in the article.

import CodeBlock from "../../components/CodeBlock.astro";
export const coverage = [0, 0, 5, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 1]

<CodeBlock info={coverage} showLineNumbers={true} print={(d) => `${d}x`}>
```javascript
// foo.js
function foo(...args) {
  switch (args.length) {
    case 0:
      throw new Error("Expected at least 1 param");
    case 1:
      throw new Error("Neh, 2 would do");
    case 2:
      return 2;
    case 3:
      return undef.something;

    default:
      return -1;
  }
}

module.exports = foo;
```
</CodeBlock>

Is code coverage useless then?

No, it is not. Code coverage is a great tool to help you understand how well you are doing on testing. But, like with any type of measurements, you should take its results with a grain of salt. For instance, snapshot testing could lead to false positives in terms of line of code covered but not properly verified. Also, imposing a ridiculous threshold (like 98% coverage) will cause more damage that it will help. Developers will have to start exposing aspects of the code that were supposed to be encapsulated, just for the sake of reaching the necessary mark needed for the pipeline to pass.

Simple fetch limiter (Part 2)

Elvis Adomnica — Thu, 19 Oct 2023 16:28:08 GMT

It is very possible that you had such a reaction while reading my previous post, especially at the part where I mentioned that moving the delay to the bottom of the loop was a mistake. The move at the bottom was an attempt to address an issue that becomes obvious when using large values for the loop interval, e.g., 30 seconds.

const limiter = new HTTPLimiter({
  intervalMilliseconds: 30_000,
  requestsPerInterval: 2,
});

console.log("start");
for (let i = 10; i; i--) {
  limiter
    .fetch(`https://jsonplaceholder.typicode.com/todos/${i}`)
    .then((response) => response.json())
    .then((json) => console.log(json));
}

We'll see start being printed in the console, and only after the 30 seconds delay (sleep), we will see the requests being fired, and the responses being printed as well. Let's move it back to the bottom of the loop.

async #loop() {
  while (true) {
    const entities = this.#queue.splice(0, this.#options.requestsPerInterval);
    if (!entities.length) break;

    for (const entity of entities) {
      fetch(entity.input, entity.init)
        .then(entity.resolve)
        .catch(entity.reject);
    }

    await delay(this.#options.intervalMilliseconds);
  }
}

We are now back at the issue that all the items are being consumed immediately. Go back to the previous article for an explanation why that happens. In any case, the fix is easy. All we have to do is to allow "the producer" (the main thread) to produce all the requests it needs. For instance, allow our todos fetch loop to finish iterating over all the requests. We can easily achieve this by deferring the start of processing the items to the next event loop cycle using setTimeout.

fetch(input: FetchInput, init?: RequestInit): Promise<Response> {
  const promise = new Promise<Response>((resolve, reject) => {
    this.#queue.push({
      input,
      init,
      resolve,
      reject,
    });
  });

  if (this.#queue.length === 1) setTimeout(() => this.#loop(), 0);

  return promise;
}

Now everything works as expected, and the code remained simple.

Simple way to rate limit your fetch requests

Elvis Adomnica — Tue, 17 Oct 2023 08:41:52 GMT

A few weeks ago, my colleagues at SprintEins shared an article describing a solution for rate limiting fetch requests in the Deno to avoid reaching an API rate limit. I used to write similar code in the past, so this really caught my attention.

Original implementation

The original implementation described in the first part of the artile series proposes an initial "not production ready" solution:

import { delay } from "https://deno.land/std@0.202.0/async/delay.ts";

interface IMyRequest {
  url: string;
  resolve: (value: Response | Error) => void;
}

const queue: IMyRequest[] = [];

const myFetch = (url: string) => {
  const promise = new Promise((resolve) => {
    queue.push({
      url,
      resolve,
    });
  });

  return promise;
};

const loop = async (interval: number) => {
  while (true) {
    await delay(interval);
    const req = queue.shift();
    if (!req) continue;

    try {
      const response = await fetch(req.url);
      req.resolve(response);
    } catch (error) {
      req.resolve(error);
    }
  }
};

The self criticism the author brings, and the reason they call it "not production code", is that the code doesn't respect the fetch interface. However, the version from Github linked in the second article fixes this by pushing FetchInput and RequestInit parameters into the queue:

fetch(input: FetchInput, init?: RequestInit): Promise<Response> {
  let promise = undefined as unknown as Promise<Response>;

  promise = new Promise((resolve, reject) => {
    this.#queue.push({
      promise,
      input,
      init,
      resolve,
      reject,
    });
  });

  if (this.#queue.length === 1) this.#loop();

  return promise;
}

After a quick glance at the entire code, one can notice that the promise field of the IRequestEntity is never used, so fetch could be simplified to:

fetch(input: FetchInput, init?: RequestInit): Promise<Response> {
  const promise = new Promise((resolve, reject) => {
    this.#queue.push({
      input,
      init,
      resolve,
      reject,
    });
  });

  if (this.#queue.length === 1) this.#loop();

  return promise;
}

The private #loop method has also been slightly changed from its original proposal:

async #loop() {
  while (true) {
    const entity = this.#queue.shift();
    if (!entity) break;

    try {
      const response = await fetch(entity.input, entity.init);
      entity.resolve(response);
    } catch (error) {
      entity.reject(error);
    }

    await delay(this.#options.interval);
  }
}

Moving the delay at the end of the #loop method is actually a mistake. The following code executes the fetch requests immediately:

const limiter = new HTTPLimiter({
  interval: 1000,
});

for (let i = 10; i--; ) {
  console.log(i);
  await limiter.fetch(`https://jsonplaceholder.typicode.com/todos/${i}`);
}

This is because, as soon as we push the item into the queue, this.#queue.length === 1 is true, and we invoke the #loop method. We then pop the item from the queue and we proceed with the request. Processing the item immediately means that this.#queue.length === 1 is true for every limiter.fetch call, thus creating a new while(true) loop each time. Each of these loops will then wait for the delay and will be interrupted in the next cycle due to the if (!entity) break; statement. Moving back the delay function at the beginning of the while loop will block it for at least 1 second before it continues with processing the items. This behavior is closer to what we need. If we remove the await in front of the limiter.fetch call, we will notice that all requests get queued and then processed one-by-one with 1 second delay between them.

Extended version

The second part of the series goes in a direction I don't quite agree with. Instead, I would rename the interval option to intervalMilliseconds, add a new option called requestsPerInterval, and update the logic correspondingly. Here is the entire HTTPLimiter.ts:

import { delay } from "../deps.ts";

interface IRequestEntity {
  init?: RequestInit;
  input: FetchInput;
  resolve: (value: Response) => void;
  reject: (value: Error) => void;
}

interface IHTTPLimiterOptions {
  intervalMilliseconds: number;
  requestsPerInterval: number;
}

type FetchInput = URL | Request | string;

export class HTTPLimiter {
  #options: IHTTPLimiterOptions = {
    intervalMilliseconds: 0,
    requestsPerInterval: 0,
  };

  #queue: IRequestEntity[] = [];

  constructor(options?: Partial<IHTTPLimiterOptions>) {
    if (options) {
      for (const [key, value] of Object.entries(options)) {
        // @ts-ignore
        if (key in this.#options) this.#options[key] = value;
      }
    }
  }

  async #loop() {
    while (true) {
      await delay(this.#options.intervalMilliseconds);
      const entities = this.#queue.splice(0, this.#options.requestsPerInterval);
      if (!entities.length) break;

      for (const entity of entities) {
        try {
          const response = await fetch(entity.input, entity.init);
          entity.resolve(response);
        } catch (error) {
          entity.reject(error);
        }
      }
    }
  }

  fetch(input: FetchInput, init?: RequestInit): Promise<Response> {
    const promise = new Promise<Response>((resolve, reject) => {
      this.#queue.push({
        input,
        init,
        resolve,
        reject,
      });
    });

    if (this.#queue.length === 1) this.#loop();

    return promise;
  }
}

and an example how to test it:

import { HTTPLimiter } from "./src/HTTPLimiter.ts";

const limiter = new HTTPLimiter({
  intervalMilliseconds: 1000,
  requestsPerInterval: 2,
});

for (let i = 10; i; i--) {
  limiter
    .fetch(`https://jsonplaceholder.typicode.com/todos/${i}`)
    .then((response) => response.json())
    .then((json) => console.log(json));
}

If we are executing the code above, we will notice that only two requests are being fired every second, until all 10 requests are done. We still have a problem though. As pointed out in the series, our fetch requests are being executed sequentially. To better visualize this, we can use the following example code:

import { HTTPLimiter } from "./src/HTTPLimiter.ts";

const limiter = new HTTPLimiter({
  intervalMilliseconds: 1000,
  requestsPerInterval: 2,
});

let lastTime = new Date().getTime();
let totalTime = 0;

for (let i = 10; i; i--) {
  limiter
    .fetch(`https://jsonplaceholder.typicode.com/todos/${i}`)
    .then((response) => response.json())
    .then((json) => {
      const now = new Date().getTime();
      const delta = now - lastTime;
      totalTime += delta;

      console.log(totalTime, delta, json);

      lastTime = now;
    });
}

and, we can also mock the global fetch to control the time it takes to resolve a request:

const fetch = (input, _) =>
  new Promise<Response>((resolve) =>
    setTimeout(() => {
      const response = {
        json: () => new Promise<Response>((res) => res({ input } as any)),
      } as Response;

      resolve(response);
    }, 300)
  );

The code returns a Promise that looks like a Response (has a json method which returns a Promise) and resolves after 300ms. Running it should output something similar to:

$ deno run --allow-net example.ts
1306 1306 { input: "https://jsonplaceholder.typicode.com/todos/10" }
1607 301 { input: "https://jsonplaceholder.typicode.com/todos/9" }
2910 1303 { input: "https://jsonplaceholder.typicode.com/todos/8" }
3211 301 { input: "https://jsonplaceholder.typicode.com/todos/7" }
4514 1303 { input: "https://jsonplaceholder.typicode.com/todos/6" }
4816 302 { input: "https://jsonplaceholder.typicode.com/todos/5" }
6119 1303 { input: "https://jsonplaceholder.typicode.com/todos/4" }
6420 301 { input: "https://jsonplaceholder.typicode.com/todos/3" }
7724 1304 { input: "https://jsonplaceholder.typicode.com/todos/2" }
8026 302 { input: "https://jsonplaceholder.typicode.com/todos/1" }

That's around 8 seconds instead of around 5. Not good. Let's now fix this by making our loop run the requests in parallel:

async #loop() {
  while (true) {
    await delay(this.#options.intervalMilliseconds);
    const entities = this.#queue.splice(0, this.#options.requestsPerInterval);
    if (!entities.length) break;

    for (const entity of entities) {
      fetch(entity.input, entity.init)
        .then(entity.resolve)
        .catch(entity.reject);
    }
  }
}

Indeed, this solution yields the desired results, as you can see below.

$ deno run --allow-net example.ts
1307 1307 { input: "https://jsonplaceholder.typicode.com/todos/10" }
1315 8 { input: "https://jsonplaceholder.typicode.com/todos/9" }
2308 993 { input: "https://jsonplaceholder.typicode.com/todos/8" }
2309 1 { input: "https://jsonplaceholder.typicode.com/todos/7" }
3310 1001 { input: "https://jsonplaceholder.typicode.com/todos/6" }
3311 1 { input: "https://jsonplaceholder.typicode.com/todos/5" }
4312 1001 { input: "https://jsonplaceholder.typicode.com/todos/4" }
4313 1 { input: "https://jsonplaceholder.typicode.com/todos/3" }
5314 1001 { input: "https://jsonplaceholder.typicode.com/todos/2" }
5315 1 { input: "https://jsonplaceholder.typicode.com/todos/1" }

Yey, we managed to reached our goal of having a fully functional API-rate-limiter implementation with just a few simple changes to the original code!

Social media cleansing

Elvis Adomnica — Fri, 16 Dec 2022 16:18:58 GMT

I remember the early days of social media interaction when I would got to an internet cafe just to have a chat on mIRC with someone from my community. If I was lucky, I would even get to have a blind date. Those years seem like ages ago and a lot has changed, gone are the days of mIRC, HI5, MySpace, and Yahoo Messenger.

I've never been a big fan of Twitter so my social media activity revolved around Facebook, Facebook Messenger and Instagram. With Instagram I had a somehow healthy relationship. Since I have joined the platform back in 2016, I have decided to only post pictures that have a meaningful story behind them. That usually meant I will only post a few times a year. But still, here I was checking the app multiple times a day and knowing almost all the stories posted by the people I follow. Not the best use of my time and a somehow addictive behavior.

This year, on the other hand, has been a time for change and part of it has been tying to disconnect from all the noise and distractions that consume my time. In June I have deleted Facebook and Facebook Messenger, and this month I have deleted my main Instagram account (I still have an "arty" one). In the beginning I felt like a void, like something was missing. But after a while that void feels like a relief. I get more time to focus on the things that matter and have meaningful the conversations I so much enjoy. I totally recommend it :-)

Hello, World!

Elvis Adomnica — Wed, 14 Dec 2022 20:17:09 GMT

This is my first blog post!