Weeknotes: 2025-04-18

- 5 minutes read - 895 words - Page Source

Continuing my pattern of writing “week"notes every fortnight. It’s not intentional, I swear, it’s just working out that way!

What I Did

  • The Gitea PR for OIDC is still open, though it’s had a milestone label attached, so I’m hopeful that it’ll get merged soon.
  • I finally got a working replacement PSU for my NAS (the original broke back in early February, and I received two replacements that had the incorrect cables in that time), so was able to get my NAS properly installed back in the rack - until now, it’d been awkwardly half-hanging-out, with a differently-sized PSU outside the case with cables snaking Frankensteinily in. Nice to get that tidied away! Although…
  • …power-cycling my NAS (and, therefore, my clusters, both hardware and software) highlighted some cold-start problems of Pods mounting persistence. Thanks to this issue I found that updating to a newer version of k3s did the trick - but that itself came with a host of teething troubles. Still - they got ironed out, and the cluster is now more resilient and fully-featured for it, and all it cost me was a couple hours’ sleep :P
    • I also reinstalled a Raspberry Pi board that had been nonfunctional with a broken SD card for months. Back up to 4 nodes in the cluster!
  • I implemented a feature in EDH ELO that I’d been meaning to do for some time - the ability to seed the database by directly reading the source-of-truth1 Google Sheet, rather than me down/uploading .csvs every time I wanted to update. Cursor/Claude was a major help - as usual, it couldn’t get 100% of the way there by itself, but it got me pretty damn close way faster than I would have with documentation alone.
    • Along the way, I tried using Vault Sidecar Injection2. I’d always found it pretty tricky3 to compare these and the other methods of Vault injection (BanzaiCloud’s webhook, the External Secrets Operator, probably several others I’m unaware of) - without using them, it’s hard to get a handle on their ergonomics. And this is why we homelab!
    • Perhaps a comparison of these methods would be a blog post in the future! TL;DR of what I found - the VSO writes the data as a Kubernetes Secret, which can be referenced as an Env Variable, whereas VSI writes the data into the Pod’s filesystem. Ergonomics aside, VSI should be preferred as Kubernetes Secrets are not actually entirely secure.

What I’ll Do

Move to Vercel

Now that it’s been announced at work, I guess I can also write here that - I’ll be leaving my current job this coming Thursday 24th, and starting at Vercel on the 28th. I’ll be working on their internal DevX Platform, so much of the responsibilities will be the same - tooling, automation, process improvement - but I’m really hopeful that the culture of “a technology company” (rather than “a company that uses technology”) will be more-aligned with how I prefer to work.

I’m especially excited to work at Vercel in particular, as their product focus will help me to strengthen in two areas where I could benefit from improvement:

  • next.js is a Frontend framework; I can sling some HTML/CSS/JS, but I’m definitely more of a Backend-and-Ops guy, so rounding out that skillset will be a good exercise.
  • Turborepo is a build system intended for monorepos. I have long felt considerable cognitive dissonance at the twin facts that:
    • Most of the claimed benefits of Monorepos feel, to me, either like simply “benefits of good tooling” (i.e. neither monorepos nor polyrepos are “better”, here - good tools are just better than bad tools), or as active drawbacks (I’ll save that for another, spicier, post :P ).
    • And yet, lots of smart people seem to genuinely and enthusiastically find them helpful.

So, I must be missing some advantage of monorepos - but, unfortunately, it’s not the kind of system that you can trivially spin-up on a homelab to experience, you really need to work in a “real” one in order to get a feel for it. I’m hoping that a position at Vercel can give me the opportunity to learn what I’m missing!

Continue AI Experimentation

Having recently been converted to “AI Development Tools are Useful, Actually”, I’m also interested to see how v0 stacks up against Claude. I’ve also been tinkering with self-hosting some AI models4, and it’s really highlighted how patchy my understanding is of the layers of the stack. I’d love to dig a little deeper into understanding those system design concepts.

  1. The dream would be for this application itself to be the Source Of Truth. But that requires availability and durability guarantees that are far beyond what I’m willing to commit to at this point. My playgroup’s match history is more emotionally important to me than the data of any company I work at! (hello prospective employers. For legal reasons, the preceding comment is a joke) ↩︎

  2. As opposed to the Vault Secrets Operator, which I’d previously written about here and elsewhere ↩︎

  3. Not helped by a Principal Engineer colleague who straight-up stated that he likes to withold information from people because, quote, “I had to work to get this information, I feel like others should too”. But I digress… ↩︎

  4. My 4Gb GPU can just about run some of the most stripped-down models, but I sense some more hardware investment in my future… ↩︎