我的天

越是整理数据，越是觉得挺奇葩的。还记得一开始的时候，BlogBus只有分类，没有标签，后来多了标签，但分类没了，强迫把我们的分类全部变成标签。后来分类回来了，标签依然有，但分类只能选一个，标签可以好多个。这样的设计纠结了好长时间才终于确定了下来。后来当我用上WordPress以后，发现原来人家分类和标签都可以同时多个，但因为BlogBus的使用习惯，所以分类通常我只会选一个，而标签会搞一大堆。这是因为blog上的使用习惯，所以我在文件归档的时候也会用分类和标签，我的默认设置继续是分类只有一个，标签有一堆，用python的思路去解释就是某个文件跟某个分类是一一对应的，它们可以形成字典的关系。某个文件和某串标签是一对多的，如果要用字典表话。那堆标签得用列表去表达，于是在文件一开始的时候，就得引入特殊的字典模块。我也不知道为什么必须得有个分类。如果没有分类，全部都只有标签呢？其实也说得过去。文件完全按照时间排序。如果时间一样的话，就按照不同的文件号排序，因为文件号这种东西也是有一定的命名规律的。至于用什么关键词找到这个文件，则可以通过标签，所以其实我觉得标签和关键词是非常类似的东西。

当我在进行动态blog数据转为静态网站以后，我有点明白到。分类就像是定义一个人的一级目录。有些人的blog分类的命名非常有意思。对我来说，那肯定是花了很多心思才终于想出来的，对别人来说或许不这样。要快速定义一个人的话，用分类基本上就可以了。标签通常体现的是某个人的各种特征。标签使用的多少跟这个人的性格和特点很有关系。标签云是一种非常有用的东西，通过不同的颜色以及不同字体的大小就能体现出标签出现的频率，从而反映出这个人的特点。分类这种东西，像是自我介绍，是努力想出来，把自己介绍给别人的，而标签更像是无意之中积累回来的东西。我不知道别人的blog情况会怎样，基本上我的blog的分类是废掉的，因为绝大多数文章都被分类到烂日记，因为我的习惯是一天至少要有一篇日记，而烂日记每天也顶多只有一篇，如果大于这个数的话，我就会用其他分类。从前当我还非常勤快的时候，还有其他分类，但现在，每天一篇日记算是保底，也是封顶。只有一些非常特殊的时候，我才会有两篇或者以上的日志。从前的我，那些多于一篇的日志类型五花八门，而现在也就只有当我心血来潮的时候才会来一些，而通常，那都是专注于某个领域的。对我来说，分类能代表些什么呢？那只能代表过去我曾经做过的某些事。真能体现我个人特点的，只有标签云。到底我用过多少个标签呢？我实在记不清楚了，因为WordPress是个神经病的存在，有些标签我输入了，但是有错别字，我删掉了，但那居然也会保存下来。即便我没有按保存按钮，而有些时候，我真的敲错别字了，但是自己毫不知情。那个错误的标签也保留下来。一篇文章我会输入多个标签。基本上，想到什么相关就会往里面写，所以标签可能一大串，也正是因为这样，各种标签都会出现，所以只出现一次的标签在我的blog里，概率很高。于是就造成了一个比较搞笑的局面，我的分类是严重偏科的，而我的标签是海量的。如果某一天我要把这些东西选进我比较简洁的目录，我该怎么选择呢？标签肯定是不行的，但分类也很奇怪。所以大概那个时候，我就只能用日期做归档了，又或者选择用得最多的10个标签。

静态blog很伟大，但我觉得，我的东西、我过去16年的生活没那么容易在一个静态blog里全部展现出来。因为连我自己都说不清，那到底有多少东西。

我终于做到了用模板的方式以及我自己的数据生成静态网页。暂时我还不知道，那些放进去就能用的格式类东西应该怎么在生成网站的时候顺便一并放进去。肯定是有方法的。虽然现在我手动挪一挪也无所谓。我觉得那大概是一个获取文件，然后解压到目标位置的操作。

jinja的模板套用比我想象中简单。在进行我自己的操作之前，我复制了网上的一个教程的代码，发现真的很容易。模板本身也可以通过浏览器查看效果，这个非常棒。从前BSP不就是干这种事吗？无论是可视化编辑的，还是纯代码操作的，其实都是在设计模板。现在我也终于明白，为什么相比于其它核心功能，在模板方面，我为什么总感觉自己有那么多的经验，因为实际上，我的确在那个方面花了很多时间。现在我已经不记得BlogBus的模板是怎样的了，唯一的印象是他们用的是代码编辑。他们会给你一些核心代码的封装，你可以把那些东西放在指定的某些模板里。封装的东西以外的部分，你可以通过css，或者js去控制，但是封装在里面的，基本上就是一个无药可救的状态了。所以有些格式你觉得你应该可以控制得了，实际上你却做不到，因为封装在里面，已经把格式给写死了。不知道如果我在css那里强行加个important，能不能扭转局面，但显然，当时我根本不知道有important这种东西。css的important的确威力无穷，但是important如果经常用，就会破坏规则，也不好维护。不得已我才会用，即便用了，一个css文件里面，通常不会超过三处。

以前的模板设计，我只是能处理一些格式上的东西。现在，我自己写脚本生成静态网站。无论前台后台，我都玩了，我得顾及前台的模板形式。也要考虑后台的数据整合以及数据的架构类型。在用jinja模板之前，我用的是人肉低端的字符串合并。虽然实际上，我做的低端操作也是实现模板的功能，但就维护来说，这实在太困难了！如果一个网页里面有很多数据是动态的，我就不得不把网页切分为很多份。切着切着，我都不知道自己切到哪里了。就数据生成效率来说。我的低端做法效率会更高，至于为什么，我不知道。9498个页面，我的低端做法转化需要22秒，jinja模板只需要32秒。这个不是偶然事件，在进行9498个页面转化之前，我先进行了一个只有几个页面的测试。结果跟大数据的很类似，低端做法，要比高端做法快1/3。这其中的原因是什么呢？据说jinja已经是个生成速度自称为“快速”的脚本，如果是另外一些，可能更慢。9000多个页面才多10秒钟，任何人都忍受得了。就维护的便捷性来说，低端拼接的维护成本随便超过10秒,所以用jinja模板绝对是值得的。这让我想起了我最在行的邮件合并，用word和Excel联合起来批量生产东西。我不知道其他人玩这个能溜到什么程度，反正这个东西一直都是让我引以为傲的，当然了，这种技能，也是后天逼出来的，工作使然也。

一些我觉得可能挺不容易的东西，居然很轻松就被我攻克了，感觉非常意外。接下来，生成搜索引擎所需的索引，估计不是件容易的事。生成索引，最重要的是思路，而过程不过是一些机械操作而已，我必须掌握好那个思路！

当我把电子书的列表从800多KB改成几个以后，整个静态网站的生成速度就从之前的120秒降为20多秒。20多秒的生成速度跟生成markdown文件没什么区别了。准确来说，生成速度更快了，因为少了一个markdown转换的过程，我猜可能是这样吧。虽然我已经绕了一个大圈又重新做了一个判断，如果我直接从点点转换成静态网站，而不是先格式化为wordpress标准的XML格式，估计速度会更快，但可以肯定的是，如果那样的话，我还是得做不少的判断，因为点点的文件里面不同类型的核心内容是不一样的。其实最简单的方法，是我生成wordpress格式文件的时候把分类继续放在分类，不把博客的名字放在分类，不把分类作为其中一个标签，相对来说这样的改动是最简单的。其实现在我绕了一个圈再回去，也没麻烦多少，因为那个标签是第1个，而我的判断是，如果找到了某个标签，就马上停止循环，所以虽然每篇日志的标签有n个，但判断第1个以后就结束了。就循环来说，没耗多少时间，只是代码会显得又长又臭。

近段时间我一直在纠结如何把手动输入的字典搞得好看些。除了好看，也要容易维护。最明白的方式当然是自己写键值对，但是那么多的引号，那么多的冒号，那么多的逗号，想想都觉得好疯狂。最整齐最不容易出错的方式是一行一个，但那样的话，好像有点奢侈了。所以有时我也搞不懂自己，到底是想节省空间，还是维护容易。

昨天晚上，我纠结一个问题，如果某个单词被我用作变量，在字典里那个单词又是一个key，同时这个单词也是个文本。有没有某个函数能把某个变量只当作是某个名字的字符串呢？如果这样，我的某句话就可以写得很简洁。否则的话，当我调用函数的时候，我就要把这个单词写一遍，当作字符串再写一遍。或者你会说，我直接把这个变量等于这个字符串不就好了吗？显然，我之所以把那个单词当作变量，肯定是因为其内涵跟字符串不一样。所以我试试是不是自己挖了个坑给自己跳呢？我明明不应该把这两个东西命名成一样。

有些时候我会问一些很弱智的问题，明明我是知道的，但是一下子就是想不起来。归根到底，我觉得是我的基础还不够扎实。在完成了静态博客的部署以后。我还没想好我是继续把Think Python那本书从我中断的地方继续看下去，还是应该从头开始，复习一遍，加深印象，因为那些很基础的东西在用着用着的时候，我觉得自己已经忘光了。所以到用的时候，我又得翻箱倒柜。那些东西，我明明应该已经掌握的。

现在的静态网站转换，我是用很低端的字符串连接整出来的。有些字符串是一成不变的，有些字符串是变量。我就在变量的之前之后把静态字符串断开，储存在某个文件里。最后就像穿珠子一样，把动态和静态的东西连在一起，最终合成一个网页。实际上，这是一种模板的思路。接下来，我要利用python的模板引擎，把静态的东西写在模板里，把动态的东西放在某些参数中。这才是我的网页转化应有的方式，但我不确定，这样的转化效率会不会比我现在的低端做法还要低。对我来说，那是一个未知的世界，我非常想，立马通过实践得出答案。

人在求知的路上会越发明白到自己的无知。

当所有现成的方法都解决不了问题的时候，我选择了自己写python脚本转换我的静态网站。花了一个下午的时间，居然还真做出来了。之所以可以这样，是因为我是站在巨人的肩膀上的，我用的是gitbook的格式，他们的静态网页是怎么整的，我就怎么整，毕竟在一个网页里面，哪些部分的数据需要动态变化，哪些需部分的数据无需变动是显而易见的。

之所以可以这么快，另外一个原因是我有了调试的利器。这一次，我用的是VS Code调试html代码。VS Code本来就很强大，昨天更新了个新版本以后，还自动内置了自动修改标签功能，之前这个功能需要用插件实现。大概因为要用这个功能的人实在太多了，所以还不如把它变成默认支持。默认也是需要设置的，不过那就不过是打一个勾而已。VS Code版本更新来得很及时，刚好在我需要用到这个功能的时候，他们就更新了。我还安装了美化格式的插件，这样的好处是，缩进空行什么的一键完成，虽然这个东西看上去很美好，但实际上也是有缺陷的，甚至导致我都不敢用了。因为他们为了好看做了一些不该做的事，超连接给我回车分行，并且在a和href之间再加入很多缩进，这样的话，超链接就不再是超链接了。我实在不知道他们是怎么想的，显然这是一个很大的bug。帮助我最大的是一个叫做live server的插件。这个东西可以虚拟出服务器，网页就可以直接在浏览器上实时更新了。这样的好处是显而易见的，因为这样的话，网站上的超链接全部都可用了，而不需要再按一个CTRL。那种感觉就像直接是在服务器上运行了。我觉得这个效果大概跟各种脚本建立虚拟服务器静态网站差不多。那些脚本除了建立静态网页到缓存，还开起了虚拟服务器。现在，我自己写静态网页，live server开启虚拟服务器。

从前用记事本或者Notepad++，写html的时候，标签配对从来是个大问题，虽然写好了以后，他们会提醒你标签到底配对到哪里了，但在写的时候一点都不智能。之所以这样，可能因为我一直没有去找Notepad++的相关插件。VS Code自带了智能配对的功能，当你写完半边标签以后，后半边自动跳出来了，而且标签你不用写全，写一部分他们就会提醒你，你即将要写的是什么，然后选择就可以了。这样的好处是，标签的配对再也不会出状况，而且标签也不可能写错了。当时我是在看某个介绍VS Code的视频的时候知道这个Emmet功能的，也正是因为这个功能吸引我，那天晚上就下载了个便携版。我不知道便携版和安装版有什么不一样，反正后来，VS Coe用得越来越多，安装版是必须的。如果从前就有VS Code，大概我的很多工作就不需要走那么多的弯路了。但话说回来，现在我写的是静态的网站，如果那是动态的，估计就没那么容易了，但是，就标签配对来说，VS Code还是相当棒的。

现成的各种方法用几个小时，甚至根本生成不出来的电子书是静态网站，我用120秒就搞定了。前提是我们的数据源不一样。我配给他们的数据源是9000多个markdown文件，而我自己使用的数据源是一个20多MB的XML文件。可以生成我梦寐以求的静态网页当然是件好事，但这些静态网页加起来，居然有接近8GB的大小，显然这就很逆天，没有哪个地方能供得起这样的数据。根本原因在于我的每一个页面里面都有一个800多KB的目录列表，排除那个目录列表以外，实际上每个网页文件的内容大都只有不到10KB。所以摆在我面前的是，我不能让那个目录存在于每一个页面，我需要做一个目录页，也就是归档页，我要把那个归档页的链接放到现在的目录那里，而现在的链接则放在归档页里面。只放全部文章的归档页又好像非常空旷，所以接下来，我得考虑把从前的点点分类重新带回。最终的目录那里会有全部文章归档，以及各个分类的归档链接。这个过程挺绕，是我让那些分类消失的，现在我又要把那些分类带回来。最简单的方式是我修改点点到wordrpess的转换转换，让那些分类重新回到分类那里，然后下一步的wordpress XML转化为静态网页文件才会流畅。

python已经成为了我的大杀器，我要学更多，让这杀器更厉害！

要把9000多篇文章，准确来说，是9498篇文章生成一个静态网站实在太难了。如果只是几天，哪怕是几百天，放在哪里，用什么表达，都不成问题，无论是哪个编程语言都可以做到，只是快慢有所不同而已。到现在为止，我已经试过三种编程语言了，首先是go，然后新都javascript，最后是python。

go对应的是hugo，hugo的建站速度是最快的，但快的代价就是电脑的所有性能都会被用到极限。生成网站的时候，CPU飞到顶，内存一直往上走，最后当我看到内存到达90%以上，CPU的使用率反而下降，说明已经到顶了。因为我在做建站服务器测试，那些虚拟的东西全部都放在内存里，显然，我8GB内存的小电脑没办法在某些模板之下，hold住这9000多篇东西，但并不是所有hugo的模板都做不到，有些简单的模板可以做到。另外一些，别说9000多，一两千，都很困难。具体反映出来的效果就是建站的时间很长，其次是内存封顶，结束时间遥遥无期。

第二快的是python。python是我的老熟人了。而生成静态网站，我用的是mkdocs。这是一个python脚本，但实际上脚本自己又调用了很多东西。所以你以为你只是装一个脚本就完事，但实际上你得连串装一堆脚本。只有几个markdown文件的时候，mkdocs建站是很快的，但没到达hugo那种秒杀的地步，但是就建站构成来说最简单的。初始化以后，会自动生成了一个配置文件和一个文件夹，你把markdown文件放到文件夹，然后建站，就可以看到网站的雏形，虽然那个效果肯定不是你想要的。配置文件只有一个，所以也没什么好让你发挥的地方。正是因为够简单，所以我觉得，对那些纯粹写作的人来说，而且，是纯粹写书的人来说，mkdocs这个东西要比hugo实在。但其中一个不友好的地方是mkdocs自带的搜索对中文不友好。搜索英文的时候杠杠的，但是中文就无能为力。如果丢进去mkdocs的文件非常多，到达几百几千的时候。你会很崩溃，跟hugo不一样，mkdocs的CPU的使用率永远只耗尽我其中一个CPU，所以CPU的使用率永远只是25%，至于内存，貌似我一直都没有看到变化有多大。生成一个几页的网站，需要几秒，生成一个200多页的网站，需要十几秒。但是生成一个2000多页的网站，却需要1000多秒。为什么会有这种指数式的增长呢？我觉得跟他们的搜索索引有关。总的来说我觉得gitbook和mkdocs的思路类似。他们会建立一个json文件。而那个东西我感觉就像是一个字典。之所以能自带站内搜索，就是因为他们建立了这个东西。读取写入其它文件，再怎么慢，也有个限度，而且是匀速的，但是如果要不断的增加字典内容，把新的文件内容全部写入到json里，然后存起来，这就很变态。思路很简单，但执行起来的时候相当费劲。

其中一个让其更加费劲的地方在于，但markdown文件非常多，就肯定有一个不断打开文件关闭文件的操作，还得递归某个文件夹里面的所有东西，想想都知道这有多累。但如果有个大文件，全部都已经结合在一起的话，就没有这个烦恼。之所以我有这种感觉，是因为之前我写了一个脚本，专门用来输出9498篇文章的标题与文件名，作用是造一个目录。当时我没有把脚本输出文件的代码缩进，结果仅仅输出目录，居然需要20多秒。目录很小，但是运行时间却跟我把全部内容都输出一样过。昨天我才发现缩进的问题，那就意味着每次增加内容，文件都打开写一遍。这就意味着那个文件被反复的打开关闭9000多次。紧紧减少一个缩进，等于把写入的次数从9000多变成1，于是那个运行时间就缩短为了6秒。读取一个二十几MB的XML文件并输出目录仅仅需要6秒。可想而知，如果不是频繁打开关闭9000多个markdown文件，而是直接用完整的一个大XML文件生成json，速度会相当快。那不就是跟字典类似的东西吗，简单到没朋友。如果我不想进行全文搜索，我只需要进行标题搜索，事情会变得更简单。简单到跟我生成那个目录没啥区别。

经过了这一番折腾以后，让我明白到明细数据与汇总数据使用起来真的很不一样，虽然就总量来说，二者是等价的。

接下来，或许，我真的会像网友所说，自己写一个脚本，把已经进行wordpress标准格式化的XML转为一个静态网站。

天下大势，分久必合，合久必分。这次我算是深切体会到了。