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.