存档在 2010 年六月

又折腾回Evernote了

2010年6月29日

前几天,发现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能继续加强对数据共享方面功能的开发,那样我就满足了~~

近期想造的三个轮子

2010年6月4日

这些天在做公司项目和毕业设计的时候,因为要用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恢复了

2010年6月2日

这俩月在公司和学校都是忙得昏天黑地,这段时间也就一直没有打理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才算搞定。

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

无觅相关文章插件,快速提升流量