简介
作于2023年3月31日，修订于 2024-09-16，上传于 2024-09-16。
以前和博客《博客是Coder的必需品》是同一篇文章，修订时感觉拆开对行文更好。
主要介绍了自己折腾博客的历史，也有些本科期间的回忆。
折腾博客的历史
1. 2020：探索
大二下，也就是在2020年下半年，经过疫情的煎熬和计网、软工二等等课程的拷打，我不仅产生了运营博客的想法，而且意识到自己有能力这样做。
虽然搞个博客并不是什么了不起的事。我的很多同辈、后辈可能早在高中——甚至初中，就已经建成了自己的博客。 但在用hexo+github搞了几天，第一次看到属于自己的“网站”时，我还是很激动🥰
众所周知，github在国内始终是有些限制。再加上，我从心底里觉得，自己买个服务器运维，才更像一个真正的站长。 所以很快我就放弃了这个博客，果断删库。
2. 2021：开摆
整个大三，我都在软院的魔鬼学期里度过。这段时间别说博客了，作业上也一直是ddl战士，基本是对付过去、敷衍了事。 因此，云计算课上，当老师布置作业，让同学们各自完成和展示自己的博客时，我最终就做了一个静态页面，上传了一张表情包，然后配置nginx，随便糊弄了过去。
现在回过头看，只能说4个字：自欺欺人😥
一点本科时的心声
以下是深层次的内心活动：⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄
想起大三，我不禁会这样回忆： 如果没有gxy、yxr、zs这些大佬带飞我，如果没有学长笔记，如果没有样卷，我很难撑下来。
繁多的课程，效果奇差的教学（不能完全怪老师，这么短的时间+巨大的授课内容+老师本身也很忙…），无数多的大作业，8周以后就有五六门课的期末考……
这些东西加在一起实在是扼杀人的兴趣和活力。
靠着运气（数据集成方向课给分好）、抱大腿（需求组队、软设组队）、及时开摆（编译原理）和一些奋发（OS、SE3），我居然在大三学年排名前列，13/209。
常常感觉，我的这个名次和拿高额奖学金是“受之有愧”。 但在“自有一套生存之道”的，教学体系不够成熟完善的软院，这样的投机取巧也多少带点无奈。
但我带着现在的认识重回大二、大三，真的有可能改变吗？
感觉不会，假如时间重来，我很可能还是会做同样的事。
人常常有一种illusion，有自我欺骗的冲动，有脱离现实、脱离实际的臆想。我能说现在保研的我比以前学习努力吗，能说现在的我比以前身体好吗？就算我比以前努力，就一定能取得更好的效果吗？凑合过吧。
3. 2022：尝试、折腾与突破
2022年6月22日大三结束，到9月5日开学，这个漫长而宝贵的暑假对我至关重要。我没有找到实习，也没有回家，而是决心在学校待着。 没有找到实习对我是个很大的打击，而且这并不能把责任推脱给别人。可以说软院不行，可以说22年大环境不好，但我的很多朋友——包括编程能力并不显著强于我的朋友，也都拿了不少offer呀。 虽然原因很多，但我认为最关键的一个因素还是在于：我还没有足够的觉悟、习惯和决心。
当遇到目标、竞赛和挑战，是迎难而上还是放弃；当碰到困难，是独立解决、求助于人还是逃避；当有了心得，是去系统地记录，还是零散地记录，抑或直接任它遗忘；当遇到知识点，是去深入理解原理，整理进自己的知识体系，还是浅尝辄止，抑或视而不见......正是在这一个个细节上，体现了机械的代码搬运工和灵活的工程师(Engineer/Hacker)的区别
基于这种认识，我在假期中重新产生了建立个人博客的决心。 从2023年7月开始到10月份，我先后尝试了这些建立博客的方案：
- WordPress + MySQL
- docker WordPress + docker MySQL
- docker typecho+ docker MySQL
- docker VuePress + docker MySQL
- docker Halo + docker MySQL
1.Wordpress
在第一次尝试中，手动地配置wordpress和mysql实在是折磨到我了。
我不想用宝塔配置LNMP，（毕竟安装宝塔后，服务器的安全和私密性就打折扣了），于是就只能手动去传输一个个文件，解压，配置环境变量等等。 这对一个大四的软件学生来说，当然不能是一件困难的事情。
但是有两点，让我无法忍受：
1.对环境的侵入性。我目前只有一台服务器，配置很不错，很多时候做作业都需要它。假如这个时候配置了某个具体版本的mysql，php，java，到另一个时候，又需要不同版本的mysql，php，java，还得去修改环境变量，不麻烦吗? 或者考虑另一个场景，我删除了一个软件，却可能没有移除干净，继续占着我的硬盘空间，这简直无法容忍!
2.繁琐，不能开箱即用。这已经是2022年了，还需要手动搞这搞那——有必要吗，能不能简洁点啊，能不能省点心啊。 要上官网，有些下载还要注册，要找各个LTS版本; 传文件要ssh; 要压缩，环境变量，vim 这 vim 那 …… 虽然这种安装方式有最高的灵活性，但是它一来浪费时间，二来浪费心力——这是最关键的。我认为人的意志、决心是有限的，因此必须在精神力耗尽前，就取得一定的阶段性进展。而无数细碎的操作往往在你取得一个个里程碑之前，就耗尽了人的耐心和决心。 因此，这个环境刚配好没多久，我就放弃了。
2.docker WP
当我想起docker以后，搭环境这件事立马变得十分轻松愉快。 只需要pull几个镜像运行，配置docker和mysql，20分钟以内就可以看到WordPress框架的引导页面了。
然而很快，我又为wordpress抓狂了：它太臃肿了，太慢了。尤其在我安装几个插件，使用一个精美的主题之后。每次更新，网页都要近十秒才能重新渲染出来，真是难以忍受。 我知道可以配置CDN，用缓存，换主题，Gravatar换Cravatar，这些方式做优化。 但还是太麻烦了！我是猴急的人，我就想要一个开箱即用的博客框架…
于是我想到了typecho——
3.docker typecho
typecho的作者joyqi在dockerhub上上传了官方的typecho镜像。因此，这次配置过程也特别轻松愉快——赞美docker！
但typecho就像WP的反面——它太简洁了，简洁到我觉得寡淡无味…
而且我对typecho的社区感到担忧——typecho1.2的更新与上个版本隔了9年。它的主题数和插件也不多，几个不错的主题和插件的最后更新时间都是几年前了。 因此，在对比了vuepress和typecho的社区、主题、插件后，我又打算使用vuepress了。
4.docker VuePress
vuepress是静态博客框架，vue技术栈我比较熟悉，社区生态也非常活跃，这都让我很满意。
但是！当我发现dockerhub上没有官方的、即时更新的vuepress后，我果断放弃它了。
对我而言，docker非侵入性、开箱即用特用的特性实在太重要了。
5.docker halo
最后，使我下定决心使用halo的是以下这个内容:
文章 https://blog.laoda.de/archives/blog-choosing#typecho 视频 https://www.bilibili.com/video/BV1cv411N7kz/
这篇文章的作者是一位非常爱折腾且经验丰富的coder，他对halo优缺点的介绍一下抓住了我的心！
Halo支持docker和docker-compose，安装、部署、维护都很方便。它的社区相对活跃，有精美丰富的主题； 而且用户文档清晰详细。当我实际尝试时，配置环境只是完全照着文档，一直Ctrl C + Ctrl V命令，然后执行，不到一会儿就完全搞定。这种开箱即用的特点实在太刷我的好感了！🥰😍
同时，因为是中国团队开发的产品，halo又不至于像WP那样麻烦和缓慢，不需要替换国外网站的资源访问。
可以说，halo完全符合了我的需求。
6. 对博客的期望：
云端知识库和对外发布的空间
从高中到大学，我越来越认同：一个人必须有他的知识体系。 我考虑过各种云笔记，考虑过云盘，最后得出了以下云端知识库的标准和要求：
- 私密性
- 安全性
- 支持Markdown和数学公式，支持emoji😊
- 支持搜索、文章分类、文章标签
- 便于检索
- 容量
- 可维护性
- 可扩展性
- 美观、现代，但不过分强调外在
- 流畅
在各个博客框架里，能幸运地找到完美契合需求的halo，真令人开心！ 希望我能从今天开始，为自己建立一个内容丰富的小窝！ (＾－＾)V
4. 2023: 重建halo2
非兼容升级
2023-3-4 Update.
硬币有两面。同一个事物在不同的上下文下可能呈现不同程度的利弊。
在上一小节里我提到，halo的社区非常活跃，包括开发团队和插件提供者。这一方面为软件的持续更新和持续维护提供了保障，另一方面也为软件更新时的麻烦做了铺垫。
果然没多久，halo就从1.6升级到了2.0，同时，halo的升级重构了底层代码，导致数据迁移不能平滑地进行。
而且halo毕竟不是大公司，它的社区不可能一直为过期版本提供技术支持。
首先，用户更新需要手动迁移数据；其次，旧版本得不到技术支持，用户最终不得不去更新。这种决策，某种程度上，让用户陷入了两难困境。
幸好，我的数据量太小，因此手动保存数据是可能的。
我的4C8G服务器正好在23年2月左右到期了。在购买了新的服务器之后，我就开始重建基于docker halo2的博客。
这一次还是照着halo官方的文档来，通过使用别人已经编写好的docker-compose文件，安装和部署的效率依然非常高。大概只花了一个多小时，就从一个全新的服务器做到了新博客继续运行。
这次搭建halo博客和上次的唯一不同点是如何实现反向代理。上次反向代理我是通过手动配置nginx实现的，这次是基于nginx-proxy-manager。虽然做的事都相同，但是nginx-proxy-manager让我的使用体验好了很多。
联想到的topic
这件事让我想到了几个topic。
- 软件更新演进时的新旧版本兼容性问题
- 兼容性意味着对旧特性妥协，必然影响和拖累新的实现
- 舍弃兼容性，意味着对客户和市场的部分不负责，什么时候能下定决心来个新版本？什么时候一定要保留兼容性？
- 软件更新演进时的更新频率问题
- 怎么让更新速度合适？
- 不让用户感觉太快，难以适应
- 不让用户感觉太慢，及时修复
- 用户的产品使用成本和使用场景
- 对我这种个人站长，实现反代上，nginx-proxy-manager提供的图形化用户界面实在比nginx好太多了
- 使用场景（小型个人博客）和更低的使用成本的组合，导致在我这里, nginx-proxy-manager > nginx 成立。
- halo通过提供用户全流程的、详尽的指导文档，使得建站成了一次轻松愉快的活动。数据不能平滑迁移的遗憾和不满，被快速简单的重建过程缓解了。这也是一个产品的低学习成本、低使用成本为产品价值带来的额外收益
5. 2024：返璞归真
2023年的博客到研究生开学以后，我就无力维护了。而且也不想花钱买服务器和域名了。
同时，进入研究生以来，伴随着工作经验的积累，我的语言表达效率提高了。自己以前那种冗长繁复、低效无聊的文风实在让现在的我感到不满。
所以，服务器到期以后就没续订了，重新用 github pages + Obsidian + hexo 重建一个简单而长久的博客吧！