我的天

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

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

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

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

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

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

昨天晚上我根据电影的时长，看了一部叫做《肆式青春》的电影。那是一部动画电影，中日合作的。至于合作的是什么部分，我就不知道了，反正画风是日本的。上个星期，我看了《大鱼海棠》，同样是一部动画电影。我个人感觉《肆式青春》比《大鱼海棠》好看，因为没有那些过于纠结的爱情。《肆式青春》反映的更多是现实生活。里面说的远远不止是北上广。那里说的是生活中一些每个人都会遇到的事情。当我看完电影，要去豆瓣做记录的时候我才发现。这部电影的豆瓣评分非常低。为什么那些人可以给出这么低的分数呢？从我的角度考虑，第一个故事已经把我看哭了。我承认我的泪点比较低，每到那种话题我就会哭。如果是几年前，大概不会这样，但当我经历过这种事以后。我完全不能自已。之所以有人能打出那么低的分数，肯定是因为他们不曾经历过这种东西。所以他们完全体会不到应有的泪点。看到电影的分数被拉下去以后，我觉得自己被代言了。

《肆式青春》的三个故事我都喜欢。因为那就是我身边普通人的味道。没有非常精密的设计，那更多上是普通人的日记。在广州的那个故事里，基本上广州最著名的建筑物都融到里面去了，尤其是珠江新城的那一片，让我莫名地感到亲切。虽然那一部分说的是粤语，但我觉得那个大概不是广州方式的粤语，那有点香港感觉的，但起码那是纯正的粤语，而不像现在公交车上粤语播报的那种带有口音。会说粤语的这么多，为什么要搞个带口音的来进行语音播报呢？唯一的解释就是挑选人的和审核这条语音信息的人，根本不懂粤语。又或者说，他们不知道纯正的粤语应该是怎样的。在外地人的心目中，粤语大概就那样，发出差不多那个音就可以了，但是对土生土长的人来说，实在太别扭了。开始我以为，只是某条公交车线路，又或者是某个汽车公司的播报是这样。但后来我发现，全部线路用的都是那个带口音的新语音播报。我实在不知道他们到底是怎么想的。到底有多少人像我这样已经听出不对劲呢？我明明知道那不对劲，但是我没有进一步采取手段。比如主动反馈到某些部门，虽然它通常没有用，但不管有用没用，这个连尝试都没做过，怎么知道结果呢？大概有很多人也听出了不对劲，但是也跟我一样，心里觉得很别扭，但是却没有主动改变这个事实。当别人的普通话说得很不普通的时候，我们会笑话他们，尤其当某些香港明星普通话很水的时候，经常会被大家当作笑柄。同样的事情发生在说普通话的人在香港街头跟本地人说很普通的粤语的时候。明星说话不标准那只是他们自己的事，但一个城市的公交车语音播报带了口音那可是整个城市的是事！当一个城市的曾经的母语逐渐消失到大家都不知道母语应该是怎样的，这个城市的魂算是丢了。

记忆还在那里，但里面的东西再也摸不到了。

一直以来我都觉得一个国家的政府，大概是那个国家最靠谱的东西。在我的国家里，几乎没有政客这个词。因为政府的每一个人代表的都不是他们自己，而是整个体系。中国是个一党专政的国家，无论这个体系里的什么人，都是党的代表，都是国家的代表。但其他国家不这样，尤其是资本主义国家。他们的政府总是通过选举而来，所以永远都有执政党和反对党，或者在野党这种说法。执政党与在野党，永远是敌对的关系。他们挖空心思都要把对方搞垮，虽然实际上无论什么党派，最终的利益都是为了国家好，人民好。但实际上，这是不是他们的最终利益呢？我真说不准，如果是从前我觉得这是理所当然的，但现在，我迷糊了，因为他们代表的只是他们自己党派的利益，而且还不是某个党派大多数人的利益，而只是那些象牙塔尖，少数富人的利益。

这个2020真的是非常颠覆的一年，西方国家给我的印象从很早以前的向往，到前一段时间的无感，到现在的反感。我明确地意识到，我反感的不是他们的科学技术，又或者是历史文化，而是他们资本主义特色的政治运营。我不知道该不该用政治运营去形容他们的各种挖苦和挑拨离间。我不知道他们是如何发展到现在这个发达国家的地步的？他们靠什么发家？他们靠的是什么政策？他们靠的是什么科学技术手段？

前段时间，我看了混子曰的简明美国史。看完以后，不知道为什么，我脑子里蹦出了一个词：恶心。他们的发家史，是一个纯粹的商业流氓运作。跟其他国家，基本上是靠战争打回来的不一样。美国就像是用钱买回来的。知道了这段历史以后，我真的不知道，他们经常叫嚣的那种骄傲，底气到底从哪里来。他们之所以有发家的本钱，完全是靠两次世界大战，从别国那里捞回来的好处。

现在，他们对付中国的手段，跟从前他们对付日本和法国的两个企业的手段，如出一辙。当时，他只是对日本和法国的某两个企业怎么干，而现在，他是对中国所有他们认为有威胁的新兴企业都这么干。中国跟法国日本不一样。中国也跟美国派别斗争里的某一个派别不一样。他们的那些无中生有、挑拨离间根本是他们瞎掰的剧本。现实世界可不是他们编剧和导演中的好莱坞故事。

我不知道中国和美国现在的关系是不是因为美国的总统是特朗普。如果现在的总统不是特朗普，情况会不会不一样？还是说，这是中国发展必然会遇到的问题，而这也是美国一直以来的霸权风格。之所以从前我们没有狠狠地碰上，是因为他们从前觉得中国很落后，微不足道，而现在的中国，让他们有紧迫感了。

如果说第三次世界大战即将爆发，我会完全相信。因为当自己不太行的时候，美国就会想起要发起世界大战的攒国难财。但是事不过三，发财这种事，虽然不完全靠运气，但是，胜利的天平不会永远都偏向于某一边。

当所有现成的方法都解决不了问题的时候，我选择了自己写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转为一个静态网站。

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