All Stories

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进缓存。不过这些只是我现在的构想,不知道是否可用,先放着吧,这个问题不是很急。   最后,传张代理配置界面的截图吧,这回是真实数据了。

Ninayan W.I.P.

  兵马未动,粮草先行。第一次用Qt,第一次用QML,用QML Viewer做原型,可以强迫自己界面与逻辑分享,大赞啊!于是先把几个主要部分的界面用QML画出来,当然,所有显示的数据都是假的。现在还没想好显示和操作微博的界面应该弄成什么样,本来想模仿FaWave的,可是前些天Reeder把MobileRSS的界面抄袭抖出来后,弄得我不好意思抄别人的了,继续发呆神游天外。先放截图上来,其实用QML的主要原因除了比较容易做出漂亮的界面外,还因为操作上有各种动画效果,这里静态图片上就看不出来了。   另外还有个Paper视图,以paper.li的那种排版显示内容,其实就是一个网页浏览器,现在也没有可看的内容。