关于本站 

Last Update: 2024-06-16

写在前面

这个页面也集中回答邮箱收到的,被问了很多次的问题。

很多读者找到这里是为了看李守中翻译的文档。为了方便读者,李守中单开了一个 翻译 模块,读者可以从页面顶部进入。

站点描述

该站点为李守中 (联系方式: [email protected]) 的个人站点。

最初,为方便在线查阅笔记,这个站点出现了。后来,李守中也把一些自己写的/收集来的文章放在这里。

但是,李守中水平有限,请诸位务必谨慎参考。

是否提供 RSS?

没有做 RSS 的打算。站内文章多为笔记类型,站点的主要目的也是为资料的在线查阅提供方便。

这意味着,站内文章的内容会少量多次地更新。用 RSS 不停地给你们推内容相似的文章,很烦。

为什么觉得有些内容莫名其妙,看不懂?

李守中在制作笔记的时候根本没有考虑除李守中以外的,任何人的阅读体验。

所以,看不懂李守中的某些笔记是非常正常的事情。如果读者有疑问需要解答,可以发邮件联系李守中。李守中会尽量回答。

为什么几乎整个站点都没有图?

好问题。诚然,图片的信息密度更高,信息传递相较于文字也更加直观。但是,对应地,制作精良的图片也需要相当多的时间和精力。

在李守中能用文字清晰表达的情况下,李守中不想花太多时间和精力来制作图片。

同时,图片远比文字占用的硬盘空间大,传输图片也比传输文字消耗更多的网络与计算资源。再加上,多数情况下,文字,已足够描述李守中的思想。这些因素叠加在一起最终导致了李守中很少在笔记里用图片。

当然,要表述复杂逻辑的话,还是图片比文字更省事。

简言之,因为李守中穷且懒,在文字表达能力够用、写出的东西理解起来不费劲的时候,就不用图片了。

为什么不使用更现代的 UI 设计?

好吧。被问的是,为什么 UI 那么丑… 有两个原因。

第一,李守中希望站内文章可以被 w3m 等 text-based 浏览器正常显示。使用现代感很强的设计的话 UI 一致很难做。

第二,李守中喜欢类似于 Windows 2000 的那种简单、耐看的,信息密度极高的 UI,不喜欢大片的空白。

所以,在 UI 方面,李守中选择基于文字来做。纯文字嘛,视觉刺激总是弱一些。但是,讲道理,写这版在浏览器端不使用任何 JavaScript、克制地使用 css、只使用纯文字 UI 的站点还挺费劲。

站点用了什么技术?

站点一共有过五版。第一版是用 Golang (gin, goldmark, cron) + Bootstrap + ZTree + highlight.js 组装的。但后来发现 Golang 的坑还是有点多,就整个用 Java 重写了,用的全是 spring boot, freemarker, flexmark 等等常规且常用的组件,UI 部分就是用自己写的 CSS 简单排个版 + 体积更小的 prism.js 做代码高亮。这就是第二版。

一直到第三版之前,笔记格式一直都是 Github Flavored Markdown。但随着李守中的笔记越来越多,对于排版的要求也越来越高,这时候 Markdown 不够用了。排除 Markdown,程序员间出名的排版方式中,除了 latex 就是 org mode 了。又由于 latex 的编辑体验不如 org mode,所以,最终,笔记被迁移到了 org mode 上。连带着,主力编辑器也由 VSCode 变成了 Emacs。

但还有一个问题,Java 没有解析 org mode 的包。而李守中又不想自己写 org mode 解析器,但想要笔记能被正常访问又得用 org mode 解析器把 org 文件渲染成 HTML 文件。这问题有个死循环。既然问题无解,那么另一个思路就是解决提出问题的人 (指 Java)。所以,李守中最后抛弃 Java,直接用 org mode 自带的 ox-publish 生成了一个静态站放在 Nginx 下面。

这次直接把后台简化到消失,站点生成之后自带基础样式,自己再写点 CSS 简单排个版、改个字体就能看,非常方便。但是这个方案的坑在于,虽然使用 org 原生支持的 htmlize 可以在 org file 导出时自动给代码块加高亮,但当 emacs 以 batch 模式 (non-interactive mode) 启动的时候,emacs 不会加载内部样式,而 htmlize 读不到当前 emacs session 中的样式的话,就会使用最简单的样式 (只有斜体、粗体、下划线和黑色默认字体)。所以,李守中就只能用 org-html-htmlize-generate-css 导出 emacs 的内部样式到 CSS 文件之后,再在每个导出的 html 的 head 块中以加载外部 CSS 文件的方式来加载 htmlize 的代码高亮。这就是第三版。(不用自己写后台逻辑真省事啊…)

半年多以后,李守中重新写了一下 emacs 的配置,主要目的是提速 (各方面的),emacs 也从 27.2 升级到了 28.2 (眼馋 28 对 CJK 字符的 word-wrap 优化),然后问题就来了。htmlize 中的 org-html-htmlize-generate-css 方法自 emacs 28.1 开始无法导出 emacs 的内部样式,emacs 28.2 official release 都有了,这个 bug 还没修。所以放弃使用 htmlize 的李守中重写了一下 org-html-src-block 这个负责导出 org file 中的代码块的函数,让最终得到的代码块可以被 highlight.js 渲染,接着用第一版的代码高亮方式。这就是第四版。(ps. 不用 prism.js 是因为,凭李守中的知识储备,适配 highlight.js 的工作量更小。)

再后来啊,org mode 也不够用了。用 latex?到现在为止还没有从 latex 到 html 的成熟的渲染方案,而且 latex 太重了,几千几万字的文章还不至于用 latex。突然,李守中意识到 markdown 内可以混入 html 和 css 代码来影响页面的最终显示效果。所以,所有文章又被改回了 .md 格式,需要特殊排版的地方就手写 html 和 css。兜了个大圏,又回来了。写到这李守中都被自己逗笑了。下面就是决定怎么把 markdown 文件给读者看了。

用回 java 后台?现在的服务器内存剩余不多了,再跑个 java 程序得升配置。加钱?那必不可能。用回第一版的 golang 后台?资源占用倒不大,但这一版后台的文章存储结构和 UI 都要重写,不 dei 劲。最好还是把站点静态化。用 hugo?可定义的东西太少。后续还想用 vue/react 做点在线工具放出来用。查了一圈,发现 Astro 的 SSG 模式可以满足要求,也支持独立引入 vue/react 来用,灵活性是足够了。但值得吐槽的是,Node.js 代码真费内存,一个静态站生成器,李守中总共才写了不到 1000 行代码,在 40 多秒的构建时间里吃掉 400-500M RAM… 啧,资源占用赶上第二版 java 后台了。看在它只在短暂的构建期间吃资源的份上,凑合用吧。所以,各位当前浏览的这个,用 Astro 生成的站点就是第五版。

本站页面由 Nginx 分发,使用 CloudFlare 的免费 CDN 做缓存。SSL 证书由 acme.sh 管理。写好的文章通过 SFTP 上传到服务器,每天 4:00 (GMT+8) 左右定时更新。

这几次迭代导致了当前的站点结构简单地不能再简单,并没有什么很奇怪的操作和搭配。(所以老多人问这个有啥意义…)