我的黑莓8320最近频频罢工。虽然已开始有些习惯了黑莓，但这个手机用了不到一年就这这样，实在是有些失望。
在E72和E63间纠结了一整后最终选择了E63。
今天，新机到手的第二天，用官方的PC套件对系统进行了一次升级。升级好后系统语言变成E文和另一不知道是哪的蝌蚪文，中文则彻底成了框框。这时候我才反应过来，这就是传说中的刷机，由于我的机器区域码为某小国，系统没带中文。新到手的机器，还没来得及把玩就挂了，实在是让人崩溃。
迫不得已到网上寻找解决办法。
网上有使用“凤凰”刷机的方法。虽然凤凰的个头不小，而且过程繁琐，但为了解救我的E63只好尝试。然后失败。
经过再次搜索后终于找到了个简单的解决方法。使用NSS将E63的code改成新加坡，然后用官方PC套件进行更新。
具体使用方法参考下面的链接：
NSS无法改CODE的的究极秘籍 http://bbs.dospy.com/thread-5547565-1-1.html
貌似最全的E63 code号 http://bbs.dospy.com/thread-3002663-1-1.html
LBForum 用django开发的论坛系统，演示地址为：http://vik.haoluobo.com/lbforum/
项目的地址为：http://github.com/vicalloy/LBForum
界面部分抄的 FluxBB(一个开源的PHP论坛 http://fluxbb.org/ )。
虽然Django写的论坛也不少，不过还真没什么好用的。
大多Django论坛都是独立的app，而且不少还缺模板，想我这样有经验的Django用户要跑起来都觉得麻烦，其他普通用户就更别说了。
LBForum主要注重部署的方便性和易用性，功能方面目前还比较简单。
LBForum一开始就是以整站的形式提供，所以以LBForum做为基础项目进行二次开发是很容易的。
同时LBForum的开发尽量遵照Django可复用app原则，因此即使需要将LBForum做为独立的app集成到其他项目也并不会太难。
目前功能还比较简单，而且还有些小问题有待修正。
|+lbforum_env/#lbforum运行的python虚拟环境，运行create_lbforum_env.py后自动创建
|+requirements/#lbforum用的第三方库和app，运行的时候会将该目录加到python路径
|~scripts/#工程相关脚本
| |-create_lbforum_env.py#初始化python虚拟环境，并自动安装easy_install/django依赖库
| |-helper.py#提供其他脚本所需的辅助函数
| `-lbforum_env.bat*#启动lbforum运行的虚拟环境及，并为lbforum的manage.py提供快捷方式%mg%，比如初始化数据库%mg%
syncdb
|~sites/#站点配置/模板/静态文件
| `~default/#默认站点
| |+static/#静态资源文件，如css等
| |+templates/#Django模板目录
| |+templates_plus/#Django模板目录，用户将自己重写过的目标放到该目录
| `-……
|~src/#django的app目录
| |+account/#account相关app。具体站点通常会对用户中心进行定制，所以该app在实际应用中很可能需要针对实际情况进行修改。
| |+djangohelper/#一些django的辅助函数等，
| |+lbforum/#lbforum的主app，论坛功能都在改app中
| |+lbregistration/#registration app的lbforum扩展，主要去掉邮件地址认证功能
| |+onlineuser/#显示在线用户的app（可复用的django app，可脱离lbforum单独使用）
| `+simpleavatar/#头像功能的app（可复用的django app，可脱离lbforum单独使用，依赖djangohelper）
|+tools/#工程用到的辅助工具，目前只有一个virtualenv的脚本
pycon2010上关于SF网站重构的演讲，里面介绍了SF重构的技术选型及原因。在我看来SF用的东西还真的很GEEK。
主要用到的技术有Python、TurboGears2、MongoDB、Jinja*、RabbitMQ，服务器用的是LigHTTPd和Nginx。
早些时候就在google到Whoosh和xapian的性能对比文章，只是由于文章被墙，今天才翻墙看到。
文章是xapian作者写的。就文章里的对比结果来看，whoosh和xapian的性能差距还是比较明显。索引和搜索的速度有近4倍的差距，在full cache情况下的性能差距更是达到了60倍。
除算法原因外，whoosh的纯python定位也决定了whoosh很难达到其他c/java的搜索引擎库的速度。
当然，whoosh的优势是易用性，在考虑性能的情况下whoosh不是首先。
注：Xapian performance comparision with Whoosh
JDK6已经内置了webservice支持，使用JDK6开发webservice是一件很方便的事。很不幸的是，由于IDE的支持axis成为使用最广的java webservice库。而且由于的部分应用使用了不兼容的RPC/encoded模式，使得你还不得不用axis。
通常情况下用axis开发webservice服务端，需要挂在tomcat等web服务器下，以servlet的方式提供服务。但有些时候我会想将接口部分以一个单独应用程序的方式进行发布，另外再多带个web服务器似乎有些笨拙。
使用嵌入式的jetty是一个比较简单的解决方式。其中需要注意的是，一定要设置Context的ResourceBase，不然是无法找到webservice配置文件的。我当初就是想当然的认为jetty会默认在当前路径下查找配置文件，导致一直无法正确发布服务。
protected static void runJetty() throws Exception {
Server server = new Server();
SocketConnector connector = new SocketConnector();
connector.setMaxIdleTime(30000);
connector.setPort(8000);//jetty的端口
server.addConnector(connector);
ServletHolder axisServletholder = new ServletHolder(new AxisServlet());
ServletHolder axisAdminServletholder = new ServletHolder(new AdminServlet());
Context root = new Context(server, "/", Context.SESSIONS);
root.setResourceBase("./web/");//WEB资源目录，./web/WEB-INF/server-config.wsdd
root.addServlet(axisServletholder, "/servlet/AxisServlet");
root.addServlet(axisServletholder, "/ws/*");//设置webservice的发布目录
root.addServlet(axisServletholder, "*.jws");
root.addServlet(axisAdminServletholder, "/servlet/AdminServlet");
server.start();
}
haystack 是 django 全文搜索的一个中间件，可以粘合 django 应用和 solr、xapian、whoosh 全文搜索引擎。
solr和xapian是早就知道的，Whoosh就没听过了。简单的了解后感觉这东西还是非常不错的。whoosh是一个纯python实现的全文搜索引擎。对python应用而言，whoosh的纯python实现，使whoosh的集成会容易很多，而且扩展起来也会容易很多。
下面是对Whoosh官方简介的翻译
Whoosh: 高效的纯python全文搜索组件
Whoosh是一个纯python实现的全文搜索组件。Whoosh不但功能完善，还非常的快。
Whoosh的作者是MattChaput，由Side Effects Software公司开发。项目的最初用于Houdini（Side Effects Software公司开发的3D动画软件）的在线帮助系统。Side Effects Software公司将该项目开源。
主要特性
为啥选择Whoosh
Whoosh从其他的开源搜索引擎中获取了大量的灵感。 基础构架参考Lucene，使用KinoSearch的索引算法，部分评分算法来自Terrier，英文的词语态变化来自Minion.
在django的资源页面里有个第三方论坛app的比较页面Django Forum Apps Comparison。一眼望过去，可用的app还不真不少，数下了有15个之多。但真正看下来，似乎很难找到一个让人满意的。
我对论坛app的要求是:
既然找不到满意的app，那就只能自己动手做了。目前计划在pybb（注：pybb的许可协议没看太懂，似乎是类似BSD的）的基础上进行开发。目前的开发计划如下：
最后还是选择了完全从头进行开发。pybb里面可以用的东西不多，而且他的开发思路和我还是有些分歧。
Spring的JdbcTemplate无疑极大的简化了JDBC操作。只是查询出的数据都直接放在MAP里。想要直接从数据库里直接查询出对象的朋友不免要有些失望。
这写天本想给JdbcTemplate做个扩展，让JdbcTemplate自动绑定对象。等写得差不多的时候，很不幸的发现自己只是重复造轮子而已。Spring已经自带了比较完善的解决方案，通过BeanPropertyRowMapper自动绑定数据库的列到对象。BeanPropertyRowMapper的绑定规则是，FiledName相同的绑定，如果绑定失败，将尝试将hiVik转换成hi_vik查找数据库的列。
如果需要查询出一个包含YouVO对象的List只需要做如下操作就可以了。
List objList = DbHelper.getJdbcTemplate().query(sql, new Object[]{}, new BeanPropertyRowMapper(YouVO.class));
Play!一个类ROR的java框架。和Grails不同的是，Play!没有用Groovy等脚本技术进行扩展。直接使用java技术，这对java程序员来说要亲切很多，而且推广阻力也相应的会小不少。
最近简单的了解Play!，感觉确实是挺有意思的一个东西。Play!作为ROR“仿制品”，在开发思想方面和ROR还是比较接近。Play!本身提供了不少开发相关的辅助命令。使用命令创建出的新工程直接就可以运行了。相比之下，基于ssh的开发，光是脚手架的搭建就得费不少事。
数据模型方面使用JPA定义数据对象，直接从对象生成数据库。这点和django比较像，这也是比较符合我开发习惯的一个做法。
模板方面和Django类似，支持模板的继承。Django模板的继承给我的体验很好。jsp页面虽然可以使用include实现复用，但对于结构相似的页面依旧需要重复的include。Sitemesh虽然可以实现类似django模板的功能但看到那繁琐的配置我就撤了。
总的来说Play!给我的印象还是挺不错的，希望在日后的工作中可以用到。
Play!的FAQ里有一个解答让我挺印象深刻的。其中有关于为什么使用不符合java规范的play做包名的说明。play!本身就是一个平台，运行在play!上的东西都将是符合play!规范的，所以不必为play这个包名而计较。play!专注于web的敏捷开发，为了适应web敏捷的需要一些无伤大雅的“另类”做法也是未尝不可的。想自己在某些情况下对代码还是有些所谓的“洁癖”。在django开发的时候喜欢在自己的app外面还要另外加一层包，而这种做法在一定程度上是不符合django做法的（django的app名必须唯一，即使上层的包名不同也没用）。
Twitter网页客户端都封得差不多了，于是决定在自己主机上搭个Twitter网页客户端。本想自己写个简单的，不过看到Rabr后立马打消了这个想法。
Rabr是一个用PHP写的Twitter网页客户端，具备基础的Twitter功能，而且界面漂亮。
作者还是用Rabr搭了个演示站点。虽说是演示站点，但普通用户已经可以通过这个站点登录自己的twitter了。
不过我觉得这样的东西搭建好后最好还是自己用就好，不然搞不好莫名其妙的就被封，那就不好玩了。
很早以前就听说可以使用JAVA的PHP库在GAE上使用PHP程序。所以特意将Rabr部署到了GAE，可惜没有顺利的跑起来。提示GAE对java.net.Proxy做了限制。去看了quercus（java的php引擎）的代码，似乎可以将Proxy去掉。改天对quercus修改看看。
如果你想用python开发一个twitter客户端可以看看http://code.google.com/p/python-twitter/，twitter api的python封装。