一直装的 night stand （好像下架好久了）

就是会闹到自己没电的

@razor1895 实践证明能，官方 4k 显示器，3840x2160p 的话可以 60hz，但最高分辨率 4096 只能 48hz，另外，外接显示后卡顿明显了

JLS 里面并没有说两个不同的 monitor m, n 存在定义上的互斥关系

17.4.3 第一行定义就很清楚的指出是 monitor m 的 unlock 操作必须发生在同一个 monitor 的 lock 操作之前

但 synchronization order 的定义表述是不能局限于某一个 monitor 上，比如死锁问题，单独局限在任一个 monitor 下都不存在的，所以序和锁是不同的抽象概念，因为有序才会发生死锁

除了第一条，17.4.3 后面列出的所有和序相关的规则都和 monitor 无关
比如 volatile 关键字, read 允许并发, 但 write 必须发生同一个变量的 read 之前
又如 thread.join() 和 thread.isAlive()
等等等

通常
还原网络设置解决问题的话
就是说以前那个 pac 的 bug 还没解决
但我已经好久没遇到过那个 bug 了

我觉得增加了 16g 选项已经相当有诚意了，CPU 快 20%，硬盘块 50%，还有什么不满意的

@zo 算是自问自答了吗？结合 #13 就是

git show commit1..commit2 --author=你 --pretty= --name-only | sort -u

你可以觉得是一个 bug，但我觉得是 JetBrains 是故意的，因为这两个方法签名虽然是完全 override 了，但由于在定义具体化了很多，IDEA 把它等同于另一种形式的覆盖

比如
父类 Base getXXX()
子类 Extend getXXX()

他们的签名不完全一致，但会导致 override，在 Java 1.4 以及之前这种 override 是不允许的
在 1.5 之后开始允许，编译器会给子类自动生成一个 override 的 Base getXXX() 的方法，自动 delegate 给 Extend 后的版本

感觉 IDEA 是模拟为这种情况来生成语法结构，毕竟两个 add 方法的定义实际是不一样的

你 python 最终不还是得调用命令行才能访问到 git

一般来说没有比较本地和远程这种说法（ svn 思维）
git fetch
git rev-parse HEAD @{u} | uniq | wc -l

第二行输出 1 就是没有变更，输出 2 就是有变更

这有啥好吐槽的
所有银行信用卡的利息计算都是这么坑，就是摆明了靠这个赚钱的
但基本上所有银行都能自动购汇还款，无论是招行和中信都一样
然而招行的招招盈不但有五万限额还不能自动还信用卡更不能在快捷支付的时候自动转出
反而中信的薪金宝限额远高于五万可以自动还信用卡还能在快捷支付里面使用
你直接把余额宝的钱存到中信的薪金宝里面不就没这个烦恼了

我肯定选 12
该有的都有了，由于选项少，直接上顶配也多不了几个钱 16g / 512g / m7
13 不带 bar 的性能好的有限，但要忍受这些缺点
- 重了 50% （最难忍），还有厚度
- 风扇噪音（用过的都知道，完全无声音有多爽）
- 可能续航还差一点

在性能已经可接受的前提下（尤其是，有了 16g 的选项了），当然便携度才是第一要领

这不重要

重要的是，没人发现可以选配 16g 内存了吗？

还在用 Dash 2 的路过

这货不带电源的吧，65w 怎么得来的

当然是 16:10
同样是 full hd 多出来的 1 (1200) 就比 1080 多了一百多点

git checkout 相当于 svn switch
如果本地有未 commit 的文件，而 switch 到的新的分支上修改了同样的文件，结果就是 conflict
在 git 里如果不 commit 的话会直接禁止你 checkout
原理是一样的，只不过一个选择了 conflict 状态（ svn ）另一个选择了禁止（ git ）

https://i.v2ex.co/5G0fX5L7.png

我说这是啥特效，原来居然是换行了

《大腕》

多扯淡一下，kotlin 的官方推荐标准也是不加
这个我遵循了
因为毕竟是新语言

对于 js 这类背着一大堆历史包袱的老旧语言，即便 es5678 玩出了花，那还得兼容吧？一个分号可以消除所有歧义，何必费脑筋

standard 是不加

反正我是加

前端高大上不断的闹革命，在他们看来，如果有两个相似的选项，那肯定会选择一个和以前不相容的选项