The idea is simple: help golfers log range sessions quickly and review distance-control patterns over time without turning practice into data-entry homework.

This is not a launch monitor product. It is not a full swing analytics suite. It is not trying to replace TrackMan, Arccos, or a lesson. It is a focused tool for a smaller problem:

When you're on the range working on distance control, how do you capture just enough information to notice patterns and improve?

That constraint shaped the entire app.

Why I Built It

I wanted something I could realistically use between balls at the range.

That pushed the product in a few specific directions:

• large tap-driven controls

• minimal typing

• simple target selection

• estimated miss bands instead of fake precision

• local-only persistence

• no account system

• no sync

• no backend

The point is not to pretend range practice is richer in data than it really is. Most of the time, it's approximate. You know the target. You know whether a shot finished short, pin high, or long. You know whether it leaked left or right. You may not know the exact yardage miss, but you usually know the band.

That turns out to be enough, as long as the app stays fast.

What The MVP Does

The current MVP includes:

• editable bag setup with default clubs

• fixed-target sessions

• random-target sessions

• tap-driven shot logging

• distance and lateral miss bands

• session summaries

• local session history

• session detail, rename, and delete support

The app stores completed sessions locally on device. No login. No sync. No cloud layer.

That simplicity is intentional. I wanted a real first release, not a platform plan in disguise.

What Changed As I Built It

Even a small app picks up real product decisions quickly.

A few examples:

• shot entry originally felt more form-like than range-friendly, so I changed the flow to prioritize miss amount first

• summary and history flows needed better navigation and rename/delete support

• outdoor readability mattered more than I first gave it credit for, especially for golfers in the 50+ range who do not want to keep grabbing reading glasses between practice shots

• testing on a physical Android tablet surfaced a very normal issue: I first installed the wrong kind of APK and hit a native architecture mismatch that never showed up in the emulator

That last one was a good reminder that device testing still matters, even for a small app.

Where It Is Now

At this point:

• the app runs in the Android emulator

• the app runs on a physical Android 15 tablet

• the Play upload key is created

• the signed release bundle is built

• the Play Store listing is set up

• the screenshots, icon, feature graphic, and privacy policy are in place

Which means I am now in the least glamorous and most real part of shipping: store setup, release tracks, policy forms, and recruiting enough testers to satisfy Google Play's closed-testing requirements.

The Current Hurdle

For a new app like this, Google Play requires a closed test before I can apply for production access.

That means I need at least 12 testers opted into the closed test for 14 continuous days.

So at the moment, the main job is not coding. It's finding enough Android testers to get through that gate.

What I Need Next

If you're an Android golfer and you'd be open to helping test Range Session Tracker, I'd love to hear from you.

The ask is simple:

• join the Google Play closed test

• stay opted in for 14 days

• try the app if you can

• send feedback if anything feels rough or confusing

If that sounds interesting, message me directly or reply wherever you found this post.

This has been a fun project to build in public because it keeps the work honest. It's easy to talk about ideas. It's better to talk about what actually shipped, what changed, what broke on real hardware, and what still stands between "working app" and "available app."

Range Session Tracker is real, it's running, and now it needs testers.

BullMQ is excellent. Redis-backed queues, retries, delayed jobs, priorities, parent-child flows: it gives you a lot of power. But once you start running real workloads through it, the operational questions get more specific.

At first, queue depth feels like enough.

How many jobs are waiting?

How many are active?

How many failed?

How many completed?

Those are useful questions, and they were the first things bull-der-dash answered. The dashboard could show live queue state, inspect jobs, expose Prometheus metrics, and run cheaply in Kubernetes.

But queue depth is not workload visibility.

Eventually I wanted to answer different questions:

• Which job types are running most often?
• Which jobs are slow?
• What is the p95 or p99 completion time by job name?
• Which workloads are failing?
• Are failures isolated to one queue or one job type?
• During a spike, what actually changed?

A queue can look healthy at the depth level while one specific workload is getting slower. A queue can drain quickly while hiding a rising failure rate. A completed count can tell you that work finished, but not whether the work took 50 milliseconds or 30 seconds.

That gap is what pushed me to add workload metrics.

The Tempting Bad Idea

BullMQ stores completed and failed jobs in Redis. Job hashes include useful fields like the job name and timestamps. In particular, BullMQ jobs expose fields such as:

• name
• timestamp
• processedOn
• finishedOn
• failedReason
• attemptsMade

So the obvious idea is simple:

1. Scan the completed and failed job sets.
2. Read each job hash.
3. Calculate finishedOn - processedOn.
4. Export success/failure counts and duration percentiles.

That would work in a demo.

It is also exactly the wrong shape for a production monitoring path.

The cost of that design grows with retained job history. If you retain thousands or millions of completed jobs, a metrics collector built around scanning retained jobs becomes more expensive as history grows.

Even worse, if that work happens during a Prometheus scrape, /metrics stops being a cheap in-memory export and becomes an accidental Redis workload.

That is not a small detail.

A monitoring tool should reduce uncertainty. It should not become part of the production problem.

The Performance Constraint

bull-der-dash already had a performance philosophy:

• frequently polled pages should stay cheap
• queue stats should use lightweight Redis commands like LLEN and ZCARD
• expensive diagnostics should stay off hot paths
• /metrics should export in-memory Prometheus data
• Redis scans should be treated with suspicion

That philosophy matters because queues can be spiky. A normal day might look quiet, then suddenly fan out to hundreds or thousands of queued jobs.

In our case, peak fan-out can mean around 1,500 jobs waiting across BullMQ queues. That is not enormous by distributed systems standards, but it is enough that careless observability can become visible load.

The goal was not merely "add more metrics."

The goal was:

Add workload visibility without making Redis pay for every scrape.

That constraint shaped the whole design.

The Better Source of Truth: BullMQ Events

BullMQ already emits events.

For each queue, BullMQ writes to an event stream in Redis. Instead of repeatedly asking Redis, "What jobs have ever completed?", the collector can ask, "What has happened since I last checked?"

That changes the scaling model.

Bad model:

metric cost ~= retained jobs

Better model:

metric cost ~= newly finished jobs

That is the key design move.

The workload metrics collector now watches BullMQ event streams in the background. It listens for terminal job events, currently completed and failed.

The implementation lives in the internal/workloadmetrics package in the bull-der-dash repository. The important part is not a large framework or a complicated metrics pipeline; it is a small background collector that reads BullMQ events incrementally and records Prometheus metrics in memory.

When one appears, it reads only the fields it needs from the job hash:

HMGET bull:{queue}:{jobId} name processedOn finishedOn

Then it records Prometheus metrics in memory.

Prometheus scrapes /metrics, and /metrics does not need to query Redis to produce those workload metrics.

The flow looks like this:

BullMQ worker
    |
    v
Redis stream: bull:{queue}:events
    |
    v
bull-der-dash workload collector
    |
    +--> HMGET bull:{queue}:{jobId} name processedOn finishedOn
    |
    v
Prometheus counters and histograms
    |
    v
Grafana

This is the shape I wanted: incremental, cheap, and operationally understandable.

The Metrics

The first version exposes a small set of workload metrics.

The metric definitions are in internal/metrics, and the collector code is in internal/workloadmetrics.

Completed and failed job counts:

bullmq_jobs_finished_total{queue, name, result}

Job processing duration:

bullmq_job_completion_duration_seconds_bucket{queue, name, result, le}
bullmq_job_completion_duration_seconds_sum{queue, name, result}
bullmq_job_completion_duration_seconds_count{queue, name, result}

Collector health:

bullmq_workload_event_lag_seconds{queue}
bullmq_workload_events_read_total{queue, event}
bullmq_workload_events_dropped_total{queue, reason}
bullmq_workload_job_lookup_errors_total{queue, reason}

The name label is the BullMQ job name. The result label is either completed or failed.

That gives Grafana enough to answer the questions I actually care about.

For example, completed and failed jobs over a five-minute window:

sum by (queue, name, result) (
  increase(bullmq_jobs_finished_total[5m])
)

p95 processing duration by queue and job name:

histogram_quantile(
  0.95,
  sum by (le, queue, name) (
    rate(bullmq_job_completion_duration_seconds_bucket[5m])
  )
)

Failure ratio by queue and job name:

sum by (queue, name) (
  rate(bullmq_jobs_finished_total{result="failed"}[5m])
)
/
sum by (queue, name) (
  rate(bullmq_jobs_finished_total[5m])
)

Collector lag:

bullmq_workload_event_lag_seconds

These are simple metrics, but they move the dashboard from "how deep are my queues?" to "what work is actually happening?"

Cardinality Still Matters

Adding name as a label is useful, but labels are not free.

Prometheus cardinality can get out of hand if labels contain unbounded values. A queue name is usually safe. A job name is often safe. Arbitrary job data is not.

So the collector does not label metrics by job payload, title, user ID, tenant ID, or anything else that might explode.

It also caps the number of job names per queue.

If a queue exceeds the configured job-name limit, additional job names are grouped under:

__other__

If a terminal event is observed but the job hash is already gone before the collector can read it, the count is still recorded under:

__unknown__

That case can happen if completed or failed jobs are removed aggressively. Counts still matter, but duration samples require processedOn and finishedOn.

Those guardrails are not glamorous, but they are the difference between useful production metrics and a Prometheus cardinality incident.

A Small Architecture Compromise

Originally, bull-der-dash leaned hard into being stateless.

That was the right default. Stateless HTTP handlers are easy to scale, easy to reason about, and easy to operate.

But event-derived metrics need a tiny bit of state:

• the last stream ID read per queue
• in-memory Prometheus counters and histograms
• bounded job-name tracking

So I refined the architecture rule.

The web request path stays stateless. The dashboard, job inspection pages, health checks, and /metrics export do not depend on session state.

But optional background collectors are allowed to maintain small, ephemeral telemetry state.

That is a practical distinction:

Stateless HTTP serving v. Ephemeral state for telemetry collection.

I did not add leader election or distributed coordination in the first version. The current deployment runs a single bull-der-dash instance, so a single in-process collector is the simplest correct design.

If we later run multiple replicas, the collector will need explicit ownership coordination or a separate single-replica deployment. Otherwise multiple pods could read the same BullMQ events and double-count.

That is a good future problem. It did not need to be solved on day one.

Why Go Has Been a Good Fit

One of the quiet wins in this project has been the choice to build bull-der-dash in Go.

In my environment, bull-der-dash sits around 12 MB RSS. A TypeScript-native BullMQ dashboard we compared against was closer to 500 MB RSS while offering less of the workload visibility we wanted.

That difference matters.

A monitoring tool should be cheap enough to leave running continuously. It should not become another meaningful workload to operate.

This is not a "Go beats TypeScript" argument. TypeScript is a great application language, and existing BullMQ dashboards are useful. The point is that for production-adjacent tooling, the operating model matters.

Go gives this project a nice shape:

• one small binary
• low idle memory
• simple container packaging
• straightforward Prometheus integration
• cheap background goroutines
• predictable Kubernetes footprint

That makes it easier to add observability without worrying that the observability tool itself is becoming expensive.

The most important performance feature of an internal monitoring tool might be that you barely notice it running.

What Changed Operationally

The rollout was intentionally boring.

The collector is behind a feature flag:

WORKLOAD_METRICS_ENABLED=true

The configuration is exposed through the Helm chart as well, so the same binary can run with workload metrics disabled by default and enabled per environment.

By default, it starts from new events only:

WORKLOAD_METRICS_START_ID=$

That means no startup backfill and no surprise Redis scan. Existing completed jobs are not retroactively counted by the workload metrics. The metrics reflect events observed while the collector is running.

That tradeoff is fine for operational dashboards.

For rollout, the sequence was:

1. Enable in a local simulator environment.
2. Confirm event reads.
3. Confirm completed job counts.
4. Confirm duration histograms.
5. Watch collector lag.
6. Deploy to demo.
7. Build Grafana panels manually.
8. Promote to production.

That is exactly the kind of rollout I want for production-adjacent tooling: incremental, visible, and easy to back out.

What I Can See Now

With the new metrics, Grafana can show:

• completed jobs by queue and job name
• failed jobs by queue and job name
• p95/p99 duration by workload
• failure ratios
• event collector lag
• lookup errors when job hashes disappear too quickly
• whether job-name cardinality is escaping expectations

That is a much better operational picture than queue depth alone.

Queue depth still matters. It tells me about backlog.

But workload metrics tell me about behavior.

That distinction is the whole point.

Project Links

The project is open source here:

• bull-der-dash on GitHub
• Helm chart and deployment docs
• Workload metrics usage examples

If you are running BullMQ and want lightweight visibility into queue depth, job inspection, Prometheus metrics, and workload duration percentiles, I would love feedback or issues.

Closing Thought

The lesson from this work is not specific to BullMQ.

It is a general observability lesson:

The easiest metric to compute is not always the safest metric to collect.

For BullMQ, scanning retained jobs would have been easy to understand, easy to implement, and easy to regret.

Reading event streams incrementally is a better fit for the system. It gives us the workload visibility we need while preserving the performance characteristics that made bull-der-dash useful in the first place.

Observability should make production clearer.

It should not make Redis sad.

For the past three decades, I’ve had a complicated relationship with Java. It was one of the first languages I wrote “real” software in, but over the years I drifted toward more expressive, flexible ecosystems — Ruby, Elixir, TypeScript. Java always felt like something you had to fight a little to enjoy.

But lately, something’s shifted.

I’ve been circling back to the JVM, not because I miss Java, but because I’ve been pulled in by Kotlin — a language that manages to feel modern, expressive, and dare I say… joyful?

If Java is the multi-tool that gets the job done, Kotlin is the well-balanced wedge that just feels right in your hand.

So what’s this series?

This “What’s in the Bag” JVM series is my way of exploring the tools and ideas that are making Java exciting again — at least for me. I'm focusing less on traditional enterprise stacks and more on lightweight, elegant technologies that feel closer to the kind of development I enjoy in TypeScript.

Here’s what you can expect:

1. A Kotlin primer – Why I think it’s the best thing I’ve used on the JVM in a long time.

2. A look at Ktor – A JetBrains-built server framework that makes writing APIs in Kotlin surprisingly fun.

3. Some working examples – APIs, dev tools, and patterns that remind me of the joy of fast iteration.

4. A few comparisons – Why these tools are worth a second look even if you’ve moved past Java.

Why Kotlin?

Kotlin hits a sweet spot that few languages do:

• Null safety that works

• Coroutines and structured concurrency

• First-class tooling from JetBrains

• Concise syntax with real type safety

And maybe most surprisingly — it’s just fun to write.

If you’ve ever thought “I wish JavaScript had a type system that didn’t hate me”, or “I wish TypeScript ran on the server with real threads”, Kotlin might be your thing.

Where this is going

I’m going to keep each entry focused, digestible, and grounded in real code. The goal isn’t to teach Kotlin from scratch — it’s to show what makes these tools worth your time in 2025, even if you never thought you’d look at a .kt file again.

Let’s get back in the bag.

Next Up: Kotlin for TypeScript Developers

We'll explore Kotlin's core features, what makes it elegant, and how it compares to the tools you already know.

I’ve always been curious about what really lowers golf scores.

Not just what feels important — but what the data actually says.

So I started building a model.
And I’m already learning things that surprised me.

📊 Not All Strokes Are Equal

Strokes Gained is a powerful stat.
But at its core, it assumes one thing:

A stroke gained is a stroke gained, no matter where you earn it.

That might be true in theory.
But what if how you gain or lose strokes matters more than we think?

🧠 You've Heard the Debate:

“Drive for show, putt for dough.”
“The driver is the most important club in the bag.”

Depending on who you ask, the most valuable club in your bag changes.

I wanted to know what the data says — not just the tour chatter.

So I built a model and ran it on 7 full seasons of PGA Tour data, from 2015 to 2022, using round-level strokes gained stats and computed scoring differentials.

📈 Early Results from the PGA Tour

Here’s what I found:

• ✅ Approach play is the most consistent driver of lower scores

• ✅ Putting is right behind — and sometimes just as important

• ✅ Off-the-tee skill helps, but contributes less directly

• ✅ Short game plays a supporting role, not a starring one

That’s the big picture.
But when you zoom in on individual players, the story gets more interesting.

🔍 Everyone Scores Differently

I ran individual models on dozens of PGA players — and the variation was striking.

• 🧨 Some players like Erik van Rooyen and Daniel Chopra rely heavily on Off-the-Tee or Short Game performance to lower scores

• 🎯 Others like Victor Perez or Mark Wilson live and die by the putter

• 🛠 Players like Rory McIlroy and Sean O’Hair show balanced, all-around scoring profiles

Every scorer has a different recipe.
And the model shows how they get it done.

🗣 How You Can Help

Now I want to go further.

I'm starting to collect amateur and VR golf data to see how these patterns shift at lower skill levels.

• Are drivers more important when you’re missing more greens?

• Does putting get messier as you move away from elite ranks?

• Do different skill levels need different practice priorities?

If you're a golfer — real-world or VR — and want to help, I’d love your input.

Even just a few rounds of data — Score, Differential, and basic strokes gained stats — can help expand the model.

Want to contribute?
A simple upload form is coming soon. Until then, feel free to reach out.

🧠 What’s Coming Next

In future posts, I’ll be sharing:

• How PGA Tour players actually score — by skill, not by myth

• What patterns emerge at the amateur level

• What this means for your practice, your stats, and your game

This is just the beginning.
Let’s find out what really matters — and maybe help a few golfers score lower along the way.

📝 Want to follow along or contribute your own rounds? You can find me at shankproof.dev or drop a comment below.
👊

The goal was to build a real-world demo that shows off the strengths of this stack—without turning it into a full-blown product. I wanted persistence, live updates, and minimal complexity.

What We’re Building

Fairway Tasks is a collaborative to-do list that allows anyone to:

• Add tasks

• Mark them as complete

• See updates in real-time across all open tabs

There’s no login system, no multi-user tracking, and no external database. Just the core interactions and live state syncing.

But there is one key addition to the base demo: I used Deno’s built-in KV store to persist the data. It’s a small change from an in-memory store, but it showcases how batteries-included Deno really is.

The Stack

Here’s what I used:

• Deno: runtime with built-in TypeScript, security, testing, and KV storage

• Fresh: a modern web framework with island-based rendering

• SSE (Server-Sent Events): for real-time updates

• KV Store: Deno’s built-in persistence layer

Together, this gave me a stack with no extra tooling or dependency setup. Just native capabilities and good architecture choices.

Diving into the Code

Fairway Tasks has a minimal but purposeful codebase. Here’s a closer look at the moving parts and how they interact.

1. API Routes

All task interactions live in routes/api/tasks.ts. It handles:

• GET – Return all tasks from the Deno KV store

• POST – Create a new task, store it, and broadcast it

• PATCH – Mark a task complete and broadcast the update

• DELETE – Remove a task from storage and notify all clients

All task mutations trigger the broadcast() function from routes/api/stream.ts, sending the action over Server-Sent Events to connected tabs.

2. Server-Sent Events (SSE)

The real-time update system is handled via a simple SSE implementation:

• Clients connect to /api/stream

• A Set of writable clients is maintained

• On any task change, a message is encoded and sent to each connected writer

export function broadcast(data: unknown) {
  const msg = `data: ${JSON.stringify(data)}\n\n`;
  for (const writer of clients) {
    writer.write(new TextEncoder().encode(msg));
  }
}

It’s lightweight, doesn’t require any external library, and perfect for small collaborative experiences.

3. Frontend Islands

The interactive frontend lives in islands/TaskInput.tsx, where:

• Tasks are displayed from initial props

• Users can add, complete, or delete tasks with a minimal UI

• The island listens to the SSE stream and updates local state accordingly

With the recent addition of Jsonous, the SSE message decoding now looks like this:

useEffect(() => {
  const sse = new EventSource("/api/stream");
  sse.onmessage = (msg) => {
    sseEventDecoder.decodeJson(msg.data).cata({
      Ok: (event) => {
        if (event.type === "add") {
          setTasks((prev) => [...prev, event.task]);
        } else if (event.type === "complete") {
          setTasks((prev) =>
            prev.map((t) => t.id === event.id ? { ...t, completed: true } : t)
          );
        } else if (event.type === "delete") {
          setTasks((prev) => prev.filter((t) => t.id !== event.id));
        }
      },
      Err: (err) => {
        console.error(err);
      },
    });
  };
  return () => sse.close();
}, []);

This small change brings clarity, safety, and makes the SSE message format easier to evolve over time.

Bonus: Deno KV Integration

Persistence is handled with Deno’s built-in KV store using a utils/kv.ts helper module. Tasks are saved under a task:<id> key. Fetching is done with a simple kv.list() call.

export async function getTasks(): Promise<Task[]> {
  const entries = [];
  for await (const res of kv.list<Task>({ prefix: ["task"] })) {
    entries.push(res.value);
  }
  return entries;
}

The result? A real-time, collaborative app with no third-party DB or state store.

What Worked Well

• Fresh’s simplicity: Routing, rendering, and hydration are all predictable and fast

• SSE was perfect: Minimal setup, great fit for one-way sync like this

• Deno’s DX: Linting, testing, and dev server all just work

• KV store: Simple, stable, and lets the app persist between restarts with almost no config

What I’d Explore Next

• Adding authentication using session cookies or tokens

• Using external DBs if relational needs increase

• More complex event handling (editing tasks, reordering, undo)

• Offline sync and background queuing

• More Robust SSE (something that scales horizontally and watches the db for changes)

Wrap-up

Fairway Tasks started as a small project—a swing at trying something simple, collaborative, and live. It turned into a rewarding dive into the capabilities of Deno and Fresh. Using only built-in tools like the KV store and SSE, I was able to build a functional app with real-time syncing and data persistence, all without touching external services or bolting on extra complexity.

The island-based approach of Fresh made it easy to separate server-rendered state from interactive components, and adding jsonous brought confidence to decoding live updates. It’s refreshing to build something that feels cohesive, productive, and fun.

There’s still room to grow—authentication, offline support, and more resilient streaming—but as it stands, Fairway Tasks is a solid example of what modern minimal stacks can accomplish.

You can try the app live on Deno Deploy, and view the source code on GitHub.

Next up? I might take a swing with Wasp, Effect, or even try a mobile-first build using Tamagui. Let me know what you'd like to see in the next post—and what’s in your bag these days.

Thanks for reading!

Here at jsonous, we aim to make JSON decoding as painless and type-safe as possible. While our existing oneOf decoder could handle unions, it wasn't specifically optimized for the common discriminated union pattern. Today, we're excited to introduce a new tool designed precisely for this job: the discriminatedUnion decoder!

The Challenge: Decoding Discriminated Unions "The Old Way"

Let's consider a common example: representing different types of users in our system.

// Our TypeScript types
interface User {
  type: 'user';
  id: string;
  name: string;
  isActive: boolean;
}

interface Admin {
  type: 'admin';
  id: string;
  name: string;
  permissions: string[];
}

type Person = User | Admin;

We have a Person type which can be either a User or an Admin, distinguished by the type field.

Using jsonous previously, you'd typically define decoders for each variant and combine them with oneOf:

import {
  string,
  boolean,
  array,
  stringLiteral,
  createDecoderFromStructure,
  oneOf,
  Decoder,
  identity // Needed for mapping
} from 'jsonous';

// Decoders for each variant
const userDecoder: Decoder<User> = createDecoderFromStructure({
  type: stringLiteral('user'),
  id: string,
  name: string,
  isActive: boolean,
});

const adminDecoder: Decoder<Admin> = createDecoderFromStructure({
  type: stringLiteral('admin'),
  id: string,
  name: string,
  permissions: array(string),
});

// --- The "Old Way" using oneOf ---
const personDecoderOneOf: Decoder<Person> = oneOf([
  // We need to explicitly map each decoder to the union type
  userDecoder.map<Person>(identity),
  adminDecoder.map<Person>(identity),
]);

This works, but has a few drawbacks:

1. Verbosity: You need .map<Person>(identity) for every single variant. This adds boilerplate, especially with many variants.

2. Less Specific Errors: If decoding fails, oneOf tries every decoder in the list and reports all failures. For a discriminated union, you often intuitively know which variant should have matched based on the type field, making the other errors noise.

3. Potential Inefficiency: oneOf might run multiple potentially complex decoders even if the type field clearly indicates only one is relevant.

Introducing discriminatedUnion: The Right Tool for the Job

The new discriminatedUnion decoder is designed to address these pain points directly. It leverages the discriminator field (type in our case) to intelligently select and run the correct decoder.

Here's how it works:

1. You tell it the name of the discriminatorField (e.g., "type").

2. You provide a mapping object where keys are the possible string values of the discriminator (e.g., "user", "admin") and values are the corresponding decoders for each variant.

3. It first decodes only the discriminator field.

4. Based on the value found, it looks up the correct decoder in your mapping.

5. It runs only that specific decoder on the original input.

Let's rewrite our Person decoder using discriminatedUnion:

import {
  // ... other imports remain the same ...
  discriminatedUnion // Import the new decoder
} from 'jsonous';

// userDecoder and adminDecoder definitions remain the same...

// --- The "New Way" using discriminatedUnion ---
const personDecoder: Decoder<Person> = discriminatedUnion('type', {
  user: userDecoder, // Key matches the 'type' value
  admin: adminDecoder, // Key matches the 'type' value
});

// Type check: personDecoder is automatically Decoder<Person> - no mapping needed!

Look how much cleaner that is! No more .map(identity). The decoder's type Decoder<Person> is inferred automatically from the provided mapping.

Why discriminatedUnion is Better

This new decoder offers significant advantages:

1. Type Safety: Automatically infers the correct union type (User | Admin in this case) without manual type hints in .map.

2. Conciseness: Eliminates the repetitive .map(identity) calls, making your decoder definitions cleaner and easier to read.

3. Clarity: The structure discriminatedUnion('field', { key1: decoder1, key2: decoder2 }) clearly expresses the intent of choosing a decoder based on a specific field's value.

4. Targeted Errors: Error messages are much more helpful. Instead of trying all decoders, it fails fast with specific reasons:

   • Did the discriminator field (type) exist and was it a string?

   • Was the value of the discriminator field ("user", "admin") one of the expected keys in the mapping?

   • Did the selected variant decoder (userDecoder or adminDecoder) fail?

5. Efficiency: It avoids running unnecessary decoders. It only decodes the simple discriminator field first and then runs exactly one variant decoder.

A Clearer Picture: Error Handling

Let's see the difference in error messages. Consider this invalid input:

const invalidData = { type: 'guest', id: 'guest-001' };

Error with oneOf:

// personDecoderOneOf.decodeAny(invalidData) might produce:
Err: I found the following problems:
Expected user but got "guest":
occurred in a field named 'type'
Expected admin but got "guest":
occurred in a field named 'type'

(It tells you both decoders failed because the type was wrong).

Error with discriminatedUnion:

// personDecoder.decodeAny(invalidData) produces:
Err: Unexpected discriminator value 'guest' for field 'type'. Expected one of: user, admin. Found in: {"type":"guest","id":"guest-001"}

(It tells you exactly the problem: the value "guest" wasn't expected for the type field).

If the type was correct but other data was wrong (e.g., isActive was a string for a user), discriminatedUnion would report the error from within the userDecoder, prefixed clearly:

// Example: { type: 'user', id: 'u1', name: 'Test', isActive: 'yes' }
Err: Error decoding variant with type='user': I expected to find a boolean but instead I found "yes":
occurred in a field named 'isActive'

Get Started Today!

Decoding discriminated unions is now simpler, safer, and more efficient in jsonous. If you're working with tagged unions and JSON, the discriminatedUnion decoder is the tool you've been waiting for.

Update jsonous to the latest version and give it a try! We think you'll appreciate the improved ergonomics and clearer error reporting. Check out the README for detailed usage and examples.

Happy Decoding!

Well, I think developers are a lot like golfers. We each carry a different set of tools. Some we've used for years and know inside and out. Others we’re testing out, seeing how they perform in different conditions. Our tools define our approach—and how we solve problems.

So I’m kicking off a new series on my blog called What’s In the Bag? In each post, I’ll explore a specific tech stack or framework, build something small but meaningful with it, and share my honest thoughts along the way. No hype. No gatekeeping. Just real-world experience with a touch of craft and curiosity.

First Up: Deno + Fresh

The first stack in the bag is something I’ve been meaning to explore more seriously: Deno and the Fresh web application framework.

For those unfamiliar, Deno is a modern JavaScript/TypeScript runtime created by the original creator of Node.js. It comes with built-in tooling (like testing and linting), strong security defaults, and native TypeScript support out of the box. Fresh, built on top of Deno, is a full-stack web framework focused on speed and simplicity. It uses "island architecture" to keep client-side JavaScript minimal by default, enabling ultra-fast performance and a better developer experience.

To test this stack, I’ll be building a collaborative to-do app—inspired by a showcase repo from the Deno team that uses server-sent events (SSE) to keep browser tabs in sync. The twist? Multiple users can view and update the same task list in real-time. No account system, no database (yet)—just a live playground for learning.

I'll cover:

• Project setup and routing in Fresh

• How SSE works and why it's simpler than WebSockets for some use cases

• Structuring shared state in a collaborative UI

• What felt intuitive, what felt clunky, and what I’d do differently next time

Why This Matters

I’m doing this for a few reasons:

• To stay sharp by evaluating new tools

• To create public artifacts I can point to

• To rebuild the habit of sharing what I learn

And let’s be honest—like any golfer trying out a new driver, sometimes it’s just fun to see what happens when you take a swing.

If you're curious about Deno, Fresh, or just like hearing how developers think through new stacks, I hope you’ll follow along.

Join the Conversation

Have you tried Deno or Fresh? Got a tech tool you think should be in the bag? I’d love to hear what you’re exploring or experimenting with. Drop a comment, tag me on LinkedIn, or share your “what’s in the bag” story.

First build drops later this week.

Thanks for being here.

For the last several years, I’ve been building software quietly behind the scenes. My focus was deep in the architecture, the tooling, and the day-to-day work of helping teams ship reliable code. And while that work has been rewarding, I’ve come to realize I’ve missed something important: sharing what I’ve learned—and exploring what I still want to learn.

So here I am, writing again.

A Little Background

I’ve been a professional software engineer for about 30 years. I’ve built everything from Electronic Medical Records and public health systems to dev tooling and AI-enhanced educational platforms. I’ve worked in big teams, scrappy startups, and everything in between. I’ve led engineering orgs and built systems with 99.999% uptime. I’ve mentored junior devs, contributed to open source (shoutout to JRuby), and maintained libraries like Taskarian and Jsonous that reflect my love for functional programming.

But over time, I stopped writing about it. I got comfortable. Head down, shipping code, helping others get their work across the line.

And honestly, that was fine—until it wasn’t. Because I believe writing makes us sharper. Building in public keeps us honest. And articulating ideas—especially the imperfect, in-progress ones—is how we grow.

Why Now?

Lately I’ve felt the itch to connect again—to resuscitate those old blogging muscles, not just to teach, but to reflect. I want to document what I’m working on, share what I’m thinking about, and maybe even help a few people along the way.

But this time, I want to do something a little different.

This time, I want to bring golf into the mix.

Golf + Code? Really?

Yeah. Really.

During COVID, I developed a deep love of golf. I’m no pro, but I’ve spent enough time on the course—and building tools about the course—to know there’s something fascinating in the overlap between software and the swing. Systems thinking. Feedback loops. Precision. Resets. Debugging under pressure.

And lately I’ve started building apps for golfers. Tools like Yardage Card and StrokeSheet—apps that help players understand their own game the way developers debug production systems. I’ll write about those projects here, along with the libraries, design decisions, and technical rabbit holes they lead me down.

What to Expect

This blog will be a mix of:

• Real-world software engineering thoughts and practices

• Functional programming and Typescript nerdery

• Developer productivity tools (including AI-assisted workflows)

• Golf tech, stats, and systems

• Maybe the occasional metaphorical crossover—because debugging a smother hook feels a lot like debugging a bug

If that sounds like your kind of thing, I hope you’ll stick around. I’m writing this for people who care about craft, who like to build, and who maybe—just maybe—believe that thoughtful systems can make everything a little more fun.

Thanks for being here. Let’s see where this goes.