不知道有没有人注意到，Joe Armstrong 最近几个月都在忙着迁移博客到 TiddlyWiki。我很早就关注了他的 Twitter，然而之前并没多想。听闻大师在 4 月 20 号去世，我才反应过来，原来他之前的举动是在未雨绸缪。

TiddlyWiki 是个单文件的 Wiki 系统，但这并不重要。重要的是，你把信息存在哪？如果你希望存储一段信息，让 100 年后的人也能访问，要怎么做？

• Facebook, Twitter, 微博？不要说 100 年，我都怀疑 20 年后它们还在不在；
• Google Cloud, Amazon, 阿里云 + 个人域名？他们大概会存在地更久一些。但没有人能保证不出事故，比如之前的腾讯云事件，比如万一服务器被入侵，黑客把文件删了。还有，你怎么让信息能一直被访问？域名会过期。到某个时候，跑着旧版本操作系统的机器也可能被强制下线或升级，你的服务一定能够在新版本正常运行吗？
• Dropbox, Google Drive, 百度网盘。同样地，这就要看你信不信这些公司一百年后还存在了，哦不对，他们即使还在，服务也可能早关了(望向 Google
• Wiki。Wiki 很好，但并不适合存储个人信息，且可能被删改。
• 去中心化存储，比如区块链。说实话，我对区块链了解有限，但直觉上，我怀疑它能否帮助我们达成目标。对比另一个去中心化的例子：BT。当你要下一些老动画或者电影的时候，拖不下来是常事，因为"死种"了。这才几年呢。当然或许区块链有某种神奇的魔法可以解决这个问题？欢迎了解的朋友们补充。

所以，我们还有什么选择？想来想去，也只有 GitHub 了。

GitHub 已经成为互联网最重要的基础设施之一，有太多人，太多事都直接或间接地依赖于 GitHub，除非人类在未来完全不需要开源代码(这显然不可能)，否则我想不出 GitHub 有关闭的可能。对 GitHub 来说，存在 100 年简直是小意思，500 年也不是不可能。这是我的预言，不一定准确，但我还挺有信心的。

不管怎么说，对我们的目标 100 年来说，GitHub 完全可以胜任。除了服务本身的持久性，GitHub 还有两个独特优势：

• Git。Git 能保存所有历史。
• Fork。就算黑客黑进了一个账户，删掉 repo，他能把所有 fork 都删干净吗？

综上所述，目前来看，我认为 GitHub 是在百年尺度上存储信息并让其能被访问的唯一途径。未来也许会有 option 2, option 3 出现，但 GitHub 作为 option 1 依然会存在。我相信，Joe 用 GitHub 来 host 博客绝不是突发奇想，他一定是在了解自己的身体状况的前提下，思考了一遍现存所有存储方式，然后同样发现只有 GitHub 才能满足需求。

人总想留下某种痕迹，证明自己活过，然而事实上，99.999% 的普通人就这么被历史遗忘了——曾经是这样。我们处在信息时代的早期，同样也处在人类文明的早期。从今往后，被数字化的东西只会越来越多。既然有人意识到了 GitHub 的独特性，随着时间推移，越来越多的人总会意识到。那时候会发生什么？自然是，越来越多的人会把自己的信息搬到 GitHub 上，依托 GitHub 实现曾经人们可望而不可及的"永生"。人有两次死亡，第一次是肉体，第二次是被人忘记。我忘记这句话是谁说的了，但现在我们已经可以回避第二次。只要 GitHub 支持，就一定会有人这么做，至少我是其中之一。几十几百年后，GitHub 将成为世界上最大的数字公墓，注册用户大部分都已去世，然而个人主页，项目，commit 历史 还述说着他们生前做过的事——就比如 Joe 的博客。这虽然是个比较 creepy 的推论，但从另一个角度想，却证明了人类的巨大进步：对抗死亡是人类文明的永恒主题，而我们已经实现了阶段性胜利。现在是文章、照片、视频，也许还有以个人习惯作为输入训练的模型。再往后呢？会不会有基因信息，乃至意识的完整复制呢？依托于稳定的存储，我们能做的事情实在太多了。反例是现在的一些 Memorial Websites，他们把逝者的信息放在自己网站上供亲友吊唁。这不能说没用，但在我看来去使用这类服务实在有些草率——就算他们再信誓旦旦，也摆脱不了某一天关站的风险，那时候还指望他们好好管理这些数据？没可能的。

既然 GitHub 变成数字公墓是一种必然，我对他们的唯一希望，就是保持某种道德义务。我完全可以想象某一天他们出台一个政策，把二十年内没有活动迹象的账户全部 archive，GitHub Pages 全部下线。那就实在太恐怖了。我祈祷那一天不会到来。

许多漫画都能让我大呼过瘾或是沉浸在剧情中无法自拔。相对而言，能触动我的同人本不多，毕竟篇幅和剧情你们都懂，最多也就感叹一句画风真还原或者这 TM 都可以。

然而前几天我看了一本丧女同人，第二天又看了一遍。我想我要写一篇文章。

本子的名字叫《大学生だしルームシェアする》，作者是 sanada。

不夸张地说，这是近几年我看过最好的一部同人。我真的被打动了。

这部作品牛逼在，作者基于对角色的深刻理解脑洞了一些角色之间的互动，其大胆又合理的想象甚至让我觉得可以直接作为原作后传，而且几乎每一页都可以让读过原作的人笑出声。

作品讲述的是临近高中毕业，黑木开始思考以后是要自己租房还是跟人合租。然后就是后宫团成员们纷至沓来，每个人都脑补出了和小丧一起租房的场景。选几页有代表性的图吧。

上图是百合和小丧一起租房的场景。小丧和优打电话，然后百合果断吃醋。

面无表情找小丧一起睡的百合，awsl

接下来出场的是加藤。

作者对加藤妈妈的刻画实在太绝了，后面百合和尼姆的眼神我看一次笑一次。她还画过一个的小丧 x 加藤的本子，也非常赞。

颜文字和尼姆的图就不放了。漫画的每一页都很有意思，每一页。

然后就是让我决定写下这些文字的一幅图：

Y-Yuri-chan, I…

When I'm with you…

I can have fun being myself.

这个理解，真的太太太太太强了，除了牛逼我想不出别的形容词。因为我自己是站百合的，所以我很清楚小丧和百合的相处模式和与其它人不一样。但直到看到 sanada 借小丧之口说出的台词，我才真正明白了区别所在。我可以肯定 sanada 也是站百合的。她对角色的理解的深刻程度，可以说达到了 EVA Re-Take 的级别。

同人本是一类特殊的作品，要从中获得愉悦是有门槛的，因为它要求读者对原作熟悉并喜爱到一定程度。类比一下，就好像只有天才们才能体会到数学的美。我恰巧超级喜欢丧女的原作，这也是为什么我会被本作深深打动。没读过原作或是对原作无感的朋友，很遗憾，你们错过了一份珍贵的礼物。

• 没有及时删掉不再使用的代码
• 单元测试真的不靠谱

最近我负责维护的一套系统出了不少问题。痛定思痛，决定总结一下。

根本原因有两个。

没有及时删掉不再使用的代码

在最近的重构中，我重写了一部分功能，导致原来的一些代码成了幽灵代码。问题源自一个 getter，它返回一个类的属性。这个属性在旧逻辑中一定会被设置，但新逻辑中不会。因为需要删除的代码很多，我在重构时加了不少 TODO，想的是等测试没问题了再一起删掉。然后就出问题了。一块我没注意到的代码调用了这个 getter，并且依赖它的返回值进行一系列判断，由于拿不到正确的值，这部分功能直接挂了。

这给了我一个教训：删除幽灵代码是实现新功能以及重构的必要工作，而不是后续。不仅仅是要最终删掉，还要删得及时。想把代码多留一会是程序员的本能，“万一有用呢”。我们必须去对抗这种本能。

单元测试真的不靠谱

按理说有测试，前面那个问题应该能发现。但实际上并没有。单元测试里该 mock 的东西都被 mock 掉了，包括那个不应该继续存在的属性，导致测试 false positive.

从本质上来说，单元测试之所以不能发现所有问题，是因为程序有无穷多的输入和内部状态，而单元测试只能检测其中一部分，即使代码测试覆盖率达到了 100%。依赖别的组件的测试又往往需要 mock，一旦实际运行状态和 mock 不符，等于什么也没测。因此测试不挂说明不了任何问题。

一般而言，集成测试（integration test）是单元测试的良好补充。然而这套系统是一个 streaming system，数据来源又多，想搞集成测试是真的难，我并没有足够的时间来做这件事。这种情况下，能做的也只有起一个测试环境，手动测试。其实重构后的代码在测试环境里也跑了几天，但我恰恰没去测试那个功能。以前看见 QA 们照着文档一遍遍重复相同的操作，觉得真繁琐，现在想来，这种繁琐和机械化是不可或缺的。

类似的，另外一个 bug 也是因为测试里输入设置得不对，并且最后没有实际验证。

话说回来，如果有无限时间，那么我们完全可以把整套运行逻辑都想得很清楚，检查每一个单元测试是否需要更新，这样所有的问题都可以避免。然而人不是机器，一定会有注意不到事，并且我们也没有无限的时间。因此我们只能尽量运用一些“原则”，去减小犯错的可能或是提早发现错误。

要学的东西果然还有很多啊。