• Their mobile app somehow lost my account. That sucks.
• I still know the password, I can’t log in without going through a recovery process.
• Their recovery process requires access to my old SIM card.
• Luckily I have it and got the SMS
• Then it asked for a PIN. I don’t have one. I assume they introduced PINs after I set up my 2FA account. Fine, I can skip this step.
• Next, I had to answer a default security question like “What’s the name of the street …”. I know the answer, but I don’t know whether it’s case-sensitive.
• Anyway,The system refuses to accept any of my attempts.
• Now I have to go through a long process of convincing their security team that it’s actually me.
• I’m not sure it’ll work out. I hope as the last hope I’ll be able to send them my passport data

So, why do I hate 2FA? Because it’s supposed to be a security measure. But instead it’s almost always a suffering measure.

Now that your component’s code loads on demand, you also need to specify what should be displayed while it is loading. You can do this by wrapping the lazy component or any of its parents into a boundary

• Lazy - React

“Need to”? Or “must to”?

If you try to use lazy without <Suspense/> it… It works. Wow. So, is it optional?

HELL NO! You must wrap your lazy components with <Suspense/>.

Why? Because such non-connected components can put React’s reconciliation engine into a semi-broken, hung state where behavior becomes unpredictable. It gets auto-healed only when the lazy promise is fulfilled.

So, if you don’t want to play hide & seek in a mine field — do it. Wrap it with <Suspense/> even if you don’t plan to render any fallback JSX.

<math>
  <mrow>
    <mi>a</mi>
    <mo>=</mo>
    <mfrac>
      <mrow>
        <mo>-</mo>
        <mi>b</mi>
        <mo>±</mo>
        <msqrt>
          <msup><mi>b</mi><mn>2</mn></msup>
          <mo>-</mo>
          <mn>4</mn><mi>a</mi><mi>c</mi>
        </msqrt>
      </mrow>
      <mrow><mn>2</mn><mi>a</mi></mrow>
    </mfrac>
  </mrow>
</math>

^ It’s a valid HTML code. It renders this way:

No 3rd party libs needed.

type Fn = <T>(a: T) => T;
declare const fn: Fn;

const a = fn<number>; // no "()"
a; // const a: (a: number) => number

It was on the surface all along, but it eluded me.

• Pure functions cannot use variables. Only constants.
• Pure functions cannot run impure functions. Only pure.

These statements make some point. But they are not entirely true. Let me clarify this. The only restrictions that pure functions have are:

• It must be deterministic, meaning it doesn’t have random behavior. No matter how many times you run it with the same set of arguments — you’ll get the same result.
• It shouldn’t have any side effects.

What is a side effect? Basically, it’s any change in the world outside of the function. E.g.:

• Changing the given argument
• Changing a variable defined outside of the function
• Mutating any value reachable from outside the function (including parameters) or any value that escapes the function
• Making a query (database, network, etc.)
• Reading a file, writing to a file, removing a file, etc.
• Reading external mutable data
• etc.

I think you got the concept. Now let’s focus on the word “side” in “side effects”. “Side” means it’s outside of the given function. We don’t have these restrictions for internal state. Yep, a pure function may have mutable internal state.

function pure(a: number, b: number): number {
  let c = a ** b;
  if (c > 100) c %= 100;
  return c - 14;
}

^ this one is pure, even though it mutates c. Just because c is internal to the function — it doesn’t affect or depend on anything outside. We don’t mutate it after we return the value.

Ok, what about running impure functions? It’s a dangerous zone. Because it is very dependent on how exactly impure the impure function. If it’s not deterministic, then we have no chance. So the question is about: what side effects an impure function may have while still allowing us to use it inside a pure function? The answer is: the only side effect it may have is mutating the given arguments (only if they are local to the pure function):

function impure(packet: Packet): void {
  // deterministic and based only on packet
  packet.hash = computeHash(packet); 
}

function pure(id: number, data: Data): Packet {
  const packet: Packet = { id, data };
  impure(packet);
  return packet;
}

Here we clearly run impure in pure. But since impure changes only packet, which is entirely managed by pure, we’re safe.

That’s it.

Read more

<div>
  <br/>
  <br/>
</div>

Then you want to find all its <br/>s:

const collection  = $0.getElementsByTagName('br');

Thus far, everything is obvious, right? Ok, let’s add one more <br/>:

$0.append(document.createElement('br'));

So, now have three of them. Let’s read the same collection element again:

Whoa… It was updated too. Why? HTMLCollection is a “live” collection:

An HTMLCollection in the HTML DOM is live; it is automatically updated when the underlying document is changed. For this reason it is a good idea to make a copy (e.g., using Array.from) to iterate over if adding, moving, or removing nodes.

• Mozilla

.link:hover {
  filter: brightness(1.5);
}

… worked perfectly on a colored icon but had no effect on a text label. It turned out that the label used the color #000. brightness() is a purely mathematical function that multiplies the R, G, and B values by the given factor. This makes no difference for pure black, since 0 * anything = 0.

Many years ago, people just did this:

<input autocomplete="off"

Now it doesn’t work. These extensions don’t respect this attribute. You might have seen this one:

<input data-lpignore="true"

It doesn’t work either (at least not with KeePass)

I came up with a simple and pretty silly solution:

<input type="text" onfocus="event.target.type='password'"

And it works ;-) The extensions don’t care about text-inputs. And they are not smart enough to detect new controls. At least for now.

upd: It helped with KeePass, but didn’t work out with 1Password.

In June, I started learning Rust. Why? Just out of curiosity. A system-level language with a lot of syntax sugar, new patterns, and approaches. So, I started with the Rust Book, got through half of it, and decided to build something real.

My previous blog was made with PHP 5.5 more than ~8 years ago. It wasn’t bad, but I completely quit PHP. I didn’t want to touch that old codebase. So I came to the conclusion: why not write a new one, this time in Rust?

Here it is. You’re welcome ;)

AI

I didn’t want to vibe-code it. However, I didn’t want to face all the obstacles by myself. So I used ChatGPT a lot, for almost every aspect of the development. I turned off Copilot and didn’t use Cursor. Because I wanted to write the blog “myself”. To feel it. At least in some merit. GTP was always in a separate browser tab. More like a helper, not an author.

Rust. First impression

Rust is wonderful, but it’s a system-level language. I had no real experience in this area before. Just a few simple C++ LeetCode problems, which gave me no real C++ knowledge. So it was a real challenge. But I wasn’t completely unarmed. I still remembered something about pointers, the heap, allocation, and other important system-level stuff. Though it was purely theoretical in my mind.

Read more

Launches are after the break

Read more

Apotre ➔ Sisteron ➔ Laragne-Montéglin

Three more videos are after the break

• Chabre ➞ Montmaur
• Aspres → Pic de Bure → Gap
• Sailplane flight. Aérodrome de Serres

Read more

  const a = () => {};
  a.toString(); // () => {}
  console.log.toString(); // function log() { [native code] }

You see? [native code] label. Sounds good, right?

  const a = () => {};
  const b = a.bind(null);
  b.toString(); // function () { [native code] }

Oops. But we still have this log name in the string snapshot.

So I ran webpack-dev-analyzer and found a weird thing: the sum of the libs is 3 times smaller than the final bundle size. Then I decided to take a look at @statoscope/webpack-plugin. It was a good tool but it gave me the same result. The bundle has way too much trash.

Ok. Probably it’s just webpack wrappers over 300+ small modules. %cut% So I asked Perplexity - what can I do with it? Turned out all the proper options were already activated. So, I made a decision - it’s time to try esbuild. It made a huge impact on my work project, so I knew it could work out.

I knew that esbuild didn’t support a lot of stuff that babel supports. So I expected that it would take a day to migrate the codebase to esbuild. But surprisingly once I replaced babel-loader with esbuild-loader the build command worked out. The build didn’t work but the bundle was assembled without any errors.

Did it help? Nope. Instead of 780 KiB, I got ~1 MiB. Luckily I found out that there’s also EsbuildPlugin, which replaces TerserPlugin and works better. Added this line, it worked like a charm, and… Whoa! 280 KiB. That’s huuuge.

So I figured out - it worked. Now I have to find a way to fix the app (spoiler: it didn’t work at all).

Implicit React imports

React 17+ supports the possibility of avoiding adding import React from ‘react’ to every TSX-file. esbuild supports it too, but somehow it didn’t work out of the box. Solution:

  const esbuildLoader: RuleSetRule = {
    test: /\.(js|ts|tsx)$/,
    loader: 'esbuild-loader',
    exclude: /node_modules/,
    options: {
       target: 'es2020',
       minify: cfg.PROD,
+      // Support implicit React imports:
+      jsx: 'automatic',
+      jsxFactory: 'React.createElement',
+      jsxImportSource: 'react',
    } satisfies LoaderOptions,
  };

TSX-Control-Statements

I just removed the packages and all their <If/>s. I liked them though. There’s a plugin for Vite that adds their support. But I still use Webpack and the plugin works via string replacements, not via AST.

SourceMaps

To enable sourcemaps I had to disable EsbuildPlugin for development. Theoretically, it supports sourcemaps, but no matter what I did it didn’t work. I even debugged the package itself. Didn’t help. So I surrendered and enabled it only for the prod build.

TypeScript

EsBuild supports TypeScript syntax out of the box but it doesn’t check types. So it builds extremely fast but I need to know my errors. Solution:

  webpackConfig.plugins!.push(
    new ForkTsCheckerWebpackPlugin({
      typescript: {
        configFile: cfg.paths.TS_CONFIG,
      },
    })
  );

How does it work? The build and the type-checking processes are run in parallel. The 2nd doesn’t linger the 1st. You still can see the errors in the browser (and CLI) console. And visually too. Nice.

ES-Lint

For some reason, it stopped working. The solution was pretty simple:

  webpackConfig.plugins!.push(
    new ESLintPlugin({
      extensions: ['ts', 'tsx'],

Final results

• File sizes
  • Before: 641 KiB + 234 KiB + 29.5 KiB (css) = 904.5 KiB
  • After: 221 KiB + 55 KiB + 8.1 KiB (o_O, css) = 284.1 KiB
  • After minifyIdentifiers: true (scary thing) & minifyWhitespace: true: 138 KiB + 44.2 KiB + 8.1 KiB = 190.1 KiB
• DOMContentLoaded:
  • Before: 737ms
  • After: 231ms
  • After-2: 131ms
• Build time: esbuild was ~3x faster

Afterthought

Taking a deeper look I found:

• The main issue wasn’t in babel. The main issue was that I used inline-source-map for prod. I didn’t want to do it. Just a mistake. And both bundle analyzers didn’t notice that. Even when I manually looked at the file I barely found it (the horisontal scroll was too big). Fixing this issue dropped the file size 3x times even with babel.
• esbuild has a better wrapper logic for a ton of tiny files than babel does.
• Whitespace minification is quite important. GZip doesn’t eliminate the difference.
• Name mangling is a beast. But be careful, it can easily break your app in runtime.

Read more

One more video is after the break (Aspres, France)

Read more

Two more videos are after the break:

• Kössen
• Ruhpolding, Unternberg

Read more

• Create tsconfig.json at the root level. Content:

  {
    "compilerOptions": {
      "module": "CommonJS",
      "target": "ES5",
      "esModuleInterop": true,
      "checkJs": false,
      "strict": true,
    }
  }
  

• Rename all *.js files to *.ts
• Type all of them:
  • no more ugly require, use import.
  • webpack package has typings out of the box.
    • You may find these types useful: Configuration & RuleSetRule
    • To enable devServer write this: 

      interface Configuration extends WebpackConfiguration {
        devServer?: WebpackDevServerConfiguration;
      }
      

  • Some of the popular plugins have types too.
  • Some of them don’t have types at all:
    • Create a *.d.ts file
    • Put there something like this:

      declare module 'postcss-assets' {
        export default function postcssAssets(opts: {
          basePath: string;
          relative: boolean;
        }): unknown;
      }
      

• Make sure your webpack.config.ts file is placed at the root level. I mean exactly at the same spot where node_modules is. Otherwise, you won’t be able to build it. No compilerOptions helped me. 
• Run webpack. It should work.

[Unit]
Description={name}

[Service]
Type=simple
User={user}
ExecStart=/usr/bin/node {full-path-to-script}.js

[Install]
WantedBy=multi-user.target

… somewhere as {name}.service, where:

• {name} is the name of the service
• {user} is the name of the user to run the script (optional)

… then:

• run: this sudo ln -s /{full_path}/{name}.service /lib/systemd/system/{name}.service 
• then this: sudo systemctl daemon-reload
• then this: sudo systemctl enable {name}.service
• and finally this: sudo systemctl start {name}

How does it work?

• It starts the service on boot (see WantedBy section).
• Using ExecStart command. Important: we specify the full path to node
• SystemD remembers the PID of the new process and considers the service is ongoing until the process is died.
• So any subsequent systemctrl start {name} won’t do anything if the previous process is alive.
• This behavior is determined by Type=Simple

One more video (with my launches) is after the break

Read more

CMD or Ctrl?

At first look at Ctrl. Probably on MacOS you’d like to replace it with CMD.  You can check it by event.metaKey.

Extra modificators

Probably you wouldn’t like to consider Ctrl+Alt+S as Ctrl+S. So don’t forget to handle this case.

Different layouts

Not every language that uses the Latin alphabet has the L button at the same position as in a typical English keyboard layout. You need to decide what is more important to you ― a real key position on a keyboard or a letter upon of it. I’d guess that the 2nd case is preferable for most applications. 

To get a real key position you can use which, code, codeKey properties. To get a letter on the key use key property.

Different alphabets

What’s about Greek or Russian alphabets? Or any other possible alphabets? Or not even alphabets? There’re different strategies. And one of them is to use a key from a typical English keyboard layout. So it leads us again to code and codeKey properties.

Example

const getEventKeyBind = event => {
  const keybind = [];

  if (event.metaKey) keybind.push('cmd');
  if (event.ctrlKey) keybind.push('ctrl');
  if (event.shiftKey) keybind.push('shift');
  if (event.altKey) keybind.push('alt');

  if (event.key === ' ') keybind.push('space');
  else {
    const key = event.key.toLowerCase();

    if (key.length !== 1 || key.match(/^[a-z]$/)) {
      // latin key or a special key
      keybind.push(key);
    } else {
      // extra-latin or non-latin key
      const [, enSymbol] = event.code.match(/^Key(\w)$/) || [];
      keybind.push(enSymbol ? enSymbol.toLowerCase() : key);
    }
  }

  return keybind.join('+');
};