最近的一个创造-又开车了

过了而立之年,很多事情会不期而遇,无论好的还是坏的,有准备的还是意料之外的,不一而足。有人说,哪有什么岁月静好,唯有负重前行罢了。

一个人有一两项长期的兴趣爱好是非常重要的。有时候,实在累了的时候,驻足看看自己的爱好,如同一道希望之光,给你难以言说的温暖与慰藉。而我,作为一个喜欢驾驶的老司机,除了美剧,工作之余也会跟一些自媒体汽车节目,关注汽车本身,也关注汽车相关的文化和生活。

但是,当前的汽车自媒体平台比较分散,并且每个平台都有自己的APP,推送消息也非常不克制,这就导致要订阅这些内容变成了一个非常繁琐,还经常被推送消息打扰的事情。于是有了又开车了微信服务号这个创造:

  • 在微信中聚合你的汽车自媒体订阅,免去安装各个平台的APP,来回切换内容查找的烦恼。
  • 当你订阅的汽车自媒体有内容更新的时候,你会收到一个微信消息提醒,除此之外没有其他任何推送打扰。
  • 支持订阅历史管理,历史内容一目了然。
  • 当前接入了1000+的自媒体频道,喜欢开车的你也许能在这里发现更多精彩的内容。

生活需要仪式感,在这个逐渐被奶头乐所占据的时代,希望你无论多么忙碌都能时不时抬头看看自己一直以来的兴趣,看看那不经意间的希望之光。如果你有跟我类似的兴趣爱好,欢迎关注我的微信服务号:

Go 1.12 TLS 1.3 简单测试

《TLS 1.3 当前(2018.10)支持与部署之现状》中,我们提到 Go 将在 1.12 中支持 TLS 1.3. 作为一个 Gopher, 终于在前几天盼来了 golang 1.12 的发布。

但是从 release 日志看,本次对选择性的部分支持 TLS 1.3, 且默认处于关闭状态:

Go 1.12 adds opt-in support for TLS 1.3 in the crypto/tls package as specified by RFC 8446. It can be enabled by adding the value tls13=1 to the GODEBUG environment variable. It will be enabled by default in Go 1.13.

如果要开启 TLS 1.3, 需要设置环境变量:GODEBUG=tls13=1.

本次发布的 TLS 1.3 的 cipher suite 无法配置,也不支持 0-RTT 模式:

TLS 1.3 cipher suites are not configurable. All supported cipher suites are safe, and if PreferServerCipherSuites is set in Config the preference order is based on the available hardware.

Early data (also called “0-RTT mode”) is not currently supported as a client or server.

要知道,没有 0-RTT 的 TLS 1.3 是没有灵魂的,对本次版本的失望那是肯定的。但是依然在第一时间升级了 Go 版本,简单测试了一下国内网络环境下 TLS 1.3 与 1.2 的握手延迟。如果对 TLS 1.3 握手延迟还不太熟悉,可以参见拙文《TLS1.3/QUIC 是怎样做到 0-RTT 的》 以及 TLS 1.3 Handshake Protocol.

测试代码

需要说明的是,这个测试是不严谨,里面没有考虑 cipher suite 以及 early data 的差异。测试结果定性意义大于定量意义。

测试结果

测试使用的目标服务器地址是 blog.cloudflare.com:443, 我的网络环境下,ping 延迟为 226 ms (1-RTT).

从结果看,有如下结论:

  1. TLS 1.3 平均比 TLS 1.2 建立连接的延迟低约 1-RTT, 跟理论分析是吻合的。但是,
  2. 从 max 项可以看出,部分时候国内到目标服务器网络不稳定带来的波动比 TLS 本身协议优化的 RTT 大的多。因此,稳定高延迟的网络链路有时候比低延迟高抖动的网络更有实际意义。
  3. TLS 建立在 TCP 基础上,TCP 的握手延迟在 TLS 层面是优化不掉的,或者说不是 TLS 的管辖范围,因此,在允许的情况下,尽量复用连接。

一个适合程序员的 Markdown 文档编辑和文档管理方案

我是一个重度的 Markdown 用户。长时间使用过 Day OneUlysses、MacDown,如你所料,最终都放弃了。

坦率讲,Day One 和 Ulysses 是你一打开就会觉得非常惊艳的产品,设计上侧重写作者的主观感受和体验,在细节的打磨上非常到位。但是 Day One 的代码质量实在一般,很多闪退 bug 经常把你的写作热情消灭得荡然无存,且没有一个像样的文档管理功能。Ulysses 虽然有文档管理功能,UI 更加惊艳,尤其是沉浸模式非常吸引人,让你觉得在使用艺术品写作,当然,也会让你产生使用它写作能够提高写作质量的错觉? 不过,Ulysses 的文档管理和编辑设定更偏向于普通小白用户。这个本身是没有问题的,因为它的定位是让你享受写作,尽可能少的减少其他方面对用户的打扰。显然,作为一个经常需要从源代码级别去修改文档的用户来说,它的这种好意被我当成了一种功能的羸弱。

在很长一段时间内都没有找到满意的 Markdown 软件。于是,索性用回了只有简单编辑功能的 MacDown,同时也在摸索和完善适合自己使用习惯的 Markdown 文档管理和编辑方案。我理想中的 Makrdown 文档管理方案是这样的:

  1. 源代码级的 Markdown 文档编辑能力;不看重所见即所得的功能,且不能接受只提供所见即所得的编辑能力;
  2. 符合开发人员习惯的文档管理能力,像管理源代码一样管理我的 Markdown 文档,随时查找、编辑。
  3. 如果能够支持文档历史版本管理就更棒了。
  4. 成本不要太高,最好是免费的。

不卖关子,先说当前自己用下来比较舒服的方案:Visual Studio Code + Markdown Shortcuts + markdownlint + Bitbucket, 满足自己以上的所有需求,且成本为 0 .

选择 Visual Studio Code 作为编辑器是因为可以把自己写代码的那套文件查找和管理习惯继承过来,并且不需要重新学习和熟悉快捷键。 VS Code 本身支持 Markdown 文档编辑和预览,遗憾的是它的这两个功能都不强大,达不到自己快糙猛的要求。预览功能自己并不看重,因此选择性安装了两个插件(Markdown Shortcuts + markdownlint)来增强其编辑功能。

Markdown Shortcuts 提供了很多编辑 Makrdown 文档的风骚快捷键。我自己常用的有:

  • 快速转换成列表:

  • excel 表数据转表格:

其他命令如下:



markdownlint 则是一个语法检查 lint 工具。虽然 Markdown 语法很简单,但是因为经常编辑源代码和插入 html 代码,有一个 lint 还是能够辅助你提前发现很多 typos.

得益于 VS Code 强大而丰富的插件生态,Markdown 周边的各种功能都能通过这些插件解决,只有你想不到,没有插件没做到的。比如,如果你想导出文档为 PDF,你可以尝试 Markdown PDF; 如果你是数据公式重度用户,你可以使用 Markdown+Math
.

Bitbucket 则是用 git 来做文档的历史版本管理,免费,且支持私有仓库。如此一来,基本上编辑 Makrdown 与编写项目代码的有了相同的使用体验。

小结

习惯这东西本身就是个性化化的东西,并且一旦适应了就很难改变。以上方案只是一个我自己比较舒服的使用习惯。这个方案并不完美,比如它并没有考虑 Markdown 重度图片用户插图的效率问题。另一方面,Evernote 大陆版发布的新版本已经开始支持 Markdown 文档功能(国际版不支持哟)。如果,你是印象笔记的铁粉,不妨一试。