summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBigCoke233 <hi@guhub.cn>2025-12-18 17:39:05 +0800
committerBigCoke233 <hi@guhub.cn>2025-12-18 17:39:05 +0800
commit950c8d1bf9e7b8d05a88dadabd11269c5a4e054f (patch)
treee0fae9f9c6f7042294e73e0e8d3fdaa70f4976ef
parent9be27a8cca3dc95b7658b4452ed2ab76a4eaa531 (diff)
docs: update markdown files (2025-12-18 17:39:04)
Former-commit-id: d4add4c55cd64e2c116b8f03483ff8242178ce75
-rw-r--r--content/essays/关于一切的纯文本解决方案指南.md (renamed from content/_drafts/关于一切的纯文本解决方案指南.md)91
1 files changed, 84 insertions, 7 deletions
diff --git a/content/_drafts/关于一切的纯文本解决方案指南.md b/content/essays/关于一切的纯文本解决方案指南.md
index e75c05b6..efc55e87 100644
--- a/content/_drafts/关于一切的纯文本解决方案指南.md
+++ b/content/essays/关于一切的纯文本解决方案指南.md
@@ -1,10 +1,12 @@
---
title: 关于一切的纯文本解决方案指南
-subtitle:
tags:
-categories:
-date:
-draft: true
+ - Geek
+ - 编程
+ - 效率
+categories: 生产力报告
+date: 2025-12-18T17:38:00
+draft: false
toc: true
slug: everything-in-plain-text
---
@@ -17,9 +19,9 @@ slug: everything-in-plain-text
作为软件工程的学生,画各种流程图、活动图、时序图和用例图应该是家常便饭。在软件工程里,表达需求的方式有很多种:自然语言描述、伪代码描述,还有图表。其中,图表自然是最清晰直观的,是必要的沟通工具。
-在软件工程领域,各种类型的图表都有相应的规范。最常见的规范就是 UML,全称 Unified Modeling Language(统一建模语言),它提供了描述软件系统架构、行为和需求的标准。
+在软件工程领域,各种类型的图表都有相应的规范。最常见的规范就是 UML,全称 Unified Modeling Language(统一建模语言),它提供了用图形描述软件系统架构、行为和需求的标准。
-相关的绘图工具有很多,这里不谈国内外的各种 SaaS 软件[^1],笔者在以前最长使用的是开源免费的 [draw.io](https://draw.io/),基于 Web。使用这类基于图形界面的软件绘图的基本流程是:在左侧长长的列表中中到你需要的图形,然后把它拖拽到中间,点击它,把手指的位置从鼠标移动的键盘上,然后输入文本,然后把手指的位置从键盘移动到鼠标上,拖拽另一个图形到中间…… 在之后,你还要手动调整这些图形是否对齐、间距是否合适。
+相关的绘图工具有很多,这里不谈国内外的各种 SaaS 软件[^1],笔者在以前最长使用的是开源免费的 [draw.io](https://draw.io/),基于 Web。使用这类基于图形界面的软件绘图的基本流程是:在左侧长长的列表中找到你需要的图形,然后把它拖拽到中间,点击它,把手指的位置从鼠标移动的键盘上,然后输入文本,然后把手指的位置从键盘移动到鼠标上,拖拽另一个图形到中间…… 在之后,你还要手动调整这些图形是否对齐、间距是否合适。
在这个过程中,有不少时间都浪费在了调整图形上,而不是用在「传达信息」上。而且,可供选择的图形种类很多,用户完全有可能用错图形,画出不符合 UML 规范的图。
@@ -285,7 +287,82 @@ document/
把文档发送给别人的时候,提交 `output.pdf` 就好了。
-##
+### Quarto
+
+[Quarto](https://github.com/quarto-dev/quarto-cli) 是一个基于 Pandoc 的命令行工具,可以用 Markdown 编写静态内容,也可以用 Python、R 语言、Julia 和 Observable 等技术生成动态内容,可以生成各种格式的博客文章、网站、幻灯片,以及 HTML、PDF、Word 和 ePub 等格式的电子书。
+
+如果有更专业的写作和发布需求,比起用 Pandoc 自己搭框架,Quarto 可能是更成熟的选择。不过我没有用过这个工具,不清楚体验如何。
+
+## 制作幻灯片
+
+制作幻灯片(或者说演示文稿、PPT)的纯文本解决方案已经有很多,我比较熟悉的是 [sli.dev](https://sli.dev/),可以用 Markdown 编写幻灯片。用纯文本做幻灯片的好处与编写文档类似,可以更专注内容而不是纠结格式问题。此外,Slidev 还提供内置的代码高亮,可以编写 Vue 组件放在幻灯片里,对开发者非常友好。我能想到的使用场景是,自己用 Vue 做了一个可运行的原型组件,比起截图,嵌入可交互的组件会更有表现力。
+
+Slidev 本质上是提供了一种新的幻灯片形式,虽然可以导出为 PPT 和 PPTX 格式(甚至可以导出为单页应用),但最佳的效果还是在本地运行一个 Web 服务器做演示。所以,在需要提交 PPT 文件或者必须把 PPT 拷贝到其他设备里做演示的场景下,Slidev 可能没有那么好用。
+
+此外,Obsidian 也自带幻灯片插件。被 Markdown 的水平分割线 `---` 分开的内容就会在幻灯片里被分成两页,没有拓展语法,可自定义的空间也比较小。如果能接受幻灯片里只有基础的文字和图片(甚至没有动画)的话,也不失为一种选择。不过 Obsidian 是不能导出 PPT 文件的。
+
+![](https://image.guhub.cn/uPic/2025/12/glcTGC.png "Obsidian 的核心插件设置项,其中有一个 Slides 插件")
+
+我自己演讲的时候,比较依赖演示文稿的动画和稍微复杂一些的多栏排版,所以较少使用上述的纯文本解决方案。兴许以后可以尝试先用 Slidev 做出可用的原型,之后再使用 PowerPoint 或者 Keynote 添加动画。
+
+---
+
+## 为什么用纯文本?
+
+### 可以使用 Git 做版本管理
+
+如果一篇文档的编写周期很长,或者说需要多人协同编写,而参与者又都是会使用 Git 的开发者的话,使用纯文本的编写方案,就可以利用 Git 的版本管理能力管理文档的历史版本,上传到远程仓库后也就自带了多人协同能力。比起价格昂贵的多人办公 SaaS 软件,让本来就有 Git 使用经验的开发者使用自己习惯的编辑器协同编写文档,难道不是更高校更具性价比的选择吗?
+
+任何用纯文本编写和储存的内容,都可以用 Git 管理。《[Just use cURL](https://justuse.org/curl/)》这篇文章表达了对 Postman 的鄙夷,作者认为把 cURL 命令放在 `.sh` 脚本文件里,就能够代替 Postman 的云端同步和团队协作功能。
+
+> **Q:那团队协作怎么办?**
+>
+> 这是个文本文件。把放进 Git 里。你知道吗,那就是那个你本来就应该在用的东西?现在你的 HTTP 请求有了版本管理、代码审查和差异对比。免费的。真是革命性的改变。
+
+<details>
+ <summary>原文</summary>
+
+> **Q: What about team collaboration?**
+>
+> A: It's a text file. Put it in Git. You know, that thing you should be using anyway? Now your requests have version control, code review, and diffs. For free. Revolutionary, I know.
+
+</details>
+
+如果你不喜欢 Git,那就去用 [Jujutsu](https://github.com/jj-vcs/jj),或者别的什么你喜欢的版本管理工具。
+
+### 拥有 100% 的数据掌控权
+
+纯文本是开放的文件格式,任何设备都能读取纯文本格式。你的数据不会被强制储存在云端,不会有科技大厂分析或出售你的数据,你想把文件放在哪就放在哪。
+
+### 文件体积小
+
+PDF 文件和 PPT 文件的磁盘占用是 MB 级别的,简单的 PNG 图片往往有几百 KB,Word 文件的体积要小一些,但也没必要那么大。如果以上内容全部都用纯文本表示,只在必要时渲染成需要的格式,那么占用的磁盘空间将会非常小。如果和你协作的人也使用相同的技术将纯文本转换为 PDF 文稿或其他格式的文件,你们只需要通过网络传输 KB 级别的数据,文件只会在本地膨胀到 MB 级别,而且在工作完成之后,完全可以只保留原本的纯文本文件,删除结果文件。
+
+这相当于下载软件时只拉取源代码和 Makefile(或者 Homebrew Formula),软件本体在本地编译,是很高效的选择。我注意到有不少人的 U 盘或移动硬盘里装着爆满的 Office 文件,如果全都换成纯文本,PPTX、DOCX、PDF 等文件在用过之后就直接删除,需要的时候再从纯文本中编译,那储存的成本将会降到非常低。
+
+### 操作方便
+
+精细复杂的图形可能没办法用纯文本解决(不然就跟前端工程师调试 CSS 一样难受了),但我相信日常工作中的不少操作都可以用纯文本简化。编写文本的过程中,手指完全不需要离开键盘操作鼠标,这对熟练使用键盘的人来说无疑提升了效率——如果你只需要敲五次键盘,打出 `A-->B` 这一行代码,为什么要在冗长的图形选择菜单里翻找自己需要的图形,然后拖拽到中间,然后把手指放到鼠标上点击图形,然后把手指放回键盘按下 `A`,然后…… 你应该明白我的意思了。
+
+## 除了绘图、文稿和幻灯片,余下的一切
+
+不要忘了,除了 Markdown,JSON、YAML 和 TOML 也都是开放的文本格式,这些格式能够表示几乎所有结构化的数据,只要有能够读取这些数据的软件,理论上,你可以用文本格式编辑任何东西、做任何操作,比如管理 DNS 记录。
+
+你可以参考 [Sukka 的实践](https://blog.skk.moe/post/dns-as-code-via-dnscontrol/),他使用 DNSControl 和 GitHub Actions 实现了用配置文件管理 DNS 记录的工作流,完全抛弃了各个服务商的用户体验参差不齐的 DNS 管理面板。以下
+
+```javascript
+D(
+ 'skk.moe', REG_NONE, DnsProvider(DSP_VERCEL),
+ DefaultTTL(300),
+
+ ALIAS('@', 'skk.moe.cdn.cloudflare.net.', TTL(300)),
+ ALIAS('www', 'www.skk.moe.cdn.cloudflare.net.', TTL(300)),
+);
+```
+
+*不过,把 JavaScript 代码说成是纯文本好像有点牵强呢……*
+
+我在文章最后想要抛砖引玉一下:如果你遇到了一个比较复杂的需求,比起构建图形界面,先不妨思考一下是否有必要。如果你的目标用户都是熟练编写代码的黑客,纯文本、Markdown、JSON 甚至 JavaScript 和 Lua 等脚本语言,是比图形界面更好的选择。
[^1]: SaaS:Software as a Service(软件即服务),可以简单理解为商业软件,一般以订阅制为商业模式。