新博客及迁移方案

date
Jul 17, 2022
slug
blog-migration
type
Post
status
Published
tags
日记
Notion
技术
summary
生活越来越忙碌,要面对的事越来越多,近期面临大环境影响下的工作变动,深感大块专注时间的宝贵,能花在博客本身折腾上的时间也越来越少;但仍希望能通过记录,看到一些脉络和体系,让自己对自我有更清晰的认知。也以此对 blog 做一个更新换代,让写博文的心智负担小一些。
old_url
上回 提到我希望捣鼓一个新博客、和集中的文章列表页面的想法,也察觉到我近期日常的表达欲也特别旺盛,碎片的脑洞分散在各种不同社交平台,让自己有些抓不住重点,想来需要试着多聚焦一些,以一个主题开始写点什么,在赛博世界与现实之间慢慢找到一个属于自己的定位。
生活越来越忙碌,要面对的事越来越多,近期也面临着大环境和工作的变动,深感大块专注时间的宝贵,能花在博客本身折腾上的时间也越来越少;但仍希望能通过记录,看到一些脉络和体系,让自己对自我有更清晰的认知。也以此,对 blog 做一个更新换代,让写博文的心智负担小一些。
当然,再如何简洁都好,既然是开一个网站,维护 Web 健康的链接和交流状态自然也义不容辞,一些必要的开放协议还是需要支持的,也希望内容尽可能充分地被搜索引擎索引。
整理下来主要是三个目标:
  1. 能把分散的想法集中于一处,更加聚焦
  1. 让自己更专注于内容,减少在博客本身技术细节中内耗
  1. 基本的 Web 元素(URLRSS FeedOpen Graph)的支持,及 SEO 优化

URL、路径与域名的考虑

博客更核心的一点,在于交流与分享,因此 URL 的稳定性是一个核心重要,避免因为自己站点的变动使得自己 or 他人原有的信息“链接”失效。URL 的结构上除了协议(都走 https:// )外还有 HostPath,对外分享的 Host 即为域名。
Path 的规则大概有这几种:
  1. 直接用 ID:类似 /archives/:cid,这是 WordPress 与 Typecho 默认的方式,这个 cid 来自于数据库的自增ID,会有点暴露底层细节,当后端背后实现不同时,会有些别扭
  1. 日期 + 标题:类似 /2022/07/15/title-xxx 的模式,Hexo 默认是这么干的,但觉着这种情况,日期和标题都是较大的变数,且在中文语境下,中文标题会变成 URL encode 的字符串,一大堆百分号堆积在一起,基本丧失了可读性
  1. 自定义 slug:类似 /slug-example ,与上面的 ID 类似,一篇文章对应一个 slug,这个 slug 由用户提供,兼具唯一性和灵活性,slug 的来源可以是文件名、也可以写在博文里面
以前没考虑太多,一直在 Typecho 默认方案 1 一直这么过来,现在想想,或许于我而言,Typecho 已完成了它的历史使命:目前我自己在 Web 已有一定经验积累,再在 PHP 博客领域折腾,边际收益已越来越小,成就感少了,感到的更多是繁琐与内耗,写博客在自己其他事务的博弈中,逐渐变得弱势。
域名的注册方面,主要考虑记忆与输入的方便,尽可能短且带一些特殊含义,且价格不能太离谱,原本的 blog.izgq.net 确实是有些长了,寻思着应该换一个。
zgq 搜索了一下,3位短域名热门后缀基本都已被注册,亦或是被高价拍卖;冷门后缀看到 zgq.ink,ink(墨水)、link(链接),似乎有一点记录与交流的寓意,想想还蛮心水,就入了。
由此得出新博客的博文 URL 的模式:
https://zgq.ink/slug-example
UPDATE:
考虑到这个域名未来还可做各种项目的展示用,从目录路径规划的角度考虑,加上“博文”(Post)这一层含义,因而改成 https://zgq.ink/posts/slug-example 的形式

部署姿势

选择

以尽可能减少技术细节上的人力内耗为原则,优先考虑静态站生成器,并且使用现在发达的网站托管服务部署(如 GitHub Pages、Vercel、Netlify 等,最近更偏向于 Vercel)。
一开始想着直接用 Markdown 生成页面,捣鼓了一圈 Hexo 及其周边,主题大都不尽人意,要么配置过于复杂,要么过于简陋、移动端样式难以接受,再开发一套主题的时间消耗有些不太现实。
想起前些日子看到的 Nobelium,它以 Notion 的 database 作为展示的数据源、然后用 Next.js 的 ISR 接口,缓存已有的 API 请求,实现动态内容的快速渲染;UI 上较为简洁大方,没有什么花里胡哨元素;也支持 RSS、Open Graph,并且代码本身不复杂,有需要可以自己魔改加点 React 组件啥的,可以说非常贴合我目前的需要。
Notion 是我这几年来比较喜欢的工具,它的核心思想集中在 “block” 这一概念,存储结构上每个 block 都有其唯一 id,所有的元素都由这一个个 Block 构建而成,它组织信息的粒度恰到好处,帮助我们理顺现实中的信息的关联关系,更好地构建个人的知识体系。
这一概念也如 Git 使用 sha1 hash 去组织版本库的思路,基于 id 去存储链接关系,比通过具体内容去建立联系的成本要低不少。
进一步而言,类 Notion 的模型衍生出了 Block Protocol 标准,若能以此发展出一个开源和标准化的方案,将信息的组织从 Web 以 Page URL 为 id 的 Page 粒度 细化到以 内容元素 hash / uuid 为 id 的 Block 粒度,实现更细致的互联互通,还是很有意思的。

操作

参考 Nobelium 官方的指引(也可以看这个 教程),包括域名绑定等十几分钟就完成了,博文写的差不多,给对应文章 block 的 “是否发布” 字段改个状态就完事,可谓异常方便。
浅浅试用了下,基本都很舒适,同时发现一些优化点:
  • 图片处理走 Notion 官方地址中转,大陆访问稳定性可能欠佳
  • 没有 404 等页面,找不到页面情况下,流量压力会传导至 notion 一方(目前已补充)

评论与 PingBack

Nobelium 默认提供了三种添加评论的方式:
  • Disqus:非常成熟的评论系统,但需要注册,且墙内被屏蔽
  • 依赖 GitHub 的:Gittalk、utterances
  • 第三方、自建:Cusdis
对比之下觉得 Cusdis 挺不错,体验上与 WordPress / Typecho 特别接近,且支持自己搭建,原始在 Typecho 的数据库的部分的老评论迁移过来也不是一件难事。再一看作者是 Randy,能感受到前辈的技术追求,回归技术而非商业为导向,长远来看还是值得信赖的。
传统动态 blog 有提供 PingBack 的机制,当文章被引用时,引用的博文会通过 PingBack 通知到源网站,但暂时没找到比较好的方案。初步看有个 Webmention 的协议在做类似的事情,光有协议,概念未深入人心的时候,就还是力不从心,先保持观望吧。
UPDATE:
博客的评论区迁移要处理的细节要比想象中复杂,好在 cusdis 已搭好基本的架子,未来有空的时间,再考虑进一步维护和贡献吧。
关于评论的迁移踩过的坑,请看这篇

旧 blog 迁移与 URL 映射

原则还是尽可能维护过去这个 blog 站点与外界交互的积累,包括外链、搜索引擎索引等,因此域名仍需要保留,考虑做一个简单的 301 跳转的映射服务。
接下来也在陆陆续续抽空迁移一些文章过来,标注好原文和要跳转的链接,批量导出一个映射 map,再在 vercel 上跑一个站点,把原 blog.izgq.net 的访问转移过来。
UPDATE: 这里用了 Next.js 自带的 redirects 配置 实现,向后兼容链接在数量上是固定的,映射关系可以直接写死在代码中。

后记

这么一番操作下来,写文的精力消耗上已与其他各种平台持平,总的来说,很感谢发达的开源社区,尤其 Nobelium 的贡献者们。
在技术上,一点感触很深的是,当 JAMStack 概念深入人心,分工也逐步明确,把 Web 世界的交互都收归于一套技术栈下,业务逻辑等也可以以微服务的形式,更加纯粹地躺在 JavaScript 构建的中间层背后,而无需让 Web 开发者太费精力去纠结其他语言的细节。
特赞 Vercel 这类云服务,当自己想要部署的网站非常多的时候,它的优势就特别明显,省去了各种开机器跑 node 服务、反向代理、域名、证书配置,还要担心服务挂掉、证书过期等等一系列的繁琐事务,个人站点而言免费服务基本足够。
不管怎么说,愿笔耕不辍,对新网站的定位也是:
A place to think and write.
 

© zgq354 2014 - 2022 | CC BY-NC-SA 4.0 | RSS