认同，但我不觉得用中文标注英文读音就算得上多专业

@NStal 之前看过，但不太喜欢 online 的，而且希望能和各类 SSG 结合……

有 15pro ，入了 SP4 ，开会收邮件涂涂画画靠谱，但躺床看电影的话太重了会砸脸的……

赞赞赞！

虽然老版至今工作良好

新版 Feature Request:

+ 托盘快速切换没了
+ 迁移老版方案

有自己的清晰合理的规划&&对此有实际行动的人一般差不到哪里去

mac 上我是这样编译成功的

```
phpbrew ext install gd -- --with-freetype-dir=(brew --prefix freetype)
```

phpbrew 真乃神器也

不得不说这就是后端对前端的优势了，难以精通的另一面就是不太会荒废

nodejs 熟悉一下编译工具生态链，建议 gulp 和 webpack 都看看，他们干的事情不太一样，一起用或者只用其中一个都很好

promise 如果还不知道或者不觉得它有用的话，好好学一下，学到“没 promise 简直没法写异步代码”的程度为止

angular 用过 1 足够了，建议看看 react & (flux 系的任选一个)，老牌的 backbone 也不错，但觉得精力不够的话就算了，基础扎实了上什么框架都能迅速掌握的

想往后台方面发展的话， linux 和网络协议多熟悉，数据库， redis ，消息队列这些多熟悉

想玩第二门后台语言的话， node/go/c++吧

至于深度广度的问题，暂时工作上没需求的话，基本上撸个自己的 weekend project 觉得还比较顺 就行了，反正真得用的时候还是得重新看一遍／还是会更新的

@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 端口去连的东西都一样用