首页
归档
分类
标签
软件
关于
链接
订阅
代码
类库大魔王的挖井日记
挖一口属于自己的井
All Stories
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的那种排版显示内容,其实就是一个网页浏览器,现在也没有可看的内容。
从腾讯开放微博API说起
腾讯也开放微博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吧,这是后话了。
QOAuth编译后运行不正常
现在不少服务都用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个步骤中的哪步出错了,初步估计是第一步,因为连浏览器窗口都没弹出来。也不知道是几个库中的哪个库有问题,唉!
怀念测试组,想念马姐姐
在GTalk上聊天,说起同事集体活动,突然思绪飞回2005年了。我入部门的第一个周六便是项目组活动,去深圳东门的工人文化宫溜旱冰。我并不会溜,所以摔了半死,不过后来倒也勉强能滑一会儿了。 然后我想到了马姐姐,当年那个号称“光网络第一美女”的主管大人。我进测试部一直是一种说不清道不明的奇怪体验,因为我其实只想做开发的,记得到部门报到的那天,项目部的老大跟马姐姐交接了我们两个新人后,轻声跟马姐姐说我的培训计划要调整一下。这是我到现在都没明白是怎么回事的事。 在测试组呆了22个月,其实应该只有21.5个月,但印象却深刻得多,令我怀念得多。在测试组我的绩效一直不好,一直测不出产品问题,直到3个季度后通过代码审查才能凑够PBC指标。然后俨然一副(伪)高手的样子,哈哈。后来项目组迁移到成都,直接主管问我愿不愿意去成都,我不假思索地说不愿意。之后就直接把我释放到系统部去了,而听其他的同事说,他们都是至少被问过两次的,这也是让我觉得奇怪的事情。 还有件事也是不吐不快,这事一直是我们那拨人的谈资。测试部组织C语言考试,题目出得比较变态,要求75分合格。我们测试组的一帮人,咳咳,通过大家都知道的手段,有4个人考到80分以上,其中一个就是我。结果大条了,貌似其他组就没人合格的,就我们组就被整了,另外三个同事被叫去,结果当然是老实交代了。最意外的是我没被叫去,他们都说是看了我的答案。马姐姐作为我们的主管,当然事情就捅到她那里了,她就问我怎么回事,我一脸愤恨的说没办法,被逮住了是我们倒霉。现在想想当时的我真的挺欠揍的,呵呵,想来只要老实点认错,马姐姐的立场看怎么滴都是要保我们的。当然这事后来也是不了了之。 总之,从一个局外人的角度看,当年我在测试组的表现,可以说是成事不足败事有余,却莫名其妙的桀傲不训,作为我的主管应该很头痛吧。我转正后的第二个季度只完成了PBC一半的指标,于是自然而然被打了个D,我非常郁闷,思思玉玉和小妞都安慰我鼓励我,马姐姐和我的直接主管找我谈话,说是对我还有期望,不然就直接开了。我后来偶尔想起这个事了,就觉得有点诧异,为什么会给我个D然后又不开我呢?总不至于真是因为说这个招聘成本比较高,然后神马的吧,总觉得这说法不太靠谱。 马姐姐是个比较时尚的人,呃,这样说应该没什么大错吧。她喜欢运动,貌似打羽毛球很厉害,不过我没去看过她打球。她喜欢唱K,我们好几次活动都去唱了K,导致后来我们组的人很多都比较喜欢唱K。不过马姐姐有点色色的哦,喜欢跟组里几个唱歌好的帅正太对唱的,哈哈。哦,突然想起来,有一次活动,好像是他们下午泡温泉我没去,晚饭后又可以唱K打桌球神马的,我们在K厅里唱啤酒,马姐姐拿了我的那杯啤酒喝了一口呢,各种囧。 我们那么些年来一直在猜测马姐姐的婚姻状况,一直没得到确切的消息。直到我辞职的那年,呃,就是去年吧,才通过各种八卦得到比较准确的信息。那时我们已经都在不同部门了,偶尔还一起吃饭,马姐姐作为一个女人当然也喜欢八卦了,问起在坐的每个人的个人终生大事,最后终于有人忍不住问了一句“那你呢”,然后马姐姐就一然淡然地说“我结婚了啊”,再加一副“你们居然不知道,不知道应该是你们的错吧”的表情,但是至于是跟谁结的婚她就闭口不提了。后来跟王同学和她老公一起吃饭八卦,说起来马姐姐开的车跟某男开的是同一辆车,那时我们才比较坚定地相信这个消息应该是没错了。 最后再提一件我有点诧异的事。有一次在食堂吃饭,然后又说起男女关系什么的,说到我时马姐姐来了一句“YF(我的名字)眼光高”,我瀑布汗,她怎么这么看我,虽然可能也没错! 辞职的这一年多来,经常怀念在深圳的工作和生活,想念那些可爱的同事们。
wxWidgets项目中接管未处理异常
wxWidgets本身支持对未处理异常引起崩溃的拦截和后续处理,从它的官方文档中可以看到,只要在wxApp::OnInit()中调用::wxHandleFatalExceptions(true);然后覆盖wxApp::OnFatalException函数,可以比如遍历当前进程的堆栈什么的。 还有种处理这种未处理异常的方法是在程序启动时(一般就是在wxApp::OnInit()中)动态装入exchndl.dll文件,接下来该dll会自动拦截未处理异常,并在崩溃的时候自动在exe文件所在目录生成一个与exe文件同名的.rpt文件,里面以纯文本记录了进程上下文等现场信息。exchndl.dll可以在这里找到,可以看到其实它是配合一个叫Dr MinGW的现场调试器使用的,这是MinGW的方案。 如果是用MSVC编译器,那么有更好的方案,那便是google breakpad,它实现了Windows、Mac OS X、Linux等多个平台的dump,并且除了未处理异常,在MSVC2005之后的编译器中还包括了纯虚函数调用和CRT函数调用参数错误的捕获,另外提供了文件上传等服务,具体的编译部署可以参考这篇还有这篇文章,不过我的实际使用gyp经验是,应该在breakpad的gyp所在目录开始运行python.exe yourpath/gyp --no-circular-check breakpad_client.gyp,不然会报递归溢出。之后就只要在程序运行范围内创建个google_breakpad::ExceptionHandler对象就可以了,它有各种选项,提供了很多功能,可以通过阅读google breakpad的源代码获得详细信息。 值得说的是,这两种接管未处理异常的方案可以同时使用,但就我个人意见是,如果是用了MSVC编译器,配合PDB文件进行dump文件分析得到的信息已经足够了。 最后提一下另一种拦截未处理异常的方法。除在前面提到两种方法外,e使用了另一种方法,它没有在wxApp::OnInit添加任何代码,而是自己添加了一个WinMain函数,是的,MS官方文档给出的Windows程序的入口,在该函数中调用::wxEntry即可,在该函数后面添加IMPLEMENT_APP_NO_MAIN(CXXXApp)而不是平常用的IMPLEMENT_APP(CXXXApp)。这时,WinMain中就可以为所欲为了,比如e是自己写了__try{}__except(){},也可以根据自己需要,用google breakpad或者exchndl.dll什么的。
« Prev
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
Next »
发现
→
imported from CSDN (124)
Film & ACG (15)
Water (170)
Shareware (151)
Software (140)
Plugin Framework (28)
lookfor (36)
CPPOOPGPXP (87)
Lua,Script (51)
Be Old (15)
Job (185)
mm (48)
Emulator (3)
Execise Outdoor (13)
gfw (10)
Reading (20)
Driving (16)
Mobile (15)
wxWidgets (29)
WIND (14)
PSP NDS (2)
CodingStudio (44)
Cryptography (2)
Editor,IDE (6)
TeX (1)
Life (84)
Technic (6)
Qt (29)
SNS (35)
Ninayan (35)
GUI Framework (1)
KarenMeu (1)
Kindle (3)
Coding (16)
Startup (6)
network (16)
Go (10)
idea (1)
os (2)
iOS (1)
Cloud (1)
device (2)
embed (6)
gochess (1)
Router (3)
blog (7)
cmake (2)
Network (1)