@raincious

promise 也就是个异步的接口而已，但大家都遵守， promise 就能成为事实标准。 express/connect 中间件也就是个中间件的接口而已，但大家都遵守， express 就能成为事实标准。

PSR7 也有同样的潜力，让所有的框架，组件，中间件都遵守同一种接口，当然革命性

@imNull

不怕笑话，我还从来没写过 rest 接口，主要是觉得驾驭不了 rest 原则，不如直接用最朴素的 jsonrpc

@movtoy

看菜下饭吧， PSR7 需要一点时间让社区慢慢接受，现在还没形成规模效应之前，还是该干啥干啥。 slim3 也是个不错的选择。 之前写的挑选框架的个人方法 => http://inside.mcfog.wang/2015/09/ichizon-d/

去年的话我会推荐 slim ，但现在情况发生了变化，与 php7 发布无关的变化

我坚信未来一定是 PSR-7 的。参照 node 的话， PSR-7 约等于 node 自带的 request/response 接口，现在它的具体实现以及 connect/express 库虚位以待就等社区自己生长了

slim3 是 psr-7 的，但还差一点味道，不够模块化
zend-diactoros+zend-stratigility 颇具具体实现 & connect 的风范，但完全照搬 connect 结果如何有待观察

至于能像 express 那样高完成度的，兼顾扩展性、模块化和快速上手的，目前还没看到

顺便，我觉得以后两种不同的 phper 一定会越来越明显： php5.2er VS modern phper

扫了一眼，没看明白干啥用的，只看到

> Locked global error,never shut down.

死刑。

回头一想不能冤枉人啊，点进去搜了一把

https://github.com/MiguelValentine/GDK/blob/5502399d0489a2d64cd7e03741df5922f80b1ef5/err/index.js#L16

核准判决有效，立即执行

不解释

markdown => pdf

一页 A4

三分之一：名字，联系方式，各种链接
三分之一：经历，职责，主要项目
三分之一：技术栈

@avatar 确实有的软件字体显小，修改放大倍率可以解决部分问题，也可以修改分辨率放大所有，但要忍受马赛克……

office ，自带浏览器和 chrome 都是完美的， QQ 也几乎完美

我最讨厌的就是这种类型的注释了

rm -rf / #删除整个根目录

assert(I am SB) //断言我是傻逼

这是觉得看代码的人不懂语法还是不懂英文？

才入 sp4 ，手里是 rmbp15

触摸板这个东西， surface 本身的手感和 rmbp 的已经比较近了，但 windows 系统本身的触摸板优化不行，加速啊，拖曳啊这些不如 OS X

发热，这个没啥感觉

高清下 windows 确实有些软件呆掉了，一般体现为图标非常小，做不到 OS X 下老软件的那种无脑放大两倍马赛克

我觉得既然提到“开发软件”了，写代码毫无疑问应该选 OS X

@ben548 JSON 原作者定的协议当中有一句被社区认为违反自由原则的描述（ GNU 、 debian 、 fedora 、红帽等等均如此认定）

The Software shall be used for Good, not Evil.

所以这些代码是无法进入多数主流发行版的软件源里的，默认配置的源里都不会有 JSON 库的代码的， PHP 也一样，即使默认的编译配置是带 json 的，但放到源里的版本不能包括 JSON

所以有人写了个 jsond 来取代 json

详情

https://wiki.php.net/rfc/jsond
https://bugs.php.net/bug.php?id=63520

简单来说， JSON 的协议( http://www.json.org/license.html )被认为不属于自由的开源协议，导致很多源当中的 PHP 都无法内置 json 模块（需要额外安装，比如`apt-get install php5-json`）

参考
https://wiki.debian.org/qa.debian.org/jsonevil

八卦
Douglas 是 JSON 发明人，蝴蝶书作者
https://en.wikipedia.org/wiki/Douglas_Crockford#.22Good.2C_not_Evil.22
和社区吵的不要不要的

服务端改不了如果客户端能改的话也好办，做个中心节点(配合本地 agent 做 cache)，客户端每次连接通过业务代码向中心节点请求服务器的 IP 端口，连接以后跑业务逻辑，如果连接／业务逻辑失败就上报失败给中心，如果成功也上报成功 /耗时，然后中心节点就可以统计、负载均衡、故障告警什么的了。发现谁慢就少分配活给他，失败率高过阈值就认为倒了 告警+踢出，也可以对被踢出的节点偶尔试一下来实现自动恢复什么的

这套东西中心节点压力大（或者靠 agent 缓存的话， agent 和中心之间的逻辑复杂），但优点正是无视 server 到底是什么，无论是数据库， redis ， mq ，还是自己的 server ，只要是拿 IP 端口去连的东西都一样用

菜单里面 显示 => 隐藏标记

人品或者说专业性其实是技术的一部分呢

总是为他人着想的人，自然写的代码会比别人漂亮，易读，清晰，做的事情会让别人舒服而非难过

我一直在想根据这个特性可以恶意投毒，故意开七八十个热点，通过特殊字符什么的排序靠前……

技术文章单词很少啊，文档更少，打破心理恐惧多读即可。不要老想“我在读英文，我这次一定要读懂”什么的

高考 130 不低了，但外语就是不用就会退化的，你只需要找回高考时的水平足够了

如果是指作为一份职业的话，编程的本质是做人和电脑之间的翻译，理解产品 /策划（业务）的需求，理解电脑（编程语言、运行环境）的能力，在两者之间给出解决方案并实施落地

另外因为往往不会是一个人翻译所有东西，所以你还得会掌握和其他伙伴合作一起翻译的技巧

算法和数据结构最多只是电脑能力的一部分的一部分罢了

顶顶顶，赞赞赞

再来一百遍也不会考研

@wangqj 已经自己入了，谢谢