个人介绍

我一直觉得个人介绍很难写。

我不怎么待见这样的个人介绍：

史科特・危险・索罗，MIB，是 WHSA 认证的西格玛级虫洞冲浪专业人士。他敢于开第一枪，会毫不犹豫地交叉粒子流，善于进行第四维度的思考。

这读起来就像嚼他人自我风味的泡泡糖一样让我感到恶心。我总忍不住把这些听起来冠冕堂皇实则空虚异常的表述当作是试图给在线内容增加可信度的绝望尝试。

大多数时候，我选择不在网上写个人介绍。我的旧 WordPress 博客上的关于页面是少数例外之一：

EE 狗；技术渣，WP 新手；ACG 相关；喜欢硬件但是没有小钱钱；足迹可能遍布各大社交网站，通常名字为 shimmy1996；求友链 XDD。

即使是这种简单的介绍，对我来说也有种过于露骨的感觉。在其他情况下，我会使用随口编出的科幻风无稽之谈，例如：

川陀大学地外生命饲养与烹饪技术系

编造这些空想职业其实非常有趣，我几乎可以整天沉迷其中而不感到厌倦。这只是我库存中的一小部分：

• 超级坏蛋技工（从事他们的修理和维护工作，而不是帮他们统治世界）；
• 土星民俗学和恶魔学爱好者；
• 鱼语（亚特兰蒂斯语的一种方言，为北太平洋的甲壳类和海洋哺乳动物所使用；我知道，这名字非常容易让人混淆）母语使用者；
• 根沸能板（时伏电池模组，你可以理解为一个反向通量电容器）工程师；
• 超声音乐（不，这不包括蛇爵士乐，因为它们远比不上鲸布鲁斯或者蝙蝠摇滚）收藏家；
• 星等调节专员；
• 梦境摄影与作梦专家。

如果不是因为全光谱摄影真实存在，这个列表还会再长一些。

啊，不难看到我很容易就会被这有趣的活动分心。让我们回到如何在这个有着鸟类（或者说是生物燃料侦查用无人机）却没有树章鱼的地球上写个人介绍的话题上吧。

为何我在读个人介绍时总下意识地觉得它们是以树立权威或者“建立个人品牌”为目的而写的呢？这不意味着对别人的资历表现出敌意和轻视的我才是表现出近似优势情结现象的一方吗？还是说从小听到大的“谦虚是最好的美德”终于开始产生反效果了？如果个人介绍的目的是便于他人将我的个性轻易地、削足适履一般塞进寥寥数个标签定义的边框里的话，那我宁可不提供这一可能会从网站内容分散注意力的目标。话又说回来，如果我经由站点所展现出来的个性能够被区区个人介绍页所扭曲，那也许站点内容也不具有多少代表性。

多尺度写作

我目前将站点上的内容大致分为三类：

• 日志：任何带有发布时间和标题的内容；
• 鸮文：任何具有发布时间但没有标题的内容；
• 固定：任何没有发布时间的内容。

目前为止，我一直将个人简介页放在“固定”类别下。 但是，我开始逐渐意识到显示发布时间与否有着更微妙的含义。

最早让我意识到这一点的是一次经由 RSS 阅读器点进一篇没有标明发布时间的日志的经历。由于我对日志标题有点印象，我本能地开始在寻找任何类型的时间戳。一番侦查工作后，我在 HTML 源码里找到了发布日期的蛛丝马迹。在意识到这一页面早已发布、只不过是因为网站源的格式更新才在 RSS 阅读器中重新出现后，我很快关闭了那一标签页。和上一次读到时相比，这篇日志会不会有些地方措辞发生了变化？有这个可能，但我的记性没有好到能察觉这些的程度。有没有可能这篇日志其实经过了大幅修改？的确也不能排除这种情况，不过要是页面上没有会让人因为担心错过而焦虑异常、大红色字体的“更新于 XXXX-XX-XX”，我大概还是不会看下去的。顺便一提，我造访的另外一些博客除了标注发表日期之外，还会放上一条非常显眼的横幅来警告读者页面内容可能已经过时、作者的观点也可能已经改变。这显而易见的常识居然需要免责条款一样的声明让我觉得有点滑稽，不过这倒是很好地引出了我的观察：我在读到没有发布时间的页面时会将其视为不需改动的成品、已完成的杰作、（作者眼中）宇宙的真理。

我想要通过个人介绍来表达的内容不兼容一般的固定页面格式。那有什么其他的选择呢？我并不想要一个 E/N 站点，因为我觉得整理思想碎片这一过程的价值至少等同于、甚至超过收集这些碎片本身。我有考虑过设立 个人维基，但我想让页面的每个“主要版本”分别存在，而不是把所有改动不论大小全部扫进编辑历史里。虽然对于技术性内容而言，包含了所有勘误的最新修订版自然是最佳选择，但我并不认为过去自己的想法全是过时或错误的，可我也不喜欢将过去和现在混在同一“长内容”页面上。

我想让个人介绍成为脱去水分后文字版的自我，而这是一个固定页面只能永远追赶而不可到达的、不断随着时间的推移而变化的移动目标。在固定页面和日志之间，有个空缺的时间尺度：我需要一种能够比固定页面更快展现变化、但又比注明发布时间的日志更加持久的格式。

可扩展人格档案（XPA，eXtensible Personality Archive)

不觉得这名字超赞的吗？XPA 还恰好是 负责修复 DNA 损伤 的一种蛋白质及其对应基因的名字。

好啦好啦，在把这一切贬低为不必要的折腾之前，给我个解释的机会。比起一个固定的个人介绍页，我觉得最合适的替代品是一系列逐渐被更新的记录，像一本书的不同章节一样。有些书籍，例如漫画或连载小说，通常是马尔可夫过程般一章接着一章地不停发布的；我设想的则是一种修订与更新更频繁发生的非线性增长。

我访问的部分博客有着与“日志”独立开的、目的类似的“文章”或“观点”分区。比起这些，我所想的格式更接近 RFC、PEP 这类文件。XPA 会被编号，而每个 XPA 的内容会是我对某个主题相关的当前一切想法，并可以被新的包含类似内容的 XPA 所取代。同时，日志则保留给我做过或经历的具体事情。换句话说，XPA 包含我字面意义上的思想状态，日志和鸮文则用来记录这些状态之间的一些增量变化。

严格按照定义，XPA 实际上是一种比我最初所想要灵活得多的格式：对影视作品的评论也可以归入它的范围。想想那无数的可能性！现在我只要把剩下这点微小的工作做完就可以开始了：确定怎么在站点上显示 XPA，是否从 0 开始计算编号，想好应该使用那种进制，决定编号的具体格式……

啧，命名真不是件容易的事。

评论区

暂时没有评论。

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

我其实挺高兴看到 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.

评论区

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

对于字符串解析，正则表达式（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 的选择独特且有趣：一切都，嗯，不大一样。

评论区

暂时没有评论。

指导原则

一般的评分标准具有 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”。不过，至少不是所有的作品都是*。😜

评论区

暂时没有评论。

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 年中是否还会继续存在，但是如果是的话，我希望我们会看到一个或许更加混乱，但更加健壮、充满活力、多彩的在线世界。

评论区

暂时没有评论。

跟上 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 作为新生的 川陀全息档案馆。

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

评论区

暂时没有评论。

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

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

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

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

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

评论区

暂时没有评论。

到目前为止，我一直在源文件（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 构建站点时插入，它们也会被以上的脚本影响到。请尽管坐下、放松、享受这空白一片的绝景吧。

评论区

navigator.registerProtocolHandler(
    "mailto",
    "https://mail.google.com/mail/u/1?extsrc=mailto&url=%s",
    "Gmail"
);

通向过去的链接

好吧，《天行者崛起》的玩笑就开到这里。如前所述，我的博客最初使用 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（我在试图使它和博客的外观保持一致上花了太多时间），并移除了日志标签和类别。

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

评论区

暂时没有评论。

话说回来，看到 2020 这个数字会让人不自觉地感到兴奋，因为这在我的印象里总是存在于极为遥远的未来：我甚至不记得任何描绘 2020 年代的科幻作品。大多数作品不是止于 2010 年代，就是直接跳到 31 世纪，使得接下来的十年处于期待值的空白区域。对了，2020 年将迎来农历的庚子年，而有趣的是 维基百科 的英文直译是“金属耗子”——想不到一个传统概念会有这么朋克的名称。

2019 回放

2019 年的计划进行的非常顺利！

• ☑ 跑 400 英里。[555/400]
• ☑ 写 10 篇日志。[14/10]
• ☑ 停止使用 Gmail、Inbox 应用程序。[2/2]
• ☑ 给博客加上 rel=me 链接。
• ☑ 进一步了解 Rust 和 Julia。[2/2]
• ☑ 记录我中意的书籍，音乐，和影视作品。
• ☑ 清理台式电脑。

在排除了生活中的一些不确定因素后，我在 2019 年的日常变得更有规律了。我仍然时不时地拖延博客文章，但至少发布日志的频率高了一些。学习 Rust 和 Julia 很有趣，而且我也在实际项目中用到了它们。我还尝试了用这两种语言完成 Advent of Code 并撑到了第 17 天，到解决问题所需时间太长为止。我曾考虑过圣诞节后完成所有剩余的问题，但我决定不这样做——我认为自己不会通过这些问题增加对这些语言的了解，把时间花在其他地方可能会更好。

受到 本文 启发，我给博客写了一个新的 Hugo 主题。我发现一步步消除那些可有可无的装饰的过程奇怪地令人满足：我希望博客带有任何不必要的东西。本站的订阅源已改为使用 ATOM，并且完整显示每篇日志，而不是默认的支离破碎的摘要。在上一次尝试整理浏览器书签并遭遇惨败后，我开始使用网站订阅源来阅读其他博客。到目前为止，我很喜欢这一新方式。

我今年去电影院看了三部电影，分别是《龙珠超：布罗利》，《普罗米亚》和《星球大战：天行者崛起》。三次观影都还算愉快：试图用评级来量化这种享受可能并不公平，因为我喜欢每一部电影的原因都不尽相同。由于我很少去电影院看电影，我在飞机上度过的时间贡献了我电影消费的很大一部分。《蜘蛛侠：平行宇宙》是我 2019 在飞机上看的影片里最好的一部。在圣诞夜，我没有延续大学期间的传统——看《龙与虎》——而是重温了一部我在数年前的一次飞行中看的电影，《歪小子斯科特》。这部电影的确像我记忆中的那样怪趣。

作为一个直到 2018 年都住在不会下雪的地方的人，雪对我来说是一个如此陌生的概念，以至于我会把任何有下雪场景的电影都视为圣诞节电影。即使在 2018 年年中搬到一个下雪的城市之后，我仍然没有看到过那种虽然俗套、但蓬松得似乎带有温度的圣诞雪：我所住的地方只有堆积在路边的脏水和脏冰的混合物（而且它们总能找到办法进入你的鞋子）。这更能让我想到鱼市而非圣诞节。我敢打赌，电影中所有的积雪场景都只是道具，就像登月照片一样。嗯，肯定是这样。

在 2018 年，我设置了一个 Mastodon 实例，此后我删除了自己的 Twitter 帐户，但是我并不经常使用 Mastodon。起初我觉得我属于不会写微型博客的类型，但是现在我开始认为是登录、编辑、加标签和翻译的认知开销导致了我不怎么热衷于更新状态。在 2019 年的最后几个月里，我一直在用 twtxt 格式发布微型博客，并积累了相当数量的博文（110 条）。当发布我脑海里的任何愚蠢的想法都只有一行命令之遥时，写微型博客还是挺让人上瘾的，并且重新访问 twtxt 文件有时还会给我带来新的日志想法。将一个类似 Twitter 的社交媒体服务分为只读（订阅源阅读器）、只写（也就是我使用 twtxt 的目的）和互动（我还没有很好的解决办法）的部分对我来说更加合适。我的 twtxt 文件今年很可能会取代页脚里的 Mastodon 链接，因为维持这个重量级网络应用的日常运行对我来说并不是件愉快的事情。

说到删除帐户，我已经将我所有的 Gmail 帐户设为自动转发到我自己架设的电子邮箱，并且我所有的设备现在都已经没有了 Gmail 和 Inbox（RIP）应用。我还没有做好完全放弃 Google 帐户的准备，但是我已经比之前更接近了：我在尝试使用除 Google Domains 以外的其他注册服务商，并使用 Youtube 内置的订阅源而非依赖订阅频道来获取更新信息。不过我成功删除了我的 Facebook 帐户。帐户清理还会继续下去。

2020 之路

由于这个办法在 2019 年效果很好，因此我将继续在博客文章和跑步里程上尝试与去年的数字保持一致。甜面包圈常常是我在 2019 年深夜里罪恶感的来源（都是 Dunkin'的错）。甜面包圈是为数不多的几种尽管会给健康带来不利影响但我仍然愿意食用的食物之一，所以我在此宣言：2020 年不会有甜面包圈！

我一直都想正式建立起一套遵循 3-2-1 原则的数据备份流程。至于要学习的新语言，我已经注意 Go 有一段时间了。随着 Go 模块的发布，这似乎是一个合适的开始时机。除此之外，还有即将到来的 C++20。

2020 年会有几种不同的 Linux 手机（Librem 5 和 PinePhone）发布。我很乐意尝试它们，以探索离开 Apple 生态系统的方法。另一方面，PineTime 可能是我已逐渐老化的 Pebble Time Round 的完美替代品。

除了技术性的之外，我已经有一段时间没有阅读任何书籍了，至少没有任何足以被称为文学作品的书籍。我想在 2020 年改变这种状况。

为天行者系列的终结以及我很好奇会被如何命名的 Z 世代之后出现的一代干杯！

评论区

话说在前面：我在正传之前看的前传。我觉得前传其实还可以-初看时，我觉得这既可以算是阿纳金的故事，也可以算是欧比旺的。直到我看了老三部曲之后，我才完全意识到麦格雷戈的表现是多么出色：我小时候甚至以为他们是同一个人。看完故事的全部内容后，我可以理解与老三部曲一起长大的人为何会将前传视为对其的亵渎。虽然先看前传确实使得《帝国反击战》中的大转折变得平淡许多，但是当看到安纳金在前传中转向黑暗面时，我的震惊程度也绝对不低。

我与《星球大战》的第一次接触其实也不是前传，而是我在当地书店中找到的某个版本的《星球大战：视觉图典》。正是那些怪异的武器（包括我印象特别深刻的光鞭）、宇宙飞船和服装使我对这个世界着迷。我很高兴地发现前传恰好描绘了一个如此多彩而充满异界情调的世界。老三部曲的氛围则要黯淡的多，更加“太空”而非“异星”。在目睹了阿纳金堕落之后，这种过渡对儿时的我来说很自然。

接下来讲讲后传三部曲吧。我和我的大学室友在首映日晚上七点观看了《原力觉醒》（ TFA ）。在即将开映前我们花了半个小时寻找停车位（虽然最后还是因为超时吃了罚单），好不容易才赶在片头结束前进入放映厅。至于《最后的绝地武士》（ TLJ ），我是在首映后一个月的晚上看的。今天早上我赶去看了《天行者崛起》（ TROS ）的首映，早上九点对于观看三部曲的结尾其实意外地合适。 TFA 是一个不错的开始，怀旧加上几条有趣的线索使观看体验变得非常愉快。 TLJ 则给我留下了非常不好的印象，因为它不仅以最糟糕的方式回答了 TFA 可能提出的问题，还把大部分时间花在试图给已经树立成型的老角色上课，而忽略了新角色的成长和发展。我还有一篇充满了我对 TLJ 牢骚的日志躺在我的（ 2018 年的）草稿箱里，所以这里就不多叙述，让我们转移到 TROS 上吧。

简而言之，虽然 TROS 是一个杂乱无章、臃肿不堪的大杂烩，我看得还是挺开心的。

电影开头的一连串镜头简洁地展示了凯洛与皇帝的见面和千年隼团队逃离第一秩序的经过，令人兴致高涨。但是电影的节奏在芬恩、蕾伊和波会面后急转直下，充斥这三人之间毫无意义的争论：我不希望三部曲中最后一部电影还花时间在主角团队建设上，但是 TLJ 的剧情大概没有给 J·J·艾布拉姆斯留太多选择的余地。

这之后的半个小时，三人组和剧情都像无头苍蝇一样在行星间四处乱撞，并在此过程中“牺牲”了丘巴卡和 C-3PO 。蕾伊疗伤能力的展示如此刻意，以至于这几乎必然是情节装置。所有这些中唯一的好场景可能是蕾伊面对凯洛的地方。实际上，两者之间的大多数独处场景都非常有意思，因为只有这些地方，我才能看到蕾伊流露出一点点真实情感（与凯洛形成鲜明对比，凯洛不断的内心挣扎和变化被亚当·德赖弗完美地表现了出来）。蕾伊是一个帕尔帕庭的事实在揭露时挺让人吃惊，但对她的角色整体并没有造成多大影响：一直以来收到阴暗面诱惑的明显是凯洛，而不是蕾伊。

死星残骸上的对决在视觉上令人惊叹，但结束的方式可能有点尴尬：更多的极为刻意的剧情装置的展示，以及最后有点多余的韩·索罗镜头（考虑到亚当·德赖弗的出色演技，我认为这里体现他的转变完全不需要韩）。嘉莉·费雪的逝世是不幸的，但我觉得这为她的角色带来了过于仓促的结局。蕾伊自我放逐的过程也让人觉得老套，而且没有雷伊的特征。或许莱娅（在她即将去世时或是以原力鬼魂身份）才应该是是给蕾伊提供最后指导并而赠予她的光剑的人。

随着情节再次将蕾伊与她所谓的“队友”分开，反抗军和“最终秩序”的决战在芬恩和波看似疯狂的想法（尽管 TLJ 花了大量篇幅明确告知波不要这么做）中开幕。过早出现的蓝多在大部分时间里都无所事事，有点浪费这一角色：由于缺少与新主角团共处的时间，蓝多几乎没有与他们互动的方式。我更希望他只在最后前来援助抵抗军的成千上万艘飞船的其中之一里作为彩蛋出现。话说回来，我挺喜欢抵抗军这一条线的故事：角色之间表现出良好的化学反应，并且以巧妙的方式完成了看似不可能的任务。

与皇帝的战斗则是好坏参半：最终对决之前的一切都非常棒（光剑传递的场面特别赞），直到雷伊不得不独自面对皇帝。雷伊和皇帝之间的情感联系太少了，以至于他们之间的任何对抗都感觉十分空洞。如果有任何角色应该在其漫长旅程的最后得到展示其决心的机会的话，那应该是凯洛，而不是从 TFA 以来都一个样的蕾伊。让凯洛在战斗中牺牲自己、取代维达在《绝地归来》中扮演的角色，会是一个比爬回对决地点、治疗并亲吻雷伊（同时炫耀花了至少十五分钟铺垫的剧情装置）更加契合角色的结尾。一千个西斯对一千个绝地武士的部分显得尴尬且并不怎么贴合故事。顺便一提，皇帝看起来十分吓人（有趣的意义上）：观感酷似 80 年代的恐怖片，但意外地很合适（更不用说这部电影以“THE DEAD SPEAK! ”开头了）。同样有趣的是，皇帝改装的歼星舰终于有了名副其实的歼星级武装。

好吧，看来我其实也不太喜欢这部电影？我也有点惊讶我能想到这么多负面的评价，即使我记得走出电影院时，我的心情是轻松而满足的。回顾后传，这一三部曲整体的感觉就是缺少规划，充斥着即用即抛型角色、本可以用于发展角色的时间流向了一些新奇的机器人或外星生物（大概是为了卖出更多的玩具），而最关键的剧情方面则支离破碎、不合情理。也许《天行者崛起》是在没有适当答案的情况下尝试解决如何为三部曲收尾这一棘手问题的勇敢尝试，而我欣赏这最后的努力。我不知道在后传三部曲中长大的那代人会怎么想他们：他们会像我看前传（或者是《蜘蛛侠 3 》）一样看待后传吗？还是说我的感受并没有完全被怀旧之情蒙蔽？

评论区

暂时没有评论。

空格侵略者

大多数浏览器会将 HTML 中的连续文本合并为一行，并在链接处加上空格。所以

<html>Line one and
line two.</html>

会被渲染为

Line one and line two.

这种一刀切的方法显然不适用与字符之间不带分隔的 CJK 语言。解决方案是为页面（或页面上的任何特定元素）指定 lang 属性，如下所示：

<html lang="zh">第一行和
第二行。</html>

如果你的浏览器足够聪明（例如 Firefox），渲染的结果就不会有额外的空格。但是，所有基于 Blink 的浏览器仍然顽固地将多余的空格塞进去，所以我只能像野蛮人那样继续写一段一行的源文件。尽管不是万能的解决方案，但是指定 lang 属性仍然具有启用特定于某种语言的 CSS 规则的额外好处，这稍后会派上用场。

引号归来

如 之前的日志 所说， CJK 字体会将引号显示为全角字符，不同于拉丁字体。只要网页不尝试混搭字体，这就不会成为问题：只需使用特定于语言的字体栈就行。

body:lang(en) {
    font-family: "Oxygen Sans", sans-serif;
}

body:lang(zh) {
    font-family: "Noto Sans SC", sans-serif;
}

再加上匹配的 lang 属性，所有问题就都解决了。 Firefox 甚至允许为每种语言指定默认字体，所以仅使用后备字体（例如 sans-serif 或 serif ）也可行，不一定要费心编写特定于语言的 CSS。

那么，如果我想用 Oxygen Sans 来渲染拉丁字符，并用 Noto Sans SC 来渲染 CJK 字符怎么办？虽然看似没有问题，但像这样指定字体堆栈，

body:lang(zh) {
    font-family: "Oxygen Sans", "Noto Sans SC", sans-serif;
}

会导致引号被 Oxygen Sans 渲染、显示为半角字符。我的解决方案是通过 unicode-range 定义一个涵盖了引号的替代字体，

@font-face {
    font-family: "Noto Sans SC Override";
    unicode-range: U+2018-2019, U+201C-201D;
    src: local("NotoSansCJKsc-Regular");
}

并修改字体栈为

body:lang(zh) {
    font-family: "Noto Sans SC Override", "Oxygen Sans", "Noto Sans SC", sans-serif;
}

这样我们就可以享受全角引号了！

字体忍者

字体文件通常都不小，对于 CJK 字体来说更是如此：刚才提到的 Noto Sans SC 的大小 超过 8MB 。尽管我已经下定主意要从自己的服务器上提供所有文件，考虑到我网站上的平均 HTML 文件大小更接近 8KB，这显得有些过头了。那么那些网络字体服务如何处理这一问题呢？

大多数网络字体服务的工作方式是在网站的样式表里添加一堆 @font-face 定义，以从专用服务器上提取字体文件。为了减少所提供的文件大小， Google Fonts 会将字体文件大卸八块，并在 @font-face 里声明每一块所对应的 unicode-range （这正是它们处理 CJK 字体 的方式）。他们还将字体文件压缩为 WOFF2 以进一步缩减文件大小。而 Adobe Fonts （以前称为 Typekit ）似乎有一些 JavaScript 奇技淫巧，可以动态确定要从字体文件加载的字形。

博采众家之长，得益于这是一个静态站点，我们可以简单地统计所有用到的字符，并提供一个只包含这些字符的字体文件。所要用到的工具主要是 pyftsubset （属于 fonttools 下的一个组件）和 GNU AWK 。将字体压缩为 WOFF2 还需要 Brotli 压缩库。在 Arch Linux 下，获取这些程序需要安装 python-fonttools 、 gawk 、 brotli 和 python-brotli 。

收集生成的 HTML 文件中的所有使用的字形可以使用这条 shell 命令：

find . -type f -name "*.html" -printf "%h/%f " | xargs -l awk 'BEGIN{FS="";ORS=""} {for(i=1;i<=NF;i++){chars[$(i)]=$(i);}} END{for(c in chars){print c;} }' > glyphs.txt

你可能需要 export LANG=en_US.UTF-8 （或者其他 UTF-8 语言环境）以便正确处理某些字形。有了字形清单，我们就可以提取字体文件的有用部分并进行压缩：

pyftsubset NotoSansSC-Regular.otf --text-file=glyphs.txt --flavor=woff2 --output-file=NotoSansSC-Regular.woff2

指定 --no-hinting 和 --desubroutinize 可以进一步减小生成文件的大小，但会降低字体的美观程度。拉丁字体也可以使用类似的技术来瘦身，例如只提取包含 ASCII 字符的部分（或将范围设为 U+0000-00FF 以涵盖 Extended ASCII 字符）：

pyftsubset Oxygen-Sans.ttf --unicodes="U+0000-007F" --flavor=woff2 --output-file=Oxygen-Sans.woff2

大部分字体管理器都可以用来检查最后生成文件中可用的字形，也可以使用这一 在线检查器 （不支持 WOFF2，但是可以先试着转为其他格式后查看，例如 WOFF）。

我还考虑过将字形按受欢迎程度划分为更多块。获取按出现次数排序的字形列表可以使用以下命令：

find . -type f -name "*.html" -printf "%h/%f " | xargs -l awk 'BEGIN{FS=""} {for(i=1;i<=NF;i++){chars[$(i)]++;}} END{for(c in chars){printf "%06d %s\n", chars[c], c;}}' | sort -r > glyph-by-freq.txt

结果显示我的博客用到了大约 1000 个不同的汉字，其中大约 400 个出现了 10 次以上。由于上一步中获得的字体文件大小已经足够好，我没有继续进行拆分。

孔中窥见真理之貌（好像没有啥不对）

我最终将字体文件的总大小减少到了 250KB 左右，但这仍然比 HTML 文件大好几个数量级。虽然看到我的网站在所有设备和屏幕上都保持一致很让人开心，但是与页面大小增加上百倍的代价相比，我觉得这点好处不成比例。

费劲心思指定字体或许并不值得。如果你希望看到我眼中本站的样子的话，以下是我的常用字体：

• 比例拉丁字体： Oxygen Sans 。注意 KDE 版本与 Google Fonts 版本 有一些微妙的区别，我更喜欢前者。
• 比例 CJK 字体： Noto Sans CJK ，即思源黑体。
• 等宽字体： Iosevka ，确切地说是 ss09 样式。

评论区

暂时没有评论。

写 CSS 真是累人，不过好在挑选配色是一件挺让人放松的事。新的亮色主题有更低的对比度，我也更新了 isso 的样式表。是的，我的暗色主题只不过是亮色主题的反色版本，并没有降低文字粗细程度以照顾人类视力的某种古怪特性和其他细微的颜色调整。当我看到由三个似乎没有任何联系的数字形成的颜色代码时，我潜意识已经在大呼异端——它们就像不协和和弦一样让人头皮发麻——所以我 需要 它们至少加起来是一个不那么差劲的数。

知识就是黑夜！

评论区

暂时没有评论。

for i, elem in enumerate(v):
    print(i, elem)

以及 Rust 里 std::iter::Iterator 特性下的 enumerate() ：

for (i, elem) in v.iter().enumerate() {
    println!("{}, {}", i, elem);
}

这里记录了如何在 C++17 或更新的标准里尽量简洁地实现类似功能的办法。

第一种方法是使用一个可变的 lambda ：

std::for_each(v.begin(), v.end(),
              [i = 0](auto elem) mutable {
                  std::cout << i << ", " << elem << std::endl;
                  ++i;
              });

这个方法使用于所有能够保证 lambda 有序执行的算法，但是我并不喜欢末尾很可能被混入其他逻辑的 ++i 。

第二种方法是在 for 循环中使用结构化绑定：

for (auto [i, elem_it] = std::tuple{0, v.begin()}; elem_it != v.end();
     ++i, ++elem_it) {
    std::cout << i << ", " << *elem_it << std::endl;
}

为了不让编译器默认创建只允许同种内容的 std::initializer_list ，我们必须加上 std::tuple 。

第三种最朴实无华的办法是在循环的每一步计算指针距离：

for (auto elem_it = v.begin(); elem_it != v.end(); ++elem_it) {
    auto i = std::distance(v.begin(), elem_it);
    std::cout << i << ", " << *elem_it << std::endl;
}

由于这种方法需要我们在两个地方指定初始指针，我更喜欢之前提到的基于计数器的方法。

在 C++20 中，我们可以在基于范围的 for 循环中加入初始化语句：

for (auto i = 0; auto elem : v) {
    std::cout << i << ", " << elem << std::endl;
    i++;
}

新加入的 <ranges> 库则提供了一种更加吸引人的实现方法：

for (auto [i, elem] : v | std::views::transform(
         [i = 0](auto elem) mutable { return std::tuple{i++, elem}; })) {
    std::cout << i << ", " << elem << std::endl;
}

我最喜欢基于结构化绑定和 <ranges> 库的方法。当然如果要是有 std::views::enumerate 来一劳永逸地解决这个问题就最好不过了。

评论区

暂时没有评论。

更换电池后，触控板恢复了正常。但是，笔记本电脑电池平均在 18 个月左右开始性能下降这一事实仍使我感到非常惊讶。 我这块持续了近四年的电池已经算不错了。较新的笔记本电脑大多使用方形电芯（它们也被用在智能手机中的平板状电池里），而非我的第一台笔记本电脑 Dell Vostro 3750 中搭载那种的圆柱形电芯。电池膨胀一般是由气体积聚引起的，这在带有通风孔的圆柱形电芯中可以避免。有趣的是，可拆卸电池在消费类笔记本电脑中已基本消失 - 即使是大型的台式机替代品（虽然这些笔记本电脑大部分时间都插在电源上）。我能想到的唯一仍然几乎总是具有可拆卸电池的消费电子产品是相机。

这一事件之后，我开始浏览当前市面上的笔记本电脑，因为带有新的四、六核心 CPU 的笔记本电脑是极具诱惑力的升级（我的 XPS 13 配置了 i5-5200U ）。我不怎么喜欢最新版本的 XPS 13（9380），主要是因为端口选择：我目前没有任何 USB Type-C 设备，因此我认为 XPS 13 （9360）上的一个 Type-C 加两个 Type-A 的组合更加优越。除了端口之外，板载无线网卡和全尺寸 SD 卡插槽的移除也使最新型号的吸引力降低。

我还查看了 Panasonic 的 Let's Note 系列笔记本电脑。这些笔记本电脑是可靠而轻便的商务笔记本电脑，并通常配备可拆卸电池和各种端口。如果要是它们没有那么夸张的价格、没有那些丑陋的“ Wheel Pad ”、并配备美式键盘布局，那它们就是理想的笔记本电脑。我最喜欢 2016 年推出的 CF-MX5 系列的外观，但这一系列的性能比起我目前的配置并不会有多大提升。

更为现实的选择包括惠普的 EliteBook ，联想的 ThinkPad T 系列和戴尔的 Latitude 、 Precision 系列。 我否决了 EliteBook ，因为系列所有机器上都有一个巨大的、我可能永远不会使用的专用坞站端口。由于采用了设计功耗 45W 的 CPU， Latitude 5491 似乎有散热问题，但 Latitude 7390 和 7490 看起来都不错，不仅可以禁用 Intel ME 还带有官方 Linux 支持。 ThinkPad T480 几乎满足了我的所有要求，但下一次代的 T490 似乎将不再具有桥接电池系统并仅保留一个 SODIMM 插槽，与 T480s 差不多。

寻找二手机器也是一种选择，但是由于我的主要动机是购买新的四核 CPU ，所以这达不到升级的目的。 有的人认为我们的笔记本电脑的处理性能早已超过我们的日常需求，况且我的 XPS 13 使用时确实感觉不慢，因此我并不急需进行升级。不过我还是列了一下我对理想中笔记本电脑的需求，以备万一。

• 良好的 Linux 驱动程序支持。
• 尺寸小于 15 英寸，旅行重量轻。 XPS 13 将我从 DTR 爱好者转变为 Ultrabook 追随者：能够整天携带笔记本电脑而几乎感觉不到重量非常棒。
• 非 Nvidia 显卡。 AMD 和 Intel 都具有更好的开源驱动程序支持，而且高度依赖 GPU 的任务还有台式机可以分担。
• 合理的电池寿命（ 6 小时或更长时间）和可拆卸电池。
• 不过于激进的接口选择，至少直到所有鼠标和闪存驱动器默认接口都为 USB C 型的那一天。
• 使用标准组件，易于升级，例如内存使用 SODIMM 插槽、无线网卡和硬盘使用 PCIe 等等。
• 不错的触控板。我对笔记本电脑键盘的质量不太敏感，任何质量尚可的键盘我都能接受。不过要是有搭载 ErgoDox 的笔记本电脑就好了。
• 非超高分辨率的显示屏。我对屏幕也不是很挑剔，但是对于这种大小的笔记本电脑来说，采用 4K 分辨率完全是高射炮打蚊子。我通常使用 16：9 比例的屏幕，但不反对尝试其他分辨率比例。

评论区

暂时没有评论。

话说回来，安装过程十分顺畅： Gentoo 手册 编写的很出色，似乎预料到了所有可能出错的地方并准备好了后备反感。与 ArchWiki 的 安装指南 相比，我更喜欢该手册，因为手册还详细介绍了我采取的每一步背后的原因。我甚至觉得，Gentoo 手册实际上是对初学者更友好的，因为它精心汇总了了通常散布在各处的信息，为学习如何驯服你的操作系统提供了一个很好的起点。 此外， Gentoo 手册不仅涉及安装，还包含其他设置一个可用的系统的必要步骤。我将逐步复制我当前的台式机设置，以决定是否值得进行迁移。

我第一次接触 GNU/Linux 操作系统是 Ubuntu 12.04 ：我的一位同学（ vacuuny/A2Clef ）在学校的计算机实验室中安装了它。曾经有一段时间我每隔几天会在各种 Ubuntu 版本之间进行切换。在同时使用 Windows 和 Ubuntu 一段时间后，我在 2014 年完全切换到 Ubuntu 。由于 Ubuntu 上亚马逊广告的猖獗，我尝试了 Arch Linux ，作为 2015 年新年计划的一部分。即使有第二台计算机来查找说明，我也花了相当长的时间来适应新系统。我在旧博客中还曾写到“大概我还没有 get 到 the Arch way ”。但是完全熟悉 Arch Linux 后，我就再也没有回头。

我仍然会不时在 VirtualBox 中尝试其他发行版，但是除了设置过程之外，我从未发现它们与 Arch 相比能够提供多少改进，更不用提 ArchWiki 上极为出色的文档（现在我们有一个竞争者了）。设置好桌面环境后，发行版之间的体验并没有太大区别，但是当我遇到问题并在线搜索如何故障排除时，区别就开始出现了。拥有更多、更新的软件包是 Arch 的另一项魅力。最近，关于 systemd 的争议使我开始四处寻找新发行版以进行试用。与其说是因为实际的安全问题，不如说我只是想试试使用不同的初始化系统：在 Ubuntu 下我主要使用图形界面（ apt-get 和 nano 可能是我很长一段时间里知道的唯二命令）所以并没有什么直观感受，而在我换用 Arch 时， Arch 已经在使用 systemd 了。除了 Gentoo ，候选对象还包括 Void Linux 和 BSD 。 Void Linux 有易于使用的安装向导，但我并不感到它有特别吸引我的地方。看看 Gentoo 是否会改变我的想法。

评论区

暂时没有评论。

一年时间的相对长度比起一个人已经度过的时间总是在不停地缩短。如果一年的长度也随着人的年龄增长的话，我们在新年倒计时中的感受大概会有更多的兴奋而非焦虑和不安吧。话说回来，就算没有光追显卡， 2018 年对我来说也很有趣。

The Amazing 2018

引用 2017 年的自己：

如果我有从过去那些我制定后没能执行的计划里得到任何经验的话，那就是定计划时最好稍微低估自己的能力...

是的，从我 2018 年目标的完成状态可以看出，一定是对空闲时间的估计上出了问题。嗯，一定是这样。

• ☒ 跑 1000 英里。[405/1000]
• ☒ 完成一次马拉松。
• ☒ 写 20 篇以上的日志。[10/20]
• ☒ 获得第一个 PGP 密匙签名。
• ☒ 安装 Gentoo。

由于使用 hugo ，我可以随时更改博客条目的“发布日期”，我养成了撰写文章开头后将其搁置好几个月的坏习惯。当我最后记得那篇未完成的文章时，我经常认为这个想法不值得详细写下去。现在想想，也许这正是博客的目的，它提供了我在某个时间点的快照，使得我可以回顾过去的自己，无论将来的我会觉得这是愚蠢的还是“不值得详细写下去”的。

我在 2018 年的电影院访问次数可能占我一生的总数的 50 ％，但平均失望程度却因为 星球大战：最后的绝地武士 和 超人总动员 2 而翻倍。 顺便一提，2018 年的爆米花消费量也达到了我一生总量的 90 ％。我从来没有意识到爆米花会如此令人上瘾。

尽管不是全程马拉松，但我在 5 月参加了第一次山地半程马拉松比赛。这是我第一次在跑步时感到体力不支，原因是配速不佳以及对天气的准备不足。比赛当天极其炎热，且比赛从下午开始。在目睹许多人在头 2 英里内停下来走路后，由于愚蠢的虚荣心作祟，我的初始速度比我预期的速度要快得多，并在 4 英里的时候不得不因为体力不支停下。所幸，在我走完接下来的一半赛程并在每个补给点大量补充佳得乐后，疲劳的感觉消失了。但是，我没想到那些佳得乐会是另一个陷阱，太阳落山的同时带着气温迅速下降，我的胃开始因为摄入太多冰冷的液体而开始抽搐。当终点线出现在距我视线 400 米以内的地方时，我的双腿受到了我有史以来最强烈的抽筋的打击。在距离终点一步之遥的地方连续被 3 个人超越之后，我终于勉强完成了比赛，但我很高兴得知自己还不是最后一名：实际上，我甚至是我这个（ 大概只有一个人完赛的 ）年龄组中的第一名。来的名不正言不顺的第一名带来的喜悦，混杂着一点点的不甘心和罪恶感，使那场比赛成为了一次奇妙的经历。

The Spectacular 2019

由于 Google 即将在 3 月淘汰 Inbox ，我失去了继续使用 Gmail 的最后借口。 我将逐渐淡化 Gmail 的使用，转向我自己的电子邮件服务器。

说到博客评论的最佳解决方案，我关注的许多博客作者已经开始采用 IndieWeb 和 Webmention 。在很多方面， Webmention 正是我想要的东西：它提供了分布式的博客评论、日志等等。 但是，我不愿舍弃静态站点的好处，更不用说我发现大多数易于遵循的 Webmention 解决方案都严重依赖第三方服务。 IndieWeb 运动倒是很吸引人。说起来我的 Keybase 除了作为一个联系我不同线上身份的枢纽外并没有太大用处（在线解密和加密功能需要上传 PGP 私钥才能使用，安全消息功能对与并没有什么人可以聊天的我更是派不上用场），也许我应该用 rel=me 链接来完全取代它。

去年学习 C++17 的体验非常令人享受，因此我正在考虑学习其他新的编程语言。我已经窥觎 Rust 和 Julia 一段时间了，尤其是 Rust 。拥有一整套官方支持的工具链使写 Rust 变得顺畅而愉快。我会尝试深入了解并实际使用这两种语言。

至于跑步和博客日志，我将尝试维持 2018 年的数字。除此之外，我考虑在博客上记录看_听_读过的书籍，音乐和节目，以及自己的想法。过去在本站的 Wordpress 时代，我有过类似的尝试：我搭建了一个 MediaWiki 实例来记录这些，但缺乏继续维护条目的动力。这次我会用一些更轻量的解决办法，并且构思一套评分系统。

我应该如何处理其余的 2018 年目标呢？单独的愿望清单是一个很好的主意。作为一个额外目标，我应该清理一下那台堆积了四年份灰尘、猫毛和死皮细胞的台式机。

为接下来的 2.9e+17 个铯 133 辐射周期干杯！

评论区

暂时没有评论。

我主要使用 Emacs 的方式是使用一个图形 emacsclient 窗口链接在后台运行的守护进程。 我所要解决的主要问题有三个：缺少精细控制字体映射的方法、字形宽度和字符宽度不一致、 emoji 时常显示为豆腐块。虽然终端 Emacs 不大受这些问题的影响，但我不想放弃图形 Emacs 的其他好处，例如系统剪贴板和更加丰富的键位选择，所以我只好迎难而上着手解决 这些问题。

使用字体集（ Fontset ）设置后备字体

在最理想的状况下，我想指定两套字体，一套默认的等宽字体和一套专门显示中日韩字符的字 体。我原来是这么设定 Emacs 字体的：

(setq default-frame-alist '((font . "Iosevka-13")))

这种方法显然无法指定后备字体。不过 font 除了接受单一字体外，也可以接受字体集。 根据 Emacs 手册 ，字体集可以大致理解为从 Unicode 到字体的映射，并且我可以很容易地 修改 字体集。

听上去似乎很容易？且慢。我并不知道应该被修改的是哪一个字体集： Emacs 最终使用的 字体集似乎会因语言环境（ locale ）、使用图形还是终端窗口、使用 emacsclient 还 是 emacs 而变化。尽管有方法可以获得目前使用的字体集（ (frame-parameter nil 'font) ），但这 并不完全可靠 。

在不少失败的尝试之后，我终于找到了 答案 ：直接定义一个新的字体集。

(defvar user/standard-fontset
  (create-fontset-from-fontset-spec standard-fontset-spec)
  "Standard fontset for user.")

;; Ensure user/standard-fontset gets used for new frames.
(add-to-list 'default-frame-alist (cons 'font user/standard-fontset))
(add-to-list 'initial-frame-alist (cons 'font user/standard-fontset))

由于我除了指定中日韩字体外还对字体集做了其他更改，我会在阐明所有改变后再贴出全部 设定。

显示 Emoji

解决 emoji 显示的方法与中日韩文字类似——找到一款支持 emoji 的字体不就好了吗——至少 我是这么想的。我一开始试图使用 Noto Color Emoji 作为 emoji 用后备字体，但发现 Emacs 目前并不支持彩色 emoji 字体。 Emacs 曾经在 macOS 上支持彩色 emoji 字体，但 后来 移除 了。

我最后选择了 Symbola 作为 emoji 后备字体（事实上我把它设为了所有 Unicode 字符的 后备字体）。 Symbola 可以显示 所有 emoji 和许多特殊符号。还需要注意的一点是，在 Emacs 25 之后，要想在字体集中自定义包含了大部分标点、特殊符号、 emoji 的 symbols 字符集（ charset ），需要 一些额外的设置：

(setq use-default-font-for-symbols nil)

如果实在想要显示彩色 emoji 倒也不是完全没有办法，不过不是通过设置字体，而是将 Unicode 字符替换为图片。emacs-emojify 就是一个提供这种功能的 Emacs 包。由于这 个包会给 Emacs 带来一定的延迟，而且大部分彩色 emoji 图片库并不完整，我最终决定不 予采用。

引号风波

我一直习惯在书写中文时使用成对的全角弯引号（““””和“‘’”）以及在书写英文时 使用 ASCII 里的对称直引号（“"”和“'”）。然而我并不知道“全角弯引号”其实根本 不存在： Unicode 中只存在一组弯引号编码（ U+2018 、 U+2019 、 U+201C 、U+201D ）， 而所谓的全角与半角弯引号之分完全是字体引起的。虽然已经有相关的 提案 建议将这两种 不同的表示方法标准化，但目前弯引号就是这么一个烂摊子。

了解来龙去脉之后，就不难理解为什么弯引号在 Emacs 里隶属 symbol 字符集而非某个 中日韩字符集了。这也导致这些弯引号会使用我的默认等宽字体并显示为半角字符。我并没 有从根本上解决这一问题的办法，所以为了保证显示风格和书写风格保持一致，我通过为特 定的 Unicode 编码指定字体将这些弯引号字符统一显示为全角。当我知道直引号其实也有 着 充满误会的过去 的时候，我已经不知道应该用什么表情来面对了——也许我们在这方面真 的很糟糕。

我的后备字体设置可以在 GitHub 和 川陀全息档案馆 上找到。为了日志的完整性，我在这里也放 一份：

(defvar user/cjk-font "Noto Sans CJK SC"
  "Default font for CJK characters.")

(defvar user/latin-font "Iosevka Term"
  "Default font for Latin characters.")

(defvar user/unicode-font "Symbola"
  "Default font for Unicode characters, including emojis.")

(defvar user/font-size 17
  "Default font size in px.")

(defun user/set-font ()
  "Set Unicode, Latin and CJK font for user/standard-fontset."
  ;; Unicode font.
  (set-fontset-font user/standard-fontset 'unicode
                    (font-spec :family user/unicode-font)
                    nil 'prepend)
  ;; Latin font.
  ;; Only specify size here to allow text-scale-adjust work on other fonts.
  (set-fontset-font user/standard-fontset 'latin
                    (font-spec :family user/latin-font :size user/font-size)
                    nil 'prepend)
  ;; CJK font.
  (dolist (charset '(kana han cjk-misc hangul kanbun bopomofo))
    (set-fontset-font user/standard-fontset charset
                      (font-spec :family user/cjk-font)
                      nil 'prepend))
  ;; Special settings for certain CJK puncuation marks.
  ;; These are full-width characters but by default uses half-width glyphs.
  (dolist (charset '((#x2018 . #x2019)    ;; Curly single quotes "‘’"
                     (#x201c . #x201d)))  ;; Curly double quotes "“”"
    (set-fontset-font user/standard-fontset charset
                      (font-spec :family user/cjk-font)
                      nil 'prepend)))

;; Apply changes.
(user/set-font)
;; For emacsclient.
(add-hook 'before-make-frame-hook #'user/set-font)

中日韩字体大小比例

最后需要解决的问题就是中日韩字体字宽和等宽字体比例不一致的问题了。理论上全角的中 日韩字符应该是半角字符宽度的两倍，但这并不在所有字号下成立。看起来原因是中日韩字 体在字号上其实偷懒了：在使用 Noto Sans CJK SC 时， 16px 和 17px 大小的中日韩字符 是没有任何大小区别的，直到 18px 才会出现大一号的字形，不像拉丁字符始终表现出预期 的尺寸增幅。这一现象使得中日韩字符和拉丁字符在每隔数个字号后大小比例相称，但使用 夹在中间的字号时中日韩字符会略微偏小。

一种解决方式时在修改字体集时给中日韩字体设置一个稍大一些的默认字号。不过这会导致 text-scale-adjust （通常被绑定在 C-x C-= 和 C-x C-- 上）对中日韩字体不生效。 一种更好的办法是修改 face-font-rescale-alist 设置缩放比例：

(defvar user/cjk-font "Noto Sans CJK SC"
  "Default font for CJK characters.")

(defvar user/font-size 17
  "Default font size in px.")

(defvar user/cjk-font-scale
  '((16 . 1.0)
    (17 . 1.1)
    (18 . 1.0))
  "Scaling factor to use for cjk font of given size.")

;; Specify scaling factor for CJK font.
(setq face-font-rescale-alist
      (list (cons user/cjk-font
                  (cdr (assoc user/font-size user/cjk-font-scale)))))

虽然在使用 text-scale-adjust 后字体大小比例依然可能会乱掉，但我只要默认字号下 对齐就行。具体的缩放比例只能通过反复测试来确定。我用以下几行字符是否对齐来判断缩 放比例是否合适（这张 表格 会是很好的帮手）：

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云云
雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲雲
ㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞㄞ
ああああああああああああああああああああああああああああああああああああああああ
가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가가

不巧的是，我所使用中日韩字体的谚文比其他全角字符都要窄，所以最终结果仍不完美——解 决方案是再添加一个谚文专用的字体和缩放比例——不过对我来说够用了。

我在解决这些看似简单的问题上花的精力比想象的多不少，不过值得庆幸的是 Emacs 提供 了所需的各项工具。顺便一提， Emacs Wiki 上的 这篇文章 也提供了一些类似的问题的解 决方案：要是我早一些看到，配置过程大概会顺利许多。

评论区

施工计划

• ☑ 找一家新的服务器提供商 目前使用 DigitalOcean 。
• ☑ 在服务器上安装 Arch Linux 。
• ☑ 搜寻 WP 的替代品。 Hugo 很不错。
• ☑ 找一个合适的主题。 目前使用 hugo-xmin ，考虑 fork 出来写成自己的主题（ soresu ）。
• ☑ 完成服务器端设置，比如添加 post-receive 来实现 git 自动部署。
• ☑ 可以切换 当前页面 语言版本的语言切换按钮。
• ☑ Disqus 支持。
• ☑ 用 MathJax KaTeX 实现 \(\LaTeX\) 表达式支持。
• ☑ 把导航页的内容搬过来并翻译。
• ☑ https 支持。
• ☑ 备份原 WP 站点。
• ☑ 转移域名到 Google Domains ，并完成 DNS 设置。
• ☑ 尝试使用 org-mode 或者 R markdown 来写博客。
• ☑ 解决 emacs 不兼容 fcitx 的问题。
• ☑ 设置多语言支持，添加合适的翻译字符串。
• ☑ 使用 Google 的 Noto Sans 字体（拉丁字母使用 Oxygen Sans ），代码则使用 Source Code Pro Iosevka 。
• ☑ 为站点和社交网站找一个合适的图标/头像。
• ☑ 改善文章页面模板使其显示标签和分类。
• ☑ 改善网站外观，比如隐藏超链接的下划线等。
• ☑ 架设自己的邮箱。
• ☑ 解决 org-mode 和 hugo 略不兼容的地方，比如代码高亮。
• ☑ 尝试把 hugo new 变得更有用一些，比如直接创建多语言版本等。
• ☑ 抛弃 Disqus 自己搭建评论系统。
• ☑ 使用 Let's Encrypt 的通配符证书。
• ☑ 把比较有价值的旧文章搬过来。

现在主页上是啥？

大部分我觉得别人会感兴趣的有关我的信息都可以在关于或联系方式页面里找到，所以对于主页应该放些什么，我实在没啥好主意。由于我感觉之前的站点施工计划是个提醒自己的不错方式，我会用另外一个任务清单来取代以完成的施工计划：我在 2018 年想实现的目标。我绝对不是那种最有干劲的人，但每每看到一张未完成的任务清单，我的强迫症神经还是会跳一跳的。那么，就让我试试看这么做效果如何吧。

评论区

暂时没有评论。

入门

我在 2014 年入手了第一块机械键盘，使用 Cherry MX 青轴的 WASD v2 104 键键盘。我选了 WASD 的主要原因是他们键盘较为简约的外形和客制化键帽的服务。我在 2014 年还入手了第一块 60% 键盘，使用 Cherry MX 茶轴的 Poker II 。在那时候可能由于 Cherry 的专利尚未过期，所以键盘轴的选择要比现在少得多。当然如果不考虑 Cherry MX 兼容性，替代品还是有的（ Matias ， Topre ， IBM 弹簧轴等），但入手更加困难。

我最初的主力是一块我七拼八凑起来的基于 GH60 的 60% 键盘。我使用的键盘轴是改装了 62 克弹簧的 Cherry MX 白轴（ ErgoClear ），这更多的只是想尝试键盘轴改装而不是因为偏好。除此之外，我发觉自己比之前用 Poker II 的时候更经常修改键盘布局了。虽然 Poker II 自带的宏编辑功能听上去很棒，但复杂的步骤使得我从来没有在不看说明书的情况下成功完成过编辑。而就算我废了老大力气完成了宏的设定，我过一段时间就会把宏的存在抛在脑后。相比之下，编辑 GH60 的固件后，至少我还能查看设定文件来回忆自己的设定。我早期修改键盘布局的尝试并不太成功：在我看来， 60% 键盘的键位布局太标准了，以至于（在保持 QWERTY 布局下）任何大范围修改都会让人觉得别扭。举个例子：我完全没法找到第二个适合回车键的位置。我所作的布局修改大多只是数字小键盘和功能键的映射以及交换大写锁定和控制键，完全没发挥出 GH60 的潜能，充其量只不过和使用了 xkb 的普通键盘旗鼓相当。

顺便一提，我曾经想过要收集所有键数布局的键盘，但很快的发现这是一个不切实际且烧钱的想法。目前为止在常见的键数布局中，我尝试过 104 键， 96 键， 87 键， 75 键， 60 键，和 40 键键盘。这当中的绝大多数对我来说在体验上并没有太大区别，除了 60% 或 40% ：要想把所有标准键放上去是需要动一番脑筋的。

ErgoDox 和 Planck

ErgoDox 是第一个促使我真正下心思选择键盘布局的键盘。正是由于布局和传统键盘相差甚远， Ergodox 在键位布局选择上提供了很高的自由度：我一眼就能找到七个适合回车键的位置（传统右侧小拇指位，拇指区的四个 2u 键位，以及中心偏下的两个 1.5u 键位）。从 2015 开始，我就几乎只使用 ErgoDox 了。 ErgoDox 的好处在我开始使用 Emacs 后更加明显：能够轻而易举地够到控制键和转换键的感觉非常棒。

ErgoDox 还有很多潜力没有被我发掘出来。如你所见，我还没有想出拇指区部分键位的最佳用处。目前除了基本层外，我额外设置了三层键位布局：一层用于功能键，一层用于数字小键盘，最后一层是经过修改的 Dvorak 布局。我还没有在 Dvorak 层上花太多时间，不过我对 Dvorak 减少手指移动次数的功效很有兴趣。说到人体工学， ErgoDox 设计有个额外的好处：我书桌的正中央终于可以从键盘的统治下空出来了，就算没有一张超级深的桌子我也可以不受键盘干扰正常看书。

Planck 是另一块让我下心思设计布局的键盘。 40% 键盘所能塞下来的东西其实多的让人吃惊。但是使用 Planck 时的舒适性不可避免地被它的尺寸所妨碍了 - 相比之下，使用 ErgoDox 这种分体键盘时两手可以保持更为自然的姿势，而不是以奇怪的角度挤在一起。我觉得 Let's Split - 基本上就是分体版的 Planck - 会是个不错的选择。

键帽狂热期

在我发现了 Geekhack 论坛后，我在很长一段时间里都会疯狂刷新团购和兴趣调查版，以收集其他用户所设计的客制键帽情报。我发现自己的兴趣逐渐地从色彩对比强烈的配色转向了更为统一，柔和的设计。在键帽形状的选择上，我也偏好没有高低梯度的类型，比如 DSA 。键帽图样上我更喜欢文字而非图案，有意思的是我并不觉得空白键帽有多么值得欣赏。这些癖好使得我的寻找键帽之旅异常困难：要想给 ErgoDox 配齐一整套图样相称的键帽可不是什么容易的事（ Planck 因为全是 1u 键，所以要容易得多）。

设计自己的键盘／布局

我有时会冒出设计自己的键盘的念头。 ErgoDox 已经很接近我理想中的键盘了，但是它还 是有点笨重，而且拇指区边缘的键比较难按到。我原先一直在 Emacs 里使用 C-Home 和 C-End 来移动光标到文件开头／结尾，这两个键位组合使我不得不尽力伸展大拇指，导致 关节有些酸痛（直到我发现 M-< 和 M-> 才是正确的打开方式）。一个更加小巧，拇指区键位更加紧凑的 ErgoDox 应该就是我眼中完美的键盘了。对了，虽然我以前从来没有觉得无线键盘有多么必要，但因为 ErgoDox 的分体式设计，如果它有无线版本，我就可以像使用任天堂 Switch 那样躺在床上打字了。

自从我开始使用 Emacs 作为主力文本编辑器，我就一直在使用 keyfreq 来记录每个键／组合键的使用频率。在我收集了足够多的数据后，我会以此为根据来调整我的键盘布局。

键盘像素画

我之前跟风 Geekhack 众，也给我的键盘画了像素画作为签名。

给键盘画像素画其实挺有意思，要想保持精确的比例几乎是不可能的，这就需要在精准和简约之间作微妙的平衡。我有时间时会继续更新这些像素画的。

评论区

暂时没有评论。