@tachikomachann 所有消息来源都只是这个 twitter

@justrand SCSS 个人感觉用起来确实舒服一些。
不过我也负责维护 CI 工具链，那个 node-sass 坑到我宁可用 LESS 也不愿意用写起来更舒服的 SCSS。

而且这 App 最坑壁的不是广告，而是 Cache 根本没法清理。
用一段时间以后就会占好几个 G 的空间，而且完全无法释放，无论是内置的清理缓存还是 iOS 都无法释放这部分空间。
只能卸了重装。

他这 App 的启动屏幕是有广告的。
广告是实时下载的。
启动屏幕并不是第一次启动 App 会有，切到后台再切回来也会有。哪怕切出去时间非常短有的时候也会有。
所以如果你网不好，切到后台再切回来就会卡。
而且有个最诡吊的，有的时候切回来你看一会内容，他广告下载完了会让你再看一次启动屏。

最开始的时候是 C 语言推荐这么做，记得最早是 C 专家编程或者 C 陷阱与缺陷书里写的。
这两本书都非常老了，上古时代的 C 编译器无法在你把条件语句写成赋值语句时给出警告。但是如果你这么倒着写，赋值语句就会直接出错。
但现在几乎所有编译器都可以在这种情况下给出警告，这么写已经没什么用了。而且如果代码一部分这么写，一部分正着写，看起来就很怪，还不如全正着写。

Confluence 自建的话需要你有足够水平的 IT，否则内容多，用户量上来以后会非常的卡。
但从功能上，目前试用过各种 wiki 都没有能与其竞争的。

@cijianzy 不解决主要矛盾是做不下去的，你想想水深火热里放的都是啥。

其实是不一样的东西，不能拿来比的。pip 不过是依赖管理（官方自己叫 package installer ），而 Gradle 和 Maven 都是构建工具。
构建工具需要把软件项目构造成实际可发布的一坨东西，而解决依赖问题只是其中第一步。后面还要有编译，打包，测试，还要根据不同配置修改整个流程等等。
其实有很多基于配置文件的构建工具，无论是 xml 也好还是其他什么乱七八糟格式的配置文件，但做到最后都会发现根本没办法真的满足各种软件的各种奇葩构建需求。最终都要走到在配置文件里允许用户自己写逻辑这么条路子上。
Maven 让你把这些逻辑写成乱七八糟的插件，然后用一堆巨复杂的 xml 配置这些插件。
MSBuild 让你可以在 xml 里写一些简单的逻辑。
而 Gradle 则一开始就把配置文件做成脚本代码，你随便搞去吧。
所以当项目构建流程比较复杂，或者你需要自己修改官方流程的时候，Gradle 这种就尤其方便。

这玩意之前有人算过，是为了应付工信部油耗测试的。
因为工信部那个测试走的是欧洲标准，怠速部分很长。自动启停在速度低的时候踩刹车就直接熄火了，非常省油。
基本上启动一次相当于怠速 5 秒左右的油耗，所以你如果停了超过五秒都会省油，停的时间越长越省。
不过堵车还是关了吧，停停走走更费油。

@sparrww 不是，是所有老板都这样。
技术确保有没有这个产品，销售决定能不能卖出去。
只要产品做出来，卖出去了，从此以后就是销售比技术重要。
至于更新，增加需求，没那么重要的。销售足够厉害靠画饼都能把东西给卖出去。

1. 不一定，你的 GraphQL Schema 并不一定需要跟数据库类型对应，虽然对应了比较好理解，但不是强制的。
2. 取决于你如何设计 Schema 和是否使用 DataLoader。你可以设计成聚合类型，而不是单纯的 Domain 类型。或者你自己写 DataLoader。
不过这两个问题，RESTful 一样有，除非你并不是按照纯粹的 RESTful 设计接口的。
GraphQL 可以很好的解决前后端的沟通问题，省去你写接口文档的时间，同时也可以做一些简单的类型验证。你甚至可以一套 Schema 同时生成前后端所使用的类型。前端也可以写一些简单的聚合查询而不需要和后台沟通。

GraphQL 只是一层协议，和缓存无关。你可以在前端把查询的 JSON 直接 Base64 拼到 GET 请求的 Query String 里，然后后台取到这个 JSON 再去走 GraphQL 的 Parser。虽然默认情况下 GraphQL 都是走 POST 请求，但不代表你非得这样做。

GraphQL 的权限验证比较麻烦，如果你要区分用户权限可以访问的数据，实现起来不如 RESTful 方便。毕竟根据用户权限阻断访问请求在各种 middleware 里面都可以实现。但你用 GraphQL 就要在用户 context 里面自己验证。

我的项目不需要根据用户区分访问内容，所以只用了 GraphQL 做了查询。修改的接口很简单而且稳定，所以直接用了 RESTful。对于查询，因为类型之间有嵌套关系。比如 ClassA 包含 ClassB 对象，就可以在 DataLoader 里面省去查 B 的那部分。但对于单个类型，所有 field 是全部查询的。

等 3.1 的 LTS 吧，反正年底才发布，也差不了多久了。

仔细回一下吧。

Apple Watch 的单通道 ECG 能检测出来的症状很有限，而且就像房颤这种症状自身的感觉还是很明显的。你觉得难受了应该立刻停止运动迅速就医或者速效救心丸，而不是端正做好摸稳表冠 30 秒去测这个东西。就算你的手表跟你说你很正常，但你确实不舒服，难道你就不去医院了吗？你不觉得难受的时候除非真的是闲的太无聊了，不然过了开始一两个月的新鲜感，你都不会想起来要去测它。目前 AW 这种 ECG 功能用处有限，但并不代表它不是个好东西，汽车刚出来那会比马车还慢呢。只是这功能确实也没重要到你非得翻山越岭买水货再想办法激活的地步。

至于激活，其实只要你是美国或者香港的表，而且使用的 Apple ID 的健康数据里面有 ECG 记录，就可以激活。所以激活方法有很多。比如你可以登陆一下用过 ECG 的人的 Apple ID，激活了 ECG 以后测量一次，然后再换回自己的 ID 把健康数据合并进去。也可以让激活了这功能的人登录一下你的 Apple ID，把他的 ECG 合并到你的账号里。两种方法都可以激活。但这个很麻烦，你用别人的 ID 他可以 Find My Phone，你让朋友用你的 ID 也有各种同步风险。

所以我的意见就是这功能确实有用，但用处不大。至少没大到非得让你去买个美版然后折腾激活的地步。

@well666
@valkyrja

最大的作用是满足你买了一样的东西却用不到一样的功能这个遗憾。
实际上用处不大。

半年加个数，有啥好聊的。
又不是 LTS。
就算是 LTS 也得等你用的 Build 厂商发布支持策略。
微软努力扭转自己在开发者眼里形象的时候，Oracle 把自己玩成了过去的微软。

估计是觉得 C++标准每年新出的东西太多实在做不完了，几个 STL 库大家互相帮助一下算了。
新出的功能一家做一个，互相一抄就全有了。
开源以后 License 都改成一样的就完全没问题了。

@kid1412621 最好不要暴露这个 ID，会有安全隐患。这个值可以被猜到，也可以自己计算出来一个可能不存在的 ID。如果你其他地方没有全部做好验证，那就可能给你插进来几条错误数据。
直接随机对称加密一下就好了。