All Stories
添加了个图片本地缓存的功能，结果发现不是很好用。在Windows下实际使用时发现有时候装载本地文件仍然很慢，甚至不如直接从网络上加载的快。在Mac下发现压根就装载不上。初步估计是因为多处同时读写文件时有冲突，需要再仔细看看。
把删除消息，去fav后的响应也添加上了。
另外还有些细节方便的调整，比如所有显示图片的地方都添加了等待动画。
最后发现个奇怪的问题，在Mac下读取Friends列表有问题，json解析失败，这太诡异了。
今天听@shellexy说，用HTML5的话，配合JS/CSS这些东东，可以实现跨iOS/Android/WebOS/Symbian/MeeGo，呃，这也太强大了吧，而且据说Hotot移植到这些平台已经是在计划中了。得好好考察一番这种开发方案了。
昨天突然发现有内存泄漏，确实找到几次没有释放的，后来从任务管理器里看，貌似还有泄漏，但实在找不出有什么地方有问题了，最后今天把所有自己new和delete都放在一个类中统一调度跟踪，发现确实是都正确释放了的，只好先不管了。
今天搞定了显示friends和followers列表的功能，增加了显示所有自己发布的消息的功能。明天就搞一下显示之前的消息的功能。之后再修改一下消息显示的格式，比如图片预览，超链接处理等，然后就算是完成一个milestone了吧。
不多说，也是上两张图，还被@shellexy嘲笑了说~
经过一天的折腾，Ninayan已经能完成跟消息相关的绝大多数操作了，私信也搞定了。作为一个纯粹的微博客户端来说，也就剩下图片上传和用户Profile查看没做了。更多的诸如图片预览等功能属于比较有用的增值功能，不在这个范畴内。
汇报一下进度，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进缓存。不过这些只是我现在的构想，不知道是否可用，先放着吧，这个问题不是很急。
最后，传张代理配置界面的截图吧，这回是真实数据了。
