All Stories
我对SNS客户端的想法
在前些天的Nokia World2010中，Twitter的业务开发副总Kevin Thau明确表示，Twitter不是一个社交网络（SNS），而是新闻，是内容，是信息！大言不惭地说，这也是我最近刚刚领悟到的一点。 从半年前，就一直想着自己写一个Twitter客户端，但是不得不说，现在已经有非常多优秀的Twitter客户端了，从共享到免费都有，覆盖了各种平台，那如果我自己要写客户端的话，有什么特色值得用户们抛弃现有的那些客户端来转投这里呢。在这大半年的时间里，我根据自己对SNS的认识，以及自己需求，不断调整心目中的客户端的特性需求，到现在才在心中有一个相对比较固定的框架、模型。 为什么FlipBoard会受到如此热烈的追捧，这就说明对于很大一部分人来说，使用Facebook和Twitter主要并不是为了与人交互和玩游戏，而是为了获取信息，而FlipBoard这种经过整理，同时又有美观排版的方式，很能迎合那些主要为了从网络获取信息的用户的需求。 处于Twitter中文圈中，比较容易忽视的一点是，将Twitter当成一个公共聊天室。当然这也是很大一部分人使用Twitter的目的，传统的网络聊天室的没落，使得用户们不得不将这种需求搬到其他形式的网络服务中，可以看到在各种BBS、论坛、IM群等等都有这种版聊的现象，所以在Twitter中存在这种现象也是正常而且合理的。只不过，从服务提供商的角度讲，应该可以从服务器端，甚至客户端提供这样的信息过滤、隔离的功能，用户可以方便地在两种应用模式间来回切换，想版聊就版聊，想读新闻就读新闻。除了FlipBoard，http://paper.li/也提供了类似的服务，但它目前只能说，这种模式还不错，各种细节方面还很不够。 再扯远一点说，现在很多人应该喜欢使用Google Reader这个服务，但说实话，Google Reader这个界面仍然有很大的改进空间。之前网上一直有人在号召大家使用RSS全文输出，但全文输出后有一个很大的问题是，在Google Reader中如果是全部展开的阅读方式，花费很多时间在拖动滚动条过滤无兴趣的条目上，实际上对于订阅了大量内容的人来说，很多内容只要一眼看到标题，或者其中的某张插图，就没必要看正文了，那现在Google Reader这种阅读方式就显得很落后了。而有一家第三方的Google Reader同步服务在这方面做了不少努力和改进，那就是Feedly。Feedly自己也提供经过分类的新闻内容，但对Google Reader中文用户来说，更有价值的是它的同步Google Reader的功能，可以提取出条目的标题和插图以及正文摘要，并以一定的热度排版，并连接了几家最流行的SNS服务，可以及时分享自己的条目，自从用了Feedly后，我几乎就不用Google Reader的官方界面了（喂喂，你是他们的托儿啊）。 再说回Twitter客户端，目前现在的客户端，基本上都是简单地通过Twitter API将Twitter的Tweet功能从Web搬到桌面或手机端等，几乎没有做更多的需求挖掘。简单地看过几十个完成度较高的Twitter客户端，目前只看到Seesmic Look收集了几组全球知名媒体的账号，但也仅仅是收集，没有更多的特性拓展。现在Twitter推出了新版界面，可以说是诠释了Twitter自己的发展理念，引领了客户端发展的方向──它提供的是新闻，是内容，是信息！ 最后可以得出，我想要的客户端，是融合了FlipBoard、http://paper.li/和Feedly几者特色的客户端。它一方面可以向用户提供类似传统书报媒体提供给用户的视觉感观享受，另一方面则是结合网络、计算机的优势，提供大容量、快捷的信息分享功能。所以它不应该只像FlipBoard、http://paper.li/和Feedly它们一样只有一两家内容提供商，它应该是彻底开放的，允许其他内容提供商以固定的接口接入并提供特有的信息。而且它应该有一定的信息自动分类和索引能力，过滤重复或无价值信息，减少用户浪费的时间。
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...
