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。

面壁去

    最近研究Django,想实现在数据库翻页的功能。找了半天也没找到相关资料。网上的代码也都是在Django中分页。无奈之下发现Django上居然放了个irc的连接。赶紧去下了firefox的irc插件,杀进入。
    irc里人还不少,而且马上就有人回复了(这么专业迅速的回复,难道是Django的开发人员?)。可惜我的半吊子的E文,没太看懂对方的回答,还以为是对方没听懂我的意思。同一个问题换了几中种说法说了好几次。严重怀疑对方在郁闷,怎么会有这么不可理喻的家伙
    太丢人了,以后还真有些不好意思再用这个id进Django的irc了。
    回头又看了一下老外的回话。老外的意思是。Django在内部就已经有进行优化,判断是否需要lazy,并不会将所有数据都取出来。
    根据老外的指示,又去仔细翻看了一下Django数据库API的相关文档。文档里对这有明确的说明。
    Django确实是不错的东西,省心。

    面壁去,今天太丢人了。

CrystalCursor更新到0.2.1Alpha

    今天对CrystalCursor进行了一次小改动。将MouseHook里多余的引用单元去处,将编译出来的文件大小由88K减少到43.5K。修改主程序的Hook机制,去除MouseHook.Dll的引用(MouseHook这个辅助工程以后就不需要了)。
    现在的代码中用的是观察者模式通知各个子窗口鼠标位置的改变。但在今天察看代码的时候发现这个机制实在是多余。对于各个子窗口而言,他们根本不需要知道鼠标位置是否改变,他们要的只是能取到当前鼠标的位置。既然是这样,这个观察者模式还有什么用?为什么不直接去取?想了好久也没想明白当初是怎么设计的。看来这又是一个失败的设计
    这次更新改修正了在开启效果后会在资源管理器中现实多个窗口的问题。

PS:
    在程序发布后没多久,打开MSN(我习惯从MSN进BLOG)发现有封新邮件。是E文邮件,还夹杂着乱码。仔细一看,是请求翻译成土耳其语的permission。
    翻译?我仔细检查后,确信我的软件里只有4个E文单词,而软件介绍信息也就一句话(毕竟是Alpha版嘛)。这样都要翻译,看来我是否要加个多国语言支持了啊,
    虽然有些意外,但还是挺高兴的,有人关注总归是好事。

流氓软件探源

    在以前,软件开发者门都在想如何用软件多卖一些钱。然而这个世界忽然间就变了,很多软件都开始免费了。免费也就算了,各种各样的软件削尖了脑袋的往用户电脑里钻。更有甚者,一但进去了就占地为王,死都不出去。
    不是我不懂,只是这世界变化得太快。
    开始慢慢的回忆软件是什么时候开始流氓起来的。
    想到流氓软件,很自然的就会想到3721,对很多人来说,电脑被流氓都是从3721开始的。在几年前3721和总多小网站合作,推出了用户安装3721插件,网站就可以得到提成的推广机制。流氓归流氓,3721依靠该策略迅速的普及了起来。此后就慢慢的迎来了现在的流氓狂潮。
    虽然是3721使流氓软件的概念深入人心,但3721绝对不第一个流氓。翻看软件史,我们看到了sun。在90年代sun推出了java。一时间java风光无限(java现在也还不错了)。俺们的bill大叔当然不能看着sun在那里独美了。本着做不掉他就搞和平演变的原则,bill大叔偷偷的修改了java的规范。sun也不是惹的,一场官司,bill大叔的计划失败了。bill大叔一气之下将jre赶出了windows。sun一见茅坑没了,赶紧打官司,企图重新夺回茅坑。官司赢了,但我们的bill大叔就是牛。就是赔钱也要坚决抵制sun的无耻流氓行径。于是到现在我们都需要单独去下载jre。
    虽然MS拒绝了sun的流氓行为,但MS自己也流氓过。
    在90年代中期的浏览器大站中,MS靠在自己系统中捆绑ie来和netcaptor抢地盘。netcaptor眼见就要体力不支了,赶紧跳出来大叫一声:“你流氓”。又见官司。MS坚决不卸,说这是系统的一部分。netcaptor无奈只下只得自己出工具卸ie(现在的反流氓软件软件?)。此后,此后大家就都知道了。现在还有几个人知道netcaptor?现在的ie也被真真正正的整合到了系统中。

《戏说乾隆之江南除霸》全台词(PDF)

2022年1月13日更新:已经过去了很多年,还是不时会有人通过戏说乾隆的关键词找到这个页面,只是这里的链接早就失效了。今天把文件重新上传了,大家可以在这里下载。

《戏说乾隆之江南除霸》全台词.pdf


    《戏说乾隆》很喜欢的一部电视剧。 喜欢这么一个相忘于江湖的故事。也许这世间没有永恒,所以需要靠遗憾来作为永恒的牵挂。

    里面的台词写得很考究,有些古味却不做作。曾找过这部戏的台词,未果,于是还对着电脑,手动抄录过部分台词。最近在网上看到了第一部的全台词,是一个叫玉尘的网友做的(不知道还会不会出下两部的)。我将他写的台词整理了一下做了个PDF版本的。大家可以到我的googlePage里去下载。 随便贴点我喜欢的。第一部,第二部的都贴点。不三宿桑下这一段。第三部还是算了,我没看全过。我不太喜欢第三部,但这部戏正是有了第三部才算完整。

//---------------第一部_江南除霸---------------//
  程淮秀:“唉!啊!四爷。”
  四爷:“呵呵呵…”
  程淮秀:“何苦再来找我呢?”
  四爷:“春喜这丫头,果然探出你在这儿!一个人来,是躲着我吗?”
  程淮秀:“哦,躲我自己。”
  四爷:“来这儿做些什么呢?”
  程淮秀:“可以坐,可以想,可以跟自己相对。”
  四爷:“旱湖之约,新的感触?”
  程淮秀:“呃呵,因果倒也不止一端!”
  四爷:“淮秀,你后悔吗?”
  程淮秀:“不后悔!”
  四爷:“喜欢吗?”
  程淮秀:“不喜欢!”
  四爷:“你是……”
  程淮秀:“不想再提了!”
  四爷:“我们…再去…也许…可以透彻的谈一谈。”
  程淮秀:“佛祖在传道的时候,曾经不三宿桑下。”
  四爷:“不三宿桑下!不三宿桑下!他是佛祖!他传佛啊!”
  程淮秀:“我传盐!”
  程淮秀:“我发过重誓身献盐帮。富贵贫贱,危难生死不离盐帮。”
  四爷:“唉,但是你从来没有说过一生不嫁人哪!”
  程淮秀:“大家跟着我,我跟着大家!兄弟之情,犹如咸盐,烈日之下晒出来,煎熬之中煮出来!嫁不嫁人并不重要。”
  四爷:“你是把我当做外人?!其实不外,我是不好说,如果你知道我姓什么,叫什么,做什么,人家称呼我什么…”
  程淮秀:“四爷,不说也罢!在旱湖,我曾经想问过,眼前这个四爷,他叫什么呢?岔过去,现在你不说,我就连是不是桑树我都不知道,这不更好吗?”
  四爷:“你是帮主,不是尼姑啊!”
  程淮秀:“入帮,出家,要的是一种心境。”
  四爷:“你在江南,我在塞北,我很在意!我们能够在小狼沟无意中结缘,今天又能够在这相遇,说是缘并不错,况且你刚才也说过,因果不止一端!也许是前世的因,今世的果啊!”
  程淮秀:“四爷,在旱湖,我们没有酒,但是我们连翻的酒话,这古刹是我清修的地方,我们又续起前缘来了。海阔纵鱼跃,天空任鸟飞。四爷,您是个潇洒的人…”
  四爷:潇洒的人?千万百计地要见你,想做件不潇洒的事,我要将我母亲传给我的一样东西,转送给你。淮秀,惊扰之处,你能海涵。我走了!”

//---------------第二部_西滇风云---------------//
  四爷:“你不想说的事,说说看!”
  沈芳:“我不想说的事?什么啊?”
  四爷:“在房里你说,你是人,是女人,情,你想过。”
  沈芳:“呃…呵”
  沈芳:“太监到我们家宣召赐死,我看见的不光是冤屈,愤恨跟生离死别,我看见了我的父母,他们夫妻之间最深沉,最痛彻肺腑的不舍。我父母,十来岁就结为夫妇,几十年肩叠情深,在面临死别的时候,没有一句话,也没有动作。你,偶尔看我一眼,我,偶尔看你一眼。眼泪算什么!他们夫妻心里暗暗淌得,是血,是情血。第二天,我母亲去世了,跟着父亲走了。不过我想,母亲是很平静,是满怀希望走的。”
  四爷:“希望?”
  沈芳:“嗯!希望在另一个天地里,与他的丈夫相遇,重续旧缘,重温旧情。从那个时候起,我才知道,这世间伤人最深最重的竟然是情缘!我是人,是女人,我想过情。可是我怕,我两次躲你,都因为我怕。”
  四爷:“我懂!”
  沈芳:“佛陀传教的时候,不在同一棵桑树底下连宿三次。”
  四爷:“不三宿桑下!”
  沈芳:“对,不三宿桑下!佛陀尚且怕情缘,人能不怕吗?”
  四爷:“人…恐怕,谁也没有那个定性,那个慧根,永绝情缘。有缘则遇,有情则聚,生死别离,也许是小事。”
  沈芳:“哦!”
  四爷:“佛教有个故事说,人去喂鸟,那只鸟永远吃不饱吃不够,后来喂鸟的人把自己的身躯也喂给了鸟吃。情缘是鸟,人喂它,是不计其它的,甚至身躯性命。”

crystal-cursor更新了

    在SF上建立项目后我自己都很怀疑是否会对该项目进行更新。最近有些闲,于是对crystal-cursor进行了第一次更新,对项目进行了少量的完善,并增加了一个新的效果。我给这个新的鼠标效果取了个中文名字“绚彩萤火”。
    在程序修改后,打算将代码更新到SF的CVS上,却一直timeout。开始以为是代理的原因,于是花了一堆的时间学习如何给CVS设置代理。在设置代理后问题依旧。无奈之下重新看了一遍SF上的CVS使用说明,发现CVS服务器地址已经变了。想起前些天SF发的通知邮件,于是再去翻阅了一下,里面说的正是此事。在更新代码后本想发布个新版本,文件发布系统又有问题了,找了半天没找到incoming文件夹。难道是我RPWT?不知道还有没有那位兄台在用SF的管理平台,得咨询一下。

    在对crystal-cursor进行修改的时候遇到了一些问题。首先就是delphi的接口。虽说delphi中的接口是自行管理对象的生命周期,但在有些情况下似乎并不是那么灵光。在crystal-cursor中我采用观察者模式来将鼠标位置的变化情况通知各个子窗口。理论上只要我将子窗口从观察者列表中移除,窗口就该释放,但事实并不是如此。关于这个问题,在网上有见到相关的介绍《接口小论》

    为了让子窗口交替出现,我需要让一个子窗口建立后先sleep在进行下一个窗口的创建,但sleep会导致主线程的阻塞,无法达到预期效果。于是我增加了一个NoBreakSleep函数。这个函数虽然简单,但效果似乎还不算太烂

procedure NoBreakSleep(aInterval: Integer);
var
  StartTime: TDateTime;
begin
  StartTime := Now;
  while ((now-StartTime)*24.0*60.0*60.0*1000.0) < aInterval do
  begin
    Sleep(1);
    Application.ProcessMessages;
  end;
end;

 

PS:

    发现真是自己的RPWT。刚才一直都是用WinSCP登陆。用WinSCP登陆是更新web站点用的。发布文件直接用FTP上去就可以了。真是太大意了。

    发布文件已经更新上去了,大家可以到我的项目站点去看看crystal-cursor

JForum开发框架介绍

前言
    一直很懒,很少写些技术相关的东西。难得因为工作的需要有写些,帖上来吧。其实我对JForum也没太认真的研究过,所以如果里面有些什么不对的地方还请大家指出来。
 
JForum开发框架介绍
    JForum是著名的开源论坛,支持多达数十种的多国语言,其中包括简体中文(管理界面没有完全汉化)。JForum功能强大,界面美观,加上代码结构清晰,而且采用的是BSD授权,不必担心不必要的版权纠纷。可以说JForum是论坛二次开发的绝佳选择
    JForum采用的是自己的MVC框架,因此在初次接触的时候可能会有些不习惯,但在熟悉后,该框架还是很容易使用的。在这里只是对JForum的框架进行简单的介绍以利于利用JForum进行二次开发,具体的细节请参考JForum代码。
    JForum的MVC框架有些类似Struts。
    先看请求的url地址/bbs/jforum.page?module=recentTopics&action=topRep_Topics_thisDay。
    首先在在web.xml中配置过滤器,将所有以.page的请求交给net.jforum.JForum统一处理转发。请求在交给JForum后,JForum要获取传递过来的一些参数从而决定由哪个模块来具体处理请求。参数module,决定由哪个模块来处理。model的名字和具体class的对应关心在配置文件modulesMapping.properties里进行配置。当前操作由具体的哪个函数处理由action参数指定。action就是要执行的方法名,在无法找到指定处理方法时执行list方法。在处理完请求后,调用this.setTemplateName(TemplateKeys.SSOEXT_TOPREPMSGS_PERDAY);方法设置返回页面。其中页面和页面名称的对应关系在templatesMapping.properties中设定。
    再简单的介绍一下JForum新增功能的开发流程。新建一个Action继承Command。在配置文件中modulesMapping.properties中增加新建立Action的对应关系。实现Command中定义的list方法,完成在未指定action情况下的默认操作。在templatesMapping.properties中增加返回页面的对应关系,在类TemplateKeys里增加返回页面和templatesMapping.properties配置文件里的对应关系。利用this.setTemplateName(TemplateKeys.RECENT_LIST);设置返回页面。
    JForum默认采用的是FreeMarker作为表示层,但如果对FreeMarker不熟也可以采用jsp做为表示层的实现。