8千克

我们的tracker系统是redmine。但redmine自带的wiki非常恼人，所以，我们最近上的wiki是python开发的Moinmoin.

为了把moinmoin和redmine桥接起来，需要为moinmoin写一个插件。

虽然wiki可以在某个功能完成后，再进行整理。我的一个想法是，功能产生的任务，是从wiki的内容描述中产生的。

但wiki不容易用作这些动态关系型的管理；而同样，redmine此类的项目管理软件，则在可视性上欠缺很多。

btw，此处并不是对两个软件评头论足，只是，因为，自己是个懒人，懒人就会有自己的偷懒方法，更何况，负责开发的哥们们，更是懒人，易事贴只是拿来装饰的，俗话说好记性不如烂笔头，coder有时候不好的毛病就在于，推卸责任，因为任务上没有说清楚，比如此类的理由。大家都是懒人，但责任这事情，就不用推来推去了，把事情做好才是最终的目的，PD的描述要被查看过，PD自己也要反复的修正，Coder也要多做笔记、备忘录。

不过，种种原因，需要把这些分散的资源整合起来。插件的名字就叫做task，用来跟踪和批量发布任务到redmine上。

不过遭遇了一个比较头大的问题，就是InterfaceError的异常。

如果哪位朋友也在写moinmoin的plugin，以及使用了MySQLdb这个库来连接MySQL，并且遭遇InterfaceError的异常，以下或许有帮助。

1，把MySQLdb.connetction 写到execute这个函数内，而不能写在函数外

2，如果运行execute时，还有其它函数调用相关的cursor、connetcion，把这两个对象，global 声明一下。

demo效果图在这里，看起来还蛮酷的

(more…)

最近抽空，在Lab Day中，改了以前的GSM程序留下来的bug，并做了个应用。Sign，真是一个不务正业的产品策划……

相信大家对豆瓣都比较感兴趣，那个GSM的应用是一个跟时光机有关的，所以，我的兴趣就来了，我们坐着时光机，回到过去看看，豆瓣是怎么发芽开花的？

下面先简单介绍下收集到的数据，（前2W用户只是号称，实际上，简况里的数据是1.8W的样子。）

1，第一张图是从2005-3-2到2005-8-27为止的（X轴），每天增加的用户人数（Y轴）。

2，第二张图则是第一张图的汇总，Y轴是当前天为止的总用户人数。

显而易见，豆瓣的发展在数据上呈现出了比较明显的里程碑时期。

注：简况中的这两张图中，用到的活跃用户的概念，其界定的阀值非常简易，那就是用没有给自己设过头像。

?

?

?

@@@@@@@@@@@

两张图只是一个小预告，1.8W的数据也太少。所以接下来可能要写的东西有。

1，豆瓣发展的里程碑事件的推演，这个对大家在理解流行点上，可能会有帮助，当然，这里面，数据只是占了一部分比重而已。

2，前10w用户（全样本集）的数据详细分析，这就包括了注册情况、活跃度、产品使用程度等多种参数分析了。

3，豆瓣从开始到现在的，所有的数据趋势。这个估计同2会比较像，但是它取的数据将不是全样本集，而是会取800w中的4w的样子。

4，八卦性质的参数分析。特别是豆瓣最近的读书API在腾讯登陆后，用户量激增。估计可以弄出一个非主流参数的建议模型来……还有比如阿北（或其他程序员），手动更改了一些数据的痕迹……比如头像更改次数最多的人是谁…….etc

5，注意上图2中，红线、蓝线的斜率差别很大，这说明进入的增长率要高于（其实是远高于，因为简况用到的活跃阀值很低）留驻的增长率。而这个是一种普遍现象，手头也有其它的几个数据可以辅助说明。简单的说，就是人们习惯于一时兴起，而已。关于这点，特别想展开说明一下。关于这点，确实是自己对互联网一些事物、概念，产生悲观、抵制（有时真的是理智……）的潜意识的重要因素。