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 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).
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 :