800+的度数，镜片 1.7 的都很贵。不管怎么配都是 1000RMB 左右。所以都是去日本的时候直接 JINS 解决。
日本的 JINS 高折射率镜片不加钱，国内的加 300。而且配的不舒服一周内可以换。不过算下来也都是 1K 左右，跟潘家园或者自己买镜片淘宝配架差不多。

@xialer 所以我们都是拿 Artifactory 去 Proxy Docker Hub 的。。。。

@xialer 刚好赶上了，真是惨，看这样你是要通宵了。。

10.5 寸老款 iPad Pro，日常按照使用频率排列如下：
0. 泡面盖子，以及吃泡面的时候看个剧。
1. OneNote 笔记，PC 和手机上也有，自动同步的。iPad 上这个主要是用外接键盘比较方便。
2. Affinity Designer 简单画一些原型，pencil 用起来比鼠标方便一些。不过感觉还是没有 2 代的舒服，考虑以后有钱了换。
3. Outlook 回邮件。
4. Pythonista 写点垃圾代码。
5. Kindle 看漫画。
实际上因为出差比较多，iPad 还是很方便的。参加学会可以直接 OneNote 把论文全导进去，然后开会的时候直接笔记或者录音非常方便。也可以直接对着投影拍下来，在上面做笔记。其他会议拿来做会议记录也很好用。配上罗技那款键盘写邮件回邮件也都可以做。实在不行装个 TeamViewer 远程回去看看代码也是可以的。但是有 Pythonista 和 SSH 基本用不上这个。

@cominghome 不会，你就随便找个没人用的鬼协议，自己瞎逼改改特征，天天佛着用，不管啥时期都没人鸟你的。

@Cavolo 在也没问题，只要有 ECG 使用记录就可以一直用。
最开始的时候只要是美版就可以直接激活不限制地区的，那时候激活了就可以一直用。

Vultr 开的已经用了一年多了。。稳如老狗
你用个小众协议，自用不要长期保持连接，基本没事。

我们之前是按照从上家公司离职，全员补了 N+1。
新的公司从新开始计算。
当然你也可以拿了 N+1 不签新公司直接走。

@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 是全部查询的。