diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/_drafts/60.md | 88 |
1 files changed, 72 insertions, 16 deletions
diff --git a/content/_drafts/60.md b/content/_drafts/60.md index a6688dc8..96a6e381 100644 --- a/content/_drafts/60.md +++ b/content/_drafts/60.md @@ -1,20 +1,42 @@ --- title: 稻草人周刊 Vol.60 -subtitle: +subtitle: 我加入了 Fediverse 和 IndieWeb tags: -date: 2025-12-16T11:11:00 + - Geek + - 设计 + - 软件 + - 开源 + - 语言 + - 文化 + - Web +date: 2025-12-21T23:45:00 categories: 稻草人周刊 draft: true toc: true --- -{{< music cover="" title="" artist="" apple="" spotify="" netease="" >}} +{{< 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/) @@ -27,7 +49,7 @@ toc: true > > 有一些标准的符号可以用在菜单中指示附加信息。不要在菜单中随意使用其他的符号，因为它们可能会造成视觉杂乱、使人困惑。 -我也不喜欢菜单里硬塞图标的设计（还有在 PPT 里塞语义模糊、与上下文无关的图标），我认为这种设计本质上是缺少思考的体现，没有考虑设计是否必要，只是想要把空间占满——有些空白就应该留着。 +我也不喜欢菜单里硬塞图标的设计（还有在 PPT 里塞语义模糊、与上下文无关的图标），我认为这种设计本质上是缺少思考的体现，没有考虑设计是否必要，只是想要把空间占满，明明**有些空白就应该留着**。 ### 开发者应该如何命名工具？ @@ -44,17 +66,43 @@ toc: true 还有早期的 Emacs 编辑器里的一些名字，dired 是 Directory Editor（目录编辑器）、eshell 是 Emacs Shell；一些命令也是如此，比如 grep 是 Global Regular Expression Print（全局正则表达式打印），sed 是 Stream Editor（流编辑器），cat 是 Concatenate（串联）。 -作者认为这种命名方式造成认知债务（cognitive tax），使开发者不得不花更多的时间来理解工具的名字。他认为软件开发者应该使用复合词，根据用途来命名软件，至于宣传和接地气的部分，完全可以单独做一个吉祥物，比如 PostgreSQL 的吉祥物是一只名叫 Slonik 的大象——不要把软件的名字当成吉祥物。 +作者认为动物园式的命名方式会造成认知债务（cognitive tax），使开发者不得不花更多的时间来理解工具的名字。他认为软件开发者应该使用复合词，根据用途来命名软件，至于宣传和接地气的部分，完全可以单独做一个吉祥物，比如 PostgreSQL 的吉祥物是一只名叫 Slonik 的大象——不要把软件的名字当成吉祥物。 --- -我其实不能完全认同作者的观点。实话实说，在读这篇文章之前，我完全不知道 grep 的全名是「全局正则表达式打印」而 Emacs 里的 dired 是目录编辑器——这几个东西我都用过，`grep` 还是我最常用的命令之一，然而，它们的名字对我而言，和 Cobra、Viper 之类的没有太多区别。作者可能忽略了，许多人（尤其是非英语母语者）并不在乎一个工具的全名是什么，只要把用途和名字匹配起来就好了——所有程序员都会写 SQL，但除了学校里的老师可能会在 PPT 上写「SQL 的全名是 Structured Query Language，结构化查询语言」之外，还有多少人在乎呢？像 MySQL 和 PostgreSQL 这样的数据库管理系统，明明不是一种 DSL 或者 SQL 的变体，却还是使用了 SQL 的名字，这个词已经变成广义上的关系型数据库的代称了。 +我其实不能**完全**认同作者的观点。实话实说，在读这篇文章之前，我完全不知道 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，我认为这不失为在个性和描述性之间的一种平衡。 +不过，我也要承认，随便拿一个几乎毫无关联的名词做软件的名字，的确不太妥当，但我认为不妥当的点在于自我意识过剩和对作品以及用户不负责，而不是「名称不具有描述性」这个理由。比如，一个开发者很喜欢宝可梦，便把自己开发的一个系统清理工具命名为 Squirtle（杰尼龟），就不太妥当了，因为名称与工具之间几乎没有任何关联，或者说脑回路过于奇特，其他人难以建立起关联。但是，如果把一个用于将网盘挂载（mount）到文件系统中的软件命名为 Pokémount，我认为这不失为在个性和描述性之间的一种平衡（只不过这个例子可能会有版权问题，但我觉得我表达清楚我的观点了）。 + +作者在文中提到了一个名为 `libsodium` 的加密库，说自己看到这个名字的时候必须从「解决问题模式」切换到「一探究竟模式」，才能搞清楚这个库为什么叫这个名字——加密往往涉及到「加盐」，而名字中的 Sodium（钠）明显代指「盐」，这个名字实际上还是具有描述性的。我想说的是，开发者完全可以更专注，在解决问题的时候**收一收自己的好奇心**，就像我在用 `grep` 筛选查看返回信息的时候，只会专注找我想要的内容，而不是纠结 `grep` 这四个字母究竟是什么意思。 + +### 中文的「不错」和英文的「好」 -作者在文章提到了一个名为 `libsodium` 的加密库，说自己看到这个名字的时候必须从「解决问题模式」切换到「一探究竟模式」，才能搞清楚这个库为什么叫这个名字——加密往往涉及到「加盐」，而名字中的 Sodium（钠）明显代指「盐」，这个名字实际上还是具有描述性的。我想说的是，开发者完全可以更专注，在解决问题的时候收一收自己的好奇心，就像我在用 `grep` 查看 HTTP 返回信息的时候，只会专注找我想要的内容，而不是纠结 `grep` 里的 g 到底是什么意思。 +> [!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> + +不过，作者的确在自己的认知范围内做出了足够多的分析，文章写得也足够条理清晰，读起来很有意思。只不过，这篇文章收到的一些批评也提醒我：不要陷入太过简单的二元对立陷阱中，真实情况往往更复杂；分析现象时最好要找到足够多的依据，对于这类文化问题，最好找一些英语使用者和中文使用者来讨论，或者请他们读一读文章草稿。 ## ⁂ · 星群 @@ -72,24 +120,22 @@ toc: true 一个跨平台的桌面端应用开发框架，后端使用 Go 语言，UI 可以使用任何前端技术构建。和 [Tauri](https://tauri.app/) 一样，Wails 不会把浏览器内核打包到最终的软件包里，而是使用系统默认 WebView，软件包的大小会比 Electron 小很多。 -Tauri 使用 Rust 语言，而 Wails 使用 Go 语言，两者在前端技术上都没有限制。除了 Tauri 出现的时间比较早，生态可能更成熟之外，我认为两者都是不错的跨平台开发选择。 +Tauri 使用 Rust 语言，而 Wails 使用 Go 语言，两者在前端技术上都没有限制。除了 Tauri 出现的时间比较早，生态可能更成熟之外，我认为两者都是不错的跨平台开发选择——不过相比 Electron，这两个框架在生态上都没有太大优势。 访问：[Wails](https://wails.io/) ### MrRSS -一个比较新的跨平台 RSS 阅读器，用 Wails 开发。我并没有觉得 MrRSS 的设计有多惊艳，但我对它使用的技术栈很有好感，使用的是 Go 语言和 Vue.js（~~如果用的是 JavaScript 和 React 我大概会直接晕过去~~）。作者正在积极开发，如果你在选择新的 RSS 阅读器，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 上和其他人交流，而且，在这里没有人想要给你推荐广告、收集和售卖你的数据。 +相比 Twitter（我不想用 X 这个名字）和 Instagram 这类由某个科技公司提供的社交媒体，Fediverse 更自由，用户可以选择在自己信任的服务器上注册账号（或者自己架设服务器），只需要电子邮箱就能注册，只要在任何一个支持 ActivityPub 协议的服务器上拥有账号，就能在整个 Fediverse 上和其他人交流，而且，在这里没有人想要给你推荐广告、收集和售卖你的数据。 我刚开始探索 Fediverse，所以选择了在一个公共实例上注册，未来兴许会自建实例。[@eltrac@c7.io](https://c7.io/@eltrac) 是我的 Mastodon 账号，期待能和你在联邦宇宙上相遇。 @@ -124,7 +170,7 @@ Microformats 是基于 HTML 的一种标记内容和身份的格式，主要用 确保网站上有 `rel="me"` 的内容之后，还需要在以上链接中链接到自己的网站，比如在 GitHub 个人资料中设置个人主页链接。许多 IndieWeb 相关的服务，比如 [webmention.io](https://webmention.io/)，支持 Web Sign-In，只要提前配置好了 IndieAuth，就可以通过自己指定的 GitHub 账号或电子邮箱等方式，以域名拥有者的身份登录。 -如果你拉到网页最下方，会发现评论按钮旁边多了一个图标为 `@` 的按钮，这就是 Webmention，一个 W3C 标准，你可以以发送 HTTP 请求的方式向支持 Webmention 的网站发送回复、点赞、提及等回应，自己也可以作为接收方接收这种回应，展示在网页上。只要配置得当，在自己的网站中插入链接就能像在社交媒体上用 `@用户名` 的形式提及其他用户一样，不过要完全自动化还是有些麻烦的。 +如果你拉到网页最下方，会发现博客的评论按钮旁边多了一个图标为 `@` 的按钮，这就是 Webmention，一个 W3C 标准。你可以以发送 HTTP 请求的方式向支持 Webmention 的网站发送回复、点赞、提及等回应，自己也可以作为接收方接收这种回应，展示在网页上。只要配置得当，在自己的网站中插入链接就能像在社交媒体上用 `@用户名` 的形式提及其他用户一样给其他人发送通知，不过要完全自动化还是有些麻烦的。 我使用 [webmention.io](https://webmention.io/) 提供的服务来接收 Webmention，在 `<head>` 中添加了以下代码来声明我的 Webmention 端口。 @@ -132,6 +178,16 @@ Microformats 是基于 HTML 的一种标记内容和身份的格式，主要用 <link rel="webmention" href="https://webmention.io/www.geedea.pro/webmention" /> ``` -向这个端口发送 Webmention，就会展示在我的网站上。如果你拉到网页最下方，会发现评论按钮旁边多了一个 Webmention 按钮，点开之后可以查看这一页收到的 Webmention，也可以通过表单提交你的网址以手动发送 Webmention，不过发送 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 中没有内容，所以也就检测不到链接。 |