新博客及迁移方案

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

URL、路径与域名的考虑

博客更核心的一点，在于交流与分享，因此 URL 的稳定性也十分重要，避免因为自己站点的变动使得自己 or 他人原有的信息“链接”失效。URL 的结构上除了协议（都走 https:// ）外还有 Host 和 Path，对外分享的 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 - 2024 | CC BY-NC-SA 4.0 | RSS