我的天

当我把电子书的列表从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转为一个静态网站。

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

我觉得gitbook和github两个东西是很容易连在一起的，如果我把东西推上了github，自然而然gitbook就会自动同步过去，但实际上，我太天真了，因为我看到的gibook并不是网友们所说的那个。我看到的gitbook实际上已经是第2代。被各位网友津津乐道的gitbook是第1代。第1代的东西还在，但已经不允许新住户加入了。我开始知道有gitbook时候，注册时已经是第2代了，所以无论我费尽多少心思，想在第1代的gitbook里登陆都是无能的。第2代的gitbook简直是一个神奇的存在。我甚至有点不知道该如何去写东西了。

前天我做了个小实验，把几篇markdown放到github里，然后同步到gitbook，非常容易就显示正确了。但我不知道，那只是让我上尝点甜头，因为接下来，当我想把大部队部署到上面的时候，根本无效。一开始，我把9000多篇文章都传到github之后，然后自动往gitbook里输送，结果花了一个晚上，进度条一点反应都没有，一直卡在50%，没有成功也没有失败。昨天我试着只搞4000多篇，结果还是50%卡住，最后我甚至只用了1000多篇，有时可以，有时不行，有时说数据传过去了，但实际上展示界面什么内容都没有。我怀疑是不是我的readme和summary没做好，所以我手动做了那种东西，结果发现还是不行。readme没什么技术难度，至于summary，难道summary太大，读取不了？所以我又把summary删减了好多。到底我是要先做summary还是先做内容呢？如果只有内容，没有summary，会不会内容就无法展示出来呢？最终，我先把summary和两个很简单的文件扔上去，确认没有问题以后，再扔十几篇东西上去，然后就卡住了。没告诉我到底是哪里卡住，什么原因卡住，反正就卡住了。起码昨天我还有卡住的信息，而前天晚上卡住了也不告诉我一声。我试过直接使用zip上传，结果发现，上百篇一起都不行，只能几十篇，文档用zip上传到那里以后，标题没了，所以目录那里完全只是我的文件名。即便我有那么好的耐性，一个一个小压缩档上传，我也没办法一个一个页面改文件名啊！压缩档上传的方法也不行。

我实在搞不懂这个第2代的gitbook。当这些东西我都搞不成以后，最终我想到gitbook之所以有这个名字，肯定是因为可以用git来管理。所以我下载了个node，然后试图安装gitbook，但失败了，不知道为什么出现满屏的错误代码，最终我只能放弃。还记得，从前用点点的时候，他们第2代的模板就是基于node的，所以那时我的电脑上有安装那个东西。我也不知道这个东西需不需要环境配置，通常来说，都得这么干。但貌似这次还真不用，只不过用的方法麻烦一点，每次都要转一下目录。之所以之前没有用gitbook的本地命令行，而选择去上传文件，是因为我觉得大概用不着再装一个安装器，但是，当我觉得现有的方法都不行，我只能用最传统的实现的时候我才发现，原来有第1代跟第2代之分。第2代的gitbook彻底了没有git的功能。虽然他们的网址有迷惑性。最终，即便我可以用本地的脚本生成静态的电子书网站，我也再也不可能把那托管到gitbook上面了，但我还可以选择其它地方可以托管。晚上，我真的又配置了一个本地命令行的gitbook，接着我发现gitbook的虚拟服务器在生成静态网站的时候居然会卡死！卡死的时候不会告诉你我卡死了，因为什么原因卡死。这样太不人性化了。这简直让人连debug的机会都没有，因为不知道bug在哪里。所以接下来我只能一点一点地把文件加上去，然后才好找出到底是哪个文件整出来的幺蛾子。

文章最后，我试验证明gitbook本地版是个没用的东西，起码对我来说没用。生成9页内容需要9秒，生成50多页内容需要80多秒，生成600多页内容每一页至少要一分钟。这样没有效率的东西，可以直接扔了。如果仍然是用这种处理数据的方式运行，github推送给gitbook的9000多个页面能正常绝对是奇迹。

我觉得哪一天自己不看一下脚本，尤其是在工作日的时候，就觉得日子好像缺了点什么。脚本可以是VS Code里的那些，也可以是Excel VBA，同样也可以是各种的网页源代码，又或者是XML文件。反正就是一些不是给人看的东西，又或者说，不是给人直接看的东西。那些东西经过软件的处理以后，结果是给人看的，但是我看那些东西的时候，却是给机器看的。我还没有神经病到要看二进制代码的地步。

一个没有完美倾向的码农，绝对不是一个好码农。所以当我看到，单位的那个所谓智能系统出来东西每一页都有错的时候，我怎么可能不吐槽。他们测试过了吗？他们真的测试过了吗？他们不只是没有测试过，而且做那个表的人根本没用心，连抄都可以抄错。因为我自己是一个码农，所以我知道那些步骤到底应该是怎样的。我不知道专业的码农日子是怎么过的，反正只要我开始任务。任何时候我脑子里可能都在想，有可能是吃饭的时候，也有可能是跑步的时候，经常发生在我洗澡的时候。

写出来的东西的确能实现一些功能，但是那个东西真的能兼容所有情况吗？如果有一些突发的呢？突发的时候，我们可以手动使用B计划，也就是非智能秒杀计划，但是能不能在秒杀计划里加一些判断分分支适应特殊情况呢？这完全是可以做到的，但是一开始的时候，那并不是核心功能所在，所以没有被考虑进去。到达一定程度以后，我就要把那个功能泛化出来。不仅仅做到一些核心的东西，连一些正常的例外也得考虑进去。之所以这么说，是因为昨天走回宿舍的路上，在洗澡之前，我又想起前天写的两个脚本我还可以加一些条件判断进去，使之适应一些后续增加的例外事件。虽然说那些是例外事件，但是在某些情况下，有可能变成常态。之前我不知道该如何处理，但昨天，写了两个数据透视表的脚本以后，我明白到数据透视表我可以固定用某个表名。如果之前已经存在那样的表名，第一步需要把那个表删掉，然后开始后面的操作。又或者，我并不需要删掉那个东西，我只需要改变数据的引用范围。在我的知识范围内，直接删掉比调整引用范围简单。但实际上调整应用范围也必定是一个可控的东西，所以大概接下来我要了解一下怎么在VBA里改变数据透视表的应用范围。另外一个脚本更简单一些，直接是判断某个单元格那时是不是某个固定的东西，是的话就无需进行插入操作，直接开始排序，不是的话就要先进行插入，然后排序。

如果之前我没有学过python，没有努力地写过各种脚本，大概我会觉得泛化有点麻烦，但是当我经历过那些东西以后，我觉得这一切都理所当然了，我甚至想写一个自定义函数把主流程丢到里面去，那么，核心部分的判断就会非常明了，理论上VBA也肯定能做到。之所能具备了这种思路，我必须得感谢Think Python这本书。这种思路是我大学时学习程序语言的时候所不知道的。虽然那时我通过了计算机二级C语言的考试，但那考试对我来说只是一张纸。是后续我接触到、我自学回来的东西，成就了现在的我。

变得更好的路永无尽头。