同国行 s8，一样是未认证，是不是因为国行的机器型号和海外版不一样？希望有人给个解决的办法

这帮喷子和带节奏的是真 TM 贱，枫哥是我见过的主播里脾气最好的几个人之一了

用，为什么不呢？
把各种刚进的草案的、没进草案的、是标准的、不是标准的特性大量用在生产环境不正是 JavaScript 的魅力所在吗 :)
不过这样说的话，不如上 Node 8.0 吧，那样就不用 babel 转换 async/await 了

单数年就是给外国友人送钱啊
不过冲着地图，买了

难得不是成立，而是怎么让别人信任你

推荐 VMware 家的 clarity ui

fetch 毕竟还不是正式标准，如果要用还是建议用一个库

1. 实体版可以卖二手，可以借给其他机器玩，电子版随时可以在不同机器上使用（登陆自己账号）
2. PSN 港服支持银联卡
3. 可行，很稳

正美花了很多的心血在上面，有看过它的源码，很多地方能看出认真打磨的痕迹，只是，生不逢时
前端开发也许也进入了快餐节奏，大公司背景，作者的名气，如何推广自己
当然，从另一个角度来讲，现在的 mvvm 都是想让开发者用更简单的方法来完成更复杂的任务的，每个 mvvm 框架都有自己主打的场景
不如看看 avalon 的源码，也许可以学到很多东西、

因为现在 ecma rest operator 不支持 object
object 的 rest operator 是 stage 3 的规范
https://github.com/sebmarkbage/ecmascript-rest-spread

@nanlong
坑肯定还是有的。
定义 schema 麻烦，官方库的标准定义方法，结构复杂以及数量上来了确实是写吐，我们使用工具来通过简单的定义方法生成最终的 schema 。
js 自身数据类型太弱，比如 long 类型的数据或者 unix timestamp 处理起来就烦。
对 SOA 服务的调用参数和返回值都最好进行约束，不然就是凭空增加工作量，尤其我们 Java 和 Python 的服务同时在使用， Python 还是走的 thrift 协议。
前端使用时编写查询语句显然是比以前增加了工作量。
还有 node server 去调用其他服务时的各种问题。

方便快捷自然是要有的。
参考 github 现在开始提供 graphql 版本的 API ，使用非常灵活，前端自行获取需要的数据结构，后端也不需要关心 web api 层面的机构。
独立的 type 可以自由选择需要的 fields ，不同的 type 也可以自由组合。
另外像是 enum 和 input 也很大程度上提升了服务的健壮性。
同时由于类型系统和自省机制，配合各种工具，可以快速的查看整个 schema 定义。

关于是否解决痛点。
最大的体验就是原来占用大量开发工时的 web api 接口开发，很大一部分都可以被替代掉了，只要不是新的业务模型，很多都可以通过调整查询语句结构来完成，非常高效和方便。
接口的不确定性（不能知道接口的参数和返回值）的问题也得到了很大的缓解，最起码前端到 graphql 的通信是稳固的。
异常处理也很好用。

N9AGJRM76R13U4DK2K7VPSM

已用，感谢

你自己看进程啊，又不是说一定要启动了 QQ ，才会启动这个进程，我记得名字叫 msgBox 什么鬼的

这个是 QQ 弹出来的

https://www.google.com/get/noto/help/guidelines/

没错，就是你说的那样子必须列出来使用

Random rd = new Random();
Convert.ToInt32(Math.Floor(65536 * (1 + rd.NextDouble()))).ToString("x").Substring(1);

加上就是了。。。