All Stories

Ninayan W.I.P.(7)

  添加了个图片本地缓存的功能,结果发现不是很好用。在Windows下实际使用时发现有时候装载本地文件仍然很慢,甚至不如直接从网络上加载的快。在Mac下发现压根就装载不上。初步估计是因为多处同时读写文件时有冲突,需要再仔细看看。   把删除消息,去fav后的响应也添加上了。   另外还有些细节方便的调整,比如所有显示图片的地方都添加了等待动画。   最后发现个奇怪的问题,在Mac下读取Friends列表有问题,json解析失败,这太诡异了。   今天听@shellexy说,用HTML5的话,配合JS/CSS这些东东,可以实现跨iOS/Android/WebOS/Symbian/MeeGo,呃,这也太强大了吧,而且据说Hotot移植到这些平台已经是在计划中了。得好好考察一番这种开发方案了。

Ninayan W.I.P.(6)

  昨天突然发现有内存泄漏,确实找到几次没有释放的,后来从任务管理器里看,貌似还有泄漏,但实在找不出有什么地方有问题了,最后今天把所有自己new和delete都放在一个类中统一调度跟踪,发现确实是都正确释放了的,只好先不管了。   今天搞定了显示friends和followers列表的功能,增加了显示所有自己发布的消息的功能。明天就搞一下显示之前的消息的功能。之后再修改一下消息显示的格式,比如图片预览,超链接处理等,然后就算是完成一个milestone了吧。   不多说,也是上两张图,还被@shellexy嘲笑了说~

Ninayan W.I.P.(5)

  经过一天的折腾,Ninayan已经能完成跟消息相关的绝大多数操作了,私信也搞定了。作为一个纯粹的微博客户端来说,也就剩下图片上传和用户Profile查看没做了。更多的诸如图片预览等功能属于比较有用的增值功能,不在这个范畴内。

Ninayan W.I.P.(4)

  汇报一下进度,Fanfou的API果然是最简单的,现在除了可以浏览时间线,回复线和收藏外,已经可以做些基本的操作了,比如发消息,当然包括回复,收藏和取消收藏,删除消息。而且也把消息都保存到本地了,每次切换页面时,显示消息的速度就相比以前会快一点,以前是每次都要从服务器上取下来才能显示。   接下来要解决的是,发布消息后刷新界面,以及消息中的超链接处理等细节问题。

还是不成熟

  知道这样的结果,心里还是很难过,很阴暗的心理,唉。好好调整。

Ninayan W.I.P.(3)

  今天折腾下来后,已经可以浏览饭否的最新的timeline,mentions和favorites了,当然,也仅仅只是能浏览而已,所有其他操作都还没做,不过至少证明这个架构是能正常工作的。上张截图吧:

想给某人准备份生日礼物

  今天突然想起,给某个3个月后过生日的人准备份礼物?   其实这样的傻事以前就做过,还不止一次,后来每次回忆起来,都会觉得自己非常傻。可是即使一直觉得傻,后来还是会再去做,这才是最傻的,于是直到今天,我仍然傻着。   前天看到鱼本非鱼写的一个沙画软件,用来庆祝他女朋友生日快乐的。我想就是因为这件事,才又激起了我再傻一次的冲动。   记得小时候,大人们教育我们说,生日礼物要自己做的,才是感情最深的,最珍贵的。可是无论如果,在如今的现实社会中,我怎么都说服不了自己接受这个观点。但是,对于一个一无所有的可怜男人来说,虽然体内藏着一颗躁动的心,那爱出风头,喜欢标新立异,又希望玩点浪漫的心思在缺少金钱的支持下,是如此的无奈。   好吧,不找更多的借口和理由了,反正就是做为一名不合格程序宅,这只是一种惯用的表达方式而已。   Good luck!

总结2010,展望2011

  好吧,突然发现twitter上很多人说要写年终总结神马的。   总的说来,又是一事无成的一年,做SW已经一年多了,收入只够支付空间和域名的费用,这个太凄凉了,有点奇怪。想想可能是方向有点偏门,然后品质又达不到目标用户的挑剔的要求。所以最近一两个月已经在作些调整了。一方面,原有的IDE产品线,要继续推出其它编程语言的支持,以及支持TextMate的Bundles机制,还有实现几种最流行的SCM工具的集成。这三条是做为杀手锏的。另一方面,开辟新的产品线,已经有一个SNS/RSS客户端目前正在开发,完整的计划是PIM产品线,包括GTD、PKM、理财、日记、Email以及SNS/RSS的完美整合的客户端,而且是要覆盖Windows/Mac/Linux/Symbian/MeeGo这些平台,甚至Android与iOS可能也会有支持,这是后话。   再说到上半年,还以为能脱光的,结果可耻地失败鸟,倒是有点怨气的,花费了不少时间和金钱,不过也只能以发现得早代价小来安慰自己了,尽管这个代价已经超出我的底线很多。突然很想念小妞,思思她们,以及跟她们一起生活的时光。   至于对明年的期望,呃,还是老样子啊,希望SW事业能尽快走上正规,甚至飞速发展。然后有点底气后,希望能顺利脱团吧。啊,我只是想脱团,还没想结婚,我说过没有买得起上海或杭州主城区180平房子的能力前,暂不考虑啊。

Ninayan W.I.P.(2)

  其实是个小功能,真正实现起来还是有点花时间的,那就是移植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进缓存。不过这些只是我现在的构想,不知道是否可用,先放着吧,这个问题不是很急。   最后,传张代理配置界面的截图吧,这回是真实数据了。