发布-唐诗300首（Yahoo Widget）

发表评论
    唐诗300首的软件我可不只做过一个。在刚学delphi的时候处于学习的目的做过诗词软件。后来对delphi熟悉些后，又重新整过一个。不过以前的这些都和网上的大同小异，没有多少特色。
    最近忽然对国学/文学又多少有了些兴趣，只是在这浮躁的世界里实在太难静下心来。还是唐诗好，简单却精巧。做个widget放在桌面上，不但可以充充门面，每天看一首，调节一下心情也还挺不错的。
    这个widget花费的时间比我预期的要多不少。本以为需求简单，加上已经有过做Yahoo Widget的经验，应当三下两下就搞定了，却不想还是挺化时间的。现在还在是完成了α版本，还有些细节需要处理。
    这个widget里面用了不少Slickies.widget（一个桌面便条）的代码和资源，没有通知作者是不是有些不道德。不过这次没太盗Yahoo自己的资源文件。考虑将细节处理一下就到Yahoo去申请发布。
 
更新说明（2007-03-04 21:43）：
    做了些小修改，加了个帮助窗口。已经到Yahoo去申请发布了，不知能否通过。

发布-支持农历的Yahoo Widget

发表评论

Yahoo的widget确实很不错，放在桌面上十分漂亮，而且还有不少实用的功能（虽然我主要是为了美观）。快到春节了，本想找个支持农历的widget看看什么时候过年。在Yahoo数以千计的widget中居然没有一个支持农历的日历。于是就将yahoo自带的日历widget给整了整，加上了对农历的支持。
Yahoo的widget是以bsd协议发布的，这意味着你可以随意的修改widget的代码。可是widget的资源文件（图片等）却是有限制的，因此我的这个widget是注定见不得光的（资源文件全是yahoo自带的）。
如果有需要就到我的googlepage去下载吧。

PS：
googlepage在挂了多日后，今天终于又活了。

老鼠火星历险记

发表评论
    今天在豆瓣的首页上，无意中看到了这张PP。虽无太多的记忆，但我却清楚的记得我看过这个动画片。一只傻傻的老鼠，他在那里做什么？ 
    莫名的有些感伤。似水流年。有些东西不断的远去，远得只剩下符号，印在回忆里。这只老鼠，也似乎也成了记忆里的那个符号，成了曾经的过往。
    又想起 了另一个动画片，《等着瞧》。兔子/大灰狼版的猫和老鼠。在很长一段时间里我甚至怀疑自己是否真的有看过这么一部动画片。

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版嘛）。这样都要翻译，看来我是否要加个多国语言支持了啊，。
    虽然有些意外，但还是挺高兴的，有人关注总归是好事。