编程杂记

TL;DR Learn in Public 强调将学习到的知识 分享到公共空间，相较于纯输入式的学习有诸多好处。AI 工具极大降低了信息检索、整理、概括的门槛，使得输入信息更容易，但对我们真正掌握知识的帮助仍然有限，所以我们更需践行要像 Learn in Public 这样能提供 有效输出 的学习方式 AI 工具大大降低了信息检索、整理和概括的门槛，使得获取信息更加便捷，但对我们真正掌握知识的帮助仍然有限。因此我们更需要践行像 Learn in Public 这样重视 有效输出 的学习方式 为什么会想到这个话题 偶然间看到 Owen 发的贴子： 看到一个说法：笔记是一种无限游戏，没有结果，只有过程；而博客是一种有限游戏，因为它产出了完成的作品：博文。这说明我们不能当一个完美主义者，只在脑海或草稿箱中保留想法，我们应该尽可能完成作品，公开它，然后不断的练习这个过程。 我更坚定那个想法了：做一个默认设计为公开的笔记软件 看到这个贴子，马上联想到了 Learn in Public 这个概念，开始思考自己的这些年记笔记的方式，意识到了原来的方式可能存在一些问题，于是开始尝试践行 Learn in Public，将自己学习的一些东西写成博客、用学到的知识做一个有意义的产品等等。经过了这段时间的实践，再结合上自己日常使用 AI 的一些感受和想法，很自然地就想到了这个话题 什么是 Learn In Public 在 swyx 发布 Learn In Public 后，这个概念变得更加流行。Learn in Public 强调的是 将学到的东西分享到公共空间 常见的 Learn In Public 的方式，例如： 撰写博客、教程 在会议上发言 在问答社区提问或者回答 制作并发布视频 与之相对的 Learn in Private 侧重的是 消费内容，例如： 个人笔记 阅读书籍 阅读源码 订阅 GitHub 的 Repos 和 Issues，观察其他的人实践 为什么需要 Learn in Public Learn in Public 是一个输出的过程，促进知识的整理、理解、求证，帮助我们拓宽对某些 知识理解的边界 公共空间能提供 反馈，反馈可以产生激励、也可以修正我们努力的方向 有助于 筛选 所要学习的东西，Learn In Public 会花费大量精力，它能促使我们评估即将学习的内容是否值得 对抗完美主义，先有产出，走出第一步再根据反馈 持续迭代，而不是止步不前 很多的知识都来自 Public ，所以没有什么好藏着掖着，大部分的成果可能都是站在巨人的肩膀上 为什么 AI 时代更应该 Learn in Public 在 AI 的推动下，知识获取已经实现了质的飞跃，但对我们真正掌握知识的帮助仍然有限，所以我们更应该 Learn in Public，做更多的 有效输出 ...

先跑起来，通过文档和实践熟悉业务流程 这一步可以通过看官方文档开始，要注意的是一些项目是 更新先于文档 的，比如新版本启动方式有变更，但是文档还没更新。跟着文档不一定能把项目跑起来，需要借助 GitHub Issue 或者是 Slack 这样的工具以获取即时的帮助 看测试，通过测试了解流程 如果是开源项目，可以通过 GitHub Action 快速了解需要哪些依赖、如何快速运行测试，便于在本地运行测试，通过这些集成测试可以快速弄懂业务主线 通过 debug 高效快速地梳理流程 通过断点可以一步一步跟踪程序的运行，可以比较直观地看调用栈、变量等等的 对于一些无法本地调试的项目来说，我们可以退而求其次，断点它的测试，这也是一个很有效的方法 画图：降低复杂度 很多项目会使用一些比较优雅的设计或是引入一些抽象层，这样代码读起来就会跳来跳去，层级深的话就很容把人给绕晕了 可以用 draw.io 或者 excalidraw 等工具，根据实际情况画一画 活动图、时序图等 提出具体的问题，带着问题看项目 如果只是盲目地看项目代码，可能看完还是一头雾水，但是如果能提出一个具体问题，或是带着一个需求去看，效果就会好得多 比如我提出问题：“某个任务在集群内是如何完成的？”，我可能会先去找到该任务的创建入口，然后顺藤摸瓜，找到任务的调度逻辑，顺着 happy path 找到下发任务的逻辑，再找到 Woker 的处理逻辑，这样就能弄懂整个调度流程 最后如果能用 一句话 回答提出的问题，那可能能说明你对这个问题涉及的知识已经有了一个比较好的理解 英语很重要 大多数项目的注释、日志等的都是英文，看懂这些能极大提高效率

Year 2038 problem 在 CS50 第 01 讲：C语言 中，提到了一个很有趣的问题：Year 2038 problem，这个问题指的是：一些使用 32 位来存储时间戳的计算机，在 2038 年，可能会出现整数溢出的问题，导致计算机的时间倒退回 1901 年 时间戳 指得是：UTC 1970 年 1 月 1 日 0 时 0 分 0 秒到现在经历的秒数，用时间戳就可以表示当前的时间 为什么会出现这个问题呢？因为时间总是在流逝，所以每时每刻时间戳都在增加，但是 32 位的存储空间是有限的，总有一天会超出所能存放的最大值，而反直觉的是在超过了最大值后并不是归零（时间戳回到 1970），而是倒退到了更前的 1901 年，对应下面的表格我们就可以更直观地看到几个时间戳对应的具体时间 时间戳 对应的 UTC 时间 0 1970-01-01 00:00:00 2147483647 （32 位 int 最大整数值：2^31 - 1） 2038-01-19 03:14:07 -2147483648 （32 位 int 最小整数值：-2^31） 1901-12-13 20:45:52 可以看到当存储超过位数能容纳的最大值时，该值会从一个非常大的正数突然变为一个非常小的负数，所以导致了日期回到了 1901 年 原码、反码、补码 计算机底层是通过二进制的方式存储整数，两者转换可以参考文章：二进制和十进制之间的互相转换，除了整数的大小，还需要存储的是整数的正负，一般首位（最高位）用于存储正负，0 代表该整数为正数，1 代表该数为负数，将一个整数对应的二进制数转化为计算机存储的二进制数，这个变换就是《数字逻辑电路》里面经常提到的原码、反码、补码转化。注意：正数和 0 的原码、反码、补码相同，负数则需要转换 我们回顾一下，以 4 位二进制表示的整数举例：0 的原反补码都是 0000，1 的原反补码都是 0001，而 -1 该如何表示呢？ ...

不根据协议使用开源软件可能面临的风险 2003 年 Linksys 公司（同年 3 月被思科收购）推出 WRT-54G，这款路由器采用了基于 Linux 的固件，而 Linux 使用的是 GPL 开源协议，所以思科迫于压力，开放了 WRT-54G 的源码，这使得爱好者们知道了路由器固件的实现方式，进而促成了各种相关开源项目的繁荣，其中就包括 OpenWRT Android 和 Linux 内核 的关系 Android 使用了 Linux 内核，而 Linux 内核采用的是 GPL 的开源协议，所以 Google 修改了 Linux 内核，使得驱动程序可以在 Linux 内核的上层运行，这样上层的代码可以绕过GPL协议。这也使得所有 Android 上的开源驱动，不经过修改无法直接用在 Linux 内核上，造成了Linux 内核的分裂，所以 Linux 内核开发小组撤下了 Android 所贡献的代码 而非内核部分，Android 开源项目 (AOSP) 许可提到了： 对于用户空间（非内核）软件，相比其他许可（例如宽通用公共许可证 (LGPL)），我们更倾向于 Apache 2.0（以及 BSD 和 MIT 等类似许可） 我们为自己的代码首选 Apache 2.0 因为 AOSP 采用了 Apache 2.0 协议，所以任何人都可以基于 AOSP 开发自己的 Android 系统，而且不需要开源，国内的一些定制 Android 系统都是基于 AOSP，具体可以参考定制Android固件列表。虽然 AOSP 是开源的，但是 Google 移动服务 GMS（Google Mobile Service）是闭源的，GMS 中包括，如果手机厂商想要使用 GMS，就必须向 Google 支付授权费。GMS 包含了 Google 自家的App 和服务，除此之外海外 Android 平台发布的 App 严重依赖 GMS，没有 GMS 可能导致软件无法使用等问题，Google 禁止华为对 GMS 的使用，导致华为手机海外出货量大幅下降 ...