docs: update markdown files (2025-12-22 08:37:46)

1 files changed, 0 insertions, 193 deletions

diff --git a/content/_drafts/60.md b/content/_drafts/60.md
deleted file mode 100644
index 96a6e381..00000000
--- a/content/_drafts/60.md
+++ /dev/null
@@ -1,193 +0,0 @@
----
-title: 稻草人周刊 Vol.60
-subtitle: 我加入了 Fediverse 和 IndieWeb
-tags:
-  - Geek
-  - 设计
-  - 软件
-  - 开源
-  - 语言
-  - 文化
-  - Web
-date: 2025-12-21T23:45:00
-categories: 稻草人周刊
-draft: true
-toc: true
----
-
-{{< music cover="https://image.guhub.cn/uPic/2025/12/coffee-cantata.webp" title="咖啡康塔塔" artist="巴赫" apple="https://music.apple.com/cn/album/bach-coffee-cantata/1452223774" >}}
-
-康塔塔（Cantata）是一种古典乐形式，也叫做「清唱套曲」，是一种包含独唱、重唱、合唱的声乐作品，一般包含多个乐章，大多有管弦乐伴奏。[^1]咖啡康塔塔[^2]由巴赫在 1732 到 1735 年创作的作品，尽管叫做康塔塔，但其实更像是短小的歌剧，而且偏喜剧。
-
-故事的内容是一位父亲想要改掉女儿每天喝咖啡的*恶习*，威胁她要是不停止喝咖啡，就不准她参加派对、不准上街、没有新裙子穿，女儿说要是能喝咖啡，怎么样都行。最终父亲忍无可忍，说要是不戒掉咖啡，就不给女儿找男人，女儿说要是能找到一个健硕的爱人，自己就不会喝咖啡——最后，女儿偷偷地传播消息：要是不在婚约上写自己可以想什么时候喝咖啡就什么时候喝，自己就不会嫁给他。
-
-我真的很喜欢这段歌词，我想我会背诵下来的 😋
-
-> *If I couldn't, three times a day, be allowed to drink my little cup of coffee, in my anguish I will turn into a shriveled-up roast goat.* <br/>
-> 如果我每天不能美美喝上三次咖啡，我就会痛苦得像一只被炙烤的山羊。
-> 
-> *Ah! How sweet coffee tastes, more delicious than a thousand kisses, milder than muscatel wine.* <br/>
-> 啊！咖啡尝起来多甜美！比一千个情人的吻还美味，比麝香葡萄酒更温柔！
->
->*Coffee, I have to have coffee, and, if someone wants to pamper me, ah, then fill up my coffee again!* <br/>
-> 咖啡啊咖啡，我一定要喝，如果有人要款待我，就请满上我的咖啡杯！[^3]
-
-<!--more-->
-
-## ⋈︎ · 连接
-
-### 怎么哪里都有菜单图标？
-
-> [!note] 📜
-> [Icons in Menus Everywhere — Send Help - Jim's Blog](https://blog.jim-nielsen.com/2025/icons-in-menus/)
-
-作者抱怨了 macOS Tahoe 在菜单栏里加图标的新设计，他一直认为菜单栏里的图标是一种视觉噪音，看起来很乱，而且可能造成误解。许多产品（比如 Google Sheets）都采用了这种设计，而随着 macOS Tahoe 发布，Apple 也加入了「硬往菜单里塞图标」的大军，他感到很沮丧。
-
-作者认为用于移动窗口、管理窗口布局的图标，用图形来指示位置是很直观的，是好的设计，然而，如果没有好的理由，就不应该往菜单里塞图标。讽刺的是，Apple 实际上违背了他们自己的[设计指导](https://web.archive.org/web/20201027235952/https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/)，相关的文档中有一节专门讨论图标在菜单中的使用。
-
-> There are a few standard symbols you can use to indicate additional information in menus…Don’t use other, arbitrary symbols in menus, because they add visual clutter and may confuse people.
-> 
-> 有一些标准的符号可以用在菜单中指示附加信息。不要在菜单中随意使用其他的符号，因为它们可能会造成视觉杂乱、使人困惑。
-
-我也不喜欢菜单里硬塞图标的设计（还有在 PPT 里塞语义模糊、与上下文无关的图标），我认为这种设计本质上是缺少思考的体现，没有考虑设计是否必要，只是想要把空间占满，明明**有些空白就应该留着**。
-
-### 开发者应该如何命名工具？
-
-> [!note] 📜
-> [Programmers and software developers lost the plot on naming their tools](https://larr.net/p/namings.html)
-
-作者观察到了一种现象：如今的软件开发者非常喜欢用动物、虚构角色和一些意义不明的名词来命名自己的软件，像 Cobra、Viper 和 Melody，使得整个软件生态变得像是动物园，最大的问题是，这让那些排查依赖问题的开发者很头疼，看着长长的依赖树却根本不知道每个依赖是用来做什么的。作者指出，其他科学领域里不会把这种命名方式视作专业行为——如果一个化学家把一个分子命名为 Steve，仅仅因为 Steve 这个名字很好笑，而且会让他的论文更接地气，这无异于社会性自杀。
-
-作者指出，以前的软件名称都有表意作用，比如早期的编程语言名字：
-
-- FORTRAN（Formula Translation）
-- COBOL（Common Business-Oriented Language）
-- Lisp（List Processing）
-
-还有早期的 Emacs 编辑器里的一些名字，dired 是 Directory Editor（目录编辑器）、eshell 是 Emacs Shell；一些命令也是如此，比如 grep 是 Global Regular Expression Print（全局正则表达式打印），sed 是 Stream Editor（流编辑器），cat 是 Concatenate（串联）。
-
-作者认为动物园式的命名方式会造成认知债务（cognitive tax），使开发者不得不花更多的时间来理解工具的名字。他认为软件开发者应该使用复合词，根据用途来命名软件，至于宣传和接地气的部分，完全可以单独做一个吉祥物，比如 PostgreSQL 的吉祥物是一只名叫 Slonik 的大象——不要把软件的名字当成吉祥物。
-
----
-
-我其实不能**完全**认同作者的观点。实话实说，在读这篇文章之前，我完全不知道 grep 的全名是「全局正则表达式打印」而 Emacs 里的 dired 是目录编辑器——这几个东西我都用过，`grep` 还是我最常用的命令之一，然而，它们的名字对我而言，和 Cobra、Viper 之类的没有太多区别。作者可能忽略了，许多人（尤其是非英语母语者）并不在乎一个工具的全名是什么，只要把用途和名字匹配起来就好了——所有程序员都会写 SQL，但除了学校里的老师可能会在 PPT 上写「SQL 的全名是 Structured Query Language，结构化查询语言」之外，还有多少人在乎呢？像 MySQL 和 PostgreSQL 这样的数据库管理系统，明明不是一种 DSL 或者 SQL 的变体，却还是使用了 SQL 的名字，这个词已经变成广义上的关系型数据库的代称了。
-
-更别提 FORTRAN、COBOL 和 Lisp 了，如果不是真心对这几门语言感兴趣的黑客，谁能一眼看出来他们表示什么意思？作者所提到的认知债务，在这些「具有描述性」的名字中**依然存在**。此外，我也不太能明白为什么作者认为 Go 语言是一个有点蠢的名字，难道必须起一个像 `http-request-validator` 一样的名字，才能算好吗？那同类软件之间要如何做出区分呢？
-
-不过，我也要承认，随便拿一个几乎毫无关联的名词做软件的名字，的确不太妥当，但我认为不妥当的点在于自我意识过剩和对作品以及用户不负责，而不是「名称不具有描述性」这个理由。比如，一个开发者很喜欢宝可梦，便把自己开发的一个系统清理工具命名为 Squirtle（杰尼龟），就不太妥当了，因为名称与工具之间几乎没有任何关联，或者说脑回路过于奇特，其他人难以建立起关联。但是，如果把一个用于将网盘挂载（mount）到文件系统中的软件命名为 Pokémount，我认为这不失为在个性和描述性之间的一种平衡（只不过这个例子可能会有版权问题，但我觉得我表达清楚我的观点了）。
-
-作者在文中提到了一个名为 `libsodium` 的加密库，说自己看到这个名字的时候必须从「解决问题模式」切换到「一探究竟模式」，才能搞清楚这个库为什么叫这个名字——加密往往涉及到「加盐」，而名字中的 Sodium（钠）明显代指「盐」，这个名字实际上还是具有描述性的。我想说的是，开发者完全可以更专注，在解决问题的时候**收一收自己的好奇心**，就像我在用 `grep` 筛选查看返回信息的时候，只会专注找我想要的内容，而不是纠结 `grep` 这四个字母究竟是什么意思。
-
-### 中文的「不错」和英文的「好」
-
-> [!note] 📜
-> [The Architecture of "Not Bad": Decoding the Chinese Source Code of the Void](https://suggger.substack.com/p/the-architecture-of-not-bad-decoding)
-
-作者表示自己作为中文母语者，更喜欢用双重否定表达肯定，比如「不错」「没事」「没错」，而他观察到英文使用者更偏好直接肯定，比如「Decent」「Okay」「Right」。他认为中文使用者更偏好使用双重否定，其实是一种留白，刻意留下了一定的模糊性以避免直接承担表达的责任，设立了一种心理屏障。例如，A 在选购某种商品时寻求了 B 的建议，如果 B 说「我觉得很好」，而 A 买下之后却遇到了各种不如意，那 B 就有可能承担 A 的选择带来的后果；如果 B 说「还行吧，不坏」，没有得到直接肯定答复的 A 需要承担全部的选择带来的责任。作者认为两种语言实际上构建了两种不同的现实模型（realities）。
-
-毋庸置疑，语言会影响思维方式，不过我并不赞同这种过于简单粗暴的二分法，实际上「Not bad」这个说法也很常见，甚至比中文里还要常见，因为中国人在相似场景下可能更喜欢说「还行」——一个语气更弱的直接肯定，而不是双重否定。
-
-作者似乎也没有意识到，世界上说英语的人很多，全世界都有英语使用者，而作者提到的偏好肯定的、简单直白的英语，更像是美国人说的英语。文章下有一条评论是这样说的：
-
-> 我只是过来说一句下面已经有人说过的话：你显然没有和某一类英格兰人打过交道。
-> 
-> 美国人是喜欢玩火柴和刀片的小孩子。
-
-<details>
-	<summary>原文</summary>
-
-> Came here to say what someone else has already said below: you've obviously had little to do with a certain sort of Englishman.
-> 
-> Americans are children playing with matches and razor blades.
-
-</details>
-
-不过，作者的确在自己的认知范围内做出了足够多的分析，文章写得也足够条理清晰，读起来很有意思。只不过，这篇文章收到的一些批评也提醒我：不要陷入太过简单的二元对立陷阱中，真实情况往往更复杂；分析现象时最好要找到足够多的依据，对于这类文化问题，最好找一些英语使用者和中文使用者来讨论，或者请他们读一读文章草稿。
-
-## ⁂ · 星群
-
-### Atomic CSS Devtools
-
-用于测试和 Debug 原子化 CSS 的工具，支持 TailwindCSS、UnoCSS、PandaCSS 等其他原子化 CSS 库。刚发现的时候还觉得用处不大，因为原子 CSS 的类名本身就很清晰了，但发现这个工具的同一天，我就遇到了一个奇怪的 UnoCSS 导致的问题——有一个类只有变量，但没有实际发挥作用的属性。如果没有这个 Atomic CSS Devtools，我可能要在 Styles 标签页翻找好久才能发现。
-
-这个插件在前端开发者工具中添加了一个 Atomic CSS 标签页，会把选中元素的样式全部列出来，在右侧显示是哪个类提供了这个样式。
-
-![](https://image.guhub.cn/uPic/2025/12/UnN7eL.png)
-
-访问：[GitHub - astahmer/atomic-css-devtools](https://github.com/astahmer/atomic-css-devtools)
-
-### Wails
-
-一个跨平台的桌面端应用开发框架，后端使用 Go 语言，UI 可以使用任何前端技术构建。和 [Tauri](https://tauri.app/) 一样，Wails 不会把浏览器内核打包到最终的软件包里，而是使用系统默认 WebView，软件包的大小会比 Electron 小很多。
-
-Tauri 使用 Rust 语言，而 Wails 使用 Go 语言，两者在前端技术上都没有限制。除了 Tauri 出现的时间比较早，生态可能更成熟之外，我认为两者都是不错的跨平台开发选择——不过相比 Electron，这两个框架在生态上都没有太大优势。
-
-访问：[Wails](https://wails.io/)
-### MrRSS
-
-一个比较新的跨平台 RSS 阅读器，用 Wails 开发。我并没有觉得 MrRSS 的设计有多惊艳，但我对它使用的技术栈很有好感，使用的是 Go 语言和 Vue.js（~~如果用的是 Node.js 和 React 我大概会直接晕过去~~）。作者正在积极开发，如果你在选择新的 RSS 阅读器，MrRSS 可能是一个不错的选择。
-
-访问：[GitHub - WCY-dt/MrRSS](https://github.com/WCY-dt/MrRSS)
-
-## ↯ · 当下
-
-### 我加入了 Fediverse
-
-Fediverse（联邦宇宙）是去中心化的社交网络，所有使用相同协议的实例能够相互通信，使得用户可以在一个服务器上查看整个 Fediverse 中架设于其他服务器上的社交媒体实例上的内容。最常用的协议是 ActivityPub，支持这个协议的软件有 Mastodon 和 Misskey 等微博（Microblogging）平台，像 Ghost 这样的内容管理平台也有支持 ActivityPub 的，也属于联邦宇宙的一部分。
-
-相比 Twitter（我不想用 X 这个名字）和 Instagram 这类由某个科技公司提供的社交媒体，Fediverse 更自由，用户可以选择在自己信任的服务器上注册账号（或者自己架设服务器），只需要电子邮箱就能注册，只要在任何一个支持 ActivityPub 协议的服务器上拥有账号，就能在整个 Fediverse 上和其他人交流，而且，在这里没有人想要给你推荐广告、收集和售卖你的数据。
-
-我刚开始探索 Fediverse，所以选择了在一个公共实例上注册，未来兴许会自建实例。[@eltrac@c7.io](https://c7.io/@eltrac) 是我的 Mastodon 账号，期待能和你在联邦宇宙上相遇。
-
-### 我加入了 IndieWeb
-
-[indieweb.org](https://indieweb.org/) 是这样介绍自己的：
-
-> IndieWeb 是专注于人的网络，用于替代「大公司网络」。
-> 
-> 我们是由独立的个人网站组成的社群，基于这样的原则：拥有你自己的域名，把域名用作你最主要的线上身份，在你自己的网站上优先发表内容（发在其他地方是可选的），并且拥有你的内容。
-
-<details>
-	<summary>原文</summary>
-
-> The IndieWeb is a people-focused alternative to the “corporate web”.
-> 
-> We are a community of independent and personal websites based on the principles of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.
-
-</details>
-
-之前一直很喜欢 IndieWeb 的概念，但没有深入了解。其实加入 IndieWeb 也很简单，最主要的步骤就是拥有自己的域名和网站，优先在网站上发表内容，之后再同步到其他地方，这件事情我已经在做了。要说别的什么东西，大概就是设置一下 Microformats、配置 IndieAuth 和支持 Webmention。
-
-Microformats 是基于 HTML 的一种标记内容和身份的格式，主要用来帮助自动化工具展示作者信息和内容信息，详情可查阅 [IndieWeb Wiki](https://indieweb.org/microformats)。
-
-至于 IndieAuth，就是给链接加上 `rel="me"` 属性以声明链接到的个人资料的确属于自己，这个链接可以是 `<link>` 也可以是 `<a>`，以下是我的写法：
-
-```html
-<link rel="me" href="https://c7.io/@eltrac">
-<link rel="me" href="https://github.com/BigCoke233" />
-<link rel="me" href="mailto:hi@guhub.cn" />
-```
-
-确保网站上有 `rel="me"` 的内容之后，还需要在以上链接中链接到自己的网站，比如在 GitHub 个人资料中设置个人主页链接。许多 IndieWeb 相关的服务，比如 [webmention.io](https://webmention.io/)，支持 Web Sign-In，只要提前配置好了 IndieAuth，就可以通过自己指定的 GitHub 账号或电子邮箱等方式，以域名拥有者的身份登录。
-
-如果你拉到网页最下方，会发现博客的评论按钮旁边多了一个图标为 `@` 的按钮，这就是 Webmention，一个 W3C 标准。你可以以发送 HTTP 请求的方式向支持 Webmention 的网站发送回复、点赞、提及等回应，自己也可以作为接收方接收这种回应，展示在网页上。只要配置得当，在自己的网站中插入链接就能像在社交媒体上用 `@用户名` 的形式提及其他用户一样给其他人发送通知，不过要完全自动化还是有些麻烦的。
-
-我使用 [webmention.io](https://webmention.io/) 提供的服务来接收 Webmention，在 `<head>` 中添加了以下代码来声明我的 Webmention 端口。
-
-```html
-<link rel="webmention" href="https://webmention.io/www.geedea.pro/webmention" />
-```
-
-向这个端口发送 Webmention，就会展示在我的网站上。你可以点开博客下方的 Webmention 按钮，查看这一页收到的 Webmention，也可以通过表单提交你的网址以手动发送 Webmention，不过发送 Webmention 的前提是你提交的网址中有链接到这个页面，比如在文章中插入超链接。[^4]
-
-我目前还没有配置自动发送 Webmention，用静态网站生成器还是不太方便做自动化，要自己配置 GitHub Actions，兴许有空了我会尝试一下。
-
-在发布周刊之前我就收到了两个 Mentions，有些惊喜，如果你不喜欢发评论，或者没有 GitHub 账号，可以在自己的网站上撰写一篇文章回应我，又或者只是在写文的时候简单提及，无论怎样我都会很开心的。
-
-[^1]: 参见：[康塔塔 - 维基百科](https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A1%94%E5%A1%94)
-
-[^2]: 原名：Schweigt stille, plaudert nicht (Be still, stop chattering), BWV 211，也叫 Coffee Cantata
-
-[^3]: 歌词来源：[EMMANUEL MUSIC](https://www.emmanuelmusic.org/bach-translations/bwv-211)
-
-[^4]: 经过测试，我发现在社交媒体上发布链接并提交 Webmention 并不能成功推送通知，因为发送 Webmention 的前提是源链接（也就是你提交的链接）指向的网页中，有链接到目标链接（也就是你要发送 Webmention 的网页）的超链接。社交媒体的内容一般是通过 JavaScript 动态展示的，HTML 中没有内容，所以也就检测不到链接。