Weekly#28
琐碎两三事
博客有了一些关注
我想感谢一下在 follow 上给我打赏的读者
@l1uyun，以及前阵子猫鱼周刊 vol. 058对于博客文章的分享。知道有人看，有人喜欢这件事情让我很开心。(ﾉ>ω<)ﾉ
博客里没有做一些访问量的追踪，所以有多少人看我也不了解。
不过发布在了 follow 上，能了解到 follow 上的阅读量。
上周阅读量突然攀高，不知道从哪里吸引了一些没有见过的读者，不过可以最后订阅的人并不多 (´;ω;`)
不管如何，谢谢喜爱。有人看也好，没人看也罢，我也会继续更新。
写 weekly 时阅读很多网页，就像是看一本百科全书一样，还挺有趣的。
如果你还没有开始写博客，我也希望你开始写，不用担心没有读者，你可以评论留言，我去看～
以前 weekly 引用的这段话再次分享给你：
各位朋友们，谢谢你们今晚来，谢谢你们来看我们的作品。
如果你喜欢这个乐团，我们希望你也去组你自己的乐國，发表你自己的作品。
或者，无论你现在正对什么感兴趣，我们都期待你发表你的作品。
我们想象的事情是：
一开始都会很糟，但如果你一直做属于你的东西，事情最后都会变好；
这个好不是指“全世界都会超级爱你”
而是会有一小群人爱你，但他们爱得很深，爱得很有力量，那种力量会让你终于也能开始喜欢你自己。
一直到最后，直到你不必证明什么事情，你还是能喜欢你自己。
这就是我们想象的事情。
所以我们期待，你开始发表你的作品。
因为只有开始了，你才会察觉到，有人在你从未想过的地方等你。
谢谢大家。
LLM 的滥用
以前逛论坛，看到一些粘贴 LLM 的评论，我是无感的，大不了不看。
但是最近工作中，也看到了大段粘贴 LLM 内容，有的内容还是经不起推敲的，就让人相当厌烦。
LLM 的回复就像是那些形式主义的话，一套一套，一大段一大段的，没有了作者自己的思考在里面。
并不反对 LLM 的回答，我自己用的也很多，但 LLM 应该是一个工具，促进我们自身的思考，而不是完全依赖它。
顺便提一下，这就是我倾向于不喜欢事件总结工具的原因。不要让人们停止尝试拼凑发生了什么！
相反，我更喜欢看到一些工具，它们查看你的总结，以提醒你可能忘记的事项，或者寻找指向偏见或简化观点的语言线索。
News | Article
Cleaner codebase, happier mind
干净的桌面相比凌乱的桌面，会让人心情更好一些。
有时，把一个地方打扫干净，也会带来一些成就感。
对于代码库也是一样，把一些“垃圾代码”打扫干净，在后续维护的时候也会更愉悦。
让我强调，我并不是在谈论 Uncle Bob 的 clean code；
我指的是每个人都希望完成的琐事，但显然没有人有时间去做——作为技术债务积累的杂物。
每个代码库都有这样的东西，你一眼就能看出来。
那个每 20 次就失败一次的脆弱测试，毫无明显原因。
那个可以用更现代基础设施合理实现的遗留组件。
那个你仅仅为了持续集成而保留的 Jenkins 实例。
那三个位于内部的库，它们都做着相同的事情，但方式略有不同。
那些模块之所以存在，仅仅是因为你一年前进行过一次涉及它们的 A/B 测试，而该测试已经被回滚。等等。
是的，这就是技术债务，必须经济地管理。
有时候，忍受现状是有道理的，因为你的时间需要用在其他地方。
或者在清理这些东西上投入精力并没有明显的经济收益。
但我相信这会带来心理上的好处。
它可以带来成就感；它可以使代码库更愉快地使用；它可以减少挫折感。
长远来看，它可以让人们更快乐。
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
曾经出现过不少往 NPM “投毒”的事件，例如前阵子 rspack 的投毒事件，那么如何确保依赖的 NPM 包可信任呢？
reproduce 的方法是，从 package.json 中读取 repository 的配置，找到 repository 进行构建，比对构建后的产物和 NPM 上产物是否一致。
为了对 reproduce 进行测试，我们将其应用于前 5000 个“高影响”npm 包。
“高影响”包被认为是每周下载量超过 100 万或有超过 500 个依赖项的包。
其中，5.78% (289) 的软件包被发现是可重现的，这意味着它们可以在没有对其源代码库或发布工作流程进行任何更改的情况下，完全按照发布时的状态重新构建。
The Hierarchy of Hazard Controls
控制层级（Hierarchy of Controls，HoC）是工作场所安全中的一个重要概念。
HoC 主要是针对物理环境的，作者将其类比到软件工程中。
如果你的工作环境中没有相关规范制度避免一些生产安全问题（例如误操作生产数据库，操作生产环境没有权限控制等），这篇文章或许可以提供一些参考。
The Web Should Be A Conversation
如果你还拥有博客，开始写博客吧！拥有属于你的一方天地。
写啥都好，也许没人看，但自娱自乐也不错。
而且很多人都说，写作有助于你思绪的整理，何乐而不为呢。
文章也是鼓励大家写博客，用 RSS 订阅自己的信息流，脱离算法的控制。
作者还分享了一些写博客的平台和 RSS 工具。
Building Websites With LLMS
这里的 LLMS 指的是 (L)ots of (L)ittle ht(M)l page(S)，即多个小的 HTML 页面。
作者发现将博客的功能拆成多个 HTML 页面，配合 View Transition，比维护许多的 JS 逻辑要来得简单。
随着跨文档视图过渡获得越来越广泛的支持，我意识到构建页面内的渐进增强交互比简单地构建两个 HTML 页面并将它们链接起来要更费力。
我在心里称这种方法为“许多小的 HTML 页面”。
当我发现自己试图用 JavaScript 构建渐进增强的功能时——比如一个弹出导航菜单，或者页面内搜索，或者内容过滤——我停下来问自己：
“我能否将其构建为一个由链接触发的独立 HTML 页面，而不是从按钮构建的 JavaScript 注入内容？”
我有点喜欢这个结果。
我为每个我想要的“交互”构建单独的小 HTML 页面，然后让我使用 CSS 过渡效果，这样我得到的东西感觉比它的 JS 对应物更好，而且工作量少得多。
Basic Awareness in Addition to Deep Understanding
有的知识需要深度，需要精通它们。
有的知识只需要广度，大致知道有这样的东西，在需要的时候能提供一个方向就足够了，用到的时候在深入研究。
对软件开发人员的评估通常基于他们对特定理念和工具的理解程度。
掌握知识固然重要，但我发现自己还依赖于另一种知识：模糊的意识。
与精通不同的是，意识仅仅是知道某样东西的存在，以及对它是什么和它能解决什么问题的基本理解。
这也是我写博客的原因之一。
我发现，当我把事情写下来时，我就能更好地记住它们。
从这些错别字和拼写错误中你看不出来，但我会在发表博文前重读 3-4 遍。这种边写边读的方式有助于我保留信息。
这对未来的自己也是一个很好的参考。我不止一次利用博客来学习我曾经学得更好的东西。
我们向别人解释事情的方式就是我们希望别人向我们解释事情的方式 ，这可能是放之四海而皆准的真理。
人人都能写英文博客
英文博客似乎能得到更多的关注，作者使用 LLM 和 DeepL 将他写的文章翻译成英文，并在一些主流网站推广，得到了不错的反响，接触到了更多读者。
可以尝试一下！
The Day the Muse Died
作者的职业是一个执法人员，但是他喜欢绘画，也产生了一些成就。
但是后来他搬家后，周围的风景不是很吸引他，他发现自己对绘画不太感兴趣了。
反而，他开始对阅读和写作产生了浓烈的兴趣。
有时候，一些我们认为热爱的东西，或许会消逝，我们会对它们不再热情，但或许我们能找到别的兴趣。
也许你的创作灵感消失了。你认为自己会一直做的事情突然枯竭了。这种事是会发生的。
如果你幸运的话，某些东西会取代你曾经享受的创造激情。
我经常遇到告诉我他们不再追求或享受的过去激情的人。
通常是因为他们感到疲惫不堪，或者发现了更让他们兴奋的新事物。
如果你所做的事情消失了，你应该怎么办？
休息一下。有时候我们需要暂时离开，充电一下。
其他时候，在我们离开后，我们意识到我们准备好继续前进。
在这种情况下，问问自己还有什么其他的事情让你感兴趣或兴奋。
也许是你一直想学习的乐器。或者是你从未有机会尝试的运动。上课，尝试新的创意机会。
你可能会喜欢木工、烹饪、陶艺、舞蹈或钓鱼。
谁知道呢，除非你走出舒适区，去探索。
最重要的是，不要为了钱去做。
如果你需要更多收入，找一些你感兴趣的工作或你能忍受的工作。
但如果你试图把你的热情变成收入，你就有可能扼杀这种热情带来的快乐。
如果金钱来自你的热情，那很好。但不要把这作为目标。
…
总有一天，灵感可能会在你心中消逝。
你一直热爱的东西突然不再吸引你。
如果发生这种情况，不要惊慌。它可能会回来。
但无论它是否回来，尝试新的事物。
问问自己，最近什么真的让你感到兴奋。
一旦确定，试试看。
程序员的错误认知
Falsehoods programmers believe about languages
- …
- 每种语言都有表示“是”和“否”的词。
- 在每种语言中，表示“是”和“否”的词永远不会改变，无论它们回答的是哪个问题。
- 所有使用拉丁字母的语言都有相同的字母排序顺序。
- …
Falsehoods Programmers believe about names
- …
- 我这个系统永远都不需要处理来自中国的名字。
- 或者日本。
- 或者韩国。
- 或者爱尔兰，英国，美国，西班牙，墨西哥，巴西，秘鲁，俄罗斯，瑞典，博茨瓦纳，南非，特立尼达，海地，法国，或者克林贡帝国，因为这些国家都有好多奇奇怪怪的名字。
- 克林贡帝国那个是开玩笑的对吧？
- 人是在出生的时候被起名的。
- OK，不一定是出生那一刻，但是应该是出生前后没差多久。
- 好吧好吧，出生一年以内。
- 五年以内？
- 你 tmd 的在逗我对吧？
- 人有名字。
- …
Falsehoods programmers believe about time
- 一天总是有 24 小时。
- 二月总是 28 天长。
- 任何 24 小时的周期总是会在同一天（或同周，或同月）开始和结束。
- …
Git without a forge
Simon Tatham 是 PuTYY 的创建者和维护者，他不喜欢用 GitHub，GitLab 之类的托管平台。
文章里，他分享了几种向他提交 PR 的方法，同时表达了他为什么不想用 GitHub 等托管平台，最主要的原因是他不信任这些平台。
对我来说，决定在哪里托管我的代码的首要问题不是它能提供什么设施，而是谁来运行它。
我不希望我的代码受我不信任的人的摆布。
我并不是说我特别不信任负责主要 Git forge 网站的组织。
但我本人并不认识他们，而我更愿意信任我认识的人。
所以我的 Git 托管安排是在朋友的服务器上，而不是公司的服务器上。
另外，我不妨直截了当地说：我不想使用 Github 的一个原因是，它是最受欢迎的代码托管地。
任何事物的单一文化几乎都不健康，而由一家公司控制的单一文化尤其危险。
我宁愿为互联网的分布式发展做出贡献，也不愿意为它的集中式发展做出贡献。
In Defense of Text Labels
人脑处理图像比文字要快，icon 可以带来更快的认知效率，也能节省一些页面空间，也能让页面元素更多，没那么呆板。
但是 icon 也是存在问题的:
很少有图标能够立即传达清晰、单一的含义。
例如铅笔的图标，在不同上下文中，可能是编辑、新建、绘画。
界面中的图标越多，导航就越困难。
随着功能集的增长，我们常常不得不在图标之间 resort to 越来越抽象或微妙的视觉区分。
对于 5-7 个核心功能可能有效的方法，在 15-20 个功能时变得难以管理。
图标在更广泛的生态系统中作为特定于界面的语言。
应用可能会嵌套在别的环境中被使用，而别的环境可能也有 icon，甚至是相似的 icon，但表达的含义可能不同。
因此，作者认为不能仅靠 icon，文本也有它的用武之处：
单独使用文本通常更高效。
扫描文本，比扫描很多图标，再区分图标含义，往往来得更高效。
文本可以使图标更高效。
为图标添加文本标签有两个目的：一是澄清含义，二是提供更大的创作自由。
当图标的含义通过文本得到强化时，用户可以更快、更自信地浏览。
此外，当设计师不再仅依赖图标来传达功能时，他们可以更专注于界面视觉语言的统一性。
图标在文本密集型应用中是有效的锚点。
图标作为视觉标志，发挥着重要作用，帮助区分功能区域和内容区域。
特别是在文本密集型应用中，图标有助于吸引视线关注交互元素。
图标和文本标签的结合比单独使用任一元素更能清晰地传达功能。
每次我们在图标和文本标签之间做出选择时，我们是在选择认知负荷。
我们在决定人们在解读我们的界面上花费多少心理能量，而不是在使用它们。
虽然纯图标界面看起来简单且更具吸引力，但它往往会对注意力和理解造成一种无形的负担。
下次当你想要再创建一个图标，或者去掉文本标签时，请记住：最优雅的解决方案并不总是看起来简单的那个 ⸺ 而是让沟通和理解感觉简单的那个。
Truth, Lies and Progress Bars
作者是个设计师，在一个团队里，他发现团队实现的进度条其实是假的，和实际进度无关，只是为了避免用户提前关闭配置。
原因是因为要反馈实际进度很复杂，资源消耗也比较高。
我被告知这个特定操作很复杂，涉及许多不同的因素，这些因素可能因用户而异。
这使得提前预测变得具有挑战性，并且动态估算资源消耗也很高。
如果他们没有包含任何进度指示器，甚至没有像旋转器或不确定的“理发师杆”条那样的重复动画，用户可能会担心某个过程的某个方面已经停滞或崩溃。他们可能会不必要地取消操作。
决定使用虚构的进度条是一种必要的恶。
通过展示一定程度的前进势头，用户对操作按预期进行的信心增强，放弃设置过程的人也减少了。
但是作者对此不太满意，他给出了一些更好的实现。
Hallucinations in code are the least dangerous form of LLM mistakes
LLM 会出现幻觉，在编程的时候，可能会出现本来不存在的方法。
LLM 生成的代码需要实际去执行它，检验代码是否生效，这样才能避免一些编译器无法发现的问题。
你也需要去 review LLM 的代码，有时这会有不小的 review 压力，有时 LLM 重构的力度比较大，review 它的改动也需要不少的时间。
代码中的幻觉是你可以从模型中遇到的最无害的幻觉。
使用 LLMs 进行代码的真正风险在于，它们会犯一些不会被语言编译器或解释器立即捕获的错误。而且这些错误时常发生！
如果你在使用LLM编写代码而自己甚至没有运行它，你在做什么？
…
仅仅因为代码看起来不错并且运行没有错误，并不意味着它实际上在做正确的事情。
再仔细的代码审查——甚至全面的自动化测试——也无法明确证明代码确实做了正确的事情。
你必须自己运行它！
证明代码有效是你的工作。这是我认为LLMs不会让软件专业人士失业的众多原因之一。
避免这些问题的方法与您在审查其他人编写的代码或自己编写的代码时避免问题的方法相同：
您需要积极地执行该代码。您需要具备出色的手动质量保证技能。
编程的一条通用规则是，在亲眼看到某段代码运行之前，你绝不应该信任它——更好的是，亲眼看到它失败并修复它。
我不断看到人们说 “如果我必须审查每一行 LLM 写的代码，那我自己写会更快！”
那些人大声宣称他们在阅读、理解和审查他人编写的代码这一关键技能上投资不足。
我建议多加练习。审查由 LLMs 为你编写的代码是一个很好的方法。
减少幻觉，作者改了三个改进方向：
- 尝试不同的模型，有的模型在某些方面的表现更好。
- 学习如何使用上下文，给 LLM 提供足够的上下文。
- 选择无聊的技术，这些技术往往都存在了一段时间， LLM 的训练集中很可能包含这些“老旧”技术，LLM 能更好的使用它们。
With AI You Need to Think Much Bigger!
以前一些不太擅长的东西，在 LLM 的帮助下，现在也许可以做起来了。
虽然经常听到程序员可能会被 LLM 取代的论调，但是有了 LLM，也确实让程序员多了很多可能性。
这是一个最坏的时代，也是一个最好的时代 ;)
我现在正处于一个真正的僵局，职业生涯的末尾，知道我可以带着新的见解和更宏大的愿景快乐地重新开始一切。
这感觉就像在你去世前两周中了彩票。
我现在正在重新审视一些我曾经认为过于复杂或超出我能力范围的爱好项目，只要我能负担得起，就尝试一下。
活在这个时代真令人兴奋。
AI: Where in the Loop Should Humans Go?
这篇文章提出的问题挺值得深思的，强烈推荐看看原文。
我首先要说的是，我们目前没有人工通用智能（AGI）。
我不在乎我们是在 2 年、40 年还是永远都没有；如果我想部署一个应该在我的生产环境中执行任务的工具（或代理），它必须能够现在就做到。
我不是想要被打动，我想要让我的生活和系统变得更好。
另一个我希望你记住的机制是所谓的上下文差距。
简而言之，任何模型或自动化都是从对受控环境的狭窄定义构建的，随着其获得自主性而扩展，但仍然有限。
相比之下，系统中的人从广泛的情况开始，逐步缩小定义并添加约束，以使问题解决变得可行。
一方从狭窄的上下文开始，而另一方从广泛的上下文开始——因此在实践中，人与机器之间的合作类型是一个不断更新彼此的过程：
一个模型的最优解并不是一个问题的最优解，除非该模型是对问题的完美表述，而这在现实中从来都不是。
文章中提出的一些问题：
- 在工具被拿走后，你是否变得更好？
- 你是在增强人还是计算机？
- 它是在让你变成一个监视者，而不是帮助建立理解吗？
- 这是否限制了你可以查看的内容？
- 这是一种内置的干扰吗？
- 它融入了哪些视角？
- 它会成为英雄吗？(它变得不可或缺）
- 你需要它完美吗？
- 它是在完成整个工作还是其中的一部分？
- 如果我们有不止一个呢？
- 他们如何应对有限的上下文？
- 在停机或事件发生后，谁负责学习，谁负责修复？
总的来说，上述问题并没有明确说你不应该使用 AI，也没有说明人应该放在循环的哪个位置。
关键是你应该提出这个问题，并意识到仅仅将某些东西添加到你的系统中并不能替代工人。
相反，它会改变工作并创造新的模式和弱点。
这些模式中的一些是已知的并且经过充分研究。
我们不必急于通过失败重新发现它们，就好像我们是第一次自动化某些东西一样。
如果人工智能变得如此优秀和聪明，以至于超越了你所有的工程师，那么你在它变得优秀后才采用它也无所谓。
与此同时，这些事情确实很重要，并且会产生实际影响，因此请负责任地设计你的系统。
Tutorial | Resource
Block Breakers
本页面旨在教您关于分组密码的密码分析。
它并不假装是一个详尽的攻击列表，但会提供足够的信息让您入门。
课程分为几个部分，第一部分是关于 AES 的。
我们本可以设计一个简单的分组密码，但攻击真实的东西更有趣，你不觉得吗？
所以前往 Set 1 并开始实现 AES。
别担心，我们会陪着你 ;)
The Landscape of Lisp
文章整理了很多关于 Lisp 的资源。
Lisp 是一系列编程语言，拥有悠久、丰富且常常令人困惑的传统。
在 1960 年，约翰·麦卡锡（John McCarthy）发表了一篇论文，随后 64 年间产生了数千种方言和许多非常好的想法。
从外部视角来看，Lisp 家族的碎片化对新手来说可能显得非常混乱，就像一个软件的巴别塔。事实上，我认为 Lisp 的多样性是它最好的品质之一。
这篇文章的目的不是说服读者 Lisp 有多伟大；相反，我假设读者已经对其有一定兴趣，并且现在正在试图弄清楚这些方言中哪一种最适合他们。
这也不是关于“哪种 Lisp 最好”的问题，而只是我对使用广泛的 Lisp 方言的主观看法。
You suck at CSS
本书讲解 CSS 的编写。它也探讨如何避免编写 CSS。
它面向想要学习 CSS 的人，想要避免 CSS 的人，业余爱好者，专业人士以及所有介于两者之间的人。
该书旨在提供关于为什么 CSS 及其周围的设计生态系统是这样的背景信息。
它是为了支持 California Stylesheets CSS 框架而编写的。
它的核心是使用网络技术在前端快速完成任务，并专注于在团队中保持这种速度。
Code Related
Everything you need to know about Invoker Commands
Chrome 135 的新特性， command 和 commandfor ，可以用来方便地将 button 和 dialog，popover 关联起来。
see also: Introducing command and commandfor.
Using & Styling the Details Element
如何给 <details> 和 <summary> 设置样式。
The only way to detect touch with JavaScript
最近在想办法在同一个页面，区分是鼠标点击，还是触屏。
问了 LLM，给出的其实就是 Stack Overflow 上的答案，但并不好使。最终还是监听 Touch events 事件实现的。
如果你问 Stack Overflow “如何用 JavaScript 检测触摸”，你会得到很多答案，它们都有一个共同点：与人类无关。
在我并不谦虚的观点中，所有这些答案都是错误的，但这不是回答者的错。这是提问者的错。
你为什么会想知道你的用户是否在使用一个响应触摸的设备呢？
我们想要检测人类的触摸，而不是设备的触摸。我认为这足够重要，值得用大字体重复。
我们想要检测人类的触摸，而不是设备的触摸。
What is TypeScript? An overview for JavaScript programmers
从 JS 开发者角度看 TS。
Toe Dipping Into View Transitions
对于 view transition 的探究，不过我觉得文章写得一般，但是文章中引用的另外 2 篇文章不错：
我在博客里也实现了，现在你在首页中点击文章，然后返回，你会看到标题有一个过渡效果。
它的一个好处是，当你从一篇文章返回的时候，知道刚才看的是哪一篇 :P
CSS Kaleidoscopes
用 CSS 实现万花筒效果。
（作者的头像好像 undertale 里的 Papyrus。）
CSS Relative colors
CSS Relative colors 的使用教程，作者的代码示例做得相当好。
Cool Bit
Divided We Fall
<div>ided we fall, 通过游戏学习 HTML 和 CSS，有趣！画风也很可爱
I struggled with Git, so I'm making a game to spare others the pain
作者认为学习 Git 有点痛苦，所以他做了一个游戏帮助类似的人学习 Git。
第一个版本作者在 DOOM 里集成了 Git，你举着枪走进一个房间，上面贴着 git commit，进去之后看到的是 diff。
有点没绷住 _(:3 」∠ )_
后来他做成了类似 Minecraft 一样的游戏，挺酷的。
Michigan TypeScript Founder Successfully Runs Doom Inside TypeScript's Type System
在今年编程界可以说是最令人印象深刻的技术壮举之一，密歇根 TypeScript 的创始人 Dimitri Mitropoulos 完成了一项之前被认为不可能的事情：完全在 TypeScript 的类型系统内运行经典的 1993 年视频游戏 Doom。
Pierre
很酷炫的页面，就是有点废眼睛。
VT220 Font Emulation
一种终端复古字体的模拟。
A Map of Python
作者将 Python 生态的依赖包做成了一张地图， 像是宇宙中的一片星云。
BMW Historic Model Overview
宝马的一些历史车型。
freesound
Freesound 是一个拥有超过 50 万个声音样本的创意共享许可音频样本的协作库，且是一个非营利组织。
截至 2021 年 5 月，拥有超过 500,000 个声音和效果，以及 800 万注册用户（截至 2019 年 3 月）。
声音由用户上传到网站，涵盖从现场录音到合成声音的广泛主题。
sunshine pure css
纯 CSS 实现的小太阳。
It is as if you were on your phone
It is as if you were on your phone 是一款几乎是推测性的游戏，描绘了一个极其接近的未来，在这个未来中，我们都面临着同时需要一直使用手机和又不想一直使用手机的巨大压力。
我们的手指想要触摸屏幕，我们的眼睛想要注视表面，我们的大脑想要高效且始终被占用。
但喜欢照片、滑动个人资料、观看短视频以及我们一直在做的其他一切也让人感到疲惫。
It is as if you were on your phone提供了一种替代方案：假装在使用手机，以便看起来像人类，但实际上什么都不做。
跟随提示，获得自由。
Crossing the uncanny valley of conversational voice
Sesame 在实现一个 “对话伙伴”，具有和人接近的说话方式，可以和他们对话一下看看。
我们怎么知道某人是否真正理解我们？这很少仅仅是我们的言辞——而是在声音的细微之处：兴奋的上升，深思的停顿，温暖的安慰。
声音是我们人类最亲密的媒介，通过无数种音调、音高、节奏和情感的变化传递着多层含义。
今天的数字语音助手缺乏使其真正有用的基本特质。
如果无法充分发挥语音的潜力，它们就无法有效地与我们合作。
一个只用中性语调说话的个人助手在初始新鲜感消退后，很难在我们的日常生活中找到一个永久的位置。
随着时间的推移，这种情感的平淡不仅令人失望——它变得令人疲惫。
Scroll buddy
放一个帅小伙在你的滚动条上，增添一点乐趣。
One Logo, Three Companies (I)
日本三菱的 logo 被三家公司使用：
- 三菱商事集团 （尼康和麒麟啤酒也是它的一部份）
- 三菱铅笔株式会社
- The Golden Age of Japanese Pencils, 1952-1967 如果你对三菱铅笔感兴趣，也可以看看这篇文章。
- 三菱苹果酒
一个商标竟然可以被这么多公司用，真奇怪。
Tool | Library
random
可种子(Seedable)随机数生成器，支持多种常见分布。
相同的种子，可以生成相同的随机数序列。
fast-png
完全用 JavaScript 编写的 PNG 图像解码器和编码器。
wecat
用猫的混乱和人工智能驱动的测试挑战你的网络应用！
想象一下，您暂时离开电脑，去喝杯咖啡。
与此同时，您的猫走过您的键盘，并造成了一些混乱。
reveal.js
使用 HTML 或 Markdown 写 PPT。
reveal.js 是一个开源的 HTML 演示框架。
它是一个工具，使任何拥有网络浏览器的人都可以免费创建功能齐全且美观的演示文稿。
使用 reveal.js 制作的演示文稿是基于开放的网络技术。
这意味着您在网络上可以做的任何事情，都可以在您的演示文稿中实现。
使用 CSS 更改样式，使用 <iframe> 包含外部网页，或使用我们的 JavaScript API 添加您自己的自定义行为。
posting
一个运行在终端的 API 工具，界面看起来不错。
quaily
一个现代的、人工智能驱动的新闻通讯服务。
如果你需要一个 newsletters 服务，或许可以看看。
Mistral OCR
提供 OCR API，宣传的优点是:
- 对复杂文档的最先进理解
- 本地多语言和多模态
- 顶级基准
- 同类中最快
- 文档作为提示，结构化输出
- 可选择性地提供给处理高度敏感或机密信息的组织自托管
Emacs
一些话 | 摘抄
Should managers still code?
进行代码审查。不要只是浏览 PR，而是要真正深入其中：在本地运行分支，进行测试，批判性地思考设计和实现，并提供反馈。
目前我进行 review，还是以看 PR 为主，但比较少将分支拉下来，本地运行并测试需求功能。
有的问题或许是需要运行起来才能发现的，以后 review 改变一下。
The Ancient Art of Color
…色彩在古代世界是一种奢侈。
你可能不太会考虑生活中的颜色从何而来（我当然不会）。
你会选择一件红色衬衫或一条蓝色裤子，却不知道它们是怎么来的。
但在古代和中世纪世界，鲜艳的色彩往往是通过艰苦的努力和巨大的花费而获得的。
要想在家中或身上添上一抹亮色，需要付出一定的努力。
Avoid the nightmare bicycle
同样，产品设计中最糟糕的误解之一是，微波炉需要为你可能烹饪的每样东西都配备一个按钮：“爆米花”、“鸡肉”、“土豆”、“冷冻蔬菜”，等等等等。
真的不需要！只要有一个时间（和功率）按钮就可以了。人们会知道如何烹饪的。
好的设计揭示了系统的结构；它们依赖于用户理解这种结构并将其应用于新情况的能力。我们为此而生。
糟糕的设计用肤浅的标签来掩盖结构，从而隐藏了底层系统，阻碍了用户在头脑中建立清晰模型的能力。
The Differences between Deep Research, Deep Research, and Deep Research
“深度研究 (Deep Research) 是一个报告生成系统，它接受用户查询，使用大型语言模型（LLMs）作为代理，迭代搜索和分析信息，并生成详细的报告作为输出。”
Trusting AI with my images wasn't easy
AI 并不完美，但它可以非常有用。
人们担心幻觉和不准确性，我也有这样的担忧。
但在为 9,000 张图片生成 alt -text 之后，我看到了不同的东西：真实的、实用的价值。
它不仅让我的网站更易于访问；还挑战了我。
它让我明白，有时候，改善的最佳方式是退一步，让工具更好地完成工作。
50 things we’ve learned about building successful products
部分摘录
- 产品的成功是员工努力的结果。因为人才是会不断积累的，所以招聘的高标准至关重要。没有什么比一个不称职的员工更能拖累你了。
- 构建一个伟大的产品需要信任。缺乏信任往往是团队面临的最大瓶颈之一。这很可能是由于雇佣了一个水平不够高的人，或者未能给予该人反馈以帮助他们改进。
- 信任也是通过透明度建立的。在公开场合工作，进行公开讨论，并记录你正在做的事情。这为每个人提供了所需的背景信息，并消除了困扰许多公司的政治争斗。
- 依靠信任和反馈，而不是流程。这是我们的核心价值观之一。构建和扩展人们想要的东西是一个复杂的问题，因此我们让人们自行判断。当他们判断错误时，我们会直接给予反馈。
- “你无法验证一个想法。它并不存在，你必须去构建它。市场会验证它。”
- 计划是有用的，但死板地遵循计划并不是。良好的执行不应意味着执行一个特定的计划，而是反复做最重要的事情。评判人们的标准应是他们交付的成果、交付的频率以及他们工作的影响，而不是他们是否“遵循了计划”。
- 等待“再一周”再发布某个东西几乎总是个坏主意。这种态度如果延续几个月， 动力会大大减弱。越早将某个东西交到用户手中，越早你就能知道他们是否重视它，以及如何改进它。
- 减少你的进行中的工作。PR 应该在一天内完成，开始你的一天时先回应他人的审查请求，随时合并，使用功能标志发布，并在生产环境中测试。每一项都减少了完成工作所需的上下文量。
- 人为设定的截止日期不会让你的团队更快。它们往往导致一种恶性循环，造成大量的技术债务和疲惫。相反，消除那些拖慢团队的流程，给予小团队快速交付的自主权。
- 明确责任。这使得决定构建什么变得更加清晰和快速。回避责任的团队花费太多时间在规划、头脑风暴、会议和项目管理上，而他们本可以直接进行交付。
- 工程师能够决定构建什么。他们理解技术限制，能够识别功能之间的模式，并能够找出解决问题的方法。只是当涉及到用户需求时，他们可能会面临信息瓶颈。
- 产品经理应该通过分析产品分析数据、进行用户研究、进行竞争对手研究等方式，为产品团队创造背景，而不是控制工程师。
- 大多数人都不是史蒂夫·乔布斯。他们并不是一开始就“知道”该构建什么或拥有宏伟的愿景。相反，他们发布产品，将其交到用户手中，基于反馈进行迭代，然后再重复这个过程。你做得越快，你的产品就会越好。
- 在所有你可能构建的东西中，支持请求是最“真实”的之一。一个特定的用户有一个特定的问题。当你解决它时，你就改善了你的产品，其他的变化无法做到这一点。
- 使用自己的产品，也称为“吃自己的狗粮”，可以帮助你更快地交付产品，在问题到达用户之前拦截它们，深入理解你的产品，并培养对用户的同理心。不过，这并不能替代与用户交谈、获取真实的反馈和跟踪实际使用指标。
- 优秀的产品构建者总是在原型设计和实验。这意味着他们需要能够舒适地构建最小可行产品（MVP）和概念验证，发布未打磨的作品，获取反馈，并在事情不顺利时进行调整。这也意味着具备从零到构建所需的所有技能，包括基础设施到设计的各个方面。
- 失败并不是产品实验的世界末日。在谷歌，80-90%的实验“失败”。你可能会认为这是一种时间浪费，但在大规模的情况下，10%的成功可以弥补所有的失败。例如，Bing 展示标题的 A/B 测试使收入增长了 12%（当时超过 1 亿美元）。
- “如果你对自己正在做的事情没有激情，那就转变方向。就是这么简单。如果你在做一些感觉属于你的事情，你会取得更多成就。”
用 AI 创建高品质网站
个人觉得， 最先失业的就是低级前端工程师， 有审美的产品经理和高级前端工程师不会失业。
50 years in filesystems: 1984
进步有时很难察觉，尤其是当你参与其中或经历过时。
通常，如果你将现代教育材料和讨论的问题与旧材料进行比较，就更容易看到进步。
文章是关于文件系统的历史和分析其设计的，感兴趣可以看看。
The Best "Hello World" in Web Development
用 PHP 写一个 Hello World 网页是相当简单的，什么都不需要配置。
相反，有的框架，上来需要一系列步骤，安装很多的依赖，让初学者望而止步。
软化学习曲线意味着让常见的事物变得简单，并且在你需要它们之前不要引入太多概念。初学者和专家都能从中受益。
🔭 The Einstein AI model
人们通常犯的主要错误是认为牛顿或爱因斯坦只是优秀学生的放大版，天才的出现是通过线性外推一个前 10% 的学生。
这种观点忽视了科学中最关键的方面： 提出正确问题的能力，以及挑战自己所学知识的能力。
真正的科学突破是哥白尼提出的，尽管他所处时代的所有知识 ⸺ 用机器学习的术语来说，我们会说“尽管他的训练数据集” ⸺ 地球可能围绕太阳转，而不是相反。
要在数据中心创造一个爱因斯坦，我们不仅需要一个知道所有答案的系统，更需要一个能够提出别人从未想到或敢于提出的问题的系统。
一个在所有教科书、专家和常识都建议相反时，能够写下“如果每个人都错了呢？”的系统。
真正的科学突破将不是来自回答已知问题，而是来自提出具有挑战性的新问题以及质疑常见观念和以往想法。
多媒体
- 首次亮相，能打电话的国产“相机” (13:40) 小米的概念机，通过磁吸外接镜头，很大地提高了成像。
- R&B 会一直有人唱,成都会一直阴天丨施鑫文月x地磁卡双打歌丨HOPICO (24:04)
- 搞了一个世界上最小的V8发动机！声音简直了…… (04:50)
- 心上人请从早到晚都和我说甜蜜话吧 (02:14) up 做的电动牙刷广告，但音乐和画面都挺好的。男主的造型像是蜡笔小新里的爸爸。
Music
方大同
这周大部份的时间都在听方大同，把他大部份专辑都翻出来听了一遍，都很不错。
这么认真，真诚，音乐做得如此好听的人这么早就离世了，太让人可惜了。
- 认识你 (hidden track) 歌曲的开头还有一点点剧情
- 黑洞里 在 15 Live in HK 里大同说到，这是一个外星人用来哄地球女孩的歌，希望她能跟他去他的星球
每个人都会 (song for Cartier [Love Project])
什麽比 love love love love love 更美
爱让人安心在梦中熟睡
Oh love love love love love 最美
美在每一个人都会
-
音乐没人懂打赏要人懂
因为他真的很穷
漆黑北风中飘渺的烛光中
他想他总能为人们奏出彩虹
音乐自己懂一样有听众
沿途点亮他命运的灯笼
二泉映月他才不管红与不红
写博客也是，有没有人懂有什么关系呢，自己就是自己的读者，管他红不红。
-
浪漫温柔的一首歌。原曲是 Eric Clapton 的 Wonderful Tonight。
在《老友记》里，还有一段和这首歌的对话：
钱德勒：“我以为，求婚的地点，内容很重要，到后来我意识到，唯一重要的只有你，是你让我得到了超乎想象的幸福。如果你愿意，我希望可以尽我余生之力，使你幸福如我。你愿意嫁给我吗？”
莫妮卡：“我愿意。”
-
没有天时与地利
只有生活的压力
就算再多的话题
见不着你 前事不提