So one thing that I realise after starting writing this blog is that I care more about it than some of my other projects. For some reason or another I want to make sure that this blog will continue with me for a long time. This is one of the reasons why I use GitHub as mirror blog and why I created a bunch of automation to make sure I never forget how to maintain this blog.
Still, there are a bunch of dependencies that I need to make sure they're working so I can publish blog posts:
- Markdown
- A text editor
- Hosting and blog platform
- Shell script and Makefile
- Go toolchain and modules
Let's start with the most important one: the texts themselves, they're all
written in Markdown. The nice thing about
Markdown is that it is just plain text files with some special notation that
allow you to format text, but the text itself is still legible even if you have
no support to render Markdowns. So it means as long as I can read a plain text
file, I can still read the posts, no issue there. Closely related issue here is
the text editor, but the nice thing about Markdown is that if tomorrow I decide
to change from neovim to, say, Zed, I can still write it
Markdown files without issue. I also use a standardised Markdown implementation
called CommonMark, that fixes a bunch of ambiguities
of the original Markdown spec.
The next point is the host (capivaras.dev) and the blog platform (Mataroa). One of the nice things about Mataroa is that it avoids platform lock-in by having multiple ways to export your posts. I could export everything to Hugo, for example, and serve the blog from GitHub Pages.
This is especially nice consider how small capivaras.dev is, so it is good to know that if I eventually have issues I could move to somewhere else. I also have an e-mail backup every month with all posts made (another Mataroa feature), and of course I have a Git repo that also acts as a mirror of this blog. So I would say the chance of losing access to the content is slim.
One other issue is the URL of the posts that are indexed in many different places, like Hacker News, Lobte.rs, etc. This is why I finally decide to bite the bullet and purchase a proper domain, and this website should now be available in kokada.dev. This means that in my eventual exit from capivaras.dev, I can just point my new blog location to my own domain if needed (it is not as easy since I also need to preserve the post URLs, but shouldn't be difficult to fix this if I ever need to do so).
Now for the tools that I use to publish from the original Markdown files to everything else. Let's start with shell script(s) and Makefile: I decided that they're less of an issue if they eventually stop working: they're only used to make my life easier, but I can still publish files manually if needed. Still, I tried to rewrite both the shell and Makefile to avoid GNUisms, so in the eventual case that I decide to e.g.: stop using a GNU/Linux system like NixOS and use a *BSD system instead, I am covered.
In other projects I would probably add a shell.nix file and add the GNU
versions of the tools that I am using, but I am trying to avoid Nix while
building this blog as much as I can, mainly because it is not available
everywhere (e.g.: *BSD systems).
Go is the more important part: the tooling used to publish this blog is written in Go. Go is a good language when you want to ensure that things will work for a long time because of its backwards compatibility guarantee. Also I don't expect Google dropping Go development soon, but even if this happen ("killed by Google" is a thing after all), it is very likely some other group or company would adopt its development quickly, considering how popular the language is.
However, the Go modules that I depend are another story:
- elliotchance/orderedmap: an ordered map implementation that I use until Go adds it in the standard library
- gorilla/feeds: a RSS generator library
- gosimple/slug: a slug generator library
- yuin/goldmark: a CommonMark parser and renderer
- teekennedy/goldmark-markdown: a renderer for Goldmark to render back to Markdown (since Goldmark itself doesn't have this capacity)
In common for all those modules are that they're clearly small projects maintained mostly by one developer. They're all very good, don't get me wrong, but they're still an reliability issue in the future. There is no guarantee those repositories will not be deleted tomorrow, for example.
Yes, Go Proxy exist, but from what I understood reading its page is that while it caches modules contents, this is not guarantee:
proxy.golang.org does not save all modules forever. There are a number of reasons for this, but one reason is if proxy.golang.org is not able to detect a suitable license. In this case, only a temporarily cached copy of the module will be made available, and may become unavailable if it is removed from the original source and becomes outdated. The checksums will still remain in the checksum database regardless of whether or not they have become unavailable in the mirror.
This is why this is the first project that made sense to me to use go mod vendor. Now I have a copy of the source
code of all modules inside the
vendor
directory in the repository, avoiding the risks I commented above. This allows
me to ensure that this blog will still be publishable in the future, as long as
I have a working Go toolchain (and Go toolchain makes this
easy).
There are a few other things that can bitrot this blog, for example links going nowhere. I always try to use permalinks when it makes sense, but the only actual way to ensure those links would work in the future would be to point them to archive.org (but even archive.org may not exist forever). Maybe something to fix in the future, hope not in the far future, before things start to break.