private?

@fkdog #145 是，因为你不知道什么是好的。不管你做什么，做再多也没用。
@markgor #147 我比你大一些，这里面首先是个态度问题。知道什么是好的设计，什么是 bug，什么是 feature。
而且就 LZ 这个问题，你知道 X-HTTP-Method-Override 这样的方案吗？ API 设计还是 restful，但是可以 fallback 全都是 POST。这样是不是既满足了优雅，又符合业务了？
从小的地方，这里改一点，哪里推进一下。当真的要推一个重新设计的时候，你会发现这时就不这么难了。

我拓展说一下为什么，这就是为什么在国内「 35 岁以上不要」的原因。

从这贴可以看出，35 岁程序员的经验都是什么「这么做是有原因 」，而不是「 我在 35 岁的时候把网关拦截 OPTION 的 BUG 给改了」。就这样的和 25 岁的程序员有什么区别？
10 年的经验没有用在把系统变得更好，没有把路拓宽，而是守着一条泥巴路，然后拦着后辈说别的路走不通。这样的「 35 岁以上不要」也罢。

这就是为什么在国内「 35 岁以上不要」的原因。

你打开 readme 的源码看不就知道了

就是后期合成的。

Postgres yes!

就是贵，怎么，还不让说了？

@Sunyanzi #52 LZ 问题是，每请求 100 次，弹出一次验证码。并没有时间限制，所以 once 也要一直存着。
如果有时间限制，那一小时清一次 IP 也没问题啊。
所以我说存哪个都差不多。

@Sunyanzi #47 「不严谨要求不能挨重放」 我的理解是「不严谨要求」下「不能挨重放」是可选项。
而且如果存 nonce 我不觉得会比存 IP 少啊。。

@Sunyanzi #31 不能挨重放，全靠客户端自律，和裸奔没区别。
nonce 有不依赖服务器存储的实现方法？

单一主线原则：保证 master 分支（你这里是 dev ）处于随时可上线发布状态。
如果有任何分支并入会改变这个状态，则先，将任何有相互依赖的 feature 分支先合并再以单一 PR 并入 master。
如果合并后有 bug 使其变为无法发布状态，先 revert 再发布。

预生产本来就是团队的主观决定，一般预生产比测试环境更稳定这样。

另外我们发布是用 tag，比如 staging-1, demo-2, production-3 这样，我觉得比 branch 好很多。

比如这样： https://github.com/binux/pyspider/blob/master/pyspider/libs/counter.py#L76
目的就是使统计数据更平滑，英文有叫 moving average 的，但是滑动窗口实现不依赖数据存储，能直接输出。

@HaroldChen #2 一个 GitHub repo 一个 ns

按业务