关于本刊
这是猫鱼周刊的第 51 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在
博客：阿猫的博客-猫鱼周刊
RSS：猫鱼周刊
邮件订阅：猫鱼周刊
微信公众号：猫兄的和谐号列车
上周因为工作日工作太多，周末实在太累，不勉强自己写了，所以周刊缺席了一周。本周的内容会相对多一点，有的话题实在是戳中了我的表达欲。周刊一周年也到了（其实已经过了，不过没到 52 期），预告一篇特刊，分享一下这一年多来写周刊的经历、收获等等。如果你有感兴趣的问题，可以邮件或者评论，到时候解答一下。
文章
我是开发者，不是编译器
作者提到，在他的一次面试中，对方问出了以下这些问题：
- 什么是多态？
- List 和 Set 有什么区别，什么时候该用哪一个？
- 什么时候会出现死锁？
- 强类型和弱类型有什么区别？
- List 在什么包里？File 在什么包里？
- 继承要用什么关键字？
- 你对自己有什么五年规划？（Where do you see yourself in five years?）
作者认为这些问题不但浪费了宝贵的面试时间去了解候选人是否适合，让真正聪明有经验的人反感，而且会对候选人的能力产生误判。好的工程师在设计系统的时候思维是非常抽象的，他们考虑算法、组件和工程设计，但并不一定对一个语言的所有语法细节的清楚，尤其是有现代 IDE 来帮助他们解决这些问题。
作者觉得任何花五秒钟 Google 或者 ChatGPT 能解决的问题都不是好问题。他最喜欢的面试问题是，「你最喜欢的语言是什么」以及「它的缺点是什么」。
我在校招面试的时候，曾经有面试官问过我一个非常类似的问题，我到现在依然记得清清楚楚：「Python 的装饰器是什么？」，我一脸懵没答上来。我知道这个概念，我也稍微用过（在函数或者类头上写一个@），但我确实没有认真学过 Python 的语法（学校没教，Python 是我在高中阶段断断续续自学的）。实际上，我大学阶段主要用 Python 做深度学习相关的事情，很多论文公开的源码代码都写得缺乏工程化，真的很少有用到。
挥手，别离
原标题为 「Leaving and Waving」，我且译成「挥手，别离」，感觉这个语序更好。
作者从 1991 年开始，每次离开父母家时都拍一张挥手告别的照片留念，持续了 27 年，直到 2017 年母亲去世。文章字数很少，图片很多，从挥手告别这个角度讲述了作者一部分的人生故事：
- 父母渐渐老去，父亲在 2009 年去世，母亲住进疗养院，母亲在 2017 年去世
- 作者养了一只小狗，差不多时候孩子出生
- 孩子渐渐长大
- 拍摄设备从黑白胶卷，到渐渐有彩色数码相机
- 最终父母都仙逝，车库大门紧闭，再也没有人
陈奕迅有一首歌《沙龙》，讲的就是摄影的意义，「留住今日怎样好」。苹果的 Live Photos 也是一个非常有意义的功能，能把「一格」变成一个更丰富的片段，丰富了照片的故事性。
照片实际上是一个记忆锚点，多年以后，如果看到一张当时的照片，能回忆起当时发生的事情，重温当时的感觉，真的是非常美妙的事情。「Relive the moment」。
项目
哪个语言更快？
通过简单的循环和斐波那契数列计算比较不同语言的性能差别。结果上跟一般认知没什么大的区别，编译型的快，解释型的慢。具体结果可以看这里。
比较有意思的是，有非常多人尝试不同的方式，压榨更加极限的性能；也有人发现，部分优化在系统、架构上有区别。
工具/网站
Meshtastic 中国社区
在前几期，我介绍过 Meshtastic 这个项目，它是一个开源、离网、去中心化的通讯网络，可以在廉价、低功耗设备上运行，适合户外探险、应急等场景下使用。过去的一两个月里，我已经组装了六台设备。
最近一两个月国内社区发展也很快，交流群已经达到 70 人的规模，也拥有了一个网站。如果你对 Meshtastic 感兴趣，有以下这些文章可以帮助你快速入门并快速跟其他爱好者进行通联：
- 入门指南 | 中国 Meshtastic 社区
- Meshtastic 常用工具 | 中国 Meshtastic 社区
- 如何设置 Meshtastic MQTT 功能 | 中国 Meshtastic 社区
想法
再谈八股，AI 编程
我毫不忌讳地说，我旗帜鲜明地反对八股。我之前就说过：
在日常工作中，一口流利的八股并不能帮助你设计更好的方案或者排查出疑难的 bug，只有坚实的基础和良好的直觉，能让你迅速定位到问题，通过搜索引擎或其他工具，快速并精准地完成工作。
本期也谈到：
任何花五秒钟 Google 或者 ChatGPT 能解决的问题都不是好问题。
同时，我是 AI 编程的狂热者，我可以说，我日常 80%的代码都是由 AI 编写或辅助编写的（今年初我就用 Copilot 完成过一个前端项目）。在用 Cursor 后，它比较独特的 codebase 索引、apply（ AI 根据聊天和实际代码再重新生成代码，而非直接复制粘贴聊天中的代码）功能更是让跟 AI 的合作更加流畅。但是，也不得不说，AI 决定生成代码的下限，人决定上限。
如果你不知道如何实现一个功能，只知道你需要实现的效果，那 AI 多半会天马行空，生成出来的代码需要反复调试还不一定好用；但如果你很清楚怎么实现，只是不想写代码，你可以把一些实现细节给描述清楚，那么这个效果就会非常好。
例如下面这个例子，检查系统上有无可用的硬件加速。我本身对 ffmpeg 不熟悉，甚至在写这部分代码之前压根没用过。让 AI 生成的代码一开始并不好用（它用 ffmpeg --encoders 和 ffmpeg --hwaccels 去检测可用的硬件加速方法，但是 Windows 上即使没有显卡，也会有 cuda 出现）。经过一番查找后，发现有以下的命令可以直接测试是否可用，因此我把命令提供给它让他修改对应的代码。以下这些 subprocess、命令拼接之类的东西，我自己也能写，可能要花十几分钟加上再调试一下，但 AI 十几秒就能完成。
在这个例子中，如果我一开始就知道 ffmpeg 有这个坑，把方式告诉 AI，就不会在中间鬼打墙。在调试过程中，AI 反复修改，但都不能运行，像是有一个瓶颈卡住了它；有时候用 @Web 让它去搜索能解决，有时候也不行；人工介入了解之后，再帮它一把，就很顺利。
所以说，知道怎么做更重要。在这个例子中，我知道合成视频慢是因为没用到硬件编码，所以要在 ffmpeg 中启用硬件编码；hwaccels 和 encoders 输出的结果没法真的确认编码可用，所以要探测编码器是否真的可用。如果说 IDE 能帮忙解决语法问题，那么 AI 更进一步把写代码的事情也做了，但人还是要解决思路的问题。这也是「人决定上限」的原因。
我能列举非常多理由为什么我不掌握八股，看起来很像是为自己的无能开脱，但杀死八股的银弹是，我不会八股，但不妨碍我能快又准地解决问题，这不就是工作上要求的吗？
在这个时代，再去纠结八股里面那些概念、一成不变的教条，根本没有意义。
最后
本周刊已在 GitHub 开源，欢迎 star。同时，如果你有好的内容，也欢迎投稿。如果你觉得周刊的内容不错，可以分享给你的朋友，让更多人了解到好的内容，对我也是一种认可和鼓励。（或许你也可以请我喝杯咖啡）
另外，我建了一个交流群，欢迎入群讨论或反馈，可以通过文章头部的联系邮箱私信我获得入群方式。
