DEV Community: Michal Král

A little tool for watching algorithms run

Michal Král — Wed, 17 Jun 2026 14:19:24 +0000

I've always found algorithms easier to understand once I can see them move. Pseudocode and textbook diagrams are fine, but for a lot of things — how a sort actually rearranges elements, why Dijkstra picks the path it does — a static picture only gets me so far. I usually end up tracing through it by hand on paper.

So I made a small thing to do that tracing for me: bigoh.dev. It's free, open, and meant for learning. Sharing it here in case it's useful to anyone else who thinks the same way.

What it does

You pick an algorithm or data structure, edit the input, and press play. It runs step by step on a canvas. Below the animation there's a short description of what's happening at the current step, and the pseudocode with the active line highlighted. You can step forward and back, or scrub a timeline to jump around. That's basically it.

A few of the visualizations are interactive in a way that helps: on graphs you click to add nodes and edges, on grids you click to toggle walls, and on the geometry plane you click to drop points. Then you watch the algorithm run on the thing you just drew.

What's covered

There are around 67 visualizations right now, grouped roughly like this:

Sorting — bubble, quick, merge, heap, counting, radix, and the usual rest.
Searching — binary, jump, interpolation.
Data structures — stack, queue, deque, linked list, hash table, BST, heap.
Trees & graphs — traversals, BFS, DFS, Dijkstra, Bellman-Ford, MST (Prim, Kruskal, Borůvka), topological sort, connected components, cycle detection, bipartite check, Floyd-Warshall.
Pathfinding & mazes — BFS, A*, greedy best-first, Dijkstra on weighted terrain, bidirectional search, plus maze generation (recursive backtracker, Prim, Wilson).
Dynamic programming — edit distance, LCS, coin change, subset sum, knapsack (0/1 and unbounded), partition, Kadane, LIS, Fibonacci.
And I try to expand the list

One example

The pathfinding ones are where seeing it move helped me most. Run plain BFS on a grid and it spreads out evenly in all directions, like a flood — it has no idea where the goal is. Switch to A* on the same grid and the explored area visibly leans toward the target, because it's using a heuristic to guess which direction is worth checking first. Watching the two side by side made the difference click for me in a way that "A* is informed search" never did.

Dijkstra on weighted terrain is similar: you can watch it deliberately detour around the expensive squares instead of just taking the straight line, and suddenly the cost function isn't abstract anymore.

On the tech

For the developers here: it's built with Vue 3, with the visualizations drawn on canvas using Konva. Each algorithm produces a list of steps up front, and the player just renders whichever step you're on — which is what makes stepping back and scrubbing work. The pages are statically prerendered so they load quickly and are reasonably friendly to search engines.

That's it

It's a hobby project and still growing, so there are rough edges and gaps. If you try it and something is confusing, broken, or just missing an algorithm you wanted to see, I'd genuinely like to hear about it — suggestions for what to add next are very welcome.

Here it is: bigoh.dev. Thanks for reading.

I love MJML — I just didn't want a whole templating engine for two tiny things

Michal Král — Wed, 27 May 2026 11:19:34 +0000

I love MJML.

Responsive HTML email is one of the genuinely miserable corners of frontend — nested tables, <!--[if mso]> incantations, clients from 2007 that still get a vote. MJML takes all of that and lets me write semantic-ish components (<mj-section>, <mj-column>, <mj-button>) that compile down to email HTML that actually renders everywhere. It's one of those tools that makes a horrible problem boring, which is the highest compliment I can give a library.

So I was happy. Except for one thing.

The one thing I was missing

My templates needed two unglamorous things:

Variables — drop a name, a URL, an order number into the email.
Translations — the same template in en, cs, whatever.

MJML doesn't do either, and fair enough — it's a markup compiler, not a template engine. So like a lot of people, I reached for the template engine I already had and ran my .mjml files through Twig first, just to get this:

<mj-text>{{ 'welcome.hello'|trans({'%name%': name}) }}</mj-text>

And it worked. But look at what that actually is: I'm spinning up an entire templating engine — with loops, conditionals, filters, its own parsing pass — to do string interpolation and a dictionary lookup. Two compile steps (Twig → MJML) for what should be one. A second syntax in my files. And every time I touched a template I had to keep two mental models in sync.

I didn't want a template engine in my email pipeline. I wanted those two tiny things — and nothing else.

What I actually wanted

Co-located translations, vue-i18n style — the strings living right next to the markup that uses them — plus dead-simple variable access. Something like:

<mjml>
  <i18n type="json">
    {
      "en": { "hello": "Hello {name}!", "cta": "Shop now" },
      "cs": { "hello": "Ahoj {name}!", "cta": "Nakupovat" }
    }
  </i18n>

  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>{{ i18n('hello', { name: get('firstName') }) }}</mj-text>
        <mj-button href="{{ get('url') }}">{{ i18n('cta') }}</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

No second template language. No second compile. Just i18n() and get().

So I built it: @checkthiscloud/mjml-i18n.

Using it

It's a single MJML preprocessor:

import mjml from 'mjml';
import { createI18nPreprocessor } from '@checkthiscloud/mjml-i18n';

const preprocessor = createI18nPreprocessor({
  locale: 'cs',
  vars: { firstName: 'Ada', url: 'https://example.com' },
});

const { html } = await mjml(template, { preprocessors: [preprocessor] });

That's the whole integration. One preprocessor in, fully resolved email HTML out.

How it works (and what it deliberately doesn't do)

The trick is that it runs as an MJML preprocessor — it resolves the {{ … }} markers on the raw XML, before MJML parses it. Two nice consequences:

Markers work anywhere, including inside attributes (href="{{ get('url') }}"), not just text nodes.
It composes with MJML instead of fighting it.

Inside each {{ … }} is a single function-call expression, evaluated by a tiny allowlist (built on jsep). Only literals, object arguments, and the registered functions (i18n, get) are allowed. You can nest them — i18n('hello', { name: get('firstName') }) — and that's it.

What it is not is a template engine. No loops, no conditionals, no arbitrary expressions, no eval. If a marker isn't a recognized call, it's left untouched rather than executed. That constraint is the whole point: I wanted the two things I was missing, not a Turing-complete language living in my emails.

Translations fall back gracefully (missing key → the key, missing variable → an obvious placeholder), so a typo degrades instead of exploding mid-render.

Status

It's young — 0.x, MIT, built for MJML v5 — but small and focused, and it does exactly what it says. Params are currently plain {name} substitution (no ICU plurals yet, though the seam is there if that day comes). If you live in MJML and you've been bolting a template engine onto it just for translations, give it a spin and tell me where it breaks.

npm install @checkthiscloud/mjml-i18n mjml

Sometimes the feature you want isn't "more" — it's exactly two small things and nothing else.

Generate Human-Friendly Random Codes in PHP with Crockford’s Base32

Michal Král — Tue, 30 Sep 2025 18:24:28 +0000

Generating random codes sounds easy — until real people have to read, type, or say them out loud. Suddenly O looks like 0, l looks like 1, and half your support tickets are about users mistyping their coupon or entry code.

To solve this, I built a small PHP library that generates human-friendly random strings using Crockford’s Base32 alphabet. It’s perfect for things like coupon codes, ticket entry codes, invite tokens, or any other short identifiers where clarity matters just as much as randomness.

👉 GitHub repo: CheckThisCloud/CrockfordRandom

Why Crockford’s Base32?

When generating codes for humans to type in or read back, you don’t want people misreading O as 0 or l as 1.

Crockford’s alphabet solves this by removing ambiguous characters while keeping the string compact and case-insensitive.

Features

Generate random strings of any length.
Ideal for human-facing codes: tickets, coupons, invites, promo codes.
Output uses only unambiguous characters.
Built on PHP’s modern Random\Randomizer class.
Tiny footprint — easy to drop into any project.

Example usage

use CheckThisCloud\CrockfordRandom\CrockfordRandom;

$random = new CrockfordRandom();
echo $random->string(10); 
// Example output: 9XF7T2K4HZ

Bonus: SillyNames 🎉

I’ve also built another micro-library: [CheckThisCloud/SillyNames]((https://github.com/CheckThisCloud/SillyNames)
.
It generates random two-word names in the style of Docker container names (e.g. brave_panda, sleepy_hedgehog).
Useful for test data, logs, or giving projects some personality.

Feedback is very welcome 🙏