Zack Bartel

C++ is Great (again)!

Mon, 24 Nov 2025 00:00:00 +0000

C is my favorite programming language.

It always has been and probably always will be. It allowed me to build cool stuff at a young age, create iOS and Mac software (via Objective-C), contribute to the Linux kernel, and work on embedded systems on airplanes.

When I first learned C++ in college, it was great. It was like having a super-charged version of C. Classes, inheritance, and polymorphism, it felt modern and powerful.

I last used C++ heavily around 2010. At that time the Template Metapocalypse was in full swing. That experience made me not like programming.

I was tired of dealing with the complexities. The syntax was verbose, error messages unusable, build systems a nightmare, and the community divided over best practices. I moved on to other languages: Go, Java/Scala, Swift, Python, Javascript, but I would often miss the power of C++.

Whenever I had to use JNI or some other FFI (Foreign Function Interface), I felt weak. I don't want to have to wait for some third-party library to bind to my favorite language. I want to write high-performance code directly. But at that time I just didn't feel like C++ was a reasonable choice.

C++11 was on the horizon, promising to fix many of the issues, but the complexity of the language had already scared off many developers.

I took a long break from C++.

Necessity is the mother of invention.

Fast forward to 2024, and I found myself needing to write some high-performance code for a project that couldn't tolerate garbage collection pauses. Python was too slow, Go's GC was unpredictable, and Rust's learning curve felt steep (and frankly I don't like it - Arc<Mutex<DeezNutz>>).

I reluctantly opened up a C++ project, expecting the same old frustrations. What I found instead was a revelation.

Modern C++ is a different language.

The C++ I discovered was not the C++ I had left behind. C++11, C++14, C++17, and C++20 had fundamentally transformed the language. The improvements weren't just incremental, they were transformative.

Auto type deduction means I'm no longer writing std::vector<std::string>::iterator everywhere. Now it's just auto. The compiler figures it out, and my code is cleaner and more maintainable. It feels like I'm writing Python, but with all the performance of C++.

Lambda functions changed everything about how I write callbacks and functional-style code. Before, I'd create a functor class or a separate function. Now I can write inline lambda expressions that capture variables from the surrounding scope. Threading code went from painful to pleasant.

Speaking of which, the standard threading library finally arrived. No more pthread or platform-specific APIs. std::thread, std::mutex, std::atomic—it's all there, cross-platform, and actually usable. I can write concurrent code that works on Windows, Linux, and Mac without conditional compilation everywhere.

But the feature that truly won me back was smart pointers. std::unique_ptr and std::shared_ptr eliminated most of my memory management headaches. No more agonizing over when to call delete. No more memory leaks from forgotten cleanup in error paths. RAII (Resource Acquisition Is Initialization) finally felt natural and automatic. I know there's a lot of RAII hate out there, but for me it's very natural and makes sense. If it doesn't for you, that's okay too.

// old way - error prone
Widget* w = new Widget();
// ... do stuff ...
delete w; // Did I remember? What if there was an exception?
// new way - automatic cleanup
auto w = std::make_unique<Widget>();
// ... do stuff ...
// automatically cleaned up, exception safe

The ecosystem caught up too.

It's not just the language. The tooling improved dramatically. CMake became tolerable. Package managers like Conan and vcpkg emerged. Compiler error messages, while still pretty bad, are lightyears better than the template error novels of 2010.

LSPs made code completion and navigation great. Clang format standardized code style. Sanitizers made debugging memory issues trivial. The whole development experience modernized. All of these things made editting code in nvim a joy.

AI assistants are a secret weapon.

Here's something unsurprising: AI coding assistants have made C++ significantly more approachable. Those cryptic template errors that used to send me down rabbit holes for hours? I paste them into Claude or ChatGPT and get a clear explanation and fix in seconds.

Writing boilerplate for move constructors, copy assignment operators (did i forget the third &?), or template specializations? The AI generates it correctly while I focus on the actual logic. Debugging subtle lifetime issues with references and pointers? The AI spots the problem I've been staring at for twenty minutes.

C++ has always had a steep learning curve with tons of gotchas: the rule of three, the rule of five, argument-dependent lookup, template SFINAE, undefined behavior landmines. AI assistants act like an expert pair programmer who knows all these pitfalls and helps you avoid them. They catch my mistakes before they cause the old headaches.

It's ironic: C++ became easier to write precisely when we got AI tools trained on decades of C++ code, patterns, and best practices. The accumulated wisdom of the C++ community is now available on-demand, making the language's complexity manageable in a way it never was before.

They still can't do the hard code, I recently wrote a Wayland + EGL backend for Dear ImGui and the AI was totally useless, but they handle the tedious stuff that used to make C++ a chore.

C++ is great again.

I'm writing C++ daily now, and I'm enjoying it. I never, ever would have thought I'd say that again. I am having fun, and getting excited about programming things I couldn't do in other languages.

The language gives me the control and performance I need without the tedious manual memory management and verbose boilerplate that drove me away. It's the super language and probably always will be.

Modern C++ found the sweet spot: it kept the zero-cost abstractions and raw power, but added the ergonomics that developers expect in 2024. It's not perfect of course, the language is still complex, and there's legacy baggage, but it's legitimately great.

If you walked away from C++ years ago, give it another look. You might be surprised at what you find.

If you wish you could learn C++ and harness its power without the frustrations, now is the time, fire up Antigravity and get going.

The king has reclaimed its throne.

Hyprwat: A Wayland native menu tool for Hyprland

Mon, 06 Oct 2025 00:00:00 +0000

What is Hyprwat?

Hyprwat is a menu tool designed specifically for Hyprland and Wayland compositor. It allows users to create and manage customizable menus that can be accessed directly from the Hyprland environment.

It creates a popup menu at your cursor position where you can select from a list of options. It also has built-in support for WiFi network selection, audio input/output device selection, wallpapers, and custom menus. Custom menus can be defined using simple YAML configuration files.

The name is inspired by some javascript bashing video I saw many years ago. But, also like "What do you need?"... because it's a menu tool.

Right now you can:

Create a list of key / value pairs that show up in a menu, the selected value is printed to stdout.
Create an input menu, where the user can type in a value that is printed to stdout.
Create password menu, where the user can type in a masked value that is printed to stdout.
Select from available WiFi networks (dbus + NetworkManager).
Select audio input/output devices (pipewire).
Select wallpaper (hyprpaper).
Create custom menus with a bunch of GUI controls using YAML configuration files.

What does it look like?

Integrate with powerprofilesctl to switch power profiles:

Change wallpapers and lockscreen:

Connect to wifi networks:

Why?

I created hyprwat to fill a gap in the Wayland ecosystem for a simple, flexible, and visually appealing menu system that can be easily integrated into various use cases. Particularly, for waybar I needed a menu selection for wifi networks, power profiles, pavcontrol, etc.

Then, I wanted an easier way to switch wallpapers and lockscreen and found the existing solutions too hard, so I just added it into hyprwat. I'll keep doing this, it's fun.

My first attempt used SDL2/3 and ImGui, but I didn't like the menu being a window (there's no layer shell support in SDL). So I rewrote it using pure Wayland protocols and EGL for rendering.

If nothing else it's a pretty cool cpp wrapper for Wayland protocols.

Returning to Linux

Wed, 05 Feb 2025 00:00:00 +0000

Mac OS X is getting worse

Update: Liquid Glass is awful, and the number of bugs in all of Apple's platforms is no longer acceptable. My 2017 iMac Pro was working fine for what I needed. Yes, it's old but for what I do (edit C code in vim, play chess online) it was great. But after installing Tahoe it's noticeably slower, buggier, and plaqued with permission popus and "unexpected error" dialogs. My Apple TV is annoying now, there are too many clicks to do anything, it's slower, the remote stopped working correctly. My watch is slower, battery life worse, again with the UI taking more taps to do what I used to be able to do. Hopefully the post-Allan Dye era will be a renaissance for Apple software like the post-Johny Ive era is for hardware.

Apple's hardware is by far the best on the market, but I feel the software has been deteriorating for some time. Gatekeeper is becoming more and more invasive, and the constant permissions dialogs are getting annoying.

For average users It's probably all for the better, but as a developer I no longer want to use a computer I can't make software (freely) for and share with people.

In addition, I feel I've become too reliant on iCloud and some other overpriced Apple services.

I love the Mac. Some of the most important software I've ever written was for Apple OSs. When Mac OS X first came out it seemed like the perfect OS. I was an Apple and Unix geek so it felt magical.

I Love Linux

I was a Linux desktop user for many years before switching to Mac OS X in 2009.

My dad and I installed a Redhat distribution with kernel version 1.1.0 around 1995, and I've been using Linux on and off ever since. As a kid, I was absolutely fascinated by the idea of open source software and the ability to modify and share code freely.

In college I worked at the OSU Open Source Lab, where I was introduced to ion3. I was instantly hooked on tiling window managers and used ion3 for years. This was the ultimate developer experience.

i use arch btw

After a completely unrelated need arose to have a Linux development environment, I decided to dip my toe in the water. I bought a $300 Acer laptop and installed Arch, and Kali (I work in cybersec).

The funniest thing about the whole process is how awful the pre-loaded Windows experience was. Their beloved OOBE experience is a joke. It took me hours to get the system into a usable state, and it was unusably slow.

Anyway, I missed ion3, tried i3 (it's not for me), and then found Hyprland. It's amazing. I can't believe how amazing it is. It is absolutely perfect for me. I can't impress upon you enough how amazing Hyprland is.

Hyprland did take days to setup, but that's what I wanted. Although, you can get up and running in a matter of minutes, tweaking everything to be just how I wanted it took a while. And (hopefully) I'll keep improving it forever. If you don't want that there are plenty of good alternatives (xfce).

The other thing is, this setup is SO FAST. Even on a budget laptop, everything is snappy and responsive.

A non-exhaustive list of things I use

Hyprland / Wayland (tiling window manager)
Ghostty (terminal)
Neovim (for everything)
hypr*
- hyprpaper
- hypridle
- hyprlock
Waybar (status bar)
Rofi (app launcher)
Thunderbird (email - I can't find anything better)
- aerc was pretty cool but there is way too much html email these days
Zen (browser)
Bitwarden (password manager)
Thunar (file manager)
A bunch of hacks to get iCloud CardDav and CalDav working

Anyway,

I'm back on Linux full time now, and I couldn't be happier. It's not just for developers anymore. time.Now().Format("2006") is the year of the Linux desktop.

Why I Stopped Trying to Improve at Chess

Tue, 14 Mar 2023 00:00:00 +0000

I've played chess off and on since I was a kid

I remember the excitement of learning the rules, beating my dad (he let me win), the thrill of my first rated victory, and the countless hours spent poring over strategies and tactics. Over the years, I reached a respectable level of play, competing in local tournaments and climbing the ranks.

However, as time went on, I found myself increasingly frustrated. The more I studied and practiced, the more I realized how much there was to learn. Chess is a game of infinite complexity, and no matter how hard I tried, I felt like I was hitting a ceiling. My progress slowed to a crawl, and the joy I once found in the game began to wane. What was really the kicker was when I hit an all-time high rating of 1895 (chess.com) and then promptly dropped back down to 1700 within a few weeks. It was disheartening to see my hard work seemingly unravel and never quite reach the heights I once had.

I was spending nights and weekends reading books, doing tactics puzzles, and analyzing games, but it felt like I was running in place. The more I learned, the more I realized how much I didn't know. It was a humbling experience, but also a frustrating one. I began to question whether the time and effort I was putting into chess was worth it.

Games weren't fun anymore; they felt like chores. I found myself dreading the start of a game, which used to be adrenaline filled excitement. The pressure to improve and perform well was taking the joy out of the game. I started to see chess as a source of stress rather than a source of enjoyment.

Then, one night I said "fuck it"

and decided to just blitz out a bunch of games. It made me realize that chess was supposed to be fun, not a source of frustration. I'm never going to be a grandmaster and I don't have to feel like I should aspire to that. I started playing for the sheer enjoyment of the game, without worrying about my rating or performance. I played casual games with friends, tried tricky and trappy gambits online, and simply enjoyed the process of playing. The thrill of finding a brilliancy, laughing at silly blunders that lost me games. I can't understate how upset I would typically get if I made a mistake and/or lost a game.

This realization reinvigorated my play. I once again look forward to starting a game, tough situations in the mid-game, king-and-pawn endgames. The joy for the game returned! I know I will probably not improve my rating much for the remainder of my playing days, but I really don't care. What I care about is being in a community of people who love the game as much as I do, and enjoying the process of playing. Chess is a beautiful game, and I'm grateful to have it in my life, even if I'm not the best player out there.

I love the English Opening

Thu, 05 May 2022 00:00:00 +0000

I fell out of love with 1.d4 and the London System.

I'll always have a soft spot for it in my heart as it's responsible for a lot of my early chess success. But I'm not a system player, and the London System felt like playing chess on autopilot.

On paper, it makes sense. Low theory, solid structure, you can play it against almost anything. Just put your pieces on their natural squares: Bf4, e3, Nf3, Nbd2, Bd3, c3 and then what? London players always fall down here.

I'd clawed my way up to around 1600, feeling pretty good about my chess. My London was solid, my Queen's Gambit sharp, and I could navigate the gambits well enough to stay out of danger. Then something shifted.

Once I reached a certain rating threshold everyone knew their theory. I would get crushed with 1.e4 by opponents who had memorized the best lines.

Suddenly, every opponent knew their theory cold. They'd rattle off the first fifteen moves without thinking. They'd steer me into playing their game. And I realized: I was spending more time memorizing opening lines than actually improving at chess.

I needed a change. But I wasn't about to become that guy.

Except it felt soulless. Every game looked the same. I wasn't responding to what my opponent was doing; I was just executing a setup regardless of what was happening on the other side of the board. It was chess on autopilot.

And the players I encountered who played the London? They had this glazed look in their eyes during the opening, like they were going through a checklist. "Bf4, check. E3, check. Nf3, check." No spark, no creativity, no actual chess decisions until move 15.

I distinctly remember sitting across from an opponent who played the London against my King's Indian setup, and I could see him mentally running through his system. He wasn't looking at my position. He was following a recipe. When I threw in an early ...Ne4 to disrupt his flow, he sat there for twenty minutes because he'd never actually learned to think in the opening. He'd only learned to deploy.

I refused to become that player. I'd rather memorize theory than give up on actually playing chess in the opening.

But there had to be a better way.

Hello 1.c4

That's when I discovered the English Opening, and it completely transformed my game.

The English Opening (1.c4) seemed almost too quiet when I first looked at it. After years of fighting for the center with 1.e4 or 1.d4, starting with a flank pawn felt... indirect? But then I started playing it, and I realized: this was everything the London pretended to be, but actually delivered.

The English gets you out of theory fast, not because you're ignoring your opponent's moves, but because you're creating unique positions they haven't memorized. There's no "English System" where you mindlessly deploy pieces to predetermined squares. Every game demands actual chess thinking from move one.

Why It Catches Everyone Off Guard

Here's the beautiful thing: most players at the club level have prepared something against 1.e4 and 1.d4. They've got their Sicilian or French or King's Indian or Nimzo-Indian ready to go.

But 1.c4? They pause. You can see it on their face. "Wait, what's he doing?"

They're out of their prep by move two. Not because you've done something gimmicky, but because the English is genuinely flexible and can transpose to many different structures. They can't just follow their memorized lines - they have to actually evaluate the position.

One of my favorite moments was against a 1900-rated player who clearly had a Najdorf repertoire memorized to move 25. After 1.c4, he thought for fifteen minutes on move one. He ended up playing 1...e5, we reached a Reversed Sicilian, and suddenly I was the one playing Sicilian structures (from the better side!) while he struggled with positions he'd never studied.

Aggressive or Positional: Your Choice

What really sold me on the English is its flexibility - and this is where it completely diverges from something like the London.

The London commits you to a specific structure and plan. You're playing for a slow positional squeeze almost every game. Sure, sometimes you get a kingside attack going, but you're fundamentally locked into a style.

The English? It can be whatever you need it to be.

Against a King's Indian setup, I can play the Botvinnik System (my favorite) with g3, Bg2, and Nc3, building for a slow positional grind where I control the center from afar.

Against a symmetrical structure (1.c4 c5), I can play aggressively with Nc3, g3, Bg2, e4!, blasting open the center and creating tactical complications.

Against the more classical setups with ...e5, I can reverse my beloved Sicilian structures and play for the same types of attacks my opponents used to play against me, except now I have an extra tempo.

The choice is mine. I'm responding to what's on the board, reading the position, making real chess decisions. You know, actually playing chess.

Getting Out of Theory, Into Chess

Here's the thing about theory: it's useful until it isn't. And at some point, every opening becomes about understanding ideas rather than memorizing moves.

The English forced me to understand chess rather than memorize it. Because there's no set "system," I had to learn:

How to control the center from a distance
When to break with d4 or e4 vs. when to keep the pawn structure fluid
How to evaluate transpositions (Is this Reversed Sicilian better than a normal one? Should I allow this transposition to a Queen's Gambit Declined?)
How to handle space disadvantages when opponents claim the center with ...e5 and ...d5

These are real chess skills. Pattern recognition, positional understanding, strategic thinking. Not "if he plays ...Na5, I play b4, and if he takes, I play a3." And it has made me a much better player overall.

The Freedom of Flexibility

Maybe the best part? No two English Opening games feel the same.

With the London, every game felt like déjà vu. Same structure, same pieces on the same squares, same middlegame ideas.

With the English, I might get a Reversed Dragon one game, a Hedgehog structure the next, a Symmetrical Variation the game after that, and occasionally it transposes into something completely different like a Catalan or Queen's Indian.

It keeps chess fresh. It keeps me engaged. And it keeps my opponents off-balance.

The Dirty Little Secret

Want to know the truth? The English has plenty of theory. There are whole books on the Symmetrical Variation alone. The Reversed Sicilian lines can get incredibly deep.

But here's the difference: your opponents haven't studied it.

At the club level, nearly everyone has studied the Open Sicilian or the Najdorf or the French Defense. Almost nobody has studied the Symmetrical English or the Reversed Dragon in depth. So even though theory exists, you're functionally out of book by move five.

And unlike the London, where being "out of book" just means you're playing generic moves, being out of book in the English means you're in rich, complex positions where understanding matters more than memory.

My Rating Thanks Me

Since switching to the English, my rating has climbed steadily. It didn't at first, I took a big hit, but in the long run it has gotten me farther than I think the London could have. More importantly, I've improved at chess in general.

I'm not winning because I memorized better lines. I'm winning because I'm making better decisions, understanding positions more deeply, and outplaying opponents in the middlegame.

The opening gets me to playable, interesting positions where both sides have chances. Then the game is decided by who understands chess better, not who memorized more theory the night before.

And I've avoided becoming a London player, which frankly might be the biggest victory of all.

Tired of Theory?

If you're facing the theory wall, if you're tired of memorizing, if you want to play chess instead of reciting it, give the English a try.

Just promise me one thing: don't treat it like the London. Don't look for a "system" you can play mindlessly. The English demands that you think, that you evaluate, that you respond to what your opponent is doing.

That's what makes it beautiful.

Start with 1.c4, follow basic opening principles, and see where the game takes you. You might be surprised at how much chess you've been missing while you were memorizing theory.

And you definitely won't end up with that glazed London System look in your eyes.

Kubernetes Loves Go

Tue, 18 Jan 2022 00:00:00 +0000

I've been working with Kubernetes and Go for years now. There's something deeply satisfying about this combination. Kubernetes gives you this incredibly powerful orchestration platform, and Go provides the perfect language to extend it. The two were made for each other, and nowhere is this more apparent than when you need a custom controller to solve a particularly gnarly scaling problem.

One Pod Per User

Our system had an unusual but deliberate architecture: one pod per user. Each user would "reserve" a pod for their exclusive use during a session. Think of it like a personalized sandbox environment, isolated, secure, and fully theirs.

There were a lot of challenges. These pods weren't instant. Startup time was significant enough that we couldn't just spin them up on-demand. Users expect immediate access, so we needed a pool of pre-warmed pods sitting ready to go.

Why Standard Scaling Wasn't Enough

My first attempt was using Kubernetes' Horizontal Pod Autoscaler with custom metrics from Prometheus. After all, that's what it's for, right? But as time went on it became clear that HPA wasn't sophisticated enough for what we needed.

Our scaling logic had to account for:

Time-based patterns: We needed different pool sizes at 2 PM versus 2 AM. User demand followed predictable daily rhythms.
Velocity and acceleration: A steady increase in reservations required different handling than a sudden spike. If someone tweeted a link to our service and we got a flood of new users, we needed to scale fast.
Smart pool management: The pool couldn't just be "any X pods." We needed to track which pods were reserved, which were ready, and which were warming up.

Standard metrics-based scaling gave us crude reactive behavior. We needed something predictive and loaded with business logic.

The Custom Controller

This is where Go and Kubernetes really shine together. I decided to build a custom controller (technically an operator, since it manages a custom resource) using the excellent controller-runtime library.

None of this is the actual code, but here's a simplified version.

The Custom Resource Definition

I wanted it to be cute, so I defined a CRD to represent our pod pool:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: podpools.scaling.example.com
spec:
  group: scaling.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                minPoolSize:
                  type: integer
                  minimum: 0
                maxPoolSize:
                  type: integer
                  minimum: 1
                targetReadyPods:
                  type: integer
                  minimum: 0
                scaleUpVelocityThreshold:
                  type: number
                scaleUpAccelerationThreshold:
                  type: number
                timeBasedScaling:
                  type: array
                  items:
                    type: object
                    properties:
                      hourStart:
                        type: integer
                      hourEnd:
                        type: integer
                      targetPoolSize:
                        type: integer
                podTemplate:
                  type: object
                  x-kubernetes-preserve-unknown-fields: true
            status:
              type: object
              properties:
                readyPods:
                  type: integer
                reservedPods:
                  type: integer
                warmingPods:
                  type: integer
                currentVelocity:
                  type: number
                currentAcceleration:
                  type: number
                lastScaleTime:
                  type: string
                  format: date-time
  scope: Namespaced
  names:
    plural: podpools
    singular: podpool
    kind: PodPool
    shortNames:
    - pp

This CRD let us declare a PodPool resource with all the knobs I needed: time-based scaling windows, velocity thresholds, and the pod template to use.

The Controller Logic

The controller's reconciliation loop is the brain of the operation. Here's the core logic I implemented in Go:

func (r *PodPoolReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {

    // find the PodPool
    podPool := &scalingv1.PodPool{}
    if err := r.Get(ctx, req.NamespacedName, podPool); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // list all pods managed by this pool
    pods := &corev1.PodList{}
    if err := r.List(ctx, pods, 
        client.InNamespace(req.Namespace),
        client.MatchingLabels{"pool": podPool.Name}); err != nil {
        return ctrl.Result{}, err
    }

    // pods by state
    ready, reserved, warming := r.categorizePods(pods.Items)

    // calculate reservation velocity and acceleration
    velocity, acceleration := r.calculateMetrics(podPool, len(reserved))

    // determine target pool size based on time of day
    targetSize := r.getTimeBasedTarget(podPool)

    // check for spike conditions
    if velocity > podPool.Spec.ScaleUpVelocityThreshold || 
       acceleration > podPool.Spec.ScaleUpAccelerationThreshold {
        targetSize = r.calculateSpikeTarget(targetSize, velocity, acceleration)
    }

    // scale the pool
    currentTotal := len(ready) + len(warming)
    if currentTotal < targetSize {
        r.scaleUp(ctx, podPool, targetSize-currentTotal)
    } else if currentTotal > targetSize && len(ready) > podPool.Spec.TargetReadyPods {
        r.scaleDown(ctx, podPool, ready[podPool.Spec.TargetReadyPods:])
    }

    // update state
    podPool.Status.ReadyPods = len(ready)
    podPool.Status.ReservedPods = len(reserved)
    podPool.Status.WarmingPods = len(warming)
    podPool.Status.CurrentVelocity = velocity
    podPool.Status.CurrentAcceleration = acceleration

    return ctrl.Result{RequeueAfter: 10 * time.Second}, r.Status().Update(ctx, podPool)
}

The beauty of this approach is that everything is declarative. I could define different scaling behaviors for different environments just by creating different PodPool resources.

Measuring Velocity and Acceleration

The most interesting part was tracking reservation velocity and acceleration. I kept a sliding window of reservation timestamps in the controller's memory (later moved to the PodPool status for persistence):

func (r *PodPoolReconciler) calculateMetrics(podPool *scalingv1.PodPool, currentReserved int) (float64, float64) {
    now := time.Now()

    // reservation history from status or cache
    history := r.getReservationHistory(podPool)

    // add current count
    history = append(history, ReservationDataPoint{
        Timestamp: now,
        Count: currentReserved,
    })

    // keep only last 5 minutes
    cutoff := now.Add(-5 * time.Minute)
    history = filterAfter(history, cutoff)

    // calculate velocity (reservations per minute)
    velocity := 0.0
    if len(history) >= 2 {
        deltaCount := history[len(history)-1].Count - history[0].Count
        deltaTime := history[len(history)-1].Timestamp.Sub(history[0].Timestamp).Minutes()
        velocity = float64(deltaCount) / deltaTime
    }

    // calculate acceleration (change in velocity)
    acceleration := 0.0
    if len(history) >= 3 {
        midpoint := len(history) / 2
        recentVelocity := calculateVelocityBetween(history[midpoint:])
        olderVelocity := calculateVelocityBetween(history[:midpoint])
        acceleration = recentVelocity - olderVelocity
    }

    return velocity, acceleration
}

This gave us real-time awareness of not just how many reservations were happening, but how fast the rate was changing. When acceleration spiked, we knew something unusual was happening and could preemptively scale.

The Results

The controller worked beautifully. During normal hours, the pool would smoothly adjust based on our time-based configuration. During the night, we'd have just enough pods to handle occasional use. During peak hours, the pool would be pre-scaled.

But the real magic happened during spikes. When (hypothetically) some CEO accidentally tweeted a direct link to our service, the controller would detect the acceleration in reservations and immediately start scaling up. The pool would stay ahead of demand.

Why I Love This Stack

This project exemplified everything I love about Kubernetes and Go together. Kubernetes provides this amazing extension mechanism through CRDs and controllers. It doesn't try to solve every problem. Instead, it gives you the tools to solve your own problems in a native, first-class way.

Go makes building these controllers almost effortless. The controller-runtime library handles all the boilerplate of watching resources, managing work queues, and handling retries. The type safety catches bugs at compile time. The standard library has everything you need. And the resulting binary is a single executable that's trivial to containerize and deploy. This is why I love Go.

I could have built a separate service that called the Kubernetes API to manage pods, but making it a proper operator meant it integrated seamlessly with the rest of our Kubernetes infrastructure. We could use kubectl to inspect pool status, GitOps to manage pool configurations, and RBAC to control access.

If you're working with Kubernetes and facing a scaling problem that doesn't fit the standard tools, don't be afraid to build a custom controller. With Go and controller-runtime, it's easier than you might think, and the results can be truly powerful.

Callout: The Boxing App

Mon, 17 Aug 2020 00:00:00 +0000

I started boxing when I was in high school. My football coach didn't want some of us to have too much free time on our hands during the winter, and I got my ass kicked in wrestling. So, he took us to the local gym and taught us the basics. I'd go on to compete in Golden Gloves, becoming a long time member of a local gym, and continuing the practice on and off into my 30s. Despite what you'd think, I've met some of the most compassionate and empatheic people in my life in boxing gyms. It's been a big part of my life.

Since I put the gloves down, I've wanted a better way to train at home. So much so that I actually wrote a C program to help.

What I really wanted was someone, or something to call out punch combinations during a "round".

Callout

So I wrote Callout - The Boxing App.

The idea is pretty simple, but nothing like it exists. You select or create punch combinations to be called during a round, and iOS SpeechSythesizer does the rest. You can customize the speed, rest time, and variance of combinations called. You can even create your own combinations.

It's available on the App Store for free with an in-app purchase to unlock all features.

Back to Chess

Sat, 20 Jun 2020 00:00:00 +0000

Rediscovering Chess

I used to play chess quite a bit, and my brother Jake would always beat me. It kinda made me lose interest and not want to play at all. I've never really liked things I'm not good at, or at least things my brother is better at. But recently, I had a motivator I could not ignore.

My father passed away last month, and while he was in the hospital, my brother and I had a lot of time to kill. We played chess a lot, and he beat me a lot.

Our entire lives have been a competition. We were the best baseball players in our town as kids, I hit more homeruns but he was better at almost everything else. But that doesn't matter because chicks dig the longball, so I was kinda cool with my spot. He was always better at me at Madden, but I could cheese him with Mike Vick.

But now, sitting in a hospital room 14 hours a day getting beat by him out of the opening almost every game made me hit my limit. I really wanted to beat him.

That's when I googled "chess openings" for the first time. I went back to the hotel, read some articles, watched some videos, and learned a few new openings. A couple days in, I started beating him. It felt amazing. That competitive fire reigniting and giving me a clear goal was just what I needed.

So, I'm back to playing chess. I'm not sure how far I'll go with it, but for now, it's fun to have a new challenge and a way to connect with my brother. I'm back on Lichess and can not wait to see how far I can push it.

Checkmate, Jake.

ForceCode: Morse with Force Touch

Sun, 22 Mar 2020 00:00:00 +0000

My dad is in the hostpital and is physically impaired. He can still kinda use his iPhone, but with very limited dexterity. His speech is also impaired, so communicating with him is difficult.

He's a ham radio operator and has been since he was a teenager. So I figured Morse was worth a shot.

Putting aside the physical limitations, I was sorely dissapointed in the existing Morse code apps. Most of them are learning apps, which is cool, but there's not much in the way of simple, efficient keying apps. The ones that do exist are clunky, ugly, and not very user friendly. It's probably okay, I mean who uses Morse code anymore.

I downloaded a few apps and tried them out with him. None of them worked well for his situation. He couldn't lift his finger off the screen quickly enough to get the timing right.

Having an ungodly amount of free time on my hands, I decided to make my own app for him.

ForceCode

I made an app called ForceCode that uses Force Touch to send Morse code. The idea is that instead of lifting your finger off the screen to end a dot or dash, you just vary the pressure of your touch. A light press is a dot, a hard press is a dash. This way, you can keep your finger on the screen the whole time and just vary the pressure as needed.

I've been programming for 15 years but this was life changing when it worked.

The source code is openly available as is the free app. A neat Hacker News discussion happened that really made me feel good.

Makyō Kicks Ass

Sun, 01 Sep 2019 00:00:00 +0000

Makyō

One of my teacher's teachers called these "moments that make us dance". These are moment during zazen where we have some experience that feels profound, enlightening, or otherwise special. It might be a vision, a feeling of bliss, a sense of unity with the universe, or some other extraordinary experience.

Makyō (魔境) literally means "devil's realm" or "demon's realm", and refers to these hallucinations or visions that can occur during zazen. In Zen practice, makyō is often seen as a distraction or obstacle to true enlightenment, but I think it kicks ass.

Mean old Zen teachers usually dismiss these experiences as "makyō", or illusions, and warn students not to get attached to them. There is a lot of wisdom in that. Getting attached to these kinds of things, while maybe pleasant, can lead us away from the point of Zen practice, which is to cultivate an understanding of the nature of reality and our place in it.

You don't even have to have been practicing very long to experience really interesting "moments that make us dance". I had only been sitting for a couple of months when I had my first "dance" experience. I thought something important had happenend, that I had broken through some new level of understanding. Holly shit, am I enlightened?

This of course was completely unhelpful. I grasped on tight to that feeling of accomplishment. And agonized as the feeling slipped away over the next couple of days. Then I was right back where I started, on my zafu thinking with my legs crossed.

Sesshin - Silent Retreat

Recently, I went, for the second time, on a week-long silent retreat with Bright Way Zen.

My first retreat was unpleasant. I was uncomfortable the whole time, I had no insights, I missed home, missed my kids, missed my wife, felt guilty about missing work, and was generally frustrated the whole time. I know it sounds weird, but please don't let this dissuade you from retreat. I've talked to many people about their first experiences with sesshin and almost every single one of them regards their first time as something deeply moving and insightful. I think I'm just a weirdo.

This second retreat was different. If I'm honest I think a big part of it was that my family had my back. Before, I was new to Zen and it was still this weird thing that dad did on the side. This time, my wife and kids were totally supportive and encouraging simply because it wasn't weird anymore. I know, practice shouldn't depend on circumstances, but it does.

I enjoyed the retreat. Almost the entire time I felt comfortable, at ease, and happy to be there. The traditional "bump" of the first day or two was relatively easy, work periods, meeting with the teacher, meal and kitchen duties, and long periods of sitting all felt rhythmic (for lack of a better word). I shikantaza'd the shit out of that retreat.

Towards the end, I got hit by it. A feeling of insight and understanding that was profoundly moving. I felt like I was seeing the world in a new way. Colors were brighter, sounds were clearer, and everything felt more alive. I felt a deep sense of connection to everything around me, and a sense of peace and contentment that I had never experienced before. All those Zen books and talks clicked into place.

But most importantly, I recognized it for what it was. Makyō. Nothing more, nothing less. Oh, I "danced" but I didn't cling. I didn't even want the feeling to last, because I knew, while very pleasant, it wasn't real.

But I also don't want to dismiss it. It was a beautiful experience, and I'm grateful to have had it. It reminded me of the beauty of the world around me, and the potential for joy and connection that exists in every moment. It was a reminder that even though these experiences may be fleeting and illusory, they can still be deeply meaningful and transformative.

Falsely enlightened? Hell yeah. Makyō kicks ass.