月度归档:2006年12月

pylucene使用的问题

    早就开始关注pylucene了,不过直到最近才真正开始用到。pylucene毕竟不是原生的python程序,使用起来多多少少还是有些不太顺的地方。
    pylucene使用gcj进行不同平台间的移植。windows平台还好,直接使用官方的pylucene编译版本就好。可是linux平台没怎么好了。官方有提供几个常用linux的编译版本,如果没有官方的编译版本那可就得自己费点心编译了。
    同样是gcj的问题。pylucene的线程必须由主线程或PyLucene.PythonThread、PyLucene.PythonThread的子线程创建,不然gcj无法对新建线程进行垃圾回收。本想在django中控制,pylucene。但django似乎为每个请求新开线程,在处理请求的时候无法创建pylucene线程。因此pylucene创建索引的过程只好单独做为一个程序跑了。
   

热键助手-phoenix 1.0 正式版发布

    热键助手应当算是我整的最久的软件了。刚开始学delphi没多久的时候就开始整了。后来学习oop的时候又重新整了一遍,这就是现在的phoenix版了。因为是个试验田,里面的过渡设计过于严重,搞得现在我自己看起来都晕, 不过本来就不打算再怎么整了的。
    今天做了个安装包,也算是来个超度吧。做事总得有]始有终。
    如果感兴趣,可以在我的goolepage去下载。

互联网上曾出现过的机会

    今天在论坛上看到有人说,在今年的下半年,web2.0网站已经开始进入了衰退期了。无法考证该说法是否准确,不过有一点是可以确定的。互联网上的东西总是来得快去得也快。就如木子美,就如红衣主教,就如芙蓉姐姐(芙蓉姐姐已经算是红得长的了)。互联网上的机会亦是如此,今天来,明天走。 
    回顾,互联网的这十年,还是有过几次机会。一次浪潮,一次泡沫,一次寒冬。
    还记得刚接触电脑的那货,还的电脑杂志上看到教如何用telnet上bbs,教人如何玩“泥巴”。可到了我接触网络的时候却早已是web的天下。对于我们这些新接触网络的网民来说,telnet的bbs似乎只是个传说。
    2000年左右,我知道的第一次喧嚣,漫天的小网站。那时候的网站都在靠免费资源吸引用户。于是到处都是“免费”的身影。免费主页空间遍地都是。当时我也跟风,屁颠屁颠,用frontpage整了一个糟糕透顶的小网站。里面堆砌着一堆我从网上down下来的网页特效。
    没有良好的盈利模式,就如无根之水,毕竟无法长久。很快,互联网就赢来了她的第一个冬天。一些弱不禁风的小网站直接冻死在了这个冬天,大块头们也好不到哪去。有些卖了,有些则一蹶不振,苟延残喘的活着,比如etang(由于使用etang的邮箱所以有些关注,但她最近把邮箱业务给关了:))。当时这个冬天给我最大的感觉就是,免费主页空间怎么一夜间全没?去年还很多:)
    尽管惨烈,但不可否认的是,这是个机会。一些网站在熬过了这个寒冬后,终于等到了春天。不少个人网站都已经长大,在网上占得了一席之地,如现在“驱动之家”。曾经面临摘牌的网易,也成功的让老总丁雷坐上了中国首富(当然,现在不是他了)的宝座。sina、sohu也各有各的道,过得有滋有味。
    不知道这样的互联网冬天是否还会再来,但传统网站的机会似乎永远都不再来。该蹲的坑都有人蹲了。
    周奕,圈外听过他的名字的人应该不多,但在圈内,他的名字绝对如雷贯耳。甚至可以认为,中国共享软件的繁荣很大程度上要归功于他。在当时知道共享软件的人应当不少,但做共享软件是否赚钱,如何才能赚钱却是很多人不知道的。周奕,他做了,并且做得很成功。一系列走向海外的文章,点燃了不少国内软件作者的信心,同时也让国内的软件作者知道,原来共享应该这样做。
    我知道共享软件这回事的时候已经到2002年了。那时的共享软件应当已经开始进入衰退期了。csdn的海版已经开始没落,大量高水平的共享软件作者都已经改混xx论坛了。俺乘着xx论坛关闭注册前,成功的混迹进去了:)。虽咋做共享依旧不会,却对共享软件产业的变迁,有了些了解。随着共享软件产业的发展,市场的成熟。一些领域已经出现了垄断性的软件,对新出现的软件呈压倒性优势。市场消失。而且新加入圈子的人数远远大于市场的增长速度。竞争变得异常激烈。软件的开发/推广投入大大增加,而汇报率却难以达到预期。于是亏损现象也并不少见。
    那个共享软件论坛有一段时间没去过,后来再去的时候发现网站找不到了。也不知道换域名了,还是已经关闭了。
    在我看来,这个世界变了,共享软件的浪潮似乎永远不可能再现了。现在是网络的天下,软件更多是已经变成从属的地位了。以前的软件是用来卖前的,现在的软件是削尖了脑袋往用户电脑里钻:)。
    网游,这东东曾让盛大红极一时。不过网游产业在过渡炒做后,已经过早的衰退了。而且开发网游,需要大量高水平的美工/程序员,而且还得投入运营费用。投入太大,周期太长,我觉得,不是很适合投机,哈哈。
    web2.0,现在正在经历着的。
    还记得在几年前第一次出现了blog这词,当时也热炒了一阵子。无奈当时国内的网络环境还并不成熟。炒过后还是该做啥做啥。却不想,忽然间,全民皆bloger。blog的兴起,似乎标志这web2.0时机的成熟。一时间,ajax,web2.0满天飞。一下子出现了好多打着web2.0旗号的网站。
    web2.0,啥是web2.0?似乎对很多人来说啥是web2.0并不重要,重要的只是web2.0这个词,一个良好的炒做契机。
    也许web2.0过于喧嚣,但我依旧认为这将是个机会。web2.0,是一场草根的革命。web2.0就是全民参与,让每个人都有展现自己的机会(就这一点,我觉得超女很2.0)。web2.0是个新的切入点。寻找着传统web所留下的长尾。
    web2.0,草根的革命。让草根们可以用最低的成本展现自己,也为草根们提供了最低的创业成本。
    在web2.0的衰退期,你为何不尝试这抓住这个2.0的尾巴?而我,是否也可以尝试2.0一把?

ps:
    喧嚣的互联网。早就想写些有关于web2.0的思考。却都在提笔后发现无法下笔。呵,思绪实在是太乱了。如果哪天心情好,条理清楚的时候可以考虑写写。

浅谈wiki的设计

    虽然网上现成的wiki一大票,不过对需要进行定制开发的时候这些wiki就未必适合了。由于只是想整个最基本的wiki功能,因此打算自己整一整。 也许是有些厌倦了java,也许是想更深入的体会一下脚本语言的魅力,我决定采用django来进行开发。而且使用django有个好处,支持python的虚拟主机比支持java的好找。
    虽然是重新开始整,但如果有现成的轮子当然是最好了。既然决定使用django,当然要到django的code目录去找找。diamanda,一个论坛+wiki的程序。功能很简单,但作为一个轮子还是一个不错的选择。wiki最大的特色就是版本控制,因此我对wiki的版本控制算法比较关心。看了一下版本控制部分,居然是每个版本都全部保存(我一直认为wiki应当是增量保存的)。这意味着即使是一个很小的改动也得重新保存一份。对于一篇很长的文章来说,冗余实在是大得惊人。想来也许是这个程序的问题,于是考虑去找些其他的wiki程序作为参考。除去django的项目,其他的python wiki项目也不错。反正算法什么的都可以直接用。(中途还down了个java的wiki,不过没耐心看)
    又去溜达了一圈,看中了moin,python里最知名的wiki项目之一。不熟悉moin的web处理模型,看得我似懂非懂。不过基本上可以确定,他也是每个版本保存一份。
    最后想想还是去看看mediawiki吧,世界上最大的wiki“基维”用的就是他。有些晕,这个也是使用全部保存的方式。想来“基维”有好几百w的数据,加上每条纪录都有多个版本,“基维”的数据库压力定是N大。不过到此我也不用去想搞啥增量算法了。众多wiki程序都是使用的全部保存模式,定是有些道理。增量算法即使有,也必定会有不少难点有待解决。
    下面看看mediawikiwiki的设计吧。
    mediawiki使用数据库来存储wiki数据。一张page信息表用于保存每个wiki页面的信息。可能是考虑到性能问题,真正的页面内容却没有保存在该表中,而是单独保存在text表中。表里的数据都是以blod方式保存,为什么这样做俺就不太清楚了,难道是效率更高?只有最新版本的数据才是需要索引的数据,因此单独出一张索引表,用来进行索引查询。文本内容在被索引前实现要进行一次过滤,过滤掉wiki标签等。
    由于加入了版本控制,数据库中数据表中的纪录数将是实际主题的好几倍。而且随着wiki内容的丰富和完善,数据库中纪录大小将迅速膨胀。数据库的压力不言而喻。
    为了减轻数据库的压力,有些wiki选用使用了更高效的办法,使用文件的形式存储wiki内容。其中moin就是这样做的。moin使用一定的规则将wiki纪录以文件的形式保存,并使用lupy(1)对文件进行索引,提供查询的支持。
    为了减少每个版本都全部保存一遍所带来的巨大冗余,不少wiki都支持分段编辑。即可以对每段进行单独的编辑,在保存的时候只保存做修改那部分的内容。

(1)lupy 一个lucene的python移植版。与pylucene使用gcj移植不同的是,lupy完全使用python对lucene改写。lupy的问题是支持lucene版本比较低,只支持到1.2。