All Stories

Twitter客户端大赏之Tweetie

Tweetie for Mac是个在Mac系统上比较流行的Twitter客户端。   首先,它是个原生的Mac应用程序,而且轻便小巧。但绝大多数的Twitter该有的功能,还是有的。不过要提最重要的一点是,它目前貌似不支持List,这是一大遗憾。很多Twitter用户是比较重视并依赖List功能来组织自己感兴趣的推友的,客户端不提供支持,则很容易让用户放弃这个客户端,转头寻找其他合适的产品。虽然有这个大缺憾,似乎用它的人还是挺多的,确实其他的功能还是做得很赞的,也支持几种常见图床和URL缩短服务。它支持多账号,但不能自定义API,也不能设置代理,仍是那句话,Mac系统补上了这个缺点。它也不能让用户自定义刷新间隔,而且目前仍然使用着OAuth API,不过想来随着将来Streaming API的使用,这个问题也将不复存在。   其次,它界面美观,清爽。使用类似Echofon的单列显示界面。界面切换时,有动画效果,虽然并没有实用价值,却仍能让人觉得炫目。就我觉得,这应该也算是Mac风格,或者说iOS风格的界面吧。   最后,它是个共享软件,也有免费版,据说是加入了广告,实际上我用了也没发现哪里有广告,所以尽管它的功能足够简单,但也大致够用,要是它能支持list,并使用Streaming API,我肯定毫不犹豫地放弃Echofon,转投Tweetie门下。

Twitter客户端大赏之Seesmic Desktop2

  Seesmic是个盛产Twitter客户端的vendor,不但有PC桌面用的客户端,还有for iPhone和for Android的版本。光是PC桌面客户端,也有好几个不同的产品,有使用WPF开发的Seesmic Look,有基于AIR开发的Twhirl和Seesmic Desktop,还有使用Silverlight开发的Seesmic Desktop2。   Seesmic Desktop2最近出了新版本,原本它是只支持Windows系统的,在新版本中同时又支持Mac系统了。它与Seesmic Desktop一样,采用插件的架构,各种SNS服务都由一个插件实现,在安装的时候会自动联网下载几个常用的SNS服务的插件,包括Facebook和Twitter。Seesmic Desktop2与Echofon可算是SNS桌面客户端的两类典型代表,前者是走的整合路线,一个客户端内提供多种SNS服务的支持,一个客户端内可以完成所有事务,后者走的是精简路线,一个客户端只做好一种服务的支持,现在也不能说出哪种是更好的方式,各有优缺点吧。   Seesmic Desktop2的最新版也支持Twitter的Streaming API,不过经过我的试用发现,墙内用户需要在启动程序前先开启VPN,这样Seesmic Desktop2就会自动使用Streaming API,然后即使断开VPN也没有影响。如果一开始就没有翻墙,就会使用目前主流使用的OAuth API。Seesmic Desktop2与Echofon一样,程序本身既不提供自定义API功能,也不能设置代理服务器,也许它们从来不知道还存在我们这样的用户吧。Seesmic Desktop2的界面与TweetDeck类似,采用多列显示的方式,但总的说来,Seesmic Desktop2的界面更漂亮些,而且少一些没多少用处的界面元素,不过左侧有个侧边栏比较占用屏幕空间。Seesmic Desktop2提供很少的可配置项,不知道是不是作者认为默认的设置已经足够满足绝大多数用户的需求了。Seesmic Desktop2会在消息条目中直接显示几个常见图床上的图,这个功能还是比较赞的,很多客户端需虽然也本身提供图片预览功能,但需要用户点击链接后才会显示,就我个人感觉,这种不会明显影响用户读取消息的过程,应该程序可以帮助用户完成,当然如果能提供一个开关选项让用户自行选择就最好了。   Seesmic Desktop2也有一些小缺点,它的右键菜单弹出延迟很明显,有时候头像上方显示快捷按钮后不能自动恢复。最后是我一向比较反感的,非原生的应用程序,不但占用资源多,运行速度也慢。   最多不得不说,Seesmic Desktop2是很值得一用的客户端,多列显示的方式可以让用户一眼看到所有相关的消息,支持Streaming API又提升了用户体验,推荐使用。

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更值得推荐使用。