I started hosting a set of web apps at fly.io about a year ago, and for the most part loved their developer experience. Publishing an application was a quick command-line operation, similar to heroku.

But after months of running several small-scale apps on fly, I've found that their platform just isn't as reliable as I need, so unfortunately I've had to migrate to something else.

The most frequent issues were just random downtime, usually caused by network flakiness somewhere in their infrastructure. I'd get alerts from a monitoring service, and at least one or two apps would be unavailable for a while. The down time was usually brief, maybe 10 - 30 minutes, but once or twice was at least an hour. I need more reliability than that.

So for now, I've migrated everything back to a Digital Ocean VM that I'm managing myself. I've had really good luck with D.O. over the years; I've run multiple apps there, too, and had rock-solid reliability.

The downside of running a VM is that I have to manage the VM myself, and deal with deploying apps there, or at least configuring github build actions to deploy there.

I'd like to get out of the business of managing VMs myself, so I'll be experimenting with some other platforms as well. First up is Cloudflare. Their Pages platform looks interesting, and remix supports it as a target platform out of the box. If that works, it should give me reliable deployments with all the ease of fly but with much more solid reliability.

I'll still keep an eye on fly; I really liked them in a lot of other ways, and hopefully they'll get their infrastructure to stabilize more over time.

I liked a lot about nextjs, but its fundamental page building & publishing model seemed awkward to me.

Specifically, the publishing workflow for non-developers just didn’t seem to be a good fit. That’s an important use case for me as I was hoping to use nextjs for some CMS-based sites for “normal” people (not developers).

I loved the great performance I got from a nextjs static site, but that depended on static builds. I knew it wouldn’t fly if I told normal users to wait for new builds after publishing. As leaky abstractions go, that’s a significant one.

I thought incremental static rendering (ISR) might be a good solution after that, but next's ISR caching model just wasn’t right for me, either. I want options like invalidating the whole cache at once when pages are published. Instead, ISR’s happy path is to use time-based invalidation. Not a good fit. I could write lower-level code to invalidate individual pages, but that’s also not quite what I need.

That left me with just a plain SSR solution and no built-in caching. That could have been ok, but it didn’t excite me that much -- and it meant accepting some of the awkwardness of next's page model without really getting more than its most basic benefits.

That awkwardness of not really fitting my needs was one of the weak spots I found in nextjs. It left me open to finding another solution that was a better fit.

I've switched the framework for this site to remix. I was using nextjs before, but I was frustrated by a couple of things and I think remix offers a better solution for my use case. I'll write more about those issues soon. So far I'm really liking remix, though.

I'm moving the backend of this site to the sanity.io headless CMS. The old backend used markdown files in a git repository, and I wanted something I could easily use on my phone. (This site's frontend is still using next.js, which has been great.)

More importantly, I wanted to explore using sanity as the backend for some other sites I've been building and hosting for other people. I've been looking at a few candidates for replacing Perch, and so far sanity seems to be a great alternative. I also (mostly) love the idea of using a SaaS so I don't have to host it myself.

So far I've been really impressed with sanity. It's definitely a developer-focused CMS, so it requires coding to get up & running, but it's been incredibly easy to get started with. And querying for data from my nextjs frontend has been refreshingly straightforward.

Finally switched this site to Tailwind CSS. I've been using tailwind at work for about 2 years now, and it has been great. Have been wanting to switch this site, too. Finally did it.

If you take average risks you will, by definition, get average results.

Instead of minimizing risk, I instead like Jeff Bezos’ pursuance of regret minimization. Of the paths that you can take, which path will most likely result in the least regret later in life?

-- Steph Smith

Interesting new game development library, kaboom.js. Aimed at making it easy for kids & other beginners to learn game development, but looks really nice for general use as well. Or at least for prototyping game ideas.

I can't wait to try it out!

Found via twoseparate posts on Hacker News.

"Small b blogging" from Tom Critchlow:

As Venkatesh says in the calculus of grit - release work often, reference your own thinking & rework the same ideas again and again. That’s the small b blogging model.

At work I keep seeing cases where there is overlap in common behavior but not completely. Special cases take a simple routine and wrench it through with conditions.

With React components, it’s often easy enough to split out the separate cases as their own components or, more recently, maybe push the differing behavior into individual hooks.

Some of the uglier cases are in Redux reducers, action creator functions, or async API-calling code. These functions start small and simple, but as the requirements grow and change over time these streamlined functions quickly grow branches, and those conditions then grow their own complexities in due time. Eventually it becomes a dense forest of possible code paths where bugs grow freely.

I’ve been trying to tame some of those areas recently by simply trying to separate what is common from what is different. A wonderful benefit of doing that is being able to clearly see what is different just from how the code is structured.

I’ve come to look at significant branching as a code smell, and try to refactor so that the branching happens once, up front, where you pick from a handful of top-level functions or objects that themselves are focused & single-purpose. I think that insight came from Sandi Metz & her 99 Bottles book; it’s an enormously powerful tool, and so far has been a great help.

Interestingly, Javascript’s prototypal inheritance is quite well suited for this kind of thing.

From DHH, "No more platforms please":

Everything just scrolls by, because everything is just mixed together. Everything from everyone all the time is too much. It's unnatural and it's unhealthy. We weren't built to listen to hundreds if not thousands of people every day. Tools that let individuals publish, but do not seek to amplify them or force them viral, give us that natural, human scale. Newsletters. Podcasts. Small-scale forums. Yes, yes, yes.

More platforms? No, no, no.

git wip: a handy alias for git to see branches sorted by last commit date. Via Carolyn Van Slyck.

I read through the Indieweb criticism and Small Web pieces I linked yesterday. Both are interesting and make good points, as does the Indieweb movement itself. But all of them share what I think is a common flaw: they're too technology focused.

For an indieweb-like idea to succeed beyond a niche following, it needs to solve the problems of normal, non-technical people. What brought normal people to Facebook? Among the main reasons were discoverability,aggregation, and extreme ease of use. Discoverability means easily finding friends & being found by them. Aggregation is the news feed: combining all your friends' posts into a single time-ordered page so you can scroll down and catch up. And the essential tasks were so easy to do in Facebook that everyone's mom could do them all by herself: signing up, finding & following friends, reading posts, creating her own posts, commenting, pressing the Like button, etc.

If I had to pick just one feature to start an indieweb, it would be discoverability. That's the killer feature; that's the core thing that made Facebook useful to normal people: suddenly, you could easily find your long lost friends from high school, and reconnect.

Without a user-focused discovery mechanism, these well-intentioned indieweb efforts are going to struggle to move beyond their small niches.

To read & ponder: dgold's criticism of the Indieweb movement, "Praxis and Indieweb".

(Found via Gregory Hammond's "Removed Webmention / Indieweb from this site".)

I ran across the "Small Web" idea from Aral Balkan and Laura Kalbag, and their Small Technology Foundation. I think I've heard mention of the Small Web before but never really investigated.

To do: investigate.

I love this idea of "sincere blogging," from Roy Tang:

Please write more.

Not just on social media, FB, Twitter, whatever. Write on your own sites and blogs. On your tumblrs, wordpresses, whatever. Long-form, rambling, incessant. The world could use more sincere blogging.

Duplication is useful when it supplies independent, specific examples of a general concept that you don’t yet understand.

--Sandi Metz, 99 Bottles

I saw the movie Nomadland last night on Hulu. Meh. The fimmaking was visually beautiful and Frances McDormand was outstanding, but... it seemed like there was no story there. I felt like the movie never really engaged me or pulled me in. I didn't think McDormand's character was all that well developed, and the movie never made clear what was driving her. She starts nowhere, goes nowhere, and doesn't learn anything along the way. I have a feeling that is the point -- yes, exactly! she's going nowhere, and has nowhere to go... get it? -- but that's a hard trick to pull off in a film, and this one doesn't accomplish it.

The script felt as emotionally disconnected as its main character was. A lot of the critical attention seems to make a fuss about how the movie gives us a glimpse of this nomadic underclass, but I don't think it really did that well either; it shied away from that side of the story almost entirely, unlike the book.

Near the end it does seem to reach for a couple moment-of-truth scenes that have potential but end up as small beans. Those moments call more attention to the flatness of the script & plotline than they serve to move the needle toward actual drama.

I don't think I've ever been disappointed by a Frances McDormand film before. Maybe it's just me, but I thought Neverland was a big letdown.

You can’t create the right abstraction until you fully understand the code, but the existence of the wrong abstraction may prevent you from ever doing so. This suggests that you should not reach for abstractions, but instead, you should resist them until they absolutely insist upon being created.

--Sandi Metz, 99 Bottles

I see that Sandi Metz has a new edition of her 99 Bottles book out, with new JavaScript & PHP versions as well as the classic Ruby. I'll have to read it. I'm a big fan of Sandi's, and her work tends to be rich with insights and well-formulated principles about coding & program design. Even if it's an OO-focused book, and my preference is more FP focused these days, it's still a good bet that the book will be more than worth the time to work through it.

I put a simple webhook server in place to auto-rebuild the static version of site when I push changes to github. :-)

I've moved this site from the Perch CMS to Next.js. This is partly because of Perch's uncertain future and partly because I wanted something more modern to work with. I quickly tired of dealing with Perch's PHP stack (which I don't know well at all, since I don't use it professionally), so I've been looking for node.js alternatives on & off for years.

Next.js was intriguing first of all because it's React based, but also because it offers a really nice range of options from static to dynamic pages. It seemed worth trying out, and I really liked it after some early experiments.

Right now I've started with a fully static Next.js site. I'll see how this goes. I'm considering migrating to a headless CMS for content management if I get tired of the static generation loop again; directus.io is my leading candidate (except for a bug that broke its SQLite support for now).

So far, working with next.js has been great, especially as it lets me use React. It's far easier than the PHP templates I was using in Perch. And... it's all Javascript now! :)

Perch's future looks uncertain, unfortunately.

As things stand there is not active development happening with Perch....

The product doesn't make enough money to justify two people working on it.

They promise at least maintenance-mode updates, but given that situation I can't use it for any new projects. Very sad. It sounds like the their business model just wasn't working out for them.

From McLaren Stanley's epic Twitter thread about an engineering near-disaster at Uber:

So my advice. Everything in Computer Science is a trade off. There is no universally superior language. Whatever you do, understand what the tradeoff[s] are [and] why you are making them. Don’t let it descend into a political war between opinionated factions.

Build in failure points. Figure out how to identify the tradeoffs and give yourself a way out if you get to a certain point a realize that you made a mistake. Big efforts are hard, but the cost grows the longer you make the wrong trade off.

Don’t be a Curmudgeon who doesn't contribute to the solution. Don't be a Zealot who creates bigger problems for everyone else. The best engineers I’ve ever worked with are really good at not falling into either of these traps.

I just love the wide-ranging comments on Hacker News :

picture

I called this onion architecture, as it had lots of layers and made me cry when we had to cut through it.

-- Sam Newman, Building Microservices

Austin Kleon: Don’t discard. Keep all your pieces in play.

Just ran across the Instagram feed of Cristiana Couceiro, a Portuguese illustrator & photographer. Wow; I love her style. She seems drawn to the same broad kinds of subjects that I am: patterns, striking design, etc. (Her personal landing page: https://cristianacouceiro.com/.)

From Kim Landwehr's blog, a spot-on take on Facebook:

Facebook is like an invasive weed that puts its roots everywhere and the only way to get rid of it is to kill it

Oh yes.

(I just found Kim's blog via dailywebthing.)

Have seen several links recently to dailywebthing, a large & terrific directory of indie sites. That link has a daily set of 3 pointers to sites in the directory. This other link is to the linkport directory itself.

I finally added the ability to create picture posts. (I added that during the conversion back to Perch.) The intent is to enable me to post pictures quickly & easily, akin to instagram or twitter. It's just a first draft now. I'll refine it as I go.

I've given up on using Hugo for this site & finally moved back to Perch. The awkwardness of updating a static site just got to be too much, so I stopped posting. Now I can post quickly if I need to, and even update via mobile if I want to.

I'm using Perch Runway now instead of plain Perch. Runway's "collections" map perfectly to how I want to organize my content, and their developer pricing for a non-commercial site means there isn't a price penalty for using Runway. Thanks, Rachel & Drew!

The biggest downside I've found of using Hugo for this site is that it's awkward to create a new post. I have to be at my computer to create a new file (can't use mobile), and then I have to generate & upload to the server. The friction is minor, but it's still a small annoyance.

I'm considering using a headless CMS like strapi.io to remove this friction, but at the cost of more complexity. Mulling it over....

Great collection of personal portfolio sites by Kicks Condor, found via a HN thread for Ali Spittel's nice piece about building a portfolio. I love exploring these personal sites; they can be a fascinating window into someone's life.

Good Sandi Metz post: in software it's important to get the abstractions right, even if it comes at the cost of some duplication. Over time, the wrong or broken abstractions cause way bigger problems than duplication. Ideally you won't have either problem, but if you have to have one then choose the lesser evil of duplication if it enables cleaner abstractions.

"Every practice we use as part of our work puts forces on us, and generally those forces can push us toward or away from more successful ways of doing things." --Ron Jeffries

I tried forestry.io and investigated netlify. Interesting, but the experience is far from frictionless. They still force a good deal of developer-level complexity on you. Short story: neither seems to be the magic bullet I was hoping for.

Minor nit: I save frequently while editing, which creates a stream of work-in-progress commits when using those tools. Annoying.

I'm intrigued by services like forestry.io and netlify that put a browser-based editor in front of a static site generator like hugo. Seems like that's what is needed to make static sites a compelling alternative to the traditional CMS.

I keep thinking of John Gordon's "How to build a safe and sane social network" this weekend. "Essentially it’s the public radio model." Intriguing.

Unlike the raw indieweb -- interesting ideas, but a science project -- Gordon's is a model that could actually be workable. It's a federation of nodes, where each node is used by multiple people. The tech people (let's call them "tinkerers") can run the nodes, while the non-tinkerers can participate either for free or for for a small donation.

The critical part is that it allows for easy use by non-tinkerers, aka "normal people."

Indieweb's weakest spots are exactly where the big silos add most value: effortless social connection, simple UX, and hiding the complex infrastructure.

One strong aspect of our React/Redux-based architecture has been the separation of concerns. When some code turns ugly, the damage is often contained in one small area.

Trying out the Hugo static site generator. So far I'm loving it. Wicked fast, easier to work with than everything else I've used.

I've found Amazon Echo "skills" SDK far too complex for simple IoT / smart home devices, and the resulting UX is awkward and poor. Built-in echo support for wemo switches is better -- and can be emulated for arduino devices. +1

The Amazon Echo = game changer for my Arduino projects: a voice interface for wifi-enabled ESP8266 devices. Fits the command-based devices best.