Blogrolls have been on my mind lately. It's a rather fancy word for a more common but far from mundane corner of your website, called a _links_ section. Ever since [my first website in 1998](/museum/1998/)---you can marvel at my old junk at the [Brain Baking Museum](/museum)---I've had a links section. But for some reason, on the latest revision of this site, it's been gone for years.
A links page is fun for a couple of reasons:
- It shows what the website owner is interested in;
- It's a chance to give a shout-out to fellow _websiters_ (if I'd type _blogger_ here, I'd be too limiting);
- It can be used to play the im-bored-lets-click-through-stuff game (isn't that the purpose of those webrings?).
Especially since I've been encountering my own site in the midst of the links of others (thank you!), I felt a bit bad for not returning the favor. Enter the [/links page](/links)!
After getting nostalgic (again...), I rummaged through my digital archive to dig up [my 2007 browser bookmarks](/museum/fav.html). It's a lot of fun to scroll through and instantly gives an impression of what I was up to back then (Infinity engine game modding, Nintendo DS programming, Wizardry 8 guide writing, retro gaming, BSD and Linux kernel programming, Magic the Gathering, hip-hop).
So much yet so little has changed! It's a bit embarrassing. Or should I be proud? I'm not sure. I feel a bit conflicted when looking back at it. Like Brit Butler wrote in "[Deliberate Action](https://blog.kingcons.io/posts/Deliberate-Action.html)":
> A tremendous amount has happened, but I feel like I've lost the boy I remember from college a little. He was excited about things: video games, music, common lisp, poetry.
Anyway. As Ruben would write: _I digress_.
## Hugo and XML parsing
Since nowadays I manage my digital intake via my RSS reader, which already contains an XML-based list of links in an `.opml` file, I took a stab at automating this process.
Recently, Hugo implemented [XML Data support](https://github.com/gohugoio/hugo/commit/0eaaa8fee37068bfc8ecfb760f770ecc9a7af22a) (part of the `0.92.0` release). This means chucking an XML file in `/data` automatically exposes it in the template engine, making iterating over entries using `{{ range $.Site.Data.blogroll.body.outline }}` trivial. Or so I thought.
The supplied example in the commit message of the patch is very brief and only covers retrieving contents of XML tags: `<title>sup</title>` can be accessed via the not-so-special `{{ .title }}` shortcode, as it becomes a Go property. But OPML outline XML is something like this:
All attributes, no content: the `outline` tag is auto-closed (`/>`). I had no clue how to fetch that data, as dumping the entire variable printed a map of keys prepended with a dash. Why? It seems that someone else submitted an issue to the hugoDocs repository, so I took the effort to summarize changes into a pull request. Accessing properties, apparently, is done via `{{ index $body.outline "-title" }}`.
I've never used Hugo's [index function](https://gohugo.io/functions/index-function/) before. Having to prepend attribute names with `-` feels awkward. I presume the changes are still young and a bit untested. Hopefully it'll evolve and stabilize over time. The problem right now is a total lack of documentation. Hopefully this blog post helps alleviate the problem a bit.
## NetNewsWire OPML exports
Where does the OPML file come from? NetNewsWire keeps track of local subscriptions ("On My Mac") in a file somewhere (`/Users/me/Library/Containers/com.ranchero.NetNewsWire-Evergreen/Data/Library/Application\ Support/NetNewsWire/Accounts/OnMyMac/Subscriptions.opml`). Copying over suffices, but of course does not auto-update when I add more feeds in the reader. Other options I've considered:
- Softlinks. Nothing but trouble while committing into git, tried a lot of different approaches;
- Hardlinks. Borked in MacOS. As soon as NetNewsWire makes a change, the hardlink is severed;
- Third party hardlink cmd-based solutions. Didn't work;
- Write a script that parses it into JSON and add to the CI. Too complicated;
- Add a stupid copy command into the user's crontab.
The last option is currently in use, although not ideal. Oh well.
Another problem is the lack of metadata, or description information. The [/links](/links) page contains little information of the link itself that way, especially if the blogger's `<title/>` tag is a bit... woozy. Like, "Articles", for instance. Any RSS feed, such as mine, contains a (proper) title and description:
```xml
<channel>
<title>Brain Baking</title>
<link>http://localhost:1313/</link>
<description>Freshly Baked Thoughts by Wouter Groeneveld </description>
...
</channel>
```
It somehow doesn't get saved into the OPML, although there's a description tag---it's [hardcoded to the empty string](https://github.com/Ranchero-Software/NetNewsWire/issues/3406). Why? I'd love to hack away in the Swift code but could use some help.
**Addendum**, 31th March 2022: Auto-generating decent links proved to be too difficult. The addition of a self-hosted RSS-Bridge, which allows me to generate RSS feeds based off Instagram/Twitter feeds, proved to be too much. The resulting list of links is a nondescript mess. In the end, I decided to curate the `/links` page manually.
Hey, this site also supports dark mode from now on! It seems to be a thing and after discovering MacOS Montery's "Auto" Appearance switch setting, I couldn't resist. Enjoy!
