@suantong 因为花在思考上的时间比花在敲键盘上的时间多得多，所以叫做科学家

讲道理，针对不同应用采用不同的频率，这不就是一种 scheduler 吗

Azure 中国区也可以邮寄： https://www.azure.cn/documentation/articles/storage-import-export-service/

赛门铁克事件和 WoSign / StartCom / CNNIC 事件性质差不多甚至更恶劣，然后呢，不活得好好的？

不就是喜欢捏软柿子嘛，找个意识形态自己一向看不惯的、用户少的 ban 了以后不会导致自家产品被大规模 complain 的，ban 一下，彰显一下自己注重“安全”

像 C# 什么的也是可以反序列化出一个类的实例的呀

附链接，自己以前一个预测随机数的方案： https://breeswish.org/blog/2016/03/16/0ctf-2016-quals-rand-2-writeup/

rand() 当然不随机，不仅有线性性而且是可预测的。
好几次 CTF 都有过需要预测 PHP 随机数的题了。

@airyland 最令我讨厌的是第二项，对于一个问题不去彻底解决而是给了一个绕过的方法，然后把这个问题关了（=这个问题已解决）

绕过问题怎么能是解决了问题呢？那么其他那些问题是不是也都是给了一种绕过方式然后不当做是个问题呢。如果是这种方式的话质量并不敢恭维 :)

@airyland

我接触的大部分开源项目，对于以下类型的 issue 态度(A) 和 iView 的态度(B) 是：

1. 给出场景描述，说明无法得到预期情况：
(A): 验证是否的确存在这个问题，若存在，检查是否是自己代码中问题
(B): 这部分组件用了第三方库，close

2. 给出场景描述，说明无法实现此类场景：
(A): 要么指明这个场景不是设计目标并解释原因，要么给出一种当下临时解决方案并考虑未来优雅实现
(B): 有临时解决方案，close

也许我接触的其他项目都比较 nice 吧~

用过一次 iView，印象不好
- 开发者态度不好，对于明明是组件自身的 bug 只给业务逻辑上的 workaround 而不改进组件自己代码，或者甩锅给第三方组件啥都不跟进
- 各种坑很多不提醒，比如不支持 runtime-only

```
var arr = [
{ quarter: 12, title: 'hello' },
{ quarter: 13, title: '====' },
{ quarter: 12, title: 'word' },
];

_.groupBy(arr, 'quarter')

```

=>

```
{
"12": [
{
"quarter": 12,
"title": "hello"
},
{
"quarter": 12,
"title": "word"
}
],
"13": [
{
"quarter": 13,
"title": "===="
}
]
}
```

moto x force 过气旗舰，然而一般够用，不仅原生还防摔呢

客户端 hash 在 https 场景下是没有意义的。如果已经能进行 https 降级攻击了，那么顺便插一段脚本监听你文本框的输入又有何难？

azure 中国区和 azure 国际区有专线，带宽在 100Mbps 以上，理论上够用

@ovear 代码规范当次太低了，这还停留在语法层面上。这里我说的是做一件事情只有有限的几种做法，只要你学习了这个框架，就一定能看懂用这个框架开发出来的业务逻辑，一定能互相协作，这是企业级开发的基础。

@ovear 框架最大的作用是在有一大批人合作的时候每个人都能看懂对方的代码，并且要做一件事情只有固定的几种方式

@actto 这么来说目测你的 IO 用的也都是同步的 IO 了……？那么你首先要做的是全改成异步的 IO ，然后用上一些异步流程控制的库比如 caolan/async 来进行控制（比如可以用上它的 queue ）。然后 setTimeout 可以去掉了

@guokeke breezewish

当然上面说的那些的前提是不频繁访问数据库。数据库一般是个瓶颈，一楼已经给出优化数据库的方法了。
不过不建议用 C 重写 :P 这个需求的终极瓶颈理论上在 IO ，如果测下来瓶颈不在 IO 上那么就是可以优化的。以及既然终极瓶颈是 IO ，那么我猜测不用异步写 C 的话会写得单核性能比 nodejs 版还要低。