Jim Nielsen’s Blog

I’ve got Netlify Analytics turned on for a few of my websites.

I use it send myself a little daily digest that alerts me when folks link to my writing, be it an individual sending me a few referrals, a newsletter sending me a few hundred, or Hacker News sending me thousands.

But sometimes I want to know more than, “What happened with traffic in the last 24 hours?”

Sometimes I want to know, “What happened with traffic in the last month?” I can log in to Netlify to answer that question.

Sometimes I want to know, “What happened with traffic in the last six months?” Netlify doesn’t have an answer for that because they only store the last thirty days of traffic data.

I’ve known about this limitation for years and always thought, “I really should just start saving that data for myself.”

But, you know, laziness. How bad do I really want it? The answer, it seems, was “I only want it if it’s _easy_”.

Enter Val Town.

Val Town makes this kind of task easy. Each “Val” is it’s own little bucket of scoped computing primitives for just such a task:

• Code (run a script that fetches data)
• Secrets (securely store my Netlify access token)
• Storage (my own little SQLite database for persisting data over time)
• Automation (run this task every 30 days)

All of this might seem like overkill for a single-script task like mine. But I like it. The scoped nature of each of these primitives makes composition easy without the kind of entanglement I’d have to fight to keep isolated if I were co-locating this task with other small tasks.

I don’t want to think about a shared schema for this task and whatever other tasks I might think of in six months. I don’t want to have to reason about evolving an architecture and maintaining a codebase of miscellaneous, unrelated tasks. Vals are perfect for this.

So the way I have this setup is: run the .ts file every 30 days which fetches the last 30 days worth of analytics data from Netlify and stores it in SQLite. (You can see my Val here.)

At that point, I have the data I need to curiously ask any question, e.g.

• What are the top referring sites to my blog?
• What post has received the most page views over time?
• Where does most of my traffic come from?

The answers to these questions get more and more interesting over time, as the long tail of web dynamics play out: search engine traffic, serendipitous rediscovery of old posts in light of new trends, etc.

“But how do you actually view the data you’re storing to get answers to these kinds of questions?”

Great question. Val Town has a UI where I can see the raw data I’m storing (which I chose to store exactly as I got it from Netlify, rather than doing some pre-processing first):

But that’s not very useful. I need to parse that data and turn it into some kind of useful analysis.

And you know what tool is super useful for understanding data? A spreadsheet.

If I were using Excel, I’d probably have to figure out a way to dump the SQL, convert the JSON to some kind of CSV, then import it. And every time I wanted to see the “latest” data, I’d have to run that workflow.

Enter Quadratic.

Val Town has an API where I can fetch the latest data via code, and Quadratic is a spreadsheet that runs code. So seeing “the latest data” from my pipeline in Val Town is as easy as pressing a “re-run code” button in Quadratic.

Quadratic serves as a kind of “front-end” to my data pipeline. Easy to pull the raw data, transform it however I need, and create a “dashboard” I can revisit whenever I want to see the latest insights or ask new questions.

And, since I’m storing data for a couple different sites in Netlify, I have a single cell in my spreadsheet where I can swap out the domain — say from blog.jim-nielsen.com to iosicongallery.com — and the entire dataset and dashboard redraw.

I know, I know. There are lots of products for stuff like this. And there’s probably a million other ways to do what I’m doing, all peculiar in their own way. But this one is mine.

And now I can sleep at night knowing that every 30 days my little Val Town robot is gonna go store the last 30 days of data that Netlify is throwing away.

One person’s garbage is another person’s treasure trove of data.

Reply via: Email · Mastodon · Bluesky

A URL is a technical thing: a hostname, a path, a port, an origin, some query parameters, etc.

But a link is a cultural thing: an invitation, a citation, a gift, a shortcut, a connection.

All from a simple idea: here’s a thing that points to another thing, off you go!

We’ve built an entire culture around links. Just look at the language we use for them:

• “Drop me a link.”
• “Send me the link.”
• “Got a link?”
• “Link in bio.”
• “Link in the description.”
• “Here’s the link.”
• “Don’t click that link.”
• “Sorry, wrong link.”

Or even just, “Link?”

Our language spans the spectrum of meaning, from one end to the other:

• We save links. We lose links.
• We share links. We hide links.
• We send links. We receive links.
• We collect links. We discard links.
• We open links. We close links.
• We add links. We remove links.
• We make links. We break links.
• We shorten links. We expand links.
• We follow links. We ignore links.
• We click links. We don’t click links.
• We link in. We link out.

We make links. Links make the web. The web makes Us.

Reply via: Email · Mastodon · Bluesky

Speaking of being on the internet and finding things that make you go, “Hey! It’s not just me!” I scrolled across this skeet from Tyler Gaw:

I just dug to the bottom of my Big Box of Cables to find two cables that I needed for something. They've been in the bottom for 10+ years. So, "when are you ever gonna use these?" was today. Don't ever let anyone take your Big Box of Cables away.

I laughed. I cried. I felt inspired.

So inspired, in fact, that I decided I was gonna do something about it.

Something that would make me forever remember the value of that advice.

• I screenshotted that skeet.
• I printed it (in black and white with the ole’ trusty Brother).
• I cut it out.
• I pulled out my big box of cables (the one my wife lovingly labeled “FAMILY TECHNO BOX”).
• I cut some clear packing tape.
• And I plastered that thing on the front on my box.

Now every time I pull that box out to add YAC (yet another cable), instead of asking myself, “Why do I keep this box?” I’ll see that skeet and I’ll be reminded why I do what I do. I’ll feel a spark of joy, motivation, and purpose rekindled. (Not to mention the fact that it will serve as a warning to anyone in the family who thinks “I should just throw this away…”)

One day my kids will find that box in the attic amongst my other belongings. I hope they will pay heed to the timeless advice lovingly taped on the outside.

Reply via: Email · Mastodon · Bluesky

Marcin Wichary has a lovely article titled “Photoshop’s challenges with focus, pt. 2”. If you’re into the minutiae of interface design, this is a good ‘un. It perfectly illustrates how impossible it is to try and compare two interfaces side by side as static images.

What matters in an interface is how it works, i.e. how you interface with it.

And when you bulldoze an interface to build a new one, comparing the old vs. new side-by-side to make sure you “captured everything” is a lie. It’s never obvious what has been lost because the interactive pieces are missing from the static images — and those are what matter most because it’s how the feature works!

I’ve found this to be true a lot as of late. Lots of tiny details that were meticulously crafted over years with specific rationales tied to real-world use cases, all completely bulldozed in a giant refactor. (All made possible by the great omniscient power of AI.)

Few notice what’s gone because few can see what’s being lost in the first place.

Reply via: Email · Mastodon · Bluesky

I was reading Jason Gorman’s article “The Wall Confronting Reliable Coding Agent Autonomy” and he says:

the journey from 90% to 99% reliability is just as hard as it was to get to 90%. And from 99% to 99.9% is just as hard again.

This stood out, as I’ve been experiencing more and more “downtime” in my day-to-day work. GitHub’s down. CI’s down. AI’s down. Slack’s down. Downtime’s going mainstream! More and more I find myself visiting service status pages, where I’m confronted with a wall of colors and numbers like this:

100%? 99.72%? 99.09%? 98.98%? Those don’t all seem so different or bad? I mean, those are all an A in grade school.

Then I have to remind myself of Jason’s point and re-interpret the numbers, which is more like reading earthquake measurements. The difference between a 6.2 and a 7.8 might not seem that big, but it represents a massive difference in magnitude. Uptime percentages have a similar problem: 99.9% and 99.99% look pretty much the same, but the latter is 10× less!

Infrastructure people understand this. They even have a shorthand for it: two nines, three nines, four nines. They intuitively grasp the difference because they swim in these numbers every day.

But the audience for status pages isn’t just infra people anymore. It’s increasingly everybody.

I understand the math is straightforward. Percent uptime is a good metric for those in the industry. But it’s a lousy interface for people who don’t care about the best way to measure infrastructure reliability in a standardized, reliable, compliant way.

And status pages are the public interface for understanding the reliability of a service. I just want to know, “Dude, how much have you been down lately? Seems like a lot…”

So how about, and I’ll just throw this out there, instead of:

GitHub Actions: 98.31% uptime.

We say something like:

GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).

One requires you to understand the nonlinear significance of numbers near 100%. The other requires knowing what an hour is.

Reply via: Email · Mastodon · Bluesky

Speaking of things we know individually, but let slide collectively, here’s Jeremy Keith talking about how we all used Flash:

Remember when almost every website had a Flash intro? Everyone knew they were annoying and uneccessary, but everyone else was doing it.

And here’s John Gruber writing about his experience with those marketing schemes that trade your personal information for a discount:

The marketing shitbirds who press for these schemes  […]  do so by pointing to data that shows that they do convert some number of users. “It works” they claim, pointing to data. What doesn’t show up in their data are interactions like mine. They don’t have analytics that measure that I now consider their website an antagonist to avoid at all costs.

There’s a funny thing about us humans: we place trust in systems that our own individual experience tells us are flawed. For example:

• KPIs: we know metrics get optimized at the expense of reality, but leadership treats dashboards as a reflection of truth.
• Performance reviews: we know they’re political and subjective, yet companies leverage them for promotions, compensation, even firings.
• Standardized testing: we know tests don’t measure real ability, but institutions rely on them for admissions, funding, and rankings.
• Terms of Service: nobody reads them, but the legal system acts like informed consent is given.
• Privacy notices / cookie banners: everybody clicks through them mindlessly while companies claim transparency and compliance.

This behavior is best summed up by Scott Berkun in Confessions of a Public Speaker:

I know I avoid most surveys I’m asked to fill out, as do many of you, which begs the question why we place so much faith in survey-based research.

What’s convenient at scale becomes a substitute for the reality we experience as individuals (because scale excludes the parts of reality it cannot conveniently capture).

Reply via: Email · Mastodon · Bluesky

Eric Bailey has a fun little post about how we need more than a few icons to express the nuance of our shared human experience.

For example, he suggests Netflix provide some feedback buttons to indicate the kinds of experiences we all share consuming and rating media:

• “Just because I expressed interest in this show does not mean I want to be inundated with recommendations for its genre”
• “Disregard that I pressed ‘thumbs up’ my cat walked over the keyboard”
• “I am making bad choices and hatewatching this”

What’s great about the examples in Eric’s post is how familiar they are. We can read them and laugh because we’ve had the same thought — “I’m pressing ‘thumbs up’ here, but what I really mean is…”

We know when we click that button that it’s a reductive expression of our experience that’ll be erroneously interpreted, but we do it anyway. As Bryan Cantrill shared from his experience:

There's no way to indicate, “I’m engaging with this, but I hate myself for doing it.” I need another mouse button that is like, “I’m clicking on this, but I’m rage clicking on it and for my own mental health could you not drag more of this in front of me please?”

We know these feedback mechanisms are often a misrepresentation of our actual experience.

Yet we turn around in our professional contexts and see numbers like “142,432 users gave this a ‘thumbs up’” and we forget everything we knew about our own individual experience with these systems. We make it mean what we want it to mean, what’s convenient for measurement and reporting e.g. “Wow, what a great insight about our offerings! Let’s restructure our entire catalog around this new, objective, (pseudo)scientific fact that so many people obviously like this thing!”

We reduce the experiences of others to mere data, but grant ourselves exemption from such oversimplifications.

Where’s the conversation around:

• Values, e.g. “Should we provide more of this? We can say no to the data…”
• Nuance, e.g. “What do people really mean when they click ‘thumbs up’ in this interface?”
• Vision, e.g. “If we provide more of this, where will that lead us?”

But that’s too introspective. Introspection is slow. Ain’t nobody got time for that.

Reply via: Email · Mastodon · Bluesky

Related posts linking here: (2026) Nobody Believes It, Everybody Does It

807 blog posts across 14 years.

That’s how much I’ve published on my blog at the time of this writing.

And here’s the question I’ve been turning over in my mind: “How do I convey that kind of volume across time in a more interesting way than a mere reverse-chronological list?”

I’m not hating on reverse-chronological lists. I love my list view. I use it all the time to find stuff I’ve written.

But it’s only one way of navigating and digesting all my posts.

“What would be another way?”

Surely there are many answers to that question. And I’ll probably be exploring them more and more over time.

But I had an idea for a new view that I built out and shipped: my calendar view.

It’s also just a reverse-chronological view, but it’s meant to convey a sense of posting patterns through time more than it is meant to be a good browsing experience of content.

The view is simple: a calendar view of days in each year, and if I posted on a day, it gets a circle (bonus: if a post hit hacker news, it gets an orange square instead).

You can click on the dots to see the names of the posts from that day (and follow the link to them, but really this view is basically to scratch an itch of mine.

Because you can just make stuff for yourself, and that’s what I’ve done here. And now I’m writing about it because that means I get another little circle for today! Good job, Jimbo.

Check it out

Reply via: Email · Mastodon · Bluesky

Dave Rupert wrote about shipping microlighter: a tool for handling syntax highlighting using the CSS Custom Highlights API. I saw his post the day he released it, and I had an implementation PR up for my blog by end of day.

Then, like I do with so many things, I let it sit there.

This is the period where my subconscious takes over. It does the work of, “How do I actually feel about that? Do I want to merge it? Do I have any regrets about what I did?” If I still want to merge it after a few days, that’s usually a good sign that I’ll be happy with the work. (Sometimes after a few days I say, “What the hell was I thinking?” and then it’s easy to simply close the PR with zero regrets.)

Well it’s a few days later and I still feel good about it, so time to ship!

My PR for this is pretty straightforward:

• Remove highlight.js dependency (and related plumbing)
• On paths that 1) match my post pages (i.e. /YYYY/:slug), and 2) have code on them, pull microlighter deps from a CDN and run it.
• Done.

Granted, there are trade-offs to this approach. I get it. Dave’s explainer for this tool on The ShopTalk Show vibed with me because I’ve been in his shoes many times: “Whoops, somehow syntax highlighting on my blog is broken again. Guess I need to fix it. Ugh. I’ve done prism, I’ve done highlight.js, I’ve done shiki. What should I do this time? Could I do this in a way that’s just less?” He clarifies:

I’m not coming at this like, “Everyone is doing it wrong!” I was just kind of like, “Could I do this in a way that suited me?”

Well, this approach suites me.

There’s a kind of conceptual elegance to it where syntax highlighting lives in the realm of a styling operation rather than a content transformation plus styling. In short: syntax highlighting, i.e. styling text, is a styling concern so solve it with CSS — no DOM manipulation required!

Plus, I mean, how cool is it that the code on the website is the same as the code in the DOM?!?

I guess this is how I know I still like working on the web, because seeing browsers do stuff like this that they couldn’t do before still feels really cool!

Reply via: Email · Mastodon · Bluesky

On my icon gallery sites, I have metadata I’ve manually added over the years to tag certain icons as being predominantly “blue” or “orange” or some other color.

Then I use this metadata to present icons of (roughly) the same color. It’s kinda neat to be able to browse a wall of icons that are all the same color.

The thing is: I know there are a lot of icons I’ve missed tagging over the years. But I have no idea how many, and figuring that out seems like a really arduous task. How do I go through 2,000+ icons and find all the ones that look predominantly “orange” but haven’t been tagged as such yet?

Seems like a good task to throw at an LLM. But I don’t want to just say, “Go tag everything that’s missing” and blindly trust the output. I need to be able to make a decisions as to whether I think a particular color is “orange” or not.

What I need is a tool for the job. I’m a very visual thinker, so to continue curating these color categorizations, I need some way for the computer to do its thing really, really fast, and then pull me into the loop to visually make decisions.

Here’s how I am thinking about about accomplishing this task:

• Create a page with a list of colors on the left (red, green, orange, blue, etc.)
• When a color is clicked, show two columns. 1) All icons I currently have tagged for that color, and 2) all icons that might be that color but aren’t tagged as such (you, computer, process all my icons and do the work to figure this out and make recommendations).
• Allow me to select one or more icon(s) in the “not yet tagged as this color” column. Once I have all the ones I perceive as missing, give me a button to say “Copy” which copies the IDs of those icons.
• I’ll paste the IDs back here in the chat and you go add the corresponding metadata.

That seems like it would be a good tool to put me in control of visual decision making around color categorization. So I tell the LLM to run with it.

We chat back and forth. I think, “You probably need to run all the icons through some model to make the correlation?” But it’s like, “Nah bro, just make a ‘hue histogram’.” It tells me how. For a color like “orange”, I can:

[process] each PNG, skip transparent pixels, skip low-saturation gray, convert the rest to HSV, and score how much of the remaining mass sits in the orange hue band (roughly 15–45°). Rank icons that don’t already have colorId: orange.

Ok, sure. That sounds reasonable.

[This] scores each icon PNG by share of opaque pixels per color bucket, then writes a standalone HTML page: tagged vs maybe-missing, per color.

Let’s just make it, and then I’ll decide whether it’s good enough.

After a few iterations, the computer going “brr…”, and me saying “explain that like I’m dumb”, I have a really effective little tool!

The little threshold slider is a nice touch. It lets me fiddle around with the fidelity of the matches. In some cases, sliding it down reveals more icons I would’ve otherwise missed. In other cases, I’m like “What are you thinking? I don’t see that as ‘yellow’ at all!”

Supper effective little tool. I go through each color, select the ones I think are missing, paste the IDs back into the LLM, and then have it update each icon's metadata.

Boom, done! That all would’ve taken so long before. I would’ve never done it.

Takeaways:

• The LLM is good at making throw-away code. This doesn’t need to be “production-grade” code I depend on. Just something that’s good enough for me to get a job done, then toss. The resulting metadata is the goal, not the tool I use to get to the goal.
• The LLM is good at making one-off HTML pages for a specific task. In my case, all these images were hosted on a CDN, easy enough to just point at and have a standalone .html file that I can locate on my hard drive and open directly as a file:// URL. No bundling. No transpilation. None of that. I don’t even need a web server! Keeping things very basic on this project is paying off: I had really elemental building blocks that didn’t require additional third-party tooling. Just HTML, CSS, a little in-page JS, and images on a server!
• It’s fun to say, “Don’t do the work for me. Instead, help me make a custom-fit tool that facilitates me doing the work in the most empowering, correct way possible.”

Reply via: Email · Mastodon · Bluesky