lzpian.com还有一个多月就到期了。因为这个站点不打算再进行维护，所以也懒得去给域名续费了。为了防止域名到期后无法访问，今天为老照片新增加了一个二级域名 http://lzpian.haoluobo.com/ ，并将lzpian.com重新重定向到新域名上。
不过在进行重定向的时候遇到些问题，那些设置了跳过规则的文件都重定向到 lzpian.com 去了。整了半天也没明白是咋回事。估计和虚拟主机的设置有关。考虑过些天等lzpian快到期的时候将lzpian.com去掉看看。
前一段时间在邮件列表和limodou讨论django app重用的问题。limodou认为django的app没有对app的配置文件和静态文件的管理提出一个很好的方案。但在我看来在这方面django做的已经算是不错的了，唯一缺少或许只是一个规范而已。对于django，每个人都有各自的认识，而且在书写的时候又很少考虑到重用的问题，所以写出的代码各不相同，重用性很低，完全没有发挥出django app的优势。
DjangoSide是个演示性质的项目。主要演示如何和第三方的django应用进行整合，简单的注册登陆的实现，以及静态资源的组织等。目前项目还只是将基础的框架目录结构给搭建好了，里面提供了一个blog的整合实例。主工程（djangoside）还未正式的开始开发（其实也没多少需要开发的东西）。
至于项目的详细可以在项目页面看到，我这里就不多写了。
项目地址：http://code.google.com/p/djangoside/
assembla是一个提供免费SVN和项目管理工具的服务商。以前用过一段时间，后来挺久没去过，最近再去发现服务功能做了一些改动，其中wiki的改动实在让人无语。以前的wiki使用的wiki语法，但现在已经改成了同时支持wiki语法和WYSIWYG。就这么看上去似乎还是不错，但真正去用就会发现根本无法忍受。WYSIWYG和wiki语法之间根本就无法平滑的切换，而且在提交后文本内容就已经转成了html，根本无法再使用wiki语法进行编辑。简单的说，assembla的wiki功能基本上是废掉了。
虽然wiki被废掉，这点比较不爽，不过今天发现assembla居然提供了Trac，一个完整的Trac。Trac的wiki功能完善（而且我自己也在用Trac的wiki）。不过assembla的数据导出服务似乎是收费的，而且我已经在自己服务器上将Trac的部署好了，因此目前只使用assembla的SVN服务。
需要项目管理，SVN服务器的兄弟去看看吧，绝对是一个优秀的免费服务。
本以为wiki不被收录是因为进了搜索引擎的黑名单，于是换了新域名，哪知道还是老样子。google虽然有收录，但权重N低，baidu始终不做理会。为了防止trac自带的wiki页面导致搜索引擎错误的将我打入黑名单，我还特意在robots里将这些页面做了屏蔽。
我看了下其他的trac站点，似乎也都不太被搜索引擎待见。可能是trac自身的问题吧。
不去管它好了。
wiki地址：http://vik.haoluobo.com/
本来计划先将wiki的内容整理完再部署到服务器上，可是因为一些以外，wiki整理的速度变慢了很多。于是就先将已经整理的部分部署上去。部署wiki的时候顺便也将“老照片”和“国学阅读网”不能访问的问题给修复了。由于bluehost的调整，网站已经挂了好些天了，只是一直都懒得去整。
最近真是多事之秋。汶川的大地震近年来少有的大灾难，而我也遭遇了有史以来最严重的伤害，肉体上的伤害。新买了自行车没多久就将我摔了。虽然没有啥大伤害，可是身上有多处擦伤。而且现在“年纪一大把”，伤口恢复的速度远比不上从前。
受了伤，一面有些郁闷，一面也会有些胡思乱想。按说每次以外都是小概率事件，是N多细节的累加。如果我当初决定走另外一条路，如果我决定早点回去了，甚至路上多一个坑。很可能我就不会被那个倒霉的缝被绊倒了。只是，如果就是没有如果。不管怎么样，这件事已经发生了，这已经成了一个无法改变的事实。再说来，通常人们说的如果都是好的方面。谁知道如果真的如果了，又是否会和《蝴蝶效应》中的故事一样。
也许这次的意外也会有些好处了。因为我还有机会回头，在一定程度上说可以回头的意外都不算太糟糕。
受伤后为了能早点恢复，我的生活习惯已经好了不少了。以前经常有事没事的熬夜，现在时间差不多就睡了。早上通常匆匆忙忙的随便吃点东西，就去公司。现在也会早点起床，到公司后慢慢的吃早餐。会注意营养多吃鸡蛋。因为忌口，我放过了美味的鸡翅而选择番茄炒蛋:(。
伤口在基本愈合后应当还会有个调养期。为了不留下太明显的痕迹，我想我应当会去做些运动。
如果这次的伤害没有留下啥太严重的后果，而我能借次机会培养一个健康的生活习惯，那还是不错的。但现在，确实很郁闷，每天都在想啥时候能快点好:(。
前些天发现有些通过网友搜素Borland卖Delphi的访问我的主页。然后又在QQ群里看到了CodeGear出售的消息。CodeGear以2300w$的价格给贱卖了。Borland还保留700w$的资产，也就是说整个开发部门总共也才值3kw$。
买家叫Embarcadero，一个我没听说过的公司。虽然是个地板价，不过我想这对Borland来说也算是一个解脱吧，终于将这个烫手山芋给脱手了。
Delphi社区普遍关心CodeGear被卖了以后Delphi的前途，毕竟Delphi就borland一家在做，如果没人接手玩下去，那将直接面临玩完的危险。从我的角度来说，我是非常不看好Delphi的前途（其实早就不看好了），也不看好CodeGear的前途。CodeGear这几年出的新东西，甚至连让我尝试的冲动都没多少。
2300w，本来就是一个地板价，更何况这还并不是Delphi卖出的价钱。说不定Delphi在里面属于陪嫁的嫁妆而已。Embarcadero或许只是看重了CodeGear的技术团队。作为一次收购，Embarcadero很可能会对CodeGear的产品线进行重组，砍掉一些不盈利的项目。Delphi就很可能会在黑名单中。
食之无味弃之可惜。在我看来Delphi应当还会做做show，做一些维护性的工作，就别指望他能得到一些啥优秀资源了。
或许对我来说，Delphi的版本号发展到了7就已经终结，虽然对他的unicode版还有些许期待。
前些天用了一下好看簿，感觉还不错。加上pconline越来越不好玩，决定给相册搬家了。
以前用pconline的摄影部落主要是这里有不少摄友，感觉在部落里YY片片还挺有意思。不过可能是pconline处于流量的考虑，添加了在回复时候推荐自己最新照片的功能。而且照片的出现顺序也开始改为按照最新评论时间进行排序。一些摄友为了推销自己的摄影作品，到处回复。这样做网站的活跃度是上去了，可是评论的质量却大大的降低了。不少人是为了回复而回复。
pconline的相册不支持外联，虽然这个东西对我的影响不是太大，不过如果有个好用且支持外联的相册那不是更好。
当然用好看簿也是有一定风险的。就我的感受，好看簿还未真正形成自己的竞争优势。如果哪天好看簿不玩了，那我就得另外去找一个窝了。
我的好看簿地址：http://vicalloy.haokanbu.com
既然在线程内调用pylucene会有问题，于是我将pylucene做成了一个独立的程序，将执行结果pickle后输出到控制库。主程序在遇到查询请求的时候执行这个独立程序，获取控制台输出后再unpickle获取查询结果。
本以为这将是一个可行的方案，哪知道部署到服务器上还是不行。
真的败给pylucene了，暂时是不想再被pylucene折磨了，以后有时间还是看看Xapian吧。
lucene简单易用，而且默认的中文分词也还凑合。
本来用lucene做django的全文搜索引擎应当会是个不错的选择。
不过看似乎没看到什么项目这么做，在django的世界里似乎xapian更流行些。
做过了才知道，不是没人用，而是pylucene这东西根本就没法用:(。
今天花了一晚上将pylucene的全文搜素给做完，用django自带的测试服务器测试也没啥问题。
部署到服务器上就挂了。
本还以为服务器上的部署问题。
些了个简单的测试程序到服务器上又测试了一遍。
测试程序OK。
但django还是死活跑不了。
然后想起pylucene那个比较BT的问题。
pylucene由于是CGJ编译的，为了支持垃圾回收，如果在线程中使用pylucene需要继承PyLucene.PythonThread。
到网上找了下，还真是这个问题。
据说
"import PyLucene.PythonThread as thread" in django/utils/autoreload.py
对django做这样一个修改就可以正常工作了，不过mod_python下还是无法正常使用。
我用的是fastcgi，不过修改够还是无法正常工作:(。
各位打pyluence主意的朋友们以后得主意了，pylucene这东西有时候真的不是太好玩:(。
pylucene除了gcj版本外还一个jcc版本，这个版本是用c++对java进行wrap。
应当不会有类似gcj版本的问题，但你必须安装个java。
参考资料：
PyLucene JCC vs GCJ
http://ubuntuforums.org/showthread.php?t=593327
Python可以使用的全文检索方案还是有几个的，其中比较流行的有Xapian（豆瓣在用）和Pylucene。
但对于中文而言，除全文索引引擎外，中分分词也是个麻烦事。Pylucene移植自lucene，因此很自然的支持中文分词。Xapian就没这么幸运了。虽然也有些简单的方法让Xapian支持中文分词，但效果也都好不到哪去。经过斟酌之后最后还是确定使用PyLucene。
以前在Linux下安装软件基本上都是apt-get。不过共享主机就没这么方便了。在pylucene的网站上找了半天也没找到可以匹配的二进制包，于是决定手动编译pylucene。
去看了下编译说明，似乎还比较简单，只要简单的修改Makefile就可以。可以是有个比较大的问题，服务器上没有gcj，还得先安装个gcj。
去down了个pylucene推荐版本gcc进行编译。被那个host参数整了半天（设置得不对），后来去掉–host后将gcc编译成功。编译费时1小时？
Pylucene的编译倒挺快，不过目录结构和Makefile中定义的目录结构似乎有些不太一样。手动将相关文件复制到对应目录后运行sample，查看运行结果。
IndexFiles.py ./ 可以看到成功索引了一个文件PlainText.txt
SearchFiles.py 输入查询条件Plain，可以看到成功的查询出了一条记录
到这里pylucene就已经可以正常工作了，过些天等有空就去将国学阅读网的全文索引给做。