kmelve

Editor of the Sanity engineering blog here. Sharing this post from our SRE team about how we reduced the hosting cost for Grafana Mimir while keeping redundancy for zonal failures.

Happy to answer questions, and I'll pull in the author for anything I can't.

Author here. I work at Sanity, so I'm obviously looking at this through our lens, but I tried to write it as general advice for anyone building developer tools and haven't thought that much about agents yet.

The thing that prompted this: I kept having conversations with teams where the first question was "how do we write better skills files?" and I kept finding that the issues were upstream in our error messages, CLI surface, and so on. I increasingly feel that Skill files is your "last resort."

The Workbench experiment in the post is admittedly simplified to unpack the mental model; you would probably set up evals etc to actually test it, which we have started doing at Sanity as well.

Happy to answer questions and channel more of our experience with agents (heh) and designing for them.

I work with Rosti at Sanity and helped get the word out on this. The core problem is that logos vary wildly in aspect ratio, pixel density, and visual weight, so lining them up at the same height or width never looks right.

Rosti's approach uses three things: proportional normalization based on aspect ratio, pixel density analysis (so a dense wordmark doesn't visually overpower a thin logomark), and a center-of-mass calculation for optical alignment. The perceptual sizing math builds on Dan Paquette's earlier work.

The core normalization logic is plain JS with no React dependency: https://github.com/sanity-labs/react-logo-soup/blob/main/src...

Someone already forked it into a framework-agnostic version: https://github.com/auroris/logo-soup

Rosti is around if there are questions about the density compensation or optical alignment math.

Author's colleague here. Rosti wrote this after we kept running into the same problem across customer sites.

The core formula is Dan Paquette's proportional normalization (aspect ratio raised to a scale factor), but the density compensation and visual center-of-mass calculation are the interesting additions.

The visual center algorithm weights each pixel by sqrt(colorDistance) * (alpha / 255) to find where the "ink" actually lives vs. the geometric center. It's a subtle effect but makes a noticeable difference with asymmetric logos.

Library is MIT licensed: https://github.com/sanity-labs/react-logo-soup

Live Storybook: https://react-logo-soup.sanity.dev

Working on getting Rosti signed up to HN for questions you might have!

It's strange to see folks here speculate about something you've written.

And if you only knew how much those headings and the structure of this post changed as I wrote it out and got internal feedback on it ^^_

Fair point, we appreciated that courtesy, and I should have reached out first. That was a miss on my part.

My thinking was that it became public pretty quickly once your post went viral (folks were already connecting the dots in the replies), and it felt awkward to respond to the substance without being direct about the context.

But you're right that a heads-up would have been the better move.

(I wrote the response) Just because it's marketing, doesn't mean it can also be educational?

I am a marketer and a developer. But I also know that you don't get far by trying to trick people into your product. As a marketer, I also get front row seat seeing how software plays out for a lot of businesses out there, and I have done so for a lot of years. I wanted to share those perspectives in response to Lee's write-up.

So yes, obviously both these pieces make a case for how the software we're employed by solves problems. And anyone who has been in developer marketing for a while knows that the best strategy is to educate and try to do so with credibility.

Yeah, we're looking into it!

Ooof. We should fix that!

Author here.

I don't know folks... Maybe I have been dabbling so much with AI the last couple of years that I have started taking on its style.

I had my digits on the keyboard for this piece though.

We're fixing every week! Have you tried it recently? Are there particular issues you're having?

Author here! Of course, I'm biased!

But in that bias is a ton of experience in the CMS field and a lot of observation of actual teams trying to solve for content operations challenges. I think that's valuable to share, even if we happen to also sell a solution to these things.

She's our recruiter at Sanity. Never coded. Wanted a pottery portfolio. 7 hours with Cursor later, she had a live site. Didn't know what "deploying" meant when she started, debugged until 4AM, maxed out Vercel's deployment limit. But she shipped!

I wrote a piece a few years ago that still reflects a lot of my thoughts on the tension between Markdown as a format and the actual experience of writing and publishing on the web: [“Thoughts on Markdown” – Smashing Magazine](https://www.smashingmagazine.com/2022/02/thoughts-on-markdow...).

What Apple seems to be doing with Notes—embracing Markdown syntax but not treating it as a source format—feels like a pragmatic move. It acknowledges Markdown’s familiarity without overcommitting to it as a canonical format. That distinction matters: many people like typing emphasis or `code`, but few need or want to version-control or export that exact syntax. It’s the gesture of Markdown that carries value for most users, not the fidelity to a plain-text artifact. "Even" Google Docs implemented it recently.

In my article, I argue that Markdown is increasingly a “source language” for interfaces, not documents, and this Apple Notes move seems to align with that trend. Curious how others feel about Markdown as an authoring experience vs. a content format.

I had the great pleasure of processing Sanity's donations to open source projects too. Hope other companies follow suit!

Pretty cool! The BlueSky API is on point. A colleague of mine put together this visualization based on the firehose: https://bigmood.blue/

Source: https://bsky.app/profile/even.westvang.com/post/3laob7tefxk2...

Hi! I work at Sanity and wanted to share a blog post I co-wrote about our new Live Content API. We’ve tackled the challenge of delivering real-time content updates directly from our CDN, allowing it to scale without the usual caching headaches. We’ve also created a simple Next.js abstraction to make it easy™ to implement. Would love to hear your thoughts!