Weekly#16

尽管现在比较少在身上带一大串钥匙 （毕竟不是包租公） ，但如果你有很多钥匙的时候，你应该将钥匙排序好，让钥匙保持同一个方向。

这样，每次你要开门，只要顺序地使用钥匙就好了，不需要再调整钥匙方向，能减少一些心智负担和节省时间。

还可以在钥匙中间放一个小饰品，放在第一把钥匙和最后一把钥匙之间，这样就能快速找到第一把钥匙，找后面的钥匙也会更容易。

佩服作者对于这种细节的观察和效率提高。

以前使用钥匙从来没有考虑过可以去优化它，让自己使用起来更轻松，每次使用都是各种尝试，比较费时也让人心烦。

生活工作中也有很多事情可以去优化吧，只是往往养成了习惯，不愿意思考和改变。

文章认为开源技术，和大公司提供的技术不能相提并论，大公司除了产品，还提供了许多的服务和支持。

但是开源软件往往就是一个产品，没有额外的服务和支持。

想用开源去替代大公司的产品是可行的，代价就是失去了大公司提供的服务和便利，增加自己使用的一些维护成本。

但是，将开源技术与大型技术相提并论，就好比将烤箱与餐厅相提并论。大型科技公司提供支持良好的服务…

Source

在向大公司和政府销售软件的过程中，制作最好的软件远不是最重要的因素。

最重要的是能够满足所有需求。

而且，不要误解我的意思，支持、培训、迁移、托管和类似方面也是极其重要的。

即使你已经构建了软件，但结果却是，要向大公司和政府销售你的软件，需要付出令人难以置信的额外努力。

如此费力，以至于连苹果公司都不愿意尝试，尽管在这一市场中可以大赚一笔。

Source

史蒂夫-乔布斯曾经说过：“我喜欢消费者市场，而我一直憎恨企业市场，

那就是我们推出一款产品，并试图向所有人介绍它，而每个人都会为自己投票。

…

这真的很简单。而在企业市场，情况就没那么简单了。

使用产品的人不会自己做出决定，而做出决定的人有时也会感到困惑”。

Source

最终，我们将不可避免地希望在完全主流的平台之外尝试一些不同的东西。

但是，不要错误地把仅仅开源称为一种替代方案 —

用户需要的不仅仅是软件，还有大量的服务，而这些服务仍然需要在某个地方找到，而且不会因为软件是免费的就更便宜或更简单。

Source

我就喜欢脚踩西瓜皮，随便从一个句子开始，然后一路滑行。

当然，大约的方向是有的，我知道自己大概要朝着某个方向去，但是具体怎么个滑法我事先不知道，也不关心。

对于我来说，踩上西瓜皮之后自然会清楚，重点在滑。

Source

我写这篇文章的目的是为了告诉你：可以不一样的，你可以按照你的方法来，而且合适你自己才是最高标准，不是什么对不对，不是什么大家都，更不是什么名家都。你没有大纲就写不下去，那你就去写大纲。你就喜欢脚踩西瓜皮，那你就去做乡土版哪吒。无论是哪一种，追随你赤裸的心，你都可以达成你的目标。

对了，错了，都不如你最后写出来什么，你喜不喜欢持续写来得重要。事实上，唯有你保全自我，才能保全你的灵性。你保全你的灵性，你才有激情、创意以及从创作中得到的纯粹快乐。而这种快乐，甚至可以和任何人都无关。哪怕你一个人走在满是陌生人的街上，一想到自己可以那样去做，都觉得内心异常充实饱满。

Source

蛮喜欢作者这样的写作态度的。

我写博客还是会大致写一个大纲，写几个 heading，大概规划一下方向，剩下的就自由发挥了。

与其考虑那么多条条框框，不如先行动起来，好坏对错都无所谓，关键是先行动起来，让一切先有一个开始。

或许有了一个开始，就可以带自己走向很远的地方。

最近身体不太好，想多跑步锻炼，但是以往都是跑 5 公里，觉得锻炼就得跑到这么多才算数，但是对于现在的我来说，是有些困难的。

想到这些困难，我就不想去跑步了。

而最近用的小米手环 9 里一个跑步课程，里面有一个基础跑走结合，是一个 2 分钟快走 + 3 分钟慢跑的组合，循环 3 轮。

有时下班回来很晚了，时间也不多，就按照这个简单的课程来跑。

虽然这个课程很简单，总的跑步里程可能也就 2 公里，但还蛮适合我的，也让我有一种锻炼了身体的良好感觉。

我意识到，取得进展的感觉与取得实际进展同样重要。

这让我大开眼界。一旦我开始每天都取得持续的进步，焦虑就开始消散。

Write Code Every Day

所以如果你也想做点什么，不必顾虑那么多，先行动起来看看吧！

To make some good progress, you just need to overcome a bit of laziness at the beginning every time.

要想取得一些好的进展，你只需要克服每次开始时的一点懒惰。

Source

Angular 团队计划更新他们的 style guide，目前正在征集一些社区的建议。

Headless components 指的是那些没有预置样式，只封装了交互逻辑的组件，方便使用者自由地定制组件样式。

Headless components 将组件拆得比较细，使用的时候像是拼接积木一样，也能对每一个部分做样式调整，相比 Element 等组件库，灵活性更高一些。

人容易产生 确认偏误，容易带着自己的偏见，固执己见。

有的东西看似简单，但是深究内部有可能并没有自己以为的那么简单。

这提醒我需要尽量避免成见，避免自以为是。

研究人员指出，即使在证据“完全驳倒了他们的信念之后，人们也无法对这些信念做出适当的修正”。

撇开许多所谓的认知科学术语，梅西埃和斯佩伯的论点大致如下：与其他物种相比，人类最大的优势在于我们的合作能力。

合作很难建立，同样也很难维持。对于任何个体来说，“吃白食”永远是最好的选择。

理性的发展并不是为了让我们解决抽象的逻辑问题，甚至也不是为了帮助我们从陌生的数据中得出结论；

相反，它的发展是为了解决在协作群体中生活所带来的问题。

人们总是倾向于接受支持自己信念的信息，而拒绝接受与之相悖的信息，这就是所谓的“确认偏差”。

如果理性是为了产生正确的判断，那么很难想象还有比确认偏差更严重的设计缺陷。

梅西埃和斯佩尔伯认为，想象一下，有一只老鼠会像我们一样思考。这只老鼠 "一心想要证实它认为周围没有猫"，很快就会成为晚餐。

人们相信自己知道的比实际知道的要多得多。让我们坚持这种信念的是其他人。

…

这是人类非常擅长的事情。自从我们发现如何一起狩猎以来，我们就一直依赖彼此的专业知识，这可能是我们进化史上的一个关键发展。

斯洛曼和费恩巴赫认为，我们合作得如此之好，以至于我们几乎分不清自己的理解在哪里结束，别人的理解在哪里开始。

看待科学的一种方式是将其视为一个纠正人们自然倾向的系统。

在一个运行良好的实验室中，不存在我的偏见；结果必须能够在其他实验室中被没有动机去证实它们的研究人员复制。

可以说，这就是该系统如此成功的原因。

在任何特定时刻，一个领域都可能被争论所左右，但最终，方法论占了上风。

他们引用的研究表明，人们在处理支持自己信念的信息时，会体验到真正的快感–一种多巴胺的冲动。

“他们认为：即使我们错了，‘坚持己见’的感觉也很好。”

作者也挺不容易，孩子快生的时候碰到失业，但是家庭给予的支持还是很够的。

作者老婆问的一个问题，我也不知道该如何回答：

即便你找到了工作，身体还能承受得住吗？

三年后四十岁，再碰一次裁员，我们又该怎么办？

国内对于程序员的年龄歧视还是挺多的，不像国外，看起来大龄的程序员都很多。

随着年纪的增长，确实身体没有年轻人那么好，要有竞争力，就得积累一些东西，经验，技术，人脉，行业知识等等。

另外一个残酷的事实是，大部分人对于公司而言都不是不可或缺的，你走了，再找个人也能继续让公司运转。

不要对公司抱有太多幻想，不要心存侥幸，保持自己的竞争力。

作者的菜谱看起来都挺简单的。

以前自己一个人生活的时候也不会做饭，觉得做饭很麻烦，又要买菜，各种调味料也搞不明白，食材也不知道怎么处理。

后来和女朋友同居之后，因为女朋友有会做饭，于是我也就学了一些，菜可以去超市或者叫外卖，食谱则是根据食材去小红书找。

到现在也做过不少次了，椒盐鸡翅，咖喱，冬阴功，白灼虾，醋溜白菜，大葱豆腐……

家里的调料也配置得很齐全，勾芡也大概明白是什么回事。不过鸡鸭鹅鱼，肉类这些还是不太会处理。

自己做饭，也不难吃，有的甚至觉得还不错，主要是一些调料的比例做饭少不清楚，可能达不到餐厅的调味。

自己做饭相对而言还是比点外卖要划算，同样的价钱，除了菜，还能买到饮料和水果，可以吃得很丰盛。

做过饭之后，像是文章里的一些快手盖饭，看起来确实是挺简单的，以后可以尝试一下。

作者分享了一些例子，如何在 Web 开发中使用 makefile。

以前也看过一些相关文章：

• makefile tutrorial
• How I stopped worrying and loved Makefiles
• I Like Makefiles

后面我会尝试一下，我觉得 makefile 的一个优点就是可以统一操作，执行构建只需要执行 make build, 而不用考虑是用 npm，yarn 还是 pnpm，或者其他语言的构建命令。

统一之后就能减少自己的心智负担。

Code Review 除了阅读代码，给出合理建议之外，比较困难的是如何和提交者友好有效地沟通，如果 review 建议看起来像批评，很可能会让对方排斥厌恶。

如果程序员给你发送了一份他们认为很棒的变更列表，而你却给他们写了一大堆理由来解释为什么它不棒，这就是一个需要传达的敏感信息。

作者很容易将对其代码的批评理解为暗示他们是一个不称职的程序员。代码评审是分享知识和做出明智工程决策的机会。但如果作者认为讨论是一种人身攻击，这就不可能实现了。

如果这还不够困难的话，您还面临着以书面形式传达您的想法的挑战，在这种情况下，沟通不畅的风险更高。

作者听不到你的语气，也看不到你的肢体语言，因此更需要谨慎地表达你的反馈意见。

对于有防卫心理的作者来说，“你忘了关闭文件句柄” 这样无伤大雅的注释可能会被解读为 “我无法相信你忘了关闭文件句柄！你真是个白痴”。

作者提出了几点建议：

让计算机来完成无聊的部分

用格式化工具，lint 工具，CI/CD 处理空格，换行等格式问题，减少人工 review。例如可以使用 husky，在提交之前执行 Prettier 和 ESLint，可以参考 Git 的校验实践 。

用风格指南解决风格之争

用风格指南统一风格，避免在风格上争论。可以使用现成的，也可能自己从头整理，或者基于现成的扩展。像是前端项目，用 eslint 也能约束大部分风的编码风格。

立即开始审查

对方可能正在等你的审核，审核之后可能还要解决一些合并的冲突，所以最好及时 review。

一轮审核的绝对最长周转时间应为一个工作日。

如果您正在处理优先级更高的问题，无法在一天内完成一轮审核，请告知您的队友，让他们有机会将该问题重新分配给其他人。

如果您被迫拒绝审核的次数超过每月一次，这很可能意味着您的团队需要降低速度，这样才能保持正常的开发实践。

从高水平开始，逐步降低

如果 review 意见太多，会让提交者不知所措， 所以最好控制数量，可以先提出高层次的问题，一些细枝末节的可以放一下。

在某一轮审核中，你写的注释越多，就越有可能让作者感到不知所措。

具体的限制因开发者而异，但危险区一般在一轮审核中写 20-50 条笔记的范围内。

如果你担心会把作者淹没在笔记的海洋中，那么在早期阶段，你可以只提供高层次的反馈意见。重点关注重新设计类接口或拆分复杂函数等问题。

等到这些问题解决后，再处理较低层次的问题，如变量命名或代码注释的清晰度。

慷慨提供代码示例

如果一个建议我不熟悉怎么做，可能我会觉得烦，毕竟增加了我的工作量，但是如果审核者能给我一些链接和实例，减轻我的学习成本，我觉得是很开心的。

在一个理想的世界里，代码作者会对他们收到的每一份审核都心存感激。

这是他们学习的机会，也能保护他们不犯错误。

在现实生活中，有很多外部因素可能会导致作者对审核产生负面看法，并对您给他们提供的注释产生反感。

也许他们正面临着截稿的压力，所以除了你即时盖橡皮图章的批准之外，其他任何事情都会让他们觉得是一种阻碍。

也许你们合作不多，所以他们不相信你的反馈是善意的。

让作者对审核过程产生好感的一个好办法就是在审核过程中找机会给他们送礼物。所有开发人员都喜欢收到的礼物是什么？当然是代码示例。

如果你能写出一些修改建议，减轻作者的负担，就表明你作为审稿人是慷慨的。

…

“我们能用列表理解来简化这个问题吗？” 这会惹恼他们，因为现在他们必须花 20 分钟来研究他们以前从未使用过的东西。 …

每轮审核中，你只能写两到三个代码示例。如果你开始为作者编写整个更新列表，就表明你认为他们没有能力编写自己的代码。

永远不要说 “你”

说 “你” 🫵 ，很容易让人产生一种被冒犯的感觉。可以换成 “我们”，或者不要使用主语。

• 例子 1
  • bad
    • You misspelled ‘successfully.’
  • good
    • sucessfully -> successfully
• 例子 2
  • bad
    • Can you rename this variable to something more descriptive, like seconds_remaining?
  • good
    • Can we rename this variable to something more descriptive, like seconds_remaining?
    • Suggest renaming to something more descriptive, like seconds_remaining.
    • This variable should be renamed to something more descriptive, like seconds_remaining.
    • What about renaming this variable to something more descriptive, like seconds_remaining?

将反馈作为请求，而不是命令

没人喜欢被人命令，强迫，换一种语气，用一种商量，请求的语气更容易让人接受。

• bad
  • Move the Foo class to a separate file.
• good
  • Can we move the Foo class to a separate file?

将笔记与原则而非观点挂钩

评论的时候应该有理有据，而不是基于自己的喜好和观点

• bad
  • 我们应该将这个类一分为二
• good
  • 现在，这个类既负责下载文件，又负责解析文件。我们应该根据单一责任原则，将其拆分为下载类和解析类。

软件开发既是一门艺术，也是一门科学。你不可能总是按照既定的原则准确地说明一段代码出了什么问题。

有时，代码就是难看或不直观，很难找出原因。在这种情况下，请尽量解释，但要保持客观。

如果您说：“ 我 发现这很难理解”，这至少是一种客观的陈述，而不是 “ 这 会让人看不懂”，后者是一种价值判断，不一定对每个人都适用。

尽可能以链接的形式提供佐证。

团队风格指南的相关部分是您可以提供的最佳链接。您还可以链接到语言或库的文档。

高票通过的 StackOverflow 答案也可以起作用，但是您离权威文档越远，您的证据就越不可靠。

作者介绍了如何使用 Eleventy 构建简历，简历看起来比较简洁。

我自己以前也写过一个简单的简历工具：markdown-resume，将 markdown 转换成 HTML，然后打印成 PDF，对我来说比较简单也够用了。

== 实现了一种称为 抽象等价比较算法 (Abstract Equality Comparison) 的东西，这是一个通过 13 个步骤确定两个事物是否等价的过程。

现在写 JS，像是 eslint 会限制只能用 === 做比较，如果用 == 则会报 warning。

加上现在有 TS，在类型比较上要求就更严格了，所以一般来说编码的时候应该都会使用 === 。

== 的比较还是有点复杂的，作者尝试按照规范定义，用 JS 实现 == 比较的逻辑，对理解 == 的运作有所帮助。

看看别人如何一步步实现算法，也蛮有趣。

再次觉得文档很重要，像是这些语言实现的规范，任何人只要按照规范描述都能实现相同的功能。

正如我在文章开头所说的，重新实现这个算法基本上是无用功。

我希望它能证明，不鼓励使用 == 是有原因的：这是一种相当复杂的算法，会产生一些令人惊讶的结果。

请使用 === 代替它！

较早的时候，为了避免一些图片发起多次 HTTP 请求才能获取，会将这些图片做成一张雪碧图 (sprite sheet)。

然后通过定位和裁剪，获取对应的图片。

雪碧图除了这个功能外，还可以用来制作动画，把动画的每一帧放在雪碧图里，然后滚动雪碧图，就能得到动画。

文章作者详细讲解了如何实现，以及和其他一些动画技术的比较。

竟然有人在一直求解最大质数，挺酷的。

有人利用 Hacker News 的数据绘制了一张数据地图，数据密密麻麻的，像个小宇宙。

以前用 org-roam 做笔记，笔记之间存在双链，通过 org-roam-ui 也能形成类似的数据地图，挺好玩的。

让作者大开眼界的编程语言。

我接触的编程语言不多，写过一点 Elisp，但不多，说说它让我觉得不一样地方：

• 很多的括号
• 描述是函数和变量不可或缺的一部分，这样别的地方看函数和变量都能容易知道它的作用
• 函数可以是交互式的，这样可以直接在 Emacs 中通过 M-x 调用
• 代码编写完就可以就地执行，很容易看到效果

Title drops 指的是在电影中，电影的名字被说了出来。

作者分析了很多电影，看看 Title drops 是否和电影质量有关。

页面的排版，图表，电影进度条看起来都很不错。

“护照照片”是最平凡无奇的摄影类型之一。官方对护照照片的要求非常严格，包括拍摄对象必须直面镜头、背景清晰无阴影、眼镜无眩光，最重要的是不能有笑容。

该系列试图挑战这些官方规则，测试您在拍摄正式证件照时可能做的所有事情。

ASCII 拍立得相机，拍完就能打印出来 ASCII 组成的照片。

命令行工具，可以用来和一些云存储服务进行交互。

在真正执行命令之前，建议先添加 --dry-run 看看执行效果，不然可能一下子覆盖/删除了文件，恢复起来比较麻烦。

另外使用的时候需要注意哪边是 source，哪边是 target。

Rclone is a command-line program to manage files on cloud storage.

It is a feature-rich alternative to cloud vendors' web storage interfaces.

Over 70 cloud storage products support rclone including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.

页面比较简洁的一个打字练习应用，我的 WPM (Words per minute) 只有 40，正确率大概 85% 左右。

发现如果不纠结打错字，WPM 也只能达到 50 多，而且 50 多的 WPM 感觉还是挺快的，比较累手。

探索并找到与身份验证、授权以及身份和访问管理 (IAM) 相关的关键词汇的清晰定义。

使用开放标准，如 OpenID Connect、OAuth 2.0 和 SAML 。

命令行工具，使用深度学习判断文件类型。

一个用来解读论文的 AI 工具。

对于何时应该行动起来，永远是：Now, not How。

不要纠结太多，先行动起来~

1. 对入职前的代码尊重，不论是神仙代码还是屎山代码，至少它赚钱了，不然也轮不到你入职。
2. 对入职前的代码感恩，你可以试着重构，不能就加入其中，也许前任也是这样干的，但是他没成功，于是机会轮到你了。
3. 你上班的目的是赚钱，公司聘请你的目的是赚钱，一切运转向钱看齐，你代码写得再好看再牛逼，没赚钱也是废品。

kk2syc

在职的时候怒气值高，各种讽刺挖苦;

走人的时候暗自庆幸;

两年以后忽然从这个傻逼系统得到灵感（或者教训），颇有感慨;

三年后后悔维护的时候自己抱怨太多，而行动太少;

五年后意识到自己怒气值高的原因不是因为系统傻逼，而是自己驾驭不了;

八年后再次需要维护“傻逼”系统;

十年后方才领悟，“这个世界的本质是混乱不可知，而非有序可测”;

甚至技术新旧的界限也开始模糊;

其实是，自己不够谦虚敬畏;

zeropercenthappy

经手过，也写过垃圾代码。

有时总觉得自己能写得更好，就想去重构，但是原来的代码可能考虑了比较多的边缘场景，解决了什么特定问题，自以为是地重构，以为做得更好，反而可能影响到业务。

也不是看到垃圾代码应该容忍，但是需要在了解清楚代码逻辑的前提下，再去优化。

在我看来，“只是” 这个词作为一个修饰词加在一个观点上，会带来一大堆隐含的包袱。

如果说我在软件工程方面学到了什么，那就是计算机很难，实施细节很重要，尤其是在复杂性方面。工程解决方案的复杂性很少能用一句话概括。几乎总是有更多的问题。

管理者的职责就是要知道自己的下属在做什么，做得好不好，总体上是否有效。

如果他们做不到这一点，那么他们自己就是没有效率的，而这就是他们的经理的责任，依此类推。

他们不应该需要我（或其他任何人）来告诉他们他们的直接下属发生了什么事！

Source

压抑指出谁偷懒的冲动。这只会让你自食其果。

Source

你可能会注意到，我没有提到你做了或没做的工作、做得好坏或结果如何。老实说，对大多数人来说，这些都不重要，因为管理者对整个过程的影响力太大了。

…

一个有足够技能的管理者可以把同样的工作让它对你有利或不利。他们所需要的只是一个理由，让它朝这个方向或那个方向发展。

…

作为局外人，你能做些什么呢？首先，要认识到在这些地方，工作质量（和数量）与绩效考核之间几乎没有直接联系。更多的是看你的态度，以及你让你的主人对你和你的态度感觉有多好。

其次，在给同事写评论时，不要再提供任何形式的 “弹药”。别说了。你这样做对事情一点帮助都没有。

如果你想让他们或许有所改变，那就直接跟他们谈。如果你想让他们被管理层捅一刀，那就把这写进他们的绩效考核中。

你所说的一切都会被用来对付你的同事。

Source

别做人前君子，背后小人。

在工作能够完成的时限内，工作量会一直增加，直到所有可用时间都被填充为止。

Source

这周天去听了脆莓的 live，挺好的，合唱挺开心。

最开始认识这支乐队是听到他们的《带我走》，后来也是听过一次 live，蛮喜欢他们的风格，live 里第一次听到新专的 《相爱》，《再去海边》觉得很好听，期待了很久，现在也终于出了新专辑了。

听 live 相比听专辑，有时更容易被某一句歌词打动，或许是听 live 的时候更专心点吧。

新专《镜像》整体听着都还不错，推荐你听听。

以前的周刊里也分享过 文兆杰 的歌，《太阳光明照我心》这首歌听起来非常的积极，心情不好可以听听。

专辑《太阳光明照我心》的其他歌也都不错。

另外 Hopico 的这个打歌视频里，都是一些专辑里没有的改编版本，也推荐一听。

里面伴奏的乐队 Pu Poo Platter 的歌也很不错。

这是 教授（坂本龍一） 最后一场线上钢琴演奏会了，当时看到有票就买了，一个人在海边听完了整场钢琴演奏。

这张专辑里的钢琴曲让人心情平静，尤其喜欢其中的《Aqua》。

像是 《Merry Christmas Mr. Lawrence》，也许很多人也都听过。

最开始认识教授，应该是看 《战场上的快乐圣诞 Merry Christmas Mr. Lawrence (1983)》，荧幕里的他显得有些“艳”。

后来还发现他组过一支乐队 YMO イエロー・マジック・オーケストラ，里面的电子音乐也很有好听，里面也有一些搞怪的，例如《Multiplies》这张专辑，让人捧腹大笑。

可惜教授因为生病已经离世了，世界上又少了一个杰出的音乐家。