Weekly#10

作者使用 flex 布局实现 radio box，在 label 和 input 之间设置了 gap，发现无法点击，对用户不友好，然后用 padding 替换了 gap。

It’s a small thing, but lots of small splinters lead to an agonizing experience.

这是件小事，但很多小碎片会导致痛苦的经历。

So my recipe is: sand it, feel the grain, get a splinter, sand again, and repeat until smooth.

所以我的秘诀是：打磨，感觉纹理，有刺，再打磨，重复直到光滑为止。

The reason I like makefiles is that they often follow an unwritten convention of implementing the same set of commands to get you up and running.

我之所以喜欢 makefile，是因为它们通常遵循一种不成文的惯例，即执行同一套命令即可启动和运行。

作者喜欢 makefile，是因为它相对来说比较统一，在不同地方构建一般都是 install，build，dev 几个命令，他自己也会使用 makefile 整合其他构建工具。

这样可以减少心智负担，要构建就执行 make build 就好了。

就像有的人会买很多同样的衣服，每天就从同样的衣服里拿，不用纠结穿什么衣服。

makefile 相关的资源还有：

• makefile tutrorial
• How I stopped worrying and loved Makefiles

作者在咖啡店扫了二维码，无聊用网页打开，找到了订单系统的 API，通过 API 可以给其他人下单，获取其他门店的交易情况。

一个二维码把整个订单系统都暴露了。

不过文章已经下架了。 ┐(シ)┌

和作者类似，当我开始读一本书的时候，如果没有读完，我就不愿意读另一本书。

尽管对在读的这本书不感兴趣了，还得逼着自己读完。

因为不想读，就搁置在一边，但又不肯开一本新书。

作者的建议是可以增加一个“远离书架”：

当一本书不想读的时候，可以快速看看结尾，或者看看别人的书评，然后将它放入到“远离书架”。

这样你依然有机会看这本书，但从精神上把它放一边，让自己可以轻松一些，去看新的书。

由于上述原因，我的 "当前阅读 "书架上只能有一本书，而且我必须在读完这本书后才能把它移到 "已读 "书架上，然后再换一本新书。

去年年底，我创建了第四个书架："远离 "书架。

如果我读一本书读得不开心，这个新书架就会给我一定的精神许可，让我可以把它移到 "远离 "书架，继续我的生活。

这只是一件小事，似乎并不重要，但它却能让我的大脑允许我不必读完这本书。

我仍在追踪这本书，以及我开始写这本书的事实。

我没有把它从我的 Goodreads 上完全删除。我只是在精神上（以及在网站上）把它放在一边，为其他东西腾出空间。

谁知道呢？也许我以后还会再看，但可能不会了。

书架让它保持开放性，但也不会被人遗忘。

对于电影，至少是在家里看的流媒体电影，我坚持 "十分钟原则"。

如果有人在看电影的前十分钟内不感兴趣，就可以拔掉插头。

我觉得 GTD (Getting Thing Done) 也是类似的策略，它要求你将生活的所有事情收集起来，放到一个系统中，这样脑子就不用一直记着有什么事情没做，脑子就会轻松很多，可以去思考别的事情。

如果对 GTD 感兴趣，可以看看 Getting Things Done (GTD) by David Allen - Animated Book Summary And Review 。

翻译一下标题：2024 年了，MPA(Multiple Page Application，多页面应用) 能不能用？

作者澄清了一些 MPA 开发的误区，看起来目前使用 MPA 也能得到不错的交互体验。

在我们不经意间，浏览器已经缩小了差距，并借鉴了单页面应用程序革命的最佳理念。

…

因此，现在我们可以主要使用浏览器工具 – HTML、CSS，也许还有一些 Javascript – 来构建交互性很强的甚至是离线的网络应用程序，而且在用户体验方面仍然不会有太大的损失。

浏览器已取得长足进步。给它一个机会吧！

Here’s my one simple rule for debugging:

Reproduce the issue.

That’s the only thing, really.

There are a lot of barriers to this. This is the antithesis to “it works on my machine”.

Debugging is answering the question “why?”.

Magic exists, but I’ve never seen any in software. Problems are logical. Nothing is impossible.

You can solve this problem. You just need to reproduce the issue.

Reproducing the issue should be the team’s number 1 priority.

The issue must be reproduced exactly, not just symptoms of the same behavior.

这是我调试的一个简单规则:

重现问题。

这就是关键所在。这其中存在许多障碍。这与"在我的机器上运行正常"的理念完全相反。

调试就是回答"为什么?"这个问题。

魔法存在，但我从未在软件中见过任何魔法。问题是逻辑性的。没有什么是不可能的。

你能解决这个问题。你只需要重现这个问题。

重现问题应该是团队的首要任务。

必须准确地重现问题，而不仅仅是同样行为的症状。

确实，所谓的“偶现问题”，很多时候只是找不到重现问题的方法。

Often the solution will naturally present itself in the course of debugging, usually by the time you’re successfully reproducing the issue.

It could be that by reproducing the problem, you are gaining the required knowledge to fix it.

However I think there very few actually hard problems and you’re probably not smart and/or lucky enough to work on one.

I’m not sure that I’ve ever worked on a hard problem, at least not for work.

We’re mostly just shoveling mud around in various forms with various amounts of efficiency.

很多时候，解决方案会在调试过程中自然呈现，通常在您成功再现问题时。

可能是通过再现问题，您获得了修复它所需的知识。

但我认为实际上很少有难题，您可能足够聪明和/或幸运到去解决一个。

我不确定我是否曾经解决过什么难题，至少不是在工作中。

我们大多数人只是在各种形式和效率下拧螺丝。

作者回顾了自己写博客的 15 年，为什么写博客，为什么还继续写博客。

关于为什么还继续写，作者的理由是：

• 我喜欢写作
• 写作帮助我思路更清晰，也帮我完善想法
• 发布某些东西迫使我做得更好，因为要发布给别人看，所以需要自己斟酌内容
• 这个博客是一个记录我个人项目的地方
• 看看我已经做过的事情的记录,让我感到更好
• 我乐于将博客作为一个专门解决我自身问题的项目进行开发，可以随便折腾
• 博客写作帮助我成为更好的作家，这又反过来帮助我成为更好的开发人员

It’s important to point out that it’s not external feedback that has kept me going all these years.

Yes, of course, it’s nice to get the occasional email with compliments, but that’s just a bonus.

I keep this blog for me to write, not necessarily for others to read.

重要的是要指出，并不是外部反馈一直支撑我走到今天。

是的，当然，偶尔收到赞美的电子邮件很不错,但那只是额外的奖赏。

我保留这个博客是为了让我自己书写，而非必须让别人阅读。

“Debt defines your future, and when your future is defined, hope begins to die.”

“债务定义了你的未来，当你的未来被定义时,希望开始消亡。”

But once you view debt as narrowing what you can endure in a volatile world, you start to see it as a constraint on the asset that matters most: having options and flexibility.

但是一旦你将债务视为缩小了你在动荡世界中能够经受的范围，你就会开始将其视为对最重要的资产的约束：拥有选择和灵活性。

买了房，要背负几十年的房贷，再有了孩子，感觉很多选择确实就不敢做了。

Mr.Beast 的培训资料，有一些关于如何创建爆火视频的方法。

Mr.Beast 的视频也看过一些，看起来每期视频都成本很高。

一本电子书，教你制作一个编译器，学习编译器理论和汇编知识。

书里使用的是 TypeScript 的子集，读起来像伪代码，目标是 ARM 32 位指令集。

在处理条件渲染的时候，组合组件的形式，比将所有逻辑都写在一个组件模板中会更好维护。

好处是：

• 降低心智负担
• 容易扩展
• 更好的类型推断

一些 Node.js 最佳实践：

• 不要阻塞事件循环
• 监控 NodeJS 的具体指标并采取相应行动，如内存，CPU 的使用等，当它们达到某个阈值，就需要有措施去应对
• 使用 Node LTS（Long-Term Support） 版本
• 尽可能实现测试、代码审查和一致性的自动化
• 避免依赖性攀升，避免依赖过多
• 降低依赖风险，定期检查，及时更新依赖
• 避免使用全局变量、配置或单例，主要是为了降低耦合
• 处理错误并提供有意义的日志
• 使用应用程序接口规范（如 OpenAPI）并自动生成客户端

JS 中解构赋值的使用介绍，内容比较简单，适合对解构赋值不熟悉的初学者。

作者要渲染 20K 个表情，但是页面很卡。

最开始想到的是虚拟列表的方案，后来他想到了用 content-visibility，实践后确实也有提升，但是性能还是没有虚拟列表的好，但是可以作为一个粗略的替代方案。

AbortController 的用例，通过封装，你可以通过 AbortController 中断各种逻辑。

上传图片，生成 ASCII 图案，效果还不错。

填写一个英文名，返回对应字母的地理图片，都是真是的地理位置。

ssh terminal.shop 会终端打开一个购物页面，挺有趣的。

“飞蝇时钟”

作者重新设计了他的个人网站，首页的 hero part 挺好玩的。

网站的交互和动效都很不错。

最近我也将博客改造了一下，但是相比作者，我这简直就是毛胚房 (/▿＼ )

2024 年搞笑诺贝尔奖。

解剖学奖

Marjolaine Willems, Quentin Hennocq, Sara Tunon de Lara, Nicolas Kogane, Vincent Fleury, Romy Rayssiguier, Juan José Cortés Santander, Roberto Requena, Julien Stirnemann, and Roman Hossein Khonsari, 研究了大多数人头发的旋转方向 (顺时针还是逆时针？) 是否与南半球大多数人的头发旋转方向相同。

医学奖

Lieven A. Schenk, Tahmine Fadai, and Christian Büchel，证明引起痛苦副作用的假药比不引起痛苦副作用的假药更有效。

概率奖

František Bartoš, Eric-Jan Wagenmakers, Alexandra Sarafoglou, Henrik Godmann, and many colleagues， 通过理论和 350,757 个实验证明，当你投掷硬币时，它倾向于落在与起始状态相同的一面。

一个方言语音交流平台。

一些设计的 A/B test 数据，换了设计，有的提高了 46% 的销售额，足见好的设计的重要性。

像素风格的字体，网站也很好看。

在 GitHub 上使用 .geojson 后缀的文件，可以显示成地图，并将里面的数据标记在地图上，蛮有趣的。

简洁的博客。

Josh Comeau 的博客看起来很不错，而且分享很多关于 CSS 和 JS 的知识，之前经常刷到。

How I Built My Blog

他分享了他的博客是如何构建出来的。

Hands-Free Coding

他手患病了，无法用键盘和鼠标，就用语音和眼动仪替代。

一个儿童学习平台。

一些颜文字。

git absorb 会识别一些相近的 fix 改动，自动打上 fixup! 标记，方便 rebase.

git add $FILES_YOU_FIXED
git absorb
git log # check the auto-generated fixup commits
git rebase -i --autosquash master