我的天

要把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转为一个静态网站。

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

昨天，我把COLOR3模板的搜索功能终于做上去了。从前的搜索都非常简单，就是在网页上做一个输入框，然后再加一个提交按钮，搜索都这样。我有想过要不要在WordPress里形成一个搜索的页面，然后要搜索的话就到那里输入内容然后提交，最后返回搜索结果。这样做显然就绕了一圈，我在任何一个页面想搜索，就必须先到达那里，于是网站就要在那两个地方跳转。对于我来说这个体验肯定是不好的。因为这就意味着又要重新把网页加载一次。直接在任何一个页面就能提交搜索然后反馈得出答案跟多绕一圈差别很大，起码我个人觉得这样很折腾。

现在跟10年前的区别大概在于搜索的花样多了很多，比如现在终于可以通过CSS做出比较好看的效果，从前那只是CSS的一个美好梦想。CSS的改进让我印象深刻的是鼠标悬停时的过渡效果以及半透明的展示。从前要展示半透明，每个浏览器出来的东西还不一样，所以写一个效果还得备着多个浏览器的不同选择版本。如果是Chrome和Firefox还好一点，版本兼容性还不错。如果遇到不同版本的IE，出来的东西千差万别。我没有去研究过现在主流的浏览器都有哪些，但可以肯定的是，非常大一部分用户是的是智能设备，而不是传统的PC电脑，所以即便是看到主流浏览器的使用比例，参考性也不大。

从前，当我有了自己的网站，又或者说我有了自己的blog以后，即便blog在BSP上，我已经试图在做网站优化，尽量的让搜索网站能找到我的东西。但现在我已经完全不在乎那些东西了。所以，我连Google的SEO插件也直接删掉。百度也好，Google也好，其它搜索引擎也好，收不收录，收录多少我根本无所谓，搜索得到，搜索不到，我没兴趣去知道，从前我隔一段时间就会神经病地在搜索网站上找自己，但现在我完全不这么干了。那对我来说毫无意义。比如说我在B站上有了账号，而某些视频的点击率又很高。非常有可能，在搜索网站输入我的网名出来的大都是那些点击率很高的东西，不知道看到多少条才看到我自己的blog，但什么重要，什么不重要，哪些有价值，哪些才是我的代表作，我心里明白，我不需要知你们觉得，我不需要知道网页爬虫觉得。之所以要把网站搞好，是因为我要对自己负责。首先网站要让我自己觉得顺眼好看，我自己用得舒服，其次才是别人的浏览体验到底如何，或者我是否应该根据访客的需求进行改进。这么多年以来，我已经习惯了网站一直都冷冷清清。对我来说，有人评论是稀罕事，没人评论是再正常不过的常态，但因为我每天都会写blog，所以即便没有评论，我也要去那里去看一眼，但非常有可能一天就只看那么一眼。

回到搜索功能这个话题上，这一次我给网站配置的搜索是一个全屏搜索。因为我把链接做在版头的导航栏上，所以blog里任何网页都能到达，但是连接我做得有点隐晦，不是正常人所熟知的那种放大镜，所以要找到那个功能，可能会有点难。搜索很简单，就是点击一个像链接一样东西，然后就会有个全屏的搜索框，把需要搜索的关键字敲进去，回车就能得到结果。那个全屏搜索的界面很简洁，甚至没有提交按钮，只有右上角的一个X，作为关闭窗口。会不会有人不知道如何提交搜索内容，有没有人找不到右上角的X把这个搜索界面关掉呢？我不知道，但我相信，可能会有这种存在。这个炫酷的搜索功能是CSS和JS的配合，但是JS只用了非常简单的两条语句。我在CSS那里用了半透明的句子，从前这种东西在浏览器可能行不通，但现在无论是IE还是非IE，效果都很好。因为我是一个懒到了极点的人，所以在做这种全屏搜索的时候，我并没有加其它特效，比如说渐变。那的确很好看，但意味着要加载更多的语句。现在我已经很满意搜索界面的效果了，我把字体搞得很大。能摸到那个搜索入口，试用过以后，估计会觉得很爽，起码我自己是这么觉得的。

过去几天我就像一个少年一样，改进自己的东西，这种专心致志的感觉非常好。

玩时间轴地图玩到痴迷了，哈！

使用的是一个叫做timemap的开源脚本，基于js，伟大地把时间轴和地图结合在一起了。几天前我就开始策划我的地图计划，用意是这样的：把Alberto Del Rio一年里去的所有地方都在地图上标注出来。效果就像Facebook上的地图。之前，地图这个问题我没想到该怎么解决，最傻逼的做法莫过于下载一个宽起码3000px以上的世界地图，然后PS把地方都标注出来。想都没想过要和时间轴结合哦，虽然，按照Facebook的思路当路过某地方的时候应该时间和事件都一并出现的，但一张jpg又怎么能实现这个呢。

于是，之前我首先把基础数据收集工作弄了。先利用DESTINY IS REAL的人肉数据库，然后利用wrestlingdata的比赛数据库（就比赛数据库的全面性而言，wrestlingdata优于大名鼎鼎的profightdb，前者连house show和很多年前的比赛都收集进去了，更让人诧异的是连CMLL和AAA等非美摔的资料都巨细，虽然通过我的比对，他们还是偶尔会有一点点缺漏的，主要是，house show这玩意要收集齐全非常不容易）。如果，我是年头就计划要做这个，我一定会弄得妥妥的，但是呢，我只是半路杀出来，很多东西过了好长时间，我不好意思地忘记了。这不能怪我，这真不能怪我。我只能尽力而为。

现在，我已经基本理出一个做destiny-map-2012的思路了。功能基本能实现，打算通过2个地图去反映全部。一个是15%85%的月-年图，一个是100%的月年图。前一个是为了让大家看到每个月的变化是怎么样的，因为随着时间轴上时间的间隔的变化，间隔外的点是会消失的，进入间隔的点是会出现的。我把时间轴设置为只有显示尺寸的15%就是为了保证显示的一定不是全年内容。至于100%的，就是为了实现我的初衷，在一个大地图上显示Alberto Del Rio在WWE的“工作情况”。如果在同一个地方，有2个时间点，会怎样呢？人肉测试过，这样的话就只能把经纬度稍微调整一点点了，即便这样，在大地图里仍旧是只会看到一个，放大很多后才能分开，摊手，没办法呢～～～

我的努力方向还有一个，地图的旁边放一个列表，有内部滚动条的，不用时间轴，用那个导航。有点返祖的感觉，不过其实这样我觉得已经很足够了。时间轴对我来说是个意外的收获。

WWE的日程变态，时间上的变态、地点上的变态，我必须的用时间轴地图展示这种神经质，宿命使我然也！

技术是个好东西，让人无比兴奋的说，哈～

今天一整天都在研究把第一代的点点模板转为第二代的mars模板。准确来说这个操作昨晚就开始了，昨晚我没有看已经下载好的TNA PPV，却开始了点点的模板转换。

理论上说，这就只是XHTML部分修改而已，但实际上这种操作除了符号转换外，编程的规则也用到了，已经不只是纯粹XHTML的格式问题。在第一代模板里，循环用配对的loop就能完成，但在新的模板里，由于是基于javascript的mars，所以那些已经设置好的标签没了，要循环就要自己用for语句实现目标。我的编程数组类一直不很好，但我的for用得还凑合着，我学的基础得不能再基础的C语言里基本上不会用到forEach，这个我直觉认为是个历遍所有某玩意内所有元素的命令。当然啦，forEach可以做到的东西for ++神马也是能做到的，不过长一点而已。

我就只剩下2个循环没有通过测试了，整个网站就只剩下2个循环。在我已经完成的部分里，我做过2个循环。我至今不明白为什么会循环失败。我会在脑子更加清醒的时候继续尝试的。所以，我不打算今晚能解决掉这个问题了。

然后，Principe将成为点点第一个完全由mars写成的模板。这是完全有可能的。所以这也意味着可能有很多人会以这个为蓝本创造属于他们自己的东西，所以，这就必须更过细了。没有人强迫我这么做，但我却自主地觉得既然我可以这么做为什不呢？这个Principe的描述是“little prince little dream”，我们不可能都是小王子，但我们都会有我们的小梦想。让那些dream的玩意come true吧！谁说有钱才有快乐呢？今天就有人在点点模板开发者的群里出RMB 30让人帮他做一个页面，没有人当众答应，首先，30，太少了，其次，那人的口吻是有钱就能干任何事，他肯出钱他就可以做任何人的老大。这恐吓谁呢？我不是一个专业的程序员，所以如果有人这么“大”我的话，我会觉得这是侮辱，所以即便我能轻易做到我也绝对不会帮忙。我不缺那30块钱过日子。

我这个怪人啊，总把精神看得比$$$重要很多。

在不完全成熟的的系统上测试功能会遇到这么一个怪现象——搞了半天，实现不了目标，或许那根本不是你的问题，是系统的确有bug。于是最后，你只能给一个囧的表情了。

这种事情发生在我想在一个自定义视图里展示某blog的全部标签，折腾了一下午，未果。最后，我实在想不出什么法子了，把问题往点点官方模板开发者Q群上贴，得到“我们查一下……”这样的一句话，囧。也就是说，我什么都不用做了，等他们检查给答复就好。

我没有在BlogBus上遇到过这种问题，因为BlogBus虽然很开放，但在关键数据上都是打包提供的。即便你想知道得更多，也没有任何方式可以达到了。

我没有在WordPress上遇到过这种问题，因为WP已经非常成熟了，所有我能想到的问题其实早已有解决方案，如果找不到合适的，只能说我获取信息的技术没到家。

但点点不一样，他还是个成长中的孩子。用户在探索着，开发者在探索着。开发者不是超人，所以他们不可能任何事情都做得完美。这就要靠他们自己的主观努力和用户在使用过程中的客观反馈。换而言之，我很幸运地活在了他们的上升期，有时我是无奈的，但更多时候，我是幸运的。我喜欢像海绵一样吸收学习各种我觉得相关有用的东西。如果没有DIY的追求，我肯定走不到这一步。但貌似我从来不是那种缺乏DIY念头的人，我经常问自己，为啥别人可以，我不可以？别人这么干，我可以做得更好吗？

我和点点都要前进，都得努力。