But when I was about to ship a project the other day, I realized it still can’t replace me when it comes to DevOps:

1. Extremely high complexity: DevOps work is far more complex than programming. You’re operating command lines, logging into servers to check things, and you need to be incredibly careful — one mistake can have massive consequences.

2. Multi-dimensional interaction: You need to open various web UIs to manage cloud resources, copy-paste critical keys, deploy services, and operate cloud platform dashboards.

3. Constant context switching: You’re jumping between the terminal and web UIs, constantly verifying and handling edge cases. These operations go beyond what plain text can express.

While OpenClaw can already replace the programmer, no agent can truly handle DevOps yet. I think there’s a huge opportunity here. Maybe it’s time to build a real, autonomous DevOps Agent.

A Real Deployment Story

To show what DevOps difficulties actually look like, let me walk through my recent experience deploying Vocalflow — a voice input and transcription service I built.

First, I created a project on my self-hosted Dokploy instance and set up the app inside it. Then I manually clicked through the configuration to set the Docker image path pointing to GitHub’s container registry. Since the image is private, I had to dig up a GitHub PAT and paste it in.

Next, I wrote GitHub Actions for building the image — this was the one thing I had OpenClaw help with. Then I added another Action: once the image build completes, it calls the deployment platform’s API via curl to trigger auto-deployment. Since this step requires token authentication, I had to open the GitHub Actions settings page and add the Secret Value.

After all that, I pushed the code. The auto-deployment kicked in, but the app failed to start. I checked and found that better-sqlite3 couldn’t find its native Node extension. I had OpenClaw debug and search for a while:

1. First it tried switching the image base from Alpine to Debian Slim — didn’t help.
2. After several fruitless searches, I manually went to the project’s Issues and searched for “Alpine,” finally finding a relevant thread about Docker startup problems. https://github.com/WiseLibs/better-sqlite3/issues/146
3. In there I found a reply about pnpm workspaces — turns out pnpm was blocking better-sqlite3’s post-install build step, and you need to add an “approve-builds” config.

Once I told OpenClaw, it added the file and pushed again. The project finally came alive.

Then came domain configuration. I had to go to the Cloudflare Dashboard, find my top-level domain, add a subdomain, and point it to the deployment server. After that, I went back to Dokploy to map the new domain to the service and configure automatic HTTPS via Let’s Encrypt. I also needed to get the port right — I asked OpenClaw which port the service was actually running on. Only then was everything set up. I then checked Docker’s runtime logs to verify whether auto-migration ran correctly. It didn’t. I notified OpenClaw to look into it, but since it couldn’t directly access the production logs, verifying the fix was hard. I went back and forth debugging several times. Once that was sorted, I started a new session and had it research and write a CLI tool for fetching Dokploy service logs — just to make life easier next time. https://github.com/reorx/scripts/blob/master/dokploy-logs

The Future of the DevOps Agent

This is what DevOps work looks like — extremely tedious, fragmented, and unpredictable. There’s no universal approach to standardize it. Especially in the early stages of a project, entropy is incredibly high. Only after a project stabilizes can you start managing things through standardized text-based tools like Ansible or Terraform, forming SOPs.

In an era where development moves this fast and everyone is constantly building new projects, general-purpose Coding LLMs trained on existing data do have DevOps knowledge, but they can’t truly do the job. They can’t close the loop the way they can with development work. That’s the reality, and it’s the direction I believe future agents need to explore.

The core ideas behind such an agent:

• Not another DevOps platform: Don’t try to build yet another IaaS or ops platform.
• Adapt to the real world: The agent should adapt to real-world DevOps workflows, learning and mastering various skills — like operating AWS, Dokploy, or Cloudflare infrastructure.
• Pluggable architecture: The agent should be pluggable, like a person who can work at any company in any role. It can be installed into any system — whether that’s OpenClaw, Claude Code, or Cursor.

This would complete the last missing piece, freeing developers and small companies from DevOps busywork and closing the entire loop from idea → development → launch.

Sure, agentic coding tools like Claude Code and Cursor have made writing code easier, but at the end of the day, I was still the one writing. It might look like the AI is doing the work, but “writing” is a broad term—writing is execution. As the person making code happen, I’m the one writing code. Whether I’m editing line by line, copy-pasting, or telling an AI what I want and letting it finish—it’s still me “writing.” My role as the programmer responsible for turning code into reality hasn’t changed.

My productivity did improve, but for any given task, I still had to jump into the project, set up the environment, open my editor and Claude Code terminal. I was still the operator; the only difference was that instead of typing code manually, I was typing intent into a chat box. That only changed one dimension. Testing, debugging—most of it still fell on me. There was some change, sure, but it wasn’t mature, and there was no fundamental shift. I still had to stay deeply involved and monitor everything. And it was exactly this deep involvement that kept me stuck in the role of code executor.

Then OpenClaw came along, and everything changed.

I once discussed with my wife: in the age of AI, should you aim to be a “super individual” or build a “super team”? My answer is: become a “super manager.” A super individual who can juggle multiple threads and coordinate numerous AI tools is essentially demonstrating great management skills. Being a super individual means using AI tools to lift yourself from a basic executor to a higher-level one, and eventually into a manager. So even if you’re going the super individual route, you need solid management awareness and methods to keep everything running smoothly.

OpenClaw gave me the chance to become that super manager. After a few rounds of practice, I found that I could completely step away from the programming environment and handle an entire project’s development, testing, deployment, launch, and usage—all through chatting on my phone. That’s something Claude Code simply can’t do, or rather, it was never designed to.

As a general-purpose agent, OpenClaw interacts through messaging apps via voice, accurately understands what I mean, works independently for extended periods, and has solid memory—it can persist the methods and rules it picks up during work, gradually evolving through use. These are the capabilities that make it the real turning point for replacing me as the code executor. The biggest change is this: I just need to express my intent, and it automatically creates the project, writes up a plan for me to review. I can discuss changes with it by voice, and then it executes—even directing Claude Code to do the actual coding.

It replaced the “me” that used to write code, truly stepping into the programmer role and freeing me to act as a manager. A manager shouldn’t get bogged down in the specifics—they should focus on the higher-level, abstract work. That’s what management really is. You could even flip it around: you’re only a true manager when you can get things done purely through communication. Before, Claude Code alone couldn’t get you there. But when you have a dedicated machine running 24/7, set up with all your tools, and an agent that understands your intent sitting at the computer writing and debugging code for you—that’s when things truly change. That’s when the revolution arrives.

This is the biggest shift OpenClaw has brought—it completely transformed my workflow. Whether it’s personal or commercial projects, I can step back and look at things from a management perspective. It’s like having a programmer who’s always on standby, ready to hop into meetings, discuss ideas, take on tasks, report back, and adjust course at any time. It can even juggle multiple roles, like having several programmers working on different projects simultaneously. Meanwhile, I can be the tech lead keeping tabs on specific project progress, or the project manager steering the overall schedule and direction.

This has truly freed up my productivity, letting me pursue so many ideas I couldn’t move forward on before. I feel like my life genuinely changed at this moment. I used to have way too many ideas but no way to build them all on my own—they just kept piling up. But now, everything is different.

It’s like I suddenly have a team, achieving the dream scenario I always imagined: owning a company, hiring people to bring my ideas to life, while I just focus on product design and planning. I’m closer than ever to that dream state. Before, that required serious capital. Without money, you can’t hire anyone, and you can’t just be the idea person. Unless you’re some trust fund kid doing it for fun, you’re stuck bouncing between “indie developer who wants to build multiple projects” and “solo hustler just trying to survive.”

But now, I can finally break out of that trap and move toward actually having a team. It keeps all my projects moving forward at any time. It’s not perfect yet, but I’ve taken the first step.

Thank you, OpenClaw. Thank you, AGI—for me, it’s already here. The gears of fate are turning in directions I never imagined.

Living in a world full of technology and digital devices today, I constantly feel distracted, unfocused, and lost. The smartphone has become a part of our bodies, and we have already evolved into a new species - cyborgs. We no longer solely rely on our biological brains for looking and thinking; much of our important information is stored in our phones, our new “organ.” However, it is dumb in comparison because the only efficient way to interact with it is to use our fingers, which is much slower than other natural organs connected and controlled by neural networks. I want to get rid of it, but deep down I know I cannot live without it.

After discovering The Light Phone, I realized that we may not rely on apps and information as much as we think. However, despite initially being intrigued, I eventually found myself unable to resist returning to my iPhone 7. This begs the question: why did I make this decision?

It’s a downgrade of a person’s capabilities. I can no longer take photos wherever I find something interesting, listen to music whenever I feel like it, or call a taxi wherever I want to go.

It shouldn’t be this way when it comes to enhancing our lifestyle. From a young age, I have never held a high opinion of those individuals in history who chose to live in the wilderness as a means to find mental tranquility. I greatly admire those who can actively engage in society while maintaining a clear mind, living in a manner that brings them personal satisfaction.

Years passed, and it suddenly came to the era of LLMs. One day, I found AI Pin, a wearable device made by Humane with the power of OpenAI. My eyes lit up; I sensed a similar aesthetic and philosophy to the Light Phone. However, that was not enough. The AI Pin has no screen, meaning that I cannot interact with it through vision and touch, a significant loss of HCI technology of the past 60 years.

That being said, AI Pin is heading in the right direction, because what wastes our time and distracts us when using smartphones are the tedious and complex operations with apps. LLM excels at converting natural language into a sequence of machine-understandable commands, which is clearly the way to reduce the friction of using a digital device. I feel that the future is near, only a few steps away, but I didn’t expect it to arrive so quickly.

Today, Rabbit R1 has been released, and I view it as a milestone in the evolution of our digital organ.

R1 is definitely an upgraded replacement for smartphones. It’s versatile and fulfills all everyday requirements, with an interaction style akin to talking to a human. Other devices, such as the Light Phone and AI Pin, though minimalist and distraction-free, fall short of enabling us to accomplish our daily tasks. The disadvantages outweigh the benefits in the ultimate goal of improving our lifestyle.

So, why is R1 great? In my opinion, it’s primarily due to the two new technologies it employs: Agent and LAM.

The concept of an Agent is simple: you instruct the AI what to do, and it will analyze your words to formulate a clear goal. Subsequently, it breaks this goal down into various tasks, orchestrates the completion of these tasks, and finally assembles the results to fulfill the goal. The Agent resolves the issue of LLM’s inefficiency at task completion. AutoGPT is the first proof-of-concept that has popularized the Agent. From a certain perspective, R1 can be perceived as a physical embodiment of an Agent.

The following is LAM, which I believe is the most impressive and exciting feature in R1’s presentation. LAM, or Large-Action-Model, possesses the capability to comprehend any user interfaces and act accordingly. Utilizing LAM, Rabbit has developed a framework. This endows R1 with its most potent tool - the ability to learn.

With the power of teaching mode, R1 can acquire a new skill simply through screen recording and voice instructions. In the presentation, Jesse showed how to instruct R1 to use Midjourney for creating images from user voice commands. This proves that R1 is not limited to what the developers built in; users can tweak it to tailor it to their own needs. There’s no compromise of losing capacities while maintaining a minimalist shape and intuitive use.

Someone once stated, the primary distinction between humans and robots is self-learning. While R1 cannot learn independently, it certainly serves as a commendable human companion.

Generally, I believe R1 has the potential to change the world. This is a thought that seldom comes to my mind, as I have seen numerous new technologies and inventions. However, R1 is different; it’s not just another device to please a certain niche. It’s meticulously designed to serve one significant goal for all people: to improve lifestyle in the digital world.

Debounce 和 Throttle 是两种相似的频率限制手段。Debounce 顾名思义，去掉弹跳/抖动，能看出防止误操作的意味；Throttle 的意思是节流阀，更加直接了当。作为两种常见的设计模式，理解他们的工作原理和细微区别能够帮助我们写出更健壮的应用程序。

虽然是两个通用的概念，但它们的确主要在 JavaScript 中被提及和使用，究其原因，JavaScript 中常常出现连续发生的大量事件，如果不对调用频率做出限制，会产生严重的性能问题。且这些事件是可以舍弃的，一段时间内只需要产生一次有效调用即可。而在后端则很少出现这种情况，所有的事件都必须要处理，性能问题通常通过异步和分布式调用来解决。

下面是我对这两种设计模式的理解。

• Debounce: 将间隔不超过设定时间的多次连续调用变成一次。

  从工作原理上来讲，Debounce 会使目标函数变为延迟生效，当对其进行连续多次调用时，若前后两次调用的时间间隔不超过设定值，则前一次调用会被取消。直到某次调用后，在设定的时间内没有出现下一次调用，那么这次调用将不会被取消，从而最终被执行。

• Throttle: 确保一个函数被连续多次调用时，在设定时间内最多只实际执行一次。

放在一起对比的话：

• 相似之处：Debounce 和 Throttle 都限制了函数执行的最大频率不超过每设定时间一次
• 不同之处：在快速（间隔小于设定时间）连续调用时，Throttle 确保了函数会规律执行，但 Debounce 只有当连续调用放缓（间隔大于设定时间）时才会执行。

应用场景

设想如下几个场景:

1. 当用户改变网页窗口的大小后，调用一个函数以调整 UI 布局
2. 当用户在滚动浏览网页内容时，根据内容所处的位置，持续更新大纲目录中的链接高亮
3. 在一个输入框的下方，让搜索提示结果随着用户的输入持续不断地更新

我们一起来看看每个场景分别应用 Debounce 和 Throttle 会有什么样的效果，并评判哪个是更加合适的频率控制方式。

场景 1

用户按住鼠标不松一直改变窗口大小，使用 Debounce 的情况下，UI 在用户停顿或者松开鼠标时才会改变；使用 Throttle 的情况下，用户会观察到 UI 在拖拽窗口大小的过程中每隔一会改变一次，容易给人一种反应迟钝或卡住的错觉，因此 Debounce 是更好的选择。

场景 2

用户持续向下滚动鼠标滑轮，使用 Debounce 的情况下，大纲的高亮只有当用户停止滚动时才会更新。所以当用户一次性滚动很长时，只能看到一次高亮的改变，中间仿佛跳过了一般；而使用 Throttle 的情况下，随着用户滚动，高亮会稳定地以设定的时间间隔更新，因此 Throttle 是更好的选择。

场景 3

用户以较快地速度连续输入字符，使用 Debounce 的情况下，只有当用户停止输入时搜索提示才会更新；使用 Throttle 的情况下，搜索提示会稳定地以设定的时间间隔更新，但如果用户输入最后一个字符的时间，正好处于上一次调用后的间隔期，无法触发新的调用，那么用户所看到的提示就不是根据完整的输入内容做出的。Debounce 由于能够保证函数总是在用户停止输入时执行，是比 Throttle 更好的选择。

库的使用

首选 lodash，因为它是一个非常流行且久经考验的库。但如果不想让整个 lodash 混入项目的构建结果，可以安装 lodash.throttle 和 lodash.debounce 两个独立的库。如果你使用的 bundler 支持 tree-shaking，也可以通过 lodash-es 来 import 这两个函数，最终构建结果中只会包含与之相关的代码。

npm 狂魔 sindresorhus 也维护了两个包，debounce 和 throttleit, 如果你想要更简洁的实现，可以考虑使用。

下面以 lodash.throttle 为例，展示其如何在一个 TypeScript 项目里安装和使用 :

npm i lodash.throttle
# 还需要额外安装 `@types/` 的类型定义
npm i -D @types/lodash.throttle

引入和调用:

import throttle from 'lodash/throttle';

const onScroll = () = {/* 实现细节 */}

// onScroll 执行的最高频率为每 100 毫秒一次
document.addEventListener('scroll', throttle(onScroll, 100));

后续思考

这篇笔记来源于重构 GitHub TOC Sidebar 扩展时对场景 2 的思考，之前用的是自己手写的 Debounce，在滚动过程中经常看不到 ToC 的高亮变化，这次换成了 lodash.throttle，终于达到了预期的效果。其实这三个场景我都在过往的开发经历中遇到过，并且是在不了解这两个概念的情况下独立思考出了（简陋或丑陋的）解决方案，直到最近才重新审视，阅读了相关的文章，学习了更好的实现方式。这也是为什么我在关于状态机的短文中感叹基础知识的重要性，如果能更早地知道这两个概念，就能避免曾经在黑暗中摸索的痛苦。当然，因为自己琢磨过，当看到更系统更高级的实现时，就会有更深刻的理解，这大概是这位推友希望自己是通过 Vanilla JS 学习前端的原因。

一言以蔽之，开发遇到困难免不了自己琢磨，但在琢磨时多想想能否将问题定义出来，符合一个已有的概念，然后去参考现实世界中系统和标准的解决方案；如果没有也无所谓，未来某一刻这种思考过程会化作某种领悟，不会白费。

参考资料

• Debouncing and Throttling Explained Through Examples: css-tricks 的经典老文
• Debounce vs Throttle: Definitive Visual Guide: 用动态可交互的方式展现了 Throttle 和 Debounce 的差异，非常推荐阅读
• THROTTLE.JS: underscore 的 throttle 源码
• _.debounce: lodash 的 debounce 文档

最近阅读了一篇文章，是 AdGuard 开发基于 Manifest V3 新插件的技术性回顾:
AdGuard publishes the world’s first ad blocker built on Manifest V3

这篇文章以 AdGuard 自身作为范例，对比 Manifest V2/V3 的差异，让我终于理解了 V3 API 变化的影响之所在。

简而言之，Manifest V3 对 AdGuard 造成了如下影响：

• 规则数量限制

  • 每个扩展的静态规则数量被限制在了 30000 个以下，所有扩展的静态规则之和不能超过 330000 个。

    For static rules, Chrome set a minimum guaranteed limit of 30,000 rules per extension and a total limit of 330,000 rules for all extensions installed by a single user (this also takes into account the limit of 1,000 regexp rules per extension).

  • 预设的过滤器最多 50 个，用户自定义过滤器和规则之和不得超过 5000 个。

    blockers must use pre-set filters (no more than 50), and we have to be very selective about which filters will be available to users. Of course, you can still set your own filter manually. But don’t forget the 5000 rule limit on all custom filters and user rules.

• API 变更: onBeforeRequest → declarativeNetRequest

  • onBeforeRequest 是 Chrome Extension 中的事件回调函数，广告屏蔽插件的工作原理就是在这个函数中使用自己的一套逻辑来判断是否要中断当前的连接。从 Manifest V3 开始，这个函数就被废除了，取而代之的是 declarativeNetRequest，因此 AdGuard 必须将原来的私有动态规则转换成使用 declarative rules 所描述的新规则。

  • 而受 declarative rules 的语法所限，一些 AdGuard 原有动态规则的功能将无法被实现

  • rulesets（一组 declarative rules）只能在扩展安装和更新时加载，导致 AdGuard 失去了动态更新规则的能力

    declarative rules must be combined into rulesets

    Rulesets are specified in the manifest.json file and are loaded only when the extension is installed or updated.

• 无法获得统计信息

  • 由于 Chrome 自己实现了一套拦截机制，Manifest V3 不会将请求的统计信息开放给生产环境下的扩展，仅能在开发模式下使用。这意味着 AdGuard 将无法真正确认到动态规则的执行情况，只能通过模拟运行来猜测规则是否可能被应用了，对于规则的维护者来说是灾难性的打击。

    Chrome itself now blocks requests and shares statistics only with extensions unzipped and installed in Developer Mode

    only show which rules may have been applied.

• Service Workers 不能保证常驻，需要主动唤醒

  • AdGuard 的 cosmetic rules（在网页上屏蔽元素的规则）原本运行在 background.js 中，这个机制在 Manifest V3 中被 Service Worker 取代，由于不能常驻后台，cosmetic rules 有一定无法生效。

    When the browser stops the service worker, the extension goes into a kind of sleep mode: the declarative rules work, but the cosmetic rules that are loaded dynamically do not.

可以看出，AdGuard 这款新的 Manifest V3 插件在各方面都受到了「阉割」，无怪乎文章传达出了一种艰难求存、呼吁支持的态度。

在我看来，其实 Manifest V3 的核心非常明确，就是限制扩展对系统资源的使用。一直以来高资源占用都是 Chrome 为人诟病的痛点。相信每个用户都遇到过 CPU 或内存飙升的情景，许多人甚至说 Mac 没有 16G 以上的内存不要用 Chrome。而扩展由于在后台运行，如果出现问题，更是难以定位和管理，我想这就是 Google 的工程师想要做出改变的原因。

虽然增加了诸多限制，但我确实感受到 Manifest V3 的一些有益之处：

• Service Worker 使得扩展不再能常驻后台，让扩展所占用的资源可以被回收，降低了浏览器整体的开销
• 限制规则的数量，相当于控制了单一扩展在规则计算方面的资源使用上限
• 以无法在运行时更新为代价，declarative rules 实现了更高效的动态规则
• 不再提供请求底层的统计信息，缩短了请求生命周期中的调用链，提升了处理效率

这些变化可以让 Chrome 变得更加流畅，对于 99% 的用户来说都是好事。

未来的方向，也许 Chrome 可以提供一个 IPC 或者其他更有效率的通信方式，让另一个进程参与到请求的处理流程中，这样 ad blocker 插件的最大开销——规则匹配——就不再是效率和资源的瓶颈了。就像 LSP 的工作模式，把复杂的事情分离出来让独立的组件来做，说不定会诞生一个用 Rust 开发的新一代 rule filter engine 呢。

希望这篇文章能够帮助你理解 Chrome Manifest V3 的变化，辩证地看待它。

后记

补充一些本文完成后，与 Manifest V3 有关的趣闻

2022-09-29

昨天 Chrome 官方博客发布了一个声明 (More details on the transition to Manifest V3)，将 Manifest V2 的废除时间从 2023 年 1 月向后推迟了一年:

Starting in June in Chrome 115, Chrome may run experiments to turn off support for Manifest V2 extensions in all channels, including stable channel.

In January 2024, following the expiration of the Manifest V2 enterprise policy, the Chrome Web Store will remove all remaining Manifest V2 items from the store.

再来看看两年前对废除 Manifest V2 的声明:

January 2023: The Chrome browser will no longer run Manifest V2 extensions. Developers may no longer push updates to existing Manifest V2 extensions.

从原本的斩钉截铁，变成现在的含糊和留有余地，看来强如 Google，想要执行一个影响全世界 65% ¹ 互联网用户的 breaking change，也不是那么容易呀。

2022-10-03

著名单文件网页存档插件 SingleFile 作者依照 Manifest V3 标准重构了原版插件，命名为 SingleFile Lite，并用宣传产品升级的语气描述了新插件的 “features” 和 “benefits”，非常讽刺，可以说是一场代码行为艺术了。

Feel the power of the Manifest V3. The future, right now!

Notable features of SingleFile Lite

• unreliable auto-updates
• no auto-save
• save time limited to 5 minutes max.
• no “Referrer” header injection
• limited support for fonts dynamically loaded with the FontFace API
• and more to come!

Benefits of the Manifest V3

• none

Hacker news: Feel the power of the Manifest v3 | Hacker News

系统架构

我们所要搭建的这套服务有着如图所示的系统关系。

• Cloudflare: CDN 和 Proxy，用于加速网站访问，可选组件
• Railway: PaaS 平台，提供 Docker 环境运行 n8n 的后端进程
• Supabase: 作为数据库供 n8n 使用

完整部署流程

Supabase: 创建数据库

首先我们要在 Supabase 上注册一个账号，登入之后，点击 New project 创建新的数据库，命名为 n8n，注意要记住创建流程中输入的密码。

定位到 Project settings / Database / Connection info，将图中的信息记录下来即可进入下一步。

GitHub: 创建 Repo

在 Railway 上部署服务最便捷的方式就是关联一个 GitHub repo，你可以 fork 我准备好的: reorx/n8n-on-railway

这个 repo 的内容非常简单，其中最核心的就是 Dockerfile，只有一行代码：

FROM reorx/n8n-custom

它的作用是基于 reorx/n8n-custom 定义新的镜像。Railway 会使用这个 Dockerfile 来自动构建和部署服务。

reorx/n8n-custom 是我个人维护的镜像，基于版本 0.193.5 构建 ¹，目的是提前使用 PR 的代码，以解决无法接入 Twitter 的问题。如果你对安全性有所担忧，也可以使用官方镜像 n8nio/n8n。

Repo 中还有 example.env 和 export_workflow.sh 两个文件，稍后我们会用到。

Railway: 创建 Project

注册或登入 Railway，点击 New Project，选择 Deploy from GitHub repo，找到上一步创建的 repo 名字（n8n-on-railway）并选择，在下一个界面点击 Deploy now 开始部署。

修改域名

不需要等待部署完成，我们直接进入 Project，点击代表 service 的卡片，打开 Settings。

可以看到 Railway 已经为我们的服务分配了一个 .up.railway.app 的四级域名，这将是你访问 n8n Web UI 的入口。如果你对域名没有要求，可以保持不变，将这个域名记录下来；如果你希望使用自己的域名，请参考 Exposing Your App 文档中的 Custom Domains 章节进行设置。

下图是我的域名 n8n.reorx.com 在 Cloudflare 的配置信息。由于 n8n 是一个重前端交互的网站，需要加载很多庞大的 JavaScript 文件，直接通过 Railway 访问效率很低。使用 Cloudflare 的 Proxy 功能，可以让这些静态资源走 Cloudflare CDN，加速网站访问。因此我非常推荐用 Cloudflare 来托管 n8n 自定义域名。

设置环境变量

确认域名后，我们要切换到 Variables 页面对环境变量进行设置。

点击 Raw Editor 按钮，在弹出的输入框中粘贴 GitHub repo 中的 example.env 文件的内容，并调整各变量的值。其中：

• DB_ 开头的部分要根据 Supabase 的 Connection info 对号入座
• VUE_APP_URL_BASE_API 和 WEBHOOK_URL 填写上一步中所使用的域名。
• N8N_ENCRYPTION_KEY 是 n8n 加密 credentials 所使用的 key，请务必使用自己生成的随机字符串。如果没有这个变量，n8n 会随机生成一个并保存到文件系统中，在 Railway 的运行环境下重启后就会丢失，导致已保存的 credentials 无法解密 ²。
• EXECUTIONS_DATA_PRUNE: 打开 n8n 的自动化数据清理功能，使 n8n 定期清理在 EXECUTIONS_DATA_MAX_AGE 小时以前的执行记录，确保数据库体积不会上升过快 ³。（Supabase 的免费额度只有 500M）

以上这些变量均可在官方文档 Configuration 中找到详细说明。

编辑完成后，点击 Update Variables，Railway 会开始新的部署任务。至此，我们就完成了 n8n 在 Railway 上使用 Supabase 数据库的部署流程。

初始化和数据迁移

如果一切正常，等 Railway 的部署任务完成后，即可通过 修改域名 环节所确定的域名打开 n8n 网站。第一次访问时，n8n 会引导用户创建管理员账号，安全起见，请尽快完成这一步骤。

Workflow 导入

如果你有已经备份好的 workflow，此时就可以进行导入了。先创建一个空的 workflow，然后在左侧菜单点击 “Import from File”，选择已有 workflow 的 json 文件即可完成导入。导入后，原 workflow 所使用的 credentials 会失效，需要手动选择或创建新的 credentials 才可以正常使用。

reorx/n8n-workflows 是我自己使用的一些 workflow，供读者参考。

Workflow 导出

出于备份或分享的目的，我们可以导出 n8n 的 workflows。下面讲解如何将运行在 Railway 中的 n8n 的 workflows 进行导出。

1. 准备一个 Docker 环境，包含一个 Docker host 以及命令行工具 docker

2. 安装 Railway 的命令行工具 railway ⁴

3. 进入 GitHub Repo 所在的目录，执行 railway link，选择 n8n 对应的 project

4. 执行如下命令

   EXPORT_ROOT=/path/to/volume railway run bash export_workflows.sh
   

   其中 EXPORT_ROOT 是文件输出路径，将作为 volume 挂载到所要执行的 Docker 容器中。

   railway run 会将线上 project 的环境变量注入到当前 shell 中，使最终执行的脚本 export_workflows.sh 使用与线上一致的环境。

   执行完毕后，即可在 EXPORT_ROOT 下找到当前日期命名的目录，其中的 json 文件即为导出的 workflows。这些文件是以 workflow 的 id 命名，你还可以使用我的 get_workflows.py 脚本修改文件名为实际的可读名称，并清理其中的无用数据:

   python get_workflows.py $EXPORT_ROOT/n8n-$(date +%Y%m%d) workflows/
   

这个导出方法同样适用于 NAS Docker 中部署的 n8n，只需要去掉 Railway 相关的步骤即可。

接入第三方服务

n8n 的强大在于它内置了很多线上服务的 Integrations，仅需简单的配置即可完成接入。虽然官方有文档说明，但仍然有一些不大不小的坑，这里记录下我的一些配置技巧，希望能帮助你节省一些时间。

Google

Google 的接入相对比较复杂，请跟随文档 Integrations: Google 的详细说明进行操作。这里只说下文档中没有提到的一个注意事项。

在创建 OAuth consent screen 后，要将 Publishing status 设为 Testing，否则 Google 的 OAuth 页面会显示应用未通过审核的警告。还要将想要接入的 Google 账号邮箱加入 Test users 列表，否则无法再 Testing 模式下通过 OAuth 验证。

以下内容为 2022-09-24 更新

在创建 OAuth consent screen 后，要将 Publishing status 设为 Production，否则一周后 OAuth token 就会过期 ⁵。虽然这种方式会导致 OAuth 认证页面显示应用未通过审核的警告（点击左下角 “Go to …” 可以绕过），但总好过每周重新连接一次的麻烦。

以下内容为 2022-12-01 更新

只有当服务的域名为自定义域名且为 authorized domain 时才可以将 Publishing status 设为 Production，否则一段时间后 OAuth 将不可用，Verification Status 异常。关于如何将自己的域名在 Google 进行验证，请参考 Verify your domain (host-specific steps) - Google Workspace Admin Help.

Twitter

Twitter 由于这两年来 Developer Portal 的大幅改造，实际操作中可能与文档 Integrations: Twitter 有许多不一致，但只要确保以下几点，应该可以避免大部分问题。

1. 确保创建的 App 在 “Standalone app” 这个分类下
2. 确保 “User authentication settings” 按下图所示配置

   

3. 确保向 n8n 填入的 Consumer Key 和 Consumer Secret 来自下图中红框所在的位置

   

Pinboard

n8n 没有内置 Pinboard 接入，不过 Pinboard API 设计非常简洁，我们可以手动实现接入。

创建 credential 时选择 “Query Auth”，向 “Name” 填入 auth_token，向 “Value” 填入从 Pinboard password 页面得到的 API Token。完成后，即可在 HTTP Request node 中使用。

GitHub

n8n 虽然有内置的 GitHub 接入，但并非所有 API 都被支持，因此我建议使用 HTTP Request 手动配置验证。

GitHub 提供 PAT (Personal Access Token)，与 Pinboard 的 API Token 类似，相比 OAuth 更容易配置。

GitHub API 支持在 HTTP Header 中通过 Authorization 字段进行验证，其值为 Bearer + PAT ⁶。

首先打开 https://github.com/settings/tokens, 点击 Generate new token，勾选所需权限。具体根据所要请求的 API 来决定，一般来说至少要勾上 repo 和 user。创建完成后复制结果即为 $PAT。

然后在 n8n 中创建 Header Auth，“Name” 填写 Authorization，Value 填写 Bearer $PAT（将 $PAT 替换为上一步的结果）。完成后，即可在 HTTP Request node 中使用。

总结

随着 PaaS 和 Serverless 平台的兴起，在很多场景下它们都能够代替 NAS 成为自托管服务的最佳选择。个人使用免费额度一般都绰绰有余，无论对于想要快速试验新产品的开发者，还是喜欢体验 SaaS 服务的业余爱好者，现在都是一个非常好的时代。

之前将 n8n 部署在 NAS 上平均每天会有几十条错误报警，一部分是 SQLite 在机械硬盘上频繁读写触发事务锁竞争，一部分则是代理不稳定造成网络访问失败。在迁移到 Railway + Supabase 的方案后，两个问题都得到了解决。PostgreSQL 有着更好的连接和并发性能；而 Railway 的运行环境本身就处于外网，自然也不会遇到代理失效的问题。

Railway 也可以提供包含 PostgreSQL 的全托管方案，但独立运行 PostgreSQL 不仅资源消耗大，显著占用免费额度，而且不如 Supabase 这种专业的 DaaS 稳定和安全。Cloudflare 的免费 CDN 服务，补充了 Railway 分发能力的不足，也降低了出口带宽的成本。几个平台相互搭配，取长补短，使新的方案可以用最低的成本实现最佳的性能和体验。

我从 2018 年开始使用分体式键盘，如今它已成为我不可缺少的设备之一。

如果你看过我的 2022 年 7 月和 8 月总结，就会知道我的手腕一直都不是非常健康。在接触分体式键盘之前，我就有意识地不用笔记本电脑的自带键盘，并尝试了一些机械键盘，但提升不大，手腕还是会经常感到疲劳。

直到某天我在 Kickstarter 闲逛，发现了 Ergodox EZ（下简称 Ergodox）这款产品，这才了解到分体式键盘这一概念。本着健康至上的消费原则，我第一时间就下了单，就像 2015 年购买 Herman Miller 时一样果决。

Ergodox 对我的影响是巨大的，它大幅提高了我的打字效率和电脑操作效率，并且最终为我解决了长时间打字手腕疼痛的问题。

对于第一次使用分体式键盘的人，肌肉记忆是最大的挑战。我花了两个月的时间才逐渐适应 Ergodox 的键位，并学会了如何为自己设计键盘布局。这个过程还纠正了我多年的手指键位错误，比如我原本是用右食指敲 B，但键盘分体后就必须用左手了；之前我总是随机用任意手指按数字键，分体式键盘让 1-5 归左手、6-10 归右手，使我盲打数字的精准度产生了飞跃。

分体式键盘的另一个也是最重要的优点，是可以自由调整间距、倾斜度、旋转角度，这使手腕总是可以处于最舒适的位置。换句话说，是键盘来适应你的手腕，而不是反过来。没有用过的人，无法想象这种打字如呼吸般自如的畅快感。甚至在胳膊出现伤痛时，它也能继续使用而不造成伤害，简直可以归于医疗复健设备的范畴了。上个月我因颈椎和肌肉损伤右臂无法活动，也是因为有 Ergodox 我才能尽早恢复打字（实际上，病痛产生的很大一部分原因就是半年没有使用它）。

Ergodox 的布局属于 Columnar stagger，中文里有人把它叫做「直排」，即键帽竖直对齐。常见的键盘是 Symmetric stagger——水平对齐，分体式键盘中也有这样的布局。选择哪种在我看来并不重要，因为分体式键盘自由摆放的特性会最大程度上消除布局的差异。我在使用 Ergodox 前并没有接触过直排键盘，但习惯后并没有觉得有什么问题。

购买建议

我将分体式键盘推荐给任何使用键盘进行工作的人。

如果预算不是问题，我建议购买 Ergodox 家（现在改名叫 ZSA）的新产品 Moonlander，它是 Ergodox EZ 的升级版，更加简洁优雅。一体化的设计便于携带，拇指区域的键位也做出了优化，虽然少了两个键，但反正也用不了那么多，位置合理才是更重要的。

其实上手一个新的产品，$365 的价格还是挺高的，海淘转运也断绝了试错机会。所以如果不是特别肯定，可以试试在闲鱼/淘宝上找客制化键盘的卖家，几百块买一个尝试一下。搜索的关键词就是「分体键盘」。

如果你喜欢 DIY，也可以找一个开源的分体键盘项目，自己动手做一套，不仅有趣，而且省钱，我相信会是一次非常有成就感的体验。我的 Pinboard 上收藏过一些相关链接，其中我比较喜欢的是 rtitmuss/torn 和 kata0510/Lily58。

总价是￥16197，好贵！相当于一台中配 MacBook Pro。但这么一想，反而不觉得贵了，同样的价格可以得到三个不同产品的体验，简直太划算了不是吗 😏

我对苹果产品的购买通常从三点进行考量，一是产品设计是否有颠覆式的变革，或者足够创新有趣，iPhone 14 Pro 的灵动岛显然满足这点，并且是业界独一无二的。许多人（如罗胖）说这是硬件落后倒逼软件妥协，有道理，但我不会因此否认它的人机交互设计价值。

第二点则是目前的设备是否拖累了我的生产力，新的设备能否做出有效的提升。我手里的 iPhone 11 Pro 还挺顺畅，iPhone 14 Pro 也没有 life-saving 级的变化，就看库克啥时候按下降频按钮了。

最后一点, 是手机的大小和重量，而且不容妥协。我非常爱惜自己的右手和手腕，手机太大握持不舒服，太重则手腕容易疲劳。在 iPhone X 发布时就对我产生了巨大的考验，好在 6.1 英寸我还能勉强接受，后续也都维持了这个大小。因此每次看新 iPhone 的 spec，我总是先关注重量。下面是我整理的 iPhone 从 X 到今年的 14，重量变化的表格（X 算作初代的 Pro）：

画成图表看更加直观：

你一定想不到，当时使我决定购买 iPhone 11 Pro 而不是 iPhone 11 的原因，是前者比后者轻了 6 克！可惜的是，Pro 系列的重量在之后逐年递增，不再是我的首选项了。希望明年不带 Pro 的 iPhone 也能拥有灵动岛，这样我就会乖乖掏钱啦（库克！）。

再看看另外两个产品。Watch Ultra 的情况和 iPhone 14 Pro 差不多，不予考虑。Airpods Pro 2 则决定购买，已经在今晚抢到。现在我还在用着几年前买的 Airpods 2，有些旧了，正好换成最新产品。何况又有了可以像 AirTag 那样去寻找的便利性呢。

关于苹果，从 iPhone 11 到 13 我一直都不觉得有什么值得称道的创新，今年终于让我有些刮目相看。但我不觉得这是什么值得吹捧的事情，作为地球上最有钱的科技公司之一，本就应以引领行业发展为己任，不然赚那么多钱是干什么吃的。有人会说，资本家本就是以最低成本创造最大收益为目标呀。但这个世界还是需要有理想的人存在，哪怕只有些许的人、些许的理想，这样人类文明才不会太过无趣不是吗。

健康

回顾一下过去十年我所经历的病痛：

• 2013: 严重的中耳炎，耳膜破裂，听觉受损
• 2014: 肩膀和手臂拉伤，一个月不能使用右臂；右腿拉伤
• 2015: 右手腱鞘炎导致右手肿大压迫神经，住院一个月
• 2016: 过敏性支气管炎，咳嗽一个月
• 2018: 过敏性鼻炎，咳嗽两个月
• 2020: 支气管炎和轻度肺炎，在家治疗一个月
• 2021: 过敏性支气管炎，咳嗽一个半月

除了 2017 和 2019 年比较幸运，其余年份都有跨度至少一个月的异常时期，简直让人对生病产生仪式感了。

虽然生病本身并不是什么愉快的经历，但我也因此磨练出了比较坚韧的心态，无论去医院遇到什么麻烦和挫折，都能用平常心面对；不管是出门看病，还是自主治疗，总是能做好周全的准备；家人和朋友的悉心照顾，也让我体会到亲情和友情的珍贵。

生命本身就是在等价交换，有得有失，真的没什么可抱怨的了。所以每次病后，也只当是一次年度提醒，告诉自己要继续坚持锻炼身体，才能持续探索这个无限精彩的世界。

现在来大致回顾下今年的赛况。

上半场是鼻炎和支气管炎。7月3日从老家回到杭州，立刻就开始感冒，随后是持续的鼻炎和咳嗽。期间我没有去医院就诊，依照自己丰富的过往经验，先是在嗓子发炎时服用了针对细菌感染的阿莫西林。进入鼻炎阶段后，没有吃内服药物，而是用布地奈德鼻喷雾剂进行（这是因为我清楚自己是过敏性鼻炎，抑制鼻部症状，等待身体免疫恢复即可）。鼻炎减轻后，按照惯例引发支气管炎和咳嗽，于是我又购买了针对自身情况的孟鲁司特钠片，吃了几天后咳嗽减轻，随后慢慢恢复适度的有氧锻炼，大约在月中彻底结束。

下半场比较意外，是右臂肌肉劳损。前面鼻炎时为了转移注意力，游戏时间增加了很多，由于没掌握好手柄的使用姿势，胳膊一直隐隐作痛，但被我忽视了。等到呼吸系统恢复，我又迫不急待地连续写了两天代码，终于使三角肌不堪重负，剧烈疼痛，整个右臂都肿了起来。这让我一下子回到 2015 年的夏天，好在我对此也有经验，我清楚这种程度的肌肉劳损不是一时半刻能够恢复，便用绷带固定右手，开始练习使用左手打字、用筷子、洗澡、擦屁屁。头两天我买了冰袋冷敷，等到触碰肌肉不再那么疼时，我没事就用左手慢慢按摩三角肌。最后临近恢复时，又购置了握力器来复健因长期不活动而难以握拳的右手。折腾到 7 月 30 日前后，才重新正常使用右臂。

时间来到 8 月，又一个意外出现，进入加时赛阶段——颈椎疼痛，脖子转不动了。这一方面是受右肩的影响和左臂的过渡使用，脖子本身有些僵硬了；另一方面，我把睡了一年的宜家弹簧床垫换成了棕榈床垫，一时间睡不习惯，导致了落枕。第二天发现脖子没法往左右转动，稍微使劲就很疼。但是不慌，我想起 5 年前有过同样的症状，火速在 JD 下单了「颈椎牵引器」，顶着极端高温天气戴了一个星期，终于圆满完赛。

这次持续生病的起因，主要在于 6 月回家乡度假时，作息被打乱，不仅中断了日常锻炼，还几乎没有睡好觉，导致身体素质短时间大幅下降，病也就趁虚而入了。我的体质比较特别，如果持续锻炼，即使量比较少，也能表现出很好的运动机能。但只要停止锻炼，很快就会低于常人，容易困倦和生病。以后要更加关注自己的身体状况，尤其是对于睡眠质量。睡眠关乎身体的自我调节和平衡能力，如果连续产生低质量睡眠，一定要以最高优先级应对。

生病期间，在 Twitter 上知道了 默沙东诊疗手册 和 腾讯医典 两个医学参考手册 ¹，帮助我重新梳理了对一些医学概念的认知。这个意外收获让我越发觉得，人要在任何情况下保持交流，不断更新自己。

游戏

多亏了游戏，让我在对工作力不从心的时候保持了活跃的精神状态。但游戏玩多了确实有些收不住，会感觉自己该做的事情拖欠了太多，产生空虚感和负罪感。但这不是游戏的问题，而是我需要继续提高控制力、合理安排时间（哪怕是在生病的特殊时期）。

下面按平台列举我这两个月玩过的游戏。

Steam

• Vampire Survivors (MacOS)

  好玩又上头，Vampire Survivors 属于仅靠优秀的机制就能支撑整个游戏体验的作品，画面几乎就是贴图平移，但并不影响其出色的游戏性（梦回 Dream Quest）。每局 20 分钟，围绕武器系统构建 Build，发现不同组合的趣味，挑战更高的收割效率。它开创了一个新的游戏模式，也带来了很多模仿者 ²。不过没关系，这么好玩的东西请多来点。

  操作上，基本只需要上下左右四个按键，对于只能使用左手的我来说特别友好。

  如果你有兴趣，可以尝试下目前已知的几款相似游戏：

  • Soulstone Survivors
  • 20 Minutes Till Dawn
  • HoloCure by Kay Yu
  • Magic Survival - Apps on Google Play

• Stacklands (MacOS)

  Sokpop 7 月的作品（每月出一个新游戏），SLG + DBG 组合，同样有着优秀耐玩的机制。朋友来看望我时，用 Stacklands 度过了一个愉快的下午。

• V Rising

  来自表妹的礼物 ³，一开始我以为它是类似 Diablo 的 ARPG，打开才发现是 Don’t Starve 类型的沙盒经营游戏。总的来说画面不错，但是一个人玩进度太慢，推荐和朋友们一起开黑。

• Rogue Legacy 2

  白嫖朋友的游戏库。Rogue Legacy 一代很多年前就玩过，非常喜爱 ⁴，二代的感受更像是一代的高清重置 + 新职业和地图 DLC，有时间是可以慢慢通关的。可惜的是，开发团队没有资源将游戏移植到 Switch，对我来说更希望能在 Switch 上玩这种横版的 platformer 游戏。

• Stray

  没有买，看 streamer 的录播视频云通关。之所以特别记录一下，是因为 Stray 和我 2020 年关注的一款游戏 Little Kitty, Big City (后称 LKBC) 太像了。LKBC 的开发者只有一个人，进展缓慢，但光是预告片就深深吸引了我，我能感觉到作者在其中倾注的对猫咪的爱，相比而言 Stray 就有些缺少温度了。⁵

  Stray 虽然也很优秀，但作为一款短流程的风格化游戏，本应该充满彩蛋和细节，让人可以不停地把玩，但现实却是缺少打磨、bug 众多。Stray 大火让我对 LKBC 的未来感到担忧：等到发售时，人们会不会将其视作模仿者而不予以足够的重视呢？

• Disco Elysium

  极乐迪斯科！无需多言，这是一个早该玩但拖到现在的艺术品。由于还没有通关，对游戏剧情就不做评价了。值得一提的是游戏有一键瞬间切换语言的功能，这让一贯坚持用英语完成所有游戏的我非常开心，毕竟叙事型游戏，文案难度还是很高的，中英对照会容易很多。 ⁶

Switch

• CrossCode

  我很喜欢《远星物语》这个译名，这个游戏我在 Steam 上关注了很久，却在 Switch 上等来了打折 ⁷。游戏无论音乐、画面、UI 都很出色，就是走路太费劲了，2D 表现 3D 的地形实在是有些费眼，更别说制作者将其当做 feature 深度耕耘，竟使我回忆起玩仙剑奇侠传走迷宫时的恐惧。最终我只好遗憾地放弃了。

• Scott Pilgrim vs. the World: The Game

  同样是打折购买，一款非常好玩的 Beat ’em up 游戏。就像是 Streets of Rage 4 的小人儿版。鼻炎的时候在玩，还差一关打通，右臂损伤之后就没敢玩了。

• 忍者龙剑传大师合集

  忍龙是大学时的记忆，工作后我还拥有过一台 PS Vita，在上面把 Sigma 2 玩了一半流程，这次是冲着回味和补完去买的。总的来说，一代虽然经典，但是太难了 ⁸；二代是初恋，而且难度和乐趣也都刚刚好；三代是狗屎，10 分钟我就退出了。

• Super Mario Odyssey

  一个我不好意思说我现在才玩的游戏，不多评价了，问就是「任天堂TM就是世界的主宰」。目前有 300 🌙 的收集进度。

• 异度神剑 3

  XB3 发售的时候，我的右臂刚摆脱绷带，不敢轻易使用，于是全程用左手操作手柄，好在这个游戏不怎么需要走位之类的复杂操作，好感 +1。连续玩了几天，进度大概有一大半。

  XB2 之前我曾有心去补，但对我来说还是有点太大了🥵。XB3 则恰到好处，几乎没有我不喜欢的角色。剧情方面，XB3 虽然更有深度，但 XB2 的王道少年漫套路或许更适合游戏整体的画风一些。音乐方面，XB3 是好听的，但没有到让人回味的程度；我单独听过 XB2 的 OST，觉得更胜一筹。

• 旷野之息

  6月购入 Switch 的时候玩的第一个游戏就是旷野之息，当时打到城堡主殿就停下来了。最近有天打开游戏想要随便逛逛，不小心走进主殿触发了 BOSS 战，通关了…于是顺手买了 DLC 开启大师模式，经过 2 小时的练习，成功拿初始装备攻克初始台地人马，成就感满满。开完四神兽后，又尝试了剑之试炼，没想到难度过高，打得我自闭了两天，决定放弃，转头去玩英杰之诗。

  旷野之息对我而言，既有如《风之旅人》般自由写意的精神享受，又有比肩《巫师3》的战斗乐趣。之后我会慢慢把所有的神庙和呀哈哈都刷完，这是对我心目中最好的游戏所能表示的最大敬意。

• Splatoon 3

  由于发售日将近，Splatoon 3 的宣传视频最近也多了起来，看完之后我就种草了。其实我还挺喜欢多人竞技的游戏，在我看来 Splatoon 就是更好玩的 Overwatch，只恨当年不知道，不然我早就去玩 Splatoon 2 了。但最近身体好了之后也要恢复工作，虽然买了预购，一时半会也不敢轻易去玩了。

Itch

• 奶奶的菜谱

  非常有趣的互动式小说 (Interactive Fiction) 游戏，是两位留学生的毕设作品。玩家扮演一个孤独的社畜用手机向千里之外的奶奶学习做饭。让我想起了刚毕业那两年的自己。 ⁹

• Die in the Dungeon

  筛子、DBG、Roguelite、爬塔，全都是我喜欢的元素，放在一起自然是加倍好玩，而且还是全平台免费，快来和🐸一起🎲吧。 ¹⁰

• Shogun Showdown

  同样具有 Roguelite 和爬塔元素，玩家扮演一名武士，只身对抗左右不断涌现的敌人。游戏将武士的动作和武器融入到卡牌构筑中，策略非常多样，鼓励进攻，玩起来真的有种狭路相逢勇者胜的刺激感。适合摸鱼或编译的时候随手来两把。 ¹¹

• MOBS, INC

  你是一个给魔王打工的怪物，被派去干掉闯入地城的人类冒险者，如果被打败，地狱的老板会让你不要偷懒继续工作。这种反串阵营的设定在 Skul 和 Legend of Keepers 上见到过，非常有趣。

• Luckittown

  掷骰子的 SLG 塔防游戏。设计亮点是有多种骰子，一次投掷多个，可以保留一部分用在下个回合。地图很开放，刚开始玩有点不知道怎么下手，但也很值得挖掘不同玩法。这个游戏也是 Sokpop 出的，在 Itch 购买后会提供 Steam key，可以说是买一送一了。

其他

• 炉石

  女友一直很喜欢看我玩炉石，恰好炉石节奏比较休闲，也很适合左手操作，就在右臂恢复期间久违地玩了一阵子。或许是心态进步了，明显感觉比之前打的好了很多，5000 分后越打越顺手，动不动就连续第一名。最后在到达 6000 分时，趁着还没被吊打，带着已获得的乐趣急流勇退了。一些截图记录在了这串推文里。

• 风暴英雄

  有半年多没玩 HOTS 了，这次其实也没玩，只是听到了一个消息，风暴开发组宣布停止更新游戏内容，于是再次哀悼了我最喜欢的 MOBA 游戏。还看了职业选手 Grubby 的视频，一开始他强做平静，说着说着痛哭出声，作为5年游戏玩家的我也产生了感同身受的悲伤 ¹²。

  好在机核的这篇文章——有的游戏三岁就死了，直到七岁才埋：写在《风暴英雄》发布新公告后——冲淡了难过的情绪，里面还有一个让人忍俊不禁的比喻：

  大致想象一下，你有一位异地恋的女友。四年前，她打电话来告诉你说：“咱们就继续维持这种异地关系吧”。

  在随后的几年里，你们保持着电话联系，偶尔她会和你分享一下最近的趣事，包括她现在在干嘛，是不是毕业了，是不是工作了，是不是升职了？反正有一搭无一搭的还会说几句话。

  大约一年半以前你们通了最后一次电话，从此之后大概一两个月会发一发短信，无非也就是在干嘛，没什么，睡了，再见，有时候刷到几条你还可见的朋友圈，也能去点个赞。

  今天她突然告诉你说：咱们散了吧。作为笔者自己的话，我可能的回复也许是：合着还没分呐？

影视

老番

• 平稳世代的韦驮天们

  原本只是想补下去年的番，没想到成为我今年最喜欢的动画。反套路、快节奏的剧情，张力十足的战斗画面，MAPPA 在这部番中淋漓尽致地释放了他们业界顶尖的制作水准。唯一的遗憾是故事还未结束便戛然而止，也暂时看不到第二季制作的可能性。

• Devilman: Crybaby

  在看《平稳世代的韦驮天们》时联想到了恶魔人，便重看了这部汤浅政明 2018 年拍的老番。震撼依旧，但相比第一次观看注意到更多细节，有了更深刻的理解。许是内心的承受力这些年来有所提升，太郎吃妈妈那段情节我终于能面不改色地看下去，这才发现诺埃尔（太郎的爸爸）几次举枪又放下的镜头，对人性的刻画有多么深刻。真有你的汤浅，不愧是我最欣赏的动画导演之一。

• Burn the Witch

  很精彩的小品番，只有3集，令人意犹未尽。原作漫画的作者是久保带人，代表作是《死神》。在这个新人只会画异世界的时代，只有老一辈艺术家还在继续着纯粹的、不受约束的幻想。以及我再次感受到日本人「边境心态」的优点，不需要对英国的魔法和童话体系有多么深刻的理解，不用怕 Harry Potter 珠玉在前，想画什么就画什么完事了。这并不是对文化的源流缺少敬畏，恰恰相反，作者的心中其实并没有「我」的位置，「我」是一个边境人，没有政治立场或民族情绪。故能对所有的文化一视同仁，以纯粹的热爱，将「我」的认知糅合想象力，创造出新的世界。《来自深渊》和《宝石之国》在我看来也都是在这样的心态下才能创造出的，瑰丽奇幻的世界。（这两部的作者都是女性漫画家，究竟是巧合还是必然呢？）

• 黄金神威

  日俄战争历史背景，阿伊努人民族风俗，这两大元素让黄金神威在近年的番剧中显得如此特立独行。2018 年我在 B 站看完了第一季，后来因为 B 站下架一直没追。最近发现第四季都出了，遂下载，一口气补完三季。朋友说漫画版不容错过，得空一定要慢慢品鉴。

新番

• Lycoris Recoil

  挑不出毛病的 JK 战斗番，不挑观众，就是纯粹的好看，无论是老二次元还是普通观众，无论有什么口味偏好，都能得到极好的观看体验。角色设定上有个很有意思的地方，和《吊带袜天使》一样，都是一个黑人大叔带着两个会打枪的妹子维持世界和平，不知是巧合还是致敬 ¹³。

  关于这部番还有一则逸闻，知名游戏制作人小岛秀夫每周都会发推文记录自己的看番感受。 ¹⁴

• Call of the Night

  吸血鬼与少年的故事，梦回物语系列。第一话台词超棒，让我有找到同类的欣喜 ¹⁵：

  人为什么会熬夜 是因为有想看的节目？有想做的事？还是因为对明天感到不安？ 这全都起因于一件事 就是对今天不满足 来熬夜吧，熬到对今天满意为止

  另外这段脱衣服的镜头简直太赞了。

• 异世界归来的舅舅

  舅舅在异世界穿越了 17 年，回来后用魔法拍视频当 YouTuber，和主角回忆异世界生活的日常。总体来讲是部好看的番，有很多可圈可点的地方。首先是反套路设定，舅舅在异世界过的并不好，因此本番的笑点多数都有黑色幽默的气质。舅舅的人设是一个 SEGA 游戏机的死忠粉，游戏几乎就是他人生的全部，看的时候映照出一些自己的影子，对舅舅的傻里傻气感觉的很亲切。缺点则是女角色没什么意思，而且傲娇 + 直男梗看多了容易疲劳。

• 夏日重现

  夏日重现其实是4月新番，本季还在继续更新。如果要推荐国产剧观众来观看，我会说这是更加精彩的《开端》——虽然这个说法并不准确。

  在连续两季的更新中，夏日重现整体维持了比较平稳的质量，剧情也是越来越引人入胜。最近快要大结局了，每次我都是攒两集再看，只看一集简直百爪挠心。有次和朋友聊天提到夏日重现动画的真实感很强，朋友说那是你没有看过漫画，随后向我展示了一张男主在漫画中的表情，看到后我毫不犹豫的将其加入到了漫画待看列表中。

纪录片

• The Social Dilemma

  最早是 2 年前好友 @chiusx 向我推荐的，最近又重温一次 ¹⁶。这 2 年发生了许多事情，我们的生活越发依赖互联网公司所提供的服务。或许我们最终也无法摆脱作为数据商品被操纵的命运，至少也要尽可能多地了解真相，哪怕它是残酷的，也好过活在无知的快乐中。

• A Dream Cast

  因为《异世界归来的舅舅》而想起 SEGA 的游戏主机，便找到了这部纪录片。看完颇有感触。Dreamcast 最大的挫折就是在发售时被 PS2 狙击了。更低的售价，更高的附加值（DVD 播放器），索尼终于报了 PS1 和 Saturn 打价格战时的仇。但也怪世嘉自己不争气，在 PS2 发售前两年的时间窗口里没有推出杀手级的游戏单品和足够丰富的游戏阵容。任天堂一直以来就是在这一点做到极致，永远先有游戏，再配合推出硬件，发售的时候就是双拳出击，不给同行任何机会。但不是每个公司都是任天堂，世嘉已经尽力了。

  Dreamcast 承载着社长大川功先生做出极致主机的梦想，在那个时代造就了一系列拥有独立游戏精神的作品，并深深影响了业界的发展。这个梦想投射在了一代制作人和玩家的记忆里，that’s why it’s called a dream cast.

阅读

久居在家，促使我翻出遗忘许久的「泡面盖」重新使用。看的书不多，但是比以往都要仔细。

• 夜晚的潜水艇

  看到和菜头提及小说家陈春成，就去找了他的第一本书《夜晚的潜水艇》。它应该是十年来最打动我的文字和故事。作者的文笔非常独特，虽然没有华丽的词藻，但却有种将他对世界独一无二的感受传达给人的能力。作者年岁和我相近，把我们那一代人年幼时的懵懂、长大后的迷惘，种种最细微幽深的情结，全部重现在他天马行空的幻想故事中。

• 山月记

  这是日本作家中岛敦取材中国古代文学作品所编撰的故事集，大部分原著我都没有看过，因此读起来颇有趣味。最喜欢其中《悟净出世》和《悟净叹异》两篇，让我对沙僧甚至整个西游记都有了很多新的理解。

见闻

• 看到名为「人间观察」的频道主 Hayami 关于「男的」的言论，感到过于好笑，就发推抨击了一下。

• 某天晚上在小区人行道上发现一只踽踽爬行的小蝉，把它放到了路边的草丛，免得被路人踩到。回忆起童年时光，夏夜可以在树上找到它们，动作笨笨的很听话，捉回家放到花盆里，等它们第二天表演金蝉脱壳。 ¹⁷

• 因为感受到买药的麻烦，我发出了「你最好不要生病」的感叹 ¹⁸，谁知没过几天就应验了：女友用美团外卖购买了午时茶（一种消食冲剂），我们谁也没意识到这个药会和疫情风控有关，第二天她就因买药后 24 小时内没做核酸而被赋为黄码，不得不去附近的医院按照规定流程重新检测。

• 在天桥上散步时，偶遇在杭州见过最美的黄昏。

  

• 看了《回村三天，二舅治好了我的精神内耗》这个视频，鉴定为新时代精神毒品。当时写了点评价，之后整理下单独发一篇短文吧。

好奇心

• Retro Game Console & Android Box

  在 YouTube 上看到两个关于 Retro Game Console 的视频 ¹⁹，勾起了我对掌机运行 FC/GB/NES 模拟器玩老游戏的兴趣。以前购买过一个 GameShell，价格接近 Switch 了不说，手感还非常差，对比这次发现的新产品，个个既好看又实用，感觉真是亏爆。

  我便想，不如直接在电视盒子上安装 RetroArch，连接手柄就可以把电视变成复古游戏主机了。但在 Oppo 电视上直接安装没有成功，这时朋友向我推荐了 HK1，于是我又去研究 Android TV Box，找到一篇对比多个盒子的博文 安卓外贸电视盒子体验。在翻看作者的介绍时，发现了他的 GitHub 项目 jdhao/nvim-config，为我升级 nvim 配置提供了重要的参考，不禁感叹 “down the rabbit hole” 之奇妙。

• The Apple Store Time Machine

  在 Hacker News 发现这个网站，作者用 Unity 写了一个名叫 Shop Different 的「游戏」，以第一人称视角游览不同时期的 Apple Store。我在这座数字博物馆中流连忘返了一个晚上，还发现了之前未曾听过的 iBook 笔记本电脑 ²⁰。

• VLC & LibVLC

  过去一年我的主要观影工具是 Plex，时常会遇到一些视频无法播放的问题，开始我怀疑是 NAS 硬件的问题，经过仔细检查发现，大多数情况都是在串流 1080p 码率的原始视频文件时，客户端解码出错。于是我给电视的安卓系统安装了 VLC，测试发现同样的文件都可以播放，这才意识到是 Plex for Android TV 内置播放器的问题。

  但 VLC 毕竟不是完整的媒体服务器，使用体验还是差一些。为了解决这两个月大量的观影需求，我给 NAS 部署了 Jellyfin 并安装了其客户端，在客户端设置里发现了「首选播放器」选项，选择 LibVLC 后，大部分 Plex 不能播放的视频就都可以正常播放了，只剩少数顽固份子还是只能用 VLC 播放。经过这番折腾，我得出了解码能力 VLC > LibVLC > Plex 的结论。 ²¹

• 模块化机械键盘

  看了B站稚晖君的视频 【自制】我做了一把模块化机械键盘 !【软核】，好生羡慕他的动手能力，而且设计非常硬核，比某何同学不知高到哪里去了。这个键盘最让我感兴趣的是它的可拆卸的智能交互模块，它使用 无刷电机 实现了一个功能极其丰富的旋钮，不仅可以模拟不同程度的阻尼感，作为一个输入设备使用，还可以由软件控制其主动旋转，搭配侧边的屏幕作为仪表盘显示数据。

  说到无刷电机，就想到步进电机，之前在 B 站看过一位 up 主通过步进电机演奏音乐也给我留下了深刻的印象：【电机】来吧，甜蜜的死亡 / come on, sweet death - EVA剧场版OST

  DIY 硬件真的很有趣，希望以后我也能像稚晖君或 DIY Perks 那样创造属于自己的电子设备。

• Nota & iBar

  由于我主要使用 Obsidian 记录笔记，写博客自然也还是用它。写下十来篇后，逐渐感觉 Obsidian 写作体验并不是那么好。写作需要 distraction free 的环境，但 Obsidian 是个折腾插件的生产力工具，气氛不对；Obsidian 的编辑器中，图片会使段落高度经常发生变化，影响思考状态。最后，我发现笔记系统与博客写作是相互冲突的，笔记系统打开关闭文件的频率很高，而一篇文章的草稿可能要持续打开三五天之久；笔记的目的是将当下的想法快速记录下来，不像博客写作有文笔规范的要求。笔记最终会成为博客的素材，将它们分开在两个软件中似乎是更好的选择。

  于是我找到了 Nota，一个新的 Markdown 编辑器，它的前身是 Caret，作者是两位保加利亚的开发者。Nota 和 Typora 类似，都是所见即得的编辑器，但 Nota 有更好的文件浏览器，以及类似 Obsidian 的文件导航工具；与 Obsidian 相比，又少了许多不那么必要的功能，在简洁和强大之间找到了一个非常恰当的平衡点。总的来说，就是手感对了，我一下子就喜欢上了 Nota，决定开将它作为我的写作专门编辑器。本文是使用 Nota 创作的第一篇博客，截止此处文字，各方面体验都很让人满意。只有一个功能缺失，就是在粘贴图片时将图片存放在当前文件的相对路径上。我追踪了一个 Issue，希望它能尽快得到实现。

  iBar 是 Nota 作者的另一个产品，用来快速搜索浏览器历史记录。原本我只抱着随便试试的心态，使用后却发现相当不错，不仅 fuzzy 的准确性很高，搜索速度也不差。现在它已经是我日常工作流的一部分了，推荐给任何大量浏览网页的人。

学习

虽然身体不适并且只能单手打字，我还是设法学到一些新的知识和技能。

• PWA

  7月中旬受人之托要实现对一个手机 App 的模拟，我想到最快的方式是写一个符合 PWA ²² 标准的网页。经过研究，为网页增加了 Web app manifests，还根据 Apple 的标准添加了一些 Safari 特有的 meta tags，最终效果非常不错，达到了像素级还原 App 的体验，之后也写一篇文章来总结下。

• Vite

  在实现上文所讲的 PWA 网页时，由于没有复杂的交互，不需要用到 UI 框架，我想回归 vanilla web 的开发方式，即手写 HTML + CSS。手动刷新太麻烦，我还是需要一个能够自动刷新的 dev server。用 Webpack 显得没有必要，而且我也不够熟悉，不能短时间内完成配置。

  最终我发现 Vite 是最佳选择。一直以为 Vite 是 Vue 生态专属，没想到是通用的前端开发和构建工具，无论是开箱即用的流程，还是清晰的文档和 API 设计，都给我带来非常好的使用体验。²³

• Mantine 5.0

  我最喜欢的 React 组件库 Mantine 发布了 5.0，仔细看过 release note 后，发现还是有不少 breaking change 的。等再发几个 minor/patch 版本就对自己使用 Mantine 的项目进行全面更新。

• IELTS

  考 IELTS 是 6 月回家之后萌生的想法，一是想检测下自己的英语水平，二是可以给未来带来多一些选择。在把好友给我的一套真题完整做了一遍之后，发现自己与裸考通过还是有很大差距的，还是老老实实地背单词 + 做题吧。

  在对英语学习有了更多的重视之后，我整理了一些常用的词典文件 (mdx)，分享到了 Telegram 频道里: https://t.me/reorx_share/2040

What’s Next?

• 首先是重启之前的工作，原本我一直在开发一款 SaaS 产品，最近3个月却是全无进展。为了让工作进行得更有节奏，我会写下每日的 devlog，但可能没有时间润色并发布出来。
• 维护开源软件：我开发的 Obsidian 插件 Paste image rename 和 Hugo 主题 PaperModX 不知不觉也有了一些用户，这两个月也收到不少 issue。回复正常工作状态后，我会在周末抽时间去维护这些项目。
• 开始写 Newsletter：最近写的笔记很多，有一部分既符合同样的主题，也有分享的价值。因此我准备尝试写 Newsletter，我将其命名为 Maker’s Daily。这是一个面向创造者和开发者的通讯，1-3 日更新一篇，内容包含我对产品的思考、技术的探索、工具的使用，以及作为一个 Maker 的成长和反思。几乎每天都有与之相关的灵感涌出，所以不愁没素材可写，但我想尽量让文章短小精悍，来培养简洁写作的能力和习惯。
• 调整博客结构：在产品和技术创作之外，我也有许多关于这个世界的思考，写出来比推文长，又比一篇正式的博客要短。其实若只写长文，博客的更新频率必然不高，不利于持续输出。因此，我准备为博客增加一个新的栏目，名为 Essay，也就是短文，专门用于发表片段化的想法。

这篇文章断断续续写了3天，一共7小时50分钟。如果你能看到这里，真的很感谢你的阅读，希望我的这些琐事能给你带来一些有用的信息和启发。

我立刻理解了这个诉求的来源。咖啡馆、图书馆等场所的公共 Wi-Fi 一般都有身份验证机制，连接超过一个设备就会感觉很不方便，更不用说每个设备都还要独立设置代理；如果多人在一起工作，联机调试很可能会遇到公共 Wi-Fi 的端口限制而无法成功。我们对这个需求讨论了一番，但两人都缺乏对这类产品的认识，便不了了之。

最近在 Twitter 上看到 @酱紫表 分享了一款产品，突然意识到这可能正是我们想要的东西:

虽然没有提及这款名为 GL-AXT1800 的路由器是否可以连接已有 Wi-Fi，但既然设计的这么小巧便携，应该是针对出门在外的应用场景吧？我如此寻思，注意到它在 GL.iNet 的产品矩阵中属于 Travel Router 这一分类，于是顺着这个关键词进行了一番搜索，果然发现这类产品大都有着和我们的需求一致的应用场景。

我随后去阅读了 GL.iNet 的官方使用手册，弄清了 GL-AXT1800 所支持的四种连接互联网的模式：

• Connect to the Internet via an ethernet cable

  通过网线连接互联网。GL 的路由器都有一个 WAN 口，这种用法与通常的家用路由器一致，连接在光猫或已有路由器的后面。

• Connect to the Internet via an existing Wi-Fi

  通过已有 Wi-Fi 连接互联网。这就是本文一开始所提到的在咖啡馆中的使用场景，将公共 Wi-Fi 扩展成为相对安全可控的局域网。

  一些公共 Wi-Fi 要求对手机号/身份证等进行验证方可连接互联网，使用无线便携路由器是否会影响验证流程呢？我初步判断是不会，这种验证发生在连接 Wi-Fi 时的密码验证之后，此时无线便携路由器已完成了连接已有 Wi-Fi 并创建新的局域网的工作，假设公共 Wi-Fi 的 IP 是 192.168.1.1，无线便携路由器是 192.168.50.1，我们访问互联网触发的对 192.168.1.1 验证界面的访问是完全没有问题的，类似在家庭双层 NAT 环境下访问光猫的管理界面，DHCP 会处理好不同网段 IP 的访问关系。

• Connect to the Internet via usb tethering

  通过 USB-A 口连接手机，使用手机的移动网络连接互联网。这种模式需要打开手机的热点功能，使用有线以降低传输损耗。

• Connect to the Internet via usb modem

  通过 USB 调制解调器连接互联网。这种模式将只能插在笔记本电脑上的传统的无线上网卡变成可供多人使用的 Wi-Fi。

这些模式基本可以定义出 Travel Router——无线便携路由器的主要功能，读者可思考其中是否有符合自己需求的功能，从而对这种产品做出种草或拔草的判断。

同类产品介绍

说完了什么是无线便携路由器，我们再来看看有哪些可供选择的同类产品。

单板机 DIY

弄清楚产品功能之后，我发现家里被用作软路由¹ 的 NanoPi R2S 是可以成为无线便携路由器的，只不过还需要对系统和配件进行一些 DIY 配置。

一个未经雕琢的 R2S 长这样:

插上一个外置的无线扩展模块，它从结构上就与 GL-AXT1800 一般无二了:

Note 1: 不过这样使用也有局限，由于 R2S 只有一个 USB-A 口，当扩展为 Wi-Fi 天线后，就无法实现上文提到的 USB tethering/modem 模式了。

Note 2: 据推友 @q1ngyang 告知 ²，R2S 网卡方案有点麻烦，固件大多用不了无线网卡或无法驱动 AC，因此 R2S 不见得是最好的选择，若要使用 SBC 进行 DIY，还请读者在多方考察后慎重行事。

实际上树莓派等其他 SBC 也可以用同样的思路配置实现，不过我更喜欢 NanoPi 的外形和亲民的价格（去年好像涨价了），感兴趣的读者可以在淘宝认准 FriendlyElec 官方店购买。

固件方面，使用 OpenWrt 或其发行版即可，通过 Wi-Fi 连接互联网是 OpenWrt 的基础功能之一，官方文档对此有着非常详细的说明: Wi-Fi extender / repeater / bridge configuration.

纯硬件产品

GL-AXT1800 即属于此类，在硬件层面已经高度集成和完善，但固件、代理等还需用户自行配置。GL.iNet 系产品的优点之一是自带基于 OpenWrt 开发的固件 ³，功能足够强大，省去了自己刷的麻烦。

下面列举 GL.iNet 的其他几款 Travel Routers:

• GL-MT300N-V2

  昵称 Mango 芒果，有着鲜明的颜色和与 R2S 近似的小巧外形。电源输入是 5V/2A，相比 GL-AXT1800 的 5V/4A 对充电头更加友好。

  

• GL-AR300M

  黑色并升级了 CPU 的 GL-MT300N-V2。

  

• GL-USB150

  传统 U 盘的大小，可以直接插在充电器 USB-A 口上使用。

  

其他品牌中，TP-Link 有一款 TL-WR902AC 和 GL-MT300N-V2 类似，支持刷入 OpenWrt ⁴.

硬件 + 服务

推友 @BigEyeSmolMouth 向我分享了梅花VPN ⁵，使我得知有这类产品的存在。它们就像网易的 UU 加速盒，在硬件上内置了自己的网络代理服务，实现成软硬一体化的翻墙 Wi-Fi。

在我看来，这种产品优缺点都很明显。优点是开箱即用，省事不折腾；缺点是可控性差，无法更换代理提供商，且商品的溢价较高，其硬件性能不会有多少剩余空间。从安全的角度考虑，这样一个黑盒设备也无法让人信任。

官网的 spec 中没有关于 CPU、固件、协议等信息的描述。

相似但不同的产品

看过上文对无线便携路由器的介绍后，你是否有种似曾相识的感觉？没错，其实有一些与之类似但却不同的产品存在，平时没有用过也多少见过，这也是我在一开始未能准确把握自己想要什么产品的原因，它们都存在硬件或功能上的共性。下面我将针对两种可以明确定义出功能边界的设备进行阐述。

Wi-Fi 信号放大器

也有人将其称为「无线中继」，比较准确的英文名称应该是 Range Extender。这类产品的核心用途是接收已有 Wi-Fi 的信号，作为 AP 发射出相同的 SSID，以达到延长其信号范围的目的。一般用在家庭、办公室等空间较大、Wi-Fi 信号容易衰减的环境。

它和无线便携路由器在接收 Wi-Fi 信号这件事情上使用了相同的技术 WDS，但一个是扩展已有的 LAN，一个是创建新的 LAN，用途的差异使两者最终呈现出不同的产品形态。可以把 Wi-Fi 信号放大器看做特化的无线便携路由器。

TP-Link 有很多此类产品，它们的外形通常像耳朵长着天线的机器人🤖

随身 Wi-Fi

也叫「无线上网卡」，比较准确的英文名称应该是 Mobile Wi-Fi Router (or 4G Wi-Fi Router)。这类产品的目的是使用 3G/4G LTE 创建随时随地可供使用的 Wi-Fi。分为内置 eSIM 卡和依赖外部 SIM 卡两种。

国内的随身 Wi-Fi 一般都是内置 eSIM 卡的，外形像 U 盘或充电宝，在设计上并没有提供多少可定制性，但由于其普及程度非常高，广大 DIY 爱好者早已将其研究通透。@酱紫表 分享过一篇 4g 随身 Wi-Fi 刷 openwrt 变成软路由 教程，成品展示在这条推文中。

其实在刷上 OpenWrt 后，随身 Wi-Fi 就等同于上文中 Connect to the Internet via cellular 模式下的 GL.iNet，因此它同样可以看做无线便携路由器的特化版。

Netgear 的 MR1100 则是插卡的，黑色金属质地体现出服务器特有的冷酷和科技感，还有着让我无法抗拒的数据指示屏。

另一款值得一提的产品是 GL.iNet 的 GL-E750，它同时具备无线便携路由器和随身 Wi-Fi 的功能，并且可以通过内置的 7000mAh 供电，相当于 GL-MT300N-V2 + 上网卡 + 充电宝的 all-in-one 组合。在咖啡馆可以连接公共 Wi-Fi 并接线充电，在户外则可以使用移动网络不依赖电源，简直是理想中的产品。但一般来说，越是什么都会，越可能什么都不精，GL-E750 具体表现如何，只有真正入手使用后才能知道。

结语

在移动办公越来越广泛的今天，无论你是时常出差办公的技术工作者，还是四海为家的数字游民，无线便携路由器都是值得了解和尝试的产品。数据和隐私是无价的，当连接到公共 Wi-Fi 时，我们的设备便存在被攻击和窃取数据的风险，而通过无线便携路由器，我们可以在一个可控的局域网中管理设备、增加防护，获得更安全的办公环境和更高效的生产力。

本文仅对一些无线便携路由器做了简单的列举，不涉及传输和加密性能的测评，由于我还没有实际使用过，因此无法对这些产品的好坏做出评价，读者将本文当做科普知识的分享即可。在未来我会补充一篇实际的产品使用体验，如果你使用过这一类产品，欢迎在评论区或 Twitter 分享你的经验。

Revision

• 2022-06-30: created
• 2022-07-02: add GL-E750
• 2022-07-09: update R2S notes
• 2022-07-10: 添加关于「使用无线便携路由器是否会影响公共 Wi-Fi 手机号验证流程」的描述

博客建成也有一段时日了，渐渐也会收到一些读者的评论，在和大家交流中学到了很多新的知识，我很喜欢这种感觉，把评论看做我和读者之间重要的交流渠道。有一天我收到了 @geekdada 在 搭建 umami … 下的留言:

非常感谢推荐。不知道作者有没有想把 Disqus 换掉，又臃肿又收集数据。

于是我开始留意起 Disqus 的使用体验。其实我在 2013 年就注册了 Disqus，用在了自己最早的一版个人网站上，对它也算是有些感情，这也是一开始快速实现时选择它的原因。

我打开 Chrome Dev Tools，刷新文章页，果然看见一大堆请求，一共有 94 次，这可太恶心了！且不论它收集了哪些统计数据和用户隐私，光是数量之多就让有代码洁癖的我无法忍受。

再试探性地关掉 ublock，这下更不得了，显示出有半个屏幕之大的广告区域，充斥着猎奇的图片和 clickbait 标题的链接。去设置页看了下，果然只有付费用户才可以关闭广告，但接连被恶心到，我已经彻底决定抛弃 Disqus。

就像之前从 Google analytics 换到 umami 那样，我踏上了寻找新的评论系统的旅程。

评论系统的选择

经过一番调查，我大致将评论系统分为了如下几类，每类都放上我认为最好的几种可选项，为同样带着自己的需求寻找评论系统的读者提供参考。

• Full-fledged

  全功能的评论系统，从前端的 UI 组件到后端的 API、数据存储都完整实现。其下又分为 SaaS 和 Self-hosted 两类。

  • SaaS

    Disqus 就是属于这一类产品，优点是配置便捷，不用操心；缺点则是可能会收集隐私数据，缺乏可控性，并且价格都比较贵。

    • Commento: 目前是我最喜欢的一个 SaaS 评论系统，界面简洁清爽，能适应大部分博客的主题样式，无广告和追踪。价格为每月 $10。
    • CommentBox: 我很早收藏过的一个评论系统，和 Commento 一样的 slogan 和价格，就是功能和设计看起来要弱一些。

  • Self-hosted

    与一般的互联网服务不同，评论系统中 Self-hosted 的比例反而比 SaaS 化的大很多，这大概是因为自建博客的市场比较小众，且使用者也多为喜欢造轮子的程序员。Self-hosted 虽然较为麻烦，但优势也非常明显——由开源带来的高可控性、高定制性，并且近年来 PaaS 平台的蓬勃发展大大降低了部署成本，不需要拥有服务器便可一条龙 0 元购搭建起来。因此如果你有一定的技术基础，非常建议尝试自部署一套评论系统。

    • Remark42: 我最喜欢的一个 self-hosted 评论系统，也是本文接下来所要讲解的对象。
    • Isso: 使用 Python 开发，数据库为 SQLite。界面复古而简洁，适合 minimalist。Isso 可以配置评论自动通过，或者先审核再通过。
    • Cusdis: 我很佩服的开发者 Randy 的作品，也是使用 SQLite 作为数据库，就像是 Isso 的 Nodejs 翻版，但界面更加美观。与 Isso 不同的是，Cusdis 要求评论必须通过人工审核才可以显示，提供了 Email 和 Dashboard 两种审核方式。
    • Commento: SaaS Commento 的开源版，使用 Go 开发，支持各种 social auth 登录，甚至可以配置 SSO。但这个项目已经停止更新一年多了，如果你有兴趣，可以考虑使用社区 fork 维护的 Commento++，作者的更新还挺活跃的。
    • Twikoo, Artalk, Valine: 三者都是面向国内用户所开发的评论系统，有很多相似之处，因此放在一起介绍。与上述其他项目不同的是，三者的接入方式并非 iframe，而是直接操作网页的 DOM 元素。
      • Twikoo 主要支持腾讯云 CloudBase，也可以部署到 Vercel。数据库是 MongoDB。更新比较活跃。
      • Artalk 使用 Go 开发，无部署环境限制，支持常见的 RDBMS。更新近期较为活跃。 Artalk 的作者 qwqcode 去年高考步入大学，开发 Artalk 的时候刚上高一。在三年里独立完成 Artalk 从 PHP 向 Go 的架构转变，TypeScript 也写的贼溜，现在的年轻人真是越来越强了。
      • Valine 似乎只支持 LeanCloud 部署，已经很久没有更新了。

• Proxied

  类似 full-fledged，有自己实现的 UI 和 API，但数据存储依托于一个已有的其他服务。我个人并不偏爱此类应用，一者登录方式被限制在其所依托的服务上，再者数据也不好维护。

  • utterances: 应该是最早的基于 GitHub 的评论系统，提供了一个用于接入评论的公开服务。
  • giscus: utterances 的 fork 版，增加了自部署的能力。

• IM Plugin

  由即时通讯服务提供的插件。这是个顺理成章的思路，对于即时通许服务商来说，可以利用已有的基础设施提供更多的 user engagement，何乐而不为呢。其中最为知名的当属 Facebook，Google 曾经也有，但和 Google Plus 一同被埋葬了。这种评论系统也存在登录方式单一的问题，请谨慎选择。

  • Comments.app: Telegram 提供的网站评论插件，使用简便，界面美观，支持 dark mode 和 accent color。
  • Discussion Widget: 同样是 Telegram 的服务，但与 Comments.app 的不同在于，Discussion Widget 原本的设计目的是将 Channel 消息中的评论嵌入到网页中，但我发现这同样是一种评论系统，并且多出了将评论对应到 Channel 消息的功能。我在探索中已经顺便将 Discussion Widget 实现到了博客主题中，你可以在这个页面中预览和尝试: Commenting System: Telegram Widget
  • Meta Comments Plugin: Meta (Facebook) 的评论插件，我的社交圈里基本没人使用 Facebook，因此不予评价。

• Static

  静态评论，即评论作为静态网站原始数据的一部分，跟随网站的构建流程生成到页面中。不同于其他评论系统可以灵活嵌入到任何页面，静态评论只能用于静态网站中。评论的数据是否应该属于网站本身呢？这是一个非常两极分化的问题。

  • Welcomments: 静态评论 SaaS 服务，需要用户绑定自己网站的 GitHub 仓库。当有人评论时，Welcomments 会生成一个 commit 包含评论的数据提交到仓库中，触发 GitHub 的自动构建流程，将评论更新到静态网页中。Welcomments 支持在它的网站上进行评论审核，还接入了 Akismet anti-spam 服务，每月 $6，年付减为 $4。
  • Staticman: 更为强大的 Welcomments，并且是 self-hosted。Staticman 支持更多的代码托管平台，并且可以通过 pull-request 的方式审核评论，这才是基于 Git 的工作流应有的样子。但 Staticman 已经有 2 年没更新了，在进行更深入的调研之前，不建议作为第一选择。
  • 手动维护: 任何手动维护评论的方式。有的博主会在网站会留下邮箱、即时通讯号等联系方式，让读者将想要评论的内容发送过去，然后将评论内容手动更新到文章的评论区。这种方式虽然简陋，但也不失为一种最简单的实现手段，毕竟评论的本质就是交流。

我的选择: Remark42

基于如下这些原因，我在众多评论系统中选择了 Remark42。

技术层面

• 它使用 Go 语言实现，我很难抗拒二进制单文件的诱惑。
• 它使用基于文件的数据库。我最喜欢的数据库是 SQLite，单文件无任何依赖，Remark42 使用的 boltdb 也是基于文件，对我来说和 SQLite 一样美好。
• 它有较为现代化的前端技术栈，使用 TypeScript, Preact, Postcss 开发。
• 它是一个成熟的开源项目，文档全面、开发时间长，基本上我的任何问题都可以在文档和 Issues 中找到解答。
• 它的 API 非常完善，比如导入导出都可以用一行 curl 来完成。在其他方面作者也显示出很高的技术品味。

视觉层面

Remark42 界面简洁美观，虽然比 Isso 和 Cusdis 复杂，但依然保持了足够的适应性和可塑性。

功能层面

我其实不喜欢 pre-moderation，即评论必须先通过审核才可以显示，这会给我带来额外的工作量，并且评论者也没法得到即时的效果反馈。但我也不想开放无审核的匿名评论，给自己带来被评论机器人攻击的风险。

我想到的折中方案是，首先提供尽可能多的 social auth 登录方式，比如 Twitter, Google, GitHub，这些 Remark42 都支持；再提供一种基于邮箱的认证方式，这是 Remark42 最大的亮点——Passwordless Authentication。评论者输入邮箱，点击 login，Remark42 会向其发送一个含有 token 的邮件，评论者使用这个 token 完成登入便可以进行评论。

邮箱认证是我个人最喜欢的登录方式，因为社交账号登录总是会存在风险，服务会拿到可以访问用户数据的 access token，你不知道它会做些什么 ¹。而邮箱不存在用户数据，唯一的担忧是被 spam 骚扰，但有很多匿名邮箱和邮件转发服务帮助我们解决这个问题。使用邮箱登录进行的评论，在被回复后也会发送邮件提醒评论者，确保了双向沟通的流畅性²。

Remark42 还有一个特别的地方，它没有 Admin 界面，或者 Dashboard，这得益于其清晰的设计理念和完善的功能实现。一般对于评论系统来说，Admin 主要用于查看和审核评论，但 Remark42 不需要审核，而对评论和评论者的操作（隐藏、删除、屏蔽）都集成在评论控件中。加上 API 简单易用，去掉 Admin 不仅没有让人感到不便，反而成为一个值得一提的 feature 了。

最后，Remark42 在设计上就支持 multi-site，只需要部署一个实例，便可以为多个不同域名的站点提供评论服务。

隐私层面

Remark42 的标语是「Privacy-focused lightweight commenting engine」，而它的确在隐私这件事情上做了许多事情。无追踪和广告自不必说，尽可能少的申请 OAuth 权限也只是基操，Remark42 还对用户数据做了这些考虑：

Users can request all information Remark42 knows about them and receive the export in the gz file.

用户可将自己在一个 Remark42 服务中的所有评论数据导出，多希望我高中时使用的百度空间也有这个功能。

Supports complete cleanup of all information related to user’s activity by user’s “deleteme” request.

用户可以通过 “deleteme” 请求将所有与自己相关的数据全部清除，类似近年来用户呼吁各大网站去支持的 opt-out ³。

小结

Remark42 还有许多功能，比如评论的 RSS 输出、Telegram 通知接入、Webhook 等等，限于本文篇幅，就不做展开了。下一篇博客我会对如何在 Fly.io 部署 Remark42、自定义 UI、接入 CDN 等内容进行详细的讲解，让读者也可以快速搭建自己的 Remark42 实例，敬请期待。

前言

赛博空间构成了我的精神世界。

我的大脑从苏醒的那一刻开始渴求信息，大量新鲜的信息，它们比饮用水更早地进入我的身体。每天睁开眼睛，我做的第一件事情是拿起手机，逐个查看昨夜的消息提醒。起床之后，我会在马桶上浏览 RSS 阅读器和 Telegram 频道中的新闻，让思维复苏的过程伴随新知识的冲击。我已经习惯了如此，一边加载昨日的进展并思考今日的安排，一边点开链接，使用不同的工具进行阅读、收藏和记录。

一天之中的碎片时间，我也会不断地在 Twitter、RSS、Telegram 之间切换，这对我来说并不是信息焦虑，而是自然而然的生活习惯。在工作上，我也完全依赖于网络，在解决问题的过程中搜索阅读大量的网站，将之转化为代码和学习笔记。

我就像一台不停运行的收集器和过滤器，持续地消费、生产信息。但大脑被设计用于分析和联想，却不擅长高效精确的索引，这些信息散落在各个服务中，我可以想起一些关键词或模糊的上下文，但总是很难快速获取到。我需要一个能将它们聚合在一起的工具，或者工作流，这样既可以方便自己的回溯，也可以将这些经过提纯的信息分享出来，为和我兴趣接近的人提供另一个输入管道。

聚合什么信息？

不是所有在赛博空间产生的信息都需要被聚合。一些被动产生的如搜索记录、地理位置记录、个人健康信息等，他们可以用作 quantified self（这是另一个话题），但并不在我的考虑范畴内。

我要聚合的主要有两类信息，一类是是由我主动创造的，比如Twitter 上发表的看法、GitHub 上为开源项目提交的问题；一类是我主动收藏或标记的，Pinboard 上收藏的书签、YouTube 上点赞过的视频均属此列。它们有的直接流入我的知识库¹，有的保存在线上服务中，作为知识的原材料储备，留待日后进行消化吸收。

考虑到分享的目的，这些信息中还要去掉功能性的部分，只保留我确认有价值的那些。比如 Twitter Like 有时会用于社交目的，作为一种赞赏的回应；YouTube, Spotify 中各种 playlist 很多只是为了满足收集癖，不一定具有普适性；豆瓣的想看、想读只是待确认的 enqueue，只有看过、读过才是值得推荐的。

内容来源

基于以上考虑，我将自己主要摄入和产生信息的来源进行了整理，得到如下列表：

• Telegram

  我在 Telegram 中分享一些一闪而过的想法、菜谱，转发浏览其他频道时看到特别有意思的内容。

  • Fleeting thoughts 💭
  • Recipe 🍳
  • Forward 🔄

• Twitter 🐦

  我的所有 Tweet 和 Retweet 都经过认真思考，是希望被阅读的内容创作。

  • Tweet
  • Retweet

• Instapaper 📖

  我这样管理我的待看列表：对于没确认是否有价值的那些，我会加入 TODO 或 Telegram Saved Messages。只有当我认真阅读过并认为值得再次阅读，我才会将其加入 Instapaper 中。

• Blog 📝

  我的个人博客，通过 RSS 发布更新。

• Music 🎵

  我主要使用 Spotify 听歌，类似 Instapaper，只有我愿意反复听的歌曲才会加入 Liked Songs，可以看做是我基于个人音乐品味的推荐。

  • Spotify

• YouTube ▶️

  YouTube 是我探索世界无限可能性的地方，it’s about everything and nothing。每个 Like 过的视频都有着让我会心一笑或拍案叫绝的亮点。

• Bookmark 🔖

  我从 2013 年开始使用 Pinboard，虽然 Pinboard 的社交属性很弱，但我一直坚持用 private/public 属性来区分我的收藏，所有 public 的书签都具备一定的分享价值。

  • Pinboard

• GitHub

  由于对 Pinboard 的重度使用，大部分 GitHub 项目都收藏在 Pinboard 中，Star 的是我觉得值得鼓励的项目。每个 Issue 和 Pull-request 我都有认真撰写，他们是我参与开源活动的记录。

  • Star 🌟
  • Issue ⚡️
  • Pull-request ⤴️

• Douban

  我主要用 Douban 记录看过的电影和书。如上文所说，这里只分享在看、看过的电影和在读、读过的书籍。后续考虑对评分进行过滤。

  • Movie 📺
  • Book 📖

展现形式

我选择 Telegram Channel 作为信息聚合的目的地。一方面我许多信息都来源于 Telegram ，另一方面它也非常易于使用和接入。

Telegram 以下几种功能极大程度地丰富了信息的展现形式²：

• 链接预览

  Telegram 会将消息中附带的链接进行抓取，将摘要和图片显示在消息下方。

• 富文本格式

  Telegram 消息支持 Markdown 和 HTML 两种富文本格式的解析，可以实现粗体、斜体、下划线、超链接、行内和块级代码等样式。

• 标签索引

  Telegram 的消息支持 # 为前缀的标签，在频道/群组内点击标签即可对消息进行筛选，这让结构化的信息索引成为可能。

实现自动化同步

我使用 n8n 来实现整套信息收集和聚合的自动化工作流³。下面将对我的操作方法和配置进行讲解，参照这些说明，你也可以快速搭建一套属于自己的自动化信息分享系统。

n8n 概念说明

• workflow

  用于定义一条自动化工作流，由多个 node 以及 node 之间的指向关系构成。

• node

  构成 workflow 的基本单位，每个 node 可以完成一个独立的任务，比如定时触发、获取数据、筛选数据、发送信息等。

• credential

  访问凭据，用于在访问在线服务接口时进行身份验证。workflow 内只存储 credential 的 id，只有在运行时才会获取其中的实际内容，这一机制确保了 workflow 在分享时不会造成凭据泄露。

安装 n8n

n8n 支持使用 Docker 进行自部署，它由 Nodejs 开发，使用 SQLite 作为数据库，没有其他外部依赖，因此理论上可以部署在任何 Docker 或 Nodejs 运行环境。

为了方便调试，我将 n8n 部署在家里的 NAS 上，你也可以尝试将其部署在 Railway 等 PaaS 平台。

正常情况下，参照 n8n 的 Docker Installation 文档即可完成初步运行。但在使用中，我发现了 n8n Twitter 接入的 bug，在对代码进行了修改后，不得不在本地构建 Docker 镜像 (见 n8n - Custom Image)。如果你需要使用 Twitter 接入，在这个 PR 合并之前，建议使用我构建好的镜像 reorx/n8n-custom。

version: '3'
services:
  n8n:
    #image: n8nio/n8n
    image: n8n-custom
    ports:
      - 5678:5678
    volumes:
      - /share/CACHEDEV2_DATA/Misc/AppData/n8n:/home/node/.n8n
      - /share/CACHEDEV1_DATA/homes/reorx/Misc_Backup/:/backup
    environment:
      - PUID=1000
      - PGID=1000
      - VUE_APP_URL_BASE_API=http://harrogath-local.com:5678/
      - WEBHOOK_URL=http://harrogath-local.com:5678/
      - GENERIC_TIMEZONE=Asia/Shanghai
      - TZ=Asia/Shanghai
      - N8N_LOG_LEVEL=verbose
    restart: unless-stopped

由于许多服务需要通过 OAuth 进行接入，我们运行的 n8n 需要有一个固定的访问地址，以便接收 OAuth callback url 的访问。我的做法是在局域网内将 harrogath-local.com 这个域名指向 n8n 所在的机器，并为 n8n 设置如下环境变量，使其显示的 OAuth callback 与域名一致。

VUE_APP_URL_BASE_API=http://harrogath-local.com:5678/
WEBHOOK_URL=http://harrogath-local.com:5678/

启动完成后，即可通过 http://harrogath-local.com:5678/ 访问 n8n 的 web 界面了。

创建 Workflows

我的每个 workflow 都分享到了 GitHub reorx/n8n-workflows 仓库中，通过复制 .json 文件的内容、粘贴在 n8n 的 workflow 编辑界面，即可对 workflow 进行复用。也可以使用 n8n 的命令直接将 workflow 导入到 n8n 的数据库中 (见文档 Import workflows and credentials)。注意无论使用何种方式导入，credentials 都需要重新配置。

New tweet to telegram

Link: n8n-workflows/workflows/new tweet to tg.json

这一 workflow 实现了每 5 分钟搜索一次我的 Twitter 时间线，将最新的 tweets 发送到 Telegram Channel。

第一个 node 是 Interval，它是一个 trigger，可以设置重复运行的间隔时长。

随后是 Twitter node，它通过 OAuth 连接了我的账户，使用 from:novoreorx 搜索语法来获取我最近的推文条目。

IF reply to other 是一个 IF node，通过条目中的 in_reply_to_screen_name 字段判断推文是否是对别人的回复，只有否才可以走向下一步。意味着只有单独创建或回复自己的推文才会被转发。

Set Retweeted node 根据条目中的 retweeted_status 字段，识别 retweet 条目，并将原推的 URL 拼凑出来，赋值给新的字段 retweeted 和 retweetedUrl，以便后续使用。

2022-08-12 updated:

Set Retweeted node 在后续的维护中打开了 “Keep Only Set” 选项，只保留其中所定义的字段，实际作用已经与名称不符，称为 “Set properties” 更准确一些。

新增了 proxyUrl 字段，使用 vxTwitter 服务的域名 vxtwitter.com 替代 twitter.com，以在 Telegram 中有更好的预览效果

Function 是我写的一段 JavaScript 代码，它使用了 n8n runtime 内置的 getWorkflowStaticData 函数，记录每次更新的第一个条目 lastItemId，通过与上一次的记录进行对比，确保只有新的条目会被输送到下一个 node 执行。如果没有 lastItemId，则只返回第一个条目，避免冷启动时造成大量信息的无效转发。这段代码基本在每个 workflow 中都有用到，下面将不再赘述。

/* only return new items */
const staticData = getWorkflowStaticData('global');
const lastItemId = staticData.lastItemId;

console.log('lastItemId', lastItemId);
const firstItem = items[0];
let newItems = [];

function getId(item) {
  return item.json.id;
}

if (lastItemId) {
  for (const item of items) {
    if (getId(item) === lastItemId) {
      break;
    }
    newItems.push(item)
  }
} else {
  newItems = [firstItem]
}

staticData.lastItemId = getId(firstItem)
// Reverse the order so that items are sent from old to new
return newItems.reverse()

经过 Function 的处理后，有效条目会被送往 Telegram node，进行 message 组装，最终发送到频道。

n8n 的表达式 (Expression) 有一个可以预览的编辑界面，左侧会展示当前 node 从上一个 node 获取到的输入数据 (Input Data)，点击即可将模板变量插入到 Expression 中。模板语法 {{ }} 中可以使用 JavaScript 语法，这里我通过 $json["retweeted"] 来决定 tag 为 #retweet 还是 #tweet。推文 URL 放在了 <a> 标签中，既可以触发 Telegram 的 link preview 功能，也避免展示太长的 URL 影响可读性。

2022-08-12 updated:

Twitter 的 search API 默认会将长推文截断，只有加了 tweet_mode=extended 参数才能确保显示全文，不过推文内容字段会从 tweet 变为 full_text。按下图所示添加参数后，请在 “Set Retweeted” node 中修改字段映射 text → tweet 为 full_text → tweet。

Blog RSS to telegram

Link: n8n-workflows/workflows/blog rss to tg.json

从第二个 workflow 开始，我将只对大致逻辑进行说明，不再详细讲解每个 node 的实现方式，有兴趣的读者可以在 workflow 编辑器中自行查看。

这一 workflow 实现了每 10 分钟检查一次博客的 RSS，将最新的文章发送到 Telegram Channel。

RSS Feed Read node 填写了博客的 RSS 地址，Function 同样是实现了有状态的更新判断，唯一的不同是将 getId 函数改为从 item.json.guid 获取 item id。

Spotify like to telegram

Link: n8n-workflows/workflows/spotify likes to tg.json

这一 workflow 实现了每 1 小时检查一次 Spotify Liked Tracks，将最新的歌曲发送到 Telegram Channel。

YouTube like to telegram

Link: n8n-workflows/workflows/youtube like to tg.json

这一 workflow 实现了每 30 分钟检查一次 YouTube Liked Playlist，将最新的视频发送到 Telegram Channel。

这里需要注意的是，Liked 是一个内置的 playlist，因此其 ID 与自己创建的不一样，通过访问 YouTube get playlists API，得到其 ID 为 LL，顺利完成了这一 node 的配置。

Pinboard new bookmark to telegram

Link: n8n-workflows/workflows/pinboard to tg.json

这一 workflow 实现了每 5 分钟检查一次 Pinboard 最近的书签，将最新的书签发送到 Telegram Channel。

n8n 没有 Pinboard 支持，但我们可以通过 HTTP Request 直接访问 Pinboard 的接口。古怪的是 Pinboard 没有官方的 API 文档，于是我对一些开源的 Pinboard SDK 代码进行阅读，得到了我所需要的接口 https://api.pinboard.in/v1/posts/recent。

Pinboard 接口返回的数据并不直接是一个列表，而是一个形如 {"posts": [...]} 的结构，这里用了 Item Lists 将 posts 字段提取出来作为 items 向后传递。

GitHub activities to telegram

Link: n8n-workflows/workflows/github activities to tg.json

这一 workflow 实现了每 10 分钟检查一次 GitHub 的动态，筛选出 star, pull-request 和 issue 发送到 Telegram Channel。

GitHub 可以通过 https://github.com/$username.atom 获取用户公开的动态信息，因此不需要复杂的 API 接入，直接使用 RSS Feed Read 即可获取到我们所需要的数据。

在 Function filter 中，我用正则为动态进行了分类，并组成最终所需的消息格式，代码如下:

/* filter items */
const newItems = [];

const regexes = {
  'star': /^reorx starred/,
  'pull-request': /^reorx opened a pull request/,
  'issue': /^reorx opened an issue/,
}
const tagSymbols = {
  'star': '🌟',
  'pull-request': '⤴️',
  'issue': '⚡️'
}

for (const item of items) {
  const title = item.json.title
  let tag = ''

  for (const key in regexes) {
    const regex = regexes[key]
    if (regex.test(title)) {
      tag = key
      break
    }
  }
  if (tag !== '') {
    item.json.tag = tag
    item.json.tgTitle = `${tagSymbols[tag]} ${title.replace(/^reorx /, '')} #github #${tag}`
    item.json.guid = item.json.id
    newItems.push(item)
  }
}
return newItems

这个 workflow 还有一个使用 GitHub API 的版本，但 RSS 可以获得所有动态，更加方便，最终胜出。

Link: n8n-workflows/workflows/github issues to tg.json

Douban activities to telegram

Link: n8n-workflows/workflows/douban activities to tg.json

这一 workflow 实现了每 10 分钟检查一次 Douban 的动态，筛选出看过、在看、读过、在读发送到 Telegram Channel。

Douban 也有一个隐藏的 RSS 订阅源 https://www.douban.com/feed/people/$username/interests，包含书影音的所有动态。

Function filter 与上一个 workflow 类似，这里做了一些优化，将正则和符号定义在一个 object 中。

const SYMBOL_MOVIE = '📺'
const SYMBOL_BOOK = '📖'

const tagInfoMap = {
  watched: { re: /看过/, symbol: SYMBOL_MOVIE },
  watching: { re: /在看/, symbol: SYMBOL_MOVIE },
  read: { re: /读过/, symbol: SYMBOL_BOOK },
  reading: { re: /在读/, symbol: SYMBOL_BOOK },
}

异常通知

n8n 作为一个自动化服务，在配置完成后，一般我们不会去主动查看系统的运行情况，因此需要有监控手段得知异常的发生，以便及时维护。

n8n 支持通过 Error Trigger 创建 Error Workflow，用于接收其他 workflow 的错误信息。这一步虽然不是必须，但我强烈建议创建一个全局的 Error Workflow，并在每个 workflow 的 Settings 中设置错误处理指向它。

我在 n8n-workflows/workflows/ERROR TO TG.json 中实现了将错误信息发送到 Telegram Group 的功能，效果如下。

使用 SaaS 自动化服务

对于一些 n8n 尚不支持，或配置比较麻烦的服务，也可以通过 SaaS 服务来实现自动化。IFTTT 是一个不错的选择，它应该是最早被广泛使用的自动化服务，免费用户可以设置 5 个 applet (即 workflow)，同步间隔 1 小时。

下图是我在 IFTTT 中配置的 Instapaper 新文章推送到 Telegram 频道的 applet。

Integromat 曾是一个非常好用的 IFTTT alternative，有着现代化的交互界面，和更为灵活的定制功能，但后来 rebrand 成 make.com，变得非常难用，不仅加载速度缓慢，而且连 migration 都无法正常完成⁴。建议大家远离这个奇怪的公司。

结语

使用 n8n 的过程总体是非常顺畅的，虽然一开始就在 Twitter 上栽了跟头，好在我能看懂 Nodejs 代码，自己动手修复后一路坦途。

曾经我特别痴迷于自己实现工具、制造轮子，现有工具稍有不顺就要全盘抛弃，自己解决。后来我在 happy xiao 的忘记系统一文中看到 John Voorhees 的一段话，改变了我对使用工具的态度:

If there’s anything I’ve learned about productivity systems, it’s that the best one is the one that works for you. Approaching the problem is tricky, but my advice is to use an app first and adopt a system later. That way, you’ll have a better understanding of what your needs are before you dive in.

实现的结果才是最重要的，工具只是手段，不是目的。

这也让我对自己正在开发的产品有了更多的思考，它是一个用于信息前处理的工具，同样是为了解决信息的分散和封闭而做出的努力，我设想了很多功能要去开发，但哪些是核心需求，哪些有代替品，或者换个思路通过其他方式实现，则必须放在实际场景中去考虑，而不是凭自己作为开发者的喜欢来武断确定。

回到赛博空间这个话题，我一直觉得人类对电子设备的依赖是一个不可逆的过程，人脑与电脑的边界会逐渐模糊。这是当我们有了智慧、抛弃自然为我们提供的进化之路后，自己所选择的进化方式。正如 Ghost In The Shell 开篇所描绘的越来越近的未来：

企業のネットが星を被い、電子や光が駆け巡っても

国家や民族が消えてなくなるほど、情報化されていない近未来

而在这一天到来之前，我在精神上已经完成了自然人向 cyborg 的转变。

Revision

• 2022-05-26: created
• 2022-05-27: published
• 2022-05-28: fixed “Function” node script items order by adding .reverse() to return items
• 2022-08-12:
  • added notes about using tweet_mode=extended to avoid tweet text truncation
  • added notes about vxTwitter proxy url

An indie maker is an independent creator. They build projects with their own resources, often without funding, taking care of all aspects: development, design, marketing…

by What is an Indie Maker?

独立开发者有着两个特质，勇气和追求。放弃待遇优渥的工作，投身不确定的未来，是勇气；对已有的产品不满，用更高的标准要求打磨，则是追求。

我一直关注着一些独立开发者们，怀着敬意欣赏他们的作品，为他们的成就欢呼喝彩，从他们身上汲取勇气和追求的养分，让踏上同样道路的自己得到志同道合者的陪伴。这篇文章将我所知的独立开发者们列举出来¹，让更多的人能看到他们的经历和作品，获得启发。

如果看到本文的你也是一位独立开发者（或者认识某位），欢迎在评论和推文中分享你的经历和作品。

ZH

• Guyskk
  • Experiences
    • 自宅创业 - 开始
    • 自宅创业 - 两周近况和新产品
    • 自宅创业 - 创业三个月了
    • 自宅创业 - #13 创业半年回顾
    • 2021自宅创业10个月总结，我会再次挑战
  • Products
    • 蚁阅
• Tim Qian
  • Experiences
    • 我的透明创业实验
    • 2019 年 t9t.io 赚了多少钱
    • 我的一年独立开发经历
  • Products
    • Feeds Pub
    • chart.xkcd
    • star-history
• Tob
  • Experiences
    • 独立开发挑战:做一款产品,6个月之内实现月收入30,000元 | 电鸭
    • 从硅谷到北京再到东南亚，为自己而工作的306天 | 电鸭
  • Products
    • 21YunBox
• 染河
  • Experiences
    • 我为什么从字节跳动裸辞全职开发浏览器扩展
  • Products
    • Circle 阅读助手
• zy5a59
  • Experiences
    • 人生自由实验 - V2EX
    • 『独立开发』复盘一个“可能”月入过万的小项目 - V2EX
    • 我是张万里的个人空间_哔哩哔哩_bilibili
  • Products
    • 叶子书摘
• Hawstein
  • Experiences
    • 不上班的 613 天
    • Indie Hacker 笔记
  • Products
    • AlgoCasts 简明、轻松、易懂的算法教学视频

EN

• Michael Lynch
  • Experiences
    • Why I Quit Google to Work for Myself · mtlynch.io
    • My First Year as a Solo Developer
    • My Second Year as a Solo Developer
    • My Third Year as a Solo Developer
    • My Fourth Year as a Bootstrapped Founder
  • Products
    • The Modern, Open-Source KVM over IP | TinyPilot
    • Refactoring English
• Ben Stokes
  • Experiences
    • I Spent 2 years Launching Tiny Projects | Tiny Projects
    • I blew $720 on 100 notebooks from Alibaba and started a Paper Website business | Tiny Projects
    • Earlyname: Reserving Usernames on the Internet | Tiny Projects
  • Products
    • Tiny Projects
    • Paper Website: Start a tiny website from your notebook
    • Earlyname | Get Your Username Before Anyone Else
• @levelsio
  • Experiences
    • How I built Nomad Jobs, a remote job board for 100% distributed startups
    • I’m Launching 12 Startups in 12 Months
    • How I got my startup to #1 on both Product Hunt and Hacker News by accident
  • Products
    • Nomad List - Best Places to Live for Digital Nomads
    • Remote Jobs in Programming, Design, Sales and more #OpenSalaries
• @damengchen
  • Experiences
    • One year of indie hacking, I’ve learned a lot!
  • Products
    • Testimonial - Collect and embed testimonials in minutes
    • Embed.so - The video hosting platform for your business
    • Supportman - Intercom Metrics & Ratings in Slack
• Tony Dinh
  • Experiences
    • After 7 years working as a dev, I quit my job to pursue my dream: build software I love and make a living out of it.
    • Tony Dinh’s Newsletter | Revue
  • Products
    • Twitter Analytics & CRM - BlackMagic.so
    • DevUtils.app - All-in-one Toolbox for Developers
• Alyssa
  • Experiences
    • How I built a MacOS app and made $5000+ in a week | Women Make
    • The Serial Entrepreneur Newsletter by Alyssa X
  • Products
    • Omni - Bookmark, History, & Tab Manager - Chrome Web Store
    • Later - Save your Mac apps for later
• @SachinNeravath
  • Experiences
    • See twitter timeline
  • Products
    • ParityDeals - Price Smarter, Sell bigger!
    • Samay - Supercharge your focus and productivity.
    • lightGallery - Full featured javascript gallery for web and mobile.
    • http://tack.one (100% free)
• Thomas Sanlis
  • Experiences
    • When, Why and How I’ve changed my life
  • Products
    • Uneed, the best tools of the internet.
    • Griddely
• Jonnie Hallman
  • Products Cushion
  • Experiences
    • Cushion Journal - Launch
    • Cushion Journal - Funding Cushion
    • …all in https://destroytoday.com/blog/categories/cushion

一些链接

本文不打算整理对如何成为一个独立开发者的建议或工具（以后有机会可以做下分享²），如果你看到这里感到意犹未尽，想了解更多关于独立开发的事情，可以对下面的链接进行探索。

• What is an Indie Maker?
• Ask HN: Those making $500/month on side projects in 2021 – Show and tell | Hacker News
• mezod/awesome-indie: Resources for independent developers to make money
• Indie Hackers: Work Together to Build Profitable Online Businesses
• 独立 | 中国独立 iOS 和 macOS 开发者图鉴
• MicroAcquire, the #1 Startup Acquisition Marketplace

Revision

• 2022-05-22: created
• 2022-08-11: added Hawstein in ZH

我的设想是为博客创建一个新的路径 /weekly，当我在这个路径下发布文章，比如 /weekly/2022W20/，就触发 GitHub Actions 的 CI 任务，将文章的 HTML 通过 Newsletter 服务商的接口发送出去。

带着这个目的，我调研了市面上的一些服务，选定了 4 家进行对比。

“Send email via API” 一列表示是否可以通过 API 创建并发送邮件 (或叫 issue, broadcast，每家称呼不同)，这是我最关注的一个功能，其中只有 Buttondown 和 ConvertKit 支持，他们都是基于订阅者数量的收费模式。但每月 $9+ 的费用让我却步，我想写的是分享见闻和思考的 Weekly Newsletter，这种内容并不足以支撑起付费订阅的模式。我喜欢写作并乐意分享，但为此负担额外的费用就不大令人开心了，这也是为什么我特别感谢像 Cloudflare 这样为独立开发者考虑的公司¹。

经 EGOIST 提醒，Mailgun 的 API 有 mailing list 管理功能，同样可以实现 Newletter 所需的订阅者管理和群发。实际上 Newsletter 的本质就是 mailing list，之前我潜意识里觉得 Mailgun, SES 这些服务只是 SMTP 协议的接口化，忽略了他们其实有一些面向邮件订阅服务开发者的高级功能。

竹白

由于订阅了 Shyrism.News 和 落日间，我得知了竹白这个国内的 Newsletter 发布平台。我很喜欢它简单易用的特性和清晰可读的设计风格，甚至让我这个只相信本地编辑器的人也有了在网页上创作的冲动。

这改变了我的想法，我开始思考，基于 Newsletter 平台去管理文章和发布，再使用静态网站生成器来构建网站是否是可行的。

如果以这种架构为目标，竹白还缺少一些东西，一个更为理想的竹白应该是这样的：

• 一个内容管理和发布平台

  Newsletter 平台首先其实是一个标准的 CMS

• 一个 Newsletter 管理后台

  管理订阅者，收集和展示统计数据

• 一个付费平台

  支持接收用户的 donation；支持付费订阅

• 提供 email subscrible API

  这个接口用于在个人网站上创建订阅表单，类似于 Formspree 和 FieldGoal，通过 HTML 的 <form> 标签提交用户的订阅请求。

• 提供 headless CMS API

  让创作者可以使用 Hugo, Next.js, Gatsby 等 JAMStack 工具获取数据，自由地开发定制属于自己的网站形态。

以上几点中，竹白还有最后两点没有实现，其他我所知道的产品中，最为接近的是 Ghost，除了 email subscribe API 不确定之外，其他全部都能满足。但 Ghost 是专注于网站内容的管理，最近才有 Newsletter 的功能，在专业性上会略逊于其他 Newsletter 发布平台。并且 Ghost 提供的功能太多（甚至支持 Podcast），且价格昂贵，如果我购买后只用它的 Newsletter 功能显然是非常不划算的²。

Proselog

我的朋友 EGOIST 今天发布了他开发的博客平台: Meet Proselog: The Open Blogging Platform

Proselog 的界面相比竹白更加简洁清晰，界面上处处体现出 EGOIST 特有的克制而明快设计审美，这让基于网页编辑器的创作流程变得舒适而愉悦。

Proselog 不仅仅是一个 Substack/竹白 alternative，它还是一个开源项目，意味着创作者的数据和隐私将完全由自己掌控，这与 Fediverse 系的发布平台如 Writefreely 的理念不谋而合。

和 EGOIST 讨论后，他表示 Proselog 的确有 headless CMS 的开发计划，这让我异常期待 Proselog 后续的发展。也许这次，我找到了那个理想中的 Newsletter 发布平台。

我首先想到的是切换到另一家 hosting 的网站统计服务，如果可以的话，最好能有免费额度。然而开公司并不是做慈善，Google 之所以开放 Analytics 免费使用，除了本身体量足够大、边际成本够低之外，也因为网站统计与其核心的广告业务是密不可分的，Google 乐于让尽可能多的网站使用 Analytics，以得到可以推动广告和搜索业务发展的数据。果不其然，目前风评比较好的服务如 fathom 都没有免费套餐，价格也不便宜；plausible 价格较低，并且提供开源可部署的版本，这让我开始考虑自建统计服务的可行性。

要选择一个 self-hosted 网站统计服务，我有以下几个考量：

• 实现语言：我非常倾向于 JavaScript 的实现，这并非出于我对它更加熟悉或者偏爱，而是因为近年来 Cloudflare 在 serverless 和 edge computing 领域不断深耕，推动了一系列基于 JavaScript 的运行环境和基础设施的发展，最近还联合 Vercel 等友商成立了 WinterCG 社区组织，让我看到了 JavaScript 一站式云端开发部署的未来。我自己也尝试过 Workers 开发，体验很好，免费额度充裕。如果一个服务是 JavaScript 实现，就有在 Workers 上部署的可能性。
• 数据库：最好是 SQLite。SQLite 的存储基于单文件，非常适合小型服务的开发部署。Litestream 的存在让基于 S3 等对象存储的低成本数据库维护成为可能。
• 便于部署：有官方维护的 docker image，或提供 PaaS/Serverless 平台的一键部署模板
• 尊重数据隐私：其实 self-hosted 统计服务产生的目的之一就是为了抵制商业服务滥用用户数据，因此这一点大部分项目都可以满足，稍加注意即可。
• ublock：作为一个 webmaster，肯定希望统计数据越精确越好，因此这个服务得有绕过 ublock 拦截的能力。虽然我个人也会使用 ublock 拦截各种 tracker，但 self-hosted 统计服务本身不会过度收集用户数据，更不会将其用于商业目的，可以理直气壮地想办法确保其正常加载。

经过一番调查，我选择了 umami，它基本满足以上所有需求：

• 前后端全部使用 TypeScript 和 Next.js 开发
• 数据库是 PostgreSQL，我比较喜欢，可以接受
• 项目页面有个大大的 “Deploy on Railway”，也有 docker image
• 项目 Slogan 就是 “privacy focused”

  Umami does not collect any personally identifiable information and anonymizes all data collected.

• 提供 TRACKER_SCRIPT_NAME 环境变量用于自定义 script 名称，可以绕过 ublock 的默认规则

择日不如撞日，选定工具后我立刻开始尝试部署。umami 的部署流程是如此顺滑，只花了大概 15 分钟，我就确信自己做了一个十分正确的选择。

部署说明

我之前就对 Railway 有所了解，所以直接点击 “Deploy on Railway” 按钮开始部署流程。

Railway 是一个 PaaS 平台，可运行 JavaScript, Python, Go 等多种语言，提供 Redis, MySQL, MongoDB 等主流数据库存储。由于支持全面、界面友好，加上和 Cloudflare 一样有充裕的免费额度，足够个人项目免费使用，Railway 一直是我心中最好的 PaaS 之一。如果你有兴趣，欢迎通过我的 referral link 注册。

umani 有一篇 Running on Railway 文档，我遵照这个流程很快就完成了初步部署。其实只有一个 HASH_SALT 需要输入，其他只需点点点即可。

Railway Project 创建后，在管理界面可以看到两个 block，左边是数据库实例，右边是 umami 的后端服务。

安装依赖

在等待 umami 的镜像构建和部署的过程中，我们可以在命令行进行一些其他工作。

打开命令行，使用以下命令安装 Railway CLI 和 pgsql 两个软件依赖。

brew install railwayapp/railway/railway
brew install libpg

完成后，将 libpg 的 bin 路径添加到 PATH 中，在 .zshrc 或 .bashrc 中添加一行:

export PATH="$PATH:/opt/homebrew/opt/libpq/bin"

你可以通过执行 type pgsql 确认 pgsql 是否存在。

更新数据库

Railway 在创建 Project 时，会将 umami 的代码复制到在你的 GitHub 账户所创建的名为 umami 的仓库中，我们需要先将此仓库 clone 下来:

git clone git@github.com:username/umami.git

进入 umami 目录，执行以下命令，登录 Railway CLI 并完成链接:

cd umami
railway login
railway link

这一步完成后，可以通过 railway variables 看到 umami 服务的环境变量，确认 CLI 可以访问到线上数据。

DATABASE_URL:        postgresql://postgres:xxxxxxxxx@containers-us-west.railway.app:6595/railway
DISABLE_TELEMETRY:   1
HASH_SALT:           xxXXxxXXxxXXxx
HOSTNAME:
PGDATABASE:          railway
PGHOST:              containers-us-west.railway.app
PGPASSWORD:          xxXXxxXXxxXXxx
PGPORT:              6595
PGUSER:              postgres
PORT:                3000

执行以下命令，为 umami 创建表格、添加初始数据。注意要将 bash variable 替换为上文中的数据:

railway run psql -h $PGHOST -U $PGUSER -d $PGDATABASE -f sql/schema.postgresql.sql

配置服务

数据库初始化完毕后，回到 Project 管理界面，确认 umami 部署完毕，即可打开服务的主页。

更换密码

使用初始用户名密码 admin:umami 登录进去，然后立刻到 Settings > Accounts 界面更换一个强密码。

绑定个人域名

在 Project 管理界面点击 umami，选择 Settings，在 Service Domains 下添加个人域名。比如我使用的是 oishii.reorx.com。

打开域名的 DNS 服务商，根据 Railway 中的提示，为自定义域名添加 CNAME 记录。

等待几分钟，生效后 Railway 中会显示上图所示的 ✅ 符号。

修改脚本名称

为了避免 umami 被 ublock 误杀（有的规则集中有匹配 umami 的正则），还需要为它的统计脚本更换一个名称。Environment variables 文档中的 TRACKER_SCRIPT_NAME 提供了这一功能。

再次进入 Railway，打开 umami 的 Variables 选项卡，按下图所示添加环境变量，我使用的名称为 oishii，可以更换为任意非 tracker 特征词汇。

完成这一步后，需要重新构建 umami 的镜像，目前我还没有找到触发 rebuild 的简单方法，只能通过修改 Dockerfile 实现

2022-09-25 更新

保存 Variables 后，等待新的部署完成，即可生效。

接入个人网站

一切准备就绪，我们重新使用自定义域名和修改后的密码登录 umami。

要进行统计，第一件事情是添加一个 Website。操作非常简单，读者可以参考 Add a website 文档来进行。唯一需要注意的是 Enable share URL 选项，如果你想将自己网站的统计数据分享出去，则需要勾选之。你可以在 https://oishii.reorx.com/share/jKljpE4T/reorx.com 访问本站的统计信息。

添加完成后，点击网站列表中对应网站的 Get tracking code 按钮，在浮窗中获得需要加入到网站 HTML 中的代码。

需要注意将 src 结尾的 umami.js 替换为 $TRACKER_SCRIPT_NAME.js。

复制代码并添加到自己个人网站的 <head> 标签下的任意位置，由于使用了 defer 属性，这个 script 不会对网页加载造成阻塞。

网站更新完成后，呼朋唤友点击访问一番，就可以看到 umami 清晰、美观的统计数据了。

大约在两个月前，为了做出一款属于自己的产品，我正式开始学习 TypeScript 和 React 开发¹。虽然接触 JavaScript 时间不短了，但一直热衷于使用 Vanilla JS，也没有正式做过比较严肃的项目。因此，我把自己定位为一个前端新手，决定从 0 开始学习现代化前端开发。

这两个月来，我在学习实践过程中累计了一些自己的心得和体会，算不上高深，但应该可以为同样在学习中的新手起到参考作用。从这篇文章开始，我会逐一将我认为有价值的部分写成博客，归类于 #frontend-guide 标签下，并在未来的学习中持续更新。作为一个非专业的前端学习者，这些文章中一定会出现错误和疏漏，请读者朋友们不吝指正，如果能从批评中学到什么，将会是我写作的最大收获。

先大致列举一些可写的话题，以作备忘：

• 如何构建一个最基本的 TypeScript 项目
  • 介绍 package.json 和基本的 devDependencies
  • 介绍 tsconfig.json 中必须了解的选项
  • tsc 和 esbuild
• 如何使用 jest 进行细粒度的 TDD
• 从零开始构建自己的 React project template
  • 不使用 create-react-app 有哪些好处
  • webpack
  • babel: modular import and hot reload
  • config and APP_ENV
• 如何构建一个最基本的 monorepo
  • npm workspace
  • tsconfig reference
  • webpack: resolve alias and tsconfig paths plugin
• TypeScript caveats and cheatsheet
• 如何使用 TypeScript 和 React 开发 Chrome Extension
• Mobx 使用指南
• 实现一个简单的 useFetch Hook
• 如何使用 swr 调用 HTTP API
• 如何使用 Protobuf 和 TypeScript 封装 HTTP API

ts-loader

在现代化前端项目中，TypeScript 因其静态类型的特性，为代码的可维护性、健壮性带来了极大的提升，已逐渐成为前端开发的标准语言。但 TypeScript 不能直接在浏览器中运行，因此在项目构建流程中需要引入 transpiler 来将其编译为浏览器可用的 JavaScript。ts-loader 就是为 Webpack 设计的 transpiler 之一。

过去的开发生涯中，我虽然不是专业的前端，也对 JavaScript 世界中的基石 babel 有所耳闻目见。但在这次从零开始学习 TypeScript 开发时，因为对 babel 有种过于复杂的印象，我选择了 ts-loader 作为第一个学习和上手的插件。

ts-loader 的使用非常简单，文档也足够清晰，如果你的项目本身有正确配置 tsconfig.json 并可以使用 tsc -b 完成编译，那么在 webpack 中引入 ts-loader 后不需要额外的配置即可工作。

下面是一份使用 ts-loader 的 webpack.config.js 示例:

module.exports = {
  entry: {
    index: path.join(srcDir, 'index.tsx'),
  },
  output: {
    path: destDir,
    filename: '[name].bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        loader: 'ts-loader',
        exclude: /node_modules/,
      },
    ]
  }
}

经过一段时间的使用，我发现了对 ts-loader 不太满意的几个地方：

• 偶尔出现莫名的错误

  有的时候，当对 TypeScript 源文件进行了某种变更，或许是大量的类型变化，或许是文件重命名和移动目录，可能会触发 ts-loader 报错，但此时 VSCode 的静态检查器却没有显示出任何问题（所有源文件），重启 webpack serve 也无济于事。这时只能通过删除所有与构建过程和结果有关的文件，如 build, dist, **/*.d.ts, *.tsbuildinfo，重新运行才可以消除这个不存在的错误。

• 难以 Debug 某些 transpiling 过程中的错误

  如果你的 tsconfig.json 中设置了 noEmit: true 或 noEmitOnError: true, 那你很有可能会看到 Error: TypeScript emitted no output for… 这样的报错，这是因为 ts-loader 在将 TypeScript 转换成 JavaScript 时无法成功，于是没有输出 js 文件。但具体是什么错误，完全无法搞清楚。我在 GitHub 上跟踪了一个 issue, 目前仍然没有收获。

• 项目内多个 package 引用必须生成描述文件

  如果想在项目内想要拆分多个 package 并互相引用，需要使用 TypeScript 的 Project References 功能，而 declaration 必须设置为 true，此时 ts-loader 会为被引用的包生成 .d.ts 的描述文件，使文件浏览器变得混乱。

• 在插件生态中不是一等公民

  一些优化项目开发流程的插件，如 react-refresh-webpack-plugin, 优先支持 babel 而非 ts-loader；babel-plugin-import 的 ts-loader 实现 ts-import-plugin 远不如其本身流行。

于是我决定对 babel-loader 进行一次尝试。

babel-loader

babel-loader 的项目页面有详细的安装配置说明，在此不做赘述。下面是一个在 TypeScript + React 项目中工作的最小化配置示例:

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: [
                ['@babel/preset-env', { targets: "defaults" }],
                '@babel/preset-typescript',
                ['@babel/preset-react', {'runtime': 'automatic'}]
              ],
            },
          },
        ],
      }
    ]
  }
}

配置完成后，代码顺利编译，随后我开始了对构建配置优化的探索。

webpack-bundle-analyzer

我首先想到的是对构建出的 bundle 的大小进行检查，一看竟然有 7MB 之大，于是安装了 webpack-bundle-analyzer, 对 bundle 中所包含的依赖进行分析。

下面是引入 webpack-bundle-analyzer 之后的 webpack.config.js 文件，通过环境变量 WEBPACK_USE_ANALYZE 判断是否进入分析模式并修改 webpack 配置。

const useAnalyze = !!process.env.WEBPACK_USE_ANALYZE

const config = {...}

if (useAnalyze) {
  const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

  config.mode = 'development'
  config.plugins.push(
    new BundleAnalyzerPlugin({
      analyzerPort: 18888,
    })
  )
}

module.exports = config

运行 WEBPACK_USE_ANALYZE=1 webpack 在浏览器中查看分析结果。

原来 tabler-icons-react 一个库就占了 5.28MB，其他库中 lodash 也不算正常，似乎和 tabler-icons-react 一样被完整包含进来了。

babel-plugin-import

tabler-icons-react 是一个 SVG 图标库，我只是使用了其中一部分图标。lodash 是非常通用的工具函数库，同样的，我只对其中一部分函数进行了引用。那么有没有办法按需加载依赖中的模块，只输出被 import 到的部分呢？答案就是 babel-plugin-import。

继续修改 webpack.config.js，为 babel-loader 增加 plugins:

{
  loader: 'babel-loader',
    plugins: [
      ['import', {
        libraryName: 'tabler-icons-react',
        libraryDirectory: 'dist/icons',
      }],
      ['import', {
        libraryName: 'lodash',
        libraryDirectory: '',
        camel2DashComponentName: false,
      }],
    ]
  }
}

再次运行 WEBPACK_USE_ANALYZE=1 webpack ，可以看出 bundle 结构有了显著的改进（红色的部分是 tabler-icons-react 和 lodash）:

babel-plugin-lodash 也可以实现 lodash 的按需加载，但它是专为 lodash 开发的，不具备 babel-plugin-import 的通用性。

@babel/preset-env

@babel/preset-env 是 babel 中最重要的一个 preset。所谓 preset，即预设配置的封装，让需求相近的用户可以不用关注细节直接使用，preset-env 提供了非常丰富的选项，让使用者可以快速定制出符合目标需求的编译结果。

首先要关注的是 targets 选项，它决定了 babel 所编译出的 JavaScript 能否在特定平台上运行。targets 支持 browserslist 语法，上文中我们的初始配置 ['@babel/preset-env', { targets: "defaults" }], 代表使用 browserslist 的 defaults 查询²，虽然可以编译，但在浏览器中是无法运行的，会产生 Uncaught ReferenceError: regeneratorRuntime is not defined 错误，这是为什么呢？

为了统一不同浏览器的 JavaScript 实现差异，使 ES2015+ 代码可以正确运行，babel 会根据 targets 决定是否需要在编译结果中注入 polyfill。 最早这一功能由 @babel/polyfill 实现，但它在 babel 7.4.0 之后被废弃，由 core-js 接替。我们的代码之所以运行报错，就是因为没有指定 preset-env 使用 core-js，导致用于模拟 ES2015+ 运行环境的 regeneratorRuntime 缺失。

修改后的 preset-env 配置如下:

["@babel/preset-env", {
  targets: "defaults",
  corejs: 3,
  useBuiltIns: 'usage',
}]

重新编译，代码即可成功运行。并且通过 webpack-bundle-analyzer 可以发现 bundle 中多出了 core-js 的部分。

如果想在对浏览器的支持上激进一些，可以尝试将 targets 设为 {browsers: '> 5%'}，即仅支持占有率超过 5% 的浏览器，你会发现 bundle 中 core-js 的部分会再次消失，因为这些浏览器不需要 core-js 就有完整的 ES2015 支持。

react-refresh-webpack-plugin

webpack 提供 HMR 热更新功能，不需要刷新页面即可将改动反映到页面中。在 babel-loader 中，需要通过 react-refresh-webpack-plugin 插件来实现 React JSX 的热更新。

首先要在 devServer 中开启 hot 选项:

module.exports = {
  devServer: {
    // Enable hot reloading
    hot: true,
  }
}

然后为 webpack 添加 ReactRefreshWebpackPlugin 插件:

const ReactRefreshWebpackPlugin = require('@pmmmwh/react-refresh-webpack-plugin');

module.exports = {
  plugins: [
    new ReactRefreshWebpackPlugin(),
  ],
}

最后为 babel-loader 添加 react-refresh/babel 插件，通过 isDevelopment 决定是否存在:

{
  loader: 'babel-loader',
  options: {
    plugins: [
      isDevelopment && 'react-refresh/babel'
    ].filter(Boolean)
  }
}

Summary

将以上插件和技巧综合起来，最终我的 babel-loader 配置如下:

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: [
                ['@babel/preset-env', {
                  targets: {
                    browsers: '> 5%',
                  },
                  corejs: 3,
                  useBuiltIns: 'usage',
                }],
                '@babel/preset-typescript',
                ['@babel/preset-react', {'runtime': 'automatic'}]
              ],
              plugins: [
                ['import', {
                  libraryName: 'tabler-icons-react',
                  libraryDirectory: 'dist/icons',
                }],
                ['import', {
                  libraryName: 'lodash',
                  libraryDirectory: '',
                  camel2DashComponentName: false,
                }],
                isDevelopment && 'react-refresh/babel'
              ].filter(Boolean),
            },
          },
        ],
      }
    ]
  }
}

它实现了：

• 输出支持现代主流浏览器的 JavaScript
• 按需加载 tabler-icons-react 和 lodash 模块
• React JSX 开发热更新

如果你想看到一个可运行的例子，请参考我的最小化 React 项目模板 reorx/minireact，其中有完整的 webpack.config.js 文件。

Revision

• 2022-05-18: created

HTML

<dialog>

https://web.dev/building-a-dialog-component/

<dialog> 和 <selectmenu>，基本上所有 UI Kit 都会在组件库里实现的功能，终于被 HTML 原生实现了。如果 HTML 能多一些这种常用的交互组件，我会很乐意手写 Vanilla JS 来使用它们。

<selectmenu>

https://open-ui.org/prototypes/selectmenu

<input type=datetile-local>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local

记得 7 年前在豌豆荚工作时，因为这个标签不被 Firefox 支持，被迫找了一个 JavaScript 库来代替 (Pikaday, I still remember)。如今终于可以在主流浏览器上全面通用，太不容易了😭。

CSS

:has selector

https://developer.mozilla.org/en-US/docs/Web/CSS/:has

用于声明父子元素关系的 :has 选择器！这个功能前阵子正好搜索过，现在只能用 JavaScript 实现。

图中的代码可以解释为，在包含 <figcaption> 的 <figure> 元素中，将其 children 中的 <img> 增加 1rem 的 bottom margin。

Aspect ratio

https://web.dev/aspect-ratio/

CSS aspect-radio，使元素保持固定的宽高比。这是曾经在 <img> 标签上的实验特性，如今终于被所有元素支持了。

Cascade Layer

https://developer.chrome.com/blog/cascade-layers/

Cascade Layers, 给 CSS 加上了层级的概念，layer 可以自由排列顺序，后面的比前面的有更高的优先级 (specificity)；还展示了下越来越复杂的 CSS 优先级关系图，其实也可以把每一级都当做一个 layer。

Container queries

Container queries，在响应式中能够发挥重要作用，但我基本没听懂，未来应该会影响一些 CSS 框架的 API，到时候再来学习吧。

Accent color

https://web.dev/accent-color/

CSS accent-color，为 HTML 基本元素设定一个统一的色调，主流浏览器在一年内都争先恐后地实现了😂，毕竟这是最能体现自己颜值的功能。不知道能不能和操作系统的 accent-color 互通，这样体验就更一致了。

JavaScript

Array.prototype.at

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/at

Array 增加了 at 方法，JavaScript 终于可以用类似 Python list[-1] 的写法了。这曾经是我刚学习 JavaScript 时觉得它不如 Python 最主要的原因。

URLPattern

https://web.dev/urlpattern/

新类型 URLPattern，定义 URL 路径中的参数并解析出对应的 object。routing library 不用再写麻烦的正则了

structuredClone

https://web.dev/structured-clone/

有了 structuredClone, 再也不用写 JSON.parse JSON.stringify 这种扭曲心智的代码了，非常适合在面试官问到 deep clone 的问题时反将一军。还可以用来 clone 其他数据结构如 blobs, bitmaps, typed arrays。

createImageBitmap

https://developer.mozilla.org/en-US/docs/Web/API/createImageBitmap

createImageBitmap, 把 blob 直接转化成 Image 对象，改善了一直以来复杂而脆弱的写法。

Miscellaneous

CHIPS

https://developer.chrome.com/docs/privacy-sandbox/chips/

CHIPS 全称 Cookies Having Independent Partitioned State, 是 Cookie 在安全策略上的新特性，为 Set-Cookie 增加了 Partitioned 关键词。可以使特定 cookie 在 iframe 中只用于当前站点。自两年前 SameSite 关键词推广后，third-party cookie 只能选择全有或者全无，这次终于有了一个折中的选择。

Window controls overlay

https://web.dev/window-controls-overlay/

Window controls overlay 是一组 Web app manifests, CSS, JavaScript API 的集合，实现了定制 PWA 窗口在 window bar 部分区域的显示效果，用于获得更有沉浸感的使用体验。

英文版: Tips that may save you from the hell of PyYAML

YAML 是一个被广泛使用的数据序列化和配置语言，作为一个开发者，总是不免和它打交道。 但处理 YAML 文档，尤其是使用 PyYAML 的过程总是非常痛苦。

这篇文章分享我在 Python 下使用 PyYAML 的技巧和代码片段，并介绍几个相关的库。

注意：本文中的代码仅保证在 Python 3 下正常工作

总是使用 safe_load/safe_dump

PyYAML 的 load 函数可以构造任意 Python 对象（Pickle 协议），这意味着一次 load 可能导致任意 Python 函数被执行。

为了确保应用程序的安全性，尽量在任何情况下使用 yaml.safe_load 和 yaml.safe_dump。

保留字段顺序

Python 3.7+ 中，dict keys 具备保留插入顺序的特性，所以通过 yaml.safe_load 得到的 dict，其 keys 顺序会与原始文件保持一致。

>>> import yaml
>>> text = """---
... c: 1
... b: 1
... d: 1
... a: 1
... """
>>> d = yaml.safe_load(text)
>>> d
{'c': 1, 'b': 1, 'd': 1, 'a': 1}
>>> list(d)
['c', 'b', 'd', 'a']

当把 dict 导出为 YAML 字符串时，为 yaml.safe_dump 传递 sort_keys=False 来保留 keys 的顺序。

>>> print(yaml.safe_dump(d))
a: 1
b: 1
c: 1
d: 1
>>> d['e'] = 1
>>> print(yaml.safe_dump(d, sort_keys=False))
c: 1
b: 1
d: 1
a: 1
e: 1

如果 Python 版本较低，或者你想确保代码能在更广泛的环境下工作，你可以使用 oyaml 库来代替 PyYAML 的 yaml 包。

>>> import oyaml as yaml
>>> d = yaml.safe_load(text)
>>> d
OrderedDict([('c', 1), ('b', 1), ('d', 1), ('a', 1)])
>>> d['e'] = 1
>>> print(yaml.safe_dump(d, sort_keys=False))
c: 1
b: 1
d: 1
a: 1
e: 1

优化列表项的缩进

默认情况下，PyYAML 输出的列表缩进与其父元素一致。

>>> d = {'a': [1, 2, 3]}
>>> print(yaml.safe_dump(d))
a:
- 1
- 2
- 3

这并不是很好的格式，根据 Ansible 和 HomeAssistant 等 YAML 书写规范，列表项应该缩进 2 空格。

这种格式也会对导致列表项不会被如 VSCode 等编辑器识别，进而无法使用编辑器的折叠功能。

要解决这个问题，使用如下代码片段，在代码中定义 IndentDumper class:

class IndentDumper(yaml.Dumper):
    def increase_indent(self, flow=False, indentless=False):
        return super(IndentDumper, self).increase_indent(flow, False)

然后将它传递给 yaml.dump 的 Dumper 关键字参数。

>>> print(yaml.dump(d, Dumper=IndentDumper))
a:
  - 1
  - 2
  - 3

注意，yaml.safe_dump 由于有自己的 Dumper class，传递此参数会造成冲突。

输出可读的 UTF-8 字符

默认情况下，PyYAML 假设你希望输出的结果里只有 ASCII 字符。

>>> d = {'a': '你好'}
>>> print(yaml.safe_dump(d))
a: "\u4F60\u597D"

这会让输出结果非常难以阅读。

在 UTF-8 足够普及的今天，直接输出 UTF-8 字符是非常安全的。 因此我们可以将 allow_unicode=True 传入 yaml.safe_dump 使 PyYAML 将 Unicode 转换成 UTF-8 字符串。

>>> print(yaml.safe_dump(d, allow_unicode=True))
a: 你好

一些 YAML 相关的库

oyaml

Link: https://github.com/wimglenn/oyaml

正如上文中提到的，oyaml 是 yaml 包的替换品，使 dict keys 的顺序在 dump/load 的时候得以保留。

oyaml 是一个单文件库，只有 53 行代码，因此使用起来非常灵活，你可以直接把它的代码复制到自己的项目中，然后根据自己的需求进行修改。

strictyaml

Link: https://github.com/crdoconnor/strictyaml

有的人说 YAML 过于复杂和灵活，不是一个好的配置语言。但我认为这不是 YAML 的问题，而是使用方式的问题。如果我们限制程序只使用 YAML 的部分功能，YAML 其实可以变得像它设计的那般好用。

这就是 StrictYAML 的设计意图，它是一个类型安全的 YAML 解析器，实现了 YAML 规范说明中的一个子集 。

如果你对 YAML 的输入输出有较强的安全考虑，建议使用 StrictYAML 代替 PyYAML。

顺带一提的是，StrictYAML 的文档站有很多关于设计细节和配置语言思考的文章，非常值得一看。

ruamel.yaml

Link: https://yaml.readthedocs.io/en/latest/overview.html

ruamel.yaml 是 PyYAML 的一个分叉，于 2009 年发布并持续维护至今。

ruamel.yaml 的文档里详细说明了它和 PyYAML 的差异。 总体来说，ruamel.yaml 专注在 YAML 1.2 上，对一些语法进行了优化。

ruamel.yaml 最令我感兴趣的特性是输入输出的 “round-trip”，可以最大程度地保留输入源的原始格式。官方文档中的定义是这样的：

A round-trip is a YAML load-modify-save sequence and ruamel.yaml tries to preserve, among others:

• comments
• block style and key ordering are kept, so you can diff the round-tripped source
• flow style sequences ( ‘a: b, c, d’) (based on request and test by Anthony Sottile)
• anchor names that are hand-crafted (i.e. not of the formidNNN)
• merges in dictionaries are preserved

如果你有尽可能保留原始格式的需求，建议使用 ruamel.yaml 代替 PyYAML。

在使用中我注意到 ruamel.yaml 的 safe load 方法 (YAML(typ='safe').load) 与 PyYAML 有些不同，它无法解析 flow style 的集合定义 (如 a: {"foo": "bar"})，这点没有在文档中提及，使用时须多加注意。

总结

YAML 有它好的地方和坏的地方。它易于阅读，初期的学习曲线非常平缓。 但 YAML 的规范说明非常复杂，不仅造成了使用中的混乱，也使不同语言的实现在很多细微的地方难以保持一致。

尽管有这些小毛病，YAML 仍然是我心中最好的配置语言。希望这篇文章所介绍的技巧能够帮助你避免问题，获得更好的开发和使用体验。

Code in this article is only guaranteed to work in Python 3

Always use safe_load/safe_dump

YAML’s ability to construct an arbitrary Python object makes it dangerous to use blindly. It might be harmful to your application to simply yaml.load a document from an untrusted source such as the Internet and user input.

See from PyYAML official documentation:

Warning: It is not safe to call yaml.load with any data received from an untrusted source! yaml.load is as powerful as pickle.load and so may call any Python function.

In short, you should always use yaml.safe_load and yaml.safe_dump as the standard I/O methods for YAML.

Keep keys in order (load/dump)

In Python 3.7+, the order of dict keys is naturally preserved ¹, thus the dict you get from yaml.safe_load has the same order of keys as the original file.

>>> import yaml
>>> text = """---
... c: 1
... b: 1
... d: 1
... a: 1
... """
>>> d = yaml.safe_load(text)
>>> d
{'c': 1, 'b': 1, 'd': 1, 'a': 1}
>>> list(d)
['c', 'b', 'd', 'a']

When dumping dict into a YAML string, make sure to add keyword argument sort_keys=False to preserve the order of keys.

>>> print(yaml.safe_dump(d))
a: 1
b: 1
c: 1
d: 1
>>> d['e'] = 1
>>> print(yaml.safe_dump(d, sort_keys=False))
c: 1
b: 1
d: 1
a: 1
e: 1

If your Python version is lower, or you want to make sure the keys order preserving always works, you can use this library called oyaml as a drop-in replacement for pyyaml.

>>> import oyaml as yaml
>>> d = yaml.safe_load(text)
>>> d
OrderedDict([('c', 1), ('b', 1), ('d', 1), ('a', 1)])
>>> d['e'] = 1
>>> print(yaml.safe_dump(d, sort_keys=False))
c: 1
b: 1
d: 1
a: 1
e: 1

Enhance list indentation (dump)

By default, PyYAML indent list items on the same level as their parent.

>>> d = {'a': [1, 2, 3]}
>>> print(yaml.safe_dump(d))
a:
- 1
- 2
- 3

This is not a good format according to style guides like Ansible and HomeAssistant. It is also not recognized by code editors like VSCode, making the list items unfoldable in the editor.

To solve this problem, you can use the snippet below to define an IndentDumper class:

class IndentDumper(yaml.Dumper):
    def increase_indent(self, flow=False, indentless=False):
        return super(IndentDumper, self).increase_indent(flow, False)

Then pass it to the Dumper keyword argument in yaml.dump function.

>>> print(yaml.dump(d, Dumper=IndentDumper))
a:
  - 1
  - 2
  - 3

Note that Dumper cannot be passed to yaml.safe_dump which has its owner dumper class defined.

Output readable UTF-8 (dump)

By default, PyYAML assumes the user only wants ASCII code in the output, so it converts UTF-8 characters to Python’s Unicode representation.

>>> d = {'a': '你好'}
>>> print(yaml.safe_dump(d))
a: "\u4F60\u597D"

This makes the output hard to read for humans.

In the modern world, UTF-8 is widely supported, it’s safe to write UTF-8 in the output. Pass allow_unicode=True to yaml.safe_dump to enable that.

>>> print(yaml.safe_dump(d, allow_unicode=True))
a: 你好

No default_flow_style needed (dump)

Most of the time we don’t want flow style productions in the output (i.e. no JSON in YAML). According to PyYAML documentation, default_flow_style=False should be passed to yaml.safe_dump to achieve that.

After digging into the source code of the latest PyYaml (6.0), I find it is not needed anymore. You should remove this keyword argument to keep the code cleaner and less confusing.

Libraries

oyaml

Link: https://github.com/wimglenn/oyaml

As mentioned above, oyaml is a drop-in replacement for PyYAML which preserves dict ordering.

I suggest using oyaml if you already use PyYAML in your code.

It’s worth mentioning that oyaml is a single-file library with only 53 lines of code. This makes it very flexible to use, you can just copy the code to your library and customize it according to your need.

strictyaml

Link: https://github.com/crdoconnor/strictyaml

Some people say YAML is too complex and flexible to be a good configuration language, but I think this is not the problem of YAML, but the problem of how we use it. If we restrict our usage to only a subset of its features, it will be as good as it should be.

This is where StrictYAML came up. It is a type-safe YAML parser that parses and validates a restricted subset of the YAML specification.

I suggest using StrictYAML if you have strong security concerns for your application.

There are tons of great articles on the documentation site of strictyaml, definitely worth having a look at if you have thought about YAML and other configuration languages.

ruamel. yaml

Link: https://yaml.readthedocs.io/en/latest/overview.html

ruamel.yaml is a fork of PyYAML, it was released in 2009 and continuously maintained in the past decade.

The differences with PyYAML are listed here. Generally, ruamel.yaml focuses on YAML 1.2 with some opinionated enhancements for the syntax.

What interests me most is the ability to round-trip in the loading/dumping process. It works like black magic. Here’s the explanation from ruamel.yaml documentation:

A round-trip is a YAML load-modify-save sequence and ruamel.yaml tries to preserve, among others:

• comments
• block style and key ordering are kept, so you can diff the round-tripped source
• flow style sequences ( ‘a: b, c, d’) (based on request and test by Anthony Sottile)
• anchor names that are hand-crafted (i.e. not of the formidNNN)
• merges in dictionaries are preserved

I suggest using ruamel.yaml if you have the requirement to preserve the original content as much as possible.

One thing I notice is that ruamel.yaml’s safe_load method (YAML(typ='safe').load) cannot parse flow style collection (a: {"foo": "bar"}), this is a undocumented difference with PyYAML.

Summary

YAML has its good and bad. It’s easy to read, the learning curve is mild at the beginning, but the specification is complex, which not only causes chaos in practice, but also makes implementations in different languages inconsistent with each other in many trivial aspects.

Despite these quirks, YAML is still the best configuration language for me, and as long as we can use it properly, problems will be avoided and the experience will be much better.

我曾经是一个糟糕的 RSS 用户。

早在 Google Reader 流行的时期，我就热衷于将我感兴趣的资讯网站和博客订阅到 Google Reader 中 ¹，期盼着能从这些信息中获得有价值的东西，却总是因为懒或者忘了而不能及时查看。随着未读数的增多，焦虑感越来越强烈，最后索性不再打开阅读器，安慰自己以后总会去看的，只要订阅了就行，沉浸在虚假的满足感中。

我就像一个喜欢屯书的人，在 RSS 阅读器这个书架上摆满了放上去就再也没动过的书²。

后来我认识到，自己得了信息资源的囤积病，经过长时间的反思后，我下决心清理 RSS 订阅源。

我删除了所有资讯类网站，只留下个人博客；去掉长期未更新的，并重新审视每个博客是否是我真正想要去阅读的。最终留下大约 30 多个 RSS 源，每周的更新量被控制在 10-20 之间。自此以后，我才真正做到阅读每篇更新，也没有再因为未读数量而焦虑了。

再之后，我看到许多人分享自己的 RSS 使用经验³，将 RSS 作为获取信息的效率工具，聚合和筛选资讯，甚至成为 all-in-one 的信息输入渠道。这些文章偶尔会让我蠢蠢欲动，但因担心摄入压力过大而重蹈覆辙，我总是很快熄灭了尝试的想法。

就这样，我从一个糟糕的 RSS 用户，变成了一个克制但低效的用户，不再每天使用，只在有提醒时打开看看博客的更新。生活继续。

重新发现 RSS

最近我开始经常逛 V2EX 。我最早的活跃时期是 2010~2013，后来因为沉迷工作，和陌生人的交流欲降低，兴趣转移到 Twitter。今年自由工作后，思维又活跃起来，回过头来发现经过 10 年时间，V2EX 依然是国内最好的开发者社区。

V2EX 有着丰富的 RSS 支持，在 V2EX  ›  提醒系统 页面可以获得提醒的 RSS 订阅源。为了及时收到消息通知，我开始琢磨如何利用这一功能，于是整理了下需求：

• 直接订阅 RSS，不需要借助第三方服务
• 支持 macOS 和 iOS，同步未读条目
• 简洁清爽的界面

很快，我锁定了完美满足这三点的 NetNewsWire

NetNewsWire 发布于 20 年前，是 macOS 上历史最悠久的 RSS 阅读器。我虽然很早就知道它，却一直没有尝试，使用的是更受追捧的 Reeder，但 Reeder 最近的几次付费更新有些令人失望，没有什么有趣的变更，我也厌倦了它那软绵绵的 UI 风格。

NetNewsWire 让我眼前一亮，它使用 macOS 原生的 UI 组件，适应起来没有任何障碍。打开就算经典的三栏布局，没有多余的选项，让我感觉真正在使用一个信息组织工具，而非另一个漂亮的玩具。

Minimal and no distraction, 这是我对 NetNewsWire 的整体印象。我很快就爱上了它，逐渐把我其他几个正在摄取的信息源也添加了上去。

现在我的 RSS 订阅结构是这样的：

• V2EX

  • 节点

    我只对一些特定的节点有逐条浏览的兴趣，V2EX 每个节点都可以输出 RSS，只需要将 https://v2ex.com/feed/{node}.xml 的 {node} 替换为节点的英文名即可。

    • 分享创造
    • 分享发现
    • 程序员

  • Top Topics

    V2EX 本身没有最热话题的 RSS，幸运的是，RSSHub 提供了一个公开的源。

• Hacker News

  Hackers News 的信息量太大，不适合直接订阅，好在 hacker_news_feed 这个 Telegram 频道对内容进行了筛选，只推送分数大于 100 的条目。同样要感谢 RSSHub，用它将 Telegram 频道转换成了 RSS feed。

• Obsidian

  作为 Obsidian 重度使用者和插件维护者，我非常关注社区的动向。Obsidian 社区信息主要来自于官方 Discourse 论坛和 subreddit。两者都是通过在 URL 后面加上 .rss 即可获得订阅源（如 Showcase 和 ObsidianMD）

• 提醒

  • V2EX
  • Reddit Unread

经过一段时间的使用，我开心地发现，自己已经能每日有效摄入上百条信息而没有焦虑。我通常是在碎片时间打开手机观看，比如早上蹲马桶时、运动后和睡前。当遇到有趣的信息时，就点击 Star 收藏，如果特别需要关注或后续调研，就在 TickTick 添加一个对应的 TODO 项。要是忙起来积攒了许多未读，我就快速划过快速 Star，然后一次性 Mark All as Read。

进一步优化

V2EX 的程序员节点中经常出现 Java 相关的话题，但我的技能体系与 Java 无关，因此我想过滤掉这些对我而言无用的信息。

NetNewsWire 有一个相关的 issue，却并没有实现。Inoreader 和 Tiny Tiny RSS 等聚合器虽然支持，但我希望保持目前直接订阅原始 RSS 源的工作流，不想引入另一个工具增加复杂度。怎么办呢？

我决定自己开发一个轻量的 serverless 服务: rss-filter。（现在还没有完成，所以读者朋友们可以不急着 star 鼓励。）

rss-filter 的大致设计如下：

• 部署在 serverless 平台
• 通过 url 参数使用
  • rss: rss url
  • exclude_text[]: regex to exclude items from text (title, description, content)
  • exclude_text[]: regex to include items from text
    • if both include and exclude are provided, apply include before exclude.
  • cache_seconds: seconds to cache the result
  • debug: if true, return a json to debug
  • token: prevent abuse by anonymous users
  • full_content: fetch full content of each item

我设想 rss-filter 完成后，只需要简单的设定参数即可创造一个过滤后的 RSS 源。比如我想要从程序员节点过滤掉 Java 相关的条目，那么新的 RSS 源应为:

https://rss-filter.reorx.com/filter?rss=https%3A%2F%2Fv2ex.com%2Ffeed%2Fprogrammer.xml&exclude_text=java%7Cspring+%3Fboot%7Clog4j&cache_seconds=600

其中 exclude_text 为 java|spring ?boot|log4j，用正则匹配多种不同的关键词。

一些思考

RSS 的用法因人而异，这篇文章主要目的是分享我个人的探索过程，希望带给读者一些借鉴。选择适合自己的，不要盲目追求别人看起来「高效」「强大」的工作流。

前几天 涛叔 向我推荐了他的 WebFeed 插件 (for Firefox)，它把浏览器变成 RSS 阅读器，并能自动发现网站的 RSS 源。

我很喜欢它的 Web 与 RSS 一体的使用体验，这让我开始思考一个问题，为何近些年来 RSS 逐渐式微，主流浏览器厂商没有做任何相关的支持³，只有少部分开源爱好者还在坚持使用并为 RSS 社区做出贡献。

我能想到的答案之一是，商业公司在控制和引导互联网生态，将公开流量变成自己的私域流量。而主流浏览器背后正好也都是商业公司。想象一下，如果所有内容都来自于独立博客的 RSS，作者可以直达受众，那内容分发市场的商业价值就没他们什么事了，更不用说将用户绑定在自己的平台上。

另一个原因可能是内容农场的肆虐，独立创作者很难靠自己将原创内容推广，内容农场却通过 SEO 技术将自己洗稿后的文章顶在了搜索结果的前面。关于这个问题，少数派有一篇文章值得一读： 少数派思考 007：关于 RSS。

这是一场没有硝烟的战争，商业巨头们就像地理大发现时期的西方文明，在开放互联网的蒙昧之地大肆开拓殖民地。国外近些年来还有 Medium、Newsletter 等多种形式的内容分发模式百花齐放，国内已经被头条、微信、微博、百度完成瓜分和镇压，沦为没有生机的焦土。

但即使在这样的环境下，我还是希望能成为一个纯粹的内容创作者，为别人带来启发和帮助，为自己实现学习和思考的价值。

欢迎你来订阅我的博客:

https://reorx.com/feed.xml

最后推荐一篇文章 RSS Feed Best Practises， 如果你也是一名维护自己博客的 webmaster，可以了解下如何优化自己网站输出的 RSS。

比如加上 <link> tag 使 RSS URL 可以被主流工具自动发现:

<link rel=alternate title="Blog Posts" type=application/atom+xml href="https://reorx.com/feed.atom">

比如最好在 RSS 中附带全文：

It is generally recommended to provide the full content of your posts in the feed. This is what most readers prefer. Atom has both <summary> element for readers that prefer it. For RSS and the Atom <content> element the full article should be included.

自动补全（auto completion）大概是每个 Vim 用户在掌握了基本用法后，第一个想要进阶配置的功能。这篇文章记录了从 2017 年至今，我的 Vim 自动补全配置的每次变更，从中窥见 Vim 生态发展的一角，也纪念这些曾经给我带来过便利，最终在技术发展中被轮替的插件。

Before 2017

2017 年我从 Vim 切换到 Neovim（下文简称 nvim），除了增加 nvim 特殊的 init.vim，基本沿用了以往的配置和插件。

彼时我使用的语言以 Python 为主，自动补全插件为 jedi-vim。

我对 jedi-vim 的了解最早可以追溯到 2012 年，那时还没有 LSP 的概念。开发者们针对自己的需求，编写如语法增强、文档查看、自动补全等各类插件，非常零散。jedi-vim 对这些插件的功能进行了重构和集成，提供了开箱即用的统一解决方案，一经推出便广受好评，成为使用 Vim 进行 Python 开发的标配。在后来的十年里，它的初心始终不变，得到持续的维护并沿用至今。

jedi-vim 的流行和长寿或许可以说明一个观点，即易用和功能全面才是软件流行的第一因素，无论它的实现有多么不优雅、效率有多么低，只要是能用的、可接受的就行，用户在使用体验上得到满足后，对于小问题的容忍度是相当高的。

2017

还是 2017 年，在切换到 nvim 后不久，我发现了 deoplete 插件，经过一番尝试将 jedi-vim 替换成了 deoplete + deoplete-jedi。

Commit: 0760ba6f7d11526e38e15b36a0d1db8709834825

use deoplete, remove jedi-vim

committed on Jun 28, 2017

-Plug 'davidhalter/jedi-vim', { 'for': 'python' }
+Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
+Plug 'zchee/deoplete-jedi', { 'for': 'python' }

deoplete 的目标是提供一个通用的异步自动补全框架，这在设计理念上是一个巨大的进步。jedi-vim 虽然开箱即用，但却是一堆粘合在一起的 spaghetti code，不仅随着项目功能的增加变得越发庞大和迟缓（这是我想要离开 jedi-vim 的主要原因，文件一大各种操作都变得肉眼可见的慢），代码的可读性也非常糟糕，难以维护和参与。而 deoplete 本身并不提供针对任何语言的分析能力，只专注于与 nvim 的整合和 completion source 的调度，并且利用 nvim 的异步功能（后来 vim 8 也推出了自己的 async 接口），大大提升了补全的流畅度。

但 deoplete 也有着自身的局限性。首先配置变得复杂且麻烦，用户得理解其架构和设计，学会如何通过 deoplete 对接编程语言的 completion source。为了使检查结果的提示贴合自己的使用习惯，还要再去学习 completion source 的配置，每个语言的实现不同，配置也不一样。

当时我却没有料到，配置复杂的问题在 LSP 时代不仅没能得到解决，反而变本加厉，直到本文完成时也依旧是使用者的巨大痛点

deoplete 的第二个问题是，它只专注在 completion，缺少对于 go to definition 和显示 function siguature 等功能的支持，这对于从 jedi-vim 的 all-in-one 体验切换过来的我，显然是个巨大的落差。好在我找到了其他插件来解决这些问题。

对于 “go to definition”，通过装回 jedi-vim 并打开无补全模式可以解决。这样既可以使用 jedi-vim 提供的 go to definition 等辅助功能，也不会与 deoplete 的补全产生冲突。

Plug 'davidhalter/jedi-vim', { 'for': 'python' }

" jedi (only for go to definition)
let g:jedi#completions_enabled = 0

对于 “function signature”，我找到了 deoplete 作者的另一个插件 echodoc 来实现。它将函数的签名信息显示在 cmd 区域，规避了 deoplete 占用 completeopt 导致编辑界面无法显示补全菜单以外的其他信息的问题。

Plug 'Shougo/echodoc.vim'

" echodoc
set noshowmode
let g:echodoc#enable_at_startup=1

2018

2018 年是里程碑式的一年，Language Server Protocol 的生态逐渐成熟，新的补全工具涌现。我对 LSP 感到相当兴奋和好奇，迫不及待地从 deoplete 更换到了对 LSP 有更好支持的 ncm2。

Commit: 7a1442c2334673ac17162c101663e220ef43a3c8

nvim: update completion plugins (a lot!)

• move and reorg completion plugins definitions and configurations
• use LSP completion instead of deoplete
• remove eslint from ale_linters
• enable virtualenv display for airline
• still working on passing settings to pyls through LanguageClient-neovim

committed on Dec 7, 2018

-Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
-Plug 'zchee/deoplete-jedi', { 'for': 'python' }
+Plug 'ervandew/supertab'
+Plug 'ncm2/ncm2'
+Plug 'roxma/nvim-yarp'
+Plug 'autozimu/LanguageClient-neovim', { 'branch': 'next', 'do': 'bash install.sh', }

从设计理念上看，ncm2 与 deoplete 并无差别，都是通用的异步自动补全框架，唯有与静态分析器的集成方式不同，deoplete 是自己的私有协议，ncm2 则拥抱了更加通用的业界标准 LSP。

我为 deoplete 的作者感到惋惜，他在 LSP 还不够成熟的时期，自己设计了与静态分析器的集成协议，构建了一个完整的补全插件生态¹。还写了很多小巧实用的插件，代码也非常优美，让人感到赏心悦目。但因为 LSP 的发展和新一代更加 LSP native 的补全插件的涌现，它已不再是当下的第一选择，势必因为历史包袱而逐渐被淘汰。

说回 ncm2，其实它也有许多瑕疵，印象中配置过程比 deoplete 还要痛苦，但当时已经是让 nvim 用上 LSP 的最好插件了。之后我对 JetBrains 和 VSCode 的使用频率变高，疏于对 nvim 插件的持续跟进，ncm2 于是一直服役到 2021 年。

ncm2 出现后没过多久，coc 也诞生了，在 2019 年成为最受人关注的 vim 补全插件，国内也看到很多文章（似乎作者就是国内开发者）。由于长期受 Webpack 和 Nodejs 技术栈的折磨，当我了解到 coc 是 Nodejs 实现的，就放弃了尝试的念头 ²。一想到 jedi-vim 的缓慢，我实在没办法对同样大而全的 coc 抱有足够的信心³。

P.S. 从当年的笔记中找到了所参考的项目和文章：

• https://www.reddit.com/r/neovim/comments/8ejfg0/state_of_lsp_servers/
• https://github.com/autozimu/LanguageClient-neovim
• https://github.com/prabirshrestha/vim-lsp
• https://github.com/ncm2/ncm2
• https://github.com/palantir/python-language-server

2021

2021 年的某一天，因为 ncm2 长期存在的一个小问题（现在已经忘了），我一气之下再次打开了 deoplete 的项目页面，惊喜地发现它已经完善了对 LSP 的支持，于是立刻就开始迁移，换回了我更欣赏且代码品质更胜一筹的 deoplete。

Commit: cd044fcda603ad5b9ee16bd4d7d7873c9ade9a31

nvim: rework on languageserver & python completion

committed on Mar 26, 2021

-Plug 'ervandew/supertab'
-Plug 'ncm2/ncm2'
-Plug 'roxma/nvim-yarp'
-Plug 'autozimu/LanguageClient-neovim', { 'branch': 'next', 'do': 'bash install.sh',
+Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
+Plug 'prabirshrestha/vim-lsp'
+Plug 'mattn/vim-lsp-settings'
+Plug 'lighttiger2505/deoplete-vim-lsp'

这次变更除了换回 deoplete ，还去掉了陪伴多年的 supertab，在抄了一段看不懂的配置后，实现了我更为习惯的 tab 键触发补全的方式。

2022

在咖啡馆结束了一天的主要工作后，看着好友 @iwendellsun 流畅的 vim 操作，我问起了他的 nvim 自动补全配置，果然有许多我从未听过的东西。于是趁此机会赶紧向他请教，在他的指导下完成了 2022 年的配置升级。

Commit: 3de43d030ca40b498911c6752a7396af38202fe6

nvim: use nvim-cmp for completion

committed on May 08, 2022

-Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
-Plug 'prabirshrestha/vim-lsp'
-Plug 'mattn/vim-lsp-settings'
-Plug 'lighttiger2505/deoplete-vim-lsp'
-Plug 'w0rp/ale'
-Plug 'rhysd/vim-lsp-ale'
+Plug 'williamboman/nvim-lsp-installer'
+Plug 'neovim/nvim-lspconfig'
+Plug 'hrsh7th/cmp-nvim-lsp'
+Plug 'hrsh7th/cmp-buffer'
+Plug 'hrsh7th/cmp-path'
+Plug 'hrsh7th/cmp-cmdline'
+Plug 'hrsh7th/nvim-cmp'

这次变更分以下几个方面：

1. 补全框架从 deoplete 变为 nvim-cmp，我还没细看，不过据说它就是现在的 meta & state of the art.
2. LSP 集成从 vim-lsp 换成了 nvim-lspconfig。迟来的官方出品。
3. 去掉了 ale 和 vim-lsp-ale。nvim-cmp 可以将 LSP client 返回的错误提示直接在行内显示，不需要再依赖 ALE 这个 linter 框架了。
4. Last but not least, 这些插件的配置语法几乎都是用 Lua 写的，这让用了 10 年 Vimscript 的我感到极度陌生和恐慌。

相比之前的变更，这是唯一一次生搬硬套而非全部理解的，我想快速上车，免得被社区发展抛在了后面，现在实在没有太多精力可以悠闲地慢慢尝试。虽然有人指导免去了初次上手的痛苦，但可以预见的是，想要让这套插件和我的编程习惯完美契合，还有许多坑等着我去折腾呢。

参考链接:

• Setup | nvim-cmp
  • List of sources · hrsh7th/nvim-cmp Wiki
  • Example mappings · hrsh7th/nvim-cmp Wiki
• Default configuration | nvim-lsp-installer
• Server Configurations | nvim-lspconfig
  • pylsp
  • pyright
  • gopls
• ray-x/lsp_signature.nvim: LSP signature hint as you type

参考配置:

• https://github.com/xwjdsh/dotfiles/blob/master/nvim1/lua/plugins.lua
• https://github.com/Avimitin/nvim/blob/master/lua/plugins/load.lua

结语

Vim 的 LSP 插件生态还有许多有待优化的空间，开发者们对生产力的追求是永无止境的，下一个 5 年编辑器的体验会有着怎样激动人心的变化，我对此充满期待。

去年为了实现 Home Assistant 家电自动化 (tweet)，我购买了一台 QNAP NAS，使家里有了 24 小时常驻的 Linux server 和 Docker host。年初由于 Bilibili 迟迟不上架《鬼滅之刃遊郭篇》，我又在 NAS 上安装了 Plex，将从 dmhy 手动下载的影片串流到电视上观看。最近又逢 4 月新番播出，想到家里的基础设施逐渐完备，便动起了搭建自动追番系统的心思。以下便是对这次尝试的记录和总结，希望能帮助有同样需求的人解决问题、节省时间。

使用 QNAP Download Station

本着尽量不增加新的系统来解决问题的思想，我首先研究了 QNAP 的下载器 Download Station，发现它自带 RSS 订阅功能，在进行一些手动配置后，即可完成自动追番和下载。

如果对这一章节不感兴趣，你也可以直接跳到 使用 Sonarr 和它的朋友们。

1. 找到番剧的 RSS URL

Bangume Moe 是我经常使用的资源站，它提供基于 tag 的 RSS 搜索功能，可以非常精确地定位到番剧在特定字幕组、语言、分辨率瞎的视频发布链接。

• 首先在右上角的搜索框中输入想看的番剧名称，这里我使用「夏日重现」作为例子，可以看到下方自动匹配了 Summertime Render 这个 tag。
• 点击这个 tag，搜索结果中会出现许多不同字幕组发布的资源，我们选择其中一个字幕组「喵萌奶茶屋」的资源，在 Torrent Details 中，可以看到其标注的 tags，有 喵萌奶茶屋, 720p, chs-jpn 等，妥善使用这些 tags 能够帮助我们缩小搜索结果范围
• 将 喵萌奶茶屋, chs-jpn 添加到 Selected tags 中，现在我们一共有 3 个 tags，搜索结果缩短到了 2 条，已经非常清晰了，点击右上角的 RSS 图标即可得到用于订阅的链接。（美中不足的是，喵萌奶茶屋将 1080p 的资源错标为了 720p，不过这点我们可以在后面的下载管理器中解决）

2. 将 RSS URL 添加到下载器

RSS 订阅是许多下载管理器的通用功能，如 Synology、qBittorrent 也都具有，使用方式与 Download Station 大同小异。

• 打开 RSS Download Manager，将上一步得到的订阅链接复制到 Feed URL 中。Label 填写番剧名称，两个 Location 根据自己 NAS 的目录结构选择。点击 Apply 添加。
• 添加完成后，打开 Filter Settings，它可以用于进一步过滤 RSS 返回的结果，避免下载不需要的资源。之前在进行资源搜索时，我们没能通过 tag 过滤掉 720p 的结果，在 Filter Settings 中，我们选择 1080p，这样 720p 就被忽略了。
• 回到主界面，刷新添加的 RSS，可以看到两条结果中只有 1080p 被加入到下载列表。Status 为 Finished 代表下载完成，New 代表新添加到 RSS，但不在下载列表中。

小结

Pros

• 无需配置和增加新系统
• 操作过程透明清晰，可控性强

Cons

• 步骤较为繁琐，需要在多个服务之间切换
• 下载的文件因为不符合 Plex 的格式需求，需要手动重命名才能在 Plex 上观看。但如果你使用 DLNA 这类基于文件系统定位视频的方式，倒是可以忽略这个缺点。

使用 Sonarr 和它的朋友们

Download Station RSS 虽然解决了基本的温饱问题，但与真正的自动化之间显然还有很大差距，如果你想充分利用 NAS 的功能，在家庭多媒体设施上更进一步，请继续向下阅读，走进 Sonarr 和它的朋友们的世界。

Sonarr

Sonarr is a PVR (Personal Video Recorder) for Usenet and BitTorrent users. It can monitor multiple RSS feeds for new episodes of your favorite shows and will grab, sort and rename them.

Sonarr 是一个 PVR 系统，它可以监控多种信息源的剧集发布信息，对剧集进行自动下载、刮削和重命名。

Sonarr 是 Sick Beard 的继任者，Sick Beard 基于 Python 开发，曾经是最著名的 PVR 系统，但后来逐渐式微，后续虽然有 Sick Gear 等 fork，但最终都没能满足人们日益增长的看片需求，最后被一群 C# 爱好者们开发出 Sonarr 给替代了。经过多年发展，Sonarr 的软件质量趋于成熟和稳定，成为构架自动化的家庭多媒体中心不可缺少的组件。

Sonarr 一开始就以多系统低耦合的方式进行设计，这大大降低了代码的复杂度，使其更易于维护，也为其繁盛的社区发展提供了基石。为了满足不同的用户需求，Sonarr 的作者们开发一系列以 rr 或其他双字母结尾的工具，以至于这种命名方式成为了 Sonarr 生态圈的一个标识和事实标准。

Jackett

Jackett works as a proxy server: it translates queries from apps into tracker-site-specific http queries, parses the html or json response, and then sends results back to the requesting software.

Jackett 是一个代理，用于将 Sonarr 等系统对剧集信息的查询请求转译成各种 torrent tracker/indexer （即资源发布站）所支持的请求。Jackett 的产生是 Sonarr 社区架构合理性的一个体现，它接管了适配不同 indexer 接口的脏活累活，使 Sonarr 可以专注在任务调度和剧集管理上。

Jackett 既然被用作资源查询的网关，实现缓存功能就顺理成章了，这样一方面可以应对 Sonarr 频繁的查询需求，另一方面也减少了 indexer 站点的负载量，实现了双赢。因此虽然它不是一个必须的组件，但我强烈建议每个使用 Sonarr 的用户都安装它。

FlareSolverr

FlareSolverr is a proxy server to bypass Cloudflare and DDoS-GUARD protection.

FlareSolverr 也是一个代理，它帮助 Jackett 解决向 indexer 的请求能否成功的问题。一些 indexer 为了保护自己免于 DDoS 攻击或减少爬虫请求，会使用 Cloudflare 或一些其他的安全防护服务，如果不做处理，直接请求很可能因触发人机验证而失败。FlareSolverr 就是为解决这类问题诞生的。

在 Jackett 中添加新的 indexer 时，会根据站点情况提示是否需要接入 FlareSolverr 以绕过站点的保护措施。

qBittorrent

大部分影视资源都使用 BT 协议进行点对点传输，因此我们也需要一个 BT 下载器，qBittorrent 就是一个很好的选择，它的功能非常全面，且与 Sonarr 有很好的接入支持。如果你已经运行了其他下载器如 Aria2，甚至 QNAP/Synology 自带的 Download Station，那么你也可以参考 Sonarr 支持的下载器列表，尝试进行配置。（我并没有成功使 Sonarr 和 QNAP Download Station 协同工作起来）

部署说明

各个组件介绍完毕，现在让我们进入正题，了解如何配置和部署整个 Sonarr 服务组。

Sonarr 现代化地提供 Docker 镜像的部署方式，因此这个章节将会围绕 Docker 相关的技术进行说明。虽然 Qnapclub 也有 Sonarr 的安装包，但经过一番糟心的尝试，最终我只得出一个结论，那就是以后部署任何服务，能 Docker 就尽量 Docker 吧。

我们的部署方案的基本原理是在自己的电脑上通过 Docker 和 Docker compose CLI 对远端 NAS 上的 Docker host 进行操作。这要求读者具备基础的 Docker 相关的知识。

QNAP/Synology 等 NAS 系统提供的 Docker host 与标准实现基本没有差异，因此我们可以直接使用 Docker 官方软件包提供的命令行工具。你也可以使用 NAS 提供的图形化界面，但一则那样在部署多个服务时非常不便，二则如果你了解了如何使用 Docker compose 部署，自然也可以反推到图形化界面的操作方式上。

Docker context

为了与本地的 Docker host 区分开，我们要为 NAS 上的 Docker host 创建一个新的 context。

harrogath 是我的 NAS 的 hostname，可以使用 IP 代替

# 创建 context
docker context create harrogath

# 更新 context 的配置信息
docker context update harrogath --docker "host=tcp://harrogath:2376,ca=$HOME/.docker/ca.pem,cert=$HOME/.docker/cert.pem,key=$HOME/.docker/key.pem"

QNAP 的 Docker 需要通过证书来访问，因此要在 Container Station 的设置中下载证书。

完成 context 创建后，通过 use 命令切换到 context，之后所有的 Docker 命令都是与 NAS Docker 进行通讯

docker context use harrogath
docker context ls
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT                               KUBERNETES ENDPOINT   ORCHESTRATOR
default             moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                                         swarm
harrogath *         moby

Images

目前主要有两个组织在维护 Sonarr 及相关服务的 Docker 镜像，linuxserver.io 和 hotio.dev, 我选择前者作为本次部署的镜像源。下面是使用到的镜像列表，可以在其页面上查看镜像的使用说明。

• linuxserver/sonarr - Docker Image | Docker Hub
• linuxserver/jackett - Docker Image | Docker Hub
• linuxserver/qbittorrent - Docker Image | Docker Hub
• flaresolverr/flaresolverr - Docker Image | Docker Hub

Hierarchy

Sonarr 和它的朋友们需要对 NAS 的存储进行读写，因此在运行服务之前，首先要理解并设计一个好用的目录结构。

我们需要在 NAS 上创建一个 AppData 目录，作为容纳所有服务产生的文件的根目录。AppData 所在的 Volume 建议选择适合存放大量媒体数据的精简卷 (Thin Volume)。

AppData
├── jackett
│   ├── config
│   └── downloads
├── qbittorrent
│   └── config
└── sonarr
    ├── config
    ├── downloads
    ├── media
    ├── torrents
    └── usenet

在 AppData 之下，依次为 sonarr, jackett, qbittorrent 创建目录，每个目录下必须有 config 子目录，用于存放配置文件。flaresolverr 由于是纯网络代理服务不需要对应目录存在。

下面对各个服务的 NAS 目录与容器内目录的映射关系进行说明

表示为 NAS Directory -> Container Directory

• sonarr
  • sonarr/config -> /config: 配置文件
  • sonarr -> /data: 数据文件，可在 Sonarr 管理界面向下创建子目录
• qbittorrent
  • qbittorrent/config -> /config: 配置文件
  • sonarr -> /data: 数据文件，与 sonarr 保持一致，以便 sonarr 在重命名或移动文件时可以直接使用 qbittorrent 返回的文件路径
• jackett
  • jackett/config -> /config: 配置文件
  • jackett/downloads -> /downloads: 默认种子文件下载路径

Compose file

以我正在使用的 docker-compose.yml 文件作为示例，你可以复制下来修改自己的版本，只需要将 /share/CACHEDEV2_DATA/Misc/AppData 替换为自己在 NAS 上创建的 AppData 路径即可。

端口的配置需要额外注意，这份配置中我尽量保持各服务默认配置端口不变，若与已有服务冲突，修改到未被占用的端口即可。例如 QNAP 自带的 Download Station 已占用 6881 端口，因此我将 qbittorrent 修改到了 16881 端口。

version: '3'
services:
  sonarr:
    image: linuxserver/sonarr
    ports:
      - 8989:8989
    volumes:
      - /share/CACHEDEV2_DATA/Misc/AppData/sonarr/config:/config
      - /share/CACHEDEV2_DATA/Misc/AppData/sonarr:/data
      - /etc/localtime:/etc/localtime:ro
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    restart: unless-stopped
  jackett:
    image: linuxserver/jackett
    ports:
      - 9117:9117
    volumes:
      - /share/CACHEDEV2_DATA/Misc/AppData/jackett/config:/config
      - /share/CACHEDEV2_DATA/Misc/AppData/jackett/downloads:/downloads
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    restart: unless-stopped
  qbittorrent:
    image: linuxserver/qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
      - WEBUI_PORT=8080
    volumes:
      - /share/CACHEDEV2_DATA/Misc/AppData/qbittorrent/config:/config
      - /share/CACHEDEV2_DATA/Misc/AppData/sonarr:/data
    ports:
      - 8080:8080
      - 16881:6881
      - 16881:6881/udp
    restart: unless-stopped
  flaresolverr:
    image: flaresolverr/flaresolverr
    environment:
      - LOG_LEVEL=info
      - LOG_HTML=false
      - CAPTCHA_SOLVER=${CAPTCHA_SOLVER:-none}
      - TZ=Asia/Shanghai
    ports:
      - 8191:8191
    restart: unless-stopped

Run

一切准备就绪，执行以下命令:

docker compose up

这会启动所有服务并 attach 到终端输出日志，方便查看服务的运行日志。等确认所有服务稳定运行后，加上 -d 参数使其运行在后台。

docker compose up -d

使用说明

下面对各个服务的 Web UI 的使用方法进行说明，以我的 NAS hostname harrogath 为例展示服务的访问地址。

Jackett

打开 http://harrogath:9117, Jackett 的界面展示如下:

使用方式非常简单，Jackett 已经将这个世界上绝大部分 indexer 都内置了，只需要点击 Add indexer 搜索并添加即可。除了部分有访问限制的 indexer 需要配置外，基本上都可以一路点击确认完成添加。之后在 Sonarr 中对接时，需要复制订阅 URL 和 API key，参照截图中所示即可。

我目前使用了 4 个 indexer，其中 Bangumi Moe 和 dmhy 用于下载动画番剧，EZTV 和 RARBG 用于下载美剧。

为了使 FlareSolverr 发挥作用，我们还需要将它的 URL 填在最下方的配置中，然后点击 Apply server settings 保存生效。

qBittorrent

打开 http://harrogath:8080，使用默认用户名密码 admin:adminadmin 登录。

打开 Tools » Options，将 Default Save Path 修改为 /data/downloads。这样做的目的是为了使 qBittorrnet 所记录的文件路径与 Sonarr 保持一致，以便不需要额外配置就能使 Sonarr 的重命名功能正常工作。若你不希望修改下载路径，或使用的是其他下载器，可以参考 Remote Path Mappings 来解决路径不一致的问题。

在 Options 中切换到 BitTorrent 选项卡，将 Seeding Limits 下的 “then” 修改为 “Pause torrent”，这是为了避免 Sonarr 在删除种子时产生冲突。“When ratio reaches” 代表做种分享资源的比率。BT 协议提倡共享精神，既然从别人那里获取到自己想要的资源，理应做出回馈。推荐将分享率设置为 2.0，即上传量为下载量的两倍之后停止分享。如果你担心硬盘过度损耗，可以将比率降低。(也可以修改为 0 关闭做种功能，如果克服了道德感的约束)

Sonarr

终于到了追番大计最核心的组件——Sonarr，但先不要急，在添加番剧前，还有一些设置要做。

1. Indexers

   • 将先前在 Jackett 中添加的 indexers 逐个对接到 Sonarr，使用 Torznab 协议。
   • Bangumi.moe 的配置展示，URL 和 API Key 都是从 Jackett 中复制过来。需要注意的是， Categories 是影视剧的分类，应该留空，而在 Anime Categories 中勾选所有与番剧相关的分类项。
     • 若不确定自己要搜索在资源属于哪个分类项，可在 Jackett 中使用 Manual Search 来确认
   • rarbg 的配置展示，由于 rarbg 是影视剧 indexer，我们需要在 Categories 中勾选分类项而将 Anime Categories 留空

2. Download Clients

   • qBittorrent 配置展示。Host 最好填写 IP，使用 hostname 可能会失败。

3. Profiles

   默认只有 English，需要添加一个中文的 Profile 以在添加番剧时设定语言。

4. Media Management

   这个设置关系到下载的文件能否被 Plex 或其他 media server 识别，但别被眼花缭乱的设置项吓到， 我们只需要关心下图红框圈起的部分。

   • 首先打开 Rename Episodes 功能
   • 然后配置 Anime Episode Format 和 Season Folder Format，这代表番剧被重命名后的文件名格式和上级目录格式。你不用关心源文件的名称如何被 Sonarr 解析，你只用知道它自信并出色地完成了这项脏活，让我们可以使用变量定义想要的文件和目录名称。这里我使用的是 Plex 的 TV Show Files 格式，实现的结果如下:
   • 最后配置 Root Folders，它们在添加番剧的时候会用到，作为放置番剧的目录。你可以根据自己的需求设置多个，一般来说设置两个将影视剧和动画番剧分开存放即可。还记得我们在 docker-compose.yaml 中配置的目录映射吗？这里的目录 /data/media/anime tv 在 NAS 中对应的是 AppData/sonarr/data/media/anime tv，在 Plex 添加媒体库时不要忘了如何找到它。
   • Optional: 文件重命名时，Sonarr 默认采取移动策略，这样会导致 BT 下载器无法继续对资源做种，为了避免这种情况，在 Media Management 页面打开 Advanced Settings，找到并打开 “Use Hardlinks instead of Copy”，这样既保留了下载资源的原始路径，又不会额外占用硬盘空间。

5. Connect

   实现自动化追剧的目的是为了不需要人工检查剧集的更新情况，因此通知是必不可少的。Connect 可以连接许多通知服务，让你第一时间知道剧集何时上线，资源何时发布，何时完成下载、可以观看。下面说明如何对接 Telegram 获取通知信息。

   • 在 Telegram 搜索机器人 @BotFather，按照提示创建一个新的机器人，获取 API Token。我的机器人名为 @reorx_notify_bot。

   • 创建一个群组，将 bot 加入到群组中，请求接口 https://api.telegram.org/bot<TOKEN>/getUpdates, 取出返回结果中的 result[0].channel_post.chat.id 作为 chat id

     方法来自 How to obtain Telegram chat_id for a specific user?

     • 2022-08-11 updated: 也可以通过将 @getidsbot 邀请到群组中来获得 chat id，这个方法更加简单便捷

   • 在 Sonarr 中添加 Telegram connection，勾选自己关心的通知类型，一般至少会选择 On Download，代表新剧集下载完成的时间。

   • 配置好后，就可以通过 Telegram 第一时间掌握番剧的更新情况了。

开始追剧

配置完成，现在可以开始追剧了。下面以「盾之勇者成名录 第二季」为例说明在 Sonarr 添加番剧的过程。

打开 TheTVDB.com, 搜索到你想要追踪的番剧的页面 The Rising of the Shield Hero，获取 URL 中的最后一段 the-rising-of-the-shield-hero 作为在 Sonarr 搜索关键词。

打开 Sonarr，在左上角的 Search 框中输入 the-rising-of-the-shield-hero，点击搜索结果，进入添加番剧的界面。

1. Root Folder: 选择先前在 Media Management 中设置的 anime tv
2. Monitor: 由于我们只想看最近的第二季，因此选择 Only Latest Season
3. Quality Profile: 选择 HD-1080p 或其他你需要的格式/分辨率
4. Language Profile: 选择 Chinese
5. Series Type: 选择 Anime，这里对应的是添加 Indexer 时的 Anime Categories 选项，告诉 Sonarr 从 Indexer 的 Anime Categories 中搜索资源。如果使用默认的 Standard（对应 Indexer 的 Categories），将会导致无法搜索到资源。
6. Season Folder: 勾选，为了对应 Plex 要求的目录结构
7. Start search for missing episodes: 勾选，这会使 Sonarr 在添加番剧后立刻根据 Monitor 所设置的条件开始搜索资源。也可以在添加完成后在详情页手动点击触发。

完成添加后，点击番剧进入详情页。

1. 点击放大镜图标对其所在的 Season 进行剧集搜索。
2. Status 列的图标说明
   • 🕓: 尚未播出，不会进行监控
   • ⚠️: 已播出，硬盘中还没有资源，正在进行监控
   • ☁️ 或进度条: 已开始下载
3. 书签符号有填充代表该季处于正在监控状态，无填充代表未监控，可以点击手动设置为监控

在 Sonarr 首页可以看到各个番剧的追踪状态，蓝色代表标记追踪的剧集都已下载完成，红色代表有缺失，正在持续监控中。

下载了一些资源后，我们打开 Plex，将 anime tv 对应的路径添加到「动画」Library 中，Plex 就会开始自动扫描文件、刮削元数据、下载中文字幕了。

大功告成，在 Plex 上愉快看番吧☺️。

番外

Sonarr 的其他朋友们

• Radarr Radarr 是 Sonarr 的兄弟项目，Sonarr 专精于追剧，Radarr 专精于追踪电影
• Bazarr Bazarr 用于自动下载字幕文件，由于 Plex 本身具有这个功能，以及大部分动漫资源都有内置字幕，因此不是特别有必要部署
• Lidarr Lidarr 是音乐专辑的追踪和下载器，适用于喜欢收藏本地音乐文件的用户
• Readarr Readarr 是电子书的追踪和下载器。我看书不多，偶尔需要看的书一般从 zlibrary 下载，Calibre 足够满足我的管理需求。

LunaSea

LunaSea 是一个 Sonarr 和 Usenet 生态圈的远程控制器，能让你在手机上查看 Sonarr / Radarr / Lidarr 的资源和放送时间表。

Seedbox.io

在得知我最近的折腾经过后，我的好朋友 wzyboy 向我科普了一种名为 Seedbox 的 hosted service，提供开箱即用的 BT 下载和家庭媒体服务器，并能带来以下几点好处：

• 免于折腾和维护诸多服务/服务器
• 发扬 BT 分享精神的同时无需损耗自己的硬盘
• 规避 P2P 下载资源的版权问题

其中有一家服务商叫 seedbox.io, 它们的服务器包含本篇介绍的所有组件。如果你有兴趣的话，可以通过这个 affiliate link 注册和购买他们的服务。

结语

Sonarr 和它的朋友们还有许多功能，本篇旨在引导用户完成最基本的自动化追番配置，就不一一介绍了，有兴趣的读者可以自行探索，欢迎在评论区留言分享。

近两年来，在家办公越来越融入到我们的生活，家庭网络和服务的搭建也逐渐从以往对 Geek 的刻板印象，变成或许没被意识到，但人人都有的需求。照片存储、数据备份、远程控制、环境监控、智能家居、多媒体娱乐…这些无一不是我们的日常所需。往后我会写更多这方面的文章，将我使用 NAS 改变生活方式的过程记录下来。The digital life has just begun.

References

• WikiArr
• TRaSH Guides

Revision

• 2022-04-19: created with “使用 QNAP Download Station”
• 2022-05-02: added “使用 Sonarr 和它的朋友们”, finished “部署说明”
• 2022-05-04: finished “使用说明” and the whole article
• 2022-08-11: added using @getidsbot to find Chat ID in Telegram

since I use the “Sliding Panes” plugin, there’s always a bunch of files open in my Obsidian. Sometimes I switch to Obsidian with a very clear goal of opening a specific file, so I press Command+O and type in the file name to find it. Because I don’t want to check whether the file is open or not (rather say there’s no way to check open files quickly), I always press Command+Enter to open the file in a new pane. As this process repeats, some files will have redundant panes, the panes are bloated and the workspace ends up being a mess.

Quick Switcher++ is a very helpful tool, it allows me to search for open editors by typing a special prefix (edt by default) in the quick switcher. But after using it a while, I still feel it’s not very intuitive, I want the “search any file and open it” action and “search for existing open file and activate it” to be combined into one thing to use.

The solution

I forked Quicker Switcher ++ and added a new setting item called “Include open files”. When it’s enabled, the switcher modal shows all the open files at the top with a different color style. If the open file is chosen, make that pane active; Other suggestions behave the same as the original, opening the file in the active pane.

I’ll test this new feature in my workflow for a while to see if it’s actually useful. Meanwhile, I’d love to hear from the Obsidian community. What do you think about it? Do you have a better idea for my problem? Feel free to leave a message to me.

Heptabase is the most promising note-taking app for me in recent years. The idea of combining bi-directional links, cards, and whiteboards together is mind-blowing. The word note-taking or knowledge base is not accurate to define it, in fact, it’s more like a tool that aims for boosting the process of thinking.

Traditional note-taking tools are keen on providing more than enough ways for dumping your thoughts into notes, but lack methodologies on how to retrieve and use notes. The way Heptabase organizes and interacts with the data is what really empowers the user to think and write more efficiently.

Back to the video at the beginning, after watching it I noticed a very interesting feature. I can’t stop thinking of it and really wish to have something similar in other note-taking or PMK tools like Obsidian (yeah, I’m an Obsidian fan).

The feature

Here’s the walk though of that amazing feature:

• On a whiteboard, select several cards you would like to refer to
• Right-click on them and choose “Open in new tab”, a new page with a left-right split layout appears. The first card selected shows on the left; others show on the right as a folded list.
• Click on the + sign button on the top menu bar; a new card is created on the left side, and the card that previously shows on the left is automatically moved to the card list on the right.
• You can fold/unfold notes while browsing the right side, and drag’n drop blocks to copy them to the left side.

This is the best way I’ve ever seen to think and write a note while referring to many other notes. In other note-taking tools, take Obsidian for example, I can split the panes, but it is not convenient to organize the workspace well for more than 3 notes. As new panes are growing, it will become more and more interruptive to switch back and forth.

Even if I managed to build up a tidy workspace, it’s still very frustrating to switch to another context. Obsidian has the functionality to manage workspaces, but you have to manually save before switching, otherwise, the context will be missing. In Heptabase, all the workspaces are clearly shown in the sidebar, switching around is fast and easy as a breath.

Conclusion

It’s a shock to me how easy and intuitive it could be in Heptabase to create a workspace and focus on writing. I believe anybody with note-taking experience could learn something from Heptabase’s design.

Obsidian is still the best PKM tool for me. I’m going to create a plugin to achieve a similar workflow in Obsidian, possibly by creating a special pane that can add and show notes in an accordion. Stay tuned for the updates.