起因是我给 AI 投喂了这样一个设定：

经过多轮逻辑审计和“语言宪法”的约束，我们最终确定了一套逻辑严密、类似编程代码的粘着语架构。

这个语言名字也是 AI 命名的，根据构词法来理解，Nu- 是新的意思，-sila 是语言，所以 Nusila 的意思就是新语言。

一、 语言宪法：新世界共识架构

《Nusila 简明宪法》不仅是语法书，更是这个虚构社会的“底层协议”。

第一章：核心哲学

• 中立性：Nusila 旨在消除历史包袱，不偏袒任何地球母语。
• 易学权：成年人必须能在 3 个月内掌握交流，逻辑性永远优于习惯性。

第二章：语音铁律

• 极简音位：全语仅限 11 个辅音 (p, t, k, m, n, s, f, h, l, w, y) 与 5 个元音 (a, e, i, o, u)。
• 辅元(CV)结构：每个音节必须是“一辅一元”（如 Mi, Sa）。严禁辅音堆叠，严禁以辅音收尾，词根内部也必须严格遵守 CV-CV。
• 一符一音：拼写与发音绝对 100% 对应。

第三章：语法逻辑

• 零例外原则：100% 规则化，不存在任何“不规则变位”。
• 词性激活接口：词根必须通过后缀 -a (名), -i (动), -o (形) 激活。
• 双元音防火墙：第一个出现的双元音（如 ai, oi）是词根与语法的分界线，实现流式解析。

第四章：词汇与平权

• 绝对平权：取消性别、阶级代词。
• 生物/技术界限：代词强制区分生物智能 Lo (或 Lona) 与机器智能 Ma (或 Loma)，确保生存指令安全。
• 群体边界：区分包含式“咱们”(Miyu) 与排除式“我们”(Milo)。

第五章：多模态输出

Nusila 天生支持四种接口：拉丁接口（速记）、音节方块（几何视觉文字）、线性特征码（二进制流）和战术手势（真空/无声通讯）。

二、 语言细节：积木式构词

词根与后缀

Nusila 的词根是静态的，必须通过接口“激活”：

• -a：名词化标记 -> Mita-a (眼睛/视线)
• -i：动词化标记 -> Mita-i (看)
• -o：形容词化标记 -> Mita-o (视觉的)
• -u：副词化标记 -> Mita-u (视觉上地)

动词详解

Nusila 的动词后缀挂载顺序严格固定，像函数调用一样精准：

[词根] + [接口 -i] + [语态] + [体] + [语气] + [时态]

极限压力测试：

Mitailoyekapinu：意为“（咱们）可能不得不被迫互相观察了”。

三、 句法：核心信息优先

定语后置

名词永远在前，形容词在后（如：Wafaa samao，水 洁净的）。

• 抗噪性：在极端环境下，先听到“水”比先听到“洁净的”更能让大脑快速定位。
• 流式处理：大脑不需要缓存形容词，读到哪，理解到哪。

状语的前置与后置

副词接口 -u 的位置决定了语义侧重：

• 前置（动词前）：强调动作的方式或性质。Mi fusu-u sapai-nu (我快速地宣告)。
• 后置（句尾）：强调动作的结果或程度。Mi sapai-nu fusu-u (我宣告得很快)。

逻辑连接词 (H-族)

为了避免和语法后缀冲突，逻辑词统一由 H 开头：

• Ha(和), He(但), Ho(因), Hu(或), Hi(若)。
• Te / Tu：逻辑括号。用 Te 开启从句，Tu 关闭，彻底解决长句嵌套歧义。

四、 数字与疑问系统

数字系统 (0-9)

单音节设计，兼顾全球权重与抗噪辨识度：

疑问体系 (Wa- 通配符)

采用“通配符原位原则”，不改变语序：

• Wapona (谁 = 疑问+人)
• Wamota (什么 = 疑问+物)
• Wanuta (何时 = 疑问+时间)
• We (是否 = 句首是非问助词)

五、 AI 沟通时产生的词汇

结语：Yu Faloinu!

事实上，在 AI 设计语言的过程中，他自己经常不遵守我们定下的宪法，总是要我提醒他。对于 AI 犯错，我们在 Nusila 中就可以说：Yu Faloinu。Yu 是指你，falo 是词根错误，i 表示动词，nu 表示正在进行，合起来就是你正在犯错。

后续如果我还有兴趣的话，可能需要建立一个 GitHub 仓库来记录了。

這當然很不好。可是究竟要說點什麼呢，又感覺沒什麼好說的。我也試過寫點週記，談談一週見聞或所做之事，卻往往不見下一週。大抵因為下一週乏善可陳，於是不了了之。不然嘗試寫一下月記？

細細思索，這兩年是不是沒做什麼事呢？

不然。

• 在開源項目上，我將 Authlib 的 JOSE 功能拆分出來生成了 joserfc 這個庫，斷斷續續已經發佈到了 1.2.2 版本。
• 設計了一個 Sphinx 的主題 Shibuya，上面的 joserfc 的文檔就是用的這個主題。
• Typlog 在重新設計 V4，目前自測中。

以前，我還會寫文章介紹一下我的項目。現在這些項目我竟沒有去介紹一下，想想真是不應該。

除了介紹自己的項目，還能寫點什麼呢？近來有什麼所思所想，又有什麼洞見或者觀察？似乎沒有。這大約就是所謂的咸魚人生吧。意識到了，似乎就應該翻一下身，來曬曬另一面。

前幾天有個客戶發郵件給 Typlog，來咨詢一些問題。我回復後，過了好幾天也沒收到客戶的反饋。於是我又用自己的私人郵件去問客戶有沒有收到我的回復，答案是沒有。我有點不好的預感，於是用 Typlog 的郵箱給自己的私人郵箱發了一封郵件，不出意外地進入了垃圾箱。我們的郵箱設置沒有任何問題，DKIM、SPF、DMARC 都正常設置好了，Gmail 也全部給我們標記為 "PASS" 了，但是這封郵件就是進入了垃圾箱。

我的預感沒有錯，而且我也意識到問題出在了哪裡。進入 AWS SES 後台查看了一下，域名的口碑(domain reputation)出了問題。Typlog 的聯絡郵箱使用的是 Google Workspace，通知郵件是使用的是 SES，他們都是使用的 typlog.com 這個域名。通知郵件服務導致域名出了口碑問題，影響到了聯絡郵箱。

為何我們的通知郵件服務會出問題呢？一直以來我都忽略了一個問題，我很早的時候就注意到 Typlog 有很多的垃圾註冊，但是我沒有太在意。一是我們的註冊接口是有頻率限制的，他也註冊不了多少；二是我們是一個付費服務，他註冊了不激活也做不了什麼事。直到 Typlog 的聯絡郵箱出了問題我才意識到我忽略了什麼。

因為註冊的時候，系統會發送激活郵件給用戶。如果你並沒有註冊某個服務，但是你收到了註冊郵件，你有可能會將這封郵件標記為垃圾郵件。當標記的人多了，郵件商便會認為這個域名是個發垃圾郵件的域名。即使沒有人標記垃圾郵件，但是你的郵箱經常發送郵件到不存在的郵箱地址，郵件商也會認為這個域名是個發垃圾郵件的域名。而且還有找回密碼這個接口，也是會發送郵件的。這樣就導致你發送的郵件數量更多了。更有甚者，有的機器人還會點擊激活鏈接。也許這個機器人還順便舉報了一下垃圾郵件呢。

你開發了一個服務，運營了一段時間，總是會遇到一些黑產機器人的。我還是沒有理解為什麼會有這些垃圾註冊機器人，他們會通過什麼方式為黑產者生產利益呢？

不幸中的萬幸，Typlog 的郵件列表服務是另一個域名，沒有影響到用戶的郵件列表功能。

現在我需要重建 Typlog 的域名口碑，這會是一個漫長的過程。下面是我的計劃：

1. 首先要防止機器人的垃圾註冊，我給註冊賬戶和找回密碼頁面添加了 Turnstile 驗證。
2. 將通知郵箱和聯繫郵箱的域名分開。
3. 在註冊頁面添加文字說明，讓用戶檢查一下垃圾箱，以便用戶能正常註冊
4. 尋找朋友們的幫助，用 Typlog 的聯絡郵箱和朋友們交流，請他們標記這封郵件不是垃圾郵件

如果你有更好的建議，歡迎給我留言。也希望這篇文章能幫到新的開發者。如果我再開發一個新產品的話，我會在一開始就執行如下計劃：

• 不要使用 root domain 作為通知郵箱，比如域名是 example.com，可以使用 noreply@accounts.example.com 作為通知郵箱
• 要用驗證碼服務，比如 Turnstile，hCaptcha，reCaptcha 之類的
• 關注產品的各種狀態

我們知道 Cloudflare Email Routing 可以接收郵件然後轉發到你指定的另一個郵箱，但是並不能發送郵件。這樣的話，我們就不能使用自己的個人域名郵箱了。所以要搭配一個方案，讓我們可以用自己的域名發郵件。所以我另外註冊了一個 Gmail 來發郵件。

下面是我遷移的整個流程：

備份郵件

首先我們需要備份個人域名郵箱里的郵件，如果你沒有什麼重要的郵件的話，也可以不備份。不過最好還是備份一下。這裡我選擇將郵件導入到我新註冊的 Gmail 里。如果你已經有一個 @gmail.com 的郵箱了，這一步可以省略。不過我還是註冊了一個全新的 Gmail，這樣比較清爽。

進入 Gmail 的設置裡面，選擇 Accounts and Import，在下面可以找到 Check mail from other accounts，點擊 Add a mail account。在彈出的對話框里輸入自己的郵箱，按照引導會進入填寫 POP 服務的頁面。

按照官方文檔，你需要填寫的信息：

• 用戶名：你的郵箱
• 密碼：你的郵箱密碼
• POP 服務器：pop.gmail.com
• 端口：995
• 要求 SSL：是

我們需要先開啓個人域名郵箱（Google Workspace Gmail）里的 POP3 功能。到你的個人郵箱設置里，選擇 Forwarding and POP/IMAP，然後開啓 POP 服務。

但是可能還是無法成功，這是因為 Gmail 的安全機制導致的。雖然官方文檔里說密碼使用郵箱的登錄密碼就可以了，但其實不行。這裡有兩個解決方案：

1. 使用 App password
2. 修改賬戶安全等級

在下面的章節里會介紹如何創建 App password，這裡先介紹一下修改賬戶安全等級。因為我們這個 Google workspace 賬戶最終是要銷戶的，所以修改賬戶安全等級並沒有什麼影響。進入賬戶安全中心，激活 Less secure app access 即可。

再次嘗試添加 POP 郵箱賬戶，應該就會成功了。你需要等待一段時間才能備份完所有郵件。也許睡一覺，明天再繼續？

開啓 Cloudflare Email Routing

當郵件備份完後就可以開啓 Cloudflare Email Routing 了。進入 Cloudflare，選擇你的域名，進入 Email Routing 設置。

比如你註冊的 Gmail 叫 example@gmail.com，你的個人域名郵箱是 me@example.com，上面的表單可以填寫：

• Custom address: me
• Destination: example@gmail.com

然後根據 Cloudflare 的提示，三步後就可以開啓 Cloudflare Email Routing 了。現在，當別人發郵件給 me@example.com 時，你的 example@gmail.com 郵箱就會收到郵件了。

個人域名發件人

最後我們需要讓發件人使用我們自己的域名。這一步與上面的備件郵件有些類似。進入 Gmail 的設置中心，選擇 Accounts and Import。在 Send mail as 里選擇添加一個新郵箱。

比如我添加自己的郵箱 me@lepture.com，根據提示一步一步走，會進入最後的 SMTP 服務器設置：

使用 AWS SES

之前介紹的 Gmail SMTP 方案（在文章最下面）沒有 DKIM 驗證，會導致郵件進入垃圾箱。我們可以使用其他的 SMTP 服務來發送郵件。比如 AWS SES，因爲 SES 會提供每個月 3000 封免費郵件，這對於個人用戶來説絕對夠用了。

首先你需要注冊一個 AWS 賬戶，這裏就不介紹了。注冊後，到 SES Dashboard 裏面添加自己的域名，比如我的：

下一步，設置 DNS，讓 SES 支持 DKIM 認證。你將需要設置類似如下的 CNAME。注意，在 Cloudflare 裏面設置 CNAME 時要關閉 Proxy。

接下來，我們為這個域名創建一個 SMTP 登錄賬戶：

只需要一步一步跟著 AWS 的步驟來，你就能創建出 SMTP 登錄賬戶和密碼。之後，再將這個 SMTP 賬戶登記到 Gmail 裏面就可以了。

我們需要設置：

1. SMTP Server: email-smtp.us-west-2.amazonaws.com
2. Port: 465
3. Username：AWS SMTP Username
4. Password：AWS SMTP Password

完成後，可以在設置頁面里將個人域名郵箱設置為默認發件人。

另外，你還可以設置一下 MAIL FROM 域名，如果沒有設置的話，收件人會看到你發的郵件 mailed-by: us-west-2.amazonses.com。

使用其他 SMTP

除了 AWS SES，還有其他 SMTP 服務選擇。比如 SendGrid，比如 Alibaba Direct Mail。

• SendGrid 提供每天 100 封免費郵件。
• Alibaba Direct Mail 每個阿里雲主帳戶每日可獲 200 封免費郵件發送額度。

測試

最後，我們使用自己的域名郵箱發送一封郵件試試。下面是我收到的測試郵件示例：

可以看到，SPF、DKIM 都成功了。

下面是使用 Gmail SMTP 的方案，請謹慎使用。

這裏我們可以直接使用當前的 Gmail 賬戶，比如 example@gmail.com。

我們需要設置：

1. SMTP Server: smtp.gmail.com
2. Port: 587
3. Username：你的 Gmail 郵箱（就是你當前在用的這個郵箱）
4. Password：等一下，這裡需要創建一個 App password

在上面的最後一步需要填寫一個密碼，由於 Gmail 的安全機制，你不能直接填寫賬戶密碼，這裡需要使用一個 App password。

1. 進入賬戶安全中心
2. 激活兩步驗證（2-Step Verification)：

激活後，進入 2-Step Verification，在頁面的最下面有一個 App passwords，進入後創建一個 Mail 的 App password 即可。

然後在密碼填寫框里使用這個生成的密碼即可。完成後，可以在設置頁面里將個人域名郵箱設置為默認發件人。

[漢字(かんじ)]
[漢字(かんじ)](https://jisho.org/search/漢字)

The benefits are obvious:

1. The markup looks pretty and easy to understand
2. It works well together with links

However, the syntax for separated ruby annotations is a little complex:

[[漢(かん)][字(じ)]](https://jisho.org/search/漢字)

While in mistune v3, I've added a ruby plugin for multiple annotations with the below syntax:

[漢(ㄏㄢˋ)字(ㄗˋ)]
[漢(かん)字(じ)](https://jisho.org/search/漢字)

You can group all ruby texts in [] which can reduce the use of punctuation characters.

Typlog has been updated with mistune v3, you can use ruby syntax right now in Typlog. Here are the rendered results with the ruby markup syntax:

漢ㄏㄢˋ字ㄗˋ with zhuyin, 漢hàn字zì with pinyin, and 漢かん字じ with hiragana.

In the Typlog admin portal, there is a region visit metric that displays country flags via emoji. It looks terrible on Windows. Here is how would it look like on Windows:

There are several ways to fix this problem:

• Display country flags with <img> tag: https://github.com/hampusborgos/country-flags
• Using CSS sprits with class names: https://github.com/lipis/flag-icons
• Render emoji with web fonts: https://github.com/talkjs/country-flag-emoji-polyfill

I prefer the web font way, although this repo contains only a few stars on GitHub. I didn't use the code provided by country-flag-emoji-polyfill, it is the woff2 font I'm using directly in CSS. The font is a subset of "Twemoji Mozilla".

We would load the web font only on Windows because Mac and Linux can display country flags emoji well. In this way, it would reduce the HTTP requests and net bandwidth, though the font is quite small.

A simple JavaScript is required:

if (/windows/i.test(navigator.userAgent)) {
  document.body.classList.add('win')
}

This code will add a win class to the <body> tag. We would only use the web font for .win in CSS:

@font-face {
  font-family: 'Twemoji Country Flags';
  unicode-range: U+1F1E6-1F1FF, U+1F3F4, U+E0062-E0063, U+E0065, U+E0067, U+E006C, U+E006E, U+E0073-E0074, U+E0077, U+E007F;
  src: url('https://cdn.jsdelivr.net/npm/country-flag-emoji-polyfill@0.1/dist/TwemojiCountryFlags.woff2') format('woff2');
}

body {
  font-family: var(--user-defined-font), sans-serif;
}

.win {
  font-family: "Twemoji Country Flags", var(--user-defined-font), sans-serif;
}

Here is what the region visit metric looks like on Windows now.

也許是身處疫情的自我隔離，也許是漫漫冬季的蕭瑟，也許是自我間歇性的抑鬱。之前的幾個月裡，整個人如在泥潭，想要掙脫卻越陷越深，什麼都不想做，不想工作，不想起床，不想吃飯，不想洗澡，不想睡覺。現下終於恢復了，趁著這個時候紀錄一下，寫點流水帳，也算是活在了人間。

作息調整

告别了昼夜颠倒的生活，作息終於規律了起來，現在也算是早睡早起了。一天的時間安排大致如下：

• 自然醒，時間跨度比較大，大致 6:30 ～ 8:00
• 早餐，可能是烤麵包，可能是出門吃，也可能不吃
• 學習日語，是的，我又一次開始學習日語了，大致是 9:30 開始
• 處理 Typlog 的 bug，或優化代碼，或寫新功能
• 下午，處理真正的工作（養活自己的）
• 晚餐後，看情況，可能還是在為 Typlog 工作，可能是解決 GitHub 上的 Issue，也可能休閒
• 11:00 ～ 12:00 睡覺

以上安排比較彈性，實際上會有一些出入。

日語學習

不記得是第幾次學習日語了，這次是在 NHK 上學習《簡明日語 2015 》，每天學習一到兩課，目前學到第九課了。這次至少要將這本書學完吧。

一點新知分享，こんにちは的漢字寫法是今こん日にちは，こんばんは的漢字寫法是今こん晩ばんは。所以日語的問安並沒有「安」字，亦如我們說早安時會說「早」而省略掉「安」字。當然，我們不會簡略地說「晚」。

Typlog

Typlog 最近做了一些優化，也新增了一些功能。

• Typlog 變快了，當然你可能也感受不到，反正我們服務器的壓力變小了點。
• 優化了郵箱列表的任務隊列，開始記錄用戶發郵件的次數，之後會做限制，Pro 用戶每月可免費發 2000 封郵件。
• 跳轉服務支持 wildcard matching 了。
• 自動鏈接 embed 服務支持 App Store、IMDb、豆瓣電影以及所有支持 Open Graph 的網站了。

因為豆瓣有中國特色的圖片防盜鏈設置，豆瓣電影的卡片會出現圖片無法加載的問題，這是由於豆瓣設置了 referrer 校驗。但是在現代瀏覽器里，這種校驗是沒有意義的，除非限制必須帶有特定的 referrer。我們可以通過 referrerpolicy="no-referrer" 來防止瀏覽器發送 referrer 信息。

<img referrerpolicy="no-referrer" src="..." />

黑客帝国 The Matrix

莉莉·沃卓斯基 Lilly Wachowski, 拉娜·沃卓斯基 Lana Wachowski

View★★★★★★★★★☆ 9

Authlib

修復了一些 bug，發佈了 v1.0.1 版本。接下來可能會再次投入時間到 Authlib 的改進。

又到了鯉魚旗飄揚的時節了，出門的時候手機隨手拍了一張，也算是拍照了吧。

暫不言「員」字一解，且談他人回復，或曰其言「是對其他職業的貶低」。Yachen 表示否定，今撰文解釋於此：

這一表述亦是常見的，不過於「你自己心裡有鬼」，此文怕也是不妥，再次演繹了「子非魚，安知魚之樂？」和「子非我，安知我不知魚之樂？」

我們不談他人心中所想，只談文字表達。

原文 Tweet 建立了一個矛盾衝突，將程序員與收銀員、駕駛員等對立起來，而這個矛盾衝突是比較激烈的，如果沒有「這個標準對 coding 來說太低、太無趣了」一句，則衝突會低很多。分析此句，「這個標準」即是指「收銀員、駕駛員等」的標準，不異於指桑罵槐：

你們收銀員、駕駛員等的工作標準太低、太無趣了。

作者心裏是否這樣想的，我們不知，也不必評說，但是文字的表達上確實是有此意的，所以也怪不得他人誤解。這裏並沒有解釋一文裏所說的「腦力勞動者與體力勞動者」的衝突，而且腦力勞動亦有許多重復性。

再談「員」字，是否真的指「機械地反復做同一件事情的」人呢？並沒有，大家不要誤解了「員」字。員字源於二形，一是上口下貝，一是上口下鼎。其本意是指「物的數量」，這個物是什麼呢，是貝，貝是錢。而後引申為人數，比如關羽乃一員猛將，再引申指人，便有了官員、吏員。

而「程序員」之員字，當指從事某一職業的人。這一釋義倒是頗合本意，寫程序來獲得收入的人，收入是什麼，是錢，錢是什麼，是貝。那麼員字是不是可以理解為做某事來獲得錢的人呢？所以官員是做官來獲得收入的人，收銀員是靠幫別人收錢來獲得收入的人，駕駛員是靠駕駛車來獲得收入的人。

但是我卻發現了 Fireside 有一個 Hiatus Mode，可以用 $5 來托管播客，方便遷移：

告知「婊醬FM」確實需要再續費一個月才能方便遷移到 Typlog，但是可以使用這個 Hiatus Mode 來減少費用。申請後，兩個工作日依舊沒有反應，再次申請，還是沒有反應。賬戶信用卡已更新，但是賬戶依舊是 Suspended 狀態。不知道 Fireside 是否沒有人在工作，無法激活賬戶。

這樣等下去也不是辦法。據說互聯網是有記憶的（當然大國只有 404），也許可以在其他地方找回數據。先到互聯網檔案館尋找，未能找到。

再搜索，找到一個叫 Listen Notes 的地方，似乎可以一用。頁面解析起來不太方便，但是這個網站是有 API 的，遂去申請，可惜需要填寫太多資料，還不知道 API 里是否有 Typlog 所需要的全部資料。便先放在一邊，再找找別的地方，實在不行再回來申請 API key。

最終從 Breaker 處獲取到了所有數據：

將數據從 Network 里複製出來，剩下的便很簡單了，寫上幾行 Python 腳本，將數據整理成 Typlog 需要的格式導入到 Typlog 里便可以了。Fireside 那裡，即使賬戶已經過期，只要知道音頻文件的地址，音頻文件依然是可以訪問的，所以還是可以將音頻文件抓取到 Typlog 的存儲里。

這裡不得不說，Typlog 還是做得不錯的。從一開始就做了導出功能，即使賬戶過期了，網站不可訪問，導出功能依舊可用。

三年時間里，Typlog 修修改改亦有不少變化。經營日淺，多半靠著大家捧場口口相傳罷了，也只能分享一點技術方面的收穫了。

從靜態到動態

Typlog 是用 Python Flask 寫的，這一點沒有變化。初時的方案是文章內容存在數據庫里，文章發佈時，後端會讀取數據庫，遍歷文章表生成整個網站的靜態文件，這些靜態文件通常是 HTML，通過 nginx 托管。這裡可以分享一個小技巧，註冊 Typlog 後 Typlog 會給你分配一個 Typlog 的域名，在你綁定了域名後，你就有了兩個域名，需要兩個域名都可以訪問，我當時的做法是：

1. 所有靜態文件生成到一個固定的文件夾，比如 /data/build/lepture
2. 創建軟鏈接 /data/www/lepture.com 和 /data/www/lepture.typlog.com 到 /data/build/lepture
3. Nginx 配置里設置 root /data/www/$http_host

如是，當你訪問 lepture.com 或者 lepture.typlog.com 時便都可以訪問到相應的頁面了。最初設計選擇使用靜態方案是因為之前自己的博客是靜態的，而且靜態博客速度上會快。考慮到靜態緩存的問題，當時我選擇了不做分頁，採用按年歸檔的方案。這樣的好處是顯而易見的，比如 /archive/2019/，當 2019 年過後，這個頁面的內容便不會再變化了，而形如 /page/2 的設計，每增加一篇文章所有的 /page/ 頁面都要重新生成一遍。按年歸檔的設計亦保留到現在。

靜態化的方案堅持了許久，漸漸也有了些許用戶，功能也越加越多，設計亦不時變化，每次變化都需要將所有網站的所有內容重新生成一遍，用戶越多耗時越多，這樣是沒有辦法 scale 的，於是不得不考慮改成動態化。

後來發現完全是自己考慮多了，動態化後一點都不慢。我在 Nginx 的日誌里輸出了 $request_time 值，這是請求從 nginx 進入 Python 程序到返回 nginx 的時間，通常這個時間是 3ms，真的非常快，這歸功於 Typlog 的緩存設計。因為保留了按年歸檔的設計，我們的緩存非常方便處理，比如當一篇文章更新了，我們會自動清除相應的緩存，假如這篇文章是 2019 年寫的，我們同時也會清理掉 /archive/2019/ 的緩存，如果是按頁歸檔的話，就沒有如此方便了，只能將緩存時間設置得短一點。

從博客到播客

Typlog 誕生時只是一個博客服務，當時的目標是做一個有管理後台的靜態博客。主要是給我自己用，另外如果有其他人能和我一起用的話，服務器的費用便可以省下來了。之前一直在用靜態生成器來生成自己的博客，一個是圖片不好管理，需要找圖床上傳照片；一個是生成的過程太程序員了，沒有寫作的感覺，而且經常時隔很久後相應的編譯環境會出點各種各樣的問題。這便有了做一個有管理後台的博客的想法。

之後又心癢，想做一個播客節目，於是開始想方案將播客融入進 Typlog。這便是為何播客的 Feed 地址是 /episodes/feed.xml 而文章的 Feed 是 /feed.xml。因為播客是後來加入的，一開始沒有考慮到，不然文章的 Feed 應該設計為 /posts/feed.xml 的。最終自己的播客節目並沒有做出來，但是播客的功能卻在 Typlog 里生根了。

我需要感謝 Niki，他是我們的第一個播客用戶。也因為有了播客用戶，Typlog 才能一點一點改進完善播客功能。播客功能亦為 Typlog 帶來了不少用戶，博客多半隨意，播客通常會注重品牌，感謝播客的品牌效應，Typlog 亦漸為人知。

Typlog 也漸漸清晰了自己的定位，才有了我們現在首頁上的宣傳語：

最近又將圖片功能升級了，於是有了 Moments。

Admin 的三次重寫

Typlog 的後台 Admin 部分經歷了三次重寫。感謝 Vue，雖然重寫了三次，但是三次都是用的 Vue。

第一次，初版 Admin，未用第三方 UI 庫，界面簡潔，只有文章功能。

第二次，新增播客功能，Admin 變得複雜許多，之前的簡潔佈局已不再適用，於是重新開始設計佈局。當時在 ElementUI 和 iView 里選擇，不知是不是使用有誤，ElementUI 總是出現各種問題，於是選擇了 iView。

第三次，iView 越使用越不好用，如果只使用他已有的 UI 的話還是不錯的，自定義起來就會很麻煩，後來亦遇到了一些問題，也給 iView 提交了修改代碼，但是越用越覺得還是什麼 UI 框架都不用最好。於是便有了現在的 Admin，整個項目結構合理，邏輯清晰，用 Jessie 的話來說便是，Saber（項目代號） 寫起來特別省心。

善用第三方服務

Typlog 使用了許多第三方服務，比如：

1. Stripe 用來收款
2. Cloudflare Partner 綁定用戶的域名，支持 SSL
3. Sentry 收集錯誤信息
4. Google Analytics API 生成後台圖表數據
5. AWS SES 發通知郵件
6. Alibaba Cloud JP 處理圖片

這是目前使用的部分服務，Typlog 亦替換過不少服務，最典型的便是 Google Cloud Storage。這是一個大坑，慎入。初時不覺，使用量大起來後費用立刻大漲，賬單里的各種信息看不明白，這裡收一點費那裡收一點費，流量分了好幾種、存儲也分了好幾種，與 Cloudflare 里的流量數據對比，Google Cloud Storage 的流量翻了三倍，也不知他是如何計算的。後來便遷移到了 DigitalOcean Spaces，費用立刻降下來了。

之後要做圖片自動裁剪的功能，於是自己搭了一個 imgproxy。用過一段時間，時常會遇到一些問題。後來發現阿里雲 OSS 自帶圖片處理功能，於是註冊了日本區的 Alibaba Cloud，將圖片遷移到了阿里的 OSS。現在圖片 URL 上的 ?x-oss-process= 便是阿里雲 OSS 提供的功能。這一點特別好用，比 Google Cloud Storage 和 AWS S3 不知高到哪裡去了。

Google Analytics 確實是很好用的，我在 Authlib 的博客里分享過如何通過 API 讀取 Google Analytics 的數據，有興趣可以一閱。

開放互聯網

我向來支持互聯網而反對 App，能用瀏覽器的話就不下載 App 了。Web 是互聯的，App 是隔裂的。所以在做 Typlog 時會非常在意規範。比如最基本的，我們支持 Open Graph 和 Twitter Card。此外，我們還完美支持 Microdata 以及 Microformats。最初 Typlog 使用的是 Microformats 1，後來改作了 Microformats 2。

再比如我們還支持 PubSubHubbub 或者 WebSub，這樣的話當你的博客一有更新後，你的 RSS 訂閱者便會收到更新。新近，我們又加入了 IndieWeb 社會，支持了 Webmention。

未來的規劃

Typlog 一點點成長，希望他能漸漸成長到可以養活我。近期的規劃是多做一些 Pro 功能，讓 Pro 套餐更吸引人，已經規劃好的功能點：

• 搜索功能已經快完成了，還在優化 (更新：已在內測）
• 郵件列表，遷移到 AWS SES 便是為郵件列表功能做準備
• 會員服務，方案還沒有想好

感謝 Typlog 用戶們的支持與包容。

RSS feed is meant to be used by machine (apps) not by human. But people may visit a feed link directly and shout out WTF is this.

The RSS feed however can be human friendly. Take an example of my blog's RSS feed. It is simple and clean, not so scary to ordinary people.

XSL URL

We added this UI in Typlog recently. It is pretty simple with xsl. I'm not going to explain XSL in this post, instead, we can quickly decorate our RSS feeds with the famous copy paste method.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/rss.xsl" type="text/xsl"?>
<rss version="2.0">

Here you can see, the feed is styled by an external file /rss.xsl. Note here, instead of providing a shared URL typlog.com/rss.xsl, we are using a relative path here. Because it is required by some browsers for security reasons; we need to put the xsl file under the same domain, protocol and port with the RSS feed.

Next, we can inspect the source code of rss.xsl:

view-source:https://lepture.com/_style/default.xsl

XSL Template

Here is an overview of the XSL file:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:atom="http://www.w3.org/2005/Atom">
  <xsl:output method="html" version="1.0" encoding="UTF-8" indent="yes"/>
  <xsl:template match="/">
    ...
  </xsl:template>
</xsl:stylesheet>

Things to do:

1. XML namespaces: register the required namespace when you need to select it via xpath.
2. XSL template: create the UI in XHTML

XSL Methods

We will use some XSL methods to create our XHTML template:

1. xsl:if
2. xsl:for-each
3. xsl:attribute
4. xsl:value-of

Take a look at https://lepture.com/_style/default.xsl, follow the example. It is not hard to create a pretty UI for RSS feed.

我原先便有做一個播客列表的想法，不過是推薦一下使用 Typlog 的播客用戶，順便給 Typlog 做點宣傳。然而二零一九年春夏之交國內播客的異動打斷了我的方案，與其只推薦 Typlog 上的播客，何如推薦中文獨立播客。

愚聽播客並不算多，初始不過列舉三四個，幸得眾人共襄，今已數十者矣。好壞暫且不論，至少都滿足了「獨立域名」這一條件，當是時所立之唯一准則。此番定義怕是很難讓人信服，然而「這可以算是獨立播客的一個不完美但有效的定義」。

Jesse Chan 言：

愚非賢者，不敢斷言何為真正獨立的內容，亦不可能聽遍所有節目。這裡取「獨立域名」一條皆因中國播客審查之過，假使播客並沒有自己的域名，而是使用喜馬拉雅、荔枝等，其便不至於被蘋果除名，因為這些國內平台已經幫忙審查過了。

當前情形，愚不可能去評判播客內容之優劣。止以域名論之，何也？假使播客 RSS 地址不能自己控制，全仰仗平台，平台說刪就刪，何談獨立？而有了自己的域名，即使使用別人提供的服務，想移走時便可以移走，可對 RSS 地址做重定向。至少在這一點上算得獨立了。

針對蘋果國內播客政策，我以為有如下解決方案：

1. 保留現有獨立域名的 RSS 作為國際版播客，同時提供一個喜馬拉雅或荔枝等 RSS 作為特色社會主義版。
2. 且加倍鼓勵用户使用泛用型播客客戶端，如 Castro、Pocket Casts、 Overcast 等。

而我卻擔心起室友來，恐怕其會有輕生之意。希望她能堅強一點，渡過此次難關，待事件平息後還能過上正常的生活。

我這裡也不願列出原始出處，算是保護一下二位當事人。也許是一廂情願，搜一搜便可以找到的，甚至都不需要「人肉」一下。

我亦曾感嘆於互聯網之偉大，樂見社交網絡的興起。那時我們一起見證社交網絡的力量一度左右過政府的政策，恍惚間便生出了幻覺，以為公權力終於有了束縛。

萬不料網絡最終成了威逼個人的利器。公權力？那是我無法理解的力量，畢竟年輕，畢竟單純。便是前年，我亦嘗言：

確實是我孤陋寡聞，大約網絡暴力已經是一種常態了。此番卻不必號召眾人去人肉了，姓名學校公司與照片齊全。倘使是正經的媒體，人物會化名，照片會打碼，我們知道發生了這樣的事，輿論可以去批評虐貓的行為，當事人能得到教訓而不必生活於恐懼之中。

社交網絡的力量很可怕，雖然還沒有公權力可怕，個人在其面前是如此的渺小，如何使用他，這是一件值得思考的事。我們縱然無法利用他做正確的事，亦當謹慎用其作惡。

我不想分辨室友算不算是在虐貓，貓很可愛，但這不是我們支持網絡暴力的理由。

走上國際通的街道。還有深夜經營的小店，居酒屋拉麵店咖啡館。行人三三兩兩，行至人少處，終究忍不住尖叫了兩聲，權當發洩了。

不遠處聞得歌聲，是首英文歌，我也哼得起來，便慢慢向著歌聲走去。過了紅綠燈，見到是兩個年輕人在那裡唱歌，男生彈著吉他，女生捧著話筒，面前是個小音箱。我問了一聲能否坐在這裡，得到肯定的答復後便坐在了旁邊。

女生唱完後問我想聽點什麼，我說你隨意，唱你喜歡的就好了。而後便靜靜呆著，聽他們唱完一首又一首。路上偶爾一兩人丟下硬幣便走了。忽而一個大叔騎著自行車經過，又回轉回來，停下車，在對面坐下來，亦聽起歌來。兩首後過來與他們搭過話，再聽了聽也離開了。倒是以為我跟他們一起的，連忙解釋說我是外國人。

歌聲繼續，沒有人駐足，唯有微風吹拂。這那霸的夜溫暖濕潤，最是怡人。曲終人散，從錢包掏出幾張紙幣後匆匆離去。又是一個人漫無目的的閒轉。

大抵生命還是美好的。晚安。

Background

Authlib was created to replace my Flask-OAuthlib project. In my previous blog article Announcement of Authlib, the following is posted:

• Flask-OAuthlib is not designed well.

  It was caused by the API provided by OAuthLib and my poor understanding of OAuth at that time.

• Flask-OAuthlib is not maintained well.

  It was caused by the maintenance problem of OAuthLib at that time (things are better now).

That is why I started Authlib from scratch and build it as a monolithic project. Starting from scratching would provide Authlib a cleaner and better designed code base, it won't be affected by the maintenance of other projects. Being monolithic would keep specification implementation and framework integrations synchronic in Authlib, and it would also provide a better API design for integrations.

Sustainable

The original goal of making Authlib sustainable won't change. Being profitable equals being sustainable. Although I had switched Authlib license from AGPL to BSD, it is still suggested that enterprise users buy a commercial plan.

1. You will be enlisted in the security mail list to get security notification at first time;
2. Your feedbacks will get responses more quickly than community support;
3. There will be more features in the future.

There is also another way to support my work on Authlib. I'm now accepting donations and sponsorships on Patreon. Thanks for supporting my work on Authlib.

Get Updates

Version 0.11 should be released in January soon. Follow Authlib's Twitter account and subscribe Authlib's Blog to get updates.

Here is the official blog announcement: https://blog.authlib.org/2019/switch-to-bsd-license.

Happy new license, happy new year.

分享

我自己偏愛概念類的分享，以傳播為主，這次的分享亦是順帶推廣自己的項目 Authlib。下面的視頻大抵從 15:00 開始，英語口語不好講話不太流利（國語口語也不好），但是還算講清楚了。

The modern OAuth 2.0

另外 slide 可見 SpeakerDeck。

體驗

這次參加 PyCon JP 算是偶然，來日本第三年了才第一次參加。報名後才發現原來講者亦要買票的，這卻是第一次聽說，查了一下，一般 PyCon 確實都要買票，但是可以申請補助。

中途並沒有人來聯繫，也沒有提前要 slide，所以一直拖到演講前一天才寫完。也正是這一天，PyCon 開始前的一天，主辦方終於有一個活動了，邀請了工作人員、贊助商、講者去晚餐。餐廳有點搞笑，將 PyCon 寫成了 TyCon——Welcome TyCon 樣。人很多，沒有自我介紹，就瞎聊，日語不太會，只能找人講講英語，我又不太會社交，有點尷尬。不過好歹還認識了幾人。

這次 PyCon JP 規模很大，除了早上的 Keynote 沒有並行外（住太遠趕上不 keynote），下午場的演講都是 6 個場次並行的，參會者可以自行挑選。當然，我只能挑選英文場的去聽了，可選擇項就少了。

收穫

PyCon JP 這邊有蠻多台灣 PyCon 過來的志願者，有好些人差不多每個地方的 PyCon 都會去，還挺驚奇的。跟台灣的朋友聊了聊，畢竟講國語比較輕鬆，決定明年去台灣宣傳一下。

我自己的分享結束後，亦收到了幾張名片，可惜我自己沒有印名片。有一位大約是想找我做點什麼，不過好像名片弄丟了，沒辦法聯繫了。還有一位馬爾代夫來的先生邀請我去給他們團隊做一個短期的培訓，看名片上的網址還帶 gov 難道是政府人員？倒是可以考慮一下，順便去度個假，得找個空閒時間。

感想

日本這邊辦得比中國要好。首先是議題，什麼樣的都有，有適合初學者聽的，有適合中高級聽的，有公司的有社區的，比較多樣。中國的看起來都是架構師，感覺像是 Summit（峰會），而不是 Conference，話題太過厚重。PyCon 還是要多元一些，要有對初學者友好的話題。

另外一點，PyCon JP 和其他地方的聯繫比較多，比如 PyCon 台灣、印尼、新加坡等，國際化比較好。問了一下在場的人，大家都沒聽過 PyCon 中國，以為中國沒有。正巧我分享完後有北京 PyCon 的人聯繫我（我沒有時間去），幫他要了 PyCon 日本、台灣、印尼的主席們的聯繫方式，希望 PyCon 中國能走出來與其他地方多多聯繫。

預祝十月的 PyCon 中國順利。

歷史

OAuth 的歷史最早可追溯到 2006 年 11 月，Twitter 需要一套 API 的授權訪問方案，彼時並沒有一套開放的標準規範來實現 API 的授權。由 Twitter 的開發者 Blaine Cook 首倡²，最終於 2007 年 7 月完成了 OAuth 的初版草案。2007 年 12 月 4 日 OAuth Core 1.0 正式發佈。

這是 OAuth 1.0 的歷史。其後 OAuth 1.0 進入 IETF，2010 年 4 月 RFC5849 發佈。這期間，即 2009 年 IETF 成立了一個 OAuth 工作組，後來的 OAuth 2.0 正是由這個工作組創建的，用以取代 OAuth 1.0。

無論是 OAuth 1.0 還是 OAuth 2.0，他們解決的都是同一個問題，即「如何讓一個應用在用戶的授權下訪問操作用戶授權的有限資源」。

框架

OAuth 2.0 與 OAuth 1.0 並不兼容，其實是個全新的體系。不同於 OAuth 1.0，OAuth 2.0 是一個框架，而 OAuth 1.0 是一個協議³。框架，意味著開發者可以在 OAuth 2.0 這一體系里添磚加瓦，修補 OAuth 2.0 的不足，亦可以利用其構建新的協議。

時至今日，OAuth 2.0 框架體系里已經誕生了許多標準協議，亦有許多草案等待完善。除卻最初的 RFC6749 (OAuth 2.0 Framework) 和 RFC6750 (Bearer Token)，這裡列舉些許別的 RFC:

1. RFC7009: OAuth 2.0 Token Revocation
2. RFC7519: JSON Web Token
3. RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
4. RFC7591: OAuth 2.0 Dynamic Client Registration Protocol
5. RFC7636: Proof Key for Code Exchange by OAuth Public Clients

發現沒有，就連 JWT 亦是 OAuth 工作組起草的。更全面的 RFC 列表可參考 OAuth Status Page。

角色

在 OAuth 2.0 框架內，通常有 4 種角色。分別是：

1. Resource Owner：資源所有者。例如一個圖片分享網站，圖片就是資源，而圖片的上傳者便是資源所有者，通常便是這個圖片分享網站的用戶。
2. Resource Server：資源服務。提供訪問這些圖片數據的 API。
3. Client：客戶端。例如能訪問這個圖片分享網站的 iOS App。
4. Authorization Server：認證服務。在資源所有者的允許下，提供訪問權限給客戶端。

有時你能明顯感受到這些角色的存在，有時則不然。但通常這四種角色都會存在於一個完整的 OAuth 2.0 授權訪問流程里，如圖所示：

OAuth 2.0 的授權流程：

1. 客戶端提供其自身的信息，在資源所有者的允許下，向認證服務請求 Access Token。
2. 認證服務驗證通過後，返回 Access Token 給客戶端。
3. 客戶端使用 Access Token 向資源服務請求用戶數據。
4. 資源服務驗證 Access Token 有效後，返回資源數據。

須知，資源所有者的授權有多種方式，客戶端提供自身信息有多種方式，請求 Access Token 的方法亦有多種方式，便連返回的 Access Token 種類也可以有多種形態。而這些不同的方式不同的形態，在 OAuth 2.0 框架體系里是可以擴展的，隨著時間的推移，會有更多的草案變成標準，亦會有更多人提出其他草案。

玉兔隱長夜，寒蟬聒青堤。
睹物思君意，憑欄空悲淒。
杯淺迷人眼，相見何遲遲。

I didn't know such a problem until someone reported an issue to Authlib. And I can't understand the problem either. Then another person explained it to me with a project structure, I finally got it. I was terrified that lots of posts, guide, boilerplates are backward importing modules from project root __init__.py:

# project/__init__.py
from flask import Flask
from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy()

def create_app():
    app = Flask(__name__)
    db.init_app(app)

# project/auth/models.py
from .. import db

class User(db.Model):
    # define columns

The code itself will work, but when your projects grow, sooner or later you will face a cyclic dependencies problem. For instance, another extension requires to init with the User model:

# project/__init__.py
from flask_sqlalchemy import SQLAlchemy
from another_extension import AnotherExtension
from project.auth.models import User

db = SQLAlchemy()
ext = AnotherExtension(User)

Oops, a cyclic dependency occurs. Because auth.models is importing db from the root, root can not import User module. This is a common cyclic problem, not limited to Flask. It is easy to fix, but junior developers may find it very hard. So why not avoid such thing from the very begining? Actually, if you have read the official documentation, in application factories you can find this piece of code:

def create_app(config_filename):
    app = Flask(__name__)
    app.config.from_pyfile(config_filename)
    from yourapplication.model import db
    db.init_app(app)
    from yourapplication.views.admin import admin
    from yourapplication.views.frontend import frontend
    app.register_blueprint(admin)
    app.register_blueprint(frontend)
    return app

See, we put db in yourapplication.model.

I always keep this one certain rule when writing modules and packages:

That's why I submitted a ticket to Flask as soon as I found this problem. People need a guide on folder structure. And here I'm going to share my suggestions. But think it yourself, don't treat mine as a golden rule.

Functional Based Structure

There are many ways to setup your project folder structure. One is by its function. For instance:

project/
  __init__.py
  models/
    __init__.py
    base.py
    users.py
    posts.py
    ...
  routes/
    __init__.py
    home.py
    account.py
    dashboard.py
    ...
  templates/
    base.html
    post.html
    ...
  services/
    __init__.py
    google.py
    mail.py
    ...

All things are grouped by its function. If it hehaves as a model, put it in models folder; if it behaves as a route, put it in routes folder. Build a create_app factory in project/__init__.py, and init_app of everything:

# project/__init__.py
from flask import Flask

def create_app()
    from . import models, routes, services
    app = Flask(__name__)
    models.init_app(app)
    routes.init_app(app)
    services.init_app(app)
    return app

Here is a trick by me. In official documentation, db of Flask-SQLAlchemy is registered in this way:

from project.models import db
db.init_app(app)

So my trick is define a init_app in every folder's __init__.py, and unify the init progress as one:

# project/models/__init__.py
from .base import db

def init_app(app):
    db.init_app(app)

# project/routes/__init__.py
from .users import user_bp
from .posts import posts_bp
# ...

def init_app(app):
    app.register_blueprint(user_bp)
    app.register_blueprint(posts_bp)    

# ...

App Based Structure

Another famous folder structure is app based structure, which means things are grouped bp application. For instance:

project/
  __init__.py
  db.py
  auth/
    __init__.py
    route.py
    models.py
    templates/
  blog/
    __init__.py
    route.py
    models.py
    templates/
...

Each folder is an application. This pattern is used by default in Django. It doesn't mean this pattern is better, you need to choose a folder structure depending on your project. And sometime, you will have to use a mixed pattern.

It is the same as above, we can init_app as:

# project/__init__.py
from flask import Flask

def create_app()
    from . import db, auth, blog
    app = Flask(__name__)
    db.init_app(app)
    auth.init_app(app)
    blog.init_app(app)
    return app

Configuration

Loading configuration would be another issue that many people find difficult, it is also a folder structure problem. I don't know how other people are doing, I'm just sharing my solution.

1. Put a settings.py in project folder, treat it as static configuration.
2. Load configration from environment variable.
3. Update configration within create_app.

Here is a basic folder structure for configration:

conf/
  dev_config.py
  test_config.py
project/
  __init__.py
  settings.py
app.py

Define a create_app to load settings and environment variable:

# project/__init__.py
import os
from flask import Flask

def create_app(config=None)
    app = Flask(__name__)
    # load default configuration
    app.config.from_object('project.settings')
    # load environment configuration
    if 'FLASK_CONF' in os.environ:
        app.config.from_envvar('FLASK_CONF')
    # load app sepcified configuration
    if config is not None:
        if isinstance(config, dict):
            app.config.update(config)
        elif config.endswith('.py'):
            app.config.from_pyfile(config)
    return app

This FLASK_CONF is a python file path which contains configrations. It can be any name you want, e.g. your project is called Expanse, you can name it as EXPANSE_CONF.

I use this FLASK_CONF to load production configurations.

Again, Flask is very flexible, there is no certain patterns. You can always find your favors. These are just my suggestions, do not blind by anyone.

I don't like to write posts like this. But there are so many wrong guide, I hope this post can get a better SEO, so that bad posts don't mislead people.

Authlib contains everything you need to create OAuth clients and servers. It contains:

• python-requests OAuth1Session and OAuth2Session
• Flask OAuth clients integrations
• Django OAuth clients integrations
• Flask OAuth servers implementations
• Django OAuth servers implementations (not ready)
• OpenID and many other things

Documentation & Playground

No, there will be no guide on how to create an OAuth server in this post. It is hard to keep information updated in a single blog post. Instead, I've deployed a real OAuth server online so that everyone can play with.

To get a better understanding, you can read the official documentation and the source code of Authlib playground:

1. Official Documentation: https://docs.authlib.org/
2. Source Code of Authlib: https://github.com/lepture/authlib
3. Online Playground: https://play.authlib.org/
4. Source Code of Playground: https://github.com/authlib/playground

Starting from Scratch

I have several reasons to deprecate Flask-OAuthlib. But the main reason is that Flask-OAuthlib is not maintained well. And it seems things will not go well in the future. Flask-OAuthlib depends on OAuthLib which I believe is in a chaotic maintenance (although I am a maintainer too). Besides, there are many designs I don't like.

I created Authlib from scratch - from specification implementation to framework integrations. I didn't understand OAuth well enough when writing Flask-OAuthlib. However, this time, I read every RFC carefully so that there will be less misunderstanding (I'm not a native English speaker). The experience in OAuthLib helps too.

Being Monolithic

I started Authlib with a monolithic design in mind. As I've said "it is designed from specification implementation to framework integrations". Being monolithic is a feature of Authlib. I've always hated the micro modules in Node ecosystem, there are even lots of one line code modules in npm.

Being monolithic means it won't break things. When specifications changed, implementation will change too. It keeps everything synchronized. You don’t have to worry about monolithic, it doesn’t cost your memory. If you don’t import a module, it won’t be loaded.

Will it always be monolithic? It depends. As time goes and Authlib becomes mature, maybe I will separate the framework integrations from Authlib source code.

Profitable = Sustainable

Flask-OAuthlib is not sustainable. I can't spare too much time on it. That's why I created Authlib with a sustainable idea from the beginning. I hope the project will last long enough.

Profitable equals sustainable. If I can make a living on Authlib, I can spare more time on it, keeping it updated, fixing bugs, resolving vulnerable securities. OAuth server implementation is an enterprise level problem, if you are running a company, you wouldn't like to use a non-sustainable module for such an important feature. What you need is a sustainable solution.

The price model for Authlib is simple yet affordable. It is $1000/year (or $500/year if your company is small), it is just 1/10 of one month salary for one year. However, if you don't care, you can always use the open source license.

Road Map

I've released Authlib v0.3 when writing this post. It is started from Oct 21, 2017:

1. Common client and Flask client integration is available in v0.1
2. Django client integration is available in v0.2
3. Flask OAuth 2 server is available in v0.3

The next implementation will be Flask OAuth 1 server. After that, there will be Django OAuth servers, and more OAuth 2 specification implementation. I wish I can make a version 1.0 in the end of this year.

Now, head over to the documentation and play with Authlib.

余年少而家貧，無以直航，東京途次洛杉磯而適三藩。三藩多苦民，衣衫襤褸，幽幽然無所歸者，或蹲或坐或行於街市馬路也。又有果皮紙屑棄於地，臟亂差如是，不及扶桑多矣。三藩之民疑焉，每及問必答曰：扶桑乃發達國家之宗也。

余居三藩凡九日，得閒四天。

初。邀大學同窗共遊伯克利。伯克利者，加州大學分校也，是名校也。其聲名於外，世人但知伯克利，不聞加州大學也。會伯克利慶典，吹號者、擊鼓者、舞者、觀者、錯錯然聚首一地。余與同窗隨慶典行，聞其聲樂觀其歌舞，少女短着，或搔首或旋足或立於他人之肩，青春之謂也。余不得習業於伯克利，奚爲之？購伯克利衛衣，假之充數耳。

再。適東原君赴蘋果公事，相約觀金門大橋。東原君驅車，載以出行，午食於天堂洲（Paradise Cay）泰國餐廳也。金門大橋者，蓋三藩名勝，客每至，必觀之也。余不敢自欺，隨波逐流耳。觀之以高山，觀之以近海，皆賴東原君相載也。其山皆灰黃而少植被，三藩環海，乾燥如斯，何爲之？

是夜，與諸君聚於聖荷西，有飯團、Loddit、梁海、東原等君。

三。央Bao君載余行射擊之樂也。其地近聖荷西，喚曰「靶宗」（TargetMaster）。余，中國人也，未嘗近手銃也。Bao君親攜槍支彈藥，銃二彈百，余與Bao君相次射之。其聲也巨，余每射，初必入靶，次則未必，皆因初射之聲懼也。

日本十一倒不放假，究竟在家呆久了，早想著出一趟遠門。原本計劃回國去新疆玩的，機票都買好了，因為辦美國簽證，護照還在美國大使館裡，不得不更改行程。去佐渡是臨時決定的，十一的早晨，感冒還未好，小明搭了電車去往秩父，打算坐一坐蒸汽機車，路途翻看地圖，見著西邊有一個離島，便想著不妨到島上一遊，由是選定了佐渡島。

這次又是一個人的旅行，小明倒也習以為常，往年亦多是一人旅，雲南游山水、西北逛沙漠、清邁騎摩托，倒是快活。亦不知是上了年紀，還是異國的孤獨，一個人出行時常會失了興致，又或許因為日本的精緻，失之疏蕩宏博，無法暢懷胸意。

佐渡一度算作流放犯人的蠻荒之地，及至金銀礦的發現，德川幕府置佐渡奉行所直領之。明治時亦曾置縣，現下稱市，屬新潟。小明於小木港入島，両津港離島，其間不過三天，山川人物歷史風貌只得一點淺薄的認識。

小木略顯荒涼，便是十一這樣的時節，到處都是中國人，這裡卻見不著幾個遊客，入境時還見著懸了中文橫幅，上書不地道的歡迎語——歡迎光臨來到佐渡。走在路上，時而可見廢棄的房屋，斑駁的牆壁，爬了一牆的藤蔓，破窗上的蛛網，網中央安靜的蜘蛛。天又陰沈沈的，飄著點細雨。尋找旅館的路上，去城山公園散步的路上，到處散漫著這份荒蕪的詩意。

此番行程未曾預訂宿所。他在觀光案內所¹翻閱信息，看到小木溫泉有一家「かもめ莊」便記下了。在小木遊蕩，找了一家日式料理店，點了一份天婦羅的定食作午餐。究竟背著旅行包，不太方便，飯後便去尋溫泉旅館了。

可巧還有房間。這一路皆是到了當地再找的，沒有中國遊客，又是工作日，大約因為這些緣故，總是有空房。一路的溫泉旅館，和室加早晚餐，算起來真是便宜，不過一萬多日元，最貴的一回還是去了阿賀町，倒不是佐渡島上的，也不過一萬五。早晚餐又豐富，他竟擔心起會發胖來，也是，來日本後重了十斤。

かもめ莊的老闆給了他一把雨傘，小明放過旅行包便出門散步了。

宿根木的公車卻沒有了，要到五點才有一班。他那麼喜歡破落的人，不能去宿根木的舊房子散步，頗覺遺憾。本來買了三日的公車券，看看小木的情形，車次那麼少，今日大約作廢了，只得在附近走走，坐坐たらい舟，爬城山公園，再去日和山咖啡館喝點東西。

公車券要到第二日，去相川時才稍微用得多點。先是從小木坐到佐和田，於佐和田轉車去相川，到相川再坐了車去「佐渡金山」觀光。他在相川觀光案內所內查資料，問所內工作人員近處的溫泉旅館，大叔給他介紹，聽得不太懂的便用紙寫漢字，後來詢問了價格又幫他打電話給旅館，總算是確定了晚上的住所。他把包存在案內所，等公車去佐渡金山。

佐渡金山開放的坑道只有兩個，宗太夫坑與道游坑，另有別的坑是要預約的。如果只看一個坑的話，選宗太夫坑。道游坑乃明治時的現代坑，沒有太多感覺。宗太夫坑卻是幕府時期人工挖掘出的坑道，內里頗具巧工，有會動的人偶扮演當時的情景，或是轉水輪，或是敲石塊，又有做文書工作的。除卻工作情景，亦有洞內的生活再現。坑道長，一路乒乒乓乓，又有介紹工具人物的，不及細看。因為要趕著下一班公車回去，只能草草觀之。

後來才想到，如果能自己開車的話，宿根木也去得，金山坑道也可看得愜意。

回程時又去看過北澤浮游選礦場遺跡。到處都是爬山虎，綠的紅的，垂著飛碟般形狀不知名的建築上，對面卻只有綠色的，蓋滿了階梯。此處又有個技能傳承展示館，可以一睹織布的技藝。

晚間宿道游，其地不大，房間不多，卻皆是面海的，拉開窗簾便可見著。他回相川觀光案內所，所內的大叔幫他致電旅館，不一時便有旅館開車來接了。這家叫道游的旅館，溫泉池太小，沒有露天溫泉。かもめ莊的都有，還有桑拿房。不過都比不了在阿賀町住的福泉。

火車行到津川站，他在這一站下車。上車時刷的交通卡，這一站卻沒有刷卡口，到底是有多鄉下呀。翻看手機地圖，見到兩家溫泉旅館，他便選了福泉，因為看著似乎便宜點。

房間很大，臨窗有一處休息區，窗外便是阿賀野川。川水不息，反照著天空的藍，對面是山，長滿了杉樹，這時節還顯綠。福泉的露天溫泉亦是臨著阿賀野川，彷彿懸在山間，男湯的風景略遜於女湯，因為女湯沒人，過去參觀了一下。

相較起來，福泉的餐食亦是最豐富的。到底是新潟，產米的大縣，晚餐的天婦羅里居然有一例炸稻穗。說起來，新潟的米真是好吃，當時不覺得，他回家後才發覺，因為再吃家裡的米時覺得不好吃了。以前還覺得自己在家煮的米挺好吃的，過年時節回國吃過國內的米，這一對比便知道平日里自家煮的有多好吃了。這回佐渡與阿賀町的旅途才發覺，還有更好吃的米。

到福泉時不過二點。辦了手續，旅店的姐姐領著他去房間，一路介紹各種設施，他到房間放了包，姐姐泡了茶，稍微休息一下便出門閒逛了。這姐姐會點英文，又有筆紙，聊起來還算順暢，他亦在越谷住過，小明便覺得親切了許多。

麒麟山公園卻在維護，進不得，來途的「狐の嫁入り屋敷」亦閉館，真是憾事。他在麒麟山邊望見城山橋下有個老奶奶在洗東西，一時好奇過去看看，原來是在洗板栗。兩個人便聊起了天，老奶奶提到冬天時特別誇張地直呼「怖い、怖い」，逗得他直笑。

後來聽說他一個人過來玩，並且一路都是一個人時，不免可憐起來。

吃了兩日不知是誰剩下來的感冒藥，但是還不見好。下午便去診所看了醫生，開了處方藥。這是我第二次用健康保險，第一次是洗牙。

填過一點基本信息，醫生問了幾個問題，便開了五日份的藥，分四種，每種對應各自的病癥。問診費 1060，藥費 830。藥房開藥時又細緻講解了一下各種藥是什麼作用怎麼吃，可惜聽不太懂，不過開的藥單上都寫清楚了，上面的漢字信息便夠用了。

今日日語學習，自動詞與他動詞。另外記新單詞、複習舊單詞。

9.26，晴

一整天都在處方藥的副作用裏度過，昏昏沈沈的，一直想睡覺，只能做點機械類不用動腦子的工作。

9.27，晴、陰、雨

今天天氣多變，感冒還不見好。藥的副作用稍微適應了些。

聽了一期太醫來了，講兒童性教育的。憶起自己並不曾有過學習，讀書的時候好奇，常常翻字典，專門找相關的詞條來看，看詞條也是會勃起的哦。

寫了一篇博客《前端的基礎修養：ARIA Live Regions》。

今日日語學習，主要在記單詞，另外複習了形容詞的文法。

9.30，晴

本來打算今天出門旅遊的，但是感冒還沒好，只好繼續呆在家裏。

這一日便全身心投入 Typlog 上了，給 Typlog 加上播客功能。之前已經寫了部分了，今天把設計都做完了，順便重構了許多代碼。Podcast 的功能不日便可上線，早期（現在還是早期）用戶將會免費贈送一個 Podcast 功能。

之前答應了給校友會寫稿子，晚間總算把中秋聚會的稿子寫完了。

10.1，晴

六點多咳嗽醒了，已經一週了，感冒還沒好。但是我一定得出門，憋了好久，必須得出去旅遊了。

目的地還沒想好，打算先往秩父。結果途中看地圖，又決定去佐渡了。一路猶豫不決，終於還是到高崎坐新幹線至上越妙高了。在上越妙高吃過午飯後，往直江津渡口趕去。不巧差了幾分鍾，沒能趕上今日的渡輪。直江津港前邊有一家叫「みなと荘」的旅館，過去打聽了一下，還有房間，便在這邊逗留一晚吧。

房間是和室的，很大一間，因爲附近看起來沒有吃飯的地方，便訂了夕食朝食付，房間加兩餐一起 6500 日元。等到吃晚餐的時候才發現挺豐盛的，一份煎魚、一份刺身、天婦羅、青菜、漬物、蒸蛋、豆腐味噌，大約是越谷 1600-2000 價位的。不知明早的早餐如何，算起來房費便很便宜了。

終於出門了，也有了今日攝影。可惜到上越後，天氣便不太好。

這一篇還是談 Accessibility，未來亦有相當一部分這一主題的文章。由簡入繁，一點一點提高網站的可訪問性。也是因爲稍微複雜的話題我還需要學習。這一篇單講 Live Regions。

Live Regions 是什麼

現代的 Web 越來越依賴 JavaScript，頁面裏的內容亦會隨着使用者的操作發生變化，我們需要標註出哪些變化必須通知給讀屏軟件，這些需要標註的動態區域便是 Live Regions。

在實際應用裏，Live Regions 一般用作消息提醒。例如 Twitter，你可以 Inspect 一下頁面代碼，當有新的 Tweet 時會出現，在 <body> 的最下面會出現：

<div id="sr-event-log" class="visuallyhidden" aria-live="polite">
  <p>New Tweets available. Press period to review them.</p>
</div>

如果你開啓了 Voice Over¹ 或者別的讀屏軟件，這些軟件便會誦讀：

但是你在網頁裏並不會看到這段內容的呈現，因爲它 class="visuallyhidden"，與我在 aria-label 一文裏提到過 .sr-only 一樣。

aria-live

如上代碼所示，我們使用 aria-live 來標示 Live Region，它有三個可選參數：off/polite/assertive。

• off: 等同於不標示 Live Region，讀屏軟件不做任何處理
• polite: 通常使用這個設定，在用戶的當前行爲終止後，讀屏軟件發出消息通知
• assertive: 比 polite 的優先級高，當同時有其它消息時，讀屏軟件會先讀 assertive 的消息

我們看到 Twitter 的那段通知代碼正是用的 polite。但是我們偶爾也會有重要的信息，需要即時反饋，這時便可以用 aria-live="assertive" 了。例如「保存錯誤」等消息。這裏有一個消息提醒的例子，我們可以看到 Voice Over 的效果：

https://vimeo.com/235672780

1. 註：如果你在中國大陸，可能看不到這個視頻演示。
2. 註：這個 UI 庫我暫時沒有精力（財力）更新，大家看看就可以了，不要使用。

aria-atomic

aria-live 用來標記 Live Regions，以及定義它們是否打擾式提醒；aria-atomic 用來定義是否將 Live Region 當作一個整體。舉例如下：

<textarea v-model="content"></textarea>
<div aria-live="polite" aria-atomic="true">
  You have entered
  <span v-text="content.length"></span>
  characters.
</div>

假使我們不使用 aria-atomic="true"，那麼當 content 的長度發生變化時，讀屏軟件將只讀出變化的內容，亦即 <span v-text="content.length"></span>，你聽到的便是 1、2、3 等。當標記了 aria-atomic="true" 後，你聽到的則是完整的一句話：

註：使用不同的讀屏軟件或者不同的瀏覽器，得到的效果會有差異。

aria-relevant

我們使用 aria-relevant 控制讀屏軟件在何種情況下發出通知消息。它的可選參數爲：

1. additions: 當 live region 內有新增的 Node/Element 時
2. removals: 當 live region 內有 Node/Element 被刪除時
3. text: 當 live region 內的文本有變化時
4. all: 以上所有的情況

默認值爲：aria-relevant="additions text"，也就是說，如果 live region 內有節點被移除的話，讀屏軟件不會通告。這在一般情況下是合理的，但是有時我們也想知道是否有節點被移除了，比如當我們要做一個 Todo 時：

<ul aria-live="polite" aria-relevant="additions removals">
  <li v-for="(s, i) in todo" :key="i">{{s}}</li>
</ul>

當我們在其它地方的操作導致 Todo 裏的項目減少時，我們亦希望得到通知，這時需要給 aria-relevant 添加 removals 參數。

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
• http://pauljadam.com/demos/aria-atomic-relevant.html
• https://dev.opera.com/articles/introduction-to-wai-aria/

9.20，晴

今天去新宿，到一家喚作 サポート 的事務所咨詢辦公司或個人事業主的事宜。因為打算做自由職業，不想呆在辦公室里。結果卻不能滿意，辦公司需要雇人，個人事業主需要有日本公司的合同，目前都不具備。

咨詢過後，去涉谷的 Apple Store 處理 AirPods 的問題。是在上週六買的 AirPods，取出時左耳沒電，右耳有一半以上的電量。充電時當右耳充滿時左耳只有 60% 多一點。在都充滿的情況下使用，右耳還有 80% 左右時，左耳已經只有一半了。於是預訂了今天的 Genius Bar，結果 AirPods 又神奇地好了。

在 Apple Store 排了很久的隊，順便在店裡寫了一段時間代碼。Apple Store 的網絡挺不錯的，比附近的一家星巴克好多了。最終還是沒有處理 AirPods，等向一北過來時，還沒有輪到到我。畢竟 AirPods 又恢復了，就算了吧。

今日攝影

9.21，晴

昨日決定了週記事項，今日決定重啓日語學習計劃。每次都是學了點開頭，過些天便放棄了。倘使在週記里記錄一下，會不會能堅持下來呢？

因為已經有點日語知識了，跳過一些內容，先復習部分語法。今日日語學習動詞的未然形和過去形。

晚間戴 AirPods 跑步，有點擔心 AirPods，便沒跑太快。不知道跑太快了會不會掉出來。

9.22，雨

今日下了一天的雨，斷斷續續，時大時小。

寫了一篇博客《像遊客一樣生活》，這標題躺在我的 Trello 里也有好幾個月了，今天終於解決了，雖然有點潦草，得意便可。

今日日語學習，動詞的助詞，主要是 を、に、へ、で。

9.23，陰

昨晚便有感冒的跡象，今早起來喉嚨便乾疼。但是還是堅持著出了一趟門，去附近的田野里轉轉，看秋的稻穗。

晚上很早就睡下了，便沒有學日語，不過看了一章《夾邊溝記事》——許霞山放羊。九點半醒來，燒熱水喝藥，打算泡個澡，似乎煤氣出了問題，沒能泡成。

今日攝影

9.24，陰

晚上沒睡好，出了很多汗，被子翻來翻去的。到了早上感冒還沒好。

今天有一個武大校友會的活動，在龜有「中國文武學校」做月餅。中間有活動，獎勵玫瑰和康乃馨。也得了幾束，可惜沒有能送的對象。

今日攝影

Typlog 一周回顧

• 如果不喜歡 AMP，現在可以在 Labs 里關掉了
• 完善了付款流程，內測將在十月一日結束
• 後台統計數據從最近 30 天改為本月數據