DEV Community: V G P

I built Kobol (Kobol Programming Language) — because code is read far more often than it is written

V G P — Thu, 04 Jun 2026 12:00:11 +0000

A maintenance window at 2 a.m.

A few years ago I spent a night staring at a function I had written myself, maybe eight months earlier. It was clever. It was dense. It chained four higher-order calls across two lines and folded a reducer into a ternary inside a map. When I wrote it, I felt smart. At 2 a.m., trying to fix a rounding bug in it, I felt nothing of the sort.

I rewrote it the next morning as a boring, plain loop with names that said what they meant. The bug was obvious once the code stopped showing off. It took me longer to type. It took everyone after me far less time to understand.

That night stuck with me. We spend a tiny fraction of a program's life writing it, and almost all of the rest reading it: debugging, reviewing, onboarding, patching it at 2 a.m. years later. And yet so much of our tooling optimizes for the act of writing: fewer keystrokes, denser expressions, cleverer symbols. We optimize the cheap part and pay for it in the expensive part.

Today I'm releasing Kobol, a small, opinionated language that takes the opposite bet.

Kobol (with a K) is inspired by COBOL. It is not COBOL. The Kobol language is new and independent, with its own syntax, compiler, and runtime. It isn't a COBOL dialect, isn't source-compatible with COBOL, and isn't affiliated with or endorsed by any COBOL vendor or standards body.

Going back to a very old, very good idea

Here's the question that started it: why do we write programs in syntax that doesn't read like the language we think in?

We had an answer to that once. In 1959, a committee called CODASYL set out to build a programming language that ordinary people, not just specialists, could read. The result was COBOL, and the people behind it were serious computer scientists with a genuinely radical goal for the time: make programs readable. Grace Hopper's earlier work on FLOW-MATIC had already argued that English-like commands were not a gimmick but a feature, and that idea carried straight into COBOL's design. Jean Sammet and the rest of the committee built a language where a statement like ADD 1 TO total meant exactly what it said, to a programmer and to the accountant reading over their shoulder.

I want to be clear about something, because the internet loves to dunk on COBOL: those people were right about the important part. The systems they designed have run the world's payrolls, banks, and government benefits for over sixty years. Sixty years. Most of our frameworks don't survive sixty months. That is not an accident of inertia. It's a consequence of a design that prioritized clarity and stability over cleverness. When the original designers talked about the future, they talked about programs that would outlive their authors and still be legible to whoever inherited them. They were thinking about my 2 a.m.

What they couldn't have planned for was the world the language got chained to: the mainframe, fixed-column punch-card layouts, divisions and paragraphs and ceremony that made sense in 1959 and make a 25-year-old developer bounce off the language today. The good idea got buried under the era it was born in.

So I took the idea, and left the era behind

Kobol keeps what was good — English-like, readable, says-what-it-means syntax — and drops everything that tied it to a specific decade of hardware.

Here's a complete Kobol program:

NOTE:
  Hello World in Kobol — the simplest possible program.
  Block comments read like English: NOTE: ... END-NOTE.
END-NOTE

PROGRAM HelloWorld
  VERSION "1.0"

DATA:
  greeting : TEXT = "Hello, World!"

PROCEDURE Main:
  DISPLAY greeting
  DISPLAY "Welcome to Kobol — a modern COBOL-inspired language."
  STOP RUN
END-PROCEDURE

You can read that out loud and a non-programmer would mostly follow it. That's the whole point.

But readable doesn't have to mean toy. Here's real business logic — invoice processing with money, conditions, and error handling:

PROCEDURE ProcessOneInvoice:
  ADD 1                        TO summary.total-count
  ADD current-invoice.amount   TO summary.total-amount

  IF current-invoice.Paid:
    ADD 1 TO summary.paid-count

  ELSE IF current-invoice.Overdue:
    ADD 1 TO summary.overdue-count
    PERFORM CalculateLateFee
    ADD adjusted-amount TO summary.total-outstanding

  ELSE:
    ADD 1 TO summary.pending-count
    ADD current-invoice.amount TO summary.total-outstanding
  END-IF
END-PROCEDURE

Notice current-invoice.Paid and .Overdue. Those aren't magic. They're named conditions declared on the record itself:

RECORD Invoice:
  invoice-id    : INTEGER
  customer-name : TEXT(100)
  amount        : MONEY(12.2)
  due-date      : DATE
  paid          : BOOLEAN
  status-code   : TEXT(1)
    CONDITION Pending WHEN status-code = "P"
    CONDITION Paid    WHEN status-code = "X"
    CONDITION Overdue WHEN status-code = "O"

The business rule lives next to the data it describes, in words. Six months from now, nobody has to decode what status-code = "X" means scattered across the codebase. It says Paid right where you read it.

The parts that are firmly in this century

This is where Kobol stops being a nostalgia trip:

It runs on the JVM. No mainframe required. Kobol compiles to JVM bytecode. It runs on your laptop, in a container, in CI, on whatever boring Linux box you already have. There is no special hardware, no emulator, no licensed runtime. If you can run Java, you can run Kobol.
Full Java interop. You can IMPORT and call Java directly, so the entire JVM ecosystem is available. You're not on an island.

  IMPORT java.time.LocalDate
  IMPORT java.time.format.DateTimeFormatter AS DateFmt

  PROCEDURE Main:
    CALL LocalDate.now GIVING today
    CALL DateFmt.ISO_LOCAL_DATE.format USING today GIVING report-date-str

Exact decimal money, built in. MONEY(12.2) is real fixed-point decimal, not a float you cross your fingers over. Finance code shouldn't have to fight the language to add two numbers correctly.
Modern data work. Filtering, sorting, and taking the top N reads like a sentence:

  COMPUTE top5 = customer-list FILTER WHERE active SORT BY balance DESCENDING TAKE 5

Concurrency without the ceremony, structured error handling with TRY / ON, records, lists, pipelines. The conveniences you'd expect from a language designed now.

Who I'm hoping finds this

Honestly? The next generation.

There's a strange situation in our industry: an enormous amount of critical software is written in a style most new developers have never been taught and have been quietly told to avoid. The people who maintain it are retiring. The work isn't going anywhere.

I'm not asking anyone to go learn 1959. I'm hoping a few curious people — students, early-career devs, anyone who's ever been burned by code they couldn't read — pick up Kobol, feel how natural readable code can be, and take that instinct with them everywhere, whatever language they write in next.

And if you're coming from COBOL: existing COBOL programs don't run on Kobol as-is. They have to be refitted and rewritten. I won't pretend otherwise. But because Kobol keeps the familiar English-like, readable shape, moving from COBOL to Kobol is a far gentler journey than porting a system into a syntax that looks nothing like what your team has read for decades. The mental model carries over; that's worth a lot on a migration.

A genuine thank-you

Credit where it belongs: Grace Hopper, Jean Sammet, and the CODASYL committee decided, in 1959, that code should be something humans can read. Kobol carries that idea forward into a world they'd recognize and a runtime they'd never have imagined. The foundational insight is theirs; building a modern language on top of it is the work I'm proud to have done.

Try it

Kobol is open source and out now. Pick whichever line matches your machine. They all leave you with a working kobol command.

macOS (Apple Silicon) — Homebrew

brew tap kobol-lang/tap
brew install kobol
kobol --version

Linux — native binary, no JVM needed

# pick your arch: linux-x86_64 or linux-aarch64
curl -fsSL https://github.com/kobol-lang/kobol/releases/latest/download/kobol-linux-x86_64.tar.gz | tar xz
sudo mv kobol /usr/local/bin/
kobol --version

Windows — Chocolatey

choco install kobol
kobol --version

Any machine with a JVM 21+ (Intel Macs included) — the fat JAR

# grab the latest kobolc-<version>.jar from the releases page:
#   https://github.com/kobol-lang/kobol/releases/latest
curl -fsSL -O https://github.com/kobol-lang/kobol/releases/download/v0.1.0/kobolc-0.1.0.jar
java -jar kobolc-0.1.0.jar --version
# handy alias:
alias kobol="java -jar $PWD/kobolc-0.1.0.jar"

Docker

docker pull ghcr.io/kobol-lang/kobol:latest
docker run --rm ghcr.io/kobol-lang/kobol:latest --version

The rest:

🌐 Site: kobol-lang.org
💻 Source: github.com/kobol-lang/kobol
📖 Language spec: LANGUAGE_SPEC.md

If you build something with it, or just have opinions, I'd love to hear them. Write code your future self can read at 2 a.m.

— the person who got tired of decoding their own cleverness

We Keep Building Bigger Walls Around the Wrong Thing

V G P — Fri, 15 May 2026 22:34:14 +0000

There's a species of tree in dense forests that grows toward whatever gap in the canopy lets light through. It doesn't ask permission. It doesn't register with the other trees. It just moves toward what it needs, and the forest works because of that — not in spite of it.

We don't build software that way anymore.

At some point we decided that before a user can do anything — read a note, save a preference, pick up where they left off — they need to announce themselves to a server, wait for a response, get issued a token, and carry that token everywhere like a passport in a country that checks papers at every door.

And when that system gets too heavy, we don't question the system. We add another layer to it.

There are entire job functions dedicated to managing this. Entire platforms — some charging by the login — whose whole purpose is to sit between your user and your app and say: prove yourself first. The infrastructure behind a simple "remember my theme preference" can span multiple availability zones, three third-party vendors, and a compliance audit.

Nobody stops to ask whether this was the only way.

I'm not arguing against security. I'm asking about proportion.

A river doesn't move water by building a bigger pump. It follows the path of least resistance, deposits what it carries at the delta, and keeps moving. The water arrives. Nothing registers. Nothing authenticates. The delta doesn't care where the water came from — it cares what the water does when it gets there.

The session token model is the opposite of this. It says: water cannot flow until we verify it's water, issue it a credential, log that it arrived, and stand ready to revoke its water-ness at any time. Then we wonder why everything feels sluggish.

What I've been working on with tessera starts from a different assumption.

The user already has the device. The device already has the browser. The browser already has a crypto engine sitting idle — AES-256-GCM, PBKDF2, Web Crypto — powerful enough to handle what most apps actually need to protect. The passcode stays local. The key never leaves the device. The server never enters the picture.

const vault = await Tessera.unlock('abc123');
await vault.local.setItem('preferences', JSON.stringify(prefs));

No round-trip. No token. No registration. The user's data is encrypted with their own passcode, in their own browser, and only they can read it.

That's not a compromise. For a significant class of problems, that's strictly better — because there's no central store to breach, no credential database to leak, no session to hijack in transit.

There's a concept in structural design called the minimum viable structure — the least amount of material you can use while still holding the load. Bridges built this way are elegant. They carry weight precisely because they don't carry anything extra. Every beam earns its place.

Most auth infrastructure fails this test badly. It carries weight that exists to justify itself: the logging layer that feeds the dashboard nobody checks, the token refresh cycle that prevents a session timeout nobody would have noticed, the password complexity rules enforced by a system that hashes the password anyway.

tessera tries to be the minimum viable structure for what it actually does. Encrypt the data. Derive the key locally. Let the value expire when it should. Notice when something looks wrong.

vault.local.setItem('one_time_code', value, {
  ttl: 30_000,
  maxReads: 1,
});

That's it. The code is gone after one read. No server involved in that transaction. No revocation request. It just ceases to exist.

The immune system doesn't keep a registry of every pathogen it's ever seen stored on a central server somewhere. It carries the memory in the cells themselves — distributed, local, present at the point of contact. When something unfamiliar shows up, the response comes from within, not from a round-trip to headquarters.

tessera does something similar with honey keys — decoys planted inside storage that look identical to real entries. Real code never touches them. Anything enumerating storage and guessing will.

vault.on('honey-hit', (event) => {
  // something is probing your storage
});

The detection lives where the data lives. No external service needed.

I'm not trying to kill authentication. There are things that genuinely require a server, a verified identity, a shared secret negotiated between two parties. I'm not pretending otherwise.

But I think we've spent so long inside one way of thinking about identity and access that we've stopped noticing the assumptions embedded in it. That every interaction needs a server to bless it. That local state is inherently less trustworthy than remote state. That the right response to a security problem is always more infrastructure.

Some problems don't need a bigger wall. They need a different shape entirely.

tessera is small. It's a start. But it's built on the premise that the device in your user's hand is already powerful enough to protect their data — if you give it the right tools and get out of the way.

npm install @mrtinkz/tessera

GitHub — I'd genuinely like to know where you think this line of thinking breaks down.

@mrtinkz/tessera v0.1.2 — I Wasn't Done Yet

V G P — Fri, 15 May 2026 22:19:49 +0000

After shipping v0.1.0 I did what most developers do after a release — I opened my own app and started poking around.

The values were ciphertext. Good. But the keys were sitting right there in plain English. auth_state. cart_items. pending_payment. Anyone who opened DevTools knew exactly what I was keeping track of, even if they couldn't read the contents. That shouldn't have bothered me as much as it did. But I couldn't let it go.

So I kept going.

Your keys now mean nothing to anyone but you

tessera now runs every key name through HMAC-SHA-256 before it touches storage. What you call cart_items, tessera stores as t_3a9f7c2e. Close DevTools, reopen it, and all you see is:

t_3a9f7c2e  →  <ciphertext>
t_b2d4f110  →  <ciphertext>
t_03e8a5cc  →  <ciphertext>

The mapping only exists in memory, derived from your passcode. Lock the vault — it's gone.

Some of those entries are fake

Here's the thing I'm most pleased with: not all of those entries are real. tessera automatically plants honey keys — decoys that look exactly like real values. Same key format, same ciphertext format. Completely indistinguishable.

Real code never touches them. Only something enumerating your storage and guessing would. That's the tripwire.

vault.on('honey-hit', (event) => {
  // something is probing your storage
});

Values that delete themselves

Some data shouldn't outlive its purpose. A one-time code. A recovery token. A payment session. v0.1.2 lets values carry their own expiry:

vault.local.setItem('one_time_code', value, {
  ttl: 30_000,   // gone after 30 seconds
  maxReads: 1,   // gone after first read
});

There's no background timer running. The check happens at read time — the moment something requests the value, tessera looks at the write timestamp and acts. If it's expired, it wipes before returning anything. A timer can be cleared by an attacker. A check on read cannot.

Don't want to configure every key manually? Sensitivity presets have you covered:

vault.local.setItem('recovery_code', value, { sensitivity: 'critical' });
// 5 minute TTL, 3 max reads, wiped at first sign of trouble

It notices things that shouldn't be happening

The last thing I added was a suspicion engine. If reads start coming in faster than any human could trigger them, tessera notices. If an HMAC check fails on a read — meaning the value was touched outside the API — tessera notices that too.

You decide what happens:

Tessera.unlock('123456', {
  suspicion: {
    rateLimit: { callsPerSecond: 10 },
    onSuspicion: 'lock',
  },
});

lock, wipe, or throw. tessera just makes sure something happens.

The encryption in v0.1.0 was the obvious part. v0.1.1 is all the stuff I couldn't stop thinking about after — the layers that make it hard to learn anything useful from your storage even when someone already has full read access.

npm install @mrtinkz/tessera

GitHub — feedback always welcome.

I Built a Zero-Dependency Browser Storage Encryption Library — Here's Why

V G P — Thu, 14 May 2026 05:21:55 +0000

A few months ago I found myself auditing a side project and noticed something uncomfortable: I was storing sensitive user preferences, cart data, and session tokens in localStorage — completely in plaintext. Anyone with DevTools open could read it in two seconds.

The obvious fix is "just encrypt it." But when I went looking for a library that actually did this well, I kept running into the same problems: heavy dependencies, weak key derivation, or APIs that felt bolted on as an afterthought. So I built tessera.

What tessera does

One passcode. All your browser storage — localStorage, sessionStorage, IndexedDB, and cookies — encrypted with AES-256-GCM. The key is derived from PBKDF2-SHA-256 at ≥ 310,000 iterations (the OWASP 2024 minimum), and it never leaves the Web Crypto engine as raw bytes.

The API is a drop-in replacement for the storage APIs you already use:

import { Tessera } from '@mrtinkz/tessera';

const vault = await Tessera.unlock('abc123');
await vault.local.setItem('cart', JSON.stringify(cartData));
const cart = await vault.local.getItem('cart'); // plaintext back
vault.lock(); // zeroes the in-memory key

No server round-trips. No cloud keys. No dependencies.

The threat model I was actually designing against

Most encryption libraries stop at "we encrypt the data." tessera is built against the OWASP browser storage threat model, so let me be specific about what it protects and what it doesn't.

What it protects against:

Passive observer in DevTools — storage values are ciphertext. Useless without the key.
XSS reading storage — same deal. The attacker gets ciphertext.
Offline brute force — PBKDF2 at 310k iterations costs roughly 1 second per attempt on modern hardware.
Key exfiltration via heap dump — extractable: false means the raw key bytes never exist in JavaScript memory.
On-device brute force — configurable lockout: wipe all storage, apply exponential backoff, or throw immediately after N failed attempts.

What it doesn't protect against:

tessera protects your data at rest — when the vault is locked, everything in storage is ciphertext. Unlocking doesn't decrypt everything at once; it just derives the key and holds it in memory. Individual values only decrypt on demand when you call getItem.

The one scenario where this breaks down is if your page already has an XSS vulnerability. An attacker running code on your page has the same access you do — they can call vault.local.getItem() while the vault is unlocked and get plaintext back, one value at a time. They can't steal the raw key bytes (extractable: false blocks that), but they don't need to. Fix XSS first; tessera handles the rest. The threat model docs go deeper on this.

The crypto internals

Each stored value gets its own salt and IV. The stored format is:

salt(16) ‖ iv(12) ‖ ciphertext ‖ tag(16)

The vault salt lives in localStorage so the same passcode re-derives the same key across sessions — you unlock once per session, not once per page load.

Key derivation:

PBKDF2(passcode, vaultSalt, 310_000 iterations, SHA-256) → AES-256-GCM key

The CryptoKey is created with extractable: false. The Web Crypto engine holds the key material; your JavaScript never sees the raw bytes.

The PIN pad problem

I wanted to mitigate keyloggers and click-sequence recording. The naive approach — an HTML grid of buttons with digit labels — fails because:

Keyloggers read keydown events
Click-sequence recording reads which DOM element was clicked
The digit labels on buttons reveal the sequence

tessera ships a Canvas-based PIN pad. Digit positions are randomised on every render. No DOM element carries a digit value. A click recorder sees coordinates, not digits.

import { renderPinPad } from '@mrtinkz/tessera';

renderPinPad(document.getElementById('pin'), {
  onUnlock: async (passcode) => {
    const vault = await Tessera.unlock(passcode);
  },
  randomize: true,
  length: 6,
});

You can style it with CSS custom properties:

.tessera-pin-pad {
  --tessera-pad-bg: #1a1a2e;
  --tessera-btn-bg: #16213e;
  --tessera-btn-color: #e2e8f0;
  --tessera-btn-hover: #0f3460;
  --tessera-btn-size: 64px;
  --tessera-indicator-color: #4ade80;
}

Framework support

tessera ships ESM, CJS, and IIFE builds. There are native adapters for React, Vue 3, Svelte, and Angular so you get a hook/store/service rather than managing vault state yourself.

React:

'use client';
import { useTessera } from '@mrtinkz/tessera/react';

function SecureApp() {
  const { vault, isLocked, unlock, lock } = useTessera({ idleTimeout: 600_000 });

  if (isLocked) return <PinPad onUnlock={unlock} />;
  return <Dashboard vault={vault} onLock={lock} />;
}

Vue 3:

<script setup lang="ts">
import { useTessera } from '@mrtinkz/tessera/vue';
const { vault, isLocked, unlock, lock } = useTessera({ idleTimeout: 600_000 });
</script>

Svelte:

<script lang="ts">
  import { tesseraStore } from '@mrtinkz/tessera/svelte';
  const { vault, isLocked, unlock, lock } = tesseraStore({ idleTimeout: 600_000 });
</script>

There's also an Angular TesseraModule and TesseraService if that's your stack.

Idle timeout and cross-tab sync

The vault auto-locks after a configurable idle period. When it locks, it broadcasts over BroadcastChannel so every open tab locks simultaneously. No stale unlocked tabs sitting in the background.

const vault = await Tessera.unlock('abc123', {
  idleTimeout: 900_000,    // 15 minutes
  lockoutAttempts: 5,
  lockoutAction: 'wipe',   // nuclear option
});

Install

npm install @mrtinkz/tessera

CDN:

<script src="https://cdn.jsdelivr.net/npm/@mrtinkz/tessera/dist/index.global.global.js"></script>
<script>
  const { Tessera } = TesseraLib;
  Tessera.unlock('abc123').then((vault) => {
    vault.local.setItem('theme', 'dark');
  });
</script>

Browser support: Chrome/Edge 89+, Firefox 86+, Safari 15+. Also works in Deno, Bun, and Cloudflare Workers.

I'd love feedback — especially from anyone who's thought hard about browser storage security. What's missing? What would you do differently? Drop it in the comments or open an issue on GitHub.

Docker Desktop Won't Start After a BIOS Update? Check This First

V G P — Tue, 12 May 2026 02:36:29 +0000

I spent way too long troubleshooting this. Reinstalled Docker Desktop multiple times, wiped config folders, checked WSL, verified Hyper-V — nothing worked. Turns out the fix was two PowerShell commands.

Here's what happened and how to fix it fast if you run into the same thing.

The Situation

My ThinkPad T480 got a BIOS and firmware update. After rebooting, Docker Desktop stopped launching. No error dialog, no crash message — it just silently died every time. The whale icon would never show up in the system tray.

Running wsl --list showed no docker-desktop distro. The logs had nothing useful — just Docker initializing and then abruptly stopping. Looked like a WSL problem, a virtualization problem, or a busted installation. It was none of those.

What Was Actually Wrong

The BIOS update disrupted Windows service configurations. The Docker Desktop backend service — com.docker.service — got flipped to Manual startup, so it was no longer running when Windows booted.

Docker Desktop's UI process depends entirely on that backend service. If the service isn't running, the UI launches, finds nothing to connect to, and kills itself immediately. No warning, no useful error — just gone.

The Fix

Open PowerShell as Administrator and run:

Start-Service com.docker.service
Get-Service com.docker.service

You should see Status: Running. Then lock it in so it survives future reboots:

Set-Service com.docker.service -StartupType Automatic

Then launch Docker Desktop normally from the Start Menu (or via PowerShell):

Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"

That's it. Whale icon appears, engine starts, everything works.

Save This for Next Time

If Docker Desktop ever silently dies on you again, run this before doing anything else:

Get-Service com.docker.service

If the status is Stopped, just start it. You'll save yourself an hour of unnecessary reinstalls.

And if the service is running but Docker still won't start, then check the actual log for a real error:

Get-Content "$env:LOCALAPPDATA\Docker\log\host\com.docker.backend.exe.log" -Tail 50 | Select-String -Pattern "error|fatal|panic|fail" -CaseSensitive:$false

Tested on ThinkPad T480, Windows 11, WSL2 with Debian. Hope this saves someone the hour I lost.