-- Leo's gemini proxy
-- Connecting to drawk.cab:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
It's a tradition whenever I'm between jobs for me to rip up the software running my website and start over.
This is for two main reasons
I like taking the site in wacky and experimental new directions, and
I have likely forgotten how to update it, owing as often as not to the wacky direction I chose last time.
For a long time my Web presence was at `colourcountry.net` but this time I am moving over to an exciting new domain.
2023's vibe is about simplifying the important things. And maybe even finishing some things. I'm not a tech startup, it's OK to say something is complete. (Some things won't get finished. 2023's sub-vibe is spotting those things sooner.)
Well, I have also converted the whole site into a Gemini "capsule".
The web version of the site is just a proxy to the Gemini server, which applies styles and other slinky effects for those browsers that do that kind of thing.
With the old site, I found I wasn't putting projects up there, even when I'd finished (or shelved) them. There was an extra step of writing some content and then building the site, which often didn't get done.
Using Gemtext, a format that's simpler even than Markdown, I hope there will be basically no reason not to write stuff.
My projects live in a Git repo that's backed up, and the Gemtext files are right in there. When I push some work to it, the content goes live automatically. No extra step.
I'm also going to try using the same pages for in-progress notes and todos. Work out in the open.
The second important new feature is that if I do want to do something fancy on the Web, I still have a way to incorporate that onto the site. Previous designs wanted me to work within the framework I'd built, using templates and things for new content types. I've come to believe this is a fundamental mistake which may be the subject of a whole piece someday. I've tried it on strangers in coffeeshops, so it's probably ready for the internet?
The Gemini capsule is served over its proper protocol, for those who are interested in that.
TODO: the content is the product, a rant.
I've reconciled myself to managing links manually. I've spent way too long exploring different ways of automating connections between pages, both on this site and professionally. It has been fun in its way, but at the scale I'm working at here it really doesn't save any time, and it leads to sites which feel more like a maze with very little treasure to be found. This time I'm going to aim to make every page worth the effort to get there.
You'll find the links on these pages are separated from the text, in asides or at the ends of sections. This is enforced by the Gemtext format, but I'm happy with it. I prefer reading content without being distracted by links in the middle, and I suspect this policy plays better with assistive technologies too.
Incidentally it was standard policy of BBC News Online in the 90s to separate links from articles, although probably the editorial tools at the time didn't support links, so they will have had to be added by someone else.
There's no metadata about times in this setup, so I can't organise posts by date or provide an RSS feed;—I think I'm OK with this, but having a bit of YAML at the end of the page is a possibility.
TODO: 12 (3221) Images are just served straight out of the source bucket, so I have to resize them manually. I'd prefer to be able to offer responsive images.
Vite image-tools will resize images at build time, but I don't want to redeploy the Svelte app when I update my content.
imgproxy will resize anything from anywhere, but it's another service to run.
Both of the above use libvips/sharp under the hood. Maybe I can use sharp directly?
TODO: 4 (2112) there's no caching anywhere. I'm relying on staying obscure for the moment.
The 2020 iteration was statically generated using templates, so the site was just a bunch of files. Very easy to serve. But this meant I had to move a lot of complexity into a build step. There could be bugs in the build process or in the files I was building the site from. Basically I had to debug my own content.
The design suffered from severe framework disease. Pages had lots of stuff that the framework made easy, and not much actually interesting stuff. The CSS was a bit horrible, there was no component encapsulation, and I'm pretty sure it had some severe accessibility issues.
The framework used a triple store of linked data, with an ontology to back it up. That was cool! But completely unnecessary for a website targeted at sentient beings. It's nice to have an ontology because it helps you think through the concepts you're using and apply them consistently, but use cases for the technical part are thin on the ground.
Most importantly though, it was just too hard to update, so I didn't. In three years I didn't even transfer everything worth saving from the previous site.
This iteration was also statically generated but was much simpler. It was very visual. I miss this one a bit.
My hosting provider gave me a SQL database so I thought I should use that. It was a mistake.
My first website didn't use tables because tables hadn't been invented yet. I remember using javascript to make the links glow when you hovered over them. The links were text in a GIF, because nobody thought about accessibility in the 90s. Ironically, the friend who showed me how to do that ended up making a career out of accessibility on the Web.
-- Response ended
-- Page fetched on Sun Apr 28 07:42:17 2024