DEV Community: Christoph Dieck

astro-gallery: four image gallery components for Astro

Christoph Dieck — Mon, 31 Aug 2026 11:42:51 +0000

Every time I write a post with photos in it, I need a gallery. The dog post needed one. The paving post needed three. I kept copying the same Astro component from post to post, tweaking it slightly each time, and the copies slowly drifted apart.

So I did the sensible thing and turned it into a package. It is called astro-gallery, it is on npm, and my blog now runs on it.

What astro-gallery is

astro-gallery is a set of four gallery components for Astro. You point a component at a folder in src/, drop your photos in, and it handles the rest: image optimisation through astro:assets, responsive srcset, a lightbox, EXIF reading at build time, and structured data. No client framework, no config file, one integration.

The four components:

Component	What it does
`JustifiedGallery`	Aspect-ratio-aware rows that fill the width edge to edge. Nothing gets cropped to a grid cell.
`ImageGallery`	A uniform responsive grid. Click a thumbnail, get a lightbox with arrow-key navigation.
`ImageTimeline`	Reads each photo's EXIF capture date, groups by day, lays the days out on a timeline. Horizontal rail or vertical spine.
`MapGallery`	Reads GPS EXIF and drops a photo marker per location on a Leaflet map. Ships a consent gate so no tile request happens before the visitor agrees.

The photos in the examples below are real. A hiking trip in the Harz, a few days on Rügen, and some odds and ends from around Hamburg. All of them live in one folder, src/assets/images/demo/, and every example reads from that same folder.

Setup

Install the package and add the integration.

npm install astro-gallery

// astro.config.mjs
import { defineConfig } from 'astro/config';
import gallery from 'astro-gallery';

export default defineConfig({
  integrations: [
    gallery({
      locale: 'en-GB',
      // pick a basemap for MapGallery. 'osm' is keyless.
      map: { basemap: 'osm' },
    }),
  ],
});

The integration exposes its resolved config to the components through a virtual module. The components will not render without it, so this step is not optional.

Then import a component in any .astro or .mdx file and give it a folder:

---
import JustifiedGallery from 'astro-gallery/components/JustifiedGallery.astro';
---
<JustifiedGallery folderPath="demo" album="Trips 2025 and 2026" />

JustifiedGallery

This is the one I reach for first. Rows are justified to the container width using each photo's aspect ratio, so a landscape shot takes more horizontal space than a portrait, and nothing is cropped to fit a box. It is the layout you know from Flickr, Unsplash and the Lightroom web galleries.

It is built for Core Web Vitals. Every image carries its intrinsic width and height so there is zero layout shift, offscreen rows use content-visibility to skip rendering work, and the first couple of images load eagerly with fetchpriority="high". The rest lazy load. There is a blur-up skeleton while each image decodes.

The alt prop is a map of file name to alt text. You only fill in the ones that matter. For the rest, the component builds an alt string from the file name or from an embedded IPTC caption if the photo has one. More on that below.

ImageGallery

Same photos, uniform grid. Every cell is identical, so each image is cropped with object-fit: cover to fill it. Use this when your photos are roughly the same shape, or when the gallery is really just navigation and you want it tidy.

It also takes an explicit images array if you would rather list imported images, /public paths or remote URLs by hand, with per-image alt and caption. That is the mode the older posts on my blog use.

ImageTimeline

Here is where the EXIF reading earns its keep. ImageTimeline reads DateTimeOriginal from each photo, groups the photos by calendar day, and lays the days out in order. If a day has GPS data it reverse-geocodes a location label for that group, once, at build time. Nothing hits the network in the browser.

Default orientation is a horizontal rail you scroll sideways:

Set orientation="vertical" and the same data stacks down the page on a left-hand spine:

The Rügen days cluster together in August 2025. The Harz days sit in June 2026. You can see the shape of both trips without a caption telling you.

MapGallery

MapGallery reads the GPS coordinates, builds one circular photo marker per location, and puts them on a Leaflet map. Photos without GPS are skipped. If none of the photos have GPS, the component renders nothing.

The important part is the consent gate. Map tiles come from a third-party CDN, and loading them sends the visitor's IP address to that provider. So MapGallery renders an overlay first and loads nothing from the network until the visitor clicks the button. The choice is remembered in localStorage.

Underneath the map, in the HTML, there is a plain list of linked thumbnails with real alt text. Search engines and no-JS visitors get that list. The client script swaps in the interactive map once you accept the gate. Nobody loses the content.

You pick the look with a basemap preset: osm (keyless), carto-dark, carto-light, carto-voyager, stadia-dark or esri-satellite. The CARTO and Stadia presets need a free API key, which you pass as map.tileApiKey. On my blog the key lives in a Gitea secret and the config falls back to plain OpenStreetMap when it is not set.

What you get for free

The reason I bothered to package this properly, rather than keep copy-pasting, is the boring stuff. Every component renders crawlable, accessible markup on the server. The JavaScript only enhances it.

Semantic HTML. Galleries are a <ul> of <figure> elements. Each thumbnail is a real <a href> to the full-size image, so crawlers can follow it. The timeline is a <section> with an <ol> where each day heading is a <time datetime="...">.
Alt text that is not a file name. Resolution order: an explicit value you pass, then an embedded IPTC or XMP caption, then a humanised file name (IMG_4821.JPG is recognised as camera noise and ignored), then "<album> photo N".
Lazy loading without layout shift. Intrinsic width and height on every <img>, plus loading="lazy" and decoding="async". The first image is eager and high priority for LCP.
Responsive images. ImageGallery and JustifiedGallery emit a srcset across a set of widths, never upscaling past the source, with a matching sizes.
Structured data. Each gallery emits one <script type="application/ld+json"> with an ImageGallery whose associatedMedia is a list of ImageObject entries. Relative URLs become absolute when site is set in astro.config.

astro-gallery vs rolling your own

	astro-gallery	Hand-rolled component	A JS lightbox library
Image optimisation	`astro:assets`, built in	You wire up `getImage` yourself	Usually none, you pass URLs
EXIF date and GPS	Built in, build time	You add `exifr` and the plumbing	Out of scope
Consent gate for map tiles	Built in	You build it	Out of scope
Semantic HTML and JSON-LD	Built in	Whatever you remember to add	Depends on the library
Client JS	About 2 kB for the lightbox, Leaflet only on map pages	Your call	The whole library on every page
Config surface	One integration, sensible defaults	Full control, full maintenance	Its own API

Rolling your own is fine. I did it for a year. The problem was never the first copy. It was the fifth copy, slightly different from the other four, with a bug I had already fixed somewhere else.

FAQ

Does it need a client framework like React?
No. The components are .astro files. The only client JavaScript is a small dependency-free lightbox, plus Leaflet on pages that use MapGallery.

Where do the images live?
Anywhere under src/. The default base folder is src/assets/images/, so folderPath="demo" reads from src/assets/images/demo/. ImageGallery also accepts imported images and remote URLs directly.

Does the reverse geocoding call an API on every build?
Only for coordinates it has not seen before. Results are cached to a JSON file that you commit, shared by ImageTimeline and MapGallery. After the first run, builds and CI never touch the network for geocoding.

Can I theme it?
Yes. Everything is namespaced under .asg-* and driven by CSS custom properties. Override the tokens in your own CSS. Light and dark are picked up from prefers-color-scheme.

Which Astro versions work?
Astro 4 and up. My blog runs Astro 7.

Monte Carlo Simulation: How to go broke eight times faster with 8 Eurojackpot lines

Christoph Dieck — Sun, 30 Aug 2026 18:24:35 +0000

Every lottery player knows the saying: "One line is no line, you have to play a few more to boost your chances!" That's why the average player often fills out a complete ticket with 8 lines.

Sounds like a solid strategy, right? Wrong. It’s actually the fastest way to systematically burn through your cash.

To prove it, we wrote a Python simulation that uses historical payout data and cold, hard combinatorics to see who actually has any money left in their account at the end.

What exactly is a Monte Carlo simulation?

Named after the famous casino in Monaco, the Monte Carlo simulation is basically the brute-force approach to probability theory.

Usually, mathematicians use a single, elegant formula to calculate the expected value. That formula will dryly inform you: "You lose an average of 1 Euro per Eurojackpot line." That might be mathematically correct, but emotionally, it's a bit of a snooze. It doesn't capture the true pain of slowly bleeding out financially.

The Monte Carlo simulation throws that elegant formula right out the window. Its core concept is pure, raw computing power. Instead of just calculating the theoretical outcome, we let the computer simply play through reality thousands of times. It’s not an equation; it’s a simulation and iteration of real events.

The computer spawns 1,000 fictional players. For every player and every draw over the last 10 years, it generates a random number based on the actual Eurojackpot probabilities. It simulates the real-world winning and (mostly) losing, step by step. At the end, we aren't looking at some abstract theoretical number, but at the very real, blood-red bank accounts of 1,000 ruined clones.

The Setup

We're using Polars for lightning-fast data processing, NumPy to simulate millions of random draws, and Matplotlib to visualize our financial doom.

First, grab our historical Eurojackpot database and drop it into the same folder.

The Script

Here is the complete Python code. It calculates the exact mathematical odds on the fly using combinatorics (math.comb), links them up with the real average payouts from recent years, and then runs 1,000 players through the brute-force meat grinder.

"""
Eurojackpot Monte Carlo Simulation
===================================
Simulates realistic lottery participation over multiple years
using exact combinatorial probabilities and historical payout data.
"""

from __future__ import annotations

import math
import logging
from dataclasses import dataclass, field
from pathlib import Path
from typing import TYPE_CHECKING

import matplotlib.pyplot as plt
import matplotlib.ticker as ticker
import numpy as np
import polars as pl

if TYPE_CHECKING:
    pass

# ---------------------------------------------------------------------------
# Logging
# ---------------------------------------------------------------------------
logging.basicConfig(level=logging.INFO, format="%(message)s")
log = logging.getLogger(__name__)


# ---------------------------------------------------------------------------
# Constants
# ---------------------------------------------------------------------------
MAIN_POOL = 50
MAIN_PICK = 5
EURO_POOL = 12
EURO_PICK = 2
TICKET_COST = 2.0
DRAWS_PER_YEAR = 104  # 2× per week

PRIZE_TIERS: dict[str, tuple[int, int]] = {
    "5 + 2": (5, 2), "5 + 1": (5, 1), "5 + 0": (5, 0),
    "4 + 2": (4, 2), "4 + 1": (4, 1), "4 + 0": (4, 0),
    "3 + 2": (3, 2), "2 + 2": (2, 2), "3 + 1": (3, 1),
    "3 + 0": (3, 0), "1 + 2": (1, 2), "2 + 1": (2, 1),
}


# ---------------------------------------------------------------------------
# Config dataclass
# ---------------------------------------------------------------------------
@dataclass
class SimConfig:
    players: int = 1_000
    years: int = 10
    fields_per_draw: int = 8
    output_dir: Path = field(default_factory=lambda: Path("."))

    @property
    def total_draws(self) -> int:
        return self.years * DRAWS_PER_YEAR

    @property
    def cost_per_draw(self) -> float:
        return self.fields_per_draw * TICKET_COST

    @property
    def total_spent(self) -> float:
        return self.total_draws * self.cost_per_draw


# ---------------------------------------------------------------------------
# Probability calculation
# ---------------------------------------------------------------------------
def calculate_exact_probabilities() -> dict[str, float]:
    """Exact Eurojackpot winning probabilities via combinatorics."""
    total_main = math.comb(MAIN_POOL, MAIN_PICK)
    total_euro = math.comb(EURO_POOL, EURO_PICK)

    probabilities: dict[str, float] = {}
    prob_sum = 0.0

    for tier, (match_m, match_e) in PRIZE_TIERS.items():
        ways_main = math.comb(MAIN_PICK, match_m) * math.comb(
            MAIN_POOL - MAIN_PICK, MAIN_PICK - match_m
        )
        ways_euro = math.comb(EURO_PICK, match_e) * math.comb(
            EURO_POOL - EURO_PICK, EURO_PICK - match_e
        )
        prob = (ways_main / total_main) * (ways_euro / total_euro)
        probabilities[tier] = prob
        prob_sum += prob

    probabilities["No Win"] = 1.0 - prob_sum
    return probabilities


# ---------------------------------------------------------------------------
# Data loading
# ---------------------------------------------------------------------------
def load_empirical_payouts(
    file_path: str | Path,
    probabilities: dict[str, float],
) -> tuple[np.ndarray, np.ndarray]:
    """Load historical payout data and align with probability tiers."""
    log.info("[1/3] Loading historical payouts…")

    df = pl.read_json(str(file_path))
    payouts_df = df.select(pl.col("prizeDistribution")).unnest("prizeDistribution")
    avg_payouts: dict[str, float] = payouts_df.mean().to_dicts()[0]

    tiers = list(probabilities.keys())
    payouts = np.array(
        [0.0 if t == "No Win" else float(avg_payouts.get(t) or 0.0) for t in tiers],
        dtype=np.float64,
    )
    probs = np.fromiter(
        (probabilities[t] for t in tiers), dtype=np.float64, count=len(tiers)
    )
    probs /= probs.sum()  # normalise to guard against floating-point drift

    return payouts, probs


# ---------------------------------------------------------------------------
# Monte Carlo simulation
# ---------------------------------------------------------------------------
def run_monte_carlo(
    payouts: np.ndarray,
    probs: np.ndarray,
    cfg: SimConfig,
    *,
    seed: int | None = None,
) -> pl.DataFrame:
    """
    Vectorised Monte Carlo simulation.

    Memory layout: (total_draws, players, fields_per_draw)
    All draws are sampled in a single call for maximum throughput.
    """
    rng = np.random.default_rng(seed)

    log.info("[2/3] Simulating %d players over %d draws…", cfg.players, cfg.total_draws)
    log.info(
        "      Fields/draw: %d  |  Cost/draw: €%.2f  |  Total per player: €%.2f",
        cfg.fields_per_draw, cfg.cost_per_draw, cfg.total_spent,
    )

    # --- sample outcomes for every (draw, player, field) triple at once ---
    outcome_indices = rng.choice(
        len(payouts),
        size=(cfg.total_draws, cfg.players, cfg.fields_per_draw),
        p=probs,
    )
    raw_winnings: np.ndarray = payouts[outcome_indices]

    # sum over fields, subtract per-draw cost, cumsum over time
    net_per_draw = raw_winnings.sum(axis=2) - cfg.cost_per_draw  # (draws, players)
    bankroll = np.cumsum(net_per_draw, axis=0)                   # (draws, players)

    return pl.DataFrame(
        bankroll,
        schema=[f"Player_{i}" for i in range(cfg.players)],
    )


# ---------------------------------------------------------------------------
# Visualisation helpers
# ---------------------------------------------------------------------------
_PALETTE = {
    "jackpot":   "#00E5FF",
    "major":     "#FFD700",
    "minor":     "#FF9800",
    "profit":    "#00ff88",
    "loss":      "#ff4d4d",
    "worst":     "#ffffff",
    "breakeven": "#00bfff",
    "bg_fig":    "#0f1117",
    "bg_ax":     "#111827",
    "bg_legend": "#1f2937",
    "bg_text":   "#1f2937",
    "edge_text": "#ff4d4d",
}


def _profit_color(balance: float) -> str:
    if balance >= 1_000_000:
        return _PALETTE["jackpot"]
    if balance >= 100_000:
        return _PALETTE["major"]
    if balance >= 10_000:
        return _PALETTE["minor"]
    if balance > 0:
        return _PALETTE["profit"]
    return _PALETTE["loss"]


def _apply_dark_style(fig: plt.Figure, ax: plt.Axes) -> None:
    fig.patch.set_facecolor(_PALETTE["bg_fig"])
    ax.set_facecolor(_PALETTE["bg_ax"])


def _add_stats_box(
    ax: plt.Axes,
    avg: float,
    winners: int,
    players: int,
    fields: int,
) -> None:
    ax.text(
        0.02, 0.04,
        f"Stake per draw: €{fields * TICKET_COST:.2f}\n"
        f"Average result: €{avg:,.0f}\n"
        f"Profitable players: {winners}/{players}",
        transform=ax.transAxes,
        fontsize=12,
        bbox=dict(
            boxstyle="round,pad=0.6",
            facecolor=_PALETTE["bg_text"],
            edgecolor=_PALETTE["edge_text"],
            alpha=0.9,
        ),
    )


def _euro_formatter(x: float, _pos: int) -> str:
    return f"€ {int(x):,}"


# ---------------------------------------------------------------------------
# Plot generation
# ---------------------------------------------------------------------------
def analyze_and_plot(df: pl.DataFrame, cfg: SimConfig) -> None:
    """Generate log-scale (illusion) and linear-scale (reality) charts."""
    log.info("[3/3] Creating visualisations…")

    players = len(df.columns)
    final_balances = np.array(df.row(-1))

    avg_balance   = float(final_balances.mean())
    best_balance  = float(final_balances.max())
    worst_balance = float(final_balances.min())
    best_idx  = int(final_balances.argmax())
    worst_idx = int(final_balances.argmin())

    best_col  = df.columns[best_idx]
    worst_col = df.columns[worst_idx]

    winners_mask = final_balances > 0
    winners_count = int(winners_mask.sum())

    winner_cols = [df.columns[i] for i, w in enumerate(winners_mask) if w and df.columns[i] != best_col]
    loser_cols  = [df.columns[i] for i, w in enumerate(winners_mask) if not w]

    # cap losers shown to 500 for readability
    sample_losers = loser_cols[:500]

    plt.style.use("dark_background")

    chart_configs: list[tuple[str, str, bool, float | None]] = [
        (
            "eurojackpot_1_illusion_log.png",
            f"The Illusion: {cfg.years} Years Eurojackpot ({cfg.fields_per_draw} Fields)",
            True, None,
        ),
        (
            "eurojackpot_2_reality_linear.png",
            f"The Reality: {cfg.years} Years Eurojackpot ({cfg.fields_per_draw} Fields)",
            False, 5_000.0,
        ),
    ]

    for filename, title, use_log, ylim_max in chart_configs:
        fig, ax = plt.subplots(figsize=(12, 7))
        _apply_dark_style(fig, ax)

        # losers (faint red)
        for col in sample_losers:
            ax.plot(df[col].to_numpy(), color=_PALETTE["loss"],
                    alpha=0.15, linewidth=0.5, zorder=1)

        # non-best winners
        for col in winner_cols:
            series = df[col].to_numpy()
            ax.plot(series, color=_profit_color(series[-1]),
                    alpha=0.7, linewidth=0.8, zorder=3)

        # best & worst highlighted
        ax.plot(
            df[best_col].to_numpy(),
            color=_profit_color(best_balance),
            linewidth=1.5,
            label=f"Best: €{best_balance:,.0f}",
            zorder=6,
        )
        ax.plot(
            df[worst_col].to_numpy(),
            color=_PALETTE["worst"],
            linestyle="--",
            linewidth=1.5,
            label=f"Worst: €{worst_balance:,.0f}",
            zorder=6,
        )

        ax.axhline(0, color=_PALETTE["breakeven"], linestyle=":",
                   linewidth=1.5, label="Breakeven (€0)")

        if use_log:
            ax.set_yscale("symlog", linthresh=1_000)
            ax.set_ylabel("Net Bankroll (Log Scale)")
        else:
            ax.set_ylim(worst_balance - 500, ylim_max)
            ax.set_ylabel("Net Bankroll (Linear Scale)")

        ax.set_title(title, fontsize=18, fontweight="bold")
        ax.set_xlabel("Number of Draws (Tuesday & Friday)")
        ax.grid(True, axis="y", linestyle="--", alpha=0.15)
        ax.yaxis.set_major_formatter(ticker.FuncFormatter(_euro_formatter))

        legend = ax.legend(loc="upper right", fontsize=11)
        legend.get_frame().set_facecolor(_PALETTE["bg_legend"])
        legend.get_frame().set_edgecolor("#374151")

        _add_stats_box(ax, avg_balance, winners_count, players, cfg.fields_per_draw)

        plt.tight_layout()
        out_path = cfg.output_dir / filename
        fig.savefig(out_path, dpi=300, bbox_inches="tight")
        plt.close(fig)
        log.info("[+] Saved: %s", out_path)

    log.info("\nAll charts generated successfully.")


# ---------------------------------------------------------------------------
# Entry point
# ---------------------------------------------------------------------------
def main() -> None:
    data_file = Path("eurojackpot-history.json")

    if not data_file.exists():
        log.error("Error: '%s' not found.", data_file)
        return

    cfg = SimConfig(players=10_000, years=10, fields_per_draw=8)

    probabilities      = calculate_exact_probabilities()
    payouts, probs     = load_empirical_payouts(data_file, probabilities)
    df_simulation      = run_monte_carlo(payouts, probs, cfg, seed=42)
    analyze_and_plot(df_simulation, cfg)


if __name__ == "__main__":
    main()

The Result

When you run the script, something visually striking happens. Thanks to the symlog scaling on the Y-axis, we get to see both: the brutal, steady losses of the general public and the absurd outliers of the extreme winners, all without breaking the chart.

The hard truth in numbers:
At 8 lines per draw, you will burn through roughly €11,500 in 10 years. The simulation shows it clearly: even if you hit 3 correct numbers now and then, it won't save you from the statistical expected value. The red cloud inevitably drags every player into the negative. Most of the time, not a single one of the 1,000 simulated players finishes the decade in the green.

Think you're that green outlier on the chart? Test your own 8 lucky lines in our Eurojackpot Simulator and click your way into bankruptcy!

10 Years of Eurojackpot Data with Polars

Christoph Dieck — Sat, 29 Aug 2026 17:57:24 +0000

Welcome to the intersection of high-performance data engineering and terrible financial decisions.

In this post, we are going to do what every hopeful gambler eventually tries: analyze historical lottery data to find the "secret pattern." To do this, we will use Python's Polars library—because if we are going to calculate our inevitable financial ruin, we might as well do it with blazing fast, multi-threaded performance.

Spoiler alert: the data won't help you win. But it is a fantastic exercise in data manipulation, nested JSON parsing, and visualization. Let's dive in.

Step 1: Setup Your Development Environment

To follow along, you will need a Python environment with Polars (for data crunching) and Matplotlib (to draw pretty charts of our losses). Run this in your terminal:

mkdir eurojackpot-analysis
cd eurojackpot-analysis
python -m venv .venv
source .venv/bin/activate
pip install polars matplotlib

Step 2: Loading the Eurojackpot Draw History

We provide a massive, free dataset of all Eurojackpot draws over the last 10+ years right here on the site. Let's grab it:

wget https://www.howtolosemoneyfast.com/downloads/eurojackpot-history.json

Step 3: The "Reality Check" Script

Here is the complete Python script. It uses Polars' powerful .explode() method to untangle the nested arrays of winning numbers, and .unnest() to flatten the prize distribution data.

import polars as pl
import matplotlib.pyplot as plt
from pathlib import Path
from typing import Union

def load_lottery_data(file_path: Union[str, Path]) -> pl.DataFrame:
    """Loads historical lottery data from a JSON file."""
    path = Path(file_path)
    if not path.exists():
        raise FileNotFoundError(f"Dataset not found at: {path}")
    return pl.read_json(path)

def calculate_number_frequencies(df: pl.DataFrame, column_name: str, top_n: int = 10) -> pl.DataFrame:
    """Calculates the frequency of drawn numbers."""
    return (
        df.select(pl.col(column_name).explode())
        .group_by(column_name)
        .agg(pl.len().alias("frequency"))
        .sort("frequency", descending=True)
        .head(top_n)
    )

def analyze_payout_distribution(df: pl.DataFrame) -> pl.DataFrame:
    """Calculates summary statistics for minor prize tiers."""
    payouts_df = df.select(
        pl.col("date"), 
        pl.col("prizeDistribution")
    ).unnest("prizeDistribution")

    summary_stats = payouts_df.select([
        pl.col("2 + 1").drop_nulls().mean().round(2).alias("2 Main + 1 Euro"),
        pl.col("3 + 0").drop_nulls().mean().round(2).alias("3 Main + 0 Euro"),
        pl.col("3 + 1").drop_nulls().mean().round(2).alias("3 Main + 1 Euro")
    ])
    return summary_stats

def plot_reality_check(top_main: pl.DataFrame, payout_stats: pl.DataFrame):
    """Generates a professional dual-plot visualization."""

    # Set up a professional plotting style
    plt.style.use('ggplot')
    fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(14, 6))
    fig.suptitle("Eurojackpot Historical Analysis: The Illusion of Strategy", fontsize=16, fontweight='bold')

    # --- Plot 1: "Hot" Numbers ---
    # Convert Polars columns to lists for Matplotlib
    numbers = [str(n) for n in top_main["mainNumbers"].to_list()]
    frequencies = top_main["frequency"].to_list()

    ax1.bar(numbers, frequencies, color='#2c3e50', edgecolor='black')
    ax1.set_title("Top 10 Most Frequent Main Numbers", fontsize=12)
    ax1.set_xlabel("Lottery Number")
    ax1.set_ylabel("Times Drawn")

    # Add a cynical watermark/text box
    ax1.text(0.05, 0.95, "Past performance does not\nindicate future results.", 
             transform=ax1.transAxes, fontsize=10, verticalalignment='top', 
             bbox=dict(boxstyle='round', facecolor='white', alpha=0.8))

    # --- Plot 2: Payout Reality ---
    # Extract column names and their single row values
    tiers = payout_stats.columns
    avg_payouts = payout_stats.row(0)

    ax2.bar(tiers, avg_payouts, color='#e74c3c', edgecolor='black')
    ax2.set_title("Average Payouts for Common 'Wins'", fontsize=12)
    ax2.set_xlabel("Matching Tiers")
    ax2.set_ylabel("Average Payout (€)")

    # Add exact values on top of the bars
    for i, v in enumerate(avg_payouts):
        ax2.text(i, v + 0.5, f"€{v:.2f}", ha='center', fontweight='bold')

    plt.tight_layout()

    # Save the plot so you can upload it straight to your blog
    output_filename = "eurojackpot_reality_check.png"
    plt.savefig(output_filename, dpi=300)
    print(f"\n[+] Chart successfully generated and saved as '{output_filename}'")

    # Show the plot window
    plt.show()

def main():
    pl.Config.set_tbl_formatting("ASCII_MARKDOWN")
    pl.Config.set_tbl_hide_column_data_types(True)

    file_path = "eurojackpot-history.json"

    try:
        print("Initializing Eurojackpot Historical Analysis...\n")
        df = load_lottery_data(file_path)

        # Get top 10 for a better looking chart
        top_main = calculate_number_frequencies(df, "mainNumbers", top_n=10)
        payout_stats = analyze_payout_distribution(df)

        # Generate the visualization
        plot_reality_check(top_main, payout_stats)

    except Exception as e:
        print(f"Analysis failed: {e}")

if __name__ == "__main__":
    main()

The Results

When you run this script, Matplotlib generates the following reality check:

The takeaway: Even if you successfully pick the "hottest" historical numbers, and you manage to match 3 Main numbers and 1 Euro number... congratulations. You've statistically won enough to buy a nice pizza.

Want to see the math in action without writing any code? Try running 1,000 lifetimes of tickets through our live Eurojackpot Simulator and watch your virtual bank account drain in real-time.

Middle-earth and the Digital Infarction

Christoph Dieck — Fri, 21 Aug 2026 09:15:16 +0000

It was supposed to be a relaxed evening. I had finally convinced my girlfriend to watch the Lord of the Rings Extended Edition with me. The mood was good, the elves were marching into Helm's Deep. But right around 10 PM, everything went dark.

The entire LAN was dead. No streaming on the TV and no internet on the PC. The strange thing was that the Wi-Fi on my Fritzbox 7690 was still working perfectly. Only everything connected via cable was completely knocked out.

The Suspect in the Server Closet

Since I had just recently put the Lenovo M920q into service, it was naturally my prime suspect. My first assumption was a misconfigured Docker container. I thought about problems with macvlan or a container in Network Host Mode that might be causing a loop.

I disabled a suspicious container and had two days of peace. I thought the problem was solved. But then it happened again: right in the middle of the movie, the LAN was gone. Only when I pulled the network cable from the Lenovo did the entire network calm down immediately.

Hunting Through the Kernel Logs

I SSHed into the Proxmox host and searched through the logs:

dmesg -T | grep -i e1000e

There I found error messages appearing every second:

e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang
TDH                  <52>
TDT                  <73>
next_to_use          <73>
next_to_clean        <52>

Technically, this is a problem with the ring buffers of the network card. Think of it like a conveyor belt. The system puts packets on the back (TDT - Transmit Descriptor Tail) and the card sends them off the front (TDH - Transmit Descriptor Head).

In my case, the logs showed:

TDH (Head): 52
TDT (Tail): 73

This means the system is queueing packets, but the hardware isn't processing them on the front end. The network card is simply frozen internally. Because the server is connected to the LAN via a bridge, this hang clogs up the entire Fritzbox switch port and takes down the rest of the wired network with it.

Why Does This Happen?

The culprit is a feature called EEE (Energy Efficient Ethernet), also known as IEEE 802.3az. The Intel i219-LM card tries to save power when there's little activity. But in combination with virtualization under Proxmox, it sometimes doesn't wake up properly. This leads to timing problems and ends in a Hardware Unit Hang.

The Solution

I applied three steps to get the Lenovo stable again:

1. Adjust Driver Options

In /etc/modprobe.d/e1000e.conf I added the following line:

options e1000e InterruptThrottleRate=0,0,0 EEE=0

This disables Energy Efficient Ethernet and interrupt throttling at the driver level.

2. Disable Offloading

So-called offloading refers to functions where the card takes work off the CPU (TSO, GSO, GRO). That sounds good in theory, but often leads to problems:

ethtool -K nic0 tso off gso off gro off

3. Create a Systemd Service

To make these settings persist after every reboot, I created a systemd service:

/etc/systemd/system/nic-stable.service:

[Unit]
Description=Disable NIC offloading and EEE for stability
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -K nic0 tso off gso off gro off
ExecStart=/usr/sbin/ethtool -s nic0 eee off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Then activated it:

systemctl daemon-reload
systemctl enable nic-stable.service
systemctl start nic-stable.service

And an initramfs update to load the modprobe config:

update-initramfs -u

The Rescue Mission Conclusion

It wasn't a bug in Proxmox or the Fritzbox. It was simply the hardware losing the thread while trying to save power. By the way, the Fritzbox doesn't see any of this because the problem happens at Layer 2 the network card just hangs before any IP packets can even be sent.

Since these adjustments, the system has been running without a single dropout. We were finally able to finish Lord of the Rings without interruption. If your LAN ever goes down for no apparent reason, take a look at your server's kernel logs:

dmesg -T | tail -100

Often it's just a network card that slept a little too deeply. 🛌💤

I Built a Chimney Calculator Because I Wanted a Wood Stove

Christoph Dieck — Fri, 21 Aug 2026 07:17:45 +0000

The origin story

Early this year I decided to get a wood-burning stove for the house. Sounded simple. Pick a nice one, call the chimney sweep, done. Wrong.

The first question the sweep asked: "Which flue are you connecting to?" My house has a secondary shaft. Rectangular cross-section, not the standard 150mm round. It was originally just a ventilation shaft. Never designed for a combustion appliance. The sweep told me I needed a cross-section calculation according to DIN EN 13384-1 to prove the combination would even work. Pressure balance. Temperature at the outlet. Condensation risk. The whole program.

I looked at the math and got hooked. Not because it's pretty. It's not. It's pressure drops through friction, buoyancy from density differences between hot flue gas and cold ambient air, exponential temperature decay along insulated pipes, and dew point calculations that decide whether your chimney liner will dissolve in acid over time.

I wanted to understand it. So I built a tool that does it.

What DruckZugPro does

druckzug.pro is a free chimney cross-section pre-check tool based on DIN EN 13384-1. You enter your stove's exhaust data and your chimney geometry. The tool runs the three core verification checks and tells you if the combination is feasible.

This is not a certified calculation. You still need a professional for that. But it gives you a solid first answer before you spend money on a consultation that might end with "nope, doesn't work."

Three checks run simultaneously:

Pressure balance — Is the natural draft strong enough to overcome all friction and pressure losses?
Temperature check — Is the gas temperature at the chimney outlet still above the dew point? (If not: condensation, acid, masonry damage.)
Cross-section adequacy — Is the flue diameter large enough for the gas velocity to stay below critical limits?

Pass all three and you have a good basis for the real calculation. Fail one and the tool tells you what's wrong and what you could change.

The physics that makes it interesting

The core is a thermodynamic model. Flue gas enters the connecting pipe hot and cools exponentially as it travels upward. The cooling rate depends on the pipe material, insulation, diameter, ambient temperature, and mass flow rate.

The available draft comes from buoyancy. Hot gas is less dense than cold ambient air. The density difference over the effective chimney height creates a pressure differential. That's your engine.

Working against it: friction along the pipe walls, losses at bends and transitions, the outlet loss at the chimney top, and the operating pressure the stove itself needs.

The temperature check is where it gets serious for the building. If the flue gas cools below its dew point before leaving the chimney, water and sulfuric acid condense on the inner walls. Over years, that destroys masonry. The tool computes the outlet temperature using the worst-case outdoor temperature and compares it against the fuel-specific dew point.

Chimney visualization. An SVG diagram that renders your chimney geometry to scale. Height, diameter, connecting pipe, top adapter. Updates reactively when you change parameters.

Features beyond the core check

Appliance database. Over a hundred stove models with their official technical data (exhaust temperature, mass flow, CO2 content, fuel type). Select your model and the form auto-fills. Data sourced from manufacturer specifications and the HKI registry.

Compatible appliances finder. Flip the question. Instead of "does my stove fit my chimney?" ask "which stoves fit my chimney?" The tool runs a simplified DIN check against every appliance in the database and shows you which ones pass.

Parameter tuner. After the initial calculation, interactive sliders let you tweak chimney height, diameter, pipe length, and cross-section shape. Results update live. You can see exactly where the margins break or improve. Failing parameters get highlighted in red.

Weather resilience chart. Sweeps the calculation across a range of outdoor temperatures (from -20 to +35) and plots the pressure margin and temperature margin as curves. Shows you at which ambient temperature your chimney setup starts failing. Useful for understanding edge-case behavior in extreme cold.

PDF export. Generates a multi-page A4 report with all configuration data and calculation results. Uses pdfme for client-side generation. No server round-trip.

Calculation appendix. Shows the full intermediate values and formulas used. Every number is traceable. Molar mass, density, specific heat, thermal conductance, cooling factor, friction coefficient. If you want to verify the math by hand, everything is there.

The tech stack

Astro for static site generation. German and English with localized routes.
TypeScript for all DIN 13384-1 calculation logic. Pure functions, no DOM, fully testable.
Nanostores for reactive state. The config store triggers recalculation and UI updates.
Chart.js for pressure balance, temperature profile, weather resilience, and flow visualizations.
KaTeX for rendering mathematical formulas in the calculation appendix.
pdfme for client-side PDF report generation.
Ajv with JSON Schema for configuration validation.
Tailwind CSS for styling.
Vitest with fast-check for property-based testing on the thermodynamics module.

Everything runs in the browser. No backend. No accounts. Projects are saved in localStorage.

The architecture that made it clean

The DIN 13384 calculation is a pure function. ChimneyConfig goes in, CalculationResult comes out. No side effects. No store access. No DOM.

The pipeline runs in stages:

Validate input (structural and physical constraints)
Compute flue gas properties (density, specific heat, molar mass)
Compute pressure losses through the connecting pipe (friction + single-point losses at bends)
Compute pressure losses through the chimney (friction + transition + outlet loss)
Compute available draft (buoyancy from density differential over height)
Run the three verification checks
Generate recommendations if anything fails

The recommendation engine is the part I'm most pleased with. When the pressure check fails, it binary-searches for the minimum chimney height that would pass. When the cross-section fails, it iterates through standard diameters and recommends the smallest one that works. Actionable output instead of just "fail."

What I learned

DIN EN 13384-1 is surprisingly elegant once you strip away the bureaucratic language. It's basically Newton's cooling law combined with the hydrostatic pressure formula and pipe friction factors. Three equations that interact. The difficulty is not in any single formula. It's in getting all the constants right (thermal transmittance per wall type, friction coefficients per material, outlet loss coefficients per termination type) and handling the edge cases cleanly.

The hardest part was testing. The standard doesn't include reference calculations you can verify against. I had to cross-check results against commercial software outputs from a chimney sweep I know and manually verify intermediate values against textbook examples.

Try it

druckzug.pro — Enter your stove and chimney data, get instant results.
Compatible appliances — Find which stoves work with your existing chimney.

Free. No login. No tracking. If you're planning a stove installation and want a sanity check before calling the sweep, this saves you the guesswork.

The Cloud in a Cabinet

Christoph Dieck — Wed, 19 Aug 2026 13:36:30 +0000

In Part 1 I covered the hardware: how the Lenovo M920q replaced my overwhelmed Synology as a compute node. The hardware is in place, Proxmox is humming. Now for the real question: how do the services reach the internet without turning the router into Swiss cheese?

Infrastructure as Code: Everything in Git

Clicking containers together by hand is not for me. If I break something, I want to rebuild it with a single command. My setup: a Git repository with one YAML file per service.

Instead of dumping everything into one giant docker-compose.yml, I built my services as modular Portainer stacks:

gitea.yml My private code home, including a Gitea Runner for CI/CD.
jellyfin.yml Media streaming for after work. Movies live on the Synology, streaming runs on the M920q. For this to work, the NAS media volume needs to be mounted on the Docker host via NFS or SMB. In my case, a simple entry in /etc/fstab:

  //192.168.1.x/media /mnt/nas-media cifs credentials=/etc/nas-credentials,uid=1000,gid=1000 0 0

Jellyfin then accesses /mnt/nas-media through a bind mount.

vaultwarden.yml Password manager for all devices. More on this below.
web.yml Traefik as reverse proxy for my websites (blog, portfolio, howtolosemoneyfast etc.).
tunnel.yml The Cloudflare Tunnel that ties everything together.

New service? Create a YAML file, deploy it as a stack in Portainer, done. Everything broken? git pull, redeploy the stacks, back online.

Cloudflare Tunnels: No Open Ports, Still Reachable

The old way: open ports 80 and 443 on the router, set up DynDNS, and hope nobody rattles the front door. Today that is no longer necessary.

The Cloudflare Tunnel (cloudflared) establishes an encrypted connection from the inside out to Cloudflare. No inbound port needs to be opened. Cloudflare handles TLS termination, DDoS protection, and DNS.

Two things that make this especially valuable for my setup:

No port forwarding. My router stays completely locked down. Port scanners hit nothing.
Zero Trust via Cloudflare Access. Before anyone sees the login page of Jellyfin or Gitea, they must pass an email verification. Only approved email addresses get through.
One subdomain per service. In the Cloudflare dashboard you create a subdomain for each service and point it to the internal port. For example jellyfin.example.com → http://jellyfin:8096, git.example.com → http://gitea:3000. Each subdomain gets its own access rules. This keeps everything cleanly separated and lets you control who can reach each service individually.

The Architecture

Here is the path from the browser to each service:

The cloudflared container connects to Cloudflare automatically on startup. All services sit on the same Docker network as cloudflared and are reachable directly. Only the static websites (blog, portfolio) have Traefik in front as a reverse proxy, because multiple domains need to be routed to different Nginx containers. The Synology remains a pure storage node: movies and backups.

Important: local traffic should not go through the Cloudflare Tunnel. When the TV in the living room streams a movie, it makes no sense to send the data to Cloudflare and back into your own network. That costs latency and bandwidth. Instead, TV and notebook connect directly to Jellyfin via IP (port 8096). The tunnel is only for access from outside.

Vaultwarden Instead of KeePass + Google Drive

My previous setup: a KeePass database on Google Drive, the same .kdbx on every device. Works fine until you change a password on the laptop while the phone still has the old version open. Save, sync conflict, two files. Then you get to merge by hand and hope nothing is lost. That happened often enough that I got tired of it.

Vaultwarden is a Rust reimplementation of the Bitwarden server API. The trick: you use the official Bitwarden clients and browser extensions, point the server URL to your own domain, and log in. The clients cannot tell the difference from hosted Bitwarden, but the data stays with me.

Sync works across all devices, autofill in browsers and on mobile just works, and sharing passwords with the family is handled through organizations. The container uses less than 100 MB of RAM.

For me this was the service that justified the whole homelab effort the fastest. No more Google Drive in the chain, no more broken .kdbx files.

Deployment via Shared Volumes

One detail I am quite happy with: how the websites go from git push to live without any file copying or rsync.

The Gitea Runner has access to specific Docker volumes listed as valid_volumes in its config, for example blog-astro-content-prd or howtolosemoney-content-prd. When a CI pipeline runs, the runner builds the static site and writes the output directly into the matching volume. The Nginx containers in web.yml mount exactly these volumes as read-only:

# web.yml (excerpt)
blog-astro-web-prd:
  image: nginx:alpine
  volumes:
    - blog-astro-content-prd:/usr/share/nginx/html:ro

# gitea.yml (runner config excerpt)
container:
  valid_volumes:
    - "blog-astro-content-prd"
    - "howtolosemoney-content-prd"
    - "portfoliomanager-content-prd"

Git push, runner builds, result lands in the volume, Nginx serves it. No SCP, no webhook, no second deploy step. The Nginx containers do not even notice anything changed because they just read from the filesystem.

FritzBox, IP Changes and the Bypass Rule

Cloudflare Access protects my services with email verification. But from my own network I do not want to go through that every time. For that there is a Zero Trust bypass policy that allows my public IP through. Problem: the FritzBox gets a new IP on every forced reconnect.

The solution is a webhook. In the FritzBox under "Internet > Permits > DynDNS" there is an update URL pointing to my nas-manager-hooks container. When the IP changes, the FritzBox calls the webhook which triggers a Python script that:

Fetches the current IPv4 and IPv6 via external services (ipify, ident.me)
Calculates the /64 network from the IPv6 address
Updates the Cloudflare Zero Trust bypass policy via API with the new IPs

Why fetch externally? The FritzBox passes the IPv4 in the DynDNS callback but no IPv6 address. So the script fetches IPv6 itself via api6.ipify.org with v6.ident.me as fallback. If the lookup fails it retries up to five times with exponential backoff.

The result: IP changes, FritzBox reports in, script runs, bypass policy is up to date. No cron job, no polling.

Real-World Performance CPU usage during that: rarely above 30%. Thanks to the fiber connection, my friends cannot tell whether the server lives in my cabinet or in a data center.

Some numbers from daily operation:

Metric	Value
RAM usage (all containers)	~8 GB
Idle power consumption	~10 W
Power consumption under load	~35 W
Active Docker containers	9

What's Next in Part 3?

Mysterious network outages, always right when a movie should be playing in the evening? In Part 3 I dig into the network logs to find out whether the M920q is really a good roommate or if it is secretly killing the Wi-Fi.

Building a Home Lab with a Lenovo ThinkCentre M920q

Christoph Dieck — Tue, 18 Aug 2026 08:14:25 +0000

It all started innocently enough. A little Jellyfin for the movie collection here, a small Gitea instance for my code there. My Synology DS223 handled the job without complaint. But once you get a taste for automating your own software pipeline, you quickly end up wanting a CI runner. And that is exactly where things went sideways.

When memory runs out

One runner here, one build process there, and suddenly my NAS was telling me we had a massive memory problem. 2 GB of RAM is no luxury resort for containers. It is more like a studio apartment with a shared kitchen. As soon as the Gitea Runner kicked off a build, the system started gasping for air. The OOM killer came knocking.

The conclusion was obvious: I need a real server. But without solar panels on the roof, the usual second-hand server monsters with their 200-watt power supplies were out of the question.

My requirements:

Enough CPU and RAM for Docker containers, CI/CD runners, and media streaming
35 watts max under load (electricity is not free)
Under 400 euros all-in, including upgrades
Compact enough to fit next to the NAS in the server cabinet

Big power, tiny box

After nights of browsing r/homelab and various forums, I landed on the quiet favorite of the home lab community: the Lenovo ThinkCentre M920q. An off-lease unit for 160 euros. Barely larger than a box of chocolates, but it has everything:

A real PCIe slot (for future 10GbE adventures)
Two RAM slots (up to 64 GB DDR4)
An M.2 slot for NVMe storage
An Intel Core i5-8500T with six cores that quietly get the job done

The shopping list

Component	Cost
Lenovo M920q (Refurbished)	160 EUR
32 GB RAM (2x16 GB DDR4)	100 EUR
1 TB NVMe SSD (WD SN770)	100 EUR
Original 8 GB RAM (sold on eBay)	-29 EUR
Original 256 GB SSD (sold on eBay)	-26 EUR
Total (net)	305 EUR

Selling the original components on eBay brought the total down to about 305 euros. For that money you get a machine that delivers more performance per watt than many a tower server. And it is quieter than the cooler box sitting next to it.

The foundation: Proxmox, Docker, Portainer

I went with Proxmox VE as the hypervisor. First order of business after installation: an Ubuntu Server VM with Docker and Portainer as the container management UI.

I immediately made a rookie mistake: I installed the Portainer Community Edition. Only after some digging did I find out that as a private user you can use the Business Edition completely free for up to three nodes. The BE offers access control, Git-based stack deployments, and automatic updates. All features you learn to appreciate as your setup grows.

Power consumption

The M920q draws about 10 watts at idle. Barely more than an LED bulb. Under full Docker load with multiple containers running builds, streaming media, and pushing to Git, it peaks at around 35 watts.

For context: a typical used rack server (Dell R720, HP DL380) idles at 80 to 150 watts doing nothing. Over a year, that difference adds up to roughly 100 to 200 EUR in electricity costs at German rates. The M920q pays for itself in saved power within two years compared to a traditional server.

What runs on it

After a few months of iteration, the Docker host now runs:

Gitea with a CI runner (my own Git forge with build pipelines)
Jellyfin (media streaming)
Traefik (reverse proxy)
Cloudflare Tunnel (secure remote access without port forwarding)
AdGuard Home (network-wide ad blocking)
Vaultwarden (password manager)
Grafana + Prometheus + Loki (monitoring and log aggregation)
CrowdSec (WAF/IDS in front of Traefik)
Multiple Nginx containers serving static sites

All of that on a 305 EUR mini PC drawing 10 watts idle. The six cores and 32 GB RAM handle it without breaking a sweat.

Why this works for a home lab

The ThinkCentre M-series machines are built for enterprise desktop use. That means:

Rock solid hardware (these run 24/7 in corporate fleets)
Excellent Linux/Proxmox compatibility out of the box
vPro/AMT for remote management if you want it
Abundant supply on the used market as companies cycle their leases

The M920q specifically hits a sweet spot. The i5-8500T has 6 cores (no hyperthreading, but 6 real cores), supports up to 64 GB RAM, and the PCIe slot means you can add a 10GbE NIC or an HBA card for direct-attached storage later.

Lessons learned

Start with Portainer Business Edition. The free three-node license is generous and the Git-based stack deployment alone is worth it. Being able to push a docker-compose change to a Git repo and have Portainer auto-deploy it removes a lot of manual SSH work.

Sell the original components immediately. RAM and SSD prices drop fast. I listed mine the day the upgrades arrived and got 55 EUR back. Waiting a month would have netted me 30 at best.

The NAS stays a NAS. I moved all compute workloads off the Synology and let it do what it does best: store files, run scheduled backups, and serve NFS shares. It is much happier now.

35 watts is the ceiling, not the floor. Most of the time the system idles well below that. My Grafana dashboard shows an average of 12 to 15 watts over a typical week. Only CI builds and transcoding push it higher.

Over to you

If you are running Docker workloads on a NAS and hitting memory limits, or if you are paying 20 to 30 EUR/month in electricity for a tower server that is mostly idle, the ThinkCentre M920q (or its newer siblings M920x, M930q, M90q) might be worth a look.

What is your home lab hardware? Curious to hear what others are running and how you keep power consumption reasonable.

I Built a Lottery Simulator That Shows You Losing Money for 1000 Years

Christoph Dieck — Tue, 18 Aug 2026 07:34:07 +0000

What I built

howtolosemoneyfast.com is a satirical lottery analysis tool. You can simulate thousands of EuroJackpot or Lotto 6aus49 draws, check your numbers against every real historical draw (back to 1955 for 6aus49), and watch a chart of your net worth go relentlessly downward.

The entire thing runs client-side. No backend, no data collection. Your numbers never leave your browser.

Why

I wanted to make the abstract concept of "1 in 139 million" feel visceral. Reading that your odds are bad is one thing. Watching yourself lose 2,600 draws in a row while a live chart tracks your spending against an ETF that keeps growing is something else entirely.

The name is the thesis. If you want to lose money fast, buying lottery tickets is a reliable method.

Tech stack

Astro for the static site generation (multilingual: EN, DE, ES)
TypeScript for all simulation logic
Tailwind CSS for styling
Chart.js for the real-time net profit visualization
pako for decompressing embedded historical draw data

No frameworks on the client side. All interactive components are vanilla TypeScript with Astro islands. The simulator runs draw loops without blocking the main thread using chunked processing.

How the simulator works

The lottery simulator lets you configure:

Fixed or random number strategy
Play frequency (1x or 2x per week)
Duration (1 year to 1000 years, or "until billionaire" which spoiler: takes a while)
Number of tickets per draw
Ticket price

It then runs the draws in batches, updates a live chart showing your cumulative net profit over time, and tracks stats like ROI, win rate, longest dry spell, and prize breakdown by tier.

There is also a "Until Billionaire" mode that just keeps going until your cumulative winnings hit one billion. On EuroJackpot odds, that takes a very long time. My browser fan usually starts spinning before the simulation finishes.

The number checker

The other main feature lets you enter your personal lottery numbers and checks them against every single real historical draw. EuroJackpot since 2012, Lotto 6aus49 since 1955. It shows you exactly which prizes you would have won (or, much more likely, wouldn't have).

Historical draw data is fetched at build time, compressed with pako, and shipped as embedded TypeScript arrays. The site rebuilds on a schedule through a Gitea Actions CI pipeline after each draw day.

Data pipeline

Draw day (Tuesday/Friday) 
  → Gitea Actions workflow triggers
  → TypeScript scripts download latest results from official APIs
  → Generate embedded data modules
  → Astro build
  → Deploy to Docker volume via CI
  → Served through Nginx behind Cloudflare Tunnel

The whole thing is self-hosted. Proxmox VM, Docker stack managed through Portainer, Traefik as reverse proxy, Cloudflare Tunnel for public access.

Things I learned building this

Simulating millions of draws is CPU-intensive. The naive approach of running a for-loop for 52,000 draws (1000 years, once per week) blocks the main thread for seconds. I chunk the simulation into batches and yield back to the browser between them. Chart updates happen every N draws, not every single one.

Historical lottery data is surprisingly hard to get. There is no single clean API. I ended up writing custom downloaders that parse different source formats and normalize them into a consistent JSON structure.

Multilingual sites in Astro are pleasant to build. The i18n setup uses a simple key-value approach with runtime string replacement. Each page exists in three languages with localized URLs.

Nobody believes the math until they see the chart. I showed people the raw statistics first. They nodded. Then I showed them the simulator running for 50 years. That is when the message lands.

Try it

EuroJackpot Simulator (simulate up to 1000 years of draws)
Lotto 6aus49 Simulator (the German classic)
Number Checker (test your numbers against real history)

Set the simulator to 50 years, hit start, and watch the chart. Then maybe reconsider that weekly ticket.

From 7MB to 52KB: My WebAssembly Size Optimization Journey

Christoph Dieck — Mon, 17 Aug 2026 10:03:38 +0000

The problem

I built an HTML-to-Markdown converter that runs entirely in the browser via WebAssembly. No server, no uploads. The conversion engine ships as a .wasm binary that every visitor downloads on first load. That means binary size directly impacts time-to-interactive.

Over three rewrites I went from 7MB down to 52KB. A 99.3% reduction. Here's what each step taught me.

Generation 1: Standard Go (GOOS=js GOARCH=wasm)

The first version used Go with the html-to-markdown library by JohannesKaufmann and golang.org/x/net/html for DOM parsing. Go made it easy to get a working pipeline quickly.

The problem: Go's WASM output includes the entire Go runtime. Goroutine scheduler, garbage collector, and the full reflect package pulled in by encoding/json as a transitive dependency.

GOOS=js GOARCH=wasm go build -o convert.wasm ./wasm/

Result: ~7 MB (uncompressed)

Even with encoding/json stripped and buildvcs=false, the runtime overhead is substantial. Go's WASM target was designed for feature-completeness, not binary size.

Generation 2: TinyGo

TinyGo compiles Go to WASM using LLVM instead of Go's native compiler. It produces dramatically smaller binaries by using a simpler runtime, a different garbage collector, and aggressive dead code elimination.

tinygo build -o convert.wasm -target=wasm -no-debug ./wasm/

Result: ~936 KB (after wasm-opt)

A 7x reduction. TinyGo's LLVM backend and minimal runtime make a massive difference. However, I hit a ceiling. The html-to-markdown library and golang.org/x/net/html parser are non-trivial, and TinyGo's limited reflect support caused compatibility friction.

Generation 3: Rust with scraper + htmd

Next I rewrote the pipeline in Rust using scraper (html5ever-based HTML parser with CSS selectors) and htmd (a turndown.js-inspired Markdown converter). Full DOM tree, density-based content extraction, CSS selector queries.

wasm-pack build --target web --release

[profile.release]
opt-level = 'z'
lto = true
codegen-units = 1
strip = "debuginfo"
panic = "abort"

Result: 936 KB (after wasm-bindgen)

Same as TinyGo. The html5ever parser (Servo's browser-grade HTML engine) is thorough but heavy. It pulls in markup5ever, tendril, phf, string_cache, and about 124 crates total. For a browser-side tool, still too large.

Generation 4: Rust with a custom parser (zero dependencies)

I asked: do I actually need a full DOM tree and CSS selectors?

The answer is no. The pipeline does three things:

Skip noise tags (script, nav, footer, etc.)
Extract the main content region
Map HTML tags to Markdown syntax

None of this requires a tree. A single-pass state machine can do all three in one linear scan. No allocations for a DOM, no selector engine, no string interning.

I dropped every dependency except wasm-bindgen itself and wrote a custom streaming converter:

Tag-level state machine (splits on < and >, not a character-level tokenizer)
Noise depth counter (increments on <nav>, decrements on </nav>, skips all content when depth > 0)
Content extraction via <main> / <article> / <body> substring search
Direct tag-to-Markdown emission (no intermediate representation)

[dependencies]
wasm-bindgen = "0.2"

[profile.release]
opt-level = 'z'
lto = true
codegen-units = 1
strip = true
panic = "abort"

Result: 52 KB

The comparison

Approach	Binary Size	Dependencies	Parsing Strategy
Go (standard)	~7 MB	html-to-markdown, x/net/html	DOM tree
TinyGo	~936 KB	html-to-markdown, x/net/html	DOM tree
Rust (scraper + htmd)	936 KB	124 crates (html5ever, ego-tree, etc.)	DOM tree + CSS selectors
Rust (custom parser)	52 KB	1 crate (wasm-bindgen)	Single-pass state machine

Step	Size reduction	Cumulative from Go
Go to TinyGo	87%	87%
TinyGo to Rust (scraper)	0%	87%
Rust (scraper) to Rust (custom)	94%	99.3%

What I traded away

The custom parser is intentionally less capable than html5ever:

No error recovery for malformed HTML. I split on < and >. Severely broken markup may produce garbled output. In practice, real-world HTML from documentation sites and CMSes is well-formed enough.

No CSS selector queries. No div.content > article. Instead I use simple string-based tag matching for content extraction.

No character encoding detection. I assume UTF-8 (with String::from_utf8_lossy as fallback). This covers 99%+ of modern web content.

Simplified density extraction. Instead of scoring every <div> by text density with heading bonuses, I just grab <main> or <article>. Less precise, but covers the vast majority of documentation and CMS pages.

For my use case. Converting documentation HTML for AI consumption. These tradeoffs are acceptable. The content is typically well-structured and uses semantic HTML.

Key takeaways

The runtime dominates in Go/TinyGo. Even with zero application logic, Go's WASM output starts at hundreds of KB because of the runtime. TinyGo helps enormously but can't eliminate it entirely.

Heavy parsing libraries cost as much as a runtime. html5ever adds ~900KB of compiled code. Comparable to TinyGo's entire runtime. If you're optimizing for size, the parser choice matters as much as the language choice.

Question your abstractions. I didn't need a DOM tree. I didn't need CSS selectors. I didn't need a spec-compliant HTML parser. Removing those abstractions removed 94% of the binary.

opt-level = 'z' + LTO + single codegen unit + strip is table stakes. These Rust release profile settings are mandatory for size-optimized WASM. Without them, you're leaving 2-3x on the table.

panic = "abort" saves ~10-15KB. Removing the unwinding machinery is free if you use Result for error handling. Which you should in WASM anyway.

wasm-opt may not help with modern Rust. Rust 1.97+ emits memory.copy (bulk memory operations) that older wasm-opt versions can't handle. With LTO enabled, LLVM's optimizer already does most of what wasm-opt would.

The numbers that matter

For a tool where every visitor downloads the WASM binary:

52 KB transfers in ~50ms on 3G, ~10ms on 4G
936 KB takes ~900ms on 3G, ~180ms on 4G
7 MB takes 7 seconds on 3G, 1.4 seconds on 4G

That's the difference between instant and "why is nothing happening?"

Try it yourself

The converter is live at html-to-markdown-ai.com. Paste or upload any HTML, get clean Markdown back. Everything runs in your browser. Nothing leaves your machine.

Over to you

Have you gone through a similar WASM size optimization? Or hit a wall where TinyGo or Rust's ecosystem was still too heavy? I'd like to hear about it.

What's your WASM binary size, and have you tried to reduce it?
Did you end up dropping dependencies in favor of custom code?
Any tricks I missed?

The Registry Pattern in TypeScript: How I manage paving patterns in a browser app

Christoph Dieck — Fri, 14 Aug 2026 11:27:41 +0000

The problem

I'm building PatioPlanner, a browser-based tool that lets people draw paved surfaces, choose a laying pattern (herringbone, running bond, basket weave…), and get exact stone counts. The app ships 13 predefined patterns today. New patterns get added regularly.

The question: how do you structure a growing catalog of pattern and brick variants so the system stays extensible? Because if I had to write one more switch(patternType) statement with 13 cases and counting, something had to change.

If you've ever extended a patio in real life, you know the feeling. You start with a neat plan. Then you add one section. Then another. Before you know it, you're cutting irregular edge pieces at weird angles and wondering why you didn't plan the layout better from the start. Same thing happens in code.

The Registry pattern

A Registry is a map that acts as a lookup service. Objects register themselves, and consumers query the registry instead of importing concrete classes. It's a service locator scoped to a single domain concept.

Here's the generic base class I use:

export class Registry<T extends { id: string }> {
  private readonly items = new Map<string, T>();

  register(item: T): T {
    const existing = this.items.get(item.id);
    if (existing !== undefined) return existing; // idempotent
    this.items.set(item.id, item);
    return item;
  }

  getById(id: string): T | undefined {
    return this.items.get(id);
  }

  getAll(): readonly T[] {
    return [...this.items.values()];
  }

  clear(): void {
    this.items.clear();
  }
}

Three things worth noting:

The constraint T extends { id: string } ensures every entry has a stable key. Every item needs a unique identifier. No exceptions.
register() is idempotent. If hot-module reload or test setup re-imports a module, nothing breaks. You get the same result whether you call it once or ten times.
getAll() returns a read-only snapshot. Consumers can iterate but not mutate global state. This keeps things predictable.

Two registries, one shape

PatioPlanner has two domain objects that map nicely onto this: bricks and patterns.

// BrickRegistry.ts
class BrickRegistryManager extends Registry<BaseBrick> {
  getByShape(shape: BaseBrick['shape']): readonly BaseBrick[] {
    return this.getAll().filter((brick) => brick.shape === shape);
  }
}
export const BrickRegistry = new BrickRegistryManager();

// PatternRegistry.ts
class PatternRegistryManager extends Registry<BasePattern> {
  getCompatiblePatternsForBrick(brickId: string): readonly BasePattern[] {
    return this.getAll().filter((p) => p.supportsBrick(brickId));
  }
}
export const PatternRegistry = new PatternRegistryManager();

Each registry extends the generic Registry<T> with domain-specific queries. Bricks can be filtered by shape. Patterns can be filtered by brick compatibility. The UI never needs to know which concrete pattern classes exist. It just asks the registry what's available.

Self-registering modules

Each brick or pattern lives in its own file and registers itself as a side effect:

// patterns/RunningBondPattern.ts
import { PatternRegistry } from '../PatternRegistry';
import { BasePattern } from '../BasePattern';

export class RunningBondPattern extends BasePattern {
  constructor() {
    super('RunningBond', 'Running Bond');
  }

  getCompatibleBrickIds(): readonly string[] {
    return ['standard-rectangular-paver', 'standard-square-paver'];
  }

  calculateFootprints(surface: Surface, brick: BaseBrick): BrickFootprint[] {
    const bounds = this.getSurfaceBounds(surface);
    const footprints: BrickFootprint[] = [];

    let rowIndex = 0;
    for (let y = bounds.minY; y < bounds.maxY + brick.height; y += brick.height) {
      const rowOffset = rowIndex % 2 === 0 ? 0 : brick.width / 2;
      for (let x = bounds.minX - brick.width; x < bounds.maxX + brick.width; x += brick.width) {
        footprints.push({
          patternId: this.id,
          brickId: brick.id,
          x: x + rowOffset, y,
          width: brick.width, height: brick.height,
          rotation: 0,
        });
      }
      rowIndex += 1;
    }
    return footprints;
  }
}

PatternRegistry.register(new RunningBondPattern());

The last line is the key. Importing this file is all it takes to make "Running Bond" available everywhere. No config file to update. No central list to maintain.

Wiring it up

A single barrel file imports all brick and pattern modules, triggering registration:

// lib/brick-patterns/index.ts
export { BrickRegistry } from './BrickRegistry';
export { PatternRegistry } from './PatternRegistry';

// Side-effect imports register built-in entries.
import './bricks/StandardRectangleBrick';
import './bricks/StandardSquareBrick';
import './bricks/HoneycombBrick';
import './patterns/RunningBondPattern';
import './patterns/HerringbonePattern';
import './patterns/BasketWeavePattern';
// ...

Any component that imports from lib/brick-patterns automatically has the full catalog populated. Adding a new pattern is one file plus one import line. That's it.

The contract: BasePattern

Every pattern implements a shared interface through an abstract class:

export abstract class BasePattern {
  constructor(public readonly id: string, public readonly name: string) {}

  abstract getCompatibleBrickIds(): readonly string[];
  abstract calculateFootprints(surface: Surface, brick: BaseBrick): readonly BrickFootprint[];

  supportsBrick(brickId: string): boolean {
    return this.getCompatibleBrickIds().includes(brickId);
  }
}

calculateFootprints is where the math lives. Each pattern gets a surface polygon and a brick, and returns all the placed stone positions. The engine then clips them against the polygon boundary to determine full vs. cut stones.

The base class also provides a shared getSurfaceBounds() helper so concrete patterns don't repeat bounding-box math.

Why this works well

Adding patterns is cheap. Write a class, implement two methods, register it. No routing, no config file, no switch statement to update. One file, self-contained.

Compatibility is bidirectional. A brick knows which patterns it supports. A pattern knows which bricks it tiles. The registry resolves both directions without coupling the two.

The UI stays generic. The pattern picker just calls PatternRegistry.getCompatiblePatternsForBrick(activeBrickId) and renders whatever comes back. It never imports a concrete pattern class.

Testing is straightforward. Each pattern is a pure function: surface in, footprints out. No DOM, no framework dependency. Just input and expected output.

Trade-offs

Nothing is free. Here's what you accept with this approach.

Side-effect imports are implicit. If you forget the import line in the barrel, the pattern silently doesn't exist. TypeScript won't warn you. I accept this because the alternative (a manual array of constructors) scales worse. At 13 patterns it's already tedious to maintain.

Singleton state. The registries are module-level singletons. In a server-rendered or multi-tenant context that could be a problem. For a client-side browser app it's fine. One user, one process, one registry. But watch out in unit tests. State can bleed between suites if you're not careful. That's why the base class exposes clear(). Call PatternRegistry.clear() in an afterEach block and you're good.

Tree-shaking can bite you. The self-registering modules rely on side-effect imports. Modern bundlers (Vite, Webpack, Rollup) can aggressively tree-shake imports that aren't explicitly referenced. If your patterns vanish in production, make sure your bundler respects side effects. Either via "sideEffects": true in package.json or by marking specific files. Everything works in dev. Production is a different story. Classic.

No runtime validation. If two patterns share an id, the second one is silently ignored (idempotent register). A stricter approach might throw, but I found that noisy during development with HMR.

Wrapping up

The Registry pattern is simple. Maybe too simple to write about. But it's exactly that simplicity that makes it hold up as the pattern catalog grows from 3 entries to 13 and beyond. Every new pattern is self-contained, testable, and discoverable without touching any existing code.

If you're building something with a growing catalog of strategies or plugins, a typed registry with self-registering modules is a pattern worth reaching for. It's the kind of foundation that stays solid even when you keep building on top of it.

Check out PatioPlanner at patioplanner.app if you want to see it in action.

Over to you

I'd love to hear where you've used (or avoided) the Registry pattern in your own projects. Plugin systems? Theme engines? Payment providers? Maybe you've found a better alternative for the same problem.

Drop a comment:

What domain did you apply it to?
Did you go with self-registering side-effect imports, or did you prefer an explicit list?
Any gotchas you ran into that I didn't mention?

Looking forward to comparing notes.

ShowDev: I built a bulk HTML-to-Markdown converter that runs entirely in the browser

Christoph Dieck — Tue, 11 Aug 2026 18:52:10 +0000

Most HTML-to-Markdown tools handle one file at a time. You paste some HTML, get Markdown back, repeat. That works for a quick snippet but not when you have 200+ pages from a help center export sitting in a folder.

I needed exactly that. I had a full site mirror (grabbed with wget --mirror) and wanted clean Markdown I could feed into an LLM knowledge base. Nothing I found could handle it without uploading files to a server or converting one by one.

So I built HTML to Markdown AI.

How it works

You drop a ZIP file (or individual HTML files) into the browser
A Go-based conversion pipeline compiled to WebAssembly processes everything locally
You get a ZIP back with clean GitHub-Flavored Markdown, folder structure preserved

No server involved. Your files never leave your machine.

The conversion pipeline

The heavy lifting happens in Go/WASM. The pipeline:

Strips navigation, footers, scripts, styles, and other boilerplate noise
Extracts the main content from the page
Converts to GFM with proper heading hierarchy, tables, code blocks, and links
Handles batch processing so you can throw hundreds of files at it

Why no built-in crawler?

Intentional decision. Downloading HTML from someone else's site has legal implications depending on jurisdiction and terms of service. I don't want to be in that business.

Downloading is also the easy part:

wget -r -l 0 -np -k -E -p -e robots=off \
  --reject-regex '\.(png|jpe?g|gif|svg|webp|woff2?|ttf|css|js|zip|pdf)$' \
  -w 0.5 --random-wait \
  https://docs.example.com/

That gives you a local folder with all the HTML. The hard and annoying part is turning that into clean, usable Markdown. That's what this tool solves.

Stack

Frontend: Astro + Tailwind
Conversion engine: Go compiled to WebAssembly
Processing: Entirely client-side, zero backend

Try it

https://www.html-to-markdown-ai.com

Use cases I've tested it with:

Help center exports (Zendesk, Confluence, custom wikis)
Documentation sites mirrored with wget/httrack
Scraped content for RAG pipelines
Training data prep for fine-tuning

If you work with LLMs and regularly need to get web content into a format they can digest, this might save you some time.

Feedback welcome. What would make this more useful for your workflow?

DEV Community: Christoph Dieck

astro-gallery: four image gallery components for Astro

What astro-gallery is

Setup

JustifiedGallery

ImageGallery

ImageTimeline

MapGallery

What you get for free

astro-gallery vs rolling your own

FAQ

Links

Monte Carlo Simulation: How to go broke eight times faster with 8 Eurojackpot lines

What exactly is a Monte Carlo simulation?

The Setup

The Script

The Result

10 Years of Eurojackpot Data with Polars

Step 1: Setup Your Development Environment

Step 2: Loading the Eurojackpot Draw History

Step 3: The "Reality Check" Script

The Results

Middle-earth and the Digital Infarction

The Suspect in the Server Closet

Hunting Through the Kernel Logs

Why Does This Happen?

The Solution

1. Adjust Driver Options

2. Disable Offloading

3. Create a Systemd Service

The Rescue Mission Conclusion

I Built a Chimney Calculator Because I Wanted a Wood Stove

The origin story

What DruckZugPro does

The physics that makes it interesting

Features beyond the core check

The tech stack

The architecture that made it clean

What I learned

Try it

The Cloud in a Cabinet

Infrastructure as Code: Everything in Git

Cloudflare Tunnels: No Open Ports, Still Reachable

The Architecture

Vaultwarden Instead of KeePass + Google Drive

Deployment via Shared Volumes

FritzBox, IP Changes and the Bypass Rule

Real-World Performance CPU usage during that: rarely above 30%. Thanks to the fiber connection, my friends cannot tell whether the server lives in my cabinet or in a data center.

What's Next in Part 3?

Building a Home Lab with a Lenovo ThinkCentre M920q

When memory runs out

Big power, tiny box

The shopping list

The foundation: Proxmox, Docker, Portainer

Power consumption

What runs on it

Why this works for a home lab

Lessons learned

Over to you

I Built a Lottery Simulator That Shows You Losing Money for 1000 Years

What I built

Why

Tech stack

How the simulator works

The number checker

Data pipeline

Things I learned building this

Try it

From 7MB to 52KB: My WebAssembly Size Optimization Journey

The problem

Generation 1: Standard Go (GOOS=js GOARCH=wasm)

Generation 2: TinyGo

Generation 3: Rust with scraper + htmd

Generation 4: Rust with a custom parser (zero dependencies)

The comparison

What I traded away

Key takeaways

The numbers that matter

Try it yourself

Over to you