runtimeterror

My second metric century

2026-09-28T01:32:00+00:00

On Saturday I set out with a friend to tackle the Spring City Cycling Club's annual All-You-Can-Eat Century↗. Like last year we opted for the 60(ish) mile / 100(ish) kilometer "Metric Century" route. Unlike last year, I had a proper road bike for the ride.

My friend and I had done a lot more training over this summer to get ready for the ride, and that (plus the right equipment) really paid off. We finished about 40 minutes after than last year, and held a 2.5 mph higher average speed across the entire distance.

We also felt a lot better at the end than we did last year. The big hill wasn't as big of a challenge as I'd remembered it being, we didn't get passed by nearly as many groups, and we got to the finish with plenty of time to enjoy the promised all-you-can-eat barbecue.

Oh and while on course I rolled past 1500 miles on the new bike!

I'm thinking we will try for the full (imperial) century next year.

Well, Louder Than Life kind of sucked (for us)

2026-09-25T02:46:00+00:00

We hadn't initially planned on it, but when the lineup for Louder Than Life↗ dropped back in February, I knew that my partner (C) and I needed to go. There were just so many bands we love playing that we really didn't have a choice.

I mean, seriously:

Gojira
A Day To Remember
The Prodigy
Babymetal
Rise Against
Ice Nine Kills
Taking Back Sunday
Dance Gavin Dance
Nothing More
Lindsey Stirling
Dethklok
Underoath
Starset
Thrice
Bowling For Soup
Thursday
We The Kings
Fit For A King
GWAR
Atreyu
Lit
Blue Medusa
Erra
After The Burial
Currents
Alient Ant Farm
Scene Queen
Haste The Day
Hail The Sun
Mac Sabbath
Alexisonfire
Emery
Born Of Osiris
Icon For Hire
Dark Divine
Future Palace
Set For Tomorrow
and like a million other bands

How could we miss that? So, anyway, I immediately bought tickets↗, splurging on a hotel package with VIP passes and prepaid festival parking in a reserved lot to ensure things went as smoothly as possible.

Spoiler: that didn't quite work out.

Day Zero (Wednesday)

We drove up to Louisville, KY on Wednesday and settled in to our downtown hotel room. Traffic was a little dumb but we managed the drive in about five hours without any incidents or drama. We settled in to the hotel and turned in at a reasonable hour to rest up for the anticipated four full days of loud music.

Day One (Thursday)

We got up Thursday morning and drove the ~15 minutes to the festival lot and were immediately directed into a spot and then loaded into a golf cart for the short ride over to the festival proper. (I knew the lot was about a half mile from the festival entrance and had assumed we'd just be walking there; the golf cart shuttle was a really nice surprise!) Once there, it took maybe ten minutes of waiting in line before we got through security and scanned our wristbands on the way in to the festival itself. Off to a pretty good start!

This was a pretty large festival. There were seven stages spread throughout the site. It could be a bit of a trek to get from one end to the other, but you could realistically traverse between any two stages in less than ten minutes. There were also a bunch of food, drink, and merch stands as well as portable restrooms spread between the stages. Additional merch areas were inside the buildings at the Kentucky Expo Center, which offered a great air conditioned way to beat the heat in between sets. Our VIP passes also bought access to further shaded areas (and air conditioned restrooms!) to help us try to keep cool, an ongoing challenge with a heat index around 104°F (40°C).

Anyhoo, we kicked things off with Set For Tomorrow playing inside of a tent with surprisingly decent airflow thanks to big ass fans. This was our second time seeing this band live, after seeing them open for Dark Divine back in March.

After that set wrapped, we went over to the VIP area to watch some of the bigger stages from shaded comfort. Mac Sabbath played a number of Black Sabbath-inspired songs about fast food while dressed as fast food mascots, and their vocalist (clad in yellow and red like a certain fast food clown) maintained a pretty solid Ozzy-like delivery throughout. He even bit the head off of a (rubber) bat!

We also got to see another heavily-costumed band: GWAR. I knew of these guys but didn't really know what I was in for. All the members wore elaborate masks, prosthetics, and costumes to make them look like disgusting alien monster characters, and they all suffered various wounds during the performance, causing them to spray gallons of red, blue, and green "blood" all over the crowd. Their music was pretty forgettable but I was amused by the stage show. And it was fun to see people dyed red and blue later in the day.

One of the bands we were most looking forward to was Dark Divine, and they played a killer (if all too short) set. I swear they get better every time we see them, and they were pretty awesome the first time. Their performances are just always so much fun.

Bowling For Soup played fan favorites like "Teenage Dirtbag" and "Stacey's Mom" (and some of their own music, too).

I always love seeing After The Burial, but my neck always feels sore afterwards for some reason.

I've wanted to catch a Starset show for 10 years or so, and I'm glad to have finally done so. They played some great tunes and put on a very cool performance as well. I was pleasantly surprised by the violinist and cellist playing on-stage the whole time!

Also, they had neat fire.

We wanted to stick around for Currents and Fit For A King but we're old and it was wicked hot on Thursday so we turned in early to get ready for the following day.

Day Two (Friday)

That, uh, didn't work out.

This is where it gets kind of gross.

The short version is that my partner had a medical emergency which caused us to spend the remainder of the weekend in the hospital. We're going to talk a bit about blood and stuff which might be somewhat traumatic. I won't be offended at all if you just stop reading here.

C got up Friday morning to go to the bathroom and returned to report she'd had "some" blood in her stool. She had a colonoscopy the previous week and they'd removed and cauterized a few polyps, so we assumed one of those spots had started seeping. And then she pooped again and it was basically just blood. And then again.

I declared that I was taking her to the ER (against her protests) because bleeding out your butt is decidedly not okay. Fortunately there was a hospital about four blocks down from the hotel so it was pretty easy to get to.

We only had to sit in the ER waiting area for about thirty minutes before they called her back, and the nurses and other staff were all really helpful and friendly. They checked all her vitals and drew some blood to check that too, and gave her some fluids since she was a little dehydrated after spending the previous day out in the obscene heat. Her blood pressure and hemoglobin numbers were both fine so they weren't overly concerned, but did perform a CT to confirm that they didn't see signs of further active bleeding.

We were released after about six hours and advised to take it easy that evening but that we should be fine to return to the festival on Saturday. We had an early dinner, lounged about the hotel for a bit, and went to bed kind of early.

Day Three (Saturday)

But we didn't make it back to the festival on Saturday, either. Instead, C continued to have bloody bowel movements early Saturday morning. The last one was accompanied by a loud thunk from the hotel bathroom.

I trotted over to check on her, and heard her faintly groan my name as I approached the bathroom door. I opened it to find her sprawled on the hard floor atop a growing puddle of blood. She was moaning a bit but not responsive. Her skin was pale and she was kind of sputtering a bit while taking fast shallow breaths. Her pulse was rapid and weak.

It was pretty damn scary for those of us who were conscious. I managed to roll her onto her side, made sure her airway was clear, and told her I was calling an ambulance. I knew she was in really bad shape when she didn't object to that.

She came to while I was on the phone with the 911 dispatcher and even managed to call out the hotel room number that I was struggling to remember. The puddle beneath her slowly grew into a pool that reached from her knees to above her head but she also become more alert and responsive while we waited for help to arrive.

It seemed like ages but was probably only 6-7 minutes before the EMS team arrived and made their way up to our hotel room. The medics seemed a bit surprised by the amount of blood on the floor. They hooked C up to a portable monitor to check her vitals and found that her blood pressure was very low (particularly for her). And then they lifted her onto the gurney to roll her down to the ambulance waiting on the street. I grabbed some extra clothes and such on the way out the door and followed them down.

Once in the back of the ambulance they started a saline IV and we got on the way. The ride to the hospital wasn't long (again, just a few blocks). Upon arrival, they wheeled her straight into the emergency department while I was directed to the same waiting area we'd sat in the previous day.

A nurse called me back to join C a few minutes later. By that point they'd added another IV in her other arm with something to help promote clotting, and she began looking a little less pale. She was alert and coherent as she talked to the nurses but it was clear she was still in a bad way. Her blood numbers (both pressure and hemoglobin count, I guess, idk I'm not a doctor) were still really low so they also added a bag of blood to the mix.

After about an hour she seemed to be doing a lot better thanks to the blood and drugs and fluids (and my comforting presence, obvs). The nurses wheeled her off to get another CT scan, and I called the hotel to let them know that our bathroom looked like a murder scene and see if they could maybe clean it up a bit (pretty please). The woman I talked to was really understanding and said they'd take care of it.

C returned from the CT and the doc reported that the scan still didn't show an active GI bleed, but clearly the blood was coming from somewhere (even if she wasn't actively bleeding at that point in time). After a brief consult they decided to schedule another colonoscopy for the following morning so they could identify the source of the trouble and (hopefully) resolve it for real this time.

Let me tell you, C was not thrilled by the prospect of having to prep for another colonoscopy so soon after the last one.

The nurses eventually got C moved out of the emergency department and into a private room for her overnight stay. After she got settled in, I wandered around the hospital for a bit until I managed to find an exit that didn't lead to the parking deck (where I'd driven us on Friday) or the ambulance bay (where we'd come in that morning). I then walked the four blocks back to the hotel so I could shower, change clothes, grab a quick dinner, and drive back to the hospital to spend the night in a recliner helping her stumble between the bed and the bathroom.

Day Four (Sunday)

Neither of us got much sleep Saturday night. The colonoscopy prep was a part of it, but the nurse also came in every hour to recheck C's vitals and every 3 to draw more blood to monitor her hemoglobin numbers. So Sunday came very early for us.

Of course, being the weekend they weren't able to schedule the procedure extra early like they normally would during the week. We just sat around trying to grab tiny naps until they finally came to retrieve her at about 11:30 AM, at which point I slipped down to the hospital cafeteria to grab a quick bite. C returned to the room at about 1PM. She'd been told that the scope procedure "went well" but we didn't yet know if that indicated they had successfully found and stopped the source of the repeated GI bleed.

We had to wait another couple of hours before the doctor came by with the post-operation report. They had identified and stopped the bleeds by applying clips to the previously-cauterized spots where the polyps had been removed. Apparently it's not uncommon for cauterized cuts to bleed again a week or so after surgery, while clips are somewhat less prone to such complications.

After some quick convincing, the doc agreed that C was doing well enough to be discharged rather than requiring her to spend another night. So we hastily gathered up our stuff and made our escape back to the hotel before they changed their mind.

We went to bed early and slept quite soundly.

Coda

We got up and checked out of the hotel Monday morning, as originally scheduled, glad to head back home and for C to be on the mend. Her stomach was pretty wrecked from all the diarrhea followed by not eating followed by colonoscopy prep, so she had to ease back into eating again. She's finally feeling like herself again, which is such a huge relief.

Finding her bleeding on the bathroom floor was one of the scariest things I've ever faced. I'm so grateful that she's okay.

We really enjoyed the one day of the festival that we got to attend, and wish we'd been able to see more of the bands we'd wanted to. Fortunately we do have another, smaller, closer festival↗ lined up in a few more weeks. Hopefully that weekend will be a little less eventful.

Double the mesh

2026-09-06T02:14:00+00:00

I've spent the past year and a half or so tinkering with Meshtastic↗, an off-grid decentralized mesh network which operates on inexpensive LoRa¹ radios. I started with the LILYGO T-Deck Plus↗; I was impressed by the Meshtastic capabilities but rather underwhelmed by the initially-compelling promise of a true standalone device. I then picked up a Seeed Studio T1000-E tracker↗, a rugged card-sized radio that's perfect for my everyday carry needs. I also added a RAKwireless RAK4631↗ with a big fuck-off antenna↗² as a base station mounted up in my attic.

It's been neat to connect with a bunch of folks on our local mesh, and I've even met some interesting meshers while traveling as well. But I recently decided I wanted to check out a newer mesh protocol called MeshCore↗. MeshCore is similar to Meshtastic in that it also runs a mesh on cheap LoRa radios, but the implementation is pretty different³. Meshtastic messages traverse the network because every node (by default) rebroadcasts every message it receives (up to a limit: default of 3, maximum of 7). This makes it really easy to grow the mesh, but also adds a lot of overhead broadcast traffic which can make it harder to send new messages in a saturated area. MeshCore imposes more rigid roles where only designated infrastructure nodes will retransmit message. This can result in a much more efficient network and the potential to cover larger distances due to much higher hop limits (64 versus 7)... but that can't happen until an area is sufficiently blanketed by infrastructure nodes doing that repeating.

Anyway, I wanted to give it a shot and see how it worked in my neck of the woods. I started by using the handy-dandy web flasher↗ to load the Ripple GUI↗ on my T-Deck Plus and was immediately impressed by what a more polished experience it offers when compared to the more basic Meshtastic UI. The Ripple GUI really focuses on the standalone experience⁴ and it ensures that all the radio capabilities are easily accessed through the GUI (and not buried under hidden keyboard shortcuts).

I didn't pick up any other nodes that first evening at home. I carried the radio with me to work the next day and was pretty excited to discover a couple⁵ of repeaters. I even found one kind of near my house. That seemed promising, so I decided to go all-in and convert both my everday carry T1000-E and the RAK in my attic over to MeshCore as well. I selected the typical Bluetooth Companion firmware for the tracker and the Repeater firmware for the attic node⁶, hoping that maybe I can be a part of the change I want to see.

With multiple nodes running MeshCore I was able to experiment a bit more with the network's capabilities. Messages between my client nodes were delivered very quickly, and I could reliably ping my attic node from a mile or so away - as long as I stayed in my little valley rather than venturing to the other side of a crest. Remotely managing that infrastructure node over the MeshCore network works very well, too.

Of course, after several days I came to accept that MeshCore is quite a bit lonelier than Meshtastic in my area. The repeater in my attic is able to see regular advertisements from another repeater I estimate to be about a mile away, and I've seen a few discovery adverts come through from other client nodes but two-way comms seem somewhat unreliable so far. I think MeshCore has a lot of promise, and I like using it more than Meshtastic, but the infrastructure just isn't here to support it. Yet.

Still, I like MeshCore enough that I'm not going to give up on it; maybe the fixed repeater in my attic can help to grow the network as others (hopefully) come online. Until then, I wanted to get back onto Meshtastic so I could keep in touch with the existing local community for now. I was thrilled to discover that my local nerd store↗ recently began stocking a small selection of LoRa radios↗. This is knowledge I should not have⁷. I stopped by after work and picked up another T1000-E tracker card for everyday carry and a ~$15 Seeed Studio XIAO nRF52840 & Wio-SX1262 Kit to use as an additional attic node⁸.

I hope that MeshCore adoption here grows in the not-too-distant future, but until then I can keep nodes in both networks.

For "Long Range", typically 2-8 miles depending on line of sight and obstructions. ↩︎
I later realized that the giant antenna doesn't actually do me a ton of good since my house sits in a bit of a valley. I can't really overcome the line-of-sight limitations of the ~915 MHz LoRa radio band just by increasing the gain. If a signal is blocked by a mountain/tree/building, it's blocked, and that's all there is to it. Ah well, it LOOKS really impressive at least. ↩︎
This post↗ does a good job of comparing the two networks. ↩︎
A good decision since this particular firmware variant only supports the standalone device type. There's no option to connect a phone to use it as a companion node. ↩︎
Literally: two. ↩︎
With Meshtastic, you don't really want to set just any node as a router/repeater role since that can have an adverse impact on the network's health. That's not really a concern with MeshCore which should make it easier to set up infrastructure. ↩︎
Now that I know I can pick up cheap mesh radios locally I'm going to really struggle with the urge to start building and distributing solar nodes↗ to help improve the coverage. ↩︎
Even with the tiny antenna that comes with the XIAO kit, the extra elevation does help. ↩︎

2026 TAC Autocross Event 7

2026-08-11T02:09:00+00:00

It seems like ages since my last race way back in June. Our club's July event happened to fall on my partner's birthday and I decided to spend the day with her instead of ~~in the hot July sun~~ playing racecars. But it's August now¹, and our club hosted our seventh event of the 2026 season on Saturday.

We took on a challenging course which made full use of the stadium parking lot's workable surface (and really pushed the wireless timing system to its line-of-sight limits).

I struggled to put down a good time - but my SSC competitor also struggled with putting in a clean lap. When we broke for lunch, I was leading the class with a 47.285 compared to his 45.529+1.

When we returned for the afternoon session, he jumped in front with a 47.130, and then I regained the lead by putting down a 47.015. It was pretty exciting!

Of course, he then managed to drop almost a full second and got down to 46.323. I only shaved a few thousandths and ended with a time of 47.006 on my fifth run.

I totally would have beaten him on my sixth run but we had to end the event early due to lightning from an incoming storm system. Maybe next time!

Oh, and while I struggled with the course all day, I also struggled with my datalogging setup as well. My RaceCapture device has become pretty unreliable and its Bluetooth² connection kept dropping in the middle of a run. So no pretty gauges on the video this time. I'll switch to a simpler setup going forward.

Um, yikes. ↩︎
The worst tooth. ↩︎

2026 TAC Autocross Event 5

2026-06-21T00:00:00+00:00

After a short break, I returned to the ~~race track~~ parking lot yesterday for another exciting round of local autocross competition. The forecast had once again called for thunderstorms all weekend, but the weather took pity on us. We had just some light sprinkles during setup and the first set of runs but that quickly cleared up, and we then had scattered clouds and a nice breeze the rest of the day. It was hot, but not uncomfortably (or dangerously) so; June autocross weather could be a lot worse than what we got.

The course was our fairly standard layout with a few tweaks to make it a bit of a challenge. There were several areas when you really had to give up speed in order to set up for the corner exit (and entry into the next feature), and you were punished with severe understeer push if you didn't heed that. It was a really fun course to drive, and I had a blast!

My best time was 41.493, putting me "just" 0.7 seconds behind the SSC class leader; that's an eternity in autocross, but I usually trail him by more than a full second so this loss still felt like an accomplishment. I finished 28th of 112 in PAX (the SSC winner finished 16th).

We've got another full month before the next race.

Yellowcard: Up Up Down Down Tour

2026-06-11T21:56:00+00:00

Back in November, my partner and I got to see Yellowcard open for A Day To Remember on their Maximum Fun Tour↗. We were somewhat disappointed by ADTR's performance (and their over-reliance on those giant distracting video screens that I've been complaining about lately) - but rather blown away by Yellowcard's set.

So we jumped at the opportunity to see Yellowcard on their own headline tour, this time accompanied by New Found Glory. I've listened to both band's latest releases (Yellowcard: Better Days↗, New Found Glory: Listen Up!↗) a lot lately, and I was really looking forward to this show.

The date finally came on Monday, and we drove up to Nashville's Ascend Ampitheater↗, hoping that the looming bad weather would clear off and we wouldn't get wet. It did! And we didn't!

And the show was really great!

Plain White T's

Plain White T's got things started. I honestly hadn't thought about this band at all in twenty years. They did fine, but definitely not anywhere near the energy levels we typically see at shows. Their performance brought big "middle-aged dads decided to start a band, again" vibes - which I guess is fair given that several of the members are likely middle-aged dads at this point.

Still, I enjoyed hearing Hate (I Really Don't Like You)↗ and that other song↗.

New Found Glory

The tempo picked up quite a bit when New Found Glory took the stage. They sounded great and were full of energy, and it was cool to see Chad¹ join the band on stage for a few songs.

NFG played a bunch of old favorites (including Understatement↗ and Hit or Miss↗) and new favorites (like Laugh It Off↗ and Beer and Blood Stains↗) before closing with My Friends Over You↗.

Yellowcard

Yellowcard's set was similar to the last time we saw them in a lot of ways. The theme leaned heavily into 80s nostalgia, with clips from movies and TV shows playing on a (relatively) small display on the sage throughout the performance. It could have been distracting but it somehow wasn't; it really complemented their music and presentation rather than drawing away from it.

And their music was incredible! They sounded so good, and delivered every note with passion and energy.

They played a well-balanced set with old classics as well as plenty of new stuff. Highlights for me included Better Days↗, Way Away↗, Love Letters Lost↗, Lights and Sounds↗, and Bedroom Posters↗.

They ended the night of fantastic live music with Ocean Avenue↗.

Yellowcard's live performance definitely ranks among the best that I've seen lately. I heartily recommend catching one of their shows if you get the chance.

Founding member and long-time guitarist Chad Gilbert has been fighting cancer for several years. ↩︎

2026 TAC Autocross Event 4

2026-06-07T21:05:00+00:00

Our local car club returned to the track¹ yesterday for our fourth² autocross of the year. The weather was quite warm, though a steady breeze and some welcome cloud cover in the afternoon kept it from being terribly uncomfortable. We had a number of new faces joining us, either first-time autocrossers or experiences racers visiting from other regions.

We got to race on a tight and twisty course that wound up flowing a lot better than I'd anticipated based on my morning course walks.

It was a fun course to drive, and I really wish we'd gotten more than six runs. I managed to get down to a 40.903s on my last run. I was pleased with that since I'd been struggling to get out of the 41s all day, but it still wasn't a super competitive time.

(Also, my datalogger acted up so here's the raw video with no pretty overlays.)

I finished 2nd (of 2) in the Solo Spec Coupe class (down by 1.6 seconds - an eternity), and 33rd of 115 in PAX. (The SSC winner finished 7th PAX. Dude is quick.)

Parking lot of an athletic stadium. ↩︎
Last month's two day event only counts as one. ↩︎

Learning to ride a bike

2026-05-31T17:16:00+00:00

I've been riding a bicycle (as an adult) since 2020, but I only recently picked up my first road bike. As it turns out, a road bike is a very different beast¹ than the hybrids I'd been on so far, and I have learned a ton in my first month (and ~325 miles) with the new steed.

I'm no bicycle surgeon

What follows are some of the things that I've picked up on in my relatively short time as a real cyclist. I'm probably going to screw up some terminology and explanations and who knows what else. You can correct me if you'd like, but I'm just letting you know that I'm kind of making this up as I go and if I'm wrong then oh well.

Starting with...

Getting a grip

Look, the bike I'd been on only had one place for me to put my hands. It was either grab on to the flat handlebars or... ride my bike with no handlebars². This new rig has ~~so much room for activities!~~ so many more options for holding on.

The horns 🤘

These vertical bits on either end are apparently the "brake horns"³, and they're where the brake/shifter levers attach to the whole setup⁴. They also make for a pretty natural spot to hold on.

Gripping ~~life~~ bikes by the horns puts your wrists in a nice neutral position (reducing fatigue) while also maximizing access to the lever that control this thing. Also, spreading your hands a little wider like this can really help with stability.

Speaking of stability, I've also learned that I really shouldn't be leaning down on the handlebars. That was kind of a natural thing to do on the hybrid bikes with their far-more-upright seating positions. With a road bike, it seems like The Thing To Do is more of a reaching forward sort of approach. I lean my upper body forward but keep my elbows bent (down), and my forearm is then almost parallel to the ground as I push my palms forward to grasp the horns. The handlebars don't really support my upper body weight as much as just provide some stability for me to hold myself up. This results in a lot less fatigue in my shoulders, elbows, and wrists.

Anyhoo, this is where my hands hang out about 90% of the time I'm on the bike.

The drop

You may have noticed that these handlebars also have a curved bars that drop down below the horns. These are the "drop bars"⁵ and I kind of assumed they were just useful for getting really low like when you wanna go really fast.

Well they are useful for tucking⁶ out of the wind to reduce trag, but bending over further can also provide a little extra oomph when climbing up a hill or pushing for more speed. (More posture stuff coming up later.)

At rest

The horizontal portion of the handlebars is perfect for rest breaks.

You wouldn't want to try to hold on here while pedaling aggressively or diving down a hill or navigating a turn or really anything other than straight-and-level flight, but it's a nice relaxed spot to hold while slurping from a bottle or scarfing down a protein bar.

A position of power

I learned a lot about the various muscle groups used at various stages of the pedal stroke while getting my new bike fitted, but the key takeaway for me⁷ was the impact that posture has on power production.

A road cyclist's standard forward-leaning position engages a whole bunch of muscles as they pedal away. Pivoting the upper body further forward adjusts how early certain leg muscles get activated, and can provide a more powerful pedal stroke.

And it's the dropped handlebars that allow for that extra angle. So that's why grabbing the drops can help with hill climbs.

Standing on the pedals and lifting my butt out of the saddle can further increase power output because it's (again) changing how early some of those really long muscles get in the game.

Shifting gears

I've also learned a completely new-to-me strategy for shifting between gears. On the hybrid bikes, I shifted without any real direction, just kind of grabbing whatever gear combination felt goodish.

On the road bike, I've learned that cadence is king. I'm working on establishing a pedal speed of around 90 rpm and then shifting up or down to maintain that cadence at a given power output level. It kind of makes me think of a car with a CVT transmission↗, where the engine may keep a steady speed even as the vehicle is accelerating.

The new bike has twelve cogs on the rear sprocket so I've got a lot of options, but this approach takes the guesswork out of it. And I'm able to take small steps up or down to really dial in the amount of force I used to propel myself forward. This results in more speed, more efficiency, and less fatigue - all good things as I take on longer rides.

Like dancing, steer with your hips

I don't dance

I know even less about dancing than I do about cycling, but it is my understanding that the hips are involved in some way.

And, finally, I'm learning that road bikes can be quite sensitive to even small control inputs. Pushing a hand a little harder than the other can result in an abrupt change of direction, perhaps with disastrous effects⁸. So I don't really use the handlebars for steering.

Instead, I steer by shifting my hips in the direction I want to go. Just the slightest bit of weight transfer is all that's needed to smoothly maneuver without throwing anything off balance.

It reminds me a bit of this remote control motorcycle toy that I had as a kid. It had two big balloon-inflated tires, and a weighted rider on top that pivoted left or right to induce a turn. Same idea, I think.

Plus now I really can ride my bike with no handlebars².

Admittedly I bristled a little bit when the guy at the bike shop referred to me as a "novice rider" even after nearly six years of riding regularly, but he was totally right. I'm kind of starting over again. ↩︎
No handlebars↗. ↩︎ ↩︎
Bike terminology is so, so dumb. ↩︎
You can't really see the levers in these photos because the photographer (👋) is a moron, but I promise they're there. ↩︎
Not drop bears. ↩︎
Not that kind of tucking. ↩︎
Well, after getting all the bike's geometry adjusted to maximize the correct muscle usage, or whatever. ↩︎
And another reason to not lean my whole upper body weight on the handlebars. ↩︎

Embedding remote feeds in a Hugo static site (without JavaScript)

2026-05-28T21:17:00+00:00

For a year or so, this site has been using RSS2HTML↗ to pull in items from an external feed (specifically my Linkding instance↗) so they could be displayed on the sidebar (and the dedicated /bookmarks and /postroll pages). This approach uses client-side JavaScript in combination with a proxy server to retrieve the feeds, parse the items, and render them in the page. That has worked okay but can sometimes (often?) cause page loading to hang while waiting for the JavaScript to complete.

Plus, no one likes unnecessary¹ JavaScript.

So I switched to using Hugo's built-in resources.GetRemote↗² and transform.Unmarshal↗ functions to do the same thing. This approach won't be quite as "dynamic" since the feeds will be fetched at build time rather than on page load, but I've already set up a deployment pipeline³ to build and deploy the site daily.

resources.GetRemote accepts the URL to fetch as an argument (I'm using the RSS feed URL for public Linkding items tagged with #bookmarks), and then passes that feed to transform.Unmarshal to parse the XML.

That feed looks a bit like this, by the way:

<rss version="2.0">
  <channel>
    <title>Public shared bookmarks</title>
    <link>https://links.vim.wtf/feeds/shared</link>
    <description>All public shared bookmarks</description>
    <atom:link href="https://links.vim.wtf/feeds/shared" rel="self"/>
    <language>en</language>
    <lastBuildDate>Wed, 27 May 2026 12:39:50 +0000</lastBuildDate>
    <item>
      <title>Transformer Explainer: LLM Transformer Model Visually Explained</title>
      <link>https://poloclub.github.io/transformer-explainer/</link>
      <description>
        An interactive visualization tool showing you how transformer models work in large language models (LLM) like GPT.
      </description>
      <pubDate>Wed, 27 May 2026 12:39:50 +0000</pubDate>
      <guid>https://poloclub.github.io/transformer-explainer/</guid>
      <category>bookmarks</category>
    </item>
    <item>
      <title>Hister - Your Own Search Engine</title>
      <link>https://hister.org/</link>
      <description>
        Hister is a general purpose web search engine providing automatic full-text indexing for visited websites.
      </description>
      <pubDate>Thu, 21 May 2026 15:47:29 +0000</pubDate>
      <guid>https://hister.org/</guid>
      <category>bookmarks</category>
    </item>
  <!-- [...] -->

So for the sidebar I just iterate through the first five items and grab its title and link:

<h3>bookmarks</h3>
{{ with resources.GetRemote "https://links.vim.wtf/feeds/shared?q=%23bookmarks" | transform.Unmarshal }}
  <ul>
    {{ range first 5 .channel.item }}
    <li>
      <a href="{{ .link }}">{{ .title }}↗</a>
    </li>
    {{ end }}
    <li>
      <em><a href="/bookmarks/">More bookmarks</a></em>
    </li>
  </ul>
{{ end }}

That works well for the minimal embed in the sidebar:

For the larger /bookmarks and /postroll pages, I can't use that Go template directly since they are Markdown pages. So I created a shortcode at layouts/shortcodes/feed-embed.html that I'll be able to include in a Markdown document. The shortcode accepts two positional parameters: the feed URL to fetch and the number of items to retrieve. It also extracts the link's description and the date it was bookmarked (converted to a YYYY-MM-DD time format).

{{- $feed := .Get 0 -}}
{{- $limit := .Get 1 -}}
{{ with resources.GetRemote $feed | transform.Unmarshal }}
<div>
  {{ range first $limit .channel.item }}
  <h3>
    <a href="{{ .link }}">{{ .title }}↗</a>
  </h3>
  <div>{{ .description }}</div>
  <div><em>Added: {{ .pubDate | time.Format "2006-01-02" }}</em></div>
  {{ end }}
</div><br>
{{ end }}

I use my new shortcode like this:

---
title: "/bookmarks"
description: "Sites and resources that I've bookmarked recently"
---
# Recent bookmarks

{{< feed-embed "https://links.vim.wtf/feeds/shared?q=%23bookmarks" 25 >}}

👉 [**Even more bookmarks**](https://links.vim.wtf/bookmarks/shared?q=%23bookmarks)

And that works too!

The last tweak I made was to adjust the Forgejo Actions workflow↗ to build the site every six hours instead of just once per day:

on:
  schedule:
    - cron: 0 */6 * * *

That should be a goodish balance between keeping the embedded bookmarks and postroll up-to-date while not just constantly rebuilding the site for giggles.

Typo↗ is very cool and thus necessary. Don't at me. ↩︎
Which I've previously used for dynamically updating the site's robots.txt file. ↩︎
Since writing that post, I migrated my work from GitHub to a self-hosted Forgejo instance↗ and slightly tweaked the deployment workflow↗ accordingly. ↩︎

Gokapi for self-hosted secure file sharing

2026-05-25T17:18:00+00:00

I recently wanted to share a 30MB file with someone, which is still a harder problem than it should be¹. Too big for most email providers, and I didn't want to have to run through the list of cloud file store options to see which we had in common. In the past, I've handled this by using Tailscale Funnel to temporarily expose a Caddy file_server↗ for long enough for the other party to retrieve the file(s). Hardly an elegant solution.

This time, though, I stumbled upon Gokapi↗ which checks a lot of my boxes²:

Open source
Self-hosted with a single container image
End-to-end encryption
Auto-expiring and download-limited links
OIDC authentication for being able to upload files
S3-like object storage support

I particularly like that I can connect Gokapi to external storage (to avoid using up all the storage on my VPS), that links (and corresponding files) will be automatically removed after a defined time period or number of downloads, and that it doesn't allow internet randos to upload files (my compute resources are finite, after all).

It only took me a few minutes to deploy the Gokapi container on an existing Hetzner VPS, link it to Pocket ID for auth, connect the storage backend to Bunny's (beta) S3 storage offering↗, and get on with sharing files.

Deployment

The Gokapi repo has an example docker compose file↗ to make it easy to get started. I just created an /opt/docker/gokapi/ folder on my server to hold the app's configuration and data (the integrated sqlite database) and then brought up the single-container stack:

services:
  gokapi:
    image: f0rc3/gokapi:latest
    container_name: gokapi
    ports:
      - "127.0.0.1:53842:53842"
    volumes:
      - /opt/docker/gokapi/data:/app/data
      - /opt/docker/gokapi/config:/app/config
    restart: always
    environment:
      TZ: UTC

The repo also provides an example .env file↗ in case you want to use environment variables to configure the deployment. This time I skipped right past that and instead used the web interface to perform the configuration. More on that in a moment.

But first, I used Caddy↗ to proxy the container with automatic TLS magic:

gokapi.example.com {
    reverse_proxy http://localhost:53842
    log {
        output file /var/log/caddy/gokapi.log
    }
}

After doing a quick docker compose up -d to start Gokapi and sudo caddy reload -c /etc/caddy/Caddyfile to ask Caddy to please start serving the new thing I can point my browser to https://gokapi.example.com/setup and get on with the configuratin'.

Hurry up!

Until the initial configuration is complete, anyone can access that URL to configure the instance. So you'll probably want to speed through the first-run config or configure Caddy to only allow access from your home IP for now↗.

After the first config, the /setup endpoint will only be available if you explicitly ask for it at container startup, and it will then also be protected by a randomly-generated username and password.

I just stick with the default sqlite database and initial webserver options, but I update two values on the Webserver 2/2 screen:

Public facing URL is set to https://gokapi.example.com/ to reflect the base URL where this thing will be served publicly.
Redirection URL points to my little jwq.lol↗ landing page. Basically there's no reason for an outside user to poke around the main page of my Gokapi instance so anyone that hits the index page will get sent elsewhere instead.

I want to use my Pocket ID setup for logging in to Gokapi's admin page, so I enable OIDC auth:

I then created a new OIDC client in my Pocket ID deployment:

Notable configuration details from that:

Client Launch URL: https://gokapi.example.com
Callback URLs: https://gokapi.example.com/oauth-callback
PKCE: disabled

Then I could use the Client ID and Client Secret for configuring the auth back in Gokapi:

The key here is that the Admin email address must match the email for your user in Pocket ID since that's how you'll be granted access.

Then I moved on to the storage setup. I wanted to use external S3-compatible object storage so I wouldn't have to worry about blowing up the disk on my VPS. So I selected Cloud Storage from the appropriate dropdown:

I'm using Bunny's new S3-compatible storage offering but the setup should be pretty similar for any provider:

CORS

Clicking the Test configuration button yielded a warning:

Test OK. WARNING: CORS settings do not allow encrypted downloads.

I know that Bunny's S3 support is still in early stages and doesn't yet support custom CORS rules and I suspect this warning may be related to that. Encrypted downloads work fine for me, but if you get a similar warning and they don't work, try enabling proxy downloads at the bottom of the previous storage configuration page.

And I want to use full end-to-end encryption; that makes the client work a little harder since it handles the encryption/decryption when files are uploaded/downloaded, but I like that the (possibly-sensitive) files will be completely encrypted at every step along the way.

Firefox issues

There's a pinned issue↗ on the Gokapi repo about Firefox (and derivatives) having trouble downloading files which were uploaded with end-to-end encryption. I haven't run into issues yet, probably since I've so far just been sharing files with sizes in the tens of megabytes. But if you intend to share much larger files you may want to use one of the lower encryption levels until that issue gets fixed.

All that's left is to click the big friendly Submit button to save my settings and get on with sharing files!

Usage

Now that setup is complete, if I just point my web browser to https://gokapi.example.com... I get immediately redirected to my profile page↗. Oh yeah, I did set up that redirect. Well it's cool that it works!

To be able to do stuff in Gokapi, I can instead head to https://gokapi.example.com/login, and this time I get redirected to the Pocket ID auth challenge:

Once I'm in.³, I immediately get hit with a screen telling me about the randomly-generated password to support end-to-end encryption.

This gets generated in my browser (not on the server) and and will be used for encrypting files uploaded the server. The server never knows about this password and thus wouldn't be able to access the encrypted even if it wanted to.

Save this somewhere safe!

The prompt isn't kidding: this random password won't be displayed again. It never gets uploaded to the server and exists solely in your local browser session. You'll need to re-enter the same password any time you log into Gokapi from a new machine (or erase your browser's local storage).

If you lose it, you can rerun the Gokapi setup to generate a new one - but you won't be able to access any of the files which were already uploaded.

Anyhoo, once I've confirmed receipt of the encryption password I can get on in to the main Gokapi interface:

I've got options there for limiting how many times a file can be downloaded, automatically removing it after a set number of days, and optionally setting a password for the file. These options will be applied to the next uploaded file.

I went ahead and left those options on their default settings, and uploaded a 1GB file to test things out.

Now that the file has been uploaded, I can click the little "copy URL" button at the right to grab the URL I can send to my friend. I could also click the little pencil icon to change the download limit, expiry, or password options for the file.

I'd like to see what the experience looks like on the other side of things, so I'm gonna go ahead and paste the download link into another browser and download the file:

After downloading the file once (the limit configured for that file) it gets automatically removed from the server and subsequent visits to the URL are met with a 404.

Reconfiguration

Once the initial setup has been completed, the only way to revisit and change settings is to restart the container and pass the --reconfigure flag. I usually do this by stopping the compose stack and then firing off a standalone container:

$ docker run --rm -p 127.0.0.1:53842:53842 \
        -v /opt/docker/gokapi/data:/app/data -v /opt/docker/gokapi/config:/app/config \
        f0rc3/gokapi:latest /app/run.sh --reconfigure

██████   ██████   ██   ██  █████  ██████  ██
██       ██    ██ ██  ██  ██   ██ ██   ██ ██
██   ███ ██    ██ █████   ███████ ██████  ██
██    ██ ██    ██ ██  ██  ██   ██ ██      ██
 ██████   ██████  ██   ██ ██   ██ ██      ██

Gokapi v2.2.4 starting

###################################################################
Use the following credentials for modifying the configuration:
Username: q12RsR
Password: 9yyrmvLPNN
###################################################################

Please open http://127.0.0.1:53842/setup to setup Gokapi.

I can then log in to https://gokapi.example/com/setup using the provided credentials and make my changes. Once I'm done, I exit the running container and restart the compose stack to pick up the changes.

Conclusion

I'm pretty pleased with this setup so far, and it seems to work rather well for my needs. I really like that the files automatically get removed after downloading so I don't have to worry about cluttering up storage somewhere, and being able to use external object storage means I don't have to provision a ton of storage on the server itself.

See XKCD 949↗. ↩︎
If you know what I mean... ↩︎
Said in my very best hacker voice. ↩︎