I think it's a good idea to get the gallery pages working
without that supporting metadata concept initially. Then
think about adding such data pages to /content or /data
and see what we can get to work. This still doesn't solve
my ordering problem though... 🤔
If found, said file's data would be associated with the
image and displayed along with it. If not found... well,
we display the image anyway. In this case, the
/content/uploads directory would not be the canonical
source of the page. The image itself would be.
Optional because I want TNT to work out of the box
with or without additional effort. So think like an
"/uploads" page that lists uploaded media and shows
them all, but that also optionally looks for a
metadata file in content/uploads for data to be
associated with the image.
...and accessibility is important to me. It makes me think
I really should (optionally) associate each of my images with
a post in my content directory that contains metadata related
to the image.
For a static site like mine, there isn't a super easy way to
associate each of my images with metadata (like upload date).
I can't associate each photo with a title or give it a default
description for sight-impaired visitors...
A possibly naive approach to ordering images might be
to add a number to the filenames (e.g. "1.oscar_2023.jpg").
Nuxt Content supports this approach for Markdown files, but
for images I'll have to program a solution manually.
I should add a media gallery. Somewhere you'd be able to
browse through the uploaded images unattached to posts
but somehow still "in order"... which means I need some
way to order them.
Here's those cat pictures again. They should look square now.They should look square on the old post too, since
I've fixed the issue, but they will also look square
here. Yay!
We also need to solve it for responsive sizes though...
Essentially we're going to have to not depend on the successful
operation of the Image module (already failing at this task) and
use an outer-container kind of solution.
Adding Tailwind's object-cover class has applied the necessary CSS,
but this alone hasn't corrected the sizing problem. Best guess is this
is because the sizes aren't explicitly pixel values (they're 600
rather than 600px).
The issue is one of resizing to fit our chosen square dimensions.
It looks like Vercel's image optimisation only supports adjusting
the size and quality, but won't do any cropping or extended filtering.
Which means... I'll have to fix that manually.
Vercel... isn't resizing the images as I would like. I could explicitly
tell Vercel to use the default IPX provider, which should fix the behaviour
but... the preference here has got to be to somehow fix the Vercel provider.
There's definitely room for improvement (I could, for example create
a custom /uploads route for viewing the photos in isolation and a sort
of gallery view), but I am happy with where we're at. We're showing
photo attachments. That was the goal.
That post successfully demonstrates that single attachments work,
but what about multiple? Here are three more photos; one more of
that goofy cat, another of my pretty cat and one of me with pink
shades on.
This post exists solely to test image attachments. Here's a picture
of my goofy cat just chilling in the grass:
I've added a redirect rule since I've already mentioned the full
address in a previous post. So now, /shreds will redirect to
https://thombruce.com/posts... which is exactly where I started.
Oh well! 🤷♂️
All that back-and-forth deliberation and do you know what? I'm just
going to revert the section to /posts. I think it best communicates
the intent, and having seen the word choices alongside 'Blog' on the
homepage, I think it actually is clearest.
The short-short-list is /shreds, /snippets, /messages. Were I to drop one, it would
probably be /snippets (seeming to indicate code to me), so... /shreds or /messages?
I think I'm gonna go with /shreds. It's less clear, yeah, but it's more fun and more
personal. It has character.
Nice! 😎
I think my current shortlist is this: /posts, /shorts, /snippets, /shreds,
/messages. /posts and /shorts feel unclear; /snippets may also be unclear,
I might be reserving it for code; I like /shreds a lot, it's fun; /messages
does feel the clearest and fittest for purpose.
We could also call the section /updates, /notices, /alerts,
/messages or... even just /social. It is, after all, modelled
after social media platforms and their limitations.
That leaves /shorts which... just doesn't feel descriptive enough. Yes,
it does the job. Yes, these are shorts (short posts), but the name might
also suggest that it's a section of short videos.
/burps feels like an appropriate name but too silly and quite unclear.
/snippets sounds exactly like what these are, I just wonder if I'm
reserving the name for code snippets. And /shreds sounds rad - reminds
me of skating - but it doesn't clearly indicate the section's contents.
To that end, I'm considering renaming this section. Not /posts but instead...
/burps? /snippets? /shreds? /shorts?
I want to add a section to my site for longer form articles. A traditional "blog",
if you will (why wouldn't you?). The issue is one of semantics. If I have a /blog
section and leave this section named /posts, I feel like there's some confusion
about what this section is.
"If it ain't broke, don't fix it", right? I'm just annoyed that I don't
know... why this works. Why it DIDN'T work without that setting. It's just
a little custom module with a custom transformer... but whatever. It works
now, let's not complain.
Nothing else worked. And I really thought if I set that option that
OG Images would stop working but... they haven't! So we're building
for static (like I used to) and benefiting from the features I thought
that excluded us from.
Okay, after A LOT of banging my head against the specific problem of Vercel
seemingly not including my custom Nuxt module and not generating my screenplay
pages, it looks like I've got it working by setting nitro.target = static.
I could convert these posts to Markdown docs... but I don't care as much if these are
omitted from the sitemap. I care if my Fountain documents (screenplays, maybe prose) are...
and those aren't as easily converted. We'll see if I can modify this sitemap module. Low
priority.
I've imported the screenplays section from the old version of my site, so... those
are here now. It does expose an issue with the Sitemap module: neither these posts
nor my screenplays are listed - only markdown files. I'll have to look into whether
or not I can tweak that...
Sure, the OG images don't look great right now... not for these posts anyway.
And the numeric ordering is a bit wonky, and the numbered posts are having said
number appear as a title... Easily fixed. Let me just import my old page templates...
My site is now hosted on Vercel and it has working automatic OG Image support.
So each of these posts gets an OG image without me having to add one explicitly.
Huge for dynamic, frequently changing or frequently added content!
I'm now adding these posts to the new version of thombruce.com, forked from
that new template repo. A few things that used to be on the site will remain
missing for now - I'll re-add them with time - but the issues I was having are
now gone!
The issue with my GetTNT GitHub org was that I still wasn't allowed to fork multiple times
to my user namespace. So I moved the template repo back and I'm mirroring it at
https://gitlab.com/thombruce/tnt. From there, I can fork as many times as I like to my
GitLab namespace.
Actually, it's amazing how quickly I retired that URL. Correct link is now
https://github.com/thombruce/tnt, same as the old version. It's also on GitLab
(same path).
Said repository now exists at
https://github.com/GetTNT/tnt. Again, not the place I think I'll
typically be linking people to. I think I'll create a fork at thombruce/tnt when I've renamed
and archived the old version, but for my own purposes I'll be forking from there.
I'm gonna create a new namespace for it called 'GetTNT'. The core repository will live at
'GetTNT/tnt' and... I might, but only might, fork it over to 'thombruce/tnt' to have that
be its sort of canonical URL (the GetTNT org would exist purely for my own forking purposes).
I guess wanting my repos under my 'thombruce' GitHub name is a vanity consideration; it
shouldn't be my priority here. Easiest solution is to host the TNT template repo under a
different organisation. I can always fork it unchanged under my own namespace too.
So either I'm going to have to house TNT itself or my forked projects under a different
namespace... or I'm going to have to do without forking for myself, instead cloning from
upstream and managing updates locally instead.
Annoyingly, GitHub still doesn't allow you to fork a repository under the same owner
(even though they've supported renaming at the time of forking since 2022).
This complicates my repository-based template plan. Forking would be the ideal
mechanism for keeping a repo updated.
Approach is simple: Redevelop TNT from scratch as a repository-based template
with intent to fork and fast-forward changes. Have my Nuxt-based sites be forks
of that repository. It's going to be tedious adopting this approach, but it's
going to be easier to manage long-term.
Basically... Why use Nuxt to solve something that Git already does?
I mean I know Nuxt Layers does more than what I'm describing here,
but this is one major use-case I've been using Nuxt Layers for that... I just
don't need to. TNT should be a repository template, not a module.
That approach would... yeah... It would genuinely be smarter. Could I still work with Nuxt Layers?
Maybe, but they would be less critical to the operations of child projects. Issues would be easier to
identify and resolve and... there are way fewer drawbacks than positives.
For managing many projects... that means more work getting them to match the same template.
But it also means greater clarity when trying to identify issues. I suppose what I need isn't
a module, it's a template repository I can fork and merge downstream when changes are made.
The problem with TNT is... I've obfuscated the issues that get in the way of development.
It's still a good idea, it just may be the wrong approach... or is trying to do too much. I need
to simplify, consolidate - bring dependencies into this project, where I can monitor them.
So, this site has one major dependency called @thombruce/tnt-content, a child module of
@thombruce/tnt which I've been working on for a while. It's a hodgepodge of Nuxt, Vue and
JS libraries that I think are handy to have grouped together as a framework of commonly
used modules.
A total reboot doesn't mean these posts disappear. It doesn't even mean we experience any downtime.
I won't deploy the new site until it at least matches what's already here, but it seems like the
clearest way out of the bind. Let me describe that a little...
Having some trouble deploying this very website as a dynamic Nuxt project (right now it's static).
There are some nice features to be gained if I can figure this out but... I think I've gone a long
way in the wrong direction, and I'm thinking a total reboot might be called for.
Happy New Year! 🎉 My main resolution: To write a little every day (these posts don't count).
I want to be writing... fiction, maybe some non-fiction, anything essentially that progresses
towards being in a book. Some of it will be coming to the website when it's ready.
It has to be said that this is a vanity project. It's not that important. There's some
work I need to do to add more basic features to my website too, so we'll see how quickly
I get to this. I'm happy for now to have a microblogging platform of my own that I
actually like using!
Now that we're on Vercel and I'm happy with the repo rename (
https://github.com/thombruce/thombruce.com),
we now have access to Vercel's serverless functions. These are going to be essential for my integrations
with Mastodon and, eventually, Bluesky.
I've checked and we're definitely now resolving the domain to the new server.
I've unpublished the site on GitHub Pages. I just now need to... 1. Probably just
comment out the deploy script for now (done!) and 2. Change the repo name and relink
Vercel. I'll do that now.
That's done, changes have been made in my Cloudflare DNS and the changes are propagating.
Vercel is generating SSL certificates. I'm gonna give it a little time and revisit later.
Looks like it's already working, but let's be cautious before I take the next steps.
Fuck it, yeah. Let's make the new canonical URL 'www'.
Since Vercel will redirect all traffic seeking 'thombruce.com' there
anyway, I can't immediately foresee any downsides to making the
apex a redirect. Vercel also promises a faster website experience this
way too.
Unexpected choice. I've been using an apex domain for ages (thombruce.com) with the
www variant redirecting to it... but I could change this. Have the apex redirect to
the www subdomain instead. It's a question of how much of a concern cookie management
is to me here.
Step one is done. My site is now on Vercel at
https://thombruce.vercel.app/.
Changing the target of my custom domain (thombruce.com) to this shouldn't
result in any downtime... and then I just need to rename the repo and stop
the GitHub builds. Easy.
So I want to change the name of my repo AND move the build to Vercel, ideally with no downtime.
First step: Let's build at Vercel from the repo as is. Get both versions of the build
active, then we can change where the domain is pointing. After that: change repo name and relink.
Alright, Vercel migration time. This site is currently stored in a repo at thombruce/thombruce.github.io.
This creates a GitHub Page at the given 'github.io' address. But if we're moving to Vercel, that
naming is redundant and misleading. We want to change it to 'thombruce.com'.
What I'm saying is, despite those earlier posts where we played with Markdown a little,
I'm gonna be keeping my micropost text content as plain as I possibly can. I'll probably
even think about implementing facets. Bluesky's justification for the approach is really
solid!
So text decoration is a little harder to implement for Bluesky or the AT Protocol,
but actually it's an elegant and incremental solution... and extensible too. If I wanted
to support spoiler tags ahead of Bluesky doing so, I could create my own facet "feature"
to handle that.
To avoid syntax barf, the text in a Bluesky post is always... just text. Decorations
are handled in a separate array of "facets" which third-party clients can choose
to implement or not... and it doesn't effect the displayed text. That
fallback is always there, is always clean.
Bluesky's "facets" avoid syntax barfing and simplify character counting. Let's make-believe
we have our own syntax; this is what syntax barf looks like: %%Ugly Markup%%. Because
third-party clients don't know what my unique syntax is supposed to mean, they can't
parse it.
The justification for using "facets" in Bluesky over a markup syntax is actually really solid;
I love it! Paul Frazee details it here:
https://www.pfrazee.com/blog/why-facets Essentially it
boils down to keeping parsing simple for third party clients.
So... despite my toying with markup in a previous post, adding emphasis, and
inline code that I'm sure Mastodon will display properly... I should impose
a rule: No extraneous markup. Plaintext, hashtags, @ mentions and links. That's
the set of features we get here. For now.
It's just this easy: MDC(:value="post.body" unwrap="p") I hesitate to use block-level
Markdown, though I expect Mastodon handles it fine. Bluesky is the issue; the code
for rich text facets is pretty limited in scope: links, tags and mentions are all that
seem to be supported.
That said though... Parsing these posts as Markdown is the easiest/quickest option.
And I'm not compelled to use the full set of features; I can use whatever
subset I like. I will need to rethink the handling anyway when it comes to serialising
the posts for Mastodon.
What that means for me, at least, is that... YES! I can use Markdown to
compose my microposts. This is true. But should I? Sure, I'm being a bit cheeky
and using all the inline markup in this post, but should I generally do this?
I think not.
That answers that; links don't work. I'll add it to the list.
One last thing before I commit! I don't know if links yet just work implicitly
or if I need to do something to handle them better. I've also just added a todo
list with a couple of items, so... appropriate time to test this:
https://thombruce.com/todoFirst priority though: Migrate my site to a platform with serverless functions.
Once I've done this, I can begin the work of integrating it with Mastodon. Once
I've done that... I will no longer be a social media outcast. I'll have a solution
that I think actually works for me!
Eventually I will create an interface for writing these microposts that
makes a commit and a push as soon as I hit "send". This will make them
go live on social sites a bit faster but I don't need these posts to be
super low-latency at this time. Maybe we migrate to a db later.
I don't mind at all if there's latency when I'm creating these posts. Right now I'm
typing this in VS Code, posts 6 through 13 are not yet committed to my repo, once I
commit and push, the site will be queued to build and the posts won't be live for 5-10
minutes.
I think the right call is to store the likes and follows we need to store in a
database and access that information dynamically. This significantly reduces the
latency when connecting my site with the fast-moving domain of social media.
Technically, I think my storage mechanism could remain static. There'd be some latency
as the site would need to rebuild before the data became readable... but there's no
technical reason why this shouldn't work. Is it the right call though? I don't think so.
Not sure what the full set of functions I need to support is, but I think ActivityPub
(which Mastodon uses) has the concept of an "Inbox". This inbox receives the activity
requests for things like... likes, replies, follows... and your server is expected to
handle these.
Notable examples of hosts that support serverless functions: Vercel, Netlify,
Cloudflare Pages (which I only discovered exists earlier today). I've already
worked with Vercel's serverless functions before, so I think I'll migrate my
site there.
Some static site hosts do support something called "Serverless Functions". These are...
Let's think of them as micro-servers that engage with requests similarly to traditional
servers; they're just used less frequently and for specific needs.
My site is a static website. I like it that way. The code and the content can live together
in the same repo; it's super portable and super efficient because it doesn't require a server.
Downside? No server. And right now I'm hosting it on GitHub Pages, so no real backend at all.
I need to consider the server-side aspect of this, and I should do it early; I should do it now.
I believe that to integrate with Mastodon and Bluesky, I need an address on my site that can receive
POST requests and respond accordingly (e.g. adding a follower, tallying a like).
Alright, I'm pretty happy with how this is looking so far. Eventually I'll have support
for replies/follows from Mastodon, hopefully also Bluesky. Before that, I'll add support
for image attachments, hashtags and links. Emojis? Already supported. 🙂
How quickly I abandon the 280 limit for the slightly better 300 supported by
Bluesky remains to be seen. Probably pretty quickly, since Twitter/X isn't a
decentralised app like those others and is going to be impossible to integrate
in the way I'd like.
For now, I'm limiting myself to 280 characters. This is the Twitter limit.
Bluesky's is 300 and Mastodon's is 500 (I think Threads is the same). My plan
is to integrate with these eventually; have this be the canonical source of
my microposts and allow followers from those sites.
This is just a basic setup for now. No support for replies or threading,
so each post is going to be its own, separate entity. No support yet for
attachments either, though that's an early priority. And no real restrictions
on characters... except those I impose myself.
Hello, World! Welcome to my microblog. That's what these things are called.
My replacement for Twitter, now that that's X and also kind of a hellhole.
What this actually is is a DIY approach. This is presently just a simple YAML
document in my website's repo. More to follow...