一直以来，我对于写周报、日报比较反感。之前曾经试着写过一段时间，但还是写的不够好，容易因为自己的惯性而放弃记录。即使是记录的最频繁的日记，也时常因为变成流水账而失去其意义（但不得不说，即时是流水账，在若干年后回头再看， 还是非常感动的，所以即使是流水账，也还是要记录的）。
而回到我们自身的发展，一个更快的迭代周期，可以帮助我们更好的完成自我的成长，将一个更大的飞轮，变为一个个更小的飞轮。
化整为零，能够让我拥有更多的犯错机会，更快的改正机会，避免一次憋个大招，待到发现事情不对，已经失去了改进的机会。
做事总是会有惯性，我们日复一日，年复一年的坐着我们手头正在做的事情。
但正在做的事情未必就是对的，也可能只是因为惯性，我们习惯了罢了。
学会定期 Review 你自己的工作、生活、一切你已经习以为常的事情，他们可能并不对。这些不对的事情逐渐积累，遵循着复利的力量，将你推入深渊。
做事之时，不妨停下来想想，我现在做的事情，真的对么？
在豆瓣选电影的时候，突然看到了熊出没，点进去一看，评分 6.5 分，感觉还行。
突然想起来，不知道在孩子们眼中，这部电影的评分应该是多少？毕竟从评论上来看，似乎并不全是孩子们的评论，反而大部分可能都是成年人的评论。
成年人的世界和孩子们的世界是不同的，我们所看到的世界，看待问题的视角，和孩子们也是不同的。汝之蜜糖，彼之砒霜，我们所喜爱的事情，可能孩子们十分讨厌，而孩子们喜欢的事情，可能在我们看来都是很低龄的。
那，到底什么样的评分，才能真正代表这类低龄向的内容的评分呢？我想，成年人居多的评分大概率是不行的。
创作并非凭空捏造。用张小龙的话来讲，创作是把我们自己置于一个可以帮助我们创作的环境当中。对于不少人来说，创作是一个非常困难的事情，毕竟我们的日常是简单、重复和无趣的，并没有那么多有趣的事情值得我们来创作。
想要达成每日创作的目标，你需要学会记录自己的每一个日常，并试图从其中发现不同。当然，你可能发现不了任何不同，但不影响，你依然有别的选择 —— 比如每天问自己一些问题。
或者，每天打开一个你所在领域的网站，看看他们都在聊什么，并基于你自己的经验，选择其中你有自己观点的内容，并发表你的看法。
独立开发者在做一些应用的时候，往往很容易跳过一些过去在公司协作时的环节，直接写代码。
但我其实更推荐大家在做自己的独立产品时，要遵循自己熟悉的软件开发流程，按照流程来做。当然，你不是一个专业的产品，也不是一个专业的 UI，可能并不能做的很好。但区分不同的角色思考同一个问题，可以让你更加关注你要解决的问题，找到所有问题中的重点和次重点。
明确重点和次重点后，在随后的产品设计和 UI 设计环节中，你可以以一个 相对低成本的方案来完成思维和逻辑的推演，完成完整的推演后，再正式的进入开发阶段。
毕竟，在设计软件上拖拖拽拽，怎么也是要比你自己写代码更快的。
经常在论坛里看见到一些吐槽：自己接手的代码里屎山成堆，没得选，只能基于屎山进一步维护。
但为什么会是这样？
本质上是从老板的视角来看和从工程师的视角来看问题不同。工程师作为具体的执行者，希望每件事都尽善尽美，提升自身的价值，打造完美的产品。
而作为老板，往往面临的是资源有限，能做的事情又足够多，这个时候需要选择 ROI 更高的事情来做，很容易在不断解决客户问题过程中，累计历史债务。
当然， 我们可以通过一些管理手段来降低历史债务累计的手段：
此外，在解决屎山的时候，同样需要选择，如何解决屎山，以获得最高的效益。
选择，无处不在。
作为一个追求饱和式信息辅助决策的人，我最常遇见的问题就是信息太多。大量的信息源，造成接收到的信息远超他人。
但一个人的信息消费量终归是有限的，我始终是无法消费所有的信息的。所以， 我借助一些方法来调整自己的信息源，提升自己的信息消费效率。
在用 RSS 对抗算法推荐中我提到，我看论坛也不是使用网页浏览，而是选择使用 RSS 的方式来阅读。核心的原因便是 RSS 的阅读方式，可以让我同时看到几十条帖子，这样我就可以只关注我自己的最在乎的内容。
同时 RSS 的阅读界面相比于论坛、智能推荐系统，干扰项更少、内容密度更大，可以让我更好的完成信息的快速阅读、过滤、阅读。
我一直续费 InoReader 的原因是 InoReader 为我提供了信息过滤的功能，我可以设定我不感兴趣的关键词，并将对应的关键词内容过滤掉，从而只看我感兴趣的内容。(这样可能会造成信息茧房，不过我过滤的关键词往往是有特定的原因，比如我不求职，就可以把所有和求职相关的帖子过滤掉，这种茧房是可预期的）。
现有的系统可以很好的实现信息的阅读和过滤，但我一直觉得还差一个功能：对信源进行信噪比评分，对于评分低于某个数值的，视为该信源无价值，重新review 是否要停止订阅该信源。
理想情况下，应该基于某个信源被过滤掉的条目除以同一时间段所有条目得出噪音占比，对噪音占比高的信源进行过滤即可。
在看《流浪地球》的时候，有个词挺有意思：「饱和式救援」，讲的是同时安排多个团队去解决一个问题，这样的冗余操作可以在极端情况下提升目标达成的可能性。毕竟有多个备份总要有一个可以达成目标。
回过头看我自己的决策习惯，我是一个追求饱和式信息来辅助决策的人。我习惯性的收集尽可能多的上下文，并基于自己收到的上下文来做决策，以图达成最优解的选择。
当然，没有人能做出绝对的最优解，我们都有自己的可见的上下文范围和不可见的上下文范围。我们终究没有全局之眼，我们无法达成绝对的最优解。
此外，饱和式信息辅助决策的另外一个问题是，比较容易陷入到无尽的上下文收集当中，必须要给自己一个明确的时间限制，才能确保自己不至于不停的收集上下文，而忘记了更重要的是决策（毕竟没有什么是“准备好了”的时候）。
我看 V2ex 之类的论坛的方法和大部分人不太一样，我并不会常去网站上看相关的内容，更多是通过 RSS 来完成对论坛的阅读。
主要的原因是直接浏览网页虽然体验可能最好，但会让你不自觉的陷入到事情的讨论当中，而 RSS 的阅读方式，则可以让我快速的浏览文章的标题，判断这个内容我是否感兴趣，再点进帖子内容查看，十分有效的提升了我阅读的效率。
RSS 阅读给我带来的另外的好处，便是上帝视角。
通过 RSS 阅读帖子，我看到了同一个论坛的同一时刻，大家对于同一个问题的看法可能是截然不同的，清晰而深刻的感受到了世界的参差。
挺好
在 V2ex 看到一篇帖子，吐槽微信小程序不够好用，原话是“小程序发布这么多年了，调试器也还都是抄的 chromium ，怎么还是一坨屎一样，开发者就活该不配被当人看吗？“
从用户的视角来看，这么当然是合理的，体验差的点是值得被修复的。不过，在大厂的叙事中，这可能是不够的。
作为一个曾经在 TOP 大厂待过的人，我深知大厂的叙事逻辑 —— 凡事看 ROI，以及做最重要的事情。
以小程序开发者工具为例，他体验不好的点是有非常多的，开发者的数量远大于研发团队的数量，所以会有大量的任务值得、等待被解决。但终归人手有限，开发团队只能选择其中一部分事情能做。
这个时候做事就会自然而然推向最重要（比如老板们能关注到的）、ROI 最高的（用户反馈最多、对销售产生最大价值的）。这种方式让大厂的资源可以更集中的被利用在那些大事上，帮助大厂们在做重要的事情快速推进。当然， 也会让每一个个体都有可能成为被忽略的数字，毕竟，单个个体的声音太过渺小。
大厂叙事在做满足 80% 的需求的时候，是很有效的，因为他解决了大数的问题。但还有 20% 的需求是无法被满足的，资源总是不丰富的，这 20%，就是留给独立开发者、小公司的空间。
在逛 V2ex 的时候，看到一个帖子，大体上是说自己工作 7 年，没有什么技术进步，顺便聊一下自己的看法。
做为公司中的职工，我们每个人都有两面：
公司作为一个盈利机构，主要的任务还是赚钱，所以，我们的工作当中可能大部分时间和精力都在做当下面的事情。而我们作为个体，如果希望自己得到成长，则必须投注精力到未来面当中，才能让自我感到提升，让收入得到提升。
时间上的冲突，让我们无法有充足的时间投入到未来面，而我们又希望得到提升， 就需要从当下面中寻找机会，做既可以满足当下面同时又可以投注到未来面当中的事情。而想要达成这样的目标，我们不能仅仅是 —— 完成自己的工作 。
我们还可以做的是：
这样的方法和方式还有很多，如果你不知道什么事情是能够帮你投注未来面的，就以终为始，问问自己，假设未来我还要做这样一件事，什么样的事情可以帮助到我自己？
最近打了第三针疫苗，突然想起来了一个事情，之前有说过，新冠疫苗是无法防止你感染的，只是能够防止你重症。这和我们以前理解的疫苗不同的。
之所以不同，主要是因为新冠病毒的变种非常多，同时可能会有多个毒株流行。这些毒株之间虽然有亲缘关系，但又不完全相同，很有可能其特征有所不同，导致我们身体的免疫系统并不能很好的识别到不同分支的新冠病毒。
而这种不同，就造成了人是有可能感染新冠病毒痊愈之后，再次感染其他毒株的。而我们所注射的疫苗，也只能为我们提供一定特征的灭活病毒，我们终究还是有可能感染这个特征以外的新冠病毒的。
😮💨，难。
在学生时代，我总是很讨厌考试。因为自己考的不好，所以总是挨批评。
到了工作以后，也有一些反感“总结”、“复盘”，仿佛这些总结和复盘是另外一种形式的考试。
但当你仔细想想，「假设」考试是为了你好；总结和复盘也是为了你好，
我们就会发现「考试」其实是为了帮助我们明确自己当前所在的水位，明确这个水位以后，我们好有针对性的去学习和提升。
而总结和复盘也类似，其实是为了帮助我们做好上一段工作中的分析，从而为下一段工作提供燃料，让我们更近一步的好好工作。
当然，你可能会提出：这个前提不一定成立呀？
没错，从他人的视角来看的时候，这个前提不一定成立。但当复盘和总结的发起人是我们自己时，我们的立场和前提是明确的，我们无需为他人复盘、无需为他人总结，我们只需要为自己而学习。
我在尝试执行 rpi-update 给自己的树莓派做固件升级时，提示了如下报错。
Make sure you have ca-certificates installed and that the time is set correctly
Code language: JavaScript (javascript)经过研究，发现是因为 rpi-update 的自更新域名被国内封禁了（挂载 github content 上），导致无法通过自检，只能跳过自检来更新。执行如下命令，即可跳过自检完成更新。
UPDATE_SELF=0 rpi-update
由于树莓派跑内网，再加上这个树莓派算得上是我的实验机器。因此便打算直接使用 root 来完成日常操作，懒得在 pi 和 root 用户之间切换了。而 root 登录，我又不希望使用密码登录（以我的懒散的性子，可能会设置一个比较短的密码），便为树莓派配置了密钥登录。
先使用 pi 登录到树莓派上，并切换至 root 用户。在 root 用户下，将我本地公钥复制，并放在 ~/.ssh/authorized_keys 当中，保存并退出。
接下来，就可以在本地以 ssh root@ip 的方式直接登录树莓派了。为了简化这个ssh命令，我还配置了 SSH Config 的别名，来简化我的登录命令（具体可参考 如何用 SSH Config 来优化你的 SSH 连接？）
树莓派的官方源在海外，国内访问时速度难免不理想。再加上软件更新又是一个常态化的工作，所以我就希望将其切换成国内源，以加速软件更新的速度。
玩 Linux 的，更换源简直再正常不过了。
修改 /etc/apt/sources.list 文件，将其中内容替换为如下内容，即可完成源的替换。
deb http://mirrors.tuna.tsinghua.edu.cn/raspbian/raspbian/ bullseye main non-free contrib rpi
# deb-src http://mirrors.tuna.tsinghua.edu.cn/raspbian/raspbian/ bullseye main non-free contrib rpi
Code language: PHP (php)替换完成后，记得执行一次 apt update ，来更新掉本地的 APT 缓存。
React 相比于 Vue 的好处是你可以相对轻松的将一个组件抽离出来，这使得开发者可以根据自己的需要进行抽象。
但手动抽象组件还是相对较麻烦，于是我便搜索有没有一些方便的插件，可以帮助我更好快的完成组件的抽象。于是乎便找到了 Wix 出的 glean 插件。
glean 插件可以将任意层级的组件抽出为一个全新的函数，并在之前的位置引用你的函数，因此，你可以先非常快的构建出一个完整的 UI 界面，再基于这个界面，进行不同层次的抽象。或者是在开发界面时，随时根据需要来完成界面的抽象。
在实际使用过程中，你可以将 glean 插件提供的命令设置为快捷方式，从而实现更快的抽象组件，或者是点击组件前的黄色小灯泡💡来完成组件的抽象。
Kindle 无法设置熄屏时间，所以隔一段时间， Kindle 就会自动进入到熄屏状态。而如果你希望保持 Kindle 保持常亮（比如在下载电子书的时候），则可以在 Kindle 的搜索框中输入 ~ds ，并按下回车，即可开启 Kindle 的常亮模式。
在 Kindle 的常亮模式下，你无法关闭屏幕（甚至是物理按钮都没用），如果希望恢复正常，则必须进入「设置」—「设备选项」—「重启」，才能将 Kindle 恢复到会自动关闭屏幕（且可被关机）的状态。