行路頭低低

这里并不是 blog

blog 是 log

blog 是 web log 的简写。 不管是原形,还是简写,都有 log 一词。 顾名思义, blog 还是适合 log 性质的东西。

比如:

在乌镇「互联网之光」的展厅里逛到乐视的展台, 居然真看到一辆自行车。 我一边感叹我实在不明白乐视为什么连自行车都做, 一边忍不住想骑上去试试。 未遂,因为右边那个脚蹬子已经不知所踪。

王兴

再比如:

昨天数据库遇到了一个 X 问题, 损失了 Y 时间段内的 Z 数据。 A-F 功能不受影响。 R 时刻监测系统报告了问题后, 我们进行了如下排查,… 定位到是 S 造成了 X 问题。 我们使用 T 修正了问题, 同时尝试通过 I-K 恢复数据, 分别取得了如下效果,… 但 Y 时间段内的 Z 数据还是丢失了。 这个事故暴露了我们系统中的 O-Q 缺陷, 我们将采取 U-V 措施避免以后出现同类事故。

– 莫须有应用

被滥用的 blog

别忘了滥用的代价

滥用无罪。 但滥用基本上总是有代价的。

比如,HTTP 的 GET 方法可以滥用为 POST, 只要把 POST 的内容编码进请求的 url 就可以了。 看起来效果不错,服务端可以偷懒,只实现 GET 方法,不用实现 POST 方法了。 但是 GET 是为「读」设计的,滥用 GET 来「写」当然有代价。 很容易想到的代价是可能超过 url 的长度限制, 缓存、代理可能出问题。

同样,滥用 blog 来承载非 log 性质的内容, 可能让人忽视以下代价:

  1. 内容可能和代码一样,是需要维护的
  2. 内容可能和 log 不一样,按时间排序并不是最佳选择

发到 blog 上并不能改变内容的性质

甲月乙日,我配置了一台服务器,事后把流程记录下来,发到 blog 上。

丙月丁日,我学习了如何使用 GitHub, 同样把学习所得发到 blog 上。

某年某月某日,我记录了我做了什么事,这不就是 log 么?

那可不一定。

如果是这样的:

丙月丁日,学习如何使用 GitHub.

这是 log. 实际上没有 blog 的年代,日记就是这么写的。

当然,有时候日记不是这么干巴巴的:

昨天我发现 GitHub 开放注册了。

其实以前 M 曾问过需不需要 GitHub 的邀请, 我不怎么感冒。 Gitorious 不需要邀请就能注册,整个平台也是开源的, 我用 Gitorious 用得好好的, 既然 GitHub 想控制新用户增长的速度, 我又何苦去凑这个热闹呢?

现在既然 GitHub 开放注册了, 而且我看到 X、Y、Z 项目的仓库都放在 GitHub 上, 那我也去注册一个账户吧。

这同样也是 log.

但下面的并不是 log:

首先,在本地建立一个 git 仓库:

(一些命令)

接着,生成 ssh 密钥:

(一些命令)

在 GitHub web 界面粘贴刚刚生成的公钥:

(下略)

这其实是文档、说明书、手册、小抄,而不是 log. 把这样的东西发到 blog 上,并不意味着它就不需要维护了。

比如:

即使一些比较「虚」的内容,看上去属于「感想」性质的内容, 也不一定就属于 log 了,

比如一篇题为「我看 Java 和 PHP」的「blog」, 假如里面写到了 lambda 和类型标注, 那么 Java 8 引入了 lambda, PHP 7 引入了函数参数和返回值的类型标注, 相应的这篇「blog」就需要更新。 这个维护工作是逃不掉的。 即使当初严谨一点,把题目改成「我看 Java 7 和 PHP 5.5」,也逃不掉的。 要不要升到 Java 8 或者 PHP 7? 如果升级,是不是坚持不用新特性? 如果不能避免升级,不能避免使用新特性,那就不能避免维护这篇「blog」. 所以,很明显,其实这篇并不是「blog」.

当然了,也可以另起炉灶,重新写一篇。 实际上,很多「blog」就是这样「维护」的。 原本的内容已经过时了,没有人维护。 于是被其他人重新写的「blog」代替了。 这也算是一种「维护」, 可这种「维护」方式不太合理:

  1. 老的内容流传广泛,可能比新内容更容易找到,也许读者会被其中过时的内容误导。
  2. 每过一段时间就另起炉灶是一种浪费。

自然语言和程序一样是写给人看的

很多人头脑里清晰的程序设计原则,一遇到“写脚本”这样的任务就完全崩溃了似的, 他们仿佛认为写脚本就是应该“松散”一些。 很多平时写非常聪明的程序的人, 到了需要处理“系统管理”任务的时候,就开始写一些 shell 脚本,或者 Perl 脚本。 他们写这些脚本的时候,往往完全的忘记了程序设计的基本原则, 例如“模块化”,“抽象”等等。

王垠

滥用 blog 的问题是类似的。 日记松散一点很正常, 可是把不是 log 的内容当成 blog, 就容易写出不容易维护的东西。

自然语言往往不如程序语言精确,但程序设计的很多原则一样适用。

想象一下这样一个项目:

  1. 代码不是按模块划分的,全部代码文件都挤在一个目录下,按编写的先后顺序排列
  2. 有些文件有一些标签,但项目并不提供组合搜索标签的功能,只能按单个标签查看
  3. 代码的修改没有记录,有时作者会在文件里记录一下
  4. 代码的修改不是靠补丁,而是靠线性排列的「评论」,由作者手工合并
  5. 过了一段时间后,无法提交「评论」了

显而易见,这样的项目是不好维护的。

然而很多 blog 系统就是这样的项目。 当然,这些 blog 系统用来处理 log 性质的内容并没有什么大问题。 但是当这样的 blog 系统被滥用来承载非 log 的内容时,就可能带来各种麻烦。

回到上文提到的例子:

甲月乙日,我配置了一台服务器,事后把流程记录下来,发到 blog 上。

丙月丁日,我学习了如何使用 GitHub, 同样把所学发到 blog 上。

如果里面都涉及到生成 ssh 密钥, 那我完全可以把这部分内容抽出来,单写一篇, 让另外两篇引用它。 以后再有别的文档涉及到生成 ssh 密钥,我都可以直接引用。 如果打算把生成的算法从 rsa 改成 ed25519, 也只需要改动一处。 这些和编程的原则是一模一样的。

其实,编程时常常是直接引用第三方的库。 同理,如果我找到一篇很好的生成 ssh 密钥的文档,我完全可以直接引用,不必自己写。 当然,编程中相反的情况也是有的,有时候不想因为一个小函数引入第三方依赖,就自己写。 同样地,有的时候内容不长,为了文档的完整性,避免阅读时太多跳转,也可以自己写。

类似地:

总结

  1. blog 系统还是适合放 log 性质的内容。
  2. 需要维护的内容总是需要维护的,发到 blog 上并不能避免维护。
  3. 编程的经验一样可以应用于自然语言,降低维护的成本。