All Stories

Twitter客户端大赏之Echofon

  想写这么个系列的文章,以介绍一下现有的各种Twitter客户端,已经有一段时间了,却一直没开始写,一方面是自己懒,另一方面则是真没有觉得有某个客户端的特性已经达到让我觉得不写不快的地步。不过自从用了Echofon for Mac后,我觉得很有想写一下的冲动。   Echofon有好几个版本,我刚开始上推的时候曾经用过几天它作为Firefox扩展的版本。由于寄生在Firefox上,所以貌似是可以通过Firefox的代理走的,又因为那时我是用Tor来翻墙的,速度那个慢啊,因此体验并不怎么好,而且为了单纯地上推不得不开一个庞大的Firefox(我装了二十几个扩展,很占内存),感觉并不是很好。之后有了其他的客户端,就再也没用过了,直到最近比较多地用Mac系统,试了几个for Mac的客户端后,发现了Echofon for Mac,一用就爱不释手了。   Mac桌面版的Echofon是个共享软件,如果不注册,则在Timeline页顶端会有一小块广告条,而且有时候在程序启动时会弹出对话框询问你是否注册,总的说来并不影响正常使用。Echofon在界面和操作上,都做得比较细致,而最吸引我的,主要是它已经直接Streaming API,可以实时更新Timeline和Replies等等。Streaming API目前还处于测试阶段,Twitter官方的消息目前只有Echofon和TweetDeck实现了,经过试用,感觉非常好。   除此之外,Echofon有丰富的菜单项,当然大部分常用操作也可以通过快捷键实现,另外还支持多个账号,不过它是单列单账号的显示方式,所以要自己手动切换当前活动账号。从界面上看,Echofon是个比较正统的Mac程序,如果想要原班移植到Windows上,可能反而不伦不类。   最后要说的是,Echofon自身不支持API,不支持代理,不过好在Mac系统可以比较方便地用全局代理,所以问题不大。

好用的Mac五笔输入法

  看到推友@davidx_me说有个叫WBIM的for Mac的五笔输入法,马上去下载了来试用一番。之前一直用系统自带的那个五笔型输入法,相当不好用,不但字符小,应该是GB2312的吧,而且连候选提示都没有,其他的常用选项更不用说了。试用了WBIM后,就爱不释手了,虽然跟小鸭、极点神马的在可配置选项上有所差距,但总体来说,已经可以说是鸟枪换炮了。   它有着大部分常用的输入需求的选项,比如繁简切换、中英文标点、全角半角、空格,还可以自定义翻页的快捷键,可以自定义用户词库,比较遗憾的是貌似不能自定义选择候选的第二三项的快捷键,不过好在五笔输入绝大多数是选择第一项的,所以也可以忍受。   再有一个还算满意的是上屏速度不慢,虽然偶尔还是有点呆滞,不过也在可以忍受的范围内。   最后要说一下,这个软件目前貌似是免费的,这对于混迹于人傻钱又多的Mac用户群中偶尔几个穷人来说,实在是个福音。

目前最好的Lua IDE

  Lua跟众多其他开源的脚本语言一样,都没有一个官方的或绝对统治地位的IDE。而与诸如Python和Ruby这些大红大紫的脚本语言相比,Lua算不上一个流行的语言,也就是当年WoW的推出,带动了Lua的发展,相应的,Lua的开发工具也就显得更加落后,不但缺少一个比较正统或权威的库集合,还缺少好用的编辑器。之前我已经介绍过LuaPack,一个与Lua For Windows定位类似的开源项目,提供了几十个常用功能的第三方库打包。这回就介绍一个目前看来最好用的Lua IDE,叫DForD LuaCoding,它在LuaPack中也集成了,但它是个共享软件,在LuaPack中集成的那个版本只有在每次启动时弹出个要求输入注册码的对话框,只要点击“试用”按钮就可以继续使用了,除此之外没有任何其他的时间或功能上的限制。但是在DForD LuaCoding的官方网站上下载的版本,除了弹nag窗口,还有试用30天的时间限制,之后就只能花99美元购买了,当然网上也有0day。   DForD LuaCoding采用解决方案、工程组织方式来管理文件,任一时刻最多可以打开一个解决方案,而每个解决方案中可以有任意多个工程,这种组织方式与Visual Studio类似。另外,DForD LuaCoding还有通过文件名快速定位并打开文件的功能,这在Visual Studio没有直接的支持,需要装像Visual Assist X之类的第三方插件才行。这个功能对于一个解决方案中包含了大量文件的情况下特别有用。   DForD LuaCoding使用Tab浏览多个打开的文档,得益于Scintilla控件,语法着色,代码折叠等现代代码编辑器常有的功能几乎都有。不过由于DForD LuaCoding的定位是一个专业的IDE,而不是一个通用的代码编辑器,所以跟SciTE、Notepad++这种编辑器相比,就少了一些平常不太用的功能,比如复制行,交换行等等。不过总的说来,作为一个IDE内嵌的编辑器,当前已有的功能足以满足99%的编辑需求。   DForD LuaCoding提供了一个有点模仿TextMate的Code Snippet功能,不过TextMate中叫Tab triggers,该功能全部通过Tab键完成,而DForD LuaCoding中使用了三个不同的快捷键分别用于缩写展开和编辑热点前后跳转。这两种方式可以说各有优缺点吧,总的说来,我个人不太喜欢TextMate中一个Tab具有不同含义的作法,而且DForD LuaCoding中的三个快捷键分布得还算方便。   DForD LuaCoding提供了一定程序的Auto Completion,即自动完成。对Lua标准库的支持比较完善,不过也是因为Lua标准库很小很简单吧,呵呵,还支持几个其他的第三方库。但要说的是,该Auto Completion功能的准确性不高,有时把当前文档中的单词都列出来了,有时把所有库的表名列出来了,有时把所有函数名列出来了。不过实话说,有了这个Auto Completion,只要记住前几个字母,后面可能的候选字都列出来了,仍然可以减轻记忆负担,减少击键次数和拼写错误。另外,DForD LuaCoding对标准库中的函数,还提供了简单的call tips说明,只要鼠标光标停留在函数名上几秒钟,就会弹出一个tooltip,显示出该函数的简单说明,了胜于无吧。   最后值得一说的是DForD...

又系统还原,又丢失数据

  昨天鬼使神差地想下几部爱情动作片看看,结果果然不幸中招了,乱78糟地起了一堆的进程,然后装上QQ医生,删那些可疑文件,最后不幸地不能进入系统了,一登录进桌面就立即自动注销了。于是只好恢复到出厂状态了,郁闷的是那块硬盘上的其他东西都备份不下来了。说起来,有各种备份措施可以使用的,但我仍然杯具了,是有原因了。   首先,我的笔记本自带的光驱不能工作了,这是一大杯具。进入Access IBM的备份和还原界面后,虽然有备份选项,还能找到硬盘上的所有数据,但即使在USB口上接了下刻录机,也找不到那个可写媒介。IBM的软件果然糟糕哇!   其次是我使用硬盘的方式有问题。一直都是整块硬盘的使用,不分区,然后有一块外接硬盘通过USB口使用。实践证明,外接USB硬盘已经有好几次貌似都因为USB的问题把整个分区甚至全部分区都弄得不能访问了。   最后要说的是,网络备份只是小孩子过家家的玩意儿,当然,我只是使用那些免费的服务,不但空间容量小,而且传输速度慢,以及到目前为止并没有证明其可靠性有良好的保证。   所以最后的结论是,等手头开始宽裕了,就装个高配置的台式机,最好能配个RAID,这样应该算是比较可靠的了。

DForD SourceCoding介绍

  我一直在寻找,甚至试图自己编写一个Source Insight的替代品,主要看中它作为一个源代码阅读工具,并具有良好的通用代码编辑功能。如果一定要找出同类产品来,还真是比较难,也许Komodo IDE和SlickEdit在通用代码编辑器的范围上可以往上靠,但在代码阅读器的范围内,实在很少见,可能doxygen和understand for C++可以勉强算是一类,但实现方式差别很大。现在有了DForD SourceCoding,总的说来,它是最接近Source Insight定位的同类产品。   DForD SourceCoding具有良好的中文支持,这得益于Scintilla控件的完美实现和ICU的强大兼容性。Source Insight的中文支持一直是其软肋,多年来没有什么实质性的改进,无论是保存项目文件的路径字符,还是文件中的字符,凡是中文,都很有可能出现轻重不一的问题,DForD SourceCoding则完全没有这些问题。   DForD SourceCoding使用Tab栏多文档界面,很难想像如今还有一个拥有大量用户的多文档界面的软件,居然没有Tab栏,Source Insight就是那么一个独树一帜的软件,以至于有牛人通过逆向工程等手段,给Source Insight开发了外挂,通过外挂给Source Insight添加Tab浏览等功能,可谓用心良苦。   还有一个大问题是DForD SourceCoding的代码编辑器是支持代码折叠的,而Source Insight至今仍无任何迹象显示要在这方面有所改进。代码折叠也算是众多Source Insight用户特别期待的一个功能了,对于现在一个完整的代码编辑器,基本上可算是标准配置,可是比较遗憾的是,这个功能似乎连外挂也是不能指望上了。   当然DForD SourceCoding也有不少缺点,比较明显的是,速度比较慢,比起Source Insight不是差了一两个数量级。其次,DForD SourceCoding的代码分析功能相比Source Insight来说,不够精准。DForD SourceCoding直接使用了ctags和cscope来进行代码分析,而Source Insight应该是对cscope进行了一定的改进,而且跟编辑器结合得更紧密。另外,DForD SourceCoding虽然本身是基于一个Lua脚本语言扩展的架构实现,但它并不开放这个扩展构架以便用户进行二次开发,而Source Insight则是向用户开放了脚本扩展的能力。所以说,DForD SourceCoding还需要持续改进,才能彻底战胜Source...

Lua中使用DOM读写XML

  在Lua神作《PIL》中操作XML的示例是用expat库的,众所周知expat是用类似SAX的接口的,这里介绍一下使用其他的库来实现DOM接口操作XML。   可以使用的库有几个选择,包括ltxml,xerces,rapidxml等等。ltxml使用TinyXML和TinyXPath提供的服务,xerces使用Xerces-C++提供的服务,而rapidxml则是使用RapidXML。这三个库我都有过一段时间的使用,不过都没怎么深入过。总的说来三个库各有特色,呃,其实是它们依赖的C/C++库的特点,ltxml我不是很喜欢,当初用的时候发现不知道为什么,同样一段代码执行多次后,打开并读取XML文档就会出错。于是后来转用xerces,它倒是基本让人满意,不过得附带一个Xerces-C++的DLL,感觉有点不爽,而且Xerces-C++应该说是比较完整的实现了XML的几个接口标准,但xerces只是封装了其中DOM读写的很小一部分接口。而rapidxml胜在运行速度飞快,从RapidXML的项目主页上可以看到一个简单的横向评测结果。xerces和rapidxml的Lua接口非常相似,除了几个节点类型常量的名称和载入的表的名称不同外,其他的读写接口名称和签名几乎一模一样,它们的源代码可以在它们的项目主页上通过svn下载得到,但需要用户自己编译,当然也可以下载安装LuaPack,LuaPack提供已经编译好的xerces和rapidxml文件,但要注意的是由于使用VC2010进行编译,只能在Windows XP SP3或更高版本的Windows系统上运行。   下面以rapidxml为例,简单演示一下如何操作XML文档。   新建一个XML文档,并保存:   require "rapidxml"   local doc = rapidxml.parse( "" ) -- assign root node xml text   local root = doc:root()   for i = 1, 10 do...

LuaPack

  Lua官方只提供了一个解释器和一个编译器,不像Python、Ruby那样有一个大而全的标准库。但是Lua仍然有众多的第三方库,像Luaforge上就托管了一大批Lua相关的项目。   为了方便用户使用,也有第三方贡献者将一些常用的第三方库编译并打包在一起提供,比较著名的是Lua For Windows(简称LfW),而这里要介绍的是另一个刚开始没多久的项目,叫LuaPack。LuaPack受LfW的启发而创建,而且比LfW走得更远。LuaPack不但已经完成了对Windows系统的良好支持,从其SVN仓库中可以看出,现在正着手努力使其支持(Ubuntu) Linux和MacOSX,这是LuaPack与LfW最大的区别,而LfW从项目名称上就可以知道是只支持Windows系统的。另外,LuaPack打包了一个专业的Lua IDE,叫DForD LuaCoding,这是一个由DForD Software提供的针对Lua语言开发的IDE环境,勿庸质疑DForD LuaCoding的功能比LfW中附带的基于SciTE的编辑器要强大得多,但DForD LuaCoding是个共享软件,未注册版将会在每次启动时弹出一个要求输入注册码的对话框,除此之外没有任何功能或使用时间上的限制。最后一点小区别是,可能是基于创建者自身的价值理念,LuaPack和LfW打包的第三方库有些许不同,有的库只在LuaPack中存在,而另一些库只在LfW中存在,而且LfW是使用VC2005编译,所以可以在Windows 2000及更高版本中运行,而LuaPack使用VC2010编译那些Lua扩展库,所以只能在Windows XP SP3或更高版本中运行。   就我个人而言,LuaPack更值得推荐使用。

阶段性小结

  昨天算是发布出去了,这次花了3个月时间。修正了一些bug,添加了一些新特性,修改了一些功能。总之,现在回头看来,不那么令人满意。   没有UT是最大的问题,根本不能保证某次修改会影响到什么。这不能再忽视了,test case要开始补起来。   其次是编译器差异和编译模式差异之大,出乎我的意料。好几次都是VC编译出来的正常,用GCC编译的就不正常。或者debug编译的正常,release的不正常。这是因为我离不开Visual Assist,也有点离不开VC的调试器。这点实在不好解决。   再次是Lua开发环境还是不够好用。Auto Completion不准确就不说了,有时Auto Completion出来过后,整个程序就会很卡,不知道为什么。以后要能做到Auto Completion分库,可以让用户随意通过增删文件来增删符号库。   最后一点是对架构的不满意。经过如今大半年的迭代发现,插件扩展架构的可扩展性和可裁剪性不够灵活。这点现在还没有具体的思路,或者说一直觉得实现上也许有点麻烦。   除了这些外,还有许多特性要增加,比如增加几种常见的SCM工具支持,开放二次开发接口,增加插件扩展的开发环境等等。

实现注释和取消注释

  这是个很简单的功能,但却很有用。SciTE和Notepad++都有一套自己的实现,感觉Notepad++的效果比较好。从它们的配置文件中提取出众多编程语言的注释符号即可。注释分为两类,一类是行注释,另一类块注释。不是每种编程语言都支持这两类注释方式,甚至有的编程语言都不支持可以有注释。当然这个不是很重要,反正所有的信息可以写在配置文件中。   昨天还意外地发现,用boost.lambda对std::basic_string和wxString对象进行==比较时,用VC编译的运行正常,用GCC则一直不正确。一开始还以为是两个编译器对两种字符串对象的内存布局不一样引起不同的结果。最后发现,其实是我自己写的迭代器在std::find/std::find_if中不正常,在GCC编译的程序中,比较谓词根本没有被调用。回想起来当时看到GCC的std::find/std::find_if对于随机迭代器是特化实现的,想想其实我那个迭代器不需要随机迭代器,用双向迭代器就可以了,改了后,一切都正常了!