nodejs 还没上 4.x 的版本的时候，就说过了。那时候版本一个接着一个。
官方说会陆续发布一些 LTS 版本，并且之后会有稳定的升级周期，不会再乱升级。

反正速度比较慢… 而且通常代理的话就打不开了。。。

临时收藏了，有时间看看。
@jeffjade 其实谷歌也会这样。不过百度更蠢一些，以前经常是点击了 仍然搜索“ XX ” 以后继续给你搜索“纠正”后的结果 ... 再点击仍然搜索“ XX ”之后依旧如此往返... 不同时间段在手机百度上都出现过这种情况。虽然现在基本没了。。。

无所谓。不过我个人还是习惯 VBox ，最近还出新版了。因为它资源占用更小些。

VMware 在很多发行版上有一些 3D 相关的东西要解决，不然虚拟机图形很卡。。

所以标题可以再夸张点...

话说现在还找人么？有点想去张江... 懒得呆在这里了。

碰上这种 SB 直接删除，亲戚除外。

@Tr0y
code 错误不同的值是可以被枚举的，结构是固定的，但是不同的键是不可被枚举切结构不固定，是十分具有风险性的。
几乎没有服务端设计会出现这种情况，只能说服务端设计很糟糕。
有一种情况是可以让返回结构不相同，例如:

http_status:200
{list:[{...},{...}]}
http_status 非 200
{code : x, message : "xxx"}
这种情况下可以首先判断 http_status 再来对应解析相应结构，通常 RESTFul Client 都将对象的反序列化过程抽象掉了，根本无需关心返回中是否少了字段或者多了。

或者统一异常和成功结构，例如成功
{code : 0, message: "SUCCESS", data : {....}}
失败：
{code : 错误码, message: "错误消息", data : null }

初中那时候网吧上网确实看到过这种教程。传说可以提升网吧机器的网速…哈哈哈 居然现在又看到了

好不专业啊…提供一个 code 区分错误不就行了 居然键都不同。。
如果是成功和错误两种情况键不同还可以理解，首先判断 http_status 即可。估计所有 stasu 都是 200 吧…

@wuliao49 那你们当时为什么不考虑分布式消息队列呢……

大部分 JMS 实现产品都能持久化队列消息的…例如 kafuka 这种不完全为了实现 JMS 的消息中间件都会把未处理的消息持久化，更别提 AMQ 或者 RMQ 了

话说北京难道能找到大房东么…
上海已经全是二房东了。。。
并且大部分都是钻到钱眼的那种，叫办点事磨磨唧唧的，一个灯泡坏了三个星期没来换最后我自己换了。
不过我后来拖关系找到了一个上海本地人房东…人品很好。不过那也是极少数情况。。

一个月搞定算法…这么久。。。是零基础准备的么

验证码的诞生是为了干扰机器程序，目的是降低机器程序工作效率，识别验证码需要时间以及错误率，如果遭受攻击，攻击程度会降低很多很多。
从来不是绝对的完全为了让机器无法识别…毕竟人还是要看验证码的。
怎么可能会有被识别验证码还不如不用这种说法……

1L 的头像应该是只母蜗牛， LZ 的头像像海绵宝宝的小蜗。
UML 推荐 starUML ，插件一定不好用。

Genymotion 兼容性一般…不过启动很快。。
不过 android avd 运行的 x86 架构安卓也不慢…

😥我一直以为那个帖子是小号刷起来的…原来还真的有这么多人卖。。。