Ending the Season Images

In October I wrote a post about a little experiment I implemented. An experiement I wanted to build since I was a teen. Now I’m removing this experiment again.

To recap in short, back in the days when I started to create websites, I was fascinated by the idea that the design of a website (or at least a header image) depicts its own little world, with its own simulated weather and urban scenes and people living there. So I did it, with AI, which renewed the header images every 6 hours.

The magic wore off kinda quickly. It was neat to see how it added little scenes around halloween, christmas and new years; but it was also predictable that it will create those scenes. Those special scenes weren’t actually special anymore. And over time, it felt like uninteresting noise. If an artist had created them, it would’ve been much more interesting. Even though it wasn’t 100% AI slop because it had an interesting twist to it, it was still: just AI. People don’t just care about the art, they care about the artist.

I never wanted to keep those images here forever, and I’m happy this idea is now out of my head.

Here are a few oopsies that happened during the experiment:

• To simulate the weather, the AI is prompted with the weather it generated for the previous days, to create a new weather for “today”. It then uses this weather to write a new prompt for the actual image. But it started to write small scenes into the weather report itself, so it continued to reuse this same scene, and for a while all images were in a town with cobblestone streets and a church and a riverside.
• The images need a vignette, which was added to the image in a second step: it first creates the image without the vignette, and then uses this image to generate another image with the vignette. I thought that OpenAI will automatically detect the image aspect ratio to generate a new image with the same ratio. But that was wrong, it started to create square images. So for a while, the vignetted images were weirdly cut off and too small.
• During the React2Shell situation, the image generation halted because I didn’t redeploy the cron. While I updated the Next.js version in my monorepo, there were no changes to the cron (because it doesn’t use Next.js) and the deployment still had the vulnerable version of Next.js installed which we didn’t allow to run on Railway anymore.
• The AI was prompted to create scenes in a german city. But it did not create fireworks at midnight 2025 → 2026, and no streets littered with fireworks, which is just unrealistic af.

Intentionally left ugly

My favorite process in software engineering, whether I’m building something new or working on an existing feature, is to first focus purely on the functionality and completely ignore the design. Once everything works, I shift my full attention to making it look and feel great.

I learned this process over a decade ago, and I’ve been recommending it ever since to anyone who’s struggling while building something: struggling with refactors, with design collaboration, with pressure from planning and management, or simply with finding creative direction for the UI.

Question: “Why no public buckets on Railway?”

This question came up a few times, and it’s not an easy yes or no. They will come at some point, with more time. In the end, this was kinda my onboarding project and I have to scope stuff.

Public Buckets are good for static sites, but it’s already easy to host static sites on Railway. Buckets are cheaper, but the added benefit for the platform isn’t as huge as private buckets, so they weren’t high on the list of priorities.

Bucket UX is not super easy to get right, and many providers solve this with a list of configurations and assuming that users will know what they all mean and when to use them. Public buckets have lots of footguns. It’s not rare to hear about security incidents involving wrong configuration of public buckets. For most things that aren’t just static assets, you want a backend for authorization.

For caching and saving egress on static assets, CDNs work great. I’m using Cloudflare’s CDN for my stuff, and we’re also cooking on making it easier to add a CDN.

Is the solution just a “public” checkbox? Maybe it will be, but it’s not super clear to me if it really is the best way. If I would’ve went down that path and added it, it would’ve likely resulted in more than just a checkbox. It risks turning into a configuration hell where you don’t really know what those settings will actually do, and combined with the security issues, the end result risks causing more issues. Maybe even so many more issues that I’d rather want to remove it again to solve it better in the future, but you can’t simply take features away.

Ideally we have something that doesn’t require you to know what a bucket actually is, what the difference between a bucket and a CDN is, and what “public” or “private” actually means. Something that works perfectly for what you’re trying to build.

More than 15 years ago, I had this idea to autogenerate the header image of my website based on the current time of day, season, location, and a simulated weather pattern that naturally progresses. It fascinated me to have a long-running, realistic-feeling, autonomous system that changes itself without my involvement—like its own little world. I liked the idea to open my own site and being surprised by what I see. “Oh, it’s snowing!”, then seeing the snow melt away some time later, or observe the bleakness of misty autumn days.

Back then, I tinkered with layering PNGs on top of each other to create “random” scenes, but it looked terrible. I can design websites, but I can’t draw nice pictures.

I never ended up doing it because 1) I didn’t miraculously become a good artist, and 2) who cares.

Well, I care. I’m older now, and the fascination is definitely weaker, but I still thought about it every year. When my most favorite time of year starts, I get this itch. And this year, I finally scratched it.

AI made this much easier to solve. Not just for creating the images, but also for simulating the weather progression based on the time of day, the season, and previous days. Everything is now truly unpredictable, there isn’t a single line of code where I can already guess what will happen next.

New scenes get generated four times a day, and I feed the AI with previous days to create a natural progression.

I’m storing all the prompts, images and weather simulations (in a Railway Bucket of course).

I don’t like many of my development-related blog posts for one reason: I often feel like I spend too much time explaining the problem instead of getting straight to the point.

Understanding the problem is just as important as understanding how to solve it. So I don’t want to skip explaining the problem properly. And I want to include readers who might not be familiar with the topic. But whenever I start writing, I imagine readers rolling their eyes in light of the “obviousness” of it all.

I often think back to “Words To Avoid in Educational Writing” by Chris Coyier. He warns against using certain common words that make readers feel dumb. Just because you find something obvious doesn’t mean they do.

I’m certainly guilty of using those words myself sometimes, but the message stuck with me. That’s why I always try to explain problems thoroughly: because the reader might not know this yet, and it could be valuable knowledge for them, and I want them to feel included.

Still, I can’t shake the insecurity. Whenever I explain a problem, I worry readers will think that I’m a bit of a dum-dum for explaining something “everyone” already knows. Even when editing my posts before publishing them, I spend most of my time refining the problem explanation, trying to make it not too long but still explain everything.

Do I explain problems too much? You can tell me, I can take it!

Vary for images on Cloudflare CDN for free

Vary for images is a Cloudflare CDN feature that caches multiple variants of the same URL, based on the browser’s specific capabilities. It’s a paid feature. I want it, but I didn’t want to pay for it. That’s no issue, because we can rebuild this functionality on Cloudflare completely for free, with just a bit more configuration.

A Better Button Component with Composition

Do I really need to write an introduction to button components? We all know them. Buttons are one of the most commonly used components in our user interfaces, and are also some of the messiest components, with crappy interfaces and complex implementations for something as simple as a freaking button, and they only get worse as your codebase ages.

In this post, I’ll briefly explain why button components are a classic problem in software engineering, how composition can solve this problem, and how I implement complex buttons with simple code these days.