每一个博客，都是作者背后对于这种事情的执念……
你的执念是什么呢……
Blogger
2006年，那个时候还流行《读者》这种杂志，某一期的主题是关于互联网上的个人博客，并且列举了一些知名的站点，这些让还在读小学的我感觉热血沸腾。
我去了网吧登录了当时还没有被封锁的谷歌博客，并且在blogger下注册了一个博客。它的后台允许自己写代码，当然这对当时的我来说这些都太生涩难懂了。
后来新浪博客，百度空间，QQ空间开始多了起来，blogger站点也被持续封锁。“个人博客”这个词逐渐变得落伍了，同龄人更喜欢在QQ空间里发表自己的日记或者心情。
但是有一个个人博客，一直是我心里小小的愿望。
2014年，我终于搭建了属于自己的第一个博客。当时的我还在一家民营出版社做实习生。每天忙于图书校对和各种线下活动中，面对的最多的是一摞又一摞的厚重的书和活动计划。工作中偶然的一次机会，让我了解到网络空间和域名注册的相关信息，于是尝试着搭建了第一个站点，整个主页就只包含一张图片——没有样式，没有动态交互，只有一张孤零零的图片摆在上面。这个站点仅仅持续了2天，就因为我无法记住它冗长的域名而被我遗忘了。
汤姆猫
Evink.me 最早使用大名鼎鼎的Tomcat（是不是想起了猫和老鼠，我第一次看到它也是）作为它的驱动器，并且使用了ZK框架作为它的View层。这么做显然有很大的好处，例如开发方便，只需将精力集中于某一处的代码上，不需要额外多写css或者js，它将View视图全部交给了java。
ZK框架方便开发之于带来了巨大的副作用。由于使用纯Java代码，每次发生用户事件，都必须像服务器做出一次请求。就连文字变色这种简单的操作也是，如果请求过于频繁，会让我的小服务器不能及时地响应。而另一方面，Tomcat消耗了巨大的资源来驱动站点，如果想在服务器端运行一些其他的程序，还得看这只猫的脸色行事。
几次宕机事件后，ZK框架被我放弃了。
美妙的CSS和JavaScript
使用Html/CSS/JavaScript替代ZK框架，成为小博客非常好的选择。比照经典的MVC理论，我将这三者联系为结构、渲染和逻辑的关系。并在此基础上，将tomcat仅作为单纯的驱动器，提供数据处理和资源处理服务。于是就变成了：
html : 结构提供者
css : 界面渲染者
javascript : 逻辑控制者
tomcat : 数据控制者
通过对站点的结构改良，响应速度提升了许多。
然而对面服务器端仍然拥挤的空间，我仍想找到一个更轻量的驱动器用以替代这只臃肿的大猫。
Node和JS
Node是最近两年很火的服务器驱动器。提起它会想到许多的关键词，诸如：
非阻塞式I/O模型
事件驱动
RESTful路由风格
函数式编程
接触到NODE后，我真正开始思考，怎么让服务器迅速响应访问的请求。
首先，买个国内的服务器是最方便的。（并不，没有这个预算）
其次，利用CDN加速我服务器上的资源，也可以加快静态资源的访问速度。 （但是需要备案，然而……）
Hexo
确定node作为站点驱动器后，整体博客的响应速度还是不太理想。
大部分静态资源，例如CSS、JS、媒体文件，都被我置放于七牛云上了，但是服务器返回部分数据（比如博客的文章，留言板的留言）时，仍然造成了数据丢失、响应超时等状况。
于是诞生了，json文件替代数据库的想法。（与现在Hexo保存文章的方式相同）
js中，可以使用异步读取json文件，不再需要一个后台接口去调用数据库就可以实现查询操作。
不过这样写文章的时候会稍微麻烦点，你可以直接像json文件里添加文章，也可以通过一个接口，将文章通过node写入到json文件，在自动上传到七牛云（实际上和操作数据库类似，只是读操作会更加容易）。这种方式会让服务器的压力最小，同时也保留了服务器的处理数据的能力，不需要每次写文章都需要执行
node generate -> git deploy -> read article
这一过程。也可以同Hexo一样，使用node在本地自然编译（这种说法不妥，但是和编译类似）一遍，再上传静态文件。
Hexo的处理方式，几乎不会对服务器产生任何有压力的请求。
服务器在这个场景中，仅仅充当了转发器的角色。但是，这也意味着，你无法通过UI调用接口去写文章。每次都必须要重复这一过程（尽管这个过程很快）
其他部分
旧的博客被保存在 http://old.evink.me
抱歉说了这么废话，谢谢观看