💾 Archived View for jacksonchen666.com › posts › 2023-09-19 › 21-39-16 › index.gmi captured on 2024-05-12 at 15:12:15. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

➡️ Next capture (2024-06-16)

-=-=-=-=-=-=-

Even More Website Design Decisions

2023-09-19 21:39:16Z

Oh, is this another blog post about my website again? (yes)

The last time I wrote about website design decisions, it was mostly user facing design decisions. This time, mostly from a developer perspective, including generating the website.

The last time I wrote about website design decisions

Make it as easy as possible

Generating my website is a very simple process (provided you have setup the dependencies correctly):

1. Clone the git repository

2. Run hugo to generate (or `hugo serve` for preview)

That's it. It's pretty much a 2 step process, although the real amount of steps is more than that, and includes moving your arms or fingers to type on a computer keyboard.

Creating new posts

Creating new blog posts is also a pretty easy one, although involving slightly more steps:

1. Run `hugo new content/posts/$(date -Id)-insert-your-title-here.md`

2. Open that just generated file in a text editor

3. Write the post

4. (semi-optional) Add gemtext version of the post

5. Maybe touch the front end matter a bit if necessary

6. Add a date to front matter

7. Commit

8. Push

After all of that, changes will be deployed by builds.sr.ht to all versions of my website including clearnet, Tor, I2P and some other domains for backup in case the main server goes down.

99% self contained in the git repository

Almost everything needed to build the website is there, except for hugo.

All you need is an install of hugo and a copy of my website. So if the only things you had is a working hugo install and a copy of my website, and you were left without an internet connection, it will work. Everything will be pretty much there.

This of course does not account for external links.

Relative links to be domain agnostic

For links to my own website but for other pages, all links are relative. That requires more effort than toggling an option, because the option of absolute or relative links is pretty much baked into your template.

Making links relative (not specifying the domain/host part) instead of absolute (specifying the domain/host part) makes deployments easier, because the contents of the website is pretty much domain agnostic (except for maybe rare exceptions), so it can be deployed pretty much everywhere without having to generate a website for every single case.

Other stuff, again

There's probably other stuff I also considered, but forgot. I can't think of anymore.

public inbox (comments and discussions)

public inbox archives

(mailing list etiquette for public inbox)