All Stories
汇报一下进度，Fanfou的API果然是最简单的，现在除了可以浏览时间线，回复线和收藏外，已经可以做些基本的操作了，比如发消息，当然包括回复，收藏和取消收藏，删除消息。而且也把消息都保存到本地了，每次切换页面时，显示消息的速度就相比以前会快一点，以前是每次都要从服务器上取下来才能显示。
接下来要解决的是，发布消息后刷新界面，以及消息中的超链接处理等细节问题。
知道这样的结果，心里还是很难过，很阴暗的心理，唉。好好调整。
今天折腾下来后，已经可以浏览饭否的最新的timeline，mentions和favorites了，当然，也仅仅只是能浏览而已，所有其他操作都还没做，不过至少证明这个架构是能正常工作的。上张截图吧：
今天突然想起，给某个3个月后过生日的人准备份礼物？
其实这样的傻事以前就做过，还不止一次，后来每次回忆起来，都会觉得自己非常傻。可是即使一直觉得傻，后来还是会再去做，这才是最傻的，于是直到今天，我仍然傻着。
前天看到鱼本非鱼写的一个沙画软件，用来庆祝他女朋友生日快乐的。我想就是因为这件事，才又激起了我再傻一次的冲动。
记得小时候，大人们教育我们说，生日礼物要自己做的，才是感情最深的，最珍贵的。可是无论如果，在如今的现实社会中，我怎么都说服不了自己接受这个观点。但是，对于一个一无所有的可怜男人来说，虽然体内藏着一颗躁动的心，那爱出风头，喜欢标新立异，又希望玩点浪漫的心思在缺少金钱的支持下，是如此的无奈。
好吧，不找更多的借口和理由了，反正就是做为一名不合格程序宅，这只是一种惯用的表达方式而已。
Good luck！
好吧，突然发现twitter上很多人说要写年终总结神马的。
总的说来，又是一事无成的一年，做SW已经一年多了，收入只够支付空间和域名的费用，这个太凄凉了，有点奇怪。想想可能是方向有点偏门，然后品质又达不到目标用户的挑剔的要求。所以最近一两个月已经在作些调整了。一方面，原有的IDE产品线，要继续推出其它编程语言的支持，以及支持TextMate的Bundles机制，还有实现几种最流行的SCM工具的集成。这三条是做为杀手锏的。另一方面，开辟新的产品线，已经有一个SNS/RSS客户端目前正在开发，完整的计划是PIM产品线，包括GTD、PKM、理财、日记、Email以及SNS/RSS的完美整合的客户端，而且是要覆盖Windows/Mac/Linux/Symbian/MeeGo这些平台，甚至Android与iOS可能也会有支持，这是后话。
再说到上半年，还以为能脱光的，结果可耻地失败鸟，倒是有点怨气的，花费了不少时间和金钱，不过也只能以发现得早代价小来安慰自己了，尽管这个代价已经超出我的底线很多。突然很想念小妞，思思她们，以及跟她们一起生活的时光。
至于对明年的期望，呃，还是老样子啊，希望SW事业能尽快走上正规，甚至飞速发展。然后有点底气后，希望能顺利脱团吧。啊，我只是想脱团，还没想结婚，我说过没有买得起上海或杭州主城区180平房子的能力前，暂不考虑啊。
其实是个小功能，真正实现起来还是有点花时间的，那就是移植AutoProxy的功能。在Ninayan中的过程大致如下：
1、从本地读取gfwlist.txt（假如存在的话），然后应用到代理管理器中；
2、从googlecode的svn上下载到最新的gfwlist.txt，然后应用到代理管理器中，如果第一步已经成功执行过了，那么这步的应用到代理管理器的操作会被略过；
3、将下载到的gfwlist.txt替换本地那个老的gfwlist.txt。
应用到代理管理器也不难，首先将gfwlist.txt内容全部读出，然后Base64解码，按行分隔，除掉空行和注释行，剩下有效的规则大约是2700多条。规则分为5类，分别是关键字匹配，主机域名包含匹配，正则表达式匹配，开始字符串匹配以及一种优先级最高的强行不代理规则的匹配。
现在的问题是，代理似乎是能正常工作了，但感觉有点性能问题。于是我就想是不是应该想点其他办法加速这个匹配过程，比较容易想到的是做个简单的缓存，比如已经被匹配过的，需要代理的URL就保存到缓存中，以后有新的代理验证请求来的时候，先在这个缓存中找是不是已经有过，如果有了，就直接返回。这是基于这样一个假设：用户浏览的网站比较集中。而且这个缓存不能大，粗略地想想，可以保持在几十或几百个URL的容量，然后每个URL要维护一个计数，如果缓存一满，就把计数最少的删掉。不过这要注意一个问题，如果时间一长，缓存中的每个记录的计数都很大，然后新的URL就再也进不了缓存了。这种情况很容易出现，比如用户突然从某天开始关注起一个以前都不关注的网站了。其实这个问题也有个笨的简单方案，就是为每个被规则匹配成功的URL都维护一个计数，然后定期选出计数最大的一批URL进缓存。不过这些只是我现在的构想，不知道是否可用，先放着吧，这个问题不是很急。
最后，传张代理配置界面的截图吧，这回是真实数据了。
兵马未动，粮草先行。第一次用Qt，第一次用QML，用QML Viewer做原型，可以强迫自己界面与逻辑分享，大赞啊！于是先把几个主要部分的界面用QML画出来，当然，所有显示的数据都是假的。现在还没想好显示和操作微博的界面应该弄成什么样，本来想模仿FaWave的，可是前些天Reeder把MobileRSS的界面抄袭抖出来后，弄得我不好意思抄别人的了，继续发呆神游天外。先放截图上来，其实用QML的主要原因除了比较容易做出漂亮的界面外，还因为操作上有各种动画效果，这里静态图片上就看不出来了。
另外还有个Paper视图，以paper.li的那种排版显示内容，其实就是一个网页浏览器，现在也没有可看的内容。
腾讯也开放微博API了，这对于一个一贯坚持封闭的公司来说，真是个很艰难的决定。但是，眼下的互联网环境中，开放已经成了大趋势，想想Facebook和Twitter这两种SNS的代表形式，由于API的开放，第三方的应用和客户端真是百花齐放，争奇斗艳，不开放就是死。腾讯在推出微博服务的时候，我猜他们一点都不担心自己的用户数，因为他们自以为有庞大的QQ用户基数支持，只要让QQ客户端支持微博，就能顺利将用户转移过去。事实是国内使用微博的用户，绝大多数不是使用网页端，就是使用手机客户端，同时可以想像得到，目前的QQ死忠用户鉴于他们的年龄，知识构成，社交习惯等因素，很难迅速接受并支持微博这种表达方式，对他们来说，QQ签名就足以支持他们对微博这种媒体形式的需求了，那样更方便，更直观。
开放API，并不是说将微博功能从网页端到其他桌面端或手机端实现一遍就完事了。Twitter在这方面无论是官方还是第三方都有不少的尝试，当然这也跟服务商对微博的定位有关系。比如Twitter之前说过他们做的不是社交服务，而是新闻服务，提供的是内容，所以Twitter官网的上次大改版就是往这个方向上发展的，它更注重内容的展现，希望用户可以方便快捷地获取到各种信息。而国内的诸多微博服务，无一不是停留在最原始的框架下，对于信息的回溯检索，或是扩散都没有任何明显的形式的支持。就像之前ifanr对和菜头的访谈中提到的那样，国内的微博在意识形态上仍然停留在精英制造内容，草根膜拜瞻仰的原始阶段。
这些天推友@lucifierya一直在推一些他对个人知识管理的想法和实践，他主要偏重从网络上获取的信息，包括RSS、Blog、Tweet等。其实这三部分独立的，都有各种实现得很好的方案，两种或三种结合的也有一些方案，但显然就很不被重视了。再回头说腾讯，腾讯有QQ阅读器，有QQ空间，也有微博，三者也有简单的关联，比如QQ阅读器中可以看到好友最新文章，但也仅此而已了。我对@lucifierya的一些想法深以为然，但也许因为他个人缺少对软件开发方面的知识和技能，他提供的解决方案就有点畸形。我在上Twitter的这一年来，一直在考虑自己实现一个Twitter客户端，一开始只是一个单纯的客户端，后来想法就逐渐有所延伸和扩展。单纯的客户端并不是我想要的，我的本意是需要一个获取信息，管理信息的工具。考察和试用了不少其他的服务，想法已经比较完整，但尚未明确和具体，大致如下：
1、连接各微博服务，当然首要是Twitter，提取微博中的网址超链接，作为一个信息源。
2、连接各书签分享服务，比如Delicious，ReadItLater，Instapaper等，作为第二个信息源。
3、订阅RSS以及Google Reader，作为第三个信息源。
4、方便地将超链接分享到微博和书签服务中去。
5、将网页主要内容提取显示。Readability、iReader等扩展的作用很明显，可以极大地提高用户体验，但将这功能放在浏览器中需要用户手工激活，有点繁琐，而在专业的内容阅读器中默认采用这种形式就方便了。
6、将所有内容条目以列表形式组织显示，如Feedly或Reeder那样，可以看到每个条目的开头的一部分信息以及内含图片的缩略图，用户就可以直接判断是否是自己感兴趣的内容。
7、将所有内容条目以报纸排版显示，如QQ阅读器或http://paper.li那样，这样除了有上一条的好处外，更多的是一种贴近传统习惯的用户体验，至少我个人是相当喜欢这种形式，只不过QQ阅读器一页显示的内容太少，以及不能自行添加RSS订阅，而http://paper.li时有乱码，更新周期太长，并且导致有时候一页内空白块太多，不够美观。
8、用户可以对内容添加评论，评论内容和相关链接可以保存到Google Docs上去，这样就可以移动应用了。
以上这些就是我总结出来的大的需求，其他小需求暂且不提。我会自己用Qt慢慢实现，以目前的能力来看，至少可以实现跨Windows/Mac/Linux/Symbian/MeeGo了，也许以后Qt移植到Android和iOS上后，也会支持Android和iOS吧，这是后话了。
现在不少服务都用OAuth认证了，在Qt下有QOAuth这个第三方库，它是个日本人为qTwitter这个Twitter客户端而编写的。要编译QOAuth，有几个步骤。
首先，编译QCA，这是个KDE下的项目，Qt下的加密算法库封装。
然后下载OpenSSL，需要头文件和导入库文件。编译qca-ossl，即连接QCA和OpenSSL的Qt库插件。
最后便可以编译QOAuth了，需要链接QCA和OpenSSL。
今天我试着用MinGW和MSVC2008编译QOAuth，除了编译qca-ossl时发现有个whirlpool算法分支编译不过外，其他的都编译出来了。接着我就想编译一下Qwit和qTwitter来测试一下QOAuth，结果编译倒是都能编译出来，不过最后运行有问题，在认证Twitter账号时，程序会死循环，不知道是OAuth认证的3个步骤中的哪步出错了，初步估计是第一步，因为连浏览器窗口都没弹出来。也不知道是几个库中的哪个库有问题，唉！
