2 Years

前几天，发现Evernote又更新了几个版本，果断装了试下。结果欣喜地发现，Evernote 3.x版本困扰我已久的对中文支持的bug终于被fix了。这么一来，我终于可以完全将我的个人知识管理工具从Onenote迁移到Evernote了。

Evernote一直是Onenote的主要竞争对手，3.0版本貌似是用WPF写的，界面上确实漂亮很多。但 3.0版本对东亚语言的支持有问题，在搜索Tag时，对输入的中文词都分成了一个个单独的字。这一点已经不是瑕疵，而是完全导致了Evernote无法使用。毕竟基于Tag的管理跟基于树形分类的管理不同，前者完全依赖于搜索。所幸这个bug总算被修复了。

现在看来，Evernote的优点实在是太多了。Evernote是完全基于互联网的，所有的数据都是存储在服务器上的，这解决了不同平台、设备上的数据同步问题，这比Onenote只能用Dropbox等网盘来达到同步效果实在是强多了。Evernote也有大量的客户端，除了运行在Windows上的，还拥有一个基于Web的全功能在线版，这也解决了在Linux下的使用问题。在移动设备上，它也支持WM,Android,iPhone,iPad，以后只要还在用主流智能设备，都会有Evernote。而3G网络的发展，也让Evernote以网络为中心的理念不再成为问题。事实上，最近MS也推出了在线版Office，其中就包括Onenote，编辑时手感很好，但在对数据的组织上感觉很糟，观望一下吧。至于移动版Onenote，只支持过气的WM不说，还必须通过Outlook才能同步，真是渣一般的存在。

Evernote现在感觉还是很朴素的，功能只能说够用。希望Evernote能继续加强对数据共享方面功能的开发，那样我就满足了~~

这些天在做公司项目和毕业设计的时候，因为要用Python写大量的网络服务，尝试了各种能用在Python下的网络库、框架和中间件。折腾了这么久，渐渐感觉到，目前的这些鼎鼎有名的通用型网络通信解决方案都有这种那种的问题，通用的代价就是妥协，妥协的结果就是会带来一堆不符合我需求的以及我不需要的东西。对于一个立志于长期运行的大型应用来说，造出一个完全符合自己需求的轮子几乎是一个必然的事情。而这个轮子完善后也会成为一个特定领域的通用解决方案，再以后随着运行环境、系统底层、应用模式的转变（譬如异步IO从select发展到epoll，譬如c++模板元编程的大行其道），这个轮子也变得不合时宜，再也跟不上时代的脚步，它就可以果断得光荣退休了，江山代有人才出，后来事自然不用它担心。下面说下我所遇到的那些问题。

我要搭建的服务之一就是一个要支持高并发的HTTP服务器。最显而易见的方法自然是用Apache(Nginx)+FastCGI(WSGI)+Flup+Django这样的组合，但现在的情况是，这个服务是只需要处理不相关的一系列POST请求，不需要支持Session，不需要格式化HTML，不需要返回静态文件。这样一来，Django、web.py这些重型的Web框架就都成了累赘，然后我发现了Tornado(http://www.tornadoweb.org)这个HTTP服务器。Tornado现在由Facebook维护，其定位就是高并发服务器，从大量的评测结果来看，它从性能上超过了其它对手至少2倍以上，包括基于传说中的Python网络框架一哥Twisted的那些。Twisted存在的问题，我后文中会详细说明。Tornado高性能的秘诀就在于它对epoll的高效处理，它基于epoll自己实现了一套IO事件循环机制，对所有的HTTP请求都是异步处理。而对于GIL锁带来的无法有效利用多核的问题也很好解决，多跑几个Tornado进程，使用Nginx做下负载均衡即可。我的另一个需求是需要通过HTTP连接帐号服务器做验证，这个耗时的过程必然要使用异步连接，否则阻塞时间对性能的影响是致命的。这点也不用担心，Tornado支持异步HTTP请求。

另一个需求就是，我需要跟数据库通信，数据库我们用的是Redis(http://code.google.com/p/redis/)，也是一个高性能高并发的一个东东。现有的Redis的Python客户端只有2个，其中一个是用的底层Socket同步连接，这点无疑会降低服务器的并发数。另一个客户端是异步的，但是它是用twisted写的，而且很久没有更新了，许多Redis的新特性都没有支持。要知道，2个异步事件框架是无法共存的，这就注定了twisted无法用在我要写的HTTP服务器中。这就是我想造的第一个轮子，使用Tornado底层事件循环的异步Redis数据库客户端。

我的另一个需求就比较纠结了，HTTP服务器需要同大量的应用服务器进行通讯，而应用服务器要做大量的处理工作，比较耗时，所以这个连接也要是异步的。其实我需要的就是一个异步RPC机制，另外还需要考虑异构环境（x86与x64系统之间、python与c++之间）的问题。现在采用的方法又是一个通用的解决方案ICE(http://www.zeroc.com/)。ICE的问题也是通用解决方案的通病，太过臃肿，而且不是一般的臃肿。ICE的定位是一个分布式中间件，它不仅仅包括一个RPC，还有各种的命名服务、配置服务等等。而ICE的异步RPC实现方案我也不太满意，它的做法是在后台跑一个事件接收线程，无法融入到整个异步事件处理框架中去。所以，我想造的第2个轮子就是一个使用Tornado底层事件循环的RPC客户端。

为什么一直要对Tornado的底层事件循环念念不忘？因为它的高性能给我留下了深刻的印象。但直接那它来写别的网络服务也不是一件很简单的事情，因为这是在是对epoll的一层很薄的封装。这就是我要造的第3个轮子，基于Tornado IO Loop的一个异步网络库。上文说到了一哥Twisted，Twisted所存在的问题其实是与ACE一脉相承的，因为Twisted是模仿ACE而来的。ACE是这类异步网络框架的开山鼻祖，曾经光环满身，而现在也遭到了口诛笔伐，譬如“学之者生，用之者死”。ACE是得了模式综合症，用了大量的OO设计模式，结果就导致整个的程序风格完全被ACE所控制，Twisted也是这样。这几年，C++领域的ASIO横空出世，用模板元编程实现了一个优雅的异步网络框架，避免了ACE那样大量丑陋的继承。而在Python这样的动态语言下，更无须被OO的规则所束缚，面向对象设计模式更多的是解决静态语言的设计问题，但这些问题在动态语言里并不存在。所以，我要造的这个网络库是参见了ASIO的，模板元编程能实现的，动态语言也可以实现。我目前需要的网络库是什么：只支持Linux，只支持epoll，只支持IO复用+事件循环的方式，不支持同步IO，不需要线程安全（因为在Python下多进程优于多线程）。再接下来，自然是要以这个网络库为基础，实现上述的2个轮子，另外把我那个已经用twisted实现的RPC框架移植过来。

轮子虽好，可不要贪杯哦~

这俩月在公司和学校都是忙得昏天黑地，这段时间也就一直没有打理Blog。前端时间MLGB的合伙VPS终究还是散伙了，blog也就跟着停了。之后试用了Burst VPS一个月，速度很一般，blog也就没有迁移。问题是VPS也是翻墙之源呐，受够了这段不能稳定翻墙的日子。再次还是要忍不住艹两句TG，我又不搜不河蟹的东西，就那些邮件组里的技术文章你们也要封，这不典型非得把我们推到对立面么。

今天（额，应该是昨天了）果断出手了Ecvps，到手就开始配置。Ecvps的控制面板貌似很弱，别人家的都能直接自己换操作系统的，而这个DirectAdmin安上后感觉还不如webmin。更为可恶的是，DA还依赖Apache，Mysql等一坨东东。这对于不太熟悉配置的人倒是好事，但我这么有洁癖的人就实在无法忍受这个，我还是更习惯从头到尾手工打造系统出来。操着半生不熟的英语跟服务商扯了半天淡，让他们重新给我装了个干净系统。本还想让他们给换个ubuntu10.04的，但最高只有ubuntu9.04，不过也无所谓，没啥区别，只不过感觉上不太完美了O(∩_∩)O~。

第一件事当然是把这个blog恢复出来，以前用的是Apache，现在果断换用Nginx。编译Nginx倒是轻车熟路，编译Php时候出了不少问题。PHP跟Nginx的通信是用FastCGI，具体实现上5.3之前版本的PHP貌似流行SpawnCGI，而5.3以后核心开始支持FPM，江湖传闻性能更高，那自然要尝尝鲜咯。无奈5.32版核心集成FPM的方式始终链接失败，到底还是在5.31版上打了patch才算搞定。

现在看着熟悉的界面，眼泪哗哗的啊。天亮了，该睡觉了，还得早早爬起来改论文，万恶的老师哇~~

自从放了假，人也变得懒散了，基本没更新过blog了。在家跟以前一样，都是开始雄心勃勃想看完从学校带回来的书，结果最后这半箱子书的宿命还是睡了一个月后再跟着我天南海北的大游行。但这个寒假终究有许多不同，跟家里的朋友们见面时，话题更多的是工作和考研。我们都明白，这是我们年轻时最后还能享受到的这么长的闲散时光，于是酒也更醉，歌也更浓，在网吧的疯狂dota一夜也是我们浓缩的大学回忆。

正月十二终于踏上了南下的旅途，火车一路开进，各种天气也是变换非常。家乡的寒风，赣南的浓雾，粤北的艳阳，直到吹上了深圳的涩涩的海风。从深圳西到蛇口港的路上经过的都是工业x路，貌似这一片也就是当年深圳特区最先兴起的地方。路边上还不时能看见以前震动全国的标语，“时间就是金钱，效率就是生命”，“空谈误国，实业兴邦”，80年代中国的那种活力现在想来也依然让人神往，只是那个黄金时代随着天安门的枪响一去不复返了。

火车晚点的2个小时，导致的直接结果就是我在珠海无所事事了2天，周末没人管事也就没位置没网线没机子。不过第二天就享受了一下公司福利，跟着自行车协会的一干人等骑行60公里跑到了淇澳岛上吃了顿农家饭，顺便也跟大家混了个脸熟，也认识了下个各大小boss。一路上沿着海岸线前行，珠海的风景还是不错的，是个修身养性的好地方。就是也太潮了点，话说我洗好的衣服晾了两天还没干呢。

现在也上了2天班了，跟着峰哥做在线表格，整个项目组都是老大一手发offer的武汉帮，倒都是熟人。在金山这样遍地都是牛人的地方最大的好处就是不缺动力，继续看那ACE文档的蝌蚪文去了。

shared_ptr是boost库实现的几个智能指针中最重要的，其使用引用计数机制来管理资源。

如果一个类由shared_ptr管理，而在这个类的某个方法又需要传出一个指向自身的指针，那么这个指针也必须被shared_ptr所管理。boost库的实现方法为让被管理类继承boost::enable_shared_from_this类，此后通过shared_from_this函数获得指向自身的shared_ptr。

enable_shared_from_this实质上是把一个weak_ptr作为被管理类的成员，其观察资源使用情况，在调用shared_from_this函数时就是通过这个weak_ptr生成了一个shared_ptr。研读enable_shared_from_this机制的实现时，发现以下代码：

105
106
107
108
109
110
111
112

template< class X, class Y, class T >
inline void sp_enable_shared_from_this( boost::shared_ptr<X> const * ppx, Y const * py, boost::enable_shared_from_this< T > const * pe )
{
    if( pe != 0 )
    {
        pe->_internal_accept_owner( ppx, const_cast< Y* >( py ) );
    }
}

这个函数就是设置被管理类中的weak_ptr的。那么这个函数什么时候被调用呢？是在shared_ptr的构造函数中：

186
187
188
189
190

template<class Y>
explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete
{
    boost::detail::sp_enable_shared_from_this( this, p, p );
}

这里比较奇怪的地方就是sp_enable_shared_from_this这个函数是始终被调用的，但是如果被管理类没有继承自enable_shared_from_this，那这个调用肯定是通不过的，因为指向普通类型Y的指针p不能转型为指向enable_shared_from_this类的指针。继续翻代码，发现sp_enable_shared_from_this函数的一个重载：
inline void sp_enable_shared_from_this( … ){}
原来这个地方充分利用了函数重载发现机制，如果被管理类继承自enable_shared_from_this，那么第一个sp_enable_shared_from_this就是最合适的，shared_ptr的构造函数中会调用这个版本。否则，就会调用第二个sp_enable_shared_from_this函数也就是最通用化的版本，因为…就是不定参数，它可以接受任何传入的类型。而这个参数又是一个空函数，什么事都不会发生。

这种实现方式也避免了效率的降低，因为2个sp_enable_shared_from_this都是内联inline的，这就保证了如果不需要设置weak_ptr那么不会有任何函数调用发生。

这几天MLGBers都将自己压抑了几年的心情来了次总宣泄，怒斥武汉理工这所学校除了荼毒他们四年，什么都没有剩下。那对于我自己而言,武汉理工又意味着什么？

诚心而论，武汉理工不亏欠我什么。

归根到底我是中国大地上的一个凡人，做不到像Livid那样跳出五行外，不跟大学这帮死老头玩照样能风生水起。身在山东的一个普通小县城，就算对计算机的接触勉强赶上了时代的步伐又怎样？高中里从没人听说过NOI，获取信息的途径只有那一本本电脑报和电脑爱好者。如果要把这兴趣延续下去该怎么办？在大学接着读计算机就是了嘛。只是大学呢？不到山东，不知道高考的痛与泪。其他几个哥们的家乡，天津、内蒙，那是我们多么魂牵梦绕的地方，就因为分数线要低100分呐！现在是个大学生遍地跑的时代，如果学校连个211都不是谁拿正眼瞧你？只是在我这，没个600分甭想211。武汉理工档次低了点吧，武汉华科还凑合？对不起，我想我考不到640，就算考到了我也不想进一个考古系。哥几个所唾弃的武汉理工计科院，那也需要我经历2次高考的痛。底层基础决定上层建筑，我甚至应该庆幸，我至少还来到了武汉理工，而不是北大青鸟。武汉理工至少给了我一个学历，给了我一个最基本的平台，让我得以凭借之进入业界前沿的公司，认识一帮还对计算机保持着热情的人。

在大学里，周围的同学死气沉沉？老师吹毛求疵？对于一个承受过中国教育史最大的不公平的人，对于一个目睹过中学同学被高不可攀的分数线逼得神经错乱的人，这算得了什么？学校没有文化底蕴，我已早已习惯，受过了12年的题海轰炸，从不知素质教育为何物，我倒想问什么叫文化底蕴？

我不想抱怨我所在的环境，虽然这并不是我自己想要的选择，虽然我还想提醒一下后来人：投胎须谨慎。蛔虫们知道屁眼是他们的祖国，我也知道这个并不可爱的地方是我的家乡，这个并不诗意的地方是我的母校。抱怨没有什么意义，以逃离这个地方为荣更是一个懦夫，不需要伪装什么大公无私，但求问心无愧，正视自己的过去，改变自己能改变的。我骨子里终究还是一个山东人。

学期末的时光总是忙碌而又杂乱。

无尽的报告是这个时期的一大主题。Happy的三峡五天也带来了这个痛苦的副产物，花了一整天抄完后手都酸了。不过毕业设计的开题报告我还是挺用心的，选分布式文件系统当设计内容现在看来相当明智，这些天看了不少东西，研究得越深入越能感觉分布式这个领域的魅力。毕业设计的指导老师奉行的也是无为而治，基本不管我们组的实际内容，只要完成必要任务即可。这样也好，没有了束缚自然可以自由飞翔，祭起我最爱的技术，创造我喜欢的东西。其实在技术上，我总有一种完美主义者的倾向，很多压力都是自己硬压给自己的。但是，谁又不想让自己的孩子更漂亮一些呢？

这几天各处的饭馆餐厅也都留下了我们的身影，送走了一个个兄弟、同学。寒假已经过了无数次，但这次有些许不同。很多人，这一去就是半年不能再见了。MLGB这个团体也缺少了JB的身影，但看他的博文，能感到他在UC的快乐与充实，这就够了。昨天的金汉斯，大家都吃得很撑，但谭二还是没有去。不要为我那个善意的玩笑（切x皮）生气了，愿你的肠胃炎早日痊愈。今天插从合肥赶了过来，虽然都在QQ上扯了半年了，但真人还是第一次相见。大门口的香辣虾是我当年来武汉的第一餐，PZF也是，我们在这搓了一顿，挺好的。不久以后，我们3个就要在金山挥洒自己的青春了。MLGB的兄弟们大多都要踏上了社会，也愿OB能早日找到你的路，实现你的梦想。

最伤感的还是我要和自己的宝贝分开一段时间了。已经过去的2年多时间里，我们有过争吵，有过眼泪，但更多的是甜蜜的回忆。我们经住了时间的考验，接下来的是距离。离开黄河之畔的家已有半年多了，父母的牵挂是漂泊在外的最大慰藉，现在既已真正成人，自当竭力尽孝。而年后就要去珠海实习。这两地用一个一千公里的圆串起来，圆心就是武汉。这一千公里的距离，掩藏不住的是我的担心。没有我的日子里，谁去在你生病的时候帮你带饭，在你晕车的时候给你依靠。不管怎样，答应我，照顾好自己。我永远在你身边。

自打这Blog建起来，还真没写过像样的文章，白花花的银子堆起来的VPS基本就被我当成了翻墙跳板+网盘，可惜了在OB教导下搭起来的WP。眼见着就要过年了，自己纯粹的学生身份也即将到此为止，不过这最后的学生时光学校也没打算让我们闲着，一坨坨的报告在那压着呢。一想这报告，我那脐下三分之处就开始隐隐作痛。昨天忙了一整夜辛辛苦苦凑起来的报告，全打了水漂了。怪谁呢？只能怪那恨铁不成钢的WPS啊。

虽说MS Office我一直都用着很舒服，但我这好歹也要支持下公司产品吧，前几天见WPS出来一个“澳门回归纪念版“，就心血来潮安上了。安上以后发现，金山其实现在也学得挺流氓的，什么提示都没，直接接管了doc,docx,ppt一干MS Office的文档格式关联。我也懒得调了，那就先用着看吧。结果还是挺让我惊喜的，从打开MS Office文档的显示效果上看，WPS已经做到了与原版并无二至。再加上与Office2003十分相似的界面，相信那些采购WPS的国家机关里的老头大妈是不会感到有什么不适应的地方的。这一版的WPS对于在线存储的支持也已经比较完善了，可以直接保存到服务器上，也可以通过Dropbox的方式将本地文件同服务器同步。另外，WPS最能体现中国特色的地方就是它的在线模板，它不仅仅像Word一样提供了一些常用公文的格式，还直接提供一些常用八股文的架子，像入党申请书、思想汇报之类的都有。到现在为止，WPS还是比较让我满意的。

既然用了那就索性用到底吧，毕业设计的开题报告我也用WPS写吧。被Office2007宠了这么多年，现在没了Ribbon界面一朝回到解放前还真的挺不适应的。现在很多功能项只能从长长的菜单里一个个往外扒了，Ribbon界面确实有它不可比拟的优势，也难怪微软一直坚定不移地把Ribbon贯彻到Onenote，Outlook乃至它自己的在线Office了。在编辑过程中，也能感受到WPS与Word在细节上的差距了，像WPS在删除段落和增加编号时很容易把格式搞乱，对缩进的控制也不够灵活。忽然之间，我不知道得罪了哪位过路神仙，杯具降临了。我从网页上向WPS复制一段文字时，忽然WPS卡住了，最后只能结束进程了事。但更大的杯具紧跟其后，我重新打开WPS后并没有提示我恢复崩溃前编辑的文件，我可是从前天晚上8点一直写到早上7点都没有点存盘的啊！经验上我记得MS Office在编辑一个文档时，都会在原地另外生成一个临时文件，编辑过程中所作的改动都会定期保存到这个临时文件中，这样即使程序崩溃也不会造成太大的影响。但我发现WPS并没有实现这个机制，原来的地方只孤零零的站着一个原始文档，最后修改时间还是10个小时以前，我抱着侥幸心理在临时文件夹里扒了一圈，也没有什么有价值的东西。感情WPS的编辑过程全是针对的内存数据啊！

事到如今，哭也没用了。气愤之余直接把WPS卸掉重新用Word靠记忆再写一篇报告了事。就这么短短的半天的使用过程已经暴露了WPS的很多硬伤，如果连基本的稳定性和数据安全性都没有做好，别的一切都是空中楼阁。而且据我统计，这些问题还出现得相当频繁。JB上个月就碰到了文档丢失的情况，前些天班里一哥们也是这样杯具的。如果WPS连这些基本使用都要提心吊胆的，它与MS Office的差距只会越拉越大。

这些年，WPS一直是跟着微软的脚步跑的，WPS与MS Office也越来越像。但山寨终究是得其形而得不其神。现在MS Office的界面换了，难道以后WPS也要跟着换吗？不过貌似现在公司也意识到了这样的窘境，公司现在的研发重点放在了在线Office之上，但这个领域也进是强敌环伺，微软的继续跟进，Google的严阵以待，如果还不能形成自己的符合用户需求的特质的话，只能是死路一条。但就目前的趋势来看，微软一家独大那么多年的影响是很难消除的，现在公司里即使是全新研发的在线Office，为了同MS Office保持良好的兼容性，仍使用微软提出的OOXML而不是ODF或者UOF作为存储标准。联想到前些天公司高调推出的UOF SDK，那更多地是向政府表明一种姿态，如果连自己都没有使用的话，又有多少人会用呢。不管怎样，过不了多久我也会出现在在线Office的团队之中，虽然我只是个普通程序员，但至少要对自己的产品有责任感。尽人事，由天命吧。