如果你想获得别人更多的认同感，你应该提升自己的技术水平。
而非把时间花在这些小众工具上企图通过与众不同来装逼。。。

如果纯 vim 真的那么好用，jetbrain 和微软为什么要花大力气去开发 idea 和 vs ？
合适的场景用合适的工具，这才是聪明人的选择。

楼上这些解释都是复读机。

你想想 spring 就明白了，我们在做 spring 相关插件扩展功能的时候，是不是都不需要修改 spring 核心类库的任何代码？
因为 spring 提供了足够多的扩展点能让我们非常方便的实现需求。

所以我们平时写代码时也应该像 spring 一样，通过类似模板等设计模式为变化较多的部分提供充分的可扩展空间。

细化到具体的某个业务么，就是类似支付系统。一开始接的支付宝支付，然后加了微信支付，if-else 可以满足需求。但是如果后边需要对接银联等支付，if-else 就会堆成屎山。在不修改原来业务主流程的情况下，通过扩展多个支付方法子类显然是更优雅的选择。

不过国内的互联网，如果不是搞基础框架、业务中台一类的，搞这些开闭原则啥的其实没多大意义，相反还会徒增烦恼。视项目规模和维护价值自己做取舍。

@joesonw 不是，mac 是用四个像素点来渲染一个逻辑像素点，也就意味着“看起来像 1080”，实际上输出的是 3840x2160 也就是 4k ，如果你的显示器分辨率大于等于 4k ，那么显示起来没有问题，如果你的显示器分辨率小于 4k ，那么显示器会自行调整画面输出。

同样，如果你选择了看起来像 2560x1440 ，那么实际上输出的是 5120x2880 也就是 5k 的分辨率，不管你设备最大分辨率是 1080p 还是 4k 还是 5k ，他都是统一 5k 输出。

windows 和 linux 阵营采用的方式是 ui 缩放，这种方式在非整数比的缩放比例下会有一定的性能损失，好处是开发者并不需要做太多的 ui 适配调整。

昨天去店里看过了表示那个刘海是真的咽不下去。。

大概率会吃灰。
还是散了吧

你的路子走错了。
前端界面上所能实现的东西大多数都是属于可替代性非常强的，根本没必要把自己的代码守的死死的。
别人真的想 copy 完全可以直接重写一套。

电脑上 du df 不是照样很慢么？
查看存储空间的操作需要统计不同类型的内容占用空间和每个 app 占用空间。
也算不上是常用功能，有什么不能忍

macos 下 term 类应用最大的问题就是不能管理机器列表了。。
所以我现在很期待能有一款基于 web 终端的 shell 。。
直接跑在浏览器上，任他是 macos 还是 windows

notability 有个手写公式识别功能，不知道什么时候 goodnotes 也能安排上

test()里 temp 只是一个形参，

我觉得目前国内的互联网公司就和那些房地产一样，想着赚快钱，根本就不会太去注意楼房质量。

国内的互联网起项目完全就是为了进场抢份额，发展的好那么后续多投入点资源，发展的不好直接掐掉。
什么高质量有的没的，根本不 care ，项目问题多了就推到重构。

我更惨
用了 airpods pro 开始，耳道湿疹、真菌感染。。。。
现在已经不用了。

@xiaoliu926
人的血压是会随着年龄增长而增长的。140-90 这个范围也是包括了 70 80 岁的。
正常 20 30 年轻人的静息血压应该是在 115-120/75-80 之间。
美国那边最新高血压标准已经调整到 120/80.

@Zhengqing 看 iPad pro 和 iPhone 以及 retina macbook air 就知道了，下放肯定是会下放的，只不过要几年后而已。

将所有的 getOfficeCodeByXXX()包装成 Function，然后塞进一个 List 。
做 list 的迭代，执行 function.apply()，如果返回值非空，则 break 跳出迭代。

``` java
List<Function<BrChangedEvent,String>> funcs= Arrays.asList(
XXX::getOfficeCodeByOfficeUnlLocCode,
XXX::getOfficeCodeByPor,
XXX::getOfficeCodeByFnd,
XXX::getOfficeCodeByPol);
for(Function<BrChangedEvent,String> func:funcs){
String officeCode = func.apply(brGeneralInfoDto);
if(String.isNotEmpty(officeCode)){
brGeneralInfoDto.setBookingOfficeCode(officeCode);
}
}
```

touchbar 不好用，太滑了。。。

这种需求建议和业务代码解耦开来。
1. 将日志写入 mq，mq 另一端写入数据库.
2. 将日志写入磁盘文件，使用 filebeat 等工具进行采集
3. 将日志写入做成一个 rpc 服务，分别给 A 和 B 去调用。

因为大部分厂商都用 go 写一些高性能的中间件。

至于应用业务逻辑，一方面是 php java 已经有了足够成熟的开源产品、开发生态和开发者，另外一方面是用 go 重写也没有太多好处。

"裸 docker run 并发 10k，rps 30k 。k3s 直接降到并发 1k，rps 1k"
如果是这种降法，那我感觉可能是哪方面配置出了问题。牺牲换取伸缩弹性很好理解，但是能牺牲 10 倍 30 倍这种性能的，我理解不了。