Hearthside by Caleb Hearth

Linked: OpenTelemetry Tracing in 200 lines of code

2026-02-24T17:14:21Z

This is really cool and in only 181 lines (Jeremy undersells it in the title) we get a really great explanation of how #OTEL works and why we'd want it.

⬣

Linked: Please, Lego, let this engineer bring your computer brick to life

2026-01-09T16:15:37Z

As #LEGO are releasing the SmartBrick soon, it's a good time to point to this article from a few years back with IMO a much cooler "smart" LEGO brick with embedded screen and capacitive touch studs.

Please, James Brown, sell me some of these!

⬣

Linked: GBC Boot Animation 88×31 Web Button

2026-01-09T13:51:33Z

Pretty neat technical dive into extracting the GameBoy Color's boot animation and using Imagemagick to transform it to an 88x31 button.

via Robb: https://rknight.me/blog/88x31-button-curios/

⬣

Linked: Bundler belongs to the Ruby community

2025-09-25T12:44:02Z

Once there is a Ruby organization that is accountable to the maintainers, and accountable to the community, with openly and democratically elected board members, I commit to transfer my [Bundler] trademark to that organization.

Super happy to see that André both has a plan/goal and that it involves community-directed stewardship over Bundler. Hopefully RubyGems is able to join Bundler under this future umbrella.

⬣

Linked: In the Future All Food Will Be Cooked in a Microwave, and if You Can’t Deal With That Then You Need to Get Out of the Kitchen

2025-09-24T17:52:33Z

One of my chefs mentioned that if they could cook the steak on the grill they could get it right the first time. This is not an acceptable attitude in the microwave era. Chefs have fragile egos and they all seem to enjoy cooking (???) so it’s obvious they’re just too attached to the food. Also they’re worried I’m planning on firing all of them. That’s true but not relevant here.

⬣

Linked: Faster GitHub Actions CI for Swift Projects

2025-06-06T02:37:54Z

I'll be trying out these GitHub CI performance improvements soon for sure.

⬣

Linked: Contabulation

2025-04-23T18:57:27Z

The bottom search in Callsheet and "search drawer" in Ketchup, both built or designed by Ben, have been inspirational in my own app design. So much easier to use.

It's surprising to me that despite Maps and Safari having their search (or equivalent) bars at the bottom, it's quite difficult to reproduce that in SwiftUI.

⬣

Linked: Storing custom metadata in PHAssets

2025-04-19T14:31:05Z

So often we need to do "hacks" like this in the Apple ecosystem. This one seems pretty straightforward but it would be great if we had an arbitrary custom metadata field available in cases like PHPhoto. CNContact also comes to mind as I've been using Contacts framework in Village.

⬣

Tally All Git Trailers in a Repository

2025-04-17T00:00:00Z

I’ve been using a lot of Git Trailers in my commit messages recently and as my thinking on which trailer keys to use has evolved, it’s been useful to look back at which ones have been used before.

git log’s --format flag can provide all sorts of useful information, including trailers. Let’s take a look:

❯ git log --format="%(trailers:keyonly)" | grep '\w\+' | grep -v https | sort | uniq -c | sort 

We start by asking Git to give us the full log with the format of only the trailer keys. That gets passed to a (naïve, but good enough) grep '\w\+ to remove empty lines, then again through grep -v https to remove lines with “trailers” which are just links¹. Finally we tally up the results with sort | uniq -c | sort which is one of my toolbox commands to get tallies of distinct lines sorted by count ascending (so that the most common trailers are nearest the prompt).

That’s helped me remember that Issue is the key I like for linking to the related issue tracker, and not Fixes or Closes...

Obsidian Bullet Journal Tasks Migration in Daily Note

2025-02-20T00:00:00Z

I’ve been tinkering with a modified, task-only Bullet Journaling approach in Obsidian for about a week now and it’s been nice, so I wanted to write up how I’m approaching things.

First, a bit of background. I’ve actually tried Bullet Journaling on paper in the past. I’ve used everything from found scraps of paper to a Field Notes notebook subscription and even invested in some nice cards and a wooden card holder from Ugmonk.

Each time I try “BuJo” I end up bouncing off of it after a week or two—for me at least the analog nature of the paper and pen(cil) approach has always been a downside. Working with physical media has meant that I’m not going to always have those items around, won’t be able to search them from whatever device I’ve got my mitts on at the moment, and in general it’s just not been convenient enough for me. In no time flat the notes, notebooks, and habit are gone.

I’ve also had trouble keeping up with various task management systems, so my recent foray into Obsidian...

Prevent Mastodon and Bluesky from Generating POSSE Link Previews

2025-02-12T00:00:00Z

Yesterday I posted that I’d resolved my new microblog POSSE¹ posts from generating link previews on Mastodon and Bluesky. Today, I want to briefly run through how I managed that.

Similar to the solution in Robb’s Stopping Mastodon From Fetching Metadata for My Notes, I wanted to include links to the original microblog notes when syndicating to Mastodon and Bluesky. Unfortunately, if a link is present and has Open Graph metadata tags then a redundant link preview is generated, which takes up a bunch of vertical space in your feed and provides no value in this case.

Hearthside is written in Rails, so Robb’s solution didn’t directly translate, but the general solution here is pretty similar in that I check the request’s User-Agent header against a list of Fediverse and Bluesky substrings and return an empty response if those match.

scope constraints: ->(request) { /(Akkoma| B(lue)?sky Bridgy| Firefish| Frendica| Mastodon| Misskey| Pleorma| gotosocial )/ix =~ request.user_agent } do...

Tell GitHub to Render Markdown Pages with .gitattributes

2024-11-22T00:00:00Z

Articles on Hearthside are written in Markdown (GitHub-flavored), but the file extension is .md.yaml as they also make use of Jekyll-style front matter. My Frontmatter gem requires that files it handles end in .yaml or .yml, so this is necessary.

Because of the file extension, GitHub until this week did not render the Markdown correctly. Instead articles have been highlighted if they were written in YAML completely, which really messes up the Syntax highlighting even beyond not giving a rendered preview.

I’m not sure why I never thought to look into it in the last several years of writing this way, but it turns out that you can tell GitHub’s Linguist tool what type of language a file type should match, so to do that I added this to my project’s .gitattributes:

*.md.y*ml linguist-language=markdown

As a bonus, GitHub usually sets Markdown files as documentation and excluded from the language statistics of the repository. To fix that you can also add these few more lines to really...

Oxtail, and more Cooklang Exploration

2024-11-21T00:00:00Z

After yesterday’s post, it was time to finally try to handle a blog post and Cooklang recipe in one file. The solution to how to format things was simple: inline the recipe in a Markdown code fence and pre-process it. The file looks like:

 --- [yaml frontmatter] --- [markdown intro] ```cooklang [cooklang recipe] ``` [markdown outro]

The code to do it is ugly and relies on a Regular Expression¹, CookCLI to generate some JSON that I use to render a partial during the view render. I didn’t bother building a nice data object, so I’m using a mess of {}.dig and case / in / else pattern-matching statements to generate the markup. It does properly handle marking up the recipe with the h-recipe microformat, so that’s a win. See below for Rails partial².

As you’ll see, the CLI doesn’t handle combining ingredients of the same name to amounts, and it isn’t able to parse ingredient aliases or comments. I’ll probably open an issue on the project’s GitHub repo, but ultimately it looks like the ...

Oat Notes

2024-11-20T00:00:00Z

You’ll probably read this recipe and think wait, this is just overnight oats but you’d be wrong, because this is a recipe for overnight oats that someone who cares about you remembered to make for you last night. At least that’s how I interpret my 3-year-old’s mis-hearing or pronunciation of us telling him that we’d made “overnight oats”.

>>servings: 1
>>author: Hannah Hearth

The general idea here is to eyeball the flavorful ingredients but keep pretty close to the specified amounts on the “backbone” ones.

Combine @old fashioned oats{1/2%cup} @over-ripe banana|banana{1/2} @chia seeds{1%tbsp} a spoonful of @peanut or other nut butter\|peanut butter{1%tbsp}(or more if you feel like it), a healthy pour of @maple syrup{2 tsp} and @oat milk{1/2%cup}(a little splash extra won’t hurt, but you can add it in the morning too) in a seal-able container.

Stir until combined and refrigerate overnight.

Enjoy right out of the fridge in the morning, possibly with a little more @milk...

How I Model SwiftUI Views

2024-11-19T00:00:00Z

The approach I take to defining ViewModels for SwiftUI was heavily inspired by Paul Hudson’s post Introducing MVVM into your SwiftUI project. In it, he advocates for defining class ViewModel inside an extension to the relevant view. By naming each view’s MVVM class ViewModel, it can always be referenced directly by that name instead of remembering to use ContentViewViewModel, UserListViewModel, etc. I take it a step further and simply name the class Model:

import SwiftUICore extension ContentView { @MainActor @Observable class Model { // properties and functions } } 

And each view has an instance of its ViewModel, and hopefully nothing else.

struct ContentView: View { @State private var model: Model = .init() } 

In practice, useful property wrappers like @Binding or @Environment will get hoisted into the view. I’ve also had absolutely zero luck incorporating this fully with SwiftData. In theory you can build your own Query with Predicate<PersistentModel> and ...