好久没有写笔记了，说说近况吧。
在字节的生活还算顺利，没有网上说的字节一年，人间三年那么严重。但确实有字节一年人间一年半的印象。
首先比较快乐的是在这边做了很好玩的事情。在字节的实习生活以做FFmpeg的safe binding开始(基于我GSoC做的那个rusty_ffmpeg)，可能是我外部代码看的比较少，但是我觉得在这边的FFI算是业界比较合理高效的FFI实践。当时做完看到自己写的binding一次就成功跑过测试，真的是非常开心。其次呢也对FFmpeg有了更深的了解，FFmpeg真的是音视频领域绕不过去的大山（当然也是宝库）。由于FFmpeg有很多实现细节，而历史的惯性又很大，除非音视频领域有重大变革，我们都不会看到它的消亡。而对于Rust语言来说，做它的binding很有意义(在社区里没有看到能打的)，在三月或者四月我会把它开源出来。后来这个binding重构了一下我们软件的解码模块，遇到了不少坑，
在字节做的第二个事情和局域网传输有关，开发其实遇到的困难很少，真正遇到的困难是开发之外的事情。 第一个困难是依赖冲突的解决，在解决这个困难的时候对Rust的依赖冲突有了更深的了解。主要可以看这篇文章。首先Rust依赖版本可以设置的很模糊，Cargo选择最终放到Cargo.lock版本的自由度就大了一点。其次，纯Rust代码可以同时存在多个版本。比较悲伤的是，非纯Rust的ffi crate就不能同时存在多个版本，这是造成Rust依赖冲突的主要问题。这种情况的解决每次都需要我们自己fork一份依赖代码然后进行手动更改。 第二个困难是联调。联调的痛苦根源来源于多人协作和编译实践，需要不时的block在别人身上，或者block在自己的代码编译上。由于自身水平有限，有时候会改错代码，重新编译的时候即使有编译缓存，依然需要编译一整条自底向上的链，即使是很小的改动也需要编译十分钟(不过最近的几个rustc release有可喜的进步)。
同时呢自己在GitHub上的活动又开始频繁了起来，主要的原因是被拉去做clap的collaborator了。clap是一个argument parser，有被很多Rust cli使用(cargo, ripgrep...)，学习Rust用的第一个crate就是它，当时用的时候最大的困扰就是clap一直卡在2.33.3版本上，但是GitHub的master上从很早开始就是3.0.0了，但是迟迟没有stable的迹象。看了一下milestone上的issue数量，然后看了一下解决issue的速度，当时感觉有生之年看不到clap 3.0.0了，于是开始帮忙发PR解决issue。成collaborator之后，写代码之外也开始帮忙review代码和参与discuss。
解决clap的issue的时候自己也成长了很多。本质上clap是一个逻辑非常复杂的库，因为本身是Rust社区cli的几个比较好用的库之一，用户基数很大，所以致辞了很多不同风格的argument parsing，这些不同风格不是被feature gate起来，二是在运行时判断的。最惨的是这些不同风格的argument parsing被塞到了一个parsing流程中。这是预期的现象，因为用户想要同时使用多个features，那么他们之间就必须在一条程序路径上体现。clap被塞入了足够多的feature，以至于维护起来稍微有点吃力，好在我们的测试比较多，改坏了也会很容易的被看出来。经过这几个月的努力修bug，clap快要出3.0.0-rc.1了。挺开心的，剩下的一些issue是基本上是clap_derive相关，修起来没有肉眼可见的巨大困难，3.0可期！