死者复苏！星系里回荡着神秘的讯号，这是听上去熟悉却又遥远的 我过去的容器 对 维度大断层 的记录。

通向过去的链接

好吧，《天行者崛起》的玩笑就开到这里。如前所述，我的博客最初使用 WordPress，并于 2017-09-01 切换到 Hugo。确切地说，我实际上有两个 WordPress 博客：一个名为 Pandora（源自《无主之地 2》，但我敢肯定还有无数其他虚构的行星起了这个已经被用滥了的名字）并托管与 WordPress.com 上；另一个才是托管在 Bluehost 上的川陀大学图书室（源自艾萨克·阿西莫夫的“基地系列”）。前者使用英文，而后者用中文。由于我在删除之前保留了它们的存档，使用 此工具 稍下工夫就可以恢复那些旧日志。我避免遗漏任何一篇旧文，因为写博客的主要动机就只是为了能够随时看到过去的自我。重读那些日志是一种奇妙而又熟悉的经历：我可以清楚地看出我的某些部分发生了变化，而某些部分仍然是那个 shimmy1996。

处理日志的配图比较麻烦，而不幸的是，这些旧日志在插入图片上毫不吝惜：我选择了最简单的处理方式，只保留了原始图片，没有任何压缩或样式设置。我仍然需要一种更有效的方式来存储和提供这些图像。即使有 Git LFS 可用，我还是不愿意把超过 300 MB 的图片尽数添加到我的博客 Git 仓库中（因此它们目前处于无版本控制的状态）。多了这么多图片，部署 CDN 应该会大大改善访问速度。或许我也可以学学 Jupyter 笔记本的做法——将所有图像编码为 Base64——以将所有内容塞进同一个 HTML 文件里。

我博客的常客们（如果有的话）可能会注意到评论部分看起来有所不同：是的，我对理想中静态站点评论系统的搜索终于结束了（直到下次开始的时候）！我曾使用 WordPress、多说（已关停服务）、Disqus、Isso 作为评论系统，而现在取代它们的是我的 Hyperskip：从 Staticman 中汲取灵感，Hyperskip 将所有评论存储在 TOML 文件中，并使用电子邮件作为提交方法，以简化设置。我终于摆脱了数据库查询和外部脚本，并且将所有评论（包括 WordPress 时代的那些）转移到了和博客相同的 Git 仓库里进行版本控制。

另一位老朋友

新年刚开始一个星期，我已经切换了五次网站的配色，并还有一大堆其他方案堆在我的文件夹里（绝对不是因为 RGB 色值本身太过丑陋）。就像我对尝试 让所有字形用上正确的字体 感到精疲力尽时一样，我已决定从网站上删除所有的自定义颜色：不再显示语法高亮、花哨的按钮和暗色模式。

事实是，只要有可以调整的选项，我总会发现自己分心并花费太多时间担心那些最微不足道的对字体，颜色或间距的调整（只要看看我的日志中有多少是关于这个博客本身的就不难看出）。我发现唯一的解决方法是完全消除做出这些选择的机会，转而使用默认设置。这就是为什么我换掉了 Isso（我在试图使它和博客的外观保持一致上花了太多时间），并移除了日志标签和类别。

与俗语所说的完全相反，我并没有发现我对所舍弃的东西感到留恋。大部分时候，我的感受更近似与终于挣脱了那条绳子的大象的感觉，而不是失去了珍爱之物之后的后悔。我偶尔也会问自己，保留这些来自过去的牢骚和胡言乱语是否只是我尚未意识的另一条束缚我的绳子。对于这个问题，我的回答是：牛仔身边总少不了他的套索。

如果你熟悉中国神话或博客众，那么你说不定听说过被半开玩笑地称作“盘古之白”的排版习惯：在中文字符（但不包括标点符号）和拉丁字符或数字之间增加一定间隔。我所实行的这一规则的变体还包括在所有 HTML 元素（如链接和强调）的周围也加上间隔。

到目前为止，我一直在源文件（Markdown 或 org 格式）中手动添加空格：这无疑是实行这一规则最糟糕的方法。除了要费额外的工夫之外，这类排版规则还应该，在我看来，仅在输出/渲染时应用。更不用说手动调整我刚刚恢复的那一大堆旧日志不是什么吸引人的差事。因为不愿加载额外的 JavaScript，我转向了万能的 GNU sed。为了将盘古之白添加到 Hugo 生成的 HTML 和 XML 文件中（通常在 ./public 目录里），我使用了以下 shell 脚本：

#! /usr/bin/env sh
# For punctuation marks to be recongnized correctly.
export LC_CTYPE=en_US.UTF-8
find . -path "./public/*" \( -name "*.html" -or -name "*.xml" \) -print -exec sed \
     -e 's/\([a-zA-Z0-9]\|<\/[a-z]*>\)\([^[:punct:][:space:]a-zA-Z0-9\s]\)/\1 \2/g' \
     -e 's/\([^[:punct:][:space:][:alnum:]]\)\([a-zA-Z0-9]\|<[a-z]\)/\1 \2/g' \
     -i {} ";"

如果你想坚持履行这一 W3C 工作草案 给出的第一选择，且并不在意生成网页的大小的话，可以换用 CSS 来生成这一间隔：

find . -path "./public/*" \( -name "*.html" -or -name "*.xml" \) -print -exec sed \
     -e 's/\([a-zA-Z0-9]\|<\/[a-z]*>\)\([^[:punct:][:space:]a-zA-Z0-9\s]\)/\1<span style="margin:0.25ch;"><\/span>\2/g' \
     -e 's/\([^[:punct:][:space:]a-zA-Z0-9]\)\([a-zA-Z0-9]\|<[a-z]\)/\1<span style="margin:0.25ch;"><\/span>\2/g' \
     -i {} ";"

如果你也是盘古之白的信徒，那么在本站留下评论时请不必担心手动添加空格：由于 Hyperskip 评论会在 Hugo 构建站点时插入，它们也会被以上的脚本影响到。请尽管坐下、放松、享受这空白一片的绝景吧。

直到几周前（在看 Level1 News 时），我才了解到这条谚语的完整版本：“三月像狮子一样来临，像羔羊一样离去。”我是从漫画《3 月的狮子》得知前半部分的，但我当时并不知道这句话是在描述三月的天气。

以上其实就是我开始写这篇日志的的全部动机，但今年的三月的确相当不寻常。由于 COVID-19，我正在家中“远离社交”，或者说是沉浸在独处的享受中。为了准备长时间在家工作（绝对是借口），我进行了一连串的电子产品升级：我购置了第二台显示器、显示器支架和更大容量的 NAS 硬盘。实际上，去年秋天以来我一直在逐步扩展我的设备库。也许我该写一篇日志来记录这些。

我开始自己做饭是三年之前，而最近两年亚马逊的 Prime Now 服务成了我赖以果腹的唯一食材来源。自己的日常起居竟然如此依赖亚马逊的事实是有点令我担忧。但是在我拥有自己的地下基地和蓝藻农场之前，我只能凑合维持这种共生（或者应该说是寄生）关系。不过，我不确定我是否真的喜欢烹饪，至少我花在烹饪上的大部分精力都在如何减少而非增加在厨房里花费的时间。幸运的是，我几乎从不厌倦吃相同的食物，所以我一直做着相同的几道菜肴，并逐步将每一道菜的准备工作优化到最简：我的早餐是酸奶和混合干果，午餐是咖喱牛肉饭，而晚餐则是煎三文鱼配米饭和炒卷心菜。

病毒的肆虐也使我不得不暂时搁置跑步计划：我平时使用的路线已经不向公众开放。所幸在开始居家远离社交之前，我已经超前完成了不少里程（比起预订计划提前了 4 周），所以我仍然有望实现 2020 年的目标。也许是由于路上的积雪，我的跑步鞋（美津浓 Wave Rider 23）磨损得比以前更快：在累积里程达到 250 英里时，我已经感觉到跑长距离时足弓不适，而这双鞋以前的版本可以一直撑到 300 英里左右。除了鞋子问题外，随着我逐步延长的跑步时间，我时有胫骨疼痛的现象，所以我正好趁这个机会休息一阵。为了最终在工作日也能跑步，我转为了晨跑派。到目前为止，尽管有个别风雪交加的日子比较难熬（但其实挺有趣的），我仍喜欢这一决定。另外，能看到更令人振奋的日出而非日落也是个优点。

在病毒爆发期间所读到的新闻经常给我带来一种不真实感：既因为实际发生的事情，也因为新闻那种刻意挑起矛盾的报导方式。好吧，公平地说，要求一个以掠夺人们注意力为食的机构以朴实、不带修饰的方式来报导新闻本身就是一种矛盾。不过话说回来，同样从当前的情况更多地感到兴奋而非不安的我或许没有资格对新闻媒体的做法挑三拣四：仅仅想到这间普通的公寓现在是我抵御尚无治疗方法的病原体的个人要塞就足以让我睡不着觉。

如果这确实是人类覆灭的开始，至少我的博客和 Emacs 配置将由于 Github 存档计划 继续存在（假设微软没有说一套作一套的话）。在那之前，请保持安全，不要随便离开自己的胶囊生活仓，并做好准备迎接我们一直苦苦等待的荧光色太空时代藻制食品吧。

就像我当时决定换掉 Wordpress 一样，我觉得我已经受够了运行 Mastodon 和 Gitea。

跟上 Gitea 设置选项的频繁改变一直很烦人，而使用 Mastodon 时，由于系统库版本不匹配（通常是 protobuf）造成的依赖软件包出错十分常见。尽管后者不是 Mastodon 本身的错，但需要额外安装两个软件包管理器（分别用于 Ruby 和 Node.js）来运行一个程序对我来说是很荒谬的。

我于 2018 年开始在服务器上运行两者：先开始的是作为 Twitter 替代品的 Mastadon，而 Gitea 则是我后来对微软收购 Github 的回应。回头想想，相对于我的需求，这有点大材小用：我的 git 服务器和微型博客的主要用例都是单用户中心的只写任务。这意味着这些内容应以只读形式提供给我网站的访问者，而静态网页正是完美的替代品。

从 Mastadon 开始说起，我现在使用 twtxt 格式存储和发布我的微型博客。这一格式已经存在了一段时间，但最近在波浪号社区（tildeverse，一系列提供可公共访问的类 Unix 系统的网站）中开始重新流行。尽管现在有一整个旨在为该格式添加更多功能的社区支持的生态系统（其中包含各种语法扩展和软件），但我发现最基本的的时间戳加制表键加文字的语法已足够满足我的需求。这种即写即忘的形式确实很容易上瘾，尤其是与自己写的命令行客户端搭配使用时（我的版本被恰当地命名为 twixter）。

至于 Gitea，虽然我认为是 Github 的优秀替代品，但它更适合于多用户协作，而不是作为个人项目的闲置场。我决定直接自己管理 git 仓库（参阅《Pro Git》的 4.4 和 4.5 章），然后使用 stagit 生成相应的 HTML 文件。这些由 stagit 生成的页面已经替代 Gitea 作为新生的 川陀全息档案馆。

在解决了我在线存在的只写任务需求后，我将继续探索剩下的两个难题：只读（内容消费）和交互（通讯方式）类操作。目前，订阅源和电子邮件是我最好的答案，但是它们仍然不足以涵盖我所有的需求。

最近，我在想办法将我的微型博客整合到当前网站里，所以我开始重新考虑 IndieWeb 所提倡的一些构想：与希望一切都通过服务器 API 和 JSON 响应来动态完成的 ActivityPub（Mastodon、Pleroma 等用于互联的协议）不同，IndieWeb 社区推荐的不少标准都支持从有正确标记的静态 HTML 文件中直接生成机器可读的网站源。IndieWeb 隐含地依赖的一大核心要素是 URI（统一资源标志符）的稳定性，或者从更高的角度来说，站点所有者对域名的控制。由于最近关于.ORG 域名的 闹剧，我逐渐意识到，一个域名昂贵到无法维护（或可能随时被扣押）的未来可能并不是遥不可及的。这会严重破坏整个 IndieWeb 赖以建立的前提，更不用说更常见的链接失效了。幸运的是，我觉得 IPFS（星际文件系统）有潜力能够解决这两个问题。

IPFS 速成班

好的，好的，我知道和一些类似的项目，例如 Dat 协议，pingfs，甚至 Scruttlebutt，比起来，IPFS 的名称听起来非常不靠谱（相信我，我开始时也和你一样怀疑），而不少加密货币类创业公司将 IPFS 与各种首字母缩写词混杂在其营销资料中的事实更降低了它的可信度，但 IPFS 看起来的确是类似项目中最成熟且易于使用的。以下我对解释 IPFS 所做的尝试，其信息大部分来自 官方文档 和这一 讲座。如果你对进一步的实现细节感兴趣，这一 来自 IPFS Camp 2019 的专题讨论 是一个很好的起始点。

简单地说，一条网页链接只是指向某服务器上文件路径的一种花哨说法。就像一般的文件路径一样，服务器下线后，即使坐在同一房间的某人可能缓存了网页内容，该链接也无法被访问。在 IPFS 中，文件（或数据块）通过与其内容相应的加密哈希值作为地址，并以分布式的方式存储在所有用户群中。这意味着我们不需要中心化的设施来访问文件、可以简单地验证文件完整性、可以使用 P2P 共享来加快访问速度、以及以这种方式存储的文件内容是无法改变的。

无法更改文件内容相比我们所得到的好处来说似乎是一个相当昂贵的代价，但是就像计算机科学中的任何其他问题一样，这可以通过添加抽象层来解决。解决这一问题的 IPNS（星际域名系统）利用公钥加密来创建可以指向不同文件的不可变地址。IPNS 地址基本上就是某个公钥的哈希值。一次 IPNS 查找包括取回公钥本身、搜索具有相应的私钥签名的指针文件（一个包含 IPFS 地址的文件）、辨认最新的指针文件、以及重定向到正确的地址几个步骤。要利用 IPNS，用户首先要创建一个公私钥对，然后将公钥、想分享的文件和带有签名的指针文件上传到 IPFS 上。当需要更新时，用户只需要签署并上传新的指针文件就可以了。

IPFS 的不少方面都可以在过去的项目中看到踪影，例如 BitTorrent（P2P 共享）、Plan 9 下的 Fossil 和 Venti（一次写入的数据块和路径重定向）、和 git（哈希树/有向无环图）。但是，IPFS 的杀手级功能在于其与现有架构集成的便捷程度。专用的 HTTP 网关允许从浏览器（而不是 IPFS 客户端）中直接访问 IPFS 或 IPNS 地址，而且 IPFS 还具有与 FUSE（用户空间文件系统）的兼容性，这意味着我们甚至可以将整个 IPFS 挂载为一个只读分区：这一兼容性也让我们能够托管静态网站，但是我必须承认，访问全球（甚至星际）规模的 P2P 共享盘是个明显更酷的用法。

在 IPFS 上架设静态网站

官方指南 已经很好地概述了使用方法。以下是简要概括：

• 运行 ipfs init 和 ipfs daemon 初始化并启动 IPFS 守护进程。
• 生成网站文件并运行 ipfs add -r <网站文件路径> 将其内容发送到 IPFS。输出的最后几行会有路径根目录的哈希值。
• 如果要使用 IPNS，请运行 ipfs name publish <网站根目录哈希> 以将 IPNS 链接定向到刚刚上传的文件夹上。IPNS 公钥的哈希值可以通过 ipfs key list -l 获得。
• 在更新或重建网站文件时重复以上两个步骤。由于 IPFS 寻址过程固有的数据去重功能，该过程的实际开销并不大。对静态站点这一用例来说非常合适：越大的文件（例如照片）更新频率就越低。

完成此操作后，我们就可以从任何专用 HTTP 网关使用 <网关地址>/ipfs/<网站根目录哈希> 或 <网关地址>/ipns/<ipns-地址> 来访问刚才上传的网站了：我们可以使用由 IPFS 守护进程启动的本地网关（通常位于 127.0.0.1:8080），也可以使用 公共网关（由于 IPFS 文件取回需要在运行网关的服务器上进行，因此使用公共网关有遭受来自服务器所有者的中间人攻击的额外风险）。如果想要架设多个网站，则可以使用 ipns key gen 来生成更多 IPNS 密钥对，并在执行 ipfs name publish 时通过 --key 选项指定发布地址。

在 IPFS支持 IPNS 密钥的导入/导出 之前（这有助于我们备份密钥并从多台设备发布内容），DNSLink 可用于更方便地访问站点，但代价是需要拥有域名并信任 DNS 服务提供者。要想通过 /ipns/<域名> 从 HTTP 网关访问站点，只需为域名加入以下 TXT 记录：

dnslink=/ipfs/<网站根目录哈希>

或

dnslink=/ipns/<ipns-地址>

例如本站就可以通过 /ipns/shimmy1996.com（该链接使用 ipfs.io 架设的公共网关）来访问。虽然算不上是一个完全没有缺点的办法，但对我来说这是个合理的妥协。我发现 IPFS 通常比 IPNS 快，所以在 DNSLink 里用 IPFS 地址应该更加合适。为了避免每次手动复制粘贴，我在博客构建脚本中添加了以下内容以自动将网站上传到 IPFS 并更新 DNS 记录（使用 DigitalOcean 的 API）：

echo "上传网站至 IPFS..."
hash=$(/usr/bin/ipfs add -Qr "<网站根目录>")

echo "更新 DNSLink 记录..."
token="<digitalocean-api-令牌>"
curl -X PUT \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $token" \
     -d "{\"data\":\"dnslink=/ipfs/$hash\"}" \
     "https://api.digitalocean.com/v2/domains/<域名>/records/<记录-id>"

DigitalOcean 上 DNS 记录的记录 ID 也可以通过 其 API 取回，不过你可能需要在请求中增加 ?page=2 或更后面的页码才能找到你想要更新的记录。

对了，还需要注意的是，正如同使用任何脱机 HTML 文件时一样，我们需要在生成的网页中使用相对链接。在 Hugo 中，这可以通过在 config.toml 中加入

relativeURLs = true

来实现。

当然，作为一个 P2P 网络，IPFS 无法取回已经不存在于任何节点上的文件。默认情况下，IPFS 客户端会 固定 从本地计算机共享的任何内容：固定内容不会被删除，这确保 IPFS 上至少有一个可用的副本。我们可以取消固定网站的过时版本，或者，如果需要，在多台设备上查找并固定网站地址以防万一。

繁星若尘

回到 IndieWeb 的问题上：越来越黑的域名系统和链接失效使基于 HTTP 的 URI 的稳定性难以保证。但是，如果我们使用 IPFS 或 IPNS 地址作为 URI 呢？简直完美！我们通过由数学而非 FBI 警告所控制的地址获得了（理论上可以永久持续下去的）对静态网页的稳定分布式访问。消除拥有服务器的需要还降低了拥有个人网站的门槛。HTTP 协议已经存在了 29 年，而 IPFS 仅存在了 5 年。我不知道 IPFS 在接下来的 24 年中是否还会继续存在，但是如果是的话，我希望我们会看到一个或许更加混乱，但更加健壮、充满活力、多彩的在线世界。

疫情给了我更多时间来回顾想看的电影、节目和书籍，所以我考虑建立一套自己的评分系统，以简化写（如果有的话）评论的过程。

指导原则

一般的评分标准具有 10 个或更多级别。这个选择范围在我看来太大了，更不用说那些采用百分制的评分系统了。即使是最常见的五颗星系统也会在引入半颗星后变得繁琐。6 分与 7 分或 4.6 分与 5.1 分间究竟有什么区别？较高的精细度在汇总大量评分中可能会有用，但从单个评论者的角度却不是这样。我更喜欢 S1 漫区投票 所采用的方法：让评论者在更少但区别更明显的几个级别中作出选择。

我的身边统计学表明，大多数在线评分都聚集在 70％周围，这是个与 预测任何事物的成功率都为 40％ 一样没用的分数。换句话说，大多数评分系统的下半部分都没有得到充分利用：我想不到任何我会给出一星半而非一星评价的情况。此外，我查看评分和评论的目的在于了解高质量的作品，而不是差的那些。一个评分系统仅关注“更好的那一半”就足够了：为什么我在忍受完一个糟糕的节目后，还要给它一个评分？《米其林指南》可没有负一颗星，不是吗？

单纯地用一个分数来概括任何东西的质量都不怎么公平。我想有一个更具表现力的评分系统，以传达我对所喜欢作品不同方面的看法。至少一个恰好对上我的波长的作品应该和一个更具大众吸引力的作品得到不一样的评价。

评分方法

隆重推出 TIReD 评分系统！以下主要以动画/电视节目为例，但这种方法中的许多内容也适用于其他艺术形式。每个作品会在以下项目中进行评分，分数之和构成最终评分：

作品的有形方面包括视觉风格、动画、配乐、CG 质量、特殊效果等等。简单来说，作品的制作是否精良。以 0 分为起点，评分标准为：

• 1 分：如果作品总体上吸引人，且维持了稳定的高质量、缺点极少（完美）或利用独特的想法、技术产生了非常棒的效果（高妙）；
• 2 分：作品采取的表现手法本身就足以作为观看的理由，即使作品在其他项目中得分全部为 0 分。

作品的无形方面包括故事本身、角色塑造、剧情节奏、文化背景参考等等。这些特质应该一定程度上独立于作品的具体表现介质而存在：我至少可以同样地享受基于其他艺术形式对作品的忠实再现。评分标准与之前类似，不过对于明显遵循原作内容的翻拍或改编作品，且我看过原作时，评分标准会有所调整：评分将以原作在无形方面的得分-1 为起点，视翻拍、改编的质量、难度、效果作出最多 1 分的调整后舍去超出 0-2 分的部分。例如，对+2 故事的平庸重述最多只能授予+1。翻拍和改编的起点往往比原创容易一些，所以我想以“作品本来可以有多好”为基础作出调整，对“如果我看过原作，还应该看吗”这类问题作出回应，并方便挑选出那些“不必看原作”或“已经超越了原作”的作品。

回味，顾名思义，衡量我是否想重温这一作品。这更多地与我自己的口味或怀旧之情相关：这应该是我会在一个无所事事的午后重新观看的作品。较长的作品在这一指标上会处于比较不利的地位，所以我会将特别令人难忘的片段也计算在内。在翻拍和改编的情况下，这一项目的得分大多数时候都应该仅授与我认为最好的版本。

酌情加分不应该轻易使用，且对已经在其他三个项目中获得满分的作品无效，这使得最高总得分为 5 分而不是 6 分。设置这一项目的主要目的是对于我认为作品优点没能很好地被现有评分标准体现出来时作出调整。适用的常见情况包括但不限于：

• 类型天花板：同类最佳；
• 作品的有形和无形方面有着紧密的联系，缺一不可；
• 超越客观条件限制的质量，尤其是对于年代久远或预算紧张的作品。

记录格式

TIReD 评分记录的格式为 X=T/I/Re[+D]。例如：

• 一个有形得分为 1 分、无形得分为 2 分、回味得分为 0 分、酌情加分为 0 分的作品会被记录为 3=1/2/0；
• 一个有形得分为 1 分、无形得分为 0 分、回味得分为 0 分、酌情加分为 1 分的作品会被记录为 2=1/0/0+1。

对于我半途放弃看下去的作品（意味着我无法给出评分），会被标记为 DNF（did not finish）。

自我问答

我在制定 TIReD 时的一些想法碎片。

问：应该评定书籍的有形得分？

答：我觉得应该就是看行文本身的质量，例如其能否称为“文学作品”。虽然我对自己鉴定优秀作品的能力并不那么有信心，但是至少获得 2 分的作品应当比《哈利波特》要好。

问：在其他相关作品中建立的世界设定如何影响评分？

答：世界设定会影响回味得分（系统或世界是否有趣、让我想进一步了解）和无形得分（人物背景是否合乎其行为）。

问：酌情加分的规则是如何确定的？

答：不论分数范围多大，最好的作品始终会获得满分，所以给它们再加分没有什么意义。另一方面，有一些看似不起眼的作品却充满了制作团队、作者的热爱和诚意，还有一些作品存在本身就足以称为爱好者的福音。我想在保证较为客观地评判作品的有形和无形方面得分的前提下表达自己的欣赏，而酌情加分提供了一个途径。

问：在看原作前后，改编或翻拍作品的评分会如何变化？

答：在看过原作后，我将调整改编或翻拍作品的分数。

问：翻译常常会漏掉一些细节，如何处理翻译作品？

答：处理方式与翻拍相同，在看过原作后评分会被调整。

问：“TIReD”（以及分项得分名称）是怎么确定的？

答：第一个有具体名称的项目是回味（revisit-ability），后面的大部分时间都花在玩单词排列和缩写上。由于 Urban Dictionary，我差点将这套评分标准命名为“TIRD”。不过，至少不是所有的作品都是*。😜

我今年 完成 了 Advent of Code！除了问题比去年（对我来说）变得简单了之外，我换用 Go 完成了今年的挑战：我觉得 Go 特别适合这类任务。

今年的谜题主要涉及字符串解析以及寻找最高效的数据结构。大部分解题流程的逻辑都比较简单，几乎不需要任何复杂的算法。

对于字符串解析，正则表达式（Go 自带支持）是最佳途径。今年为数不少的字符串解析问题意味着想只用基本的字符串操作解答会十分痛苦。我已经看够了用查找、剪切、提取子串等操作拼砌起来的怪物代码。

绝大部分时候，切片（slice）和集合（map）足够满足我的要求。Go 支持多返回值，却不支持元组（tuple）；不过，我发现序列（array）和结构体（struct）基本取代了元组的功能。这些数据结构由于 Go 鼓励使用常量而非枚举类型（enum）而变得更加多功能：将所有信息储存为整形（int）使得一些捷径成为可能，同时也省去了类型转换的麻烦。和更让人安心的支持类型检查的枚举类型不同，（滥用）这些选择让用 Go 写短程序有着和行走在刀刃上（或者在 Zoom 通话时不穿裤子）一样的莫名快感。

Go 简单明了的控制流和缺少多范式支持的特点让指令式程序编写起来非常容易。不必担心是否应该使用 STL 算法或者串联迭代器方法：写个循环就好了。合理的对象可变机制也有帮助：不论是边遍历边修改集合元素，还是将带有切片的结构体传给函数，我发现我可以很快地让 Go 做我所想的事情，而不用反复翻阅语言规范。

这让我想到了 ZOI 这一经验法则：只有零、一、无穷多是合理的个数。不少我所熟悉的编程语言，例如 Python、C++、Rust，都为了追求一致性落在这一光谱的两极：一切都有着相同的规则，用户就和语言本身一样有着决定语法含义的能力。Go 有着更多的异常之处（尽管 Go 并没有异常支持）和只有“一”个的例外：内置容器神奇地有泛型支持、它们方法的返回值数量可变、除它们之外的容器都没有获得迭代支持的资格。

这只是一个不涉及 Go 其他特性（例如界面（interface）或协程（goroutine），不过这些对解决 Advent of Code 并不是必须的）的简单比较。我觉得 Go 的选择独特且有趣：一切都，嗯，不大一样。

今早，窗外的屋顶上都是白色一片。那些广告牌在阴沉的天空下失去了平时的光辉。就连橙色的路灯也没法让一辆车都没有的道路显得温暖。不过，来自少数建筑物窗户的光点却比平时更加耀眼。

真是不寻常的一年。时空密度比平常高出不少——能将阳光削弱成象牙白的微弱光晕的程度——看看过去这多事的三百多天。

我其实挺高兴看到 2021 年的第一天感觉就和 2020 年中的任何一天一样。给这么一个随意选定的数字+1 不应该对现实产生任何实际变化。不过也许正是因为缺少变化，我们才需要时不时地看到一些新的、能让人眼前一亮的东西，不论多么微不足道。

话说回来，偶尔享受下这种廉价的心理学把戏大概也不会有什么坏处。

新年快乐，我们终于等到了。

2020: 天启

这次我可不会在进度上再打马虎眼了。

• ☑ 跑 550 英里。 跑 205 英里并骑车 865 英里（2.5 倍）。[205/205][872/865]
• ☑ 写 14 篇日志。[16/14]
• ☑ 不吃甜面包圈。
• ☐ 了解 Go 和 C++20。[1/2]
• ☐ 建立正式的数据备份流程。
• ☐ 阅读非技术类书籍。

由于 COVID-19，我从 3 月初开始就停止了在户外跑步。在偷懒了几个月后，我在 6 月份买了一台自行车和训练器，改为在室内骑行。2.5 倍的换算比例是基于我骑车和跑步的速度差异而定的。在一个更可控的环境里锻炼非常让人享受。除了能方便地补充能量和不受天气影响外，能够在骑行的同时看动画/听声优广播真是太赞了。果然科技是第一生产力！

写关于博客本身的博文仍然占据了我的日志中相当大的一部分（这真是种令人沮丧的自欺欺人的行为）,不过至少我积累了相当数量的鸮文：这些转瞬即逝的想法流对于日志来说太过松散，但仍然有趣到我想把它们记录下来。我同时也用鸮文来存放我对其他博客的回复。略显繁琐的回复流程让我意识到，大部分时候我似乎并没有什么真正想说的内容。别误会，这并不意味着这种麻烦的半手动回复系统有多么优越，但我觉得能够提高所写内容的信噪比是有实在的好处的，不论对我还是对其他人来说。

啊，甜甜圈，这刷满蜜糖的罪恶之枷锁，这油炸的放纵之镣铐。虽然我很想把成功抵御诱惑归功于我的钢铁意志，但 COVID-19 才是根本原因。我的懒惰和对隔离生活的兴奋劲消除了任何深夜造访 Dunkin'的机会。大概是时候把挑战升级了。

Go 写起来相当无脑而有趣。找到一个有效的掌握 C++20 特性的方法则要难得多。<format> 是新特性中最直截了当的一个，基本用法、功能和你能想象出来的基本一致（还没有编译器支持新标准的版本，尝鲜的话可以用 原版）。<ranges> 类似于 Rust 的迭代器方法，而且允许串联。也许是时候更新那篇 用 C++ 来 enumerate() 的日志 了。<concepts> 应该是 SFINAE 所试图解决问题的真正答案，但我还没有一个好的实际运用环境来测试它的威力。顺便一提，Zig 用编译时间函数来实现泛型的方法也很让我感兴趣。

3 份副本，有了。2 种不同的储存介质，有了。1 个非本地备份，还没有。这还是已经算上 Syncthing 副本（这能不能当作一份完整的备份还有待商酌）的进度，看来我离完成正式的备份流程还是有不少距离。

严格地说，我确实 阅读 了非技术类的书籍；只不过我没有 读完 任何一本（不算漫画的话）。事实上，除了那些我纯粹为了娱乐而读的，我并没有什么想读的非技术类的书。大多数非虚构类的书看起来像是被阿谀奉承和幸存者偏见腌制过的成功者故事。而我又不怎么提得起兴致阅读小说：和获得一个能够复述给他人听的故事相比，我更愿意了解一种新的算法。啧，这听起来真刻薄。难道我觉得我的日志能赢过所有的小说？总之，在认输之前，今年我会给出更加认真的一次尝试。

2021: 未来昔日

疫情引发了前所未有的怀旧情绪。人们表现出来的对“正常日子”的眷恋，却让我莫名地反感。并不是说我对这种异样的气氛完全免疫，只不过它对我的效果似乎正好相反：我发现自己变得比以前更加坚持己见了。说到底，人们不都暗自认为自己的水平在平均之上、能够作出更加合理的判断吗（尤其是在看完新闻之后）？同时，我的理性则告诉我要在这种冲动变成傲慢，或更糟糕的无知，之前将其抑制住。也许我应该学会把这些想法以日志的形式释放出来，比如写成非技术版本的 EWD。

换个积极一些的话题吧，我向朝 5 晚 10 生活习惯的过渡非常成功。封城居家办公对这一过渡有着很大帮助：我能够更加从容地调整睡眠时间了。现在每天早上我都有充足的时间用于锻炼，甚至还可以选择睡上两个小时（三个小时也不是不可以！）的回笼觉。考虑我在年末假期的短短几天里就完成了最后 100 英里的骑行，今年我会把目标里程数提高一些。

生活习惯的改变也让我意识到我睡前的几个小时大多在碌碌无为中度过：在一天的工作和急需的晚餐后，我不大有动力进行锻炼或长时间集中注意力于任何事情。同时，受到用 beanancount 记账的影响，我有了将类似的方法应用于时间管理的想法。我正在在测试用 Toggl Track 记录我是如何度过一天中的大块时间的，以及中间有多少分钟随着我在大脑空白状态下刷 YouTube 而溜走。对了，有这么一个可以勉强当作读书版 Strava 的系统应该能让我的阅读目标更容易实现。至于要读哪些书，我觉得经典小说是个不错的开始。

继甜甜圈之后，我今年的挑战是戒掉曲奇饼干，我工作场所的午餐时常提供它们。直接吃曲奇饼干的原料（例如成条的黄油和大堆的砂糖）只是想想都觉得恶心，但烤成饼干后吸引力却能指数性增长，真是奇怪。

我怀疑这个现象到了一定年龄才会出现：人类成长到一定程度时，听觉会和电吉他的声音一拍即合，使其变得无法抗拒。我想多花一些的时间来学这一乐器、在 2021 年底时能弹好一两首歌。

Z 之后的世代居然叫 Alpha，真是完全不讲道理。吔屎啦，这毫无逻辑的命名方式。吔屎啦，COVID-19（当然是因为命名方式以外的理由）。

Un de ces matins disparaissent
Le soleil brillera toujours.