很久很久以前,人类还没有掌握刀耕火种的时候,大家都是靠天吃饭,天上掉什么,地里长什么,就吃什么。所以基本上,没有人吃饱过。
后来,经过一番进化和变异,突然,有一位神童领悟了掌控大自然的力量,学会了种植,摆脱了大自然的控制,终于让自己吃上了饱饭。另外一些人也找到了其它的控制大自然的方式,有人种瓜,有人种菜,日子越过越好。而剩下的那些人觉得,靠天吃饱也没什么不好的,自己种植还要劳神费力,所以也懒的去学习和研究他的种植技术,依然过着有一顿没一顿的日子。
后来,这位神童随着种植的技艺不断成熟,加上自己的刻苦努力,使得种植的效率和成果大大的提高,于是,他的农场不断的扩大,而随着收成的提高,他自己不可能吃得完所有的东西,于是就拿出剩余的部分去出售,跟其它大户互相购买对方手里的东西,过上了富足而奢侈的生活。
而随着农场的扩大,他也不可能管得过来所有的农场,于是,那些懒人们开始跑到他的农场里收割他的粮食。一开始,人们这么做的时候很有一种愧疚感,称之为“盗”。而后来,随着日复一日,年复一年,人们已经习惯了每天到他的农场去收割,然后当成自己的,享受的心安理得。
终于有一天,突降天灾,他家的农场也受到了连累,收成大不如前,由于他现在家大业大,需要养的人也多,原来家旁边那些地不够吃的了,于是到更远一点的地方去收粮食,结果发现,这里一点也没有剩下。
虽然他知道他的粮食每天都被那些人随便拿去,但是他以前没有在意过,因为他还有更重要的事做,他也希望这些人能够喜欢他种出来的粮食,而从此放弃靠天吃饭的念头,所以以前他也从来没有公开的站出来批评过那些偷东西的人。但是现在,他不得不这么做了。
于是他发了一条公告,所有偷拿他粮食的人,必须停止这种行为,想吃就拿钱来买,否则,以后他会不定期的给粮食洒农药,后果自负。
此言一出,天下大乱,人们都开始怒吼,你凭什么收我们的钱,你这么多年都让我们随便拿了,凭什么现在来要钱。我们多年没有去山上捡果子吃,导致果树都荒死了,你现在想饿死我们吗?等等等等。
无论如何,饭还是要吃的,只是胆大的,不怕中毒的人仍然敢去他的田里偷,胆小的就只好一边骂娘一边想其它办法了。因为他虽然说了不定期的洒农药,却没有说一定会洒在哪里,洒多少。
第一次看到db4o这个东西还是两年前,那时候只有Java版,现在已经发展到了V7,而且已经有了.net版,而且已经支持.net 3.5和linq。
简单来说,db4o是一个可以让你直接保存对象到硬盘的组件,任何对象都可以直接保存,以简单的方式查询调用,是一个用于替代数据库的组件。如果你的程序需要保存格式化的数据到单一位置,你不再需要定义数据库结构,写SQL语句,还得考虑程序迁移问题,有了db4o,一切变得更简单。
比如你定义一个Article类,然后ar=new Article();然后就可以db.Store(ar);直接把这个Article对象保存到硬盘上,下次要使用的时候,可以直接把这个对象Load起来,不需要数据库,不需要转换和映射,对于数据库管理类程序,节省至少一半的代码。
虽然在官方的文档里说db4o的插入和查询性能比一般的数据库更强大更高效,但是在我的实际使用中发现并不是这么回事,它的查询效率不高。(总共只有不到一万个Article对象,但是比较大,数据库体积200多M,查询一次远远达不到官方说的毫秒级,当然,按ID直接定位某个对象是很快的。)另外,它并不是启动和查询的时候把所有的对象放到内存里,而是只查询出符合条件的ID放入内存,实际使用这个对象的时候再去数据库里取,所以你要一直开着这个db,不能close它。总体来说,它并不是很适合用来在保存大量数据的情况下替代数据库。但是,如果用来替代保存程序配置信息,或者用于某些软件里面保存量不大的数据,(比如我写的博客备份软件,用来备份抓取下来的博客文章),那是相当合适的。
这个组件虽然下载的安装文件很大,但是在.net中实际需要引用的只有一个400多K的dll文件,你需要使用的函数只有十几个,而最常用的,只有四个。
但是,要注意的一点,它默认的使用方法是不支持多线程的,所以不适合用于并发环境下的WEB,而更适用于单人使用的客户端程序,把db声明为全局变量,在程序启动的时候打开数据库,程序关闭的时候关闭数据库,就OK了。当然,它也有并发模式,但是需要在一个独立的地方启动一个Server程序,定义一个IP和端口进行监听,其它的客户端使用TCP的方式连接到这个Server,就可以操作这个数据库,所以,它仍然不适于做WEB,因为虚拟主机是不能启动一个单独的程序的。
对于所有用.net写Windows客户端小程序,而且有些数据需要保存的,该组件属于强烈推荐级别。
BTW:它是免费的。
做完了校内的API版本以后,本想做海内和开心网的,找半天没有一点关于API的消息,似乎从来没有公布过一样。但是里面的那些应用又不像全部是公司开发的,难道属于内测阶段?
于是转去研究UCenter的API-Manyou。初看起来,Manyou的API完成度更高,文档也更细,而且已经有了MYQL和MYJS,比校内的更加成熟。结果,真正开发起来,才发现简直是场恶梦。
注册新程序的流程跟校内一样,但是少一个映射URL的选项,也就是说你的程序没有短路径。
API的函数和参数的说明都不少,但是偏偏没有如何调用。(有,但是是PHP版的,而且是PHP开发包的调用方法,如果你想自己做Post请求,Sorry,即找不到服务器地址,也找不到接收到的参数的说明。)
Python已经有了一个开发包,结果装上以后却说有一个函数未定义,启动不起来。
尝试了N多种方法,都没有办法成功的发送一个Post。
然后放弃了这种方法,只接收用户ID,不打算进行验证了。界面终于显示出来了。又发现其它页面的相对链接都不对了。又是一阵调试加猜测,总算找对了方法,把链接都改成相对于你的目录的链接,但是又不是相对链接,而是写绝对链接。
最后,看起来所有的页面都显示正确了,但是一个Form的Post又遇到了困难。我没办法让这个Form往正确的地址Post。换了多种方法,始终提示Bad Request。而且,Form里面被插入的隐藏变量居然跟Get的时候不一样,没有my_sig_uid字段……
算了,放弃了。浪费我一天的时间。
是时候研究一下国内的开放式API了,所以抽时间搞了一下,先从校内下手吧,相对来讲他的资料算是最多的了。但是即使如此,想从零开始写一个应用出来,还真是花了我不少功夫。资料实在是太难找了。校内的API从6、7月份就出来了,还弄了个专门的Wiki作为开放平台的门户,但是里面的资料出奇的少,除了对几个api函数的说明,对xnml的简单说明,其它的几乎为0。所谓的一个上手指南只讲了怎么注册用户和怎么注册程序,注册完以后的开放过程却一点也没提。想根据这份东西写个真正的应用出来,简直是不可能的任务。没办法,上Google,上社区,上应用的论坛,一篇篇帖子里找线索,最后总算是把一个应用给凑出来了。
如此糟糕的技术支持能力,直接决定了校内API应用的未来。
开发过程简介:
首先需要注册成校内用户,然后在自己的菜单上有个应用,添加一个“开发者”应用,这里面包括一个社区,一些开发所需要的链接。进入这个应用以后,可以看到一个申请开发许可证的按钮,点击就进入设置应用属性的环节,起名字,定URL之类的。(这一步在校内的Wiki上是有说明的。)有个安装到校内的选项,默认是否,结果选了以后我的应用就变成了外部应用,在校内只提供一个链接进入而已,这当然不行了。当我把应用删了重新添加的时候,原来使用的那个URL被占用了,无耐,换了个更难看的URL。应用还有一个重要的属性,就是运行状态,是以iframe形式还是xnml形式,这个待会再讲。第一次建议先选iframe形式,这个是随时可以修改的。
Continue reading »
下载:http://www.djangoproject.com/download/
如果你还在使用0.96及其以前的版本,务必先读一下不兼容列表:http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges


近期评论