1. tcp 默认没有这样的行为，但万恶的防火墙有，并且粗暴的不完成完整的 tcp 断开流程约定，会造成业务无响应
2. http 找你的服务器文档看如何配置
3. 自己实现 tcp 服务器的话需要自己去实现断开的逻辑
4. 建议取值略小于防火墙设置，这样的性能最优，而如果不希望保持太多的空闲连接，可以设置为一到两分钟空闲关闭

maven 的依赖 resolve 是协作式的, 同一个包 (groupId:artifactId) 只能导入一个版本, 具体 resolve 到的哪一个版本在编译时是确定的, 规则虽然不是特别的复杂, 但也不是一句话能说的清楚, 可以用工具帮助解决冲突

并且实际上, groupId:artifactId 和 package FQN 没有严格对应关系这使得问题会更加复杂一些, 同一个 package 可能会被不同的 artifact 导入了超过了, 那么这时候编译以及运行时使用的是哪一个 jar 就变的不确定了, 这样的情况要尽量避免出现

作为想对面, npm 采取的是完全相反的方式, 就是每个 package 及其依赖都是尽量内蕴的, 两个一级依赖之所以用到了同一个次级依赖, 只不过是因为这个二级依赖的版本号恰巧是相同 (npm 会在条件允许下让它们尽量恰巧相同)

表面看起来 npm 的依赖管理简单易懂, 但实际上却复杂的多的多, 并造成了一大堆遗留到现在都很无语的问题

@beryl 你还是没理解, 关键在于 review 权限和 merge 权限分开, 既然你不需要控制 merge 只希望控制 review, 而又懒的找个人去点按钮, 甚至可以写个 robot 在 reviewer 点 approve 的同时自动 merge

当然, 如果开发者完全不配合, 自己点 approve 按钮, 而又不想分配人员来行使复核并 merge 的责任, 那么你可以让 robot 只是简单的检查 approver 必须和 submitter 不同, 也就是说 submitter 必须找个人帮他点 approve 按钮

@beryl 我们用的是 13 ，好像并不是 ee 专有的功能

新版的支持 approve 啊，可以收回 merge 权限，分配 reviewer ，要求必须经过 approval 才允许 merge ，负责 merge 的人不需要负责 review

实际使用上遇到过一个 bug

外接显示, 并且把外接显示设置为主显示器, 这时候自带屏幕的顶部区域变成了普通区域, 应用窗口可以直接拖进去

把视频拉到自带屏幕也即副屏, 然后全屏显示, 结果发现顶部被隐藏但应用视频渲染到了顶部不可见区域(该问题应用为腾讯视频)


解决方案就是用 RDM 把屏幕分辨率改为固定的 16:10 让刘海区域强制关闭

@otakustay 不需要的，除非额外设置，fork 分支，在创建 pr 的时候默认会给目标拥有者 push 权限

运营要求的就是个 terminal 肯定没问题, 至于销售就要看用的啥软件了, 比如 ppt 的话 mac 也能跑但可能和 win 下面的会存在一定的差别

在 mac (12.0.1) 下测试正常
1. Chrome 版本 96.0.4664.55 （正式版本） (arm64)
2. chrome://extensions/?id=febilkbfcbhebfnokafefeacimjdckgl - 启用 [ON] 允许访问文件网址 [ON]
3. Finder - 选择任一 md 文件 - 右键 - 显示简介 - 打开方式 - 选择 Chrome - 全部更改

之后双击 md 文件会使用 chrome 打开并通过插件渲染

BTW, 虽然我装了这个插件, 但从来都是关闭状态不使用的, 以及, md 文件是关联的 IntelliJ IDEA

没出现过 Sidecar 卡顿问题, 即使有应该也和无线无关, 不建议接线

既然不差钱, 建议 14 / 64G / 2T 差不多小 3 万
最主要的原因是店里会有现货不用等
如果 16 寸的话只能 16 / 64G / 8T 当然真的不差钱的话也无所谓
AC 随缘反正我是不买的

@sdd11 #8 代表 HiDPI

上周六就送达了，续航满意，没有想象中的尿崩

KeyGen 是一个函数
输入为 lambda
输出为 Tuple / Pair
解构后赋值给 (PK, SK)
这不是最自然的语言表达吗

es2015 原来已经过去 6 年了

reset —hard
push —force

你说的是 Nothing 类型吧? 怪不得看起来怪怪的

不怎么样，但比 2020 的 16 寸 i9 强