阅读视图

发现新文章,点击刷新页面。

CKB new script verification with VM pause

CKB 相关技术文章第三篇。

背景

CKB 的每一个交易在提交到交易池之前都会经过一个 script verification 的过程,本质上就是通过 CKB-VM 把交易里的 script 跑一遍,如果失败了则直接 reject,如果通过了才会继续后面的流程。

这里的 script 就是一种可以在链上执行的二进制可执行文件,也可以称之为 CKB 上的合约。它是图灵完备的,我们通常可以通过 C、Rust 来实现这些 script,比如 nervosnetwork/ckb-system-scripts 就是 CKB 上的一些常用的系统合约。用户在发起交易的时候就设置好相关的 script,比如 lock script 是用来作为资产才所有权的鉴定,而 type script 通常用来定义 cell 转换的条件,比如发行一个 User Define Token 就需要指定好 UDT 所对应的 type script。script 是通过 RISC-V 指令集的虚拟机上运行的,更多内容可以参考 Intro to Script | Nervos CKB

大 cycle 交易的挑战

通常一个简单的 script 在 CKB-VM 里面执行是非常快的,VM 上跑完之后会返回一个 cycle 数目,这个 cycle 数量很重要,我们用来衡量 script 校验所耗费的计算量。一个合约的 cycle 数多少,理论上来说依赖于 VM 跑的使用用了多少个指令,这由 VM 在跑的时候去计算 VM Cycle Limits

随着业务的复杂,逐渐出现了一些大 cycles 的交易,跑这些交易可能会耗费更多的时间,但我们总不可能让 VM 一直占着 CPU,比如在处理新 block 的时候,CPU 应该在让渡出来。但之前 CKB-VM 对这块的支持不够,为了达到变相的暂停,处理大 cycles 的时候我们可以设置一个 step cycles,假设我们设置为 100 cycles,每次启动的时候就把 max_cycles 设置为 100,这样 VM 在跑完 100 cycle 的时候会退出,返回的结果是 cycle limitation exceed,然后我们就知道这个 script 其实是没跑完的,先把状态保存为 suspend,然后切换到其他业务上做完处理之后再继续来跑。回来后如何才能恢复到之前的执行状态呢,这就需要保存 VM 的 snapshot,相当于给 VM 当前状态打了一个快照:


根据这个机制,我们老的 script 校验大交易的整个流程是通过一个 FIFO 的队列保存大交易,然后通过一个后台任务不断地从这个队列中取交易跑 VM,每次都跑 1000w cycle 左右,在这个过程中就可能切换出去,没跑完的交易继续放入队列等待下一次执行:

对应到代码就是 ChunkProcess 这个单独服务来处理的。由于 ChunkProcess 是一个单独的服务,它的处理流程和其他交易的处理流程是不一样的,这样会导致代码的复杂度增加,比如:

  1. 要针对 ChunkProcess 里面的交易额外判断,例子 1, 例子 2
  2. 暂停 / 恢复 ChunkProcess 处理的时候,需要对 ckb-vm 做相关的状态保存和恢复处理,参考结构 TransactionSnapshot, 代码比较复杂且容易遗漏,历史上也有过相关的 bug 1, bug 2, 以及安全问题。
  3. 代码中包含重复逻辑,比如 chunk_process 里的 process_inner_resumeble_process_tx
  4. 由于它只能同时处理一个大 cycle 交易,在 tx pool 本身比较空闲的情况下如果收到了多个大 cycle 交易也不能并行处理,比如 .bit 团队之前有过反馈他们通过本地 rpc 同时提交多个大 cycle 交易会比较慢的问题。

CKV-VM pause

这些问题的根本是 VM 只能通过 cycle step 的方式来暂停,有没有一种方式是我们任何时候想暂停就暂停,就是 event based 的方式。所以后来 CKB-VM 团队做了一些改进:

这个方法的本质是通过 VM 的 set_pause 接口,把一个 Arc<AtomicU8> 的 pause 共享变量设置给 VM。然后在 VM 外通过更新这个 pause 的变量让 VM 进入暂停状态或者继续执行,这样我们就不需要 dump snapshot 等操作,因为 VM 整个就还是在内存中等着:

新的实现方案

基于这些改进我们可以重新设计和实现 CKB verify 这部分的代码,主要是为了简化这部分代码,并且提高大交易处理的效率。这是一个典型的 queue based multiple worker 方案:

主要的核心是就是这段异步执行 VM 的逻辑:chunk_run_with_signal。做的过程中发现一些其他问题:

  • 交易提交的时候,SubmitLocalTxSubmitRemoteTx 如果 verify 失败目前会立即返回 Reject,如果改成加入队列的方式,这个结果无法实时给到,所以做了如下改动:
    • 优先处理本地的交易,本地提交的交易不会放入 queue,而是直接会在 RPC 的处理阶段执行
    • 所有的来自网络 peer 的交易都全到放入到 queue
  • 后来 CKB vm 又新增了 spawn 的实现,所以会有 parent、child 的概念,那么Child VM 是执行 syscall 的时候执行 machine.run ,如果不改这块执行 child vm 的时候不可暂停
    • 后来我们讨论了之后决定 spawn 时把父的 Pause 传递给子,然后暂停的时候给父的 Pause 设置暂停,这样所有的子 machine 同样返回 VMError::Pause ,同时把当前的 machine 栈重新入栈,恢复的时候继续执行,这里逻辑比较重,相关代码实现:run_vms_child
  • 后来用重新设计了 spawn,使用了一种新的 determined scheduler 的方式去管理所有的 vms 和 IO,之前和 VM 的使用者角度来说之前需要和 VM 交互,现在变成了都通过 scheduler 来管理。关于 spawn 的设计参考这个文档:Update spawn syscalls

整个 PR 在这里:New script verify with ckb-vm pause

CKB RBF 设计和实现

CKB 相关技术文章第二篇。

Replace by fee

问题

如果一个交易成功发送到交易池,但可能出现因为费用较低而一直得不到处理。之前 CKB 没有其他措施来处理这种情况。

例如 Dotbit 4 位域名注册拥堵 这个事故发生过程中,CKB 的应用方无法使用任何方式来尽快让自己的交易被打包,这就是引入 Replace-by-fee(RBF) 的原因,我们需要一个机制来提高已经在交易池里交易的费用,替换掉旧的交易,让新的交易尽快被打包。

在新的 multi_index_map 重构后,交易在 pending 阶段也会按照交易的 score 来优先处理 (通常费用高的交易 score 也会高),这会避免高费用的交易被阻塞住,所以理论上述需要手动提高费用的情况会减少,但我们还是需要 RBF 来手动提高交易的费用,应对意外的情况。

另外,RBF 可能将多个老的交易替换出去,因此也是将两个或多个支付合并为一的方法,例如下图所示,如果满足条件 tx-a, tx-b, tx-c, tx-d 都会被 tx-e 这个交易替换掉:

参考

中本聪最初的 Bitcoin 版本中就有引入一个 nSequence 的字段,如果相同交易的 nSequence 更高,就可以替换之前老的交易,这个实现的问题是没有支付额外的 fee,miner 没用动力去替换交易,另外因为没有 rate-limiting 从而导致可能被滥用,所以 Bitcoin 在 0.3.12 版本中禁止了这个功能。后来 Bitcoin 重新引入了新的 RBF 改进,主要包括需要支付额外的费用来替换老交易,另外为 RBF 指定了更多的限制条件。

在 CKB 上我们之前做过两次 RBF 的相关调研,因为之前 Pending 是一个 FIFO 的数据结构,所以处理替换不是很方便,在 RBF in CKB(draft 2023.01.05) 尝试引入一个 high priority queue 来实现 inject-replace。交易池改造之后,整个交易池可当作一个优先队列,所以应对 RBF 会简单很多。

新增 RBF 的流程

实现细节

  • pre-check 为 entry 加入到 tx-pool 之前必须要做的检查,之前只是做双花的检查,新增 RBF 后如果双花检查失败(这里意味着冲突),继续做 RBF 的相关检查,如果 RBF 检查成功则也返回成功,否则直接返回错误。这里默认直接做 resolve_tx 的检查,如果成功则走正常流程,目的是不给正常流程增加额外成本。所以这就是pre-check 修改后的主要逻辑

RBF 的检查规则参考 Bitcoin 的六条,check_rbf 初步实现

实现细节:(Bitcoin Core 0.12.0)~~1. 交易需要声明为可替换交易~~ 2. 新替换交易没有包含新的、未确认的 inputs3. 新替换交易的交易费用比待替换交易费用高4. 新替换交易费用必须比节点的 min relay fee 高5. 待替换交易的子交易数量不可超过 100 条(即使用了该交易的任意 outputs,该交易替换后它们将被从内存池中移出)6. 因为 ckb 是做了两步提交,我们新增规则:被替换的交易只能是 Pending 或者 Gap 阶段的。

我们不给交易加新的字段表示是否可以被替换,而是通过节点是否配置了 min_rbf_rate 来决定是否能做替换,因此 规则 1 不做对应考虑。

替换和提交

修改 tx-poolsubmit_entry 函数,传入 conflicts,在新增 entry 之前把所有冲突的交易删除 放入 rejected 记录,另外确保所有检查完成了之后才做删除和写操作:submit_entry 逻辑

最终实现在这个 PR 里Tx pool Replace-by-fee

并发的 Bug

在最初的实现版本中,隐藏了一个并发的 bug 后来在测试发现了。RBF 的检查如果放在 pre-check 中,如果多个线程中的多个交易发生了冲突,input resolve 可能会出问题。Fix concurrency issue for RBF 这个 PR 修复了这个问题,把 RBF 的冲突检查移动了 submit entry 之前,因为在这个函数里面会持有 write 锁。

cycling attack

后来我们在做闪电网络的时候又发现 RBF 可能会引入 cycling attack 的风险,这个攻击通过构造巧妙的新交易,让支付路径上的中间节点的 commitment tx 不能按时上链,Lightning Replacement Cycling Attack Explained这篇文章有更详细的描述。

所以我们后来又做了这么一个改进:Recover possible transaction in conflicted cache when RBF 来规避这个问题。

CKB 交易池重构

在 11.9 号清迈的 CKCON 会议上我会做一个关于 CKB 交易池的演讲,这是我准备的 slides Key Upgrades of the CKB Core 。所以这段时间在整理之前做项目的时候写的一些文档,顺便分享到自己的博客上。既然我们整个项目的源码都是公开的,所以这些文档其实也是可以分享的。

第一次听说 CKB 的读者可以参考这个文档以了解什么是 CKB 以及如何工作的:How CKB Works | Nervos CKB

我加入 Cryptape 之后一年内做的主要工作,涉及到交易池重构、Replace-by-fee 功能、以及 new-verify。这是第一篇关于交易池重构的文章。

什么是交易池

在 bitcoin 中交易池叫作 mempool,比如 mempool - Bitcoin Explorer 这个网站就很好地展示了其当前的状态。

交易池是 bitcoin 中的一个重要的组件,但感觉专门关于这块的资料很少,只能通过 PR 和邮件列表上的讨论看到一些文档。但交易池非常重要,因为一个交易要上链必须会通过交易池,而其中的交易打包算法涉及到如何选择合适的交易,这里面有很多因素需要考虑,所以在实现上也是比较复杂的。

当一个交易被提交到一个节点时,或者一个节点从网络中同步到交易时,这个交易首先需要被加入到交易池中,交易池里会根据一定的算法去选择下一个需要被打包的交易,另外交易池作为一个缓存,我们需要为其设置一个最大的 size。所以交易池里面最重要的两个操作就是 packaging 和 evicting。

交易池里面的交易存在父子关系,打包的时候需要从交易链的纬度去考虑,后面的 Replace by fee 这些功能也需要关注整个交易的所有子交易。

交易池重构

问题

根据 RFC consensus-protocol 的设计,CKB 里的 tx-pool 采用了两段提交的方式:

相应地在交易池最初实现的时候, ckb 的代码实现中 tx-pool 同样采用了三个独立的队列,具体定义如下:

  • pending 交易刚加入到交易池时候的状态,我们每次只能处理不多于 MAX_BLOCK_PROPOSALS_LIMIT 个交易,交易需要先进入 gap 备选,具体代码逻辑在 update_proposals
  • gap 已经被 proposed 了,但是还不能被打包,需要等一个块后才能被打包,所以这只是内部中间过渡状态。
  • proposed 交易可以加入到 block_template.transactions , 最终打包到 block 里,具体代码逻辑在 block_assembler

实现中 pendinggap 同样都是使用了 PendingQueue(LinkedHashMap),而 proposed 采用了 SortedTxMap(HashMap + BTreeSet)

pub struct TxPool {    pub(crate) config: TxPoolConfig,    /// The short id that has not been proposed    pub(crate) pending: PendingQueue,    /// The proposal gap    pub(crate) gap: PendingQueue,    /// Tx pool that finely for commit    pub(crate) proposed: ProposedPool,    ....    pub(crate) expiry: u64,}

这样的实现存在以下问题:

  • 我们不容易对所有在交易池中的 entry 做统一排序,这样会存在以下问题:

    • 一个 fee 高的交易可能在 transaction 多的情况下在 pending 阶段一直卡着,因为我们在 pending 和 gap 阶段只是按照时间顺序来处理,只在 proposed 后的打包阶段按照交易费来处理。
    • issue 3942 交易池满了之后,我们需要选择一些 entry 做 evict,我们目前的 evict 逻辑很简单粗暴。我们希望尽量选择最小 descendants 的交易,这样能避免在 evict 过程中删除过多交易。我们目前在 pending 和 gap 阶段没有记录 descendants,而需要加入这个逻辑就和 proposed 阶段完全重复,而且因为不会统一排序,后续实现也不容易。
  • pending, gap 和 proposed 除了所采用的数据结构不同外,有很多逻辑雷同的代码,比如 entry 的新增和删除等操作,同样都维护了 deps 和 header_deps,resolve_conflict, resolve_conflict_header_dep, resolve_tx 等函数的逻辑也是类似的,但实现上有些细微差异,这导致长期来说代码不容易维护。

  • 同样我们在 tx-pool 上对 entry 做迭代和查询时,需要依次针对 pending, gap, proposed 做相同的逻辑,比如 resolve_conflict_header_dep 这样的函数在 pool 中有几个类似的,甚至 get_tx_with_cycles 这样的函数,需要依次判断各个队列。
  • 实现其他功能不方便,比如我们如果要实现 Replace by fee,就需要找交易池中和新交易有冲突的交易,我们需要在三个数据结构上分别进行检查才能得到结果。

方案

基于以上解决现有问题、应对未来的潜在需求、保持代码可维护性的角度,同时参考 Bitcoin txmempool 的实现,我们提出引入 Multi_index_map 对 tx-pool 进行重构。

总体方向是把所有的 entry 放入统一的数据结构中进行管理,加入一个新的字段 status 标识目前 entry 所处的阶段,然后通过 index_map 的方式根据不同的属性进行排序和迭代:

pub enum Status {    Pending,    Gap,    Proposed,}#[derive(MultiIndexMap, Clone)]pub struct PoolEntry {    #[multi_index(hashed_unique)]    pub id: ProposalShortId,    #[multi_index(ordered_non_unique)]    pub score: AncestorsScoreSortKey,    #[multi_index(ordered_non_unique)]    pub status: Status,    #[multi_index(ordered_non_unique)]    pub evict_key: EvictKey,    // other sort key    pub inner: TxEntry,}

其中根据 Rust 社区的 multi_index_map 内部实现采用的数据结构看,性能上应该没有什么大问题:

  • Hashed index retrievals are constant-time. (FxHashMap + Slab).
  • Sorted indexes retrievals are logarithmic-time. (BTreeMap + Slab).
  • Non-Unique Indexes
    • Hashed index retrievals are still constant-time with the total number of elements, but linear-time with the number of matching elements. (FxHashMap + (Slab * num_matches)).
    • Sorted indexes retrievals are still logarithmic-time with total number of elements, but linear-time with the number of matching elements. (BTreeMap + (Slab * num_matches)).
    • Iteration within an equal range of a non-unique index is fast, as the matching elements are stored contiguously in memory. Otherwise iteration is the same as unique indexes.

具体实现时我们是否把 inner 也放在 Slab 里面以后可以通过 benchmark 来选择,从实现的简洁性角度考虑统一放在一个数据结构里面更容易。

目前的实现版本:Tx pool rewrite with multi_index_map #3993

实现结果

我们首先只是做模块内的重构 (保持对外逻辑和以前一样),当然考虑引入了新的数据结构,不管是从性能上还是内存占用上都会有一些影响。

为了做统一排序这件额外的事,本质上我们引入了额外的 Map(FxHashMap 或 BTreeMap) 来存储,所以比以前需要更多内存。另外,我们有时候需要调用 get_by_status 来筛选某个状态的 entries,这在新的实现里面需要先从 index 里面找出 slab 的 id,然后再找到对应的 entry,所以必然也会比以前慢。

从最终的性能对比结果上,除了内存会稍微有增加,性能上没有大的变化。另外我们在实现的过程中对所用到的 Rust 包 multi-index-map 做了一些贡献:Non-unique index support, capacity operations, performance improvement & more by wyjin

这是我入职后做的第一个主要工作,因为我们的各种测试比较齐全,所以做大的重写信心也比较足。Rust 的生态就有这种问题,如果一个 crate 不是被广泛使用的,必然还是会存在各种坑需要填。总体来说,第一个项目很顺利。做完这个重构之后对于后面的 Replace by fee 等功能也准备好了。

xz-backdoor 观感

写写最近一周的大瓜 xz-backdoor,该事件可能成为开源供应链安全的一个分水岭,从技术角度看,这里面的社工和混淆也是精彩。

简单介绍一下背景,xz 是一个开源的无损压缩工具,在出事之前可能很少有人注意到这个压缩库使用如此之广,几乎任何一个 Unix-Like 的操作系统里面都有 xz-utils。在两年多的时间里,一个名为 Jia Tan 的程序员勤奋而高效地给 xz 项目做贡献,最终获得了该项目的直接提交权和维护权。之后他在 libzma 中加入了一个非常隐蔽的后门,该后门可以让攻击者在 SSH 会话开始时发送隐藏命令,使攻击者能够跳过鉴权远程执行命令。

Timeline of the xz open source attack 总结了该事件的主要时间点,这里我挑一些关键节点:

潜伏

  • 2005 ~ 2008 xz 项目的初始版本,这是一个文件压缩算法,主要由 Lasse Collin 开发和维护。
  • 2021-10-29 ~ 2022-06-29 Jia Tan 开始较为密集地给 xz 项目贡献代码,同时几个类似马甲的账号 (Jugar Kumar, Dennis Ens) 在邮件列表里抱怨 Merge 得不到及时处理,问题得不到回复,有点逼宫的意思,在这个过程中项目主导者 Lasse Collin 把最近的优秀贡献者加入了维护者列表。

    准备

  • 2022-09-27 Jia Tan 获得了信任,并开始主导新版本的发布,他在这期间做了几个看似合理的 PR,但其实是在为今后的后门做伏笔,另一个马甲 Hans Jansen 提供了一个钩子可以让后门里的代码替换全局函数,从而绕过检查。
  • 2023-07-07 Jia Tan 在 Google 的 oss-fuzz 提供修改禁用了 ifunc,这也是为了避免 fuzz 可能发现后门。

    发动

  • 2024-02-23 Jia Tan 发布了第一个有害的 PR,在测试代码中包含了几个 binary 文件,这些文件看起来只用于测试,所以在代码 review 的过程中肯定不会被仔细查看。
  • 2024-02-26 Jia Tan 通过一个非常隐蔽的提交,给 CMakeList.txt 增加了一个 .,使得代码会编译失败从而让 Landlock 不会被激活。
  • 2024-02-24 Jia Tan 发布 v5.6.0,其中使用脚本混淆悄悄地把后门的 payload 塞进了目标文件中。Gentoo 和 Debian 开始在 unstable 版本中含有后门。
  • Hans Jansen 同时在发邮件催促 Debian 升级 xz 到 v5.6.1

    暴露

  • 2024-03-29: 一个叫 Andres Freund 的开发者在分析一个 sshd 可疑的 500ms 延迟时,发现了隐藏在 xz 的恶意后门。如果不是偶然的发现,估计现在世界上无数的服务器处于肉鸡状态,这位微软的员工如英雄一般拯救了世界。

攻击者是中国人?

从主要攻击者的名称看似乎是中国人,但 Git 昵称和时区这种东西很容易伪造,有人分析过开发者的代码提交时间,分析得出实际可能是欧洲人/以色列人冒充。

但不可否认,肯定会有不少国外的开发者会默认这就是中国人所为,我也看到了一些开发者开始带节奏,开始找各种和 Jia Tan 有过互动的中国程序员。

我倾向于相信这不是中国攻击者,感觉其 commit 信息里面的英文中没找到中式表达。比较确定的是,从这些马甲之间的密切配合来看,这像是一个有密谋的组织团体。

开源软件的脆弱性

开源意味着透明,但并不意味着安全。

10 多年前我们经历了 OpenSSL 的心脏滴血,如今类似的事情再次发生。甚至这次事件的性质更严重,心脏滴血漏洞本身是因为代码的逻辑问题导致被恶意利用,而这次是攻击者通过供应链恶意植入后门。

有一种观点是开源软件被更多人 review,所以理论上来说安全漏洞更容易被发现。但实际上看来,被巧妙设计过的代码改动,很不容易被发现问题,比如这次事件中这个提交,我相信绝大部分开发者无法发现被恶意添加的 .:

这次后门被发现有很大的运气成分,多亏了 Andres Freund 的细心和刨根问底的精神,这也算是有足够多的眼睛盯着所以发现了问题吧。

如何预防

如果有一个开源贡献者的身份识别机制,就可能预防类似的事情。我看到有人举例 Linux Kernel 提交必须使用 Git 的 Sign-off,但这个 Sign-off 更多的是在解决法律上的问题,Sign-off 本来就是因为法律诉讼而引入的。而且,在最坏情况下,一个开发者可能被社工或者入侵而导致身份被冒用,所以 Sign-off 并不意味着身份识别。

有的人提到通过支付来进行 KYC(Know Your Customer),这必然是不可能的,因为开源本来就是一个黑客文化的产物,大量的开发者会刻意选择使用匿名身份提交代码。

我们来看看 Bitcoin,如果论项目值钱程度,比特币的代码应该能排得上号。但比特币是支持 Permissionless and Pseudonymous development 的,甚至这是保证比特币去中心化的两个很重要的手段,中本聪的身份仍然是一个迷。中本聪选择匿名对比特币本身来说也至关重要,No one controls Bitcoin 是其价值根本。

那比特币如何保证不会被植入后门,比如这种供应链攻击?

  • Reproducible builds,这是个极大地缓解供应链风险的办法,不同的人编译相同的源代码必然得到相同的二进制文件,binary file 不能存在于源码库中。Bitcoin 使用 Guix container 从源码编译所有的东西,contrib: Enable building in Guix containers,这个过程可以在任何 Linux 发行版上重现。在这个过程中,几乎所有的一切都从源码编译,所以会存在一个鸡生蛋蛋生鸡的问题,为了解决这个问题必然会需要一些 binary files,但最好是将这个范围限制到最小,Preparing to Use the Bootstrap Binaries
  • Don’t forget to verify yourself!

另外比特币的安全在于 PoW,其设计本来就假设了少部分节点可能是恶意节点,除非黑客控制住了大部分节点才能造成破坏,而要达成这点在的概率可以认为就是零

开源的可持续性

从这个安全事件我们可以继续探讨开源的可持续性这个问题。这个事件中 xz 的维护者 Lesse Collin 看起来已经是处于疲于应付的地步。从贡献者统计可以看到这么多年几乎就是他一个人在给项目提交代码,Jia Tan 通过两年的潜伏就成为了贡献者第二的开发者:

长时间维护一个被大量使用的开源项目是个巨大的负担,对维护者而言不仅仅是时间的投入,有时候也是精神上的折磨,即使开发者当初的有多好的愿景,但谁也无法保证常年的持续投入。关于这点可以阅读这篇文章,The Dark Side of Open Source

Lesse Collin 在这次事件中被利用了这个弱点,他在这封邮件里解释到自己作为项目主导者的困境:

写到这里我想起自己也曾经催过一个库的作者,是不是考虑让更多人来维护项目 Maintenance status · Issue 😅。

也许未来可能有一套机制,能够让基础开源软件的维护者得到经济激励,但这条路如何演化出来我还没看出来,如果真的出来或许与加密货币有一定关联。

可怕的是,现在还有很多人没有意识到开源贡献者困境,那些价值几千上万亿的公司也是在期望开源的开发者能够像雇员似的响应他们的 High Priority:

这个世界上还是有无数的默默耕耘的开源代码维护者,比如 SQLite,全球大概有上万亿的 SQLite 数据实例跑在服务器上、手机上、浏览器里,但这个软件其实只由 3 个程序员维护了 20 多年;几乎所有工程师都使用的工具 curl,由 Daniel Stenberg 从 1998 维护到至今;vim 的作者 Bram Moolenaar 从 1991 年维护项目到自己去世,总共整整 32 年。

实际上没有人知道,多少被广泛使用的基础组件和代码是由各种默默无闻、分毫未取的开发者在用自己的业余时间维护着。

从这个角度看,人类数字基础设施这艘巨轮其实建立在非常脆弱的基础上,说不定哪天一个地方就裂开了。我现在养成了一个习惯,升级从来不追新,任何安装到自己电脑上的二进制都小心翼翼。

这个世界上有无数的恶魔,也会有一些英雄和吹哨人,致敬 Andres Freund。

从明天起,做一个 Rust 程序员

3 月是怀念海子的月份:

从明天起,做一个 Rust 程序员,喂马、劈柴,周游世界。

10 年前我开始写第一行 Rust 程序,到如今全职远程做 Rust 开源项目,也许我真能去过喂马劈柴周游世界了😆。但回想自己的学习旅程,其中有各种曲折有几度放弃的时候,如果你也想学习或者提高 Rust 方面的技能,我这篇文章里有一条更容易的路。

为什么学习 Rust

Rust 1.0 发布已经快 10 年,所以并不是一门新编程语言了,从发展的角度来看 Rust 已经度过了生存期,并进入了迅速发展的阶段。从目前可见的业界方向来说,Rust 主要在以下几个方面取得了成功:

  • 在基础软件领域成为有力竞争者
    • 大量开源的 Rust 命令行工具和开发库,如果你使用 Python,可以通过 PyO3 用 Rust 来写对性能要求更高的模块,还出现了 opendal 这样优秀的基础库
    • Cloudflare 使用 Rust 开发新的网关 Pingora
    • 开源数据库实现,比如 QdrantRisingWavedatabend
    • AI 方面参考 Are we learning yet,虽然 Rust ML 生态系统还很年轻并处于试验阶段,但已经出现了一些雄心勃勃的项目和模块,Hugging Face 开源了 candle机器学习框架
  • 前端的基础设施
  • 操作系统
    • Windows 开始使用 Rust 开发一些核心组件
    • Rust 开始进入 Linux 内核,使得使用 Rust 开发 Linux module 成为可能
    • Andriod 使用 Rust 开发更多组件,并有效减少了内存方面的漏洞,他们发布的 Comprehensive Rust是一个很好的学习资料。Google 开始尝到 Rust 的好处,并开始投入更多资金和人力,近期 Google 打算捐献 100 万美金给 Rust 基金会着重解决 Rust 和 C++ 的互操作性
  • 区块链领域
    • 以我在这个领域工作一件多的经验来说,Rust 成为了区块链领域的标配,基本区块链相关的工作岗位 Rust 技能是一个极大的加分项
    • 大量公链使用 Rust 来开发
  • 游戏开发,参考 Are we game yet?,目前已经有成熟的游戏开发框架 Bevy Engine

如果你对 Rust 的发展情况感兴趣,可以参考 2023 Annual Rust Survey Results。在内卷的 IT 市场,作为程序员选择一门小众的编程语言是避免过度竞争的方式,我之前介绍过其他人的类似经验,我们称之为 The Niche Programmer。Rust 还未成为主流编程语言,但潜力和发展空间很大,而门槛相对其他语言比较高,所以我认为从求职的角度来考虑是值得一试的。

之前提到 Google 投入更多的资金在 Rust 上面,钱进来后相关的职位就出来了 C++/Rust Interop Initiative Software Engineer Lead

我学习 Rust 的体会

我 2014 年时践行每年学习一门新的编程语言,Rust 作为一门新的编程语言进入了我的视野。我开始使用 Rust 写些简单的个人学习项目,然后我继续做了 Rust exercises

后续几年我偶尔看看 Rust 相关的新闻和项目,时不时动手写点代码都会有点磕磕碰碰。直到四年前开始在 Github 上给一些 Rust 开源项目贡献,两年前开始给 Rust 编译器做贡献,一年前开始全职从事 Rust 区块链相关的工作。

从技术角度来说,Rust 非常有趣,这里面包含了近些年程序设计方面的一些良好实践。全职写 Rust 程序这一年多是我开发体验最好的阶段,当然有时候我们需要和编译器斗智斗勇、做类型体操,但很多问题在开发阶段给规避掉了。

Rust 的最大问题还是在于学习门槛相对较高,因为在 Rust 中程序员接触最多的 = 语义都变了。从我个人体验来说,在学会了 Rust 语法后会陷入一个瓶颈,如果日常工作中不使用 Rust,就没有多少机会去实践,另外不知道做一些什么项目。

我相信很多人同样如此,看了官方 tutorial 之后不知道如何下手,我想如果有一个经验丰富的老师带,会少走很多弯路,这就是我要介绍的极客时间训练营要解决的问题。

极客时间 Rust 训练营

说起来我与这个训练营还有些渊源。

当极客时间在筹划这个 Rust 训练营的时候,策划人员找到过我问我是否有意愿当这个课程的讲师。我还稍微犹豫了一下,因为我之前也想过如何在 Rust 领域做更多的分享,我很羡慕优秀的技术分享者比如 Jon Gjengset能够非常自如地通过视频分享 Rust 方面的技术。当老师当然是个机会能从沟通和表达方面提高这方面的能力。

后来考虑到自己时间方面安排不过来,我有全职工作、有业余的 Rust 社区工作、还有三个小孩,所以我应该真没时间去录制课程了,而且他们已经找到了我认为最合适的讲师:

我看了这个项目的大纲,陈天老师希望可以教大家怎么用 Rust 比较简单的语法和技巧,来完成 80% 的日常工作,主要是通过各种实践项目来学习,这也是我最推崇的 Learn by doing 的方式。

有很多主题我都没怎么接触过,比如构建一个 ChatGPT 的应用、比如跨平台 GUI 之类的,所以我对这个课程很感兴趣,然后我和策划说能不能做这个项目的助教,后来沟通下来发现当助教也需要不少时间的,所以就没机会参与到具体的教学里面了。

总之,这个项目对于想学习 Rust 或者已经有一定 Rust 经验,但想获得更多实践经历的人是非常合适的。在和极客时间的相关人员沟通的过程中,我发现他们做事情很用心,这个训练营的课程质量我认为是有保证的。

这个训练营一共是 15 周的课程安排,其中每周都会有明确的项目安排,课后还有助教答疑。关于训练营的更多信息请参考:极客时间训练营-Rust 训练营

我与陈天老师的小故事

我最早知道陈天是他写的公众号《程序人生》,他是那种技术和文笔都非常棒的程序员,非常难得。我还看过他的 B 站上的技术讲解视频,他的演讲和分享都很流畅。陈天是极客时间《陈天 · Rust 编程第一课》专栏作者,已有 2.3w 人学过,广受好评。技术能力、演讲表达、对技术的热情这些都是讲师最重要的素质要求,所以陈天是这个训练营最好的讲师人选。

再分享一个小故事,我一年多前跳槽的时候还有些犹豫,因为自己的职业规划方面有些困惑,所以想找些人聊聊。当时我突然想到陈天之前从事过区块链方面的创业,后来从里面退出来了,所以我就想向他咨询一下。我没有他的联系方式,但灵机一动我想到了从 Git 的提交记录里面找 Email,然后抱着试一试的想法给他发了个邮件说明了自己的情况和困惑。没想到他很快给我回复了,并很详细地告诉我他对于区块链的想法,还有如何判断自己是否适合一个公司,通过各种途径了解公司的相关产品来作为决策的依据等等。

我作为一个陌生人,陈天老师都会乐于给与指导和帮助,可见为人真的很好。还没能有幸和陈天老师现实中有所交流,我本来想用当助教的机会和陈天老师多学习,但时间方面安排不过来了。希望大家能在老师的的训练营学到知识、经验、还有探索技术的乐趣!

我喜欢的 shell 工具

分享一些日常经常使用的命令行小工具,我认为这些小东西能提高我的工作效率。

percol

mooz/percol 这个工具是典型的 Unix 风格工具,它唯一做的事情就是通过管道接收输入,提供一个模糊搜索和 UI,用户选择后再把结果返回给后面的管道继续执行。

比如我这个 gt 的 alias 是我日常使用非常多的一个命令,做的事情就是 check out 一个 git 分支,因为我的本地通常有很多的分支,所以使用这个命令来模糊查找,然后选中就非常方便了:

alias gt="git branch| percol | awk '{ print \$1 }' | xargs git checkout "

类似的下面这个命令是 kill 掉某个进程,我们可以通过模糊搜索来找进程:

alias pk="ps eaux | percol | awk '{ print \$2 }' | xargs kill -9 "

如果你仔细总结,日常开发任何需要选择的地方都可以使用这个小工具来达到更高的效率,比如我工作的目录下有很多测试文件,测试其中一个文件的命令是 just ts file-path,我需要找到其中一个来测试:

find ./tests/ui/ -name \*.rs  | percol | xargs just ts

percol 可以嵌入到很多配置里面,比如在 tmux.conf 里面加入这个配置,这样可以模糊查找 tmux 的 session 和 window:

bind B split-window "tmux lsw | percol --initial-index $(tmux lsw | awk '/active.$/ {print NR-1}') | cut -d':' -f 1 | tr -d '\n' | xargs -0 tmux select-window -t"bind b split-window "tmux ls | percol --initial-index $(tmux ls | awk \"/^$(tmux display-message -p '#{session_name}'):/ {print NR-1}\") | cut -d':' -f 1 | tr -d '\n' | xargs -0 tmux switch-client -t"

atuin

atuinsh 是一个记录 shell 历史的小工具,不同于普通的记录 shell history 的工具,atuin 会把数据记录在一个 SQLite 的数据库文件中,这样可以支持更丰富的查询功能。

另外 atuin 也支持不同机器之间的同步,当然这需要加密通信。我目前还没使用这种场景,只是把 Ctrl-R 绑定到了 atuin。

atuin 也是一个 Rust 实现的工具。

tmux

tmux 我之前听很多人推荐过,但是我一直没怎么尝试,直到某天我需要通过网页打开跳板机登录到服务器上,网络不稳定的情况下我经常需要重新登录,这时候我尝试了一下 tmux 发现真是太好用了。

tmux 的教程很多,比如 Tmux 使用教程 - 阮一峰的网络日志。我的 tmux.conf配置很简单:

set -g @plugin 'tmux-plugins/tpm'set -g @plugin 'tmux-plugins/tmux-sensible'set -g @plugin 'tmux-plugins/tmux-resurrect'set -g @plugin 'tmux-plugins/tmux-continuum'unbind-key C-bset-option -g prefix C-Spacebind-key C-Space send-prefixset-option -s set-titles onset-option -g set-titles-string "#W/#T"run '~/.tmux/plugins/tpm/tpm'

安装 tmux-resurrecttmux-continuum,这样即使我重启了机器,打开 tmux 后我的 session 仍然和之前一样。

最近也有个 Rust 写的 zellij,但我认为这种软件使用更老的会更方便,比如公司的远程服务器必然有 tmux,但不一定有 zellij。

just

casey/just: 🤖 Just a command runner 是我喜欢的另外一个 Rust 写的工具,我的日常工作中严重依赖这个工具,比如我的 rustc-dev 项目中配置渐渐积累了这么多的配置:rustc-justfile

just 有些像 Makefile,但使用起来又比 Makefile 的语法简单和直观,我通常是来把一些常用的命令写入 justfile,然后留下经常需要调整的参数,比如:

err FILE N:        rustup toolchain link dev2 ./build/aarch64-apple-darwin/stage1/        RUSTC_ICE=/tmp rustc +dev2 {{FILE}} -Z treat-err-as-bug={{N}}

这样我执行 just err tests/ui/consts/const-eval/infinite_loop.rs 1 的时候就相当于执行配置的一系列命令。

另外我也会把一些频繁需要修改的参数放到最后一个位置,比如本来我需要执行:

CKB_TEST_ARGS={{SPEC}} make integration

在 justfile 里面配置:

test-one SPEC:        CKB_TEST_ARGS={{SPEC}} make integration

执行 just test-one SPEC 来测试不同的用例就会方便点。

其他


你有什么喜欢的 Shell 工具,希望也能分享给我。

中外程序员差异

今天看到这个推特,我理解作者的心情非常复杂,因为我前三年写过一段时间技术类的英文文章,也发现英文技术社区还有那种认真讨论的氛围,而在中文技术圈里,这种氛围已经几乎绝迹。

这几年因为我在外企和开源上的工作经历,接触了很多来自各个国家的程序员,今天想写写我发现的一些国内外程序员间的差异,我相信经常混迹开源社区的人会有些类似感受。

讲究细节

这点是我感受最深的,我自认为已经算是一个对细节比较在乎的人了,但我接触到一些国外的程序员,他们对细节的把握让人佩服。

最近的一个例子是我在写这篇英文文档 的时候遇到的,其中的 Reviewer jordanmack 对我文档里面的所有内容逐字逐句都过了一遍,发现不懂的地方一定要弄明白。这里面有的是中英文表达差异造成的理解偏差,也有他对这个功能的逻辑上的质疑,甚至可以细节到我在文中给出的 json 例子里的数字范围和自洽性。我们在 Github 上来回讨论了很久,然后继续在 Discord 上讨论,而在这个过程中我也确实发现了些代码上需要调整的地方,最后他给我的文章几乎全部润色了一遍

jordanmack 不算是全职的程序员,但他也有一些程序员背景。在我做开源的经历中,PR 中被挑细节的时候太多了,一度我已经不再认为自己是个对细节很把握的人了。后来我总结了一下,有时候我是在赶时间,觉得某些 corner case 就暂且跳过吧,但大多会在代码 Review 中被提出来的。

然后经历多了也就看淡了,不光是我,任何人的 PR 都可能引发大量的讨论,比如到底是使用 µs 还是 us。也许在很多人看来这是个小问题,但却引起了大量的讨论,细看其中还有些引经据典和长篇大论。随便挑一个 RFC,也都可以看到大量的讨论

所以我的感受是,国外程序员中在意细节的比例更大。那么问题是,他们为什么能看这么细?固然其中一个很重要的原因是他们确实有时间,才能静下心来看和写。

在国内公司我也碰到过对细节的把握,但很多用在了我最讨厌的形式主义上。在微软的时候,我见过各种不够漂亮的 PPT,有的时候翻来一段 onenote 就开始讲,因为都没人关注这些。

文字表达

文字表达能力是开源社区里一个非常重要的,因为但凡一个大的改动都需要和其他人广泛讨论和协作。

不少国外的程序员有文字表达的习惯,就是即使看很小的一点问题也会通过文字表达出来。这是很多国内程序员所没有的习惯,因为我们大多比较含蓄,认为多做比说强,说多容易错,说多容易暴露自己。

可能和教育和网络环境也有一定关系,如果不是刻意维持文字表达的习惯,很多人高中毕业后就没有写过几篇长文,对很多事情也没有自己的看法。

另外他们习惯使用 Email 来沟通,但中国开发人员大多习惯使用 IM 沟通。这两者还是有区别的,IM 沟通会让人不自觉地回复得更快,有的模糊想法随口就就表达了。而 Email 沟通更容易让人把事情写清楚,也更容易写得更长和有条理。

这种细微的差异长久了之后就可看出中英文技术社区的巨大差别。另外,中文网络的环境中戾气更重一些,人们对自我推销很反感,容易揣测你的意图。

个人目标

很多欧美大公司里有不少只做 Individual Contributor 而不做管理的人,在这些公司里,管理和技术是两条并行线,薪资和职级挂钩,也就是说纯 IC 的岗位可能收入比管理岗位更高,因为职级更高。

管理人员和技术人员大多是上下级关系,但下属对管理人员没有绝对的单向服从关系。当然大多数情况下,管理更容易升职上去,因为纯做技术岗位不容易通过杆杠来放大自己,管理就是一种很有效的杠杆。但这种纯粹的并行晋级路线是非常重要的,可以让技术人员有更多的选择权,甚至如果对自己的管理者不满意直接给差评和换组就是了。

所以在国外程序员中,如果一个人做了多年开发,很可能就是他确实喜欢做技术和更擅长做技术。而中国职场中,管理和技术岗的差别太大了,或者说绝大部分人到了一定年龄,如果你不混个管理的 title,好像就已经落后了,甚至没有职场安全感。

另外有些人是喜欢混到管理岗之后,纯粹为了获取更高的薪水,或者是为了把不喜欢做的事情推给别人。当然,这其中也有很大一部分中国文化里的官本位的影响,还有一部分原因是太看中钱了。

我接触过一些年龄在 40 岁多的国外程序员,他们还是对技术有很大热情。如果喜欢做技术,而又能通过做技术挣钱,这没有什么失败的,这与年龄没关系,反而这是一种很好的度过自己短暂一生的方式。

只是在国内要做到这点并不容易,很多岗位做的事情本来就不够有深度,时间更久也无法积累起来足够的壁垒,业务上的开发年轻人上手很快,而需要深入做下去的岗位不够,所以年龄大了就容易失业。

业余时间

国外程序员的业余时间真是非常多,如果你经常混 Github 就会发现,每当到了 12 月份就很多出来很多 aoc 字样的项目,这是他们在做Advent of Code 2023

Advent of Code 就是整个 12 月份每天出一道题目,都是些编程谜题,有点类似 leetcode,但题目描述更长。你可以用任何语言来实现,反正要的结果就是答案。可以发现这些 aoc 项目基本都是欧美的程序员在做,因为他们大多在 12 月份有几乎一个月的假期,我在微软工作的时候,很多人也是 12 月份开始基本不见人影。

创造性的前提是不用为生存问题发愁,欧洲那些搞哲学、做研究的,大多都是家底丰厚,闲得多了自然就能搞事。如果有大把的业余时间,用来发展工作外的开源项目可就太好了。其实很多著名的开源项目只有吃饱饭没事做的时候才能搞出来,我之前在知乎问题 为什么中国程序员不如外国程序员有创造性 中写到:

荷兰人蟒蛇大叔想着哇塞圣诞假期这么长,找点事做,结果出了 Python。
日本人松本行弘,经济危机时闲得发慌,搞出了 Ruby。
芬兰人李纳斯,大三不用为了找工作背八股和考研,冬眠似地宅家里写代码,搞出了 Linux。

在 Rust 社区中的贡献人员里,除了美国,第二多的是欧洲,他们也不是为了挣钱,完全就是感兴趣做做而已,我看到好几个大学年轻人做的事情已经非常深入了,当然其中花费的时间也是很多,他们几乎一直在线。


这些总结比较粗略,另外也可能有幸存者偏差因素。这个话题很大,深入下去探讨会包含很多方面。

我也不是在抱怨,年龄大了之后发现多看看历史相关的书还挺好,让自己更容易理解所处的环境为什么是这样的,比如《中国国民性演变史》这本书值得推荐。另外《美国种族简史》这本书也值得一看,多了解了解其他人的特点和长处,努力让自己不要局限于国界,另外做到程序员中的 80% 以上水平,保持英文能力。

Copilot,最好的编程助手

今天下午我解决一个小问题的时候,在 Copilot 的帮助下快速给出了修复,这个工具似乎有些超过期望了,所以突然想写篇文章分享这个目前我最愿意付费的 AI 工具。

Copilot 价格是每个月 10 美金,但我至今还没付费过,感谢微软支持开源,从测试阶段就邀请我试用,到现在还一直在免费使用。Github 应该有些政策,比如如果你持续给一些 star 数比较多的开源项目做贡献,就可以免费使用 Copilot

我会给出日常碰到过的一些具体的实际案例截图,以方便你更直观地感受到这个工具准确度。

Manual 类查询

我们在编程过程中经常会碰到一些命令的参数记不太清楚,这种问题很适合问 Copilot。这比自己去 Google 的感受好很多,因为他几乎能完全理解用户说的自然语言,而且给出的答案简介明了:


比 Google 更好的地方在于上下文的交谈,比如我继续基于上面的问题说我的想法,他就能继续给出反馈,比如我说大概有个类似 --exact 的参数,Copilot 会继续给出使用案例。

Copilot 非常善于回答对这种 manual 类的问题,因为这是有标准答案的,并且我作为用户对这些是有判断的,只是我们细节上记不清楚了。

还有一次我发现跑测试的时候挂了,分析下来是这个命令行失败了(但既然 CI 是过的,所以必然只是在 MacOs 下失败了):

diff -u --strip-trailing-cr -r -q A_file.txt A_file.txt

这是在 diff 同一个文件,所以必然应该返回 0,但在 MacOS 下这个命令会报错:

diff -u --strip-trailing-cr  -r -q ./x.py ./x.pyerror: conflicting output format options.blah blah 一大堆错误 blah blah 一大堆错误 

我知道这里面肯定是有参数冲突了,但我具体不知道是哪两个冲突了,所以这时候我问 Copilot:

可以看到这个解释非常清楚,并且帮我找到了问题的根源,所以我就能很快地发 PR 修复这个问题,并且我 PR 里的描述基本都是从 Copilot 里来的:
Fix diff option conflict in UI test #109036

给出示例代码

我们在写代码的时候,经常会出现固定的 Pattern,不同的语言对固定的 Pattern 有一些相对固定的代码样式。我很喜欢找 Example 类的代码,然后在这个基础上再思考或者修改:

对这种情况我们需要给 Copilot 足够的信息,他给出的 Rust 代码通常是可直接编译通过的,但当然这些示例代码需要进行仔细的修改,但这也比我自己翻 Doc 会快很多。

辅助排查问题

VSCode 上的 Copliot 更新很快,肉眼可见地体验越来越好,现在我们可以选择一段代码,然后就选择的代码来进行提问。

有时候我会选中一个函数,然后问这段函数能不能重构得更简单一些,或者我们能不能用其他方式实现。

今天让我有欲望写下这篇分享的文章是因为这个问题:
Missing request extension: Extension of type

这是一个有非常明确的报错的繁琐 issue,应该就是 Server 端限制了 HTTP 的请求类型,客户端通过 curl 发 GET 请求的时候报错了,只是这个报错信息看起来很不友好,而且和老版本行为不同。所以我就选中代码中对应的函数,然后问这里为什么会有这个错:


其实我对 Copilot 解决这个问题不怎么报有信心,只是好奇先试了试,没想到 Copilot 真的能理解我的代码,并且指出了问题所在。注意看它加的注释就是我代码中缺少的逻辑 (之前的代码只是在 enable_websocket 的条件下才加载了 stream_config 这个 Extension):

加上它建议的代码之后,那个错误信息没了,但是现在发 GET 请求是另外一个问题:

Connection header did not include 'upgrade'

这看起来是服务端期望客户使用 Websocket,但是客户端只是在通过 Curl 发一个 GET 请求,并没有按照这个期望来。所以我继续问 Copilot:

他给的回复里的代码并没有直接修复问题,但里面的
you can separate the handlers for POST and GET requests
提示了我应该尝试对 HTTP endpoint 和 Websocket endpoint 的 handler 进行分开,所以我一下想到了修复方案:

总结

如今使用 Copilot 已经成为我的一个编程习惯,就如同之前我严重依赖 Google 一样,但这个工具明显比搜索引擎高级了一个维度,当然现在我还是依赖搜索,但使用比率明显下降了不少,搜索引擎更像是成了一个书签的角色了。

我之前认为 Copliot 这种工具甚至是这辈程序员所不能体验到的东西,在我第一次尝试到 ChatGPT 居然可以理解一个函数,并且找出函数中的问题时,就感觉新的编程时代来临了。

前段时间 Redis 的创始人在文章 LLMs and Programming in the first days of 2024 中写到:

随着时间的推移,我们见证了框架、编程语言、各种库的大量涌现。这种复杂性通常是不必要的,甚至无法自圆其说,但事实就是如此。在这样的情况下,一个无所不知的“白痴”成了宝贵的助手。

这是一个事实:现今的编程大多是在微调同样的内容,只是形式略有变化。这种工作并不需要太高的推理能力。

Copilot 已经可以在一些具体的编码问题上给到我们很多帮助,甚至你把这个当作一个包含万物的文档查询工具都非常有效。

当然没有银弹,Copilot 并不能解决编程中的所有问题,比如理解大规模的程序,通过深入分析去找出 bug,或者做设计问题中的各种折中和取舍,这些都是不能取代人类的,这也是我认为编程中的乐趣还没有完全消失。

我会把繁琐和细节的问题抛给 Copilot,然后更开心地做重要和有趣的部分。

我的 2023

2023 年很快就要结束了,赶紧抓住这个冲动总结一下。今年对我来说有几个大的转变,从几个方面谈起:

生活

生活上最大的变化是我又有了一个儿子,所以我现在是三个孩子的父亲了。

同龄人中几乎没有生三胎的,有些人问我为什么这么想不开,自己找罪受。我只能说是命运的馈赠吧,我从小生活在一个大家庭里,加上我和老婆都算是喜欢小孩的人,三胎顺其自然地接受了,这个孩子也促使了我们更早地离开了苏州。

孩子 8 月底出生,前两个月请到了一个靠谱的月嫂,所以生活方面还不算痛苦。最近女儿生病才开始感受到三个孩子带来的巨大挑战,看来我们是低估了其难度。

我的大女儿开始在深圳上一年级,没想到现在的一年级都这么卷,基本上每天都有语数外作业,一个月一次的考试。我们力不从心已经放弃了一些家庭作业,比如数学之类的无聊作业我们就不怎么做,我认为每个小孩的大脑发育有自己的节奏,小学数学这种东西到了年龄自己会懂,小学阶段重要的是培养学习习惯和兴趣,强压给孩子只会让她产生对数学的恐惧。陪小孩做作业真是一件极其需要耐心的事情,我现在还在努力尝试从孩子的角度考虑问题。

三个孩子带来的另外一件事情就是冲突,大女儿心情好的时候会带着小的玩,心情不好的时候就会和妹妹争东西。如何在这些孩子中平衡,在吵闹中克服情绪去解决问题,这些都是在磨炼心性。

纪伯伦在《论孩子》中写到:你的孩子,其实不是你的孩子,他们藉助你来到这个世界,却非因你而来,他们属于你做梦也无法达到的明天。

有孩子之前我觉得养育孩子重要的是把他们当朋友,但真的等孩子三岁后有了更多自主意识之后,作为父母就会面临更多困难,什么时候该管教孩子,什么时候该放任他们。有时候我也忍不住发火,而后又觉得自己是个失败的父亲,心里多默念『还只是个孩子』几遍,如何做一个好父亲这必然是我今后一直需要学习的。

生活中的另一个变化是今年身体状态更好了,可能是因为深圳的暖和天气更适合我,加上在家办公出去本职工作外,没感受到什么职场上的琐事和压力,另外在家里办公相关的设备更适合自己,所以整体身体上没有大的问题。

但从心理方面,我能感受到和以前的更大差别,主要是彻底接受了中年这个年龄阶段。这是一点点积累起来的,那些曾经我看着长大的晚辈们都到了谈婚论嫁的年龄,或者偶然想起一些人和事心里一算已经是十多二十年前了,或是我发现自己某些方面更像印象中的父亲了。

我的生活看起来极其单调,不是坐在屏幕前写程序就是在带娃和遛娃,和梦想与激情这些词汇毫不沾边。但我满足并感恩目前的状态,我几乎没有焦虑,物欲低所以也不觉得缺钱,做着自己喜欢的工作和事情,有足够多的时间陪家人,这就很好了。

工作

2023 我全职远程做开源项目,很幸运在 Cryptape 这大半年里工作感受非常好,这大概是我工作这么多年来写程序最开心的一段时间。因为远程办公,今年我的人际圈子似乎更小了,日常微信沟通的都是些认识了 10 来年的朋友。

我的工作主要是做区块链 Layer 1 相关的事情,入职以后做的事情是交易池这块,后来又涉及到一些 RPC 相关的工作,还有些 Infra 类的工作。区块链这行涉及范围太多了,有网络、性能、分布式、密码学等各种,所以对于纯喜欢技术的人来说,这里面挑战太多,比 CRUD 之类的项目好玩得多。

我做的主要工作都是集中在 nervosnetwork/ckb这个项目,这里可以看到我做的一些 Pull requests

另外现在日常工作中纯用 Rust,编程体验和之前完全不是一个层次,除了如何实现功能,我们也会在乎项目的长期可维护性和优雅程度。区块链 Layer 1 也算是一个复杂度高和对准确度要求很高的项目,Rust 是很适合的。我虽然这两年一直在写 Rust 代码和做开源,但之前还真没有用 Rust 在实际工作中,特别是异步这块我之前甚少涉及。同事中有对 Rust 理解很深入的人,沟通也很顺畅,所以我特别喜欢这个工作氛围。

在工作过程中我看了更多 Bitcoin 相关的代码,越发觉得这真是一个伟大的发明,这像是个黑客用技术发起的社会性实验,在 beta 阶段就能如此深刻地影响了世界。关于 Bitcoin 推荐看这一系列文章 比特币的过去、现在和未来

开源

今年继续在为 Rust compiler 做贡献,能回想到的一些事情是:

因为在 Cryptape 的工作涉及到其他一些 Rust 项目,所以参与到了一些,比如我们在改造交易池的过程中用到了 multi_index_map 这个数据结构,顺带完善了一些不足 Non-unique index support, capacity operations, performance improvement

作为技术人,能全职使用自己喜欢的编程语言工作是一个很大的幸运,希望能继续在 Rust 开源这条路上走得更远。

阅读和写作

2023 看书的时间也少了很多,回顾了一下很多书没有看完,但这些书看完后值得分享:

  • 《硅谷钢铁侠:埃隆·马斯克的冒险人生》,这就是那些改变世界的人吧
  • 《失明症漫记》,似乎是重新回顾一遍疫情的场景
    • 如果我们亵渎生活的尊严,我们也就扭曲了理智;而人的尊严每天都会受到我们世界中权势者的侮辱;普遍的谎言已经替代了多元的真理;人一旦失去来自其他成员的尊重,他也就不再尊重自己。
  • 《作个闲人:苏东坡的治愈主义》,这书我估计我年轻的时候看不进去,现在看就觉得很好:
    • 人生如逆旅,我亦是行人
    • 可以寓意于物,而不可以留意于物
    • 一张琴,一壶酒,一溪云
  • 《走出戈壁》优秀的人在逆境中也能成长起来。
  • 《了不起的盖茨比》也许是因为我先看了电影,所以再看书就满脑子小李子那样子,也许有的作品就不应该看电影。
  • 《被讨厌的勇气》,一切烦恼都来自人际关系,让干涉你生活的人去见鬼,解决了一些我的日常困惑。
  • 《哲学家们都干了些什么》,你思考过的很多问题,前人必然已经思考过了。
  • 《夜晚的潜水艇》,这就是文笔好。我喜欢里面的《裁云记》
    • 值得人沉迷一生的事太多了。像你说的,每个洞穴都充满诱惑,难以取舍。我年轻时也在分岔处犹豫过。后来我才明白,不是所有洞口都陈列在那里,任人选择;有的埋伏在暗处:我一脚踏空,就一头栽了下来,到现在也没有落到底。
  • 《美国种族简史》
  • 《高山下的花环》
  • 《凤凰项目,一个 IT 运维的传奇故事》

同样在写作上的时间就更少了,总结下来居然是 13 篇博客,勉强达到月更的节奏。

写作这件事情似乎停下来之后就容易长时间停顿。带孩子太耗精力算是一个借口,但我其实很是可以把一些日常的琐碎时间利用好来做这件事情的,只是确实犯懒了。

希望借这次写年终总结的劲头,把写作这件事情捡起来。

Andriod 使用 Obsidian 的客户端

上周末试着在 Andriod 上配置好了 Obsidian 的客户端,没想到还挺好用。如果你已经买了 Obsidian 的 sync 服务,并且一切用起来都挺好的,那就不用看我这篇介绍了。

我折腾这个的主要的需求是使用私有仓库的 Git repo 来同步日记。为什么不买 Obsidian sync,我认为 Github 更符合我的使用习惯,并且我选择使用 Obisidian 的一个原因就是我不想把笔记数据同步到其他的第三方平台上,相对来说 Github 是我更信任的基础设施,毕竟我已经使用 Github 这么多年了。

Andriod 客户端

Obsidian 的安卓客户端好像没有在国内各个安卓软件市场上,你需要用过 Google play 来安装。

Termux

termux/termux-app 是一个 Andriod 上的终端模拟器,也是一个开源软件。基本上你可以把 Andriod 当作一个简化版本的 Linux 服务器来使用,Termux 高级终端安装使用配置教程 是一个很详细的介绍文章。

注意目前 termux 已经不能在 Google Play 上安装了,你需要去 Releases · termux/termux-app 下 apk 安装包来手动安装。

termux 安装好之后就可以在 Andriod 手机上跑一个 Shell,打卡进去之后运行来创建一个叫作 storage 的目录:

termux-setup-storage

接下来安装一些后面需要用到的依赖:

pkg install gitpkg install openssl

Git

ssh-keygen 来生成一对公钥和私钥,把公钥配置到自己的 Github 账户上,然后 clone 你的 Obsidian vault repo:

cd storage/sharegit config --global credential.helper storegit config --global user.email "<your_email>"git config --global user.name "<The name you want on your commits>"git config --global pull.rebase true

确保能在 Termux 上正确提交改动到 Github 上。如果有一些文件是不想同步到远程的,可以加入到.git/info/exclude 里,比如把 .obsidian/workspace-mobile.json 忽略了。

打开 Obsidian 的客户端,找到刚才 Git clone 的目录,打开作为 vault 即可使用。

定时备份

先安装 Termux 上的 cron 服务:

pkg install cronie termux-services

然后退出 Termux 重新打开,运行:

sv-enable crond

运行 crontab -e 来创建一个定时备份的 job:

*/2 * * * * ~/sync_repo.sh

每两分钟自动备份一次,我的 sync_repo.sh 是这样的:

#!/bin/bashcd  /data/data/com.termux/files/home/storage/shared/obgit add -A && git commit -a -m "android backup: `date +'%Y-%m-%d %H-%M-%S'`"git pullgit add .git rebase --continuegit push

上面的同步脚本很粗暴,如果冲突了我会把冲突一起提交进去,但这也是合理的,因为我需要让自动同步尽量成功,至于冲突可以在笔记本上解决。如果 Termux 进程被杀了,自动备份将无法自动运行。但在我的日常使用过程中,这倒不是一个大问题。


参考:

读《走出戈壁》

最近读了单伟建的《走出戈壁》,作者是个著名的金融家、投资人。我对这位作者不熟悉,但看完后觉得非常好,所以推荐给大家。

这本书记录了作者从小时候的经历、年轻时的知青生活、美国求学的回忆,算是一部回忆录。原版是用英文写作的《Out of the Gobi: My Story of China and America》,但中文版据说不是直接翻译过来,而是很多部分重新用中文写出。我猜还有一些英文版的内容如果翻译过来,那这本书就不能出版了。

知青下乡的书我看过一些,最早的时候是偶然发现家里有一本叶辛写的《蹉跎岁月》,所以就看了起来。那个年代于我这种 80 后而言很陌生,但小说中人物的某些心理特征对那时候的我来说很熟悉,比如羞涩和自卑等。这本书我后来又陆陆续续看了几遍,里面也有些爱情心理的描述,算是我看得比较投入的第一本小说,所以至今仍然印象深刻。

王小波也写过不少关于知青岁月的文章,那个年代里每个人都背负时代的枷锁,出身和成分很大程度上决定了人的命运,大部分人因为十年的浩劫失去了接受教育的机会。

有些自传和回忆类的书读起来会有点自吹自擂的感觉,而这本书里作者用了一种看似云淡风轻、带着些许幽默的口吻写成,而细节很丰富,阅读中仍会让人感到戈壁凌冽的北风,那样的生活真是太苦了。

一群年轻人被放在了戈壁滩上,总得找事情去让他们去做做,完成自我的”改造“,日常生活就是饥肠辘辘地”修理地球“。里面有不少这类事情,让人很辛苦地去做完而结果看起来没什么意义,比如部队让大家去挖土豆,结果挖出来又没开车去收,大部分又烂在了地里;比如让大家去修土壕,然后无止境地半夜做演习,结果少部分人被埋死在了土壕里。

这样折腾几次之后,大部分人都会“看破红尘”,开始随大流地磨洋工,而作者的心态是”干什么事都要干好,否则闲着也是浪费时间,而且争强好胜,虽然身体瘦弱,但不甘人后,如此而已。“

没什么英文资料可读,就反复看药品说明书里的英文单词。积极认真的工作态度,抓紧时间学习一切东西,因为这些他才能后来被推举成为工农兵大学生。一个让我印象深刻的是他处理人际关系的方法,当遭受到他人的算计时,并未过多抱怨他人,而是认识到这本就是人性中存在的恶,然后从自己的角度去尝试解决这些问题。他开始了一个广结人缘的计划,还能用一些看起来很隐蔽的方法,比如让父亲寄书过来学着当排球裁判,让更多其他连的人认识他。能站在旁观者的视角审视自己和周遭处境,并找到解决办法,这对于一个 20 岁左右的年轻人来说是非常难的。

作者在前两年的大学生推举中仍被刷下去了,大致是因为和领队的关系不够密切。这两次对作者来说是很大的打击,所以抗搓能力非常重要,即使非常难过也得在人面前保持平静:

  • 📌 漫无边际地走,一边走,一边放声大哭。
  • 📌 那天晚上,我很晚才回到宿舍。我告诫自己,不能放弃,无论受到多大的挫折,都不能放弃,放弃就是对自己的犯罪。我必须坚持下去,继续努力,等待下一次机会。

所以说,那个时代的大学生,不是纯考试的,但能通过群体推举去上大学生,绝对是非常不简单的人。经历过那个年代的苦之后,以后什么学习上的苦都是不足挂齿了。作者上大学之后,学习和成长的速度都是惊人的,10 年间从一个戈壁知青做到了藤校的副教授级别。他到了美国之后在两三周之内就能说服校方和教授,为自己定制了一个特殊的学习路径,并在两年内拿到硕士学位:

  • 📌 我承认,美国体制的灵活性对于我来说是如鱼得水。在国内的体制下,当初上大学有如登天,几乎没有自由选择的权利。
  • 📌 在最心灰意冷的时候,我反复提醒自己,自我放纵就是对自己的犯罪。基于这个信念,我从未放弃,而是坚持不懈地努力,刻苦读书,才有了今日。

其中的一个感人的故事,教授夫妇发现作者很想拿一个学位而且学习能力强,但是没有足够多的钱来应对学业开销,所以就谎称说有人匿名资助了他,其实就是教授夫妇自己资助了他。我猜想也许是因为作者赶上了新中国第一波留美学习的时机,不少人对他们是有好奇心态的,或者是“自助者天助之”。

还有一个小故事说明作者深谙体制里那套规则,并且做事很有智慧,他是通过基金会的一个留学考察项目去美国的,所以读硕士学位其实并不在计划内的:

后来我明白了为什么亚基会的官员们不热心,他们担心如果为我破例的话会影响基金会与外贸学院的关系。安迪表示,他要给外贸学院的领导写一封信,征求北京的意见。

我说你不能这么写,他问我为什么。我说,如果你征求北京方面的意见,他们就要研究是否批准。只有两个可能——批准或者不予批准。批准了当然好,但是如果不予批准,我怎么办?安迪问我还有更好的办法吗?我说有,你就给北京发个贺电,说我学习成绩优异,校方决定给我奖学金,只需延期一个学期,就可以获得硕士学位,对于这样的成绩,亚基会向外贸学院表示祝贺,其他的都不必说。

安迪将信将疑地接受了我的建议,草拟了一封电报,赞扬了我,把我的成绩归功于外贸学院的领导知人善任,表示祝贺。两周后,安迪打来电话,说外贸学院回电了。“怎么说?”我焦急地问。他停顿了一下,说:“只有四个字——‘非常感谢’。”我心花怒放。

正如我所料,谁能拒绝别人的道贺呢?后来,外贸学院的领导还专门给我写了一封信,对于我在美国的学习成绩表示满意,鼓励我再接再厉,早日拿到学位。

看这本书的过程中,我会想起自己最努力的初中时光。那是我第一次读寄宿,学校的物质条件也很贫乏,每次下完课去吃饭都得百米赛跑,不然自己的饭就会被瓜分掉。另一个深刻的印象是冷,热水也总是需要抢。生活虽然清苦,但那几年我开始感受到学习和思考的乐趣,上自习做到半夜也不觉得累,我当时觉得几何证明题目很有趣,第二天早上五六点又会爬起来去教室里早读。回想起来,我后来再也没那么专心和努力过了。

匮乏和苦难也许真能磨砺人,在那样的大环境下如何生存,在逆境中保持乐观、有所成长,这本书里所描写的是绝大部分人无法做到的。可以修改一下长者那句话:一个人的命运啊,当然要考虑到历史的进程,主要还是靠自我奋斗。

成功申请 Rust Foundation 2023 Fellows

很高兴成功申请到 Rust Foundation 2023 Fellows,我认为自己投入到 Rust 之后运气很好,两次申请到开源上的资助,很幸运能够在 cryptape 技术氛围这么好的环境里远程做开源项目。

也许是因为我践行了创造运气的方法:多做 + 多分享,所以顺便多分享一些其他想法。

三年前,我离职时不知道自己未来如何走技术路线,在国内很多职位都很卷,当时我对工作和环境都厌倦了,所以离职换了公司和城市。我在微软的岗位虽然是技术的,但做起来比较无聊,好在业余时间比较多。

闲暇能激发创造力和保持动力,很感激前公司微软包容和良好的工作环境,在苏州的两年里我有时间和精力去找自己感兴趣的事情,我重拾了写作和开源,这让我的生活变得充实,又因为些巧合开始给 Rust 编译器做贡献,从中得到了很多乐趣和收获。

没想到后来逐渐走上了 Rust 开发这条路,再回想起来过程也算是漫长的了,从 2014 年开始接触 Rust 到如今完全以写 Rust 为生,从观望学习、业余投入、全职投入这个过程快 10 年了。回想起来我对编程语言的兴趣是从看 eopl开始的,而再往前是因为 scheme,再往前是因为偶然用了 emacs,所以年纪越大越觉得这句话太对了:

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

Rust 让我开启了一个正向循环,比较容易能在一些开源项目上做出贡献,能看到开源社区里面有很多其他和我类似经历的人。

Rust 社区里另一个吸引我的地方在于有很多乐于分享的技术人,我们可以从世界上这些优秀的工程师身上学习,比如最近我喜欢看 Jon Gjengset的频道,他一期直播就有 2、3 个小时,讲解得非常细致,涉及到的主题也非常宽泛,有分布式、Rust、算法、读博和生活上的体验等等。

当然长期做开源很难,只有真的热爱才能持久,而对喜欢做技术的人来说开源是可能会上瘾的。这一年多里,给 rustc 做贡献好像已经成了我的习惯,业余时间找个 issue 试着解决就像是玩一把游戏,所以我做的事情大多并不难,而只是需要时间和耐心。国外程序员的一大优势就是有空余时间,生活负担不大,并且有足够的耐心去做周期长的事情。

这些资助算是兴趣的副产物,这次 Fellow 项目的一个好处在于可以找 mentor 来指导自己,我还在尝试找打算做的具体领域。上次 Project Grant 让我尝试了些新鲜事,比如录制播客、在 Conf 上公开演讲,这些都是代码之外的一些体验:

感觉上面的播客和演讲的内容大多差不多,打算以后会在博客里再写点技术细节相关的博文。

做得越多,越觉得自己还有好多东西需要学习,我算不上编程语言的专家,只是个业余的爱好者,希望能在接下来时间里有更大的成长。

远程办公的体验

我断断续续也有好几年的远程办公经历了,从疫情刚开始那会儿,我还在大疆工作,在家办公一个来月。2020 年下半年开始在微软,因为疫情那两年一直反反复复的,所以公司长期都是混合式办公,我通常每周会在家待两天,到了 2022 年大部分时间都是在家办公。目前在秘猿则是完全远程办公,我还从未去过公司办公室 :) 。

远程办公有好的方面,也有一些需要克服的困难,这篇文章我总结一下这方面的想法。

前提条件

并不是所有团队都适合远程办公,因为有的岗位需要频繁交流,而面对面沟通肯定是会更高效的。就软件开发这行来说,如果公司要实施全远程办公,需要满足几个条件:

  • 有效的管理、分工和协助
  • 员工有足够的自驱力
  • 公司的 IT 支撑

这些缺一不可,下面我稍微解释一下。什么是有效的管理,通常员工人数到了一定规模都会强调管理,然而很多公司做的是过程管理而不是结果管理,比如统计员工的加班时长,这是在衡量员工的上班过程,也许是因为没有更好的办法来衡量产出、或者是为了压榨员工,反正这就是一种管理上的失败。

远程工作本质来说就是放权,关注结果而非过程。就纯软件开发这行来说,工作结果是相对容易评价的,比如功能是否高质量地完成,方案和设计是否合理等,项目进度等等。

如果公司让员工远程办公,意味着相信员工能够自己管理好时间和进度,而公司也有合理地方式来验收结果。这要求员工有足够的自驱力,而且员工也对工作内容有足够的兴趣,如果一个人对工作内容没什么兴趣或者是排斥的,那远程的情况下就会更糟,因为人都是有惰性的。

远程最大的困难当然在于沟通,所以一个员工日常需要沟通交流的人数非常重要。通常一个小组就是日常协作的单元,15 个以内是相对可行的范围。对管理者而言可能是个更大的挑战,对 IC 来说日常沟通的人数通常是 4、5 个人以内。

另外公司的 IT 支撑很重要,如果工作中涉及到机密文件,而对应的 VPN 等工具不够完善,在家工作就会成为灾难。比如疫情开始那会儿,我的远程办公体验就非常不好,需要连入公司的网络才能访问某些文件,而且速度不稳定。微软的 IT 工具好用些,但连入生产环境和服务器之类的会非常麻烦,需要专门的另外一台笔记本来操作,用一台价值一万多的笔记本来专门连 VPN 确实很浪费,但这也可以理解,毕竟安全对于 ToB 的业务是更重要的事,只是日常带两台笔记本实在会很麻烦。秘猿的 IT 是专门为远程考虑过的,比如公司不提供办公设备,但会提供一些 IT 补助,员工可以用自己的设备来办公,代码都在 Github 上开源的,所以办公体验非常好。

异步沟通

异步沟通需要时间去适应,也更适合我这样的偏向于文字交流的人。在不能得到及时反馈的情况下,就需要把一个事情尽量用简单直接的文字把事情写清楚,并且需要考虑到对方可能会缺失的信息。当然,实时的文字沟通也是很重要的,适当地交流工作之外的事情,可以和线下没见过的同事培养出默契和情感。

软件开发中要达成有效的异步沟通,写好文档尤为重要。这对很多开发人员来说是一个重要的挑战,相比而言程序员更想写代码而不是文字,但文字和图都是更大范围表达自己的工具,你可以写给同事看,也可能需要写给用户看。如果无法通过文字表达清楚,意味着还没想清楚,那用代码也无法表达清楚。

所以,有的公司在面试时会看看应聘者是否有 Blog,主要也是想看这个人有没有文字表达的习惯,以及能不能把事情写明白。

就工具方面,我觉得邮件是个很好的方式,但相对来说国外开发人员更适应邮件。Slack 和 Discord 也不错,但感觉 Discord 相对来说更实时些。文档协作工具比如 Notion、Office 365、飞书等都行,我认为只要能有协同编辑就好。

除了异步沟通之外,一些在线的会议也是非常有必要的,但不宜过长,而且最好在开始之前让参与的人都了解会议的主题和相关资料,这样会更有效率。

我认为自己完全适应了远程办公的阶段就是培养出用文字记录工作的时候,我每天在 Obsidian 上都会建一个当天的文本,按时间顺序记录自己做的什么事情,或者是参与的会中的一些要点。然后通过标签做一些标注,还有把 Todo 给汇总到固定的页面。我在开会之前都会用文字记录会上要谈的要点,也会把一些零散的感受记录下来。

工作效率

通常来说,一个人的有效办公时间是到不了 8 个小时的,所以在办公室里面一直耗着就是耗着,很多时候都在摸鱼耗时间,有的会议就是大家都在摸鱼。

远程办公可以更好地利用碎片时间,以我的感受来说,如果是办公室办公通常下班后我再也不怎么去思考工作上的事,因为上班和下班是有一个明显的界限的。但在远程办公模式下这个界限会很模糊,可能我这会儿在办公,一会儿下楼去取快递了,或者我需要去接孩子之类的。所以很多时候,虽然我不在屏幕前,但我也会脑海里在考虑些工作上的问题。我反而觉得这种情况下会有更多的想法冒出来,比如人在洗澡的过程中会迸发出新的想法,这是很多人都有的体验。

这也是我在做开源的过程中得到的一个体会,因为大项目的开发者会遍布各个时区,所以绝大部分时间都是异步沟通。如果我彻底理解了一个问题,我就可以离开屏幕,随后时不时地去考虑这个问题了,等有了想法再回到屏幕前继续。

当然,在和他人讨论的情况下也可能会冒出想法,但总体而言群体讨论主要是为了达成共识,而更多好的想法是个体产生的。

在家办公一个影响效率的因素是环境,调皮的孩子可能是一个工作上的干扰,但我觉得问题不大,这也需要和孩子协调好。有时候我晚上思维更清晰、效率更高,因为晚上没人打扰,自由安排的情况下我可以更多地利用高效率时间工作,所以我在远程办公的情况下效率倒更高点。

对于大公司而言,整体来说远程办公的总体效率估计还是有损耗的,这也是硅谷大公司想让员工回到办公室的一个原因。但很多人宁愿少拿一些钱也想继续远程办公,因为就个人来说可以节省很多不必要的时间成本,这对于有孩子的员工来说真是太重要了。

心理问题

我看到很多人说远程办公会很孤独,我对此感受不够强烈,大概是因为日常经常和家人在一起,而且我还有两个小孩。如果没有小孩我估计也会感到孤独,即使结婚后也是容易孤独的,而和小孩相处完全是另外一种模式,我想这也是人类生小孩的一个重要原因吧。

但远程工作之后,确实会有一种脱离感,就好像没有进入社会的正常节奏。

脱离感也来自社交圈更小了,和同事之间的沟通基本发生在线上,而除此之外认识其他人的机会也少。我能想到的一个办法就是约老朋友线下见见,或者主动约一些线上认识的人聊聊,也可以线下见。总体而言,年级越大好像越容易产生孤独感,不容易深交,平时交流的人也都是些认识了十年、二十年的人,我不知道其他人是不是有类似体验。我倒是发现自己全职远程后,真的见到线下朋友会更有交谈的欲望,这大概是憋出来的。

另一个感受是,我远程工作之后倒更不容易焦虑了。细想一下大概是我抛去了办公室的一些不良因素的干扰,比如同事之间的竞争等。不是说远程没有晋升的压力,但我觉得从心理上我不是那么在乎了,而更在乎的是如何做好工作和如何提升自己,因为远程的情况下好像自己和公司更为平等的一个状态。不把自己和公司绑定,从物理上做到了就更容易从心理上达成这点。

如何找远程工作

最近确实能看到大量工作在流失,我身边失业的人越来越多,在这种情况下找远程工作只会更难,但这并不意味这没有机会。

我之前总结过一些工作,但我知道现在这个列表里很多公司都没在招人了:
remote-jobs-cn: 国内远程办公职位

这里有一个更全的、看起来还在更新的列表:
remote-jobs-in-china: 支持远程办公的中国公司

如果英语足够好,可以尝试找一些国外的远程机会,我在 Linkedin 看到还是有些的。区块链这行现在是熊市,所以工作机会也少了很多,但远程工作的比率相对大,大概是这个行业的人确实在践行分布式和无中心化,Web3 Jobs: Blockchain 这个站点上会有相关工作。

我能想到的另一个途径是,尝试找一些招人的、自己感兴趣的开源项目 (背后有商业公司运作的,可支持远程的) – 这样的项目也挺多的,然后给项目做贡献和社区的人熟悉,逐渐成为远程员工。虽然过程会比较耗时,但这确实是个途径。


远程办公还有很多其他好处,比如我现在可以把车的油耗保持在 6L 左右,因为我基本都在错峰出行,很多地方的人流量在工作日会少很多,包场看电影是很常见的。我们还可以做地理套利,比如去生活成本更小的地方生活。我看到公司有个数字游民计划,就是几个同事一起约好去一些未曾待过的城市和地方边工作边旅行,真是很羡慕这样的自由生活,可是我有两个小孩需要照顾😂。

总体而言,我已经习惯了远程办公,好像就再也回不去坐办公室的日子了,这是适合我的一种工作方式。

升级我的 localhost

因为开始了全职的远程办公,所以我想把自己的 localhost 打造得舒适一些,最近一直在断断续续升级工作相关的设备,对于整天生活在屏幕前的数字宅来说这犹如买新房和装修吧。

我对设备的要求并不是很高,但年级大了多少有点职业病,所以我打算这次尽量找些好设备来满足自己,主题就是“关爱中年程序员”。


Mac 及应用

我近两年都在使用 PC 笔记本当主力开发机,最近几个月重回了 Mac 的怀抱。即使苹果生态有我之前提到过的各种问题,但 M2 芯片的 Mac 性能和续航我都很满意。不过我也花了好些时间来找称手的工具和配置。

我买的 Mac 是 32 G + 12 Core + 1 TB 的中等配置,这个配置完全满足我日常需求,大概是因为我还没什么视频剪辑类的事要做,我的主要需求是编程、写文档、浏览网页这些普通事项,一周需要带出去两三次,因为我又不玩游戏,所以 Mac 还是挺适合我的。

14 寸的 Mac 外出办公稍微有点重,如果你已经有适合外出携带的笔记本,在家里放个 Mac Mini 也是很适合的选择,因为 Mac Mini 价格太美丽了,而且接口更丰富。新款的 Mac Air 看起来也很不错,也许 M3 是个入手的好时机。

我用了两个来月才完全重新适应 Mac,下面谈谈一些配置和应用:

首先系统默认语言使用英文,这样有个好处在于很多配置都可以用字母去搜索,应用的切换也完全不用中文,减少了切换输入法的动作。

我形成了一个使用习惯,那就是严重依赖各种 App 的 Command Palette,比如 VsCode 我把 Ctrl+L 绑定到 command palette,然后 Obsidian 和 Arc 也同样有 Command bar。使用 Command Palette 通过模糊搜索去跑命令是更统一的方式,因为快捷键太多了我根本记不住,而命令是一个个普通的英语单词,容易在心里念出来。

另外我会关闭所桌面和应用切换动画,这样操作起来会迅速很多。

Contexts

Mac 的应用切换简直惨不忍睹,而且这些年来都没有很好的改进。市面上有不少这类工具,足以看出很多人不适应系统原生的应用切换。特别是像我一样会用 VsCode 为不同的项目打开多个窗口,快速定位到窗口对我来说是一大刚需。

Contexts 这个应用是我想象中工具,完全贴合我的使用习惯和对细节的要求。安装后 Cmd + Tab 就替换了系统原有的应用切换,这是符合大多数人使用习惯的 Windows 风格的切换,另外我会把一个很重要的快捷键 Ctrl+I 绑定到 Contexts 里面的 search,这样我能快速通过部分关键词选中要跳转的应用。还有,Contexts 很贴心地有个自动学习用户使用习惯的 Number-Switcher,基本上我日常 右Cmd+W 跳转到 Wechat,右Cmd+D 跳转到 Discord 等等,真是提高效率的利器。

另外很多人推荐 Raycast,这款软件可以做很多自动化的功能,但目前我只是用 Raycast 来查找和启动应用。

Arc

我使用 Arc 接近三个月了,目前已经成为了我的默认浏览器。我认为最有用的是 command bar,可以输入 command,extension command,tab url,我把 Ctrl + L 配置到 command bar,这样我基本不会去关注 tabs 了,也不会去收藏网页,一切都是用关键词搜索。

其中的 Space 功能我也很喜欢,比如公司用 Gmail,而自己也用私人 Gmail 账户,Space 就可以把不同场景的同样网站区分开来。

Chrome 的所有 Extension 在 Arc 上都可以使用,而且我也不会再为插件配置快捷键,常用的命令通过 command bar 触发。

Easel 是 Arc 的另外一个好用功能,我们可以很直观地通过类似截图的动作就能组合成一个 Dashboard,比如我把邮件、Github PR、Meeting Schedule 组合成一个看板,能够一目了然地看到需要关注的信息。

Input Source Pro

这个工具用来设置一些应用的默认输入法,为什么这个很重要呢?因为我特别烦切换输入法,这是一个很干扰心流的动作。

比如在 Terminal、Raycast、Contexts、VSCode 这些应用里面,95% 以上的概率我都只会用英文输入,所以配置这些应用的默认输入法就能很大程度上减少切换。

这类工具有好几个,我用得最舒服的就是 Input Source Pro,这个工具还在 Beta 阶段,目前免费。

Karabiner

这是修改快捷键必备工具,我做了一些方向键的配置,另外配置 Ctrl 的键,因为这比 Cmd 好按:

- Change left_command+hjkl to arrow keys- Change left_command+u/i to page_up/page_down- Ctrl+Z => Cmd+Z (Undo)- Ctrl+T => Cmd+T (New tab)- Ctrl+W => Cmd+W (Close)- Ctrl+S => Cmd+S (Save)

不管是 PC 还是 Mac,我必须做的配置是把 Caps Lock 映射为 Ctrl,因为我们很少使用 Caps Lock,而这个键位是非常适合小拇指去按的,如果你是键盘党,这样配置可以很大程度减少左小拇指的损伤。

Rime 输入法

大半年前我改变自己的使用习惯,强制自己使用双拼输入,目前我已经完全适应,总体而言我认为双拼没有极大地提高我的输入效率,但确实减少了很多不必要的按键,另外我觉得敲字的节奏感会好些。

我之前看到很多人吹小狼毫,但几次打开那些文档我都没有折腾的欲望,大概是我对输入法也没有特殊的需求,系统默认或者搜狗之类的都行。

两个月前偶然在 Twitter 上看到一个人推荐 Rime 雾凇拼音,这次我试了试。虽最后还是花了点时间折腾,但我觉得这个投入是值得的。Rime 的输入体验是好过 Mac 原生的输入法,没有任何多余、花哨的功能,你不输入时不会感觉到它的存在,并且支持我喜欢的小鹤双拼。但这东西就是注定比较小众,配置个输入法需要用到很多 Yaml 文件估计会劝退很多人。

我另一个比较特别的配置是,不像大多数人那样通过按 Shift 来进行中英文切换,因为 Shift 是一个常用键,容易误切换输入法,另外一个原因是我希望有一个唯一的标识来识别目前的中英文状态,而 ShowEdge 就是这样一个工具,我在屏幕特定的边沿会配置一个小圆圈,如果是红色便是中文,如果是黑色便是英文。这样不会存在我开着 Rime 输入法,但是输入的是英文的情况。我使用 Ctrl+J 或者 Caps Lock 来切换输入法,因为 J 是右手最容易默认找到的按键。

键盘和鼠标

我以前也主要看重键盘的外貌和敲打手感,所以我买了个 HHKB,后来也买了宁芝等各种小尺寸的键盘。最近两年我越发觉得肩胛骨酸疼,特别是右肩胛骨,有时候晚上疼得我睡不好。

我稍微调查了一翻,感觉确实是因为自己长期的坐姿和使用键盘的习惯造成的。Mac 的键盘和各种小尺寸键盘,因为宽度不够,两个手都要往中间靠,这样肩胛骨就长期保持这个姿势容易出问题:

人体工程学这东西有的人说是智商税,但我还是试试吧,于是我购买了套罗技的人体工程学鼠标键盘

这个罗技 K860 尺寸巨大,其固定的手托材质舒适,这键盘需要大概一周左右的时间去完全适应,毕竟很多人的指法也是不对的,这种双手分离式键盘需要大致正确的敲打指法。

唯一的缺点是数字小键盘,毕竟我们大部分人是不用数字小键盘的,这有点浪费空间。刚用的时候我觉得很难受,我需要伸长手去摸我的鼠标,所以很想退货。但巧的是我买的是个套装,里面还有个轨迹球鼠标。当我把这两个设备这样组合起来时,小键盘的问题解决了:

使用轨迹球也是个神奇的体验,刚开始觉得操作起来太慢,适应了之后觉得右手轻松不少,反正只需要移动大拇指就行。同时鼠标也可以使用键盘的手垫,而且如果移动键盘鼠标也可以跟着移动了,配合 left_command+hjkl to arrow keys 方向键那里我也不会去按的。

很多程序员不喜欢用鼠标,但我最近发现鼠标的前进和后退键其实非常有用,比如我看代码的时候,按住 cmd 键点击鼠标可以跳转到定义,然后按鼠标的后退键返回之前的位置,这比一直使用键盘会舒服很多。

Mac 的 Trackpad 手感和体验都是很好的,但因为 Trackpad 也是居中的,和小尺寸键盘同样用久了同样容易劳损

如果你用外接鼠标,还需要另一个小 App 来配置一下。因为我们通常适应了 Mac 默认的 Natural scrolling,但是鼠标用这个选项就会很诡异,所以我找到了 Scroll reverser 这个工具,可以单独设置滚动的控制方向:

我对这套设备非常满意,肩胛骨酸疼这个问题很大程度上得到了缓解。现在我偶尔外出使用原始的 Macbook 键盘和 Trackpad 时,我会极其难受,很难想象自己使用这个姿势这么多年,不出问题才怪。

但这临时的缓解也可能是只是因为换了姿势,彻底解决长期的问题,大概只能尽量少坐多运动,不要长期保持同样的姿势太久。

Herman miller

我之前的椅子扶手快坏了,然后想着买个新的办公椅。按照这次升级的主题,直接选择了购买 Herman Miller 这把号称世界上最舒服的椅子。

我之前偶尔试过同事的这款椅子,确实很舒服,但我自己买的刚开始坐上去觉得有些偏硬,后来找了些视频资料发现是我的坐姿有点问题,这椅子适合正坐而不是半葛优躺那种坐姿,用了几周后确实能感受到差异了。二代的前倾功能很适合专注的时候使用,而这个功能在目前的椅子上相对少见。

由奢入俭难,再也回不去了,如果这把椅子帮我纠正了坐姿也算是值了:

其他

这期间我还新增了些其他设备,比如 4k 显示器、支架等等,加上多年前买的升降桌等就完全够用了。我推荐的另一个小设备是韶音的骨传导耳机,我经常带这个耳机半天一天的都不觉得难受,而且这个品牌的质量和售后我非常满意。

最近我还看了看桌面的布线之类的东西,毕竟作为数字宅男是无法拒绝一个类似这样的桌面美学:

什么东西但凡涉及到美学就会是个无底洞,然后我开始怀疑自己是不是要掉进另外一个坑,需要及时止住了,所以我买了个隐藏电线的盒子把桌面搞干净点就够了。

总之,我对现在这套办公设备非常满意,程序员要对自己的身体好一点,毕竟这些东西差不多占据了日常的大部分时间,所以值得投入些时间和金钱在上面。

如果你有什么好用的设备请推荐给我,虽然我现在也不一定会买,但我喜欢种草 😜

学习英语的新工具

我之前写过文章强调英语的重要性,这些年我也一直还在注重提高英语能力。虽然我在外企工作了两年多,但其实日常表达中使用口语的时间不多,所以口语提升有限。

最近我发现了些新的学习英语的好工具,顺便分享一下自己的一些心得。

Discord 英语小组

Discord 是我新工作的日常即时沟通工具,Discord 的服务器上有很多英语练习小组,我习惯的是这个 ,在这里可以和全世界各个地方的语言学习者聊天,有三四人以上的房间,也可以两个人进行一对一聊。

这个方法是和一个读者交流时他告诉我的,他在短时间内提高了口语最后面试成功。我使用 Discord 练习口语已经有一个半月了,我觉得效果非常好。

可能是因为时区原因,里面大部分是亚洲和中欧国家的人,比如印度尼西亚、印度、泰国、土耳其、俄罗斯等,据我统计大学生居多,也有不少高中生。这些人虽然不是英语母语者,但大部分比中国普通的英语学习者要好。

你在 B 站可能也看到过一些人用 OME TV 之类的软件来练习英语,但如果你自己试过就知道这不适合练习英语,因为总会碰到奇奇怪怪的人,我就碰到过一个恶作剧少年,聊着聊着突然给我来了个恐怖的鬼脸,还有会碰到色情等。所以想在上面找到合适的人时间成本太大,而且也很难停下来进行一些较为深入的话题。

我之前也付费在 Cambly 上提高口语,但我现在觉得那种方式太正式,用 Discord 比较随性,默认不用看到对方,所有注意力集中在听和说上面,也没有犯错的心理压力,适合我这种有些社恐的人。有时候我一边爬山一边和人聊,目前能比较流畅地用英语沟通很多方面了。我们聊的大多是一些日常的话题,如果碰到些计算机相关的从业者和学生,也可以聊聊技术方面的事。

另一个好处是能够与来自不同国家和文化背景的人交流,从而获得不同的感受,更深入地了解这个世界。除了一些常见的国家,我还与来自蒙古、埃及、巴基斯坦、孟加拉国和也门这些小众国家的人聊过。

我印象比较深的是一个也门的初中生,她说她不能上学了,因为自己的国家在内战。我不知道也门这个国家原来还如此动乱,回来后通过搜索去了解一些背景。我还碰到过一个埃及人,他的工作是客服,他想要学习英语因为英语客服的工资更高,因为他有残疾几乎一个多月没怎么出门了,那天我们聊了很久。我碰到过俄罗斯年轻人,他说现在非常恨自己的政府,正在想一切办法逃离俄罗斯。还有碰到过一些纯粹的语言爱好者,他们能流利地说几种语言,模仿能力极强。

有的人聊得比较投机就会加个好友,以便保持联系。因为同是语言学习者,所以大部分人都比较有耐心,有时候表达不清楚了,有的人也会共享屏幕给人解释。如果在屏幕前,我喜欢打开 Google 实景,和对方聊聊他们生活的国家和城市。也许是我太久没出去了,对 Google 实景比较着迷。

我和大部分中国学生一样,即使英语的读写能力还行,但是口语一直很薄弱。语言这东西就是个日常技能,如果你掌握了基本的语法,就没那么条条框框,即使是发音不标准也不是什么大问题,正常和流畅的表达是需要很多自信心的,而如果没有练习就不会得到这种自信,如果你练习得足够多,在表达的时候就没有那个在脑子里翻译的过程。

Building Your English Brain这个课程很好,构建自信心的过程在于你能把简单的单词完全掌握,并且熟练使用,造句就是一个很好的锻炼方式,而和人聊天就是最自然的方式。

也许我的口音很难有大程度的提高了,但表达的自信和流畅度是相对容易提高的。

Trancy 插件

Youtube 是最好的英语资料库,这里面可以找到很多不同层次的视频资料。 Trancy for Chrome | Master a new language in an enjoyable way 这个插件可以让你进入几种不同模式去学习英语,比如跟读、单词考查等等。

这是最近让我眼前一亮的插件,特别适合用影子跟读法去用 Youtube 的资料来锻炼口语:

这个插件还在不断更新中,现在我们可以模拟很多场景,跟读并且获得评分,如果有不认识的单词还会自动给标注出来。

沉浸式翻译插件

这种插件 immersive-translate 适合看一些比较长的英文文章,我有时候也用来看 NewsHacker 之类的。但我不推荐一直打开这个插件,而只是在想要快速浏览文章获取信息的时候试试。因为如果你一直依赖这种翻译,就不容易培养出来阅读英文的习惯。

各种 GPT 及 AI 工具

ChatGPT 的翻译水平超过大部分翻译工具,我现在写稍长一些的英文都会让 ChatGPT 帮我润色一下。

之前我还试用过 AI 聊天软件 myshell,不过自从我用 Discord 和真人聊之后就觉得 AI 工具没什么意思了,还是和鲜活的人类聊天更有趣,即使人的发音没有 AI 那么清晰和流畅,但那种人与人之间的情绪感受和生活经历的分享,是 AI 所不能替代的。


学习一门语言犹如打开一个世界,而发现一种新的学习方式也犹如打开一个世界。如果你有什么好的学习方式和工具,欢迎和我分享 🙌。

新的旅程

因为家庭原因,我决定回到深圳常住。2023 元旦前夕,我陆续把东西寄回深圳,元旦后我在晨曦中登上了往南的列车。我那时候还没确定会离职,但目前找到了合适的工作,所以就于四月份从微软离职了。

在苏州微软工作的两年多,我遇到了很好的团队和同事,真的要离开了也有些不舍得。微软很大,每个部门的工作氛围可能都会有些差别。苏州工作的两年间我学到的这些:

技术,世界上很少有公司能用技术服务这么大体量和规模的企业用户,我记得上次看过一个详细的事故报告,写着影响的用户上十亿,写出这样一个 Bug 也是个难得体验了。微软的工作氛围很好,作为技术人待在里面很舒服。在一个大的组织里工作很多时间都是在沟通,如何推进项目,如何和同事达成共识,这些是非常重要的也是最难的。另一方面,在长达 20 年历史的项目上做维护和开发也是一份难得的经历,我入职那几个月基本都在看代码,极大地提高了我的在编程上的韧性。另一方面,在一个如此大的项目上工作总感觉是在戴着镣铐跳舞,大范围地修改代码是很难的,很多时候都顾不上代码的好坏,一切都以稳定性为重。

包容,这微软的企业文化。公司里有各种背景的人,而 Leader 大多会遵循员工自己的一些想法。如果一个员工犯错了,很可能是组织和流程的问题,而不是这个人的问题,所以在做事故分析的时候,都在就事论事。也许也是因为自己年纪越来越大,我对很多人和事都更包容和平淡了。

生活,苏州的生活很舒服,感觉比较清淡,晚上八九点街道上的人就比较少了。我住在苏州的工业园区,人口密度相比深圳小很多。周末经常去湖边和公园玩耍,在这两年间我开车去周围都逛了逛,我喜欢去太湖、独墅湖、阳澄湖、诚品书店这些地方,风景都很好。工作之外认识的人不多,但也有舍不得的朋友。有一次我在金鸡湖旁边看到一家三口在夕阳下露餐,他家的女孩和我大女儿差不多大的样子,养着两只小鸭子作为宠物。我正被这幅和谐画面吸引,没想到我女儿也被两只鸭子吸引过去了,然后我们一起散步玩耍并留下了联系方式,周末经常约着出来遛娃和闲聊。这两年间我的社交圈更小,但留给自己的时间多了,找一些自己想做的事情。平时我花了很多时间在二女儿的照顾上,和孩子玩耍是是一种最好的休息。

所以,这两年不管从生活还是工作的角度我都是满意的。2020 年我攒了很大的勇气离开工作了六年的公司和城市,如今我又花了很大的勇气改变。其中很重要的一点还是父母方面的考虑,我在另外一个城市待的这两年,和父母相见的次数不足十次。The Tail End 这篇文章用残酷和直观的数据让人认同这点:Living in the same place as the people you love matters.

抛去一些不能改变的家庭原因,我还想要什么其他改变?从另一个角度看待,人生是一个游戏,不能暂停,不能回滚,但必然有终点。在这些基本限制下,有的人会选择一直玩一种剧本,而有的人会选择多玩一些剧本。在我的履历中,我认为年轻的时候探索和尝试还不够,所以现在想趁还没老到不能折腾阶段,想改变就想试试,我还有好奇心。

另外关于如何过好这一生,对我有启发的观点是李自然的如何把一辈子活成 N 辈子,这个视频值得看看。其中很重要的是需要做减法,走出舒适区,保持提高。这倒不是说要赚多少钱,而是既然我们大概无法控制长度,那我们如何从厚度去扩展。

成功就是不断地达到自己理想的生活状态,我的理想的生活状态是更自由,并且能有足够多的时间和精力陪家人,做技术和开源,所以全职远程是更适合自己。当我觉得未来可能离开微软的时候,就是抱着这样的期待开始留意一些工作机会。

可刚回深圳的那段时间,因为一些突发问题家人住院,所以这几个月我非常忙。父母年迈生病,孩子幼小,任何人到了这个阶段都不太容易吧。印象深刻的一次是我开车去给家人送饭,但因为实在太累,等红绿灯的时候想着迷眼一会儿,结果我居然睡着了,隔壁的司机下来敲我的车窗才突然惊醒,估计我就睡着了几十秒,但醒来后像是睡着了好久。

这阶段比较辛苦,幸好现阶段结果还好,深圳的医疗虽然比不上北上广之类的城市,但也有些资深的好医生在多地的跑,在常见的疾病上是能找到靠谱的医生。

另外今年工作机会不多,在我上面所列的期望条件下就更少了。我之前收集过一个远程工作列表,很多公司今年基本不再招人。幸运的是我找到了一份自己挺满意的工作,就是在 Cryptape 做区块链和 Rust 相关的开发。我知道区块链这行现在鱼龙混杂,很多人现在也并不看好,我认为这里面有很多新东西可以尝试。秘猿也是国内很少的那种企业,在做一些新事物的探索,同时给了员工很大的自由度,公司里几乎全员远程工作,所有代码也都是开源的,通过我入职后的一个月感受来说内部氛围很好。

这次我花了比较久时间来做决定,特别是家人不太理解我人到中年为什么就变得更激进起来。作为大龄技术人,在国内换个靠谱的工作并不容易,但我还没到退休的年龄。我没那么大动力在一个公司里按照既定的职级路线去爬,但还有动力去写代码,提高自己的编程能力,在开源的世界里进步。

微软是个令人尊敬的良心企业,这个有接近 50 年历史的企业再一次抓住了历史的风口。在和组里告别的时候,我说现在也许不是一个离开公司的好时机,这感觉就像是火箭正要发射而我却要下来。若干年后,再回顾起来看我的选择,是不是会显得我很愚蠢地偏离了大势。有可能,但更重要的是人要自洽,每个阶段追求自己理想中的生活就很好,我现在的生活状态和预期的几乎完全一样。

这段时间两鬓多了一些白发,觉得时间越过越快,所幸还未被生活击溃,我所遇到的困境并不特殊,而是大多数人这辈子都会面对的。

以上就是这半年里的一些改变的总结吧。

不想当作家的程序员写不出 Redis

西西里岛,是位于意大利南部阳光而宁静的岛屿,正如电影《西西里岛的美丽传说》中演绎的那样,这里有着古老的历史和建筑,看起来和 IT 不沾边,却是 Redis 的作者 antirez 的居住地。

Redis 是互联网的一个基础设施,这个世界上大量的网站背后都有 Redis 的影子。相比于 Redis 的流行度,很多程序员并不了解 antirez 的故事。最近我看了他几乎所有的博文,和你分享一下我了解到的趣事以及我们能从这位 70 后的上一代程序员身上学到什么。

antirez 不是一个典型的意大利程序员,大部分当地人喜欢 boring-but-sure 的路径,IT 这行在当地算不得特别高薪的工作,大多数人不喜欢做过多探索,但 antirez 喜欢新东西和创造新东西。在一篇 10 年前的访谈中 antirez 谈到,住在意大利对程序员而言没有多大的影响,因为我们可以在互联网上经历有趣的一切:

If your target is the world, being here is not a big limit for a programmer. The majority of interesting things are happening on the internet nowadays anyway.

职业生涯初期,antirez 做过安全研究员,后来做过嵌入式、系统、Web 等领域的开发,他早年还发明了 Nmap 中的常用的扫描技术 idle scan

2009 年,当时 antirez 在做一个网站实时统计,他认为现有数据库比如 MySQL 无法满足那种写入密集、查统计数据的需求,于是他着手解决这个问题。

antirez 使用 Tcl 快速撸了一个名为 LLOOGG Memory DB 的模块,总共只有 300 行,但却解决了手里的问题并包含了 Redis 的核心设计,有 protocollist,还有 6379 端口!

随后 antirez 重新用 C 语言实现了新的版本,投入生产环境良好运行了几周,随后发表在 Hacker News 上并由此得到了更多关注,越来越多的公司开始在生产环境运行 Redis。

这里谈点题外话,Redis 最初在 Ruby 社区受到了关注,随后 Github、Instagram 等站点开始使用 Redis。Ruby 社区曾经是潮流的引领者,比如 Git 最初发表 Linus 也搞不懂为什么 Ruby 社区的人们这么喜欢这东西,后来就有了 Rails 写的 Github。虽然 Ruby 现在略显式微,但我们应该感谢 Ruby 社区的好品味给业界发现和创造了这么多好东西。

如果只是用来做缓存,2003 年开始我们已经有了 memcached,比如我 2011 年刚工作那会儿 memcached 是更成熟通用的组件,我还仔细读过 memcached 的源码,但为什么 Redis 能后来居上?

antirez 谈到主要有两点:

  • 对于密集写入的场景,特别是缓存相关的需求,Redis 可以节省成本,性能也很好
  • Redis 不只是缓存,而是一种不同形态的数据库,适合很多性能比正确性要求更高的场景

In the field of programming languages there is a motto: a programming language is worth learning if it is different enough from all you already know to change your mind, exposing you to new abstractions. Well I think Redis definitely is a really different database, and will change the way you think about your data.

antirez 从一开始就把 Redis 当作一个数据库来看待,而不只是缓存组件,简而言之 memcached 能做的 Redis 也行,而 Redis 能做到的 memcached 不行。

Redis 天然支持各种常用的数据结构,比如 list、set、maps 等等,这些数据结构让 Redis 可以应对各种业务需求,可以说 Redis 开启了一个 KV 数据库的新时代。

这个故事和 SQLite 的由来相得益彰,SQLite 的第一个版本只是个 Tcl 扩展,Git 的第一个版本只有 1200 行,这似乎印证了软件设计中的一个道理:运行良好的复杂系统往往由简单设计演化而来,而一个从开头设计的复杂系统往往不行,通过打补丁的方式通常也无法解决:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” – John Gall

Redis 和 SQLite 都深受 Tcl 的影响,而 Tcl 是一门 1988 年发明有着 35 年历史的语言。Tcl 继承着 Unix 那种设计可组合、小巧的组件并保持简洁接口的设计风格,antirez 认为自己的程序理念深受 Tcl 的启发,特别是 Tcl 里 All data types can be manipulated as strings 和命令的风格延续到了 Redis 里。而 John Ousterhout 当年是为了解决 EDA 开发 中的一个需求发明了 Tcl,在互联网浪潮还未掀起的 80、90 年代里 EDA 真算是个技术领域里的一颗明珠,衍生出了很多技术分支。

Redis 的源码可作为 C 系统编程的典范,还包含了很多经典的数据结构的实现,你可以读读这本 Redis 设计与实现 来领略一番。

随后 Redis 被 VMWare 赞助,后来又成立了专门的 Redis Labs。虽然 Redis 从一开始就是个热门的开源项目,但我们可以从提交数排名可以看出,在这近 10 年间主要是 antirez 一个人在做贡献和维护。

这是一个较为奇怪的现象,毕竟 Redis 是一个如此通用的组件,Github 上的关注度也很高,来自各种场景的需求会非常多。

但如果你仔细回顾 antirez 的风格,这就有了合理的解释。他认为对 Redis 来说,避免复杂度、保持稳定性是最重要的事,所以每天他面对众多的需求和 PR 时,大多数时候他都会说“No”,否则就会出现 Less stable code base, more problems 的恶性循环。

The bugs you write in the first implementation are extremely hard to fix later. They don’t go away easily. Basically there’s this process where you say, okay, I want to change something, but I want the software to remain stable. So you start to think about it for weeks, the way you want to do it, without writing any code.

每个新功能的引入必须要非常小心,Redis 的核心代码一直保持在万行的级别,并且在 4.0 版本之前都是单线程运行。

设计才是最重要的,而编码和实现是简单的,因为这只是水到渠成的事

Instead, there’s this huge design process. But because of this design, sometimes we can write a new feature using half as many lines of code in a much more simple way, a much more stable way. You think and think and think and find that a couple of days ago, what sounded like the best design — it starts to sound pretty lame, actually, and you find another and another. At the end, you understand that probably that specific one was the best, and then you start doing the implementation.

This means, in turn, that people say, don’t worry, I can help you implement this. And you say, no. If you want to help me, you have to put more time into the design effort. Writing the code is the easy task. The hard task is understanding what to do and in what way to do it.

我想,这也是我们作为程序员想要提升到更高层次必须意识到的一个方面,不要过多花时间关注在编码上,而应该是花时间在思考需求和问题、找到好的设计这些事情上

长久维护一个项目也会感觉到无聊,为了让自己保持兴趣,antirez 会尝试在不同的领域切换,比如一段时间做数据结构,过几周就切换到 cluster 之类的。并且除了 Redis 之外,他还在做更多 side project:

1) Load81, children programming environment.
2) Dump1090, software defined radio ADS-B decoder.
3) A Javascript ray tracer.
4) lua-cmsgpack, C implementation of msgpack for Lua.
5) linenoise line editing library. Used in Redis, but well, was not our top priority.
6) lamernews, Redis-based HN clone.
7) Gitan, a small Git web interface.
8) shapeme, images evolver using simulated annealing.
9) Disque, a distributed queue (work in progress right now).

作为程序员 side project 是一种探索也是一种精神休息的方式,并且程序员通常会在 side project 中显得更有创造力:

Like a writer will do her best when writing that novel that, maybe, nobody will pay a single cent for, and not when doing copywriting work for a well known company, programmers are likely to spend more energies in their open source side projects than during office hours, while writing another piece of a project they feel stupid, boring, pointless.

我粗看了一下这些项目,都是 C 实现的并且风格统一,README 都会写些自己的思考和设计选择。

antirez 喜欢写小的程序,这不只是因为可以控制复杂度,而是因为短小的程序自有其美 Fascinating little programs,老一代程序员喜欢在严苛的限制下挑战自己的技艺,比如 Writing an editor in less than 1000 lines of code, just for fun

独立维护一个影响如此大的开源项目会有巨大的心理压力,虽然用户并没有直接付钱,但维护者有责任去修复出现的问题。这种压力不一定是技术上的,也有来自社会方面的压力,比如不断有人指责他不把代码和 API 里的 master/slaver 替换掉。

antirez 曾经在一篇采访中谈到想在家里组成一只小队伍来维护 Redis,后来又感叹到现在太难找靠谱的 C 程序员了,愿意做 system programming 的越来越少。

antirez 在这篇文章中 The struggles of an open source maintainer 阐述了维护开源项目的难处,其中提到在 Redis 项目用户多了之后,自己需要一直处于在线状态。而他习惯的工作方式是工作一段时间然后彻底放空,他从来不习惯朝九晚五的定时工作制,甚至提到自己无法保持编程 40 分钟以上,他喜欢编码一会儿然后去带孩子或者运动一会儿再回来。

除了编程之外,antirez 对红酒和运动也很有兴趣,而他更有追求的是在写作这件事情上,可以为了写作放弃编程,这让我想到了王小波。

三年前,他发了一篇博文声明自己从 Redis 上退下来,因为他认为自己想做的是艺术家那样的创造性工作,编程也是自己表达方式的一种,而 Redis 发展到现在这个程度创意性事情更少,事务性的工作更多了,这不是自己所期望的:

I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer.

Redis 交给了几个核心维护者,这些人已经和他在开源社区有多年的配合,所以对社区来说这是个很自然的选择。

在停下编程的这几年,他默默地完成了名为 Wohpe 的科幻小说,这本小说是关于人工智能和气候变化等,原文用意大利语写成,但现在也有英文翻译版本。

I now know for sure: it is no coincidence that for hundreds of years writing has been considered the highest art in which to try one’s hand. By writing you look for things, and if you insist enough you end up really finding them.

写完小说后 antirez 还有些犹豫到底是回到编程还是继续从事其他写作,或者是边写作一边做些技术。直到前段时间,暂别了两年之后 antirez 终于通过 Advent of Code 找回了编程的乐趣,他解决了 18 道题目,并且在过程中又折腾出来一门 stack-based 的编程语言。从 Twitter 上看,最近他在做一些 LoRa 设备上的小项目,也折腾 Flipper Zero 这样的极客设备。

总之,antirez 的博客非常值得一读,其中有一篇 英语是我 15 的伤痛 让我很有共鸣,作为英语非母语的开发者,要融入到英语的环境中需要很多额外努力,而这是技术圈里大多数英文母语者根本不会在乎和谈论到的事。

他的博客里还有些好文章:

  • 编程中保持心流,编程中如果有新的想法和问题发现,你可以先记录下来以后再回顾,这叫作 Log driven programming
  • For me other people making money out of something I wrote is not something that I lost, it is something that I gained. Redis 使用 BSD
  • Arts are one of the few things worth life’s best efforts. Programming is art, if done in certain ways.
  • Life is too short to work like crazy for most of its part.
  • The mythical 10x programmer
  • Programming and Writing

看了这么多 antirez 相关的文章后,最让我印象深刻的也是好奇心,并且在好奇心的驱使下不断去做有乐趣的事。

保持兴趣,不只是技术上,生活上的兴趣也很重要,红酒、CrossFit、写作,以及冰激凌,antirez 和 Redis 的第一位用户 (老同事) 一直合开着一个冰激凌店!

人类的终极工具

乔布斯曾经说过:计算机就像自行车一样,它们是人类思维的自行车。计算机和自行车一样,能够帮助人们快速、高效地完成很多任务,是人类思维工具的一种。

随着 chatGPT 的出现,计算机这个工具彻底地进化了,它比人类懂得更多,能通过语言和人交流,懂得推理和归纳,帮你学习、创造,计算机也可以成为”人类思维的朋友“。

LLM 技术的破圈夹杂着兴奋和恐惧,很多行业都面临巨大的变化。

很明显的是 Google 危了。以我最近的使用感受来说,使用 Google 搜索的次数会越来越少,我只有在明确想查找些网页的时候才会去用 Google,而关于一个细节、主题的搜索和学习,我会先尝试用 chatGPT。

以我最近碰到的一个例子来说,我碰到一个单元测试用例跑失败了,从错误信息看是“conflicting output format options”,当我把这个场景描述出来后,chatGPT 给出了非常好的回复,而且我们可以通过继续追问的方式来学习更多:

当然也能通过 Google 来通过关键词搜索,但我知道这样会更麻烦,我需要从一堆沙子中去寻找有价值的东西,而且我不能和搜索引擎对话。

用 chatGPT 非常适合苏格拉底式的对话和探索式学习,比如我想了解一个主题:

接着我继续问:

  • what is bound lifetimes in Rust
  • show me some example code for Rust’s generic lifetime parameter
  • show me some example code for Rust’s higher-ranked lifetime
  • show me some example code for Rust’s higher-ranked lifetime in a trait
  • show me some example code for Rust’s generic lifetime parameter in a struct
  • show me some example code for Rust’s generic lifetime parameter mixed with high-rank lifetime
  • In Rust, can ConstGeneric work with lifetime parameter?

chatGPT 给出的回答都非常好,能让我就想关主题不断地探索。当然 GPT-4 就更恐怖,我一个朋友最近在上经济学的课程,每周的 quiz 基本都被 GPT 给秒杀。

我最近写了个几十行的 Python 小程序 chenyukang/talkGPT,通过 SpeechRecognition 和 OpenAI 的接口来进行英语口语对话,可以基本运行成功 (OpenAI 接口有时候比较慢)。后来我发现了其他公司做的这类产品 Telegram: Contact @samantha_x64_bot,已经能非常流畅地和黑寡妇进行口语练习了:

所以,chatGPT 完全是另外一个维度的工具,积累了人类历史上的很多文字和知识,并且可以不断地进化。如果具备一些人类的核心能力,比如逻辑、推理和归纳,chatGPT 就是一个活了几百年的人,并且随着时间的推移不断地进化和自我更新。当 chatGPT 这种技术和波士顿动力的机器人结合起来,这个活了几百年的老人就有了身体。这是不是很恐怖?

当人类真的创造出来这样的工具,我们该如何改变自己的学习和工作方式?以后每个人都可以通过移动设备和这各种 GPT 交流,几乎所有的创作中机器生成的成分会越来越大。

这是巨变的开始,很多问题现在没有明确的答案:

学生在学校该学什么?也许所有背诵的东西都更不重要了,学生应该学习的是更多通识教育,如何自主学习和创新。

编程和写 Prompt 有本质的区别么?我以前认为有差别,但如果你把 chatGPT 看作一个编译器或者解释器,其实也没有多大差别。只是编程更为精细,这是更直接和计算机对话的原始方式。而 Prompt 几乎就是自然语言,你可以通过特定的 Prompt 完成特定领域的任务,Prompt Engineer 的需求确实会存在。现在我们常用的编程语言对于未来而言可能是一种汇编语言。

通过 chatGPT 创造和辅助创造的作品是否有版权?我不知道,似乎法律还没跟上这块。以后必然会出现大量的机器生产的内容,纯手工打造会变得稀缺,但如何区分出来是否纯手工打造,或者这将变得不重要。事实上这篇文章里就有部分 chatGPT 帮我生成的 😁。

书籍会变得更不重要?人们会更没耐心去从头到尾地看书,也许我们可以通过发布思维和知识库这样的东西来分发知识了,比如刘润把自己的所有书籍和文章汇总成为一个主题知识库,我们可以与之对话,比如有人汇总了 Paul Graham GPT

我们如何面对这样的新工具?最重要还是把它定位为工具,用来提高效率和创造价值,正如 John Carmack 在回答是否担心 AI 替代程序员时所说:

Software is just a tool to help accomplish something for people - many programmers never understood that. Keep your eyes on the delivered value, and don’t over focus on the specifics of the tools.

赶紧学起来?

❌