Google Quick Search Box for the Mac试用
Google Quick Search Box for the Mac(QSB)是google新发布的一个opensource的类似QuickSilver(QS)的小工具.
Google QuickSearch Box for mac
对比一下QS:
QuickSilver
和QS一样，qsb可以快速搜索应用程序,书签，文档资料,联系人等等。
实际上qsb的开发者也是原QS的作者.
QS是mac上的万能工具,我每天都要用到.
对比QS,QSB在使用上有些小小的问题，那就是在输入字符稍许有些停滞,从体验上没有QS那样流畅。
不过QSB和Google自身的产品结合还是不错的,可以直接搜索web,搜索建议,google书签,docs,mac本机上的开发文档等等。通过设定
google帐号,还可以搜索gmail联系人等资料。
希望QSB能够有天能取代QS.
准备将wordpress迁移到MT4
现在的Wordpress是2.6。 自从07年对wordpress-mu做了开发后，对wordpress就一直很不满意。此外，wp无法在我优化后的PHP上运行,WP的性能也不敢恭维。至于它最引以为傲的plugin机制,更不是很感冒。尤其是调试的时候,简直要疯掉的。WP-MU的设计方案也是有点问题，为了保证和WP的最大兼容性,只能每个用户clone一套表,当用户激增的时候数据库就无法管理了。即便通过Hash方式可以分散到多个数据库,在统一管理上仍然有问题,尤其是在国内环境,经常需要和谐,后台的管理是一个课题。
MT从设计上要比Wordpress强上好几个档,毕竟wordpress最早就是几个PHP程序员写的玩具(当时的编码水平也很初级). MT作为商业级的产品,自然胜出。我记得2000年左右我假设的第一个MT,那时候感觉就非常好。
MT的没落其实是策略上的失败,背后隐藏着Perl的没落,PHP的兴起和盛大。
MT的安装也过于复杂,对于普通用户无法立即上手, 但是对于Perl开发人员,是可以好好学习的。
在迁移前，我需要解决一个大问题：
如何在Nginx上运行MT?
目前没有答案。可以考虑将其Dispatcher部分包装到一个FastCGI Engine.
没有想好,需要好好读读MT的代码，这又是个庞大的工程。
放假这几天
年底公司连年假都一起放了,外加几天的强制休假。加起来有半个多月吧。家在北京，没有那么春运的烦恼。但这几天要去练车,这车学的，2年了，说起来都让人笑话。
白天练车,只能晚上看些资料，捣鼓些小玩意。我估计作息时间很快就要颠倒了。
最近一直折腾的有: Qt, PyQt, Django,Catalyst.另外，在练车路上把C++Primer重新看了下,还有Python的几本书。
关于PyQT的一本书还是很有趣的, 比较适合我今年的兴趣,可以用PyQT实现prototype,之后再用C++重新实现。
Django只是快速的看了下, 说实话，我对python没有特别的感觉, 和C#,.Net一样，都是顺手抓来用的东西。使用最合适的工具,是我一向的原则。
Perl虽然现在日渐式微,尤其是在国内,基本上沦落为日常管理的脚本工具,很少能纳入项目开发的选择范畴。
但是，我个人还是非常非常喜欢Perl,也许和我最早期的工作有关,Perlish是我最为欣赏的，就像我喜欢Mac一样。
Catalyst, 虽然从很多方面确实没有Django,RoR那么高效, 学习曲线也高了很多,但是我仍然选择作为我自己平台的
主开发语言, 毕竟，是业余爱好，而不是工作。
Catalyst的给初学者最大的困扰是选择太多,但这也深刻体现了Perl哲学,条条大路通罗马。
所以有必要对Catalyst作一些筛选,构建定制的Full Stack。
Qt是我比较看好的一个跨平台的GUI toolkit,尤其是Nokia 将Qt4.5的许可证改为LGPL后，Qt的应用将更加广泛，尤其是4.5对于Cocoa的支持让我很是期待。Leopard上提供Python对于Cocoa的binding, 而我考虑的是跨平台,至少要面向Windows和Mac OSX,Cocoa就不是备选了. Mono要走的路还很长，目前也不在我选择的范畴。
如果，Qt能够移植到iPhone上就更加完美了。
改进TextMate Perl bundle的语法检查
TextMate下Perl的语法检查对于单个perl包或module很好，但是在开发多个package的project时候，由于当前project目录没有在perl的@INC中，因此语法检查是无法通过的。
一种解决方法是将project源码所在的目录加入到perl的@INC中，或者使用use lib.
这2种不适合单个module的测试,会增加过多的use lib指令。
我是通过修改TextMate的perl bundle的perlcheckmate.pl来将当前project的目录加入语法检查include path中,
实现起来很简单,在
~/Library/Application Support/TextMate/Bundles/Perl.tmbundle/Support/perlcheckmate.pl
找到33 line, 修改如下:
my $inc_path = exists $ENV{TM_PERL_LIB_DIR}?$ENV{TM_PERL_LIB_DIR}:"$ENV{TM_PROJECT_DIRECTORY}/lib";
my @lines = `perl -I$inc_path -Tcw "$file" 2>&1`;
默认语法检查是当前项目下的lib目录添加到INC(符合大多数情况), 也可以通过给TextMate的当前Project添加一个TM_PERL_LIB_DIR变量来手动指定一个目录。
现在，ctrl+shif+V, no errors!
Mojo小试
Mojo framework 是一个新的Perl web framework。
其作者是原Catalyst的开发者之一。 最近在作一个救火的小case中试用了一下，试用中的体会：
1. 如作者所写，这是一个Full stack HTTP 1.1 client/server implementation. 因此安装和部署非常清爽，
所依赖的CPAN module很少。
2. 代码很精简，看起来不费劲
3. Mojolicious 这个类似RoR的MVC framework 用起来也比较容易。
4. 缺点： 文档很贫乏，实例很少，不把源码都看一遍很难下手。
5. Mojo几个主要Package：
Mojo是底层支持库，封装实现了Base,HTTP Server,Request,Repsonse等底层类，实际上Mojo本身是用于二次开发framework，比如其Mojo::Base就实现了一个更快速的OO系统, 可以实现accessor，风格类似Ruby的语法.
MojoX
Mojo的扩展包，主要是针对类似Mojolicious这种MVC的场景封装了一些常用类，比如Context容器,Dispatcher机制基础实现,Routes,Render系统等。
Mojolicious
在MojoX基础上构建的RubyOnRails，当然肯定是精简版了(没有Model实现）。
目前功能还比较简单，不过已经有一个app生成器，生成application模版。
6. 开发提示：
－ 在lib/App_name.pm (App_name.pm是生成的application类) startup方法用于启动server的时候进行初始化，因此对于一次性的工作可以在这里执行，比如routes设定，config的读取，database handler的创建等。
－ 通过扩展Mojolicious::Context 可以在你的context中加入其他的属性
－ Controller的每个method都可以self,context, 不过，在0.9以后,context可以从self->ctx来获得，因此，每个method只需要一个获得invocant就可以了。
－ 前端页面传递的参数通过$self->req->param,params来获得，upload(name),uploads则返回文件上传对象信息（Mojo::Upload)
－ 可以从CPAN下载JSON和TT的render
－ 如果希望Mojo以独立服务器运行,可以尝试AnyEvent::Mojo,如果和Nginx配合，则使用内置的FastCGI Server即可。
总体来说，Mojo和CGI::Application 和Catalyst不是一个起跑线， 但是其前途似乎不错，值得跟踪。