hepochen

1，默认要相信用户。原则也分大小。

2，能 disable 掉更自然，不能的话，多用一年又不碍事。

你好呀。

Best Ones, 这样的目标，非常难嘛。总会有人质疑的，也很正常不是，但总不至于出现人身攻击呀。肯定是自己想太多了。

很有参考价值，但有些地方还是不容易令人信服的，即使是“ Best ”也是有局限性的，比如 mistune 的性能明显比不过 misaka ，实际生产环境使用是要慎重的，同样的有 jieba ，这是一个非常棒的库，但是实际生产环境（直接）使用，同样也是性能问题，这就是局限性，有些应用可能允许这个局限性不被触碰到，但声明下，或许会更好。

Django 是最好的？ 这个要分场景吧。 all in one 的框架模式来说，它毋庸置疑是最好的，但是很多应用实际上是不会用 all in one 类型的框架，这也是局限性，或许分一两个子分类，会不会更好一些呢？

提到了 IPython ，要不要考虑提一下 jupyter 两者之间的关系呢？

提到了 httpie ，其实要不要再提一下 mitmproxy ？

iScipt ，呃，这个相当的不合适吧……

现在的 List ，感觉是有很强的作者个人倾向性，其实， python 的工具性实在太强，作为个体还有很多我们还没有接触的，接触了也了解不深的。众策众力是一个办法，但也不是一蹴而就的，与其如此，不如考虑先从这个样本集里再抽离 “ Best Ones ”? https://github.com/vinta/awesome-python

不过，真的是太难了，令人望而生畏。加油呀。

像这种规则性非常明确的，也不需要用到额外的 dict 来建立映射。

替换这进百行的重复代码，基本思路大抵如此：
handler = getattr(self, data_item.get('cmd', '')+'_handler', None)
if handler:
handler(*[data_item.get(key) for key in inspect.getargspec(handler).args])


写出脏代码并不可耻，为脏代码辩解的倒真算是可耻的。

@hjiang Jiang,

其它的数据库我不知道，MongoDB的其它版本，我也不确定。

但是，2.4升级到2.6，集群内必须停机一起做？我不是你们某个员工口中的`学生`，这个要也是误解，我应该会怀疑自己做过的事情和智商了。

http://docs.mongodb.org/manual/release-notes/2.6-upgrade/#upgrade-a-replica-set-to-2-6


我觉得，你们应该遇到过单节点MongoDB故障的问题，应该也有改过甚至自己写MongoDB的drive来对应这些异常（如果没有，考虑重视），包括没有直接升到3.x，本身也很慎重，但是错了就错了，错了就是让人看笑话的，特别是你们产品这种性质的，赔笑、赔偿、赔不是，可惜你们只做到了最后一条。

算了，也不是你们的用户，真给自己找麻烦。

我应该也是误解了，特定的环境下特定的技术策略。我充其量就是半桶水的程序员而已，说的话没什么含金量。

抱歉，我真蠢：

一个集群5节点坏了，包括primary --> 一个集群3节点坏了，包括primary

不知道读到的信息是不是误解了，有几个问题挺奇怪的：

1， 白天升级数据库？还临近流量高峰期的前几个小时，窗口期留得太自信了？

2， 一个集群内5节点，不是一个个挨个升级，而是一起来？

3, 一个集群5节点坏了，包括primary，重启其它两个节点未成功的前提下，整个集群应该是挂起的，这个时候能支撑外部的请求？如果可以支撑请求，并负载不住（远大于2/5=40%），四点到七点间，固然是高峰，但应该不是最高峰吧，那么，真正的高峰，如果所有的shard分流均衡，整个数据库的负载是多少？会不会很恐怖？ Mongodb的这个集群设计，除了负载外，也是冗余的保证，2/5吃不下非真正高峰的流量，感觉不是太恰当。

4， 原先的系统就没有针对OOM（内存耗尽）的对应策略？


希望是我见识浅薄，都是误解。反之的话，哪怕一点，就没有办法让人鼓励你们了，除了佩服你们勇气之外，还剩什么呢。

@jxwho 仔细看别人的建议，包括后半句

headers判断