在 Lua 中定义类型的简单方法
文章以教程形式探讨了在Lua中定义类型的简洁方法，重点介绍了从基础到进阶的实现策略。首先，作者展示了通过table和元表设置来创建类型的基本方式，这种方法依赖Lua模块机制，适合快速定义独立类型。随后，文章深入讨论了封装class模块的高级方案，通过统一管理类型定义和实例化，提供类型名查找功能，增强了代码组织性。内容核心转向
实用软件项目管理最佳实践
本文针对小型团队在软件项目中面临的交付延迟、需求变更与协作低效等问题，提出了一套注重实操的迭代管理方法。其核心在于建立固定产研节奏、标准化交付物与高频异步协作机制。 在节奏管理上，采用固定的短周期迭代（推荐双周），通过冲刺模式强制需求拆解与周期性交付，避免长期封闭开发风险。设立迭代经理角色负责排期与协调，并通过轮值促进理解。同时，利用公式估算工作量，并强制将大型需求拆分为“天”或“小时”级别的小任务。 在交接物方面，强调“写下来”以对抗软件的抽象性，要求为每个环节定义清晰的输入输出标准。例如使用结构化的需求清单与需求文档明确意图，用简洁的Release Note与持续更新的产品手册同步信息，所有文档力求简明。 在协作上，倡导“异步为主、同步为辅”。通过在线看板实现任务与风险的全局可视化，并将同步沟通压缩至必要的方案评审会与每日站会。会议需有明确结论与行动项，并全量同步至协作平台，以最大化建设性工作时间。
我的 CodeReview 实战经验
背景
Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。
我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多：
- 跳出个人开发的思维误区，更容易发现问题
- 增进团队交流，提高整体的技术氛围
- 团队水平检测器，不管是审核者还是被审核的，review 几次后大概就知道是什么水平了
通常 Code Review 有两种场景，一种是公司内部，还有就是开源社区。
开源社区
先说开源社区，最近也在做 cim 项目里做 Review，同时也在 Pulsar、OpenTelemetry、StarRocks 这些项目里做过 Reviewer。
以下是一些我参与 Code Review 的一些经验：
先提 issue
在提交 PR 进行 Code Review 之前最好先提交一个 issue 和社区讨论下，你的这个改动社区是否接受。
我见过一些事前没有提前沟通，然后提交了一个很复杂的 PR，会导致维护者很难 Review，同时也会打击参与者的积极性。
所以强烈建议一些复杂的修改一定先要提前和社区沟通，除非这是一些十拿九稳的问题。
个人 CI
一些大型项目往往都有完善的 CI 流程来保证代码质量，通常都有以下的校验：
- 各种测试流程（单元测试、集成测试）
- 代码 Code Style 检测
- 安全、依赖检测等
如果一个 PR 连 CI 都没跑过，其实也没有提前 Review 的必要了，所以在提 PR 之前都建议先在自己的 repo 里将主要的 CI 都跑过再提交 PR。
这个在 Pulsar 的官方贡献流程里也有单独提到。
同时在 PR 模板里也有提到，建议先在自己的 fork 的 repo 里完成 CI 之后再提交到 upstream。
这个其实也很简单，我们只要给自己的 repo 提交一个 PR，然后在 repo 设置中开启 Action，之后就会触发 CI 了。
如果自己的 PR 还需要频繁的提交修改，那建议可以先修改为 draft，这样可以提醒维护者稍后再做 Review。
同时也不建议提交一个过大的 PR，尽量控制在 500 行改动以内，这样才方便 Review。
Review 代码
Github 有提供代码对比页面，但也只是简单的代码高亮，没法像 IDE 这样提供函数跳转等功能。
所以对于 Reviewer 来说，最好是在本地 IDE 中添加 PR 的 repo，这样就可以直接切换到 PR 的分支，然后再本地跟代码，也更好调试。
有相关的修改建议可以直接在 github 页面上进行评论，这样两者结合起来 Review，效率会更高。
Review 代码其实不比写代码轻松，所以对免费帮你做 Review 的要多保持一些瑞思拜。
AI Review
现在 Github 已经支持 copilot 自动 Review 了，它可以帮我们总结变更，同时对一些参加的错误提供修改建议。
使用它还是可以帮我们省不少事情，推荐开启。
企业内部
在企业内部做 Code Review 流程上要简单许多，毕竟沟通成本要低一些，往往都是达成一致之后才会开始开发，所以重点就是 Review 的过程了。
既然是在公司内部，那就要发挥线下沟通的优势了；当然在开始前还是建议在内部的代码工具里比如说 gitlab 中提交一个 MR，先让参会人员都提前看看大概修改了哪些内容，最好是提前在 gitlab 中评论，带着问题开会讨论。
实际 Review 过程应该尽量关注业务逻辑与设计，而不是代码风格、格式等细枝末节的问题。
提出修改意见的时候也要对事不对人，我见过好几次在 Review 现场吵起来的场景，就是代入了一些主观情绪，被 Review 的觉得自己能力被质疑，从而产生了一些冲突。
Code Review 做得好的话整个团队都会一起进步，对个人来说参与一些优质开源项目的 Code Review 也会学到很多东西。
写代码与做菜
将编程中的模块化思想应用于烹饪，能有效提升学习效率。烹饪可拆解为预处理、烹制与收尾三个核心阶段，每个阶段包含若干可复用的具体操作模块。例如，无论是清蒸鱼还是红烧鱼，其预处理步骤（如去腥、改刀）高度相似，掌握后便可迁移至其他鱼类料理。类似地，红烧技法在鱼与肉等不同食材间也可通用，仅需调整调料与时长。这种阶段划分与模块复用的方式，让学习者能清晰定位自身薄弱环节，并通过组合已有模块来尝试新菜品。 进一步看，烹饪具体步骤还可借鉴面向对象编程的接口概念。例如，“上色”这一工序可通过炒糖色或使用老抽等多种实现方式完成，选择者可依据熟练度灵活取舍，体现“完成优于完美”的实践原则。对于不熟悉的环节，如食材初加工，则可类比服务化思想，通过采购半成品或外包完成。掌握常用模块、灵活组合阶段、善用外部服务，这三者结合能够降低烹饪门槛，逐步积累实践信心。文章最后以“火候”与“功夫”等中文词汇为例，指出烹饪中时间与耐心的要素，与编程中的调试与迭代有着内在相通之处。
Mac mini 通过键盘连接蓝牙鼠标
当Mac mini与蓝牙鼠标意外断连时，通过键盘重新连接是一种高效且独立的解决方案，避免了依赖有线鼠标的不便。核心操作涉及利用系统设置进行蓝牙配对：首先通过Cmd+空格调出Spotlight搜索框，输入“系统设置”并回车进入；随后使用方向键导航至蓝牙选项，并手动使鼠标进入配对模式。关键步骤在于解决键盘焦点无法移动到设置面板右侧的问题，这需要按下Ctrl+F7快捷键开启键盘导航功能，从而允许Tab键正常切换焦点。定位到蓝牙鼠标的“连接”按钮后，按Space键即可完成配对。此外，其他备选方法包括通过Cmd+Option+F
露营装备清单整理
本文整理了一份全面的露营装备清单，旨在帮助露营爱好者，特别是新手，提前做好充分准备。清单涵盖六大核心系统：**基础装备**包括帐篷、天幕、折叠桌椅、营地车及防潮垫等，为露营提供基本生活与休息空间；**餐厨装备**详列了炉具、锅具、餐具、水具及保温箱等，保障户外饮食需求；**辅助工具**涵盖充电宝、防晒防虫用品、头灯及急救包，确保安全与便利；**休闲装备**如蓝牙音箱、户外影院等，丰富营地活动；**消耗材料**则包括饮用水、清洁用品及各类燃料；针对烧烤爱好，另设**烧烤装备**专题。 对于计划过夜露营者，清单额外强调了睡袋、枕头、照明设备、洗漱用品及简单药品的必要性。文章同时提供了十项重要**注意事项**，包括结伴而行、选择正规营地、保持通讯畅通、携带充足饮用水、谨慎生火、制定计划以及环保意识等，这些原则对于保障露营安全与体验至关重要。清单最后还提及了针对特定场景（如汛期或山区露营）的装备建议，体现了其实用性与针对性。
C++ 中的 main 定义
这篇讲的是 C++ 最新标准里一个看似微小却影响行为的细节调整：关于 `main` 函数的定义。 作者直接指出了核心变化——根据最新的 C++ 标准草案，程序入口函数 `main` 不再允许被 `extern "C"` 这样的 linkage-specification 修饰。文章引用了标准原文，明确了这一点。对于很多习惯了在某些项目或编译器下这样写来避免名字修饰的开发者来说，这可能会造成困惑或编译错误。 文章进一步解释了背景：在旧标准和实际编译器实现中，`main` 作为程序入口点，其链接约定有着特殊的隐含处理。允许用 `extern "C"` 修饰是一种非正式的宽容行为，但新标准明确了这一行为是不符合规定的。文章通过展示错误用法与正确用法的代码对比，清晰地指明了正确做法——只需遵循基本的 `main` 函数签名即可。 这提醒我们，依赖编译器的“非标准特性”或历史宽容行为存在风险。随着标准演进，这些模糊地带正在被澄清。对于需要严格符合标准的代码，尤其是跨平台项目，留意此类细节更新很有必要。
竞业协议的相关文章收集
这篇关于国内竞业协议现象的深度合集，汇集了多篇重要文章的核心观点与案例。文章直指国内互联网行业竞业协议被普遍滥用的现状——本应仅针对高管、核心技术及保密人员的限制，已下沉至应届生甚至实习生，成为企业“拿捏”员工的工具。作者梳理了相关法律要点，例如竞业期限最长两年、补偿金一般不低于离职前12个月平均工资的30%，并强调连续三个月不支付补偿则协议自动失效。 合集进一步引入硅谷视角作为对比：加州早在1872年便立法禁止竞业协定，学者认为这促进了人才流动与创新，是硅谷保持活力的源头之一。而美国联邦贸易委员会（FTC）更在2023年提议全国禁止，指出竞业协定会压缩薪资、阻碍创业。通过汇集国内“全网通缉”式的极端案例与硅谷的开放模式，文章呈现了两种截然不同的人才观与创新生态。它既为从业者提供了应对竞业限制的实用法律知识，也引发了对于人才价值与企业权力边界的思考。
一个 VLA （可变长度数组）的实现
这篇讲的是作者如何用C语言实现一个更实用、更安全的可变长度数组库。C99引入的VLA特性因安全问题已被MSVC和Linux内核相继放弃，但在日常开发中，变长数组的需求依然存在。现有的通用方案，如C++的std::vector或简单的void*实现，在类型安全、性能（堆内存分配）和与特定运行时（如Lua）的集成方面各有不足。 作者的方案核心是将VLA拆分为抽象的“句柄”和类型化的“访问器”。通过`vla_using`宏，在栈上创建一个指向实际数据的原生指针作为访问器，同时关联句柄，从而在保证类型安全和原生数组访问性能的同时，提供了清晰的API。为兼顾临时使用与持久引用的不同场景，方案统一了栈上缓存与堆分配的切换逻辑。 更巧妙的一点是，作者针对与Lua交互的场景，实现了利用Lua GC管理内存的第三种模式：小块内存直接分配在C栈上，大块内存则转为Lua临时userdata，随函数退出自动回收，省去了手动清理的麻烦。整个实现展示了如何在C语言的限制下，通过宏技巧和分层设计，构建出一个既高效又贴合实际工程需求的通用数据结构。
iTerm2 (Mac Terminal) 清空当前屏幕内容
这篇讲的是 Mac 终端用户常遇到的一个“洁癖”小问题：执行 `clear` 命令后，屏幕看似干净，但向上滚动依然能看到历史输出，而且在搜索时，之前的内容其实也还在。 文章直接点明了 `clear` 命令的这两个局限性，并给出了一个更彻底的解决方案——使用 iTerm2 自带的快捷键 `Command + K`。这个操作能真正清空屏幕缓冲区，让历史记录在滚动和搜索时都彻底消失。 如果你经常在终端里工作，希望获得一个完全空白、不受旧内容干扰的工作界面，这个小技巧能立刻提升你的使用体验。
技术同学在业务中的成长
这篇文章探讨了技术同学在职业成长中的一个经典困惑：在大团队有机会“造轮子”但晋升竞争激烈，在小团队专注业务却可能成长更快。作者从“什么是业务”出发，清晰地梳理了团队为避免重复建设而进行抽象、分层的必然性，指出“造轮子”本质也是业务的一部分，只是需要更广阔的抽象和服务更大的体量。 文章的核心在于为“业务同学”正名。作者指出，做业务的同学身处一线，直面客户和市场的核心问题，这恰恰是他们的独特优势。但现实矛盾在于，技术价值的评估往往难以直接对应产品结果。因此，作者提出了一个关键的角色进化方向——“产品工程师”。 作者认为，业务同学不应只羡慕“轮子制造者”，而应聚焦于将各种轮子组装成更好的“产品”这辆车。他们面临的业务场景虽不确定，但可以主动去探索和定义业务模型，为其添砖加瓦。这本身就是一个充满挑战和成长空间的新课题。 最后，文章也点破了“大团队技术就一定强”的错觉，强调了环境与个人选择的关系。它鼓励技术人员无论身处何种环境，都能看清自己的价值，做好分内之事，从而实现扎实的成长。
70 后都跑哪去了？
这篇讲的是一位互联网“老兵”对自己所在行业中“70后”技术人踪迹的寻觅与思考。 作者从自己公司春节后只剩一位70后同事的“残酷真相”出发，回溯了在洪恩、用友、锤子等公司的经历，发现自己在不知不觉中成了团队里最年长的人。他调研发现，当年那批使用JDK 1.4、HTML4的第一代程序员，并没有消失，而是悄然分流：一部分晋升为大厂高管（如阿里的逍遥子、鲁肃），一部分在技术领域持续深耕，还有不少人转行、投身区块链、回归故里或消失在创业公司的起起落落中。 文章并未停留在感慨，而是深入剖析了这一现象背后的原因：互联网行业本身年轻，早期从业者本就稀少，而行业的剧烈发展又在不断稀释着这些“老人”的比例。作者联想到村上春树72岁仍笔耕不辍的创作生涯，以此反思技术人的职业生命周期——年龄增长并非必然意味着停滞，持续热爱与产出才是对抗时间的关键。 文章结尾，作者将个人“逆行”般的职业轨迹（年轻时专注技术，四十岁后反而迎来更广阔的人生）与村上春树的“特质”（30岁后找到写作方向并坚持一生）并置，留给读者一个开放的思考：技术人的中年并非终点，而是可以重新定义起点、继续前行的生命阶段。
你老了
这篇讲的是一位技术人的“年龄焦虑”与自我和解。作者从自己在用友、锤子科技，到极客邦创业的经历切入，发现自己一路走来，竟从团队里最年轻的变成了最年长的那个——入职极客邦的第一天，就成了公司年龄最大的人。 文章的核心并非抱怨，而是通过这些个人观察与同行趣事，引出了一个更普世的思考：我们是如何看待衰老的？作者坦言，人过四十，所谓的“不惑”更像是接受“有些事再也想不明白”的现实，而午夜梦回时，对青春理想的追问仍会惊出一身冷汗。 但他最终的态度是清醒而积极的。他援引姜文的“不怕老”，提到七十多岁的创作者依然笔耕不辍，并认为当代的技术人，尤其是七零后、八零后，很可能将“精力充沛地工作到七十岁甚至八十岁”。全文用一种混合了自嘲、哲思与幽默的笔调，探讨了成长、边界与梦想的消逝，最终回归到一个朴素的观点：认清年龄的边界，或许才是真正的超越。
How to Install Native Homebrew on an Apple Silicon M1 Mac
在Apple Silicon M1 Mac上安装Homebrew，不少开发者会直接运行官方脚本，结果收到报错提示“Homebrew is not (yet) supported on ARM processors!”。作者从这个常见踩坑点出发，解释了根因：M1芯片采用ARM指令集，而传统Homebrew是为x86架构设计的，直接安装会导致兼容性问题。 文章梳理了两种解决方案。一种是借助Rosetta 2转译安装x86版本的Homebrew，命令只需在官方脚本前加上`arch -x86_64`，简单快捷。但作者指出，这种方式后续通过Homebrew安装的所有软件都会是x86架构，
fbx 到 gltf 转换问题
这篇文章讲述了游戏引擎团队在迁移到 glTF 格式时，为解决美术工具导出支持不足与 FBX 私有格式带来的转换问题所经历的系列尝试。作者从项目背景出发，详细记录了团队评估和使用四个不同方案的过程：先是发现 Assimp 工具臃肿、编译问题多且存在链接失败 bug，因而放弃；继而尝试自行编写 FBX 解析模块，但意识到数据转换的繁杂性远超预期，非长期维护之选；接着采用 Facebook 发布的 FBX2glTF，却在对方停止维护后陷入 bug 无法修复的困境；最终转向 Blender，利用其优秀的命令行脚本支持、官方 glTF 插件以及详尽的 FBX 文档，形成了稳定可靠的工作流。文章不仅分享了具体的技术选型思路与踩坑经验，也反映了从私有格式走向开放标准过程中的现实挑战与务实解决策略。
做连贯性活动 - 读《好战略，坏战略》
这篇文章从作者在微信群看到《美团清华产品课》笔记中提到《好战略，坏战略》一书开始，分享了对该书核心观点的解读。好战略的逻辑结构包括调查分析、指导方针和连贯性活动，其中连贯性活动强调战略必须落地，结合自身特点发挥优势。作者用iOS程序员的类比说明：战略发展应基于已有的“属性”和“方法”，而非随意定方向，避免历史成为包袱。 书中介绍了三种实现连贯性活动的方法：聚焦，如苹果削减产品线、Intel转型微处理器，通过收缩核心业务等待机会；转换视角，如IBM将产业链整合劣势转化为整体咨询服务优势；设计思维，强调战略应精心设计而非投票决定，以保持渐进性和资源聚焦。同时，文章列举了坏战略的特征，如空话、回避挑战、目标不落地等。 通过对比波特的竞争战略，本文从执行层面探讨了战略制定，案例丰富：苹果的成功聚焦、DEC因高管意见分散导致失败等。读者能从中理解如何识别坏战略，并借鉴具体方法制定连贯性活动，在商业挑战中发挥自身优势。
选择开源项目的几点原则
这篇讲的是资深工程师在面对琳琅满目的开源项目时，如何做出不后悔的选择。作者从自己曾受邀为校招生做技术分享的背景出发，分享了沉淀下来的三点实用原则。 核心观点非常明确：选项目，本质上是选“人”。具体来说，一要看项目是否活跃，有持续演进的历史，拒绝“已死”的项目；二要看项目主导者是否善于沟通，这是项目能否健康演进的关键；三要看项目是否专注，解决单一问题的“小而美”项目更便于集成与取舍。 作者特别强调，我们不必苛求代码完美，因为选择使用一个开源项目，就意味着选择了与维护者同行。真正重要的是找到那些勤奋、开明且专注的“合作伙伴”。文中还顺带吐槽了国内某些只发代码快照、缺乏持续维护的“伪开源”现象，让这个选择原则显得更加切中时弊。
在家工作一周年
这篇文章记录了作者从2020年3月开始，持续在家工作一整年的回顾与思考。作者结合2003年SARS的“宅家”经验，原本对疫情持续时间预计乐观，但事实远超预期。文章详细描述了从公司通知可自愿远程办公、自己随后出现流感症状并康复，到逐步搭建起稳定家庭办公环境的全过程。 技术细节上，作者分享了配置居家办公设备时遇到的实际“坑”：例如使用HP USB-C显示器为Pixelbook供电时，发现显示器供电不足，需额外占用USB-C口或使用带供电的Hub；某些设备直接连接显示器无法工作，改用USB-A转C线缆则能解决。这些具体经验对面临类似设备兼容问题的读者有直接参考价值。 生活层面，文章记录了为适应居家状态，在购物（转向农场团购）、车辆维护、个人护理（购置推子自助理发）及家庭清洁（引入扫地机器人）等方面发生的切实变化。此外，作者还提及在加州山火季，如何制定应急撤离清单并检查数字备份，展现了应对突发风险的准备思路。 结尾部分，作者在反思中指出，尽管居家一年完成了不少工作，但疫情无疑打乱了许多计划，也影响了更深远影响力的产生。文章在平静的记述中，流露出对逝去时光的感慨和对行业困境的观察。
面试的艺术 - 如何面试别人
这篇讲的是，作者如何面对自己并非专家的岗位，去面试候选人。他坦言，面试是一门不完美的艺术，很难在短短几十分钟内准确判断一个人。我们能做的，是在有限时间内提高判断的正确率与召回率。 具体怎么做呢？作者的核心方法是“进行有区分度的考查”。他反对那种所有人都能答对或答错的问题。比如用算法题考察工程师的逻辑与智力，就是一种有效的区分手段。同时，面对光鲜的简历，要围绕一个项目深挖细节：问目标、问流程、问数据、问挑战。通过追问“为什么做”、“谁配合”、“最终结果如何”，能有效判断候选人是否真负责、做得好不好。 除了具体的专业技能，作者强调要关注一些基础素质，比如表达沟通能力（注意信息的“密度”）、工作热情、团队精神和学习习惯。最后，他建议将面试问题与经验标准化，形成可共享的“方法论”，并定期复盘迭代，以适应变化。 总的来说，面试不是一次性的考核，而是一个需要持续打磨和反思的技能。作者从实践出发，提供了一套可操作的框架，帮助面试官在不确定中做出更可靠的判断。
程序员职业生涯巡礼
这篇文章是作者基于十多年从业经历的总结，围绕程序员职业生涯的八点核心感想展开，既是对个人路径的回顾，也是对行业规律的洞察。 作者首先肯定了程序员是一个投入产出比高、能创造价值的好职业，并指出它已具备长久生命力，“35岁危机”更多是早期行业的误读。他强调，职业生涯的不同阶段应有不同侧重——写代码并非永恒任务，当角色需要你从更高维度把握方向时，应勇于转型。 文章特别深入探讨了“入行三到五年”的关键探索期。作者认为这段时间对于发现自身特质、建立深度技术栈不可或缺，即便领域知识浩如烟海，这段摸索也是巨大财富。同时，他犀利地指出了专业深度与广度的平衡问题：既要深耕以免缺乏竞争力，又要避免陷入过于冷门的技术孤岛。 在个人技能之外，作者着重谈到了协作与产品思维。他以张小龙等为例，说明优秀的产品离不开程序员与产品经理的深度协同，鼓励程序员主动介入产品全流程。最后，他认为职业规划不必僵化，踏实写好每一行代码、在时代浪潮中把握机遇，本身就是一种可行的规划。 这些源自实践的思考，为身处不同阶段的开发者提供了兼具共鸣感与方向性的参考。