• 中文
    • English
  • 注册
  • 查看作者
  • Rust 治好了我的精神内耗

    九年来,我一直用
    作为静态站点的生成工具。再往前追溯,我主要用的是Jekyll,动态页面大概是用Perl加Mojolicious和PHP加Kohana来实现。但我对这些只有模糊的印象,当时还没有git,所以很多开发痕迹都找不到了。

    如今,我终于下定决心,打算转向自己用
    亲手编写的自定义站点生成器。通过此番重写,我主要是想解决以下三个问题:

    第一,越来越慢的速度。在我的低配笔记本电脑上,完整站点的重建大概要75秒(不涉及编译,单纯只是站点生成)。我这博客上一共只有240篇帖子,所以应该不至于这么慢才对。虽然已经配备了不错的缓存系统,并且只在编辑期间对帖子变更执行更新的watch命令,但整个执行速度还是太慢了。

    第二,外部依赖项。虽然站点生成器本身是用Haskell编写的,但除了众多Haskell库之外,其中还包含其他依赖项。我的博客助手脚本是用Perl编写的,我使用sassc进行sass转换,还使用Python的pygments实现语法高亮,并使用s3cmd将生成的站点上传至S3。管理和更新这么多依赖项真的很烦人,我想摆脱麻烦,专心回归到博客内容上来。

    第三,设置问题。跟大量依赖项相关,我的博客网站有时候会宕机,必须得花时间调试和修复。有时候我脑子里刚有点灵感,系统就崩溃了,必须赶紧把网站生成器换掉。

    有些朋友可能会问,这么简单的网站还有什么可崩溃的?主要还是更新的锅,往往会以意想不到的方式引发问题。例如:

    • 在更新GHC之后,它无法找到cabal包。

    • 在运行Haskell二进制文件时,系统提示:

    或者是以下Perl错误:

    • 当Hakyll的不同版本间发生Pandoc参数变更时,就会破坏Atom提要中的代码渲染效果。我知道这些并不是太大的问题,可我只希望轻轻松松写个博文,所以能正常运行才是头号目标。

    Haskell 引发了我的精神内耗

    其实我还挺喜欢Haskell的,特别是它纯函数的部分。另外,我也很喜欢Hakyll对站点配置使用的声明性方法。以生成静态(即独立页面)为例:

    就算看不懂$ 和 >>=分别代表什么,仍然能看出我们是在从 static/ 文件夹中查找文件,再把这些文件发送至pandocCompiler (以转换原始的markdown格式)、再发送至模板,之后取消索引urls(以避免链接以index.html结尾)。

    多么简单,多么明了!

    但我已经很多年没用过Haskell了,所以每当需要在网站上添加稍微复杂点的功能,都需要耗费巨大的精力。

    例如,我想在帖子中添加下一篇/上一篇的链接,却难以轻松实现。最后,我不得不拿出时间重新学习了Haskell和Hakyll。即使如此,我琢磨出的解决方案也非常慢,是依靠线性搜索来查找下一篇/上一篇帖子。直到现在,我也不知道要怎么以正确的设置方式通过Hakyll实现这个功能。

    相信各位大牛肯定有好办法,但对我来说这么一项小功能耗费的精神也太多了,着实受不了。

    为什么选择Rust?

    1. 我喜欢用Rust,偏好基本足以决定这类业余项目的实现方法。

    2. Rust的性能很强,文本转换应该也正是它所擅长的任务。

    3. Cargo让人非常省心。在安装了Rust之后,就可以执行cargo build并等待运行结果。为什么要重新发明轮子?因为我想发挥主观能动性,试试自己能编写出怎样的静态站点生成器。这事应该不是特别难,我能借助它完全控制自己的博客网站,享受远超现成生成器的功能灵活性。当然,我也知道cobalt这类工具能配合任意语言对页面进行灵活的类型转换。我只是想在灵活之余,享受一下解决问题的乐趣。

    关于实施的细节,因受篇幅所限,我没办法在文章中完整回顾整个构建过程。感兴趣的朋友可以点击此处(
    )查看项目源代码。

    将“硬骨头”各个击破

    起初,我很担心没法重现自己熟悉的各种Hakyll功能,例如模板引擎、多种语言的语法高亮显示,或者自动重新生成编辑的页面并充当文件服务器的watch命令,有了它我才能边写作边在浏览器中查看帖子。

    但事实证明,每块“硬骨头”都有对应的理想的工具。下面来看我使用的几个效果拔群的库:

    • 使用tera作为模板引擎。它比Hakyll更强大,因为它能执行循环等复杂操作:

    • 使用pulldown-cmark来解析Markdown。对于Markdown的标准语法规范CommonMark,pulldown-cmark的表现真的很棒。虽然速度更快,但它的支持范围不像Pandoc那么广泛,所以我还得配合其他功能进行支持性扩展。这个问题稍后再谈。

    • 用syntect实现语法高亮,能够支持Sublime Text语法。

    • 用yaml-front-matter解析帖子中的元数据。

    • 用grass作为纯Rust中的Sass编译器。

    • 用axum创建负责在本地托管站点的静态文件服务器。

    • 用hotwatch监控文件变更,这样就能在文件内容变化时更新页面。

    • 用scraper解析生成的html。我的某些测试和特定转换中需要用到。

    • 用rust-s3将生成的站点上传至S3存储端。即使有了这些库,我的Rust源文件本身还是超过了6000行。必须承认,Rust代码可能有点冗长,再加上我自己的水平也不高,但这个项目的编写工作量还是比预期要多不少。(但好像软件项目都是这样……)

    Markdown转换

    虽然在帖子里只使用标准markdown能免去这一步,但多年以来我的帖子已经涉及大量pulldown-cmark无法支持的功能和扩展,所以只能亲手编码来解决。

    预处理

    我设置了一个预处理步骤,用以创建包含多个图像的图形。这是个通用的处理步骤,具体形式如下:

    我将它用于不同类型的图像集合,例如Flex, Figure 以及 Gallery。下面来看示例:

    它会被转换为:

    这是怎么实现的?当然是用正则表达式啦!

    (图像和图形解析部分太长了,所以咱们直接跳过好了。)

    扩展pulldown-cmark

    我还用自己的转换扩展了pulldown-cmark:

    我以前也做过标题降级和嵌入裸YouTube链接之类的尝试,实现起来相当简单。不过现在想想,在预处理或后处理步骤中嵌入YouTube链接可能会更好。

    Pandoc能够支持向任意元素添加属性和类,这可太实用了。所以下面这部分:

    可以转换成这个样子:

    这项功能随处都有用到,所以我决定在Rust中重新实现,只是这次要用一种不那么笼统和老套的方式。

    我在Pandoc中用到的另一项冲突功能,就是评估html标签内的markdown。现在的呈现效果有问题:

    我起初是打算在通用预处理步骤中实现这项功能的,但后来我总会忘记引用链接。因此在以下示例中:

    link 就不再被转化为链接了,所有解析都只在:::内完成。

    这样会调用一个通知解析器,它会在以上示例中创建一个 < aside
    >标签(而非 < blockquote
    > 标签),同时保留已解析的markdown。

    虽然现有crate会使用syntect添加代码高亮,但我还是自己编写了一个功能,把它打包在< code
    >标签中以支持内联代码高亮。例如,“Inside row: let x = 2;”会显示为:

    性能提升

    我没花太多时间来优化性能,但还是发现了两个性能要点。

    首先,如果使用syntect并包含自定义语法,那就应该把SyntaxSet压缩为二进制格式。

    另一点就是使用rayon实现并行化渲染。所谓渲染,就是指markdown解析、应用模板和创建输出文件的过程。Rayon的强大之处,在于它在执行这项任务时的效率只受限于CPU性能,而且易用性非常好(只要代码结构正确)。下面是渲染的简化示例:

    要实现并行化,我们只需要将iter() 更改为 par_iter():

    这就成了,非常简单!

    我也承认,这里的性能提升非常有限,真正的性能改善主要还是来自我使用的库。例如,我的旧站点使用由Python编写的外部pygments进程来实现语法高亮,而现在的替代方案是Rust编写的高亮器。后者不仅速度快得多,而且并行化难度也更低。

    健全性检查

    维护自己的网站,我才发现原来开发项目这么容易出错。比如一不留神就链接到了不存在的页面或图像,或者没有使用[my link][todo]来定义链接引用,而且在发布前还总是忘记更新。

    所以,除了测试watch命令等基本功能之外,我还解析了整个站点,并检查所有内部链接是否存在且正确(也会验证/blog/my-post#some-title中的some-title部分)。外部链接也是要检查的,但我在这里使用的是手动命令。

    在文章的开头,我列出了自己之前的一些设置问题。下面咱们就看看具体解决得怎么样。在生成过程中,我也采取了比较严苛的检查标准,尽可能避免遗漏各种稀奇古怪的错误。

    效果如何?

    在文章的开头,我列出了之前设置中的一些问题。下面咱们就一起来看具体解决得怎么样。

    • 性能方面
      现在,还是那台低配笔记本电脑,完整的站点重建(不包含编译时间)只需要4秒。性能一下子提升了18倍,这个成绩算是相当不错了。当然,这里面肯定还有进步空间——比如,我使用rayon处理文件IO,如果采取异步机制肯定还能再优化一些;而且我也没有使用缓存系统,所以每次构建时都得重新生成所有文件(但通过观察,我发现构建过程还挺智能的)。

    请注意,我不是说Rust就一定比Haskell更快,这里比较的只是两种具体实现。相信肯定有高手能在Haskell中实现同样的速度提升。

    • 单一依赖
      现在我的所有功能都在Rust中实现,不需要安装和维护任何外部脚本/工具。

    • Cargo不添麻烦
      只要在系统里用上Rust,cargo build就永远服服帖帖、不添麻烦。我觉得这可能就是低调的Rust最突出的优势之一——build系统不给人找事。

    大家用不着手动查找丢失的依赖项,牺牲某些子功能来实现跨平台,或者在构建系统自动拉取更新时造成破坏。往椅子里一躺,等着代码编译完成就行。

    Rust 治好了我的精神内耗

    虽然我发现在Rust当中,创建系列文章或者上一篇/下一篇链接之类的功能确实更轻松,但我并不是想说Rust就比Haskell更简单易用。我的意思是,Rust对我个人来说比Haskell更容易理解。

    而其中最大的区别,很可能在于实践经验。我最近一直在用Rust,而从小十年前使用Haskell完成网站创建以来,我就几乎没跟Haskell打过什么交道。所以如果我也十年不接触Rust,那再次使用起来肯定也是痛苦万分。

    总体来说,我对自己的这次尝试非常满意。这是个好玩又有益的项目,虽然工作量超出了我的预期,但也确实消除了长期困扰我的老大难问题。希望我的经历对各位有所帮助。

    原文链接:

  • 0
  • 0
  • 0
  • 168
  • 请登录之后再进行评论

    登录
  • 任务
  • 实时动态
  • 发布
  • 单栏布局 侧栏位置: