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。如果你其他地方没有全部做好验证，那就可能给你插进来几条错误数据。
直接随机对称加密一下就好了。

@fvckDaybyte2 然后折腾半天激活了，半年用一次。。

@Static2015 专门的陪练是有的。我找的那个驾校的陪练就有。而且正式合同的话，如果出事故陪练是有责任的。

驾校都有陪练业务，前段时间刚找了北京这边的一个，避免广告就不说名字了。一般大概 100 一小时，具体还看车型。
之前也找熟人陪练过，有的时候自己开车会注意的地方，坐在副驾就不一定能说得出来。
不过一次三小时起价格也不便宜。你可以找个陪练带你上下班路线走几次，剩下的自己练练就好了。

医院验光。
去日本的时候在当地 JINS 配了好几副。
主要是我这 800+的度数，配 1.7 折射率的镜片在国内不管哪家店都得加钱。国内的 JINS 加 300，日本的不加。而且觉得配的不好可以一周内免费换两次镜片。

@bmos 一般的 Docker Image 设计都是除了临时数据以外，其它的数据要么写到 volume 里，要么写数据库。这样你可以使用一个共享存储作为固定的持久化路径，Docker 容器本身就可以跑在网络内任意一台 host 上，只要能 mount 到这个存储路径就可以。
大部分 docker 封装的各种东西都是这么设计的，习惯了就好了。。。