搜狗输入法名不虚传，很好用。用微拼，我打了几百年的“试一试”或者“试试”看，仍然出不来这两个词，从微拼2.0到3.0，这个问题从来没有被解决过，搜狗输入法在我第二次使用的时候就牢牢记住了我的偏好，一打便出。
搜狗输入法好处在于两点，一是利用搜索引擎，将热门词汇直接作为词组在线升级，这样你有了一个活的输入法；二是将你常用的词自动放到前面。微拼也做到这一点，但是不彻底，往往你输入了数十次之后才稍稍往前挪一点，而搜狗则简单的将用过一次的词就放到最前面，这个特性深得我心。
日常使用方面，没有什么比输入法更重要的了。写作的时候，一个好的输入法保持你思维的连续性而不是SB的让你在一堆字中挑选那个恰当的字。这种事情可一而不可再。从今天的试用感觉看来，新的输入法至少提高了20%的打字速度，以及50%的心情愉快程度。
http://www.ruby-forum.com/topic/62907 提到了Armageddon，顺着link找，又看到了COMET – the next stage of AJAX， Comet: Beyond AJAX 。简单的解释Comet：传统的HTTP技术是客户端主动拉服务器端内容，每次更新需要刷新整个页面，这种方式在带宽不足的情况下用户体验尤其恶劣；AJAX让这个过程转到后台，将一次性的全页面载入转变为多次的小批量异步载入从而改善交互体验；而针对基于网页的及时通信等应用，这种每隔几秒的请求响应不够快，而且无状态的HTTP协议对服务器端效率的影响比较大。
如果说AJAX是新瓶装老酒，那么Comet则干脆连新瓶子都不用了。早在2002年更早的时候，pushlet提出的概念让我眼前一亮，基本原理是将需要持续更新的内容放到一个永远也下载不完的页面中(JSP代码)：
< % int i = 1; try { while (true) { out.print(""+(i++)+""); out.flush(); try { Thread.sleep(3000); } catch (InterruptedException e) { out.print(""+e+""); } } catch (Exception e) { out.print(""+e+""); } %>
这就是Comet的基本原理。其他的基于HTTP协议的Comet实现大多数原理如此，为了更好的提高效率，Event-Driven IO会被大量使用，如Java NIO, Twisted. 03年发现一个基于Web的网络游戏，也是这个原理。在我研究Amowa期间，发现利用Flash作代理，利用它的remoting或者XMLSocket能力，也可以实现实时的web应用。
这种技术的引入将带来web应用开发方式的一些变化，基于事件的实现方式可能更容易在Comet中使用。晚些时候我再详细探讨这些概念技术对web开发带来的影响。
看图不说话：
有机会开始了一个小的Flash项目。自从五年前当过一阵老师，在赛扬300上教过别人怎么用Flash后，就再也没有怎么认真碰过它。于是兴趣盎然的开始了研究，怎么获取Mic, 怎么录音，怎么保存文件，如何播放，如何使用第三方的ActionScript库来制作界面。一天半过后，居然一个像模像样的Flash应用出现在了网页中，成就感巨强。相比这几天前百无聊赖的摆弄JavaScript, Java, 以及毫无目的的阅读Ruby/Rails, 这种感受来得更真实丰满些。
想到了我那些到现在为止还处在半空中的项目，用一些熟悉的技术熟悉的方式来开发，只需要闭上眼睛就能想象出如何实现的那些特性，越来越感觉编程如果不能给自己带来快乐或者给客户提供价值，跟搬砖无异。这时候经验不是一种帮助，而是一种负担，一种严重的负担，这个时候你知道了多少东西，那些东西就联合起来，在你前行的路上形成多高的壁垒。如果技术本身不能给你带来快乐，这个时候带给你的就是痛苦，那种远望着目标，明知道一步一步就可以走到却跨不过自己筑下高墙的痛苦。
老庄：http://zbw25.spaces.msn.com/Blog/cns!BD4EFBFAF436336C!1227.entry
4、Blog+Digg+Dzone的展现方式，是一个不错的发展方向
与江南白衣聊天时想到的
即便这样想到，又如何呢？我想老庄或者白衣都至少知道100种以上的方法来如何实现这些东西，但想到不等于做到。在自己制造的漩涡中磕磕碰碰的人远比那些真正有所建树的人多，而尚未开始便已结束徒留嗟叹的人更多，而更过分的人将自己制造的壁垒越延越长，用来阻拦那些同样有想法的人。郑渊洁《智齿》中说，“创意的天敌是经验”。在真正想做一件事情的时候，经验是最大的障碍。
旧文一篇作注解：学习，研究，工作，灵感——学习过程其实是一张网
Web2.0最重要的特征就是，通过一定的分析方法，将具备相关兴趣的人聚集在一起。做法上，不同的应用有不同的方法。现在要说的是一种具体应用无关的分析方法。
先考虑现实中的情况。张三看了《疯狂的石头》，李四也看了。两人的在某种情况下见面聊起这部电影的时候发现观点基本相同。于是相见恨晚，以后的电影，张三推荐了，李四很有可能会看。如果恰好张三推荐的电影李四也喜欢看，两人的兴趣更接近了，意味着以后张三推荐的电影或者其他的东西，李四更可能会看会用。
很多网站做的用户兴趣相关性基于这样的现实。评价网站则严重依赖这样的事实。当用户A评价一个东西不错，用户B有相同的感受的时候，两人兴趣相投，于是对平台——就是这个网站产生了依赖。从某种程度上说，绝大多数web2.0应用所作的事情，只是把人们的社会化的需求挖掘出来，从而产生交流的欲望，进而产生对网站本身的依赖。至于提供各种服务，只是为了更好的让用户进行交流。
相关性的关联方式，可以是功能本身，例如读一本书，为某一项产品/内容做一个标签。一旦这个标签多了起来，形成一条曲线，那么根据曲线的相似程度，可以判断出这些用户的行为相近程度，进而分析出他们的兴趣相近程度。
从功能无关性的角度看来，这些都可以被抽象。读一本书可以是一个功能，打标签也可以是功能。抽象出来如下：
功能ID 动作 目标 值
1 读书 兄弟 推荐
2 标签 兄弟 余华
…
用户ID 功能ID
1 1
1 2
2 1
2 2
（上面的例子显示出，两个用户具备相同的行为，有理由想象两人有相似的兴趣）
在进行相关性分析的时候，只需要将ID与用户关联起来即可。相关性搜索算法就与具体的应用没什么关系了，一些常见的数据挖掘的技术在这里可以大显身手。