重载造成的隐蔽错误

    大家看看下面的代码在什么情况下才会出错？情况很特殊，想自己思考的不要先看第二段。

    if ton in self.ftol: self.ftol.remove(ton)

    ftol是一个list，报出的错误是ValueError。经过上文的打印，赫然发现——self.ftol中真的没有ton！

    好吧，我们揭秘谜底。

    ton是TimeoutObject类型，这种类型的对象通常放在一个list中进行堆排序，来确定最早的一个timeout对象。为了实现堆排序，我使用了heapq。而为了heapq是没有key或者是cmp参数的，因此我重载了TimeoutObject.__cmp__对象。然而根据python源码，list对象在进行in计算，以及基于in的remove计算的时候，__cmp__先于内置算法，内置算法先于id相同。因此，in函数在进行对象是否在列表中的计算的时候，实际上使用的是一个比较函数...这肯定无疑的会导致乱糟糟的结果。

    为了解决这个问题，我又重载了__eq__函数，定义为self is o。问题立刻解决了。

    之所以python内置的算法，会定义__cmp__先于内置算法，内置算法先于id相同，是因为有很多对象需要人工定义比较算法。如果id相同优先，那么这种自定义的能力将无法实现。然而为了in算符中为何会调用__cmp__，只能说是一个不解之谜。

要这么招人恨也挺不容易的

    今天看看笔记本电池，突然想知道一下还有多少容量（不是还剩多少电，那个可以通过windows直接看到）。于是需要找一款笔记本电池查看软件。

    我上网搜了一下"笔记本 电池 软件"（一开始就没去baidu，刚刚查了一下，果然满屏幕卖电池和讲电池保养方案的），出来了很多中文网页。我看了看地址，是google.com.hk。

    再看看这些软件，仔细看看他们的广告词，说的天花乱坠。我不由有点担心，这台电脑可不是linux，要是中毒还是挺麻烦的。

    罢了，还是找google.com/ncr去搜一下battery status吧。找个外国软件虽然比较难用，不过基本不用担心里面有木马病毒什么的。

    做人要做到这么招人恨也挺不容易的，明明还什么都没干呢，怀疑已经先来了。对比某些国家和地区在某个事件上的处境，我觉得不容易的人不少。

如何做一个mercurial的http发布

    我假定你了解hg，了解python，理解nginx或者其他cgi/fcgi的配置过程。现在想用http发布自己的mercurial仓库，而且可能发布一群，怎么操作呢？

    首先，复制模板文件过来，你可以挑选其中之一。以下是debian的文件位置，其他发布请自行查询。

/usr/share/doc/mercurial-common/examples/hgweb.wsgi

/usr/share/doc/mercurial-common/examples/hgweb.fcgi

/usr/share/doc/mercurial-common/examples/hgweb.cgi

    我使用nginx+fastcgi模式部署，因此复制了hgweb.fcgi。我假定你的仓库在~/hg下面，有很多子仓库。复制hgweb.fcgi到~/hg/下，改名为hgweb.py，并修改以下两行。

config = "/path/to/you/config"

WSGIServer(application, bindAddress='hgweb.sock').run()

    其中bindAddress为你需要监听的unixsocket路径，没有前缀表示在当前目录生成。而后建立配置文件，大概为以下内容。

[web]

allow_push = someone

push_ssl = false

[paths]

/hg/proj1=/path/to/proj1

/hg/proj2=/path/to/proj2

    以上就完成了hgweb的服务配置，/hg/proj1是你的url映射路径，/path/to/proj1是物理路径。someone是允许进行push的人，而push_ssl是允许http推送。而后，启动服务。

python hgweb.py &

chmod 666 hgweb.sock

    注意，这里要用screen之类的程序来启动hgweb，否则term关闭后服务进程停止，就没的玩了。修改权限是因为debian下的nginx使用www-data运行，对/home/user/hg没有读写权限，导致无法使用unixsock。

    在nginx中做以下配置。

location ^~ /hg/ {

    limit_except GET {

        auth_basic "Restricted";

        auth_basic_user_file /home/user/hg/users;

    }

    fastcgi_pass   unix:/home/user/hg/hgweb.sock;

    include fastcgi_params;

}

    如果你不需要auth，可以自行参照nginx的配置修改。其他web服务器以此类推。重启服务后，http://domains/hg/proj1就可以访问到proj1了。

    当然，其实最后还要提一句，如果你不需要web界面，可以直接设定将文件内容直接发出去，这样也是可以做pull/push的。

参考：

http://mercurial.selenic.com/wiki/PublishingRepositories

为什么高性能框架都是http的

    很多高性能的web框架，例如沈崴的euraisa，fackbook的tornado（这两个都是python）框架，都是http的。这和我们的印象相反，python，或者其他高级语言不是都很慢么？为什么都用这个来做http服务器呢？

    这个我们得从服务器架构开始说起。最初的时候，没得说，所有的都在同一个机器上，甚至可能使用cgi模式。在访问压力上去后，为了增强性能，首先被拆出去的应该是数据库服务器。而后会考虑使用fastcgi或者scgi进行部署，前面使用apache或者nginx做前端。在这个时候，fastcgi是有道理的。因为apache在静态文件处理的性能上远高于python框架（而且快数倍），而nginx在大规模静止长连接的情况下性能更优异。而且，更进一步说，在性能压力加大的时候，应用服务器会被拆分，这时候apache/nginx做反向代理很容易做到负载均衡集群。

    然而，如果压力再上去呢？在这种情况下，通常考虑的两件事情是静态文件拆分单独的服务器和应用服务器的硬件负载均衡（没钱的话也得考虑LVS了）。道理很简单，即使服务器性能能无限提升，网络接口的性能也不会无限制的上升的。完成这两步后，我们再来看整个架构，会发现反向代理变成了一个鸡肋。静态文件处理？不在这些服务器上了。负载均衡，系统级有了。apache/nginx有什么用呢？难道就是把http协议转换为fastcgi协议？

    所以说，要达到高性能，框架应当是直接处理http的，并且支持大量的客户进行长连接。当压力小的时候，使用nginx的反向代理模式进行工作（而不是fastcgi协议）。当压力大的时候，拆开静态文件，直接上去服务全社会。

中国有IT业么

    中国有IT业么？大家这么多年，看着IT业红红火火，其实神马都是浮云。

    1.中国有宽带接入么？

     没有，你可以找中国的强制法律文件，什么是宽带。结果只有字典上的定义，而没有强制标准。如果没有一个法律意义上的强制标准区分宽带，怎么能说什么是宽带，什么不是呢？结论就是，任何人都可以说——我在用宽带。这不等于没有？在唯一的一个WIFI接入加密标准和其他国家不同的国家，一个什么标准都要自定的国家，却没有宽带标准，真TMD扯淡。即使我们不说国家强制标准，我们说国际标准。目前上国际对宽带的定义已经是4Mbps，而中国目前大多数家庭所使用的标准还是1Mbps，偶尔见到有2Mbps的。而且大多数人的网络接入价格还和5-6年前没有任何变化。即使考虑通胀，我们说电信资费其实在缓慢下降，这和电信接入高速发展的事实也毫不相符。

    2.没有宽带接入又如何？

    我们要知道一个事实，中国的10亿网民，事实上都在使用窄带接入。宽带和窄带的最大差别在于，窄带只能承载文字和图片内容，而宽带可以承载高清视频/声音。中国大多数网民都是无法享受高清视频/声音的，也没有机会享受in touch的信息服务。缓慢的网络速度注定你在使用网络的时候，下载到一个图片，就要在本地保存起来。下载一个光盘，就要保存起来。你不能像云端一样，将数据托管在网上，当需要的时候再下载。我们的硬盘，变成了巨型的互联网缓存器。

    3.现在的互联网业不是挺红火？

    贝壳原先听说过一个笑话，说眼镜一定要好好配，否则怎么怎么的。台下有人说，我的眼镜配的很好，眼睛去验光和眼镜完全一致。台上讲师冷冷的说了一句，配的不好的眼镜还有个缺点，戴个一年你的眼睛状况就会跟着眼镜走。。。

    互联网也是一个类似的情况。贝壳调查的结果，很多用户并不介意接入商是否封锁P2P下载，很多用户也不介意带宽不足，因为他们只用QQ，上天涯和猫扑，早上要起床偷个菜。所以网络一定要随时通，其他就不要紧了。我们说我们的互联网业，其实是在中国的网络状况下，发展出来的畸形品。天涯，猫扑，QQ，都是低带宽时代的服务，但是直到今天经久不衰。用户黏性是一个原因，另一个原因是更强大的，具备下一代特征的服务根本跑不起来。QQ也发展过视频聊天，结果也就是网友准备找419乃至更极端的援交前要“验货”的时候用。你见过有人和朋友天天开个音频聊个不停么？有人说国外也没有啊，问题是人家手机通讯什么价钱，我们什么价钱。你见过开土豆和优酷慢到死的，土豆还专门出了客户端加速。你见过开youtube卡到死的么？中国不算。youtube在研究什么技术？高清视频分享。你试试让土豆出个720p视频分享看看？不说CDN费用，光是等待时间就会让用户跑光。

    4.将来呢？

    我不知道。如果中国宽带仍旧保持现状的话，在网络高速发展的背景下，中国的网络应用也许会在3-5年内就会再落后人家一代。在人家用着随手可得的高清视频的时候，我们还只能接受IPTV这种专用替代品。不过严格论起来，这也没什么，毕竟中国从来没心思在这方面真的赶超英美。。。

小公司的架构选择

    很多大公司都是从小公司起步的，往大做的时候，往往会受到很多制约因素。架构选择不对造成的问题很多，所以很多小公司都在架构选择上精打细算。其实架构问题，在公司规模小的时候，更大程度上是一个行政问题而不是一个技术问题。

    小公司的特点是人少，往往就那么几个人。这种情况下，与其说是你选架构，不如说你看看有什么可用的架构。通常来说，你要考虑的问题是。

    1.你有没有可以信任的核心工程师？

    2.能不能找到足够的人手做大部分的事情？

    3.能不能在你要求的时间范围内把事情做掉？

    4.这个架构有没有成功的例子，能不能支持大规模的访问？

    当这些问题都没问题的时候，你才应该考虑，这个架构性能够高么？容易扩展么？

    如果你没有可信的人作为核心工程师，项目管理和控制根本无法进行。就算要评估一下手下这些人是不是真的需要这些时间来做事，得到的结果都是不可靠和不可信的。如果找不到足够的人手做事，那除非你的核心团队能够一个人或者几个人把网站整个做出来，例如豆瓣的阿北，否则项目做做就没人，就玩不下去了。如果架构很好，但是无法在要求的时间内做出事情来，等于没用。满足了上述几点，你还得兼顾考虑一下，这个架构如果没有成功案例，是否存在隐性的风险。如果不支持大规模访问，将来的扩展问题。

    好吧，作为一家小公司，我相信你考虑完以上几点后，能凑出一个框架来已经很不错了。往往是你的核心团队没有一个核心工程师，大家会几种不同的架构，而且没人能保证评估结果。

    这时候，不要废话，先找个核心工程师，然后用最土的，被无数人验证过的技术来把你想做的事情做掉。

    除非你的核心团队有且仅有一个核心工程师，并且这个工程师的技术能力很强，管理者和投资人也支持他冒风险。否则大部分使用激进架构选择都会带来不良的结果，毕竟大部分公司都不是以开发框架和研发技术为最终目地的公司。

QQ和360之争

    两个流氓狗咬狗，老子一个都不用了。老子是Linux用户。。。

单纯评价制度的影响

    下面的讨论对事不对人，请不要自行套上OOXX的内容，谢谢。

    我们假定有个游乐园，叫做OOXX游乐园。有很多投资人，时髦点，叫做股东。他们不亲自管理游乐园，于是他们找了个经理。大家知道，游乐园经营的好坏，经理起很大作用。所以股东要评定经理的能力，并给予相应的报酬，这样才能刺激经理努力工作。那么我们如何评定经理能力呢？

    首先我们想出的最简单指标是入园人数，不过很快，也被我们推翻了。很简单，如果我们和经理约定好他的工资和入园人数挂钩，他上去干的第一件事情就是打折和送票，哪怕每张票是亏的都好，只要入园人数满了7KW，他就可以拿高薪了。亏本和他有什么关系呢？

    第二个方案是通过总收入来衡定。好，这个方案看似没漏洞，不过很快，也被我们找到了一个漏洞。经理可以给员工高额回扣进行门票销售。例如，一张门票的通常价格是20，经理可以将门票价格提升到100，但是员工内部卖出去的票，给予员工80的回扣。在计算的时候，回扣是按照人力资源成本来计算的，门票是按照纯收入来计算的。

    第三个方案是通过盈利来衡定。这个稍微难钻空子点，不过只要这个经理有任职年限，也还是有办法的。这个经理可以在每年的年底，预销售一些游乐园的打折券和团体券，并且每年逐步扩大预销售规模。这样会让每年的财报非常好看，但是，出来混，迟早要还的。这个经理拿了全部的奖金，直接离职走人，下一任看到数以百万计的人拿着打折预销门票入园，为了保住自己的饭碗，只有卖更多的打折预销门票。直到整个年度的所有客流全变成预销门票的时候，戏法就变不下去了。

    也许有人会说，怎么有那么傻的事情啊，这些方法看一看就知道了。是啊，问题是，我们的题目正是，单纯评价制度的影响。如果不通过常务股东大会来制衡，动态的改变博弈方式，而仅仅通过单一的参数评定方法。那么经理有无数的方法来钻漏洞，走空子。

twip在hawkhost上问题的解决

    这两天twip的api不正常，跑上去看看，有个错误。

Fatal error: Cannot redeclare class OAuthException in /home/shellcom/public_html/apis/include/OAuth.php on line 8

    这时候，找到include/OAuth.php，改成这样。

#class OAuthException extends Exception {

  // pass

#}

    问题就暂时解决了。

    这是因为主机上新装了什么库，这个库自己也定义了OAuthException（会定义这种异常的，估计是OAuth库）。所以，把这个自定义的异常移除，问题就暂时解决了。

圣元蒙牛，谁冤枉了谁

    止尿喝三鹿，丰胸饮圣元。圣元奶粉性早熟事件还没过去，又出来蒙牛陷害说，大家打架打的真热闹。最终用户可不管到底是谁冤枉了谁，总之，圣元蒙牛统统不买。现在国家立法尚屡禁不绝的外国邮购奶粉就是证明。

    圣元和蒙牛陷入罗生门，显然是国家，或者说行业失去信用的标志。如果行业有足够的信用，只需要相关部门辟谣，就可以澄清问题，挽回影响。然而现在我们看到的情况是，相关部门越辟谣，越是没人买。想想也没什么奇怪的，阜阳大头娃娃，三鹿，熊猫，中国在过去的五年内出了太多的奶粉问题。光是出问题到罢了，关键是出了问题后对责任人的追究和对受害人的补偿。三鹿倒闭和收购，对受害人的清付实际为0。换句话说，受害人，凡是拿到赔付的，都是从我们的税中来的。说到这里我就气不打一处来，卖奶粉的造的孽，你让我一个玩IT的顶缸。而且凡是对国家赔偿不满意的受害者，现在也没什么实际的追偿渠道了。这实际上告诉所有人，国家给你的，你就拿着，想多要的，这点都不给你。

    这种蛮横和无理的做法，果不其然遭到了天下所有家长的反对，邮购奶粉盛行一时。没追偿机制，我不喝总行了吧？结果国家又制定法律，从国外邮购需要收税，而且很明白就是冲着奶粉去的。实话说收税到不是什么错误，邮购国外产品早该收税了。但是这能让不放心的用户买国产货么？

    你们继续打你们的去吧，我去喝米汤。。。