个人观点，标准过于复杂能力过多导致多数解析器都有各种问题甚至安全漏洞，这是 yaml 标准不够好的地方，不能完全怪实现。在合适的时候，比起花时间找更好的实现，我会选择换更简单从而更不容易出错的标准，例如 json, toml 等

类似的还有挪威问题：用 yaml 写国家码 US CN JP KR 不亦乐乎直到有一天遇到了挪威…

https://hitchdev.com/strictyaml/why/implicit-typing-removed/

@Livid
以 modd 的能力来说两种都支持，你说的在 modd 里叫 prep 一般放 linter 、build 、test 之类的，失败有输出警告，有变更时会重新执行；
而另一种是持续不退出，有变更时重启就是 daemon 了，总之大概的意思是类似这样

{
daemon: caddy run // 反向代理
}

Caddyfile {
prep: caddy reload // 变更时 reload
}

backend/**/*.go {
indir: ./backend
prep: go test // 后端 test
daemon: go run // 后端 server
}

frontend/**/*.js {
indir: ./frontend
prep: npm run lint // 前端 linter
daemon: npm start // 前端 server
}

一般而言分发一长串 brew install （包括 modd 和各种 sdk ）和这个文本文件，就能够在一个全新的系统上直接启动项目了

刚才试了一下，导出的 json 里的路径是绝对路径的会影响团队成员之间共享，发明一个.cl.json 之类的后缀，路径默认以这个后缀文件作为起点如何？甚至可以去注册打开方式直接双击导入。 另外 log 没有搜索或导出

@Livid golang 项目，PHP 的 swoole/workerman 之类非 fpm 的项目，包括 node 项目为了统一方案我都会用 modd 来管

之前一直用的 https://github.com/cortesi/modd 建议参考核心需求：
pattern match 修改什么文件重启
多个进程一组管理（常见：前端+后端+反代）
配置导出文本格式 /导入

之前命令行的痛点主要是输出日志混在一起，然后就是只能整组启停不能临时 disable 导致经常不必要地重启 webpack

1.每次执行命令前把命令本身记录到一个 history 文件
2.cat abc history | sort | uniq -c | sort -n2k 后（按次数排序）再喂给 fzf
3. 得到的结果也会后面多个次数自己处理掉

并没有什么环，mac+android 接近十年了，在我看来苹果手机根本不值它的价格

我也是当年硬件部分最想念小红点

但现在已经是 trackpad 的形状了，小红点不容易外置也不兼容机械键盘，用起来和 track pad 五五开吧

补充第三点，因为我是笔记本开屏接一个外接屏幕+外置 trackpad 的，甚至直接双手各自用不同的 trackpad 也是可以的，一个就保持拖动状态另一个定位

1 、 “甩” 加速度是影响推动距离的。适合中距离但精度要求不高
2 、到触摸板边界了可以迅速抬起后三指再放下，拖动不会中断。适合拖到一半发现到头，或者较长距离精度又有要求
3 、三指触发拖动后，留两指保持状态，直接用另一个手的单指负责移动，适合距离超远定位要求又特别精确

https://github.com/go-proverbs/go-proverbs.github.io/issues/37
rob pike 并不 100%赞同这句话并拒绝将其加入 golang proverbs

截图时的 touchbar 交互是我印象深刻的少数几个我觉得 touchbar 好用的地方

1 有几个其他相关功能，一个是 bookmark，另一个是 navigate to last edit，尤其是后者，我自己的情况看了一圈想回去的时候大概率是要回之前修改的位置
2 在有请求数据的断点处走条件断点（右键红点配置 condition

别问，问就是共同责任

产品或研发甚至测试任意一边靠谱就不会出这种问题，反过来，出现这个问题说明链路上所有人都有待改进

Windows 的话小红点，Mac 的话 trackpad 都比鼠标割裂感小很多

因为 go 的风格是把接口放在调用侧而非实现侧的，所以多数情况接口和实现是在不同 package 中，可以直接用相同的名字

多个方法如果紧密相关可以放一起，起一个整体名字，如果并没有太大相关，可以分开多个接口，go proverb 如是说：

“The bigger the interface, the weaker the abstraction.”

go 语言厉害就厉害在朴素
1. 方法调用实参和形参类型要求是 assignable
https://golang.org/ref/spec#:~:text=arguments%20must%20be%20single-valued%20expressions%20assignable%20to%20the%20parameter%20types%20of%20F

2. assignable 规则
https://golang.org/ref/spec#Assignability
对于两边都是 func 来说这啊那啊的都不适用，就是要求 identical

3. type identical 规则
3.1 func 要 identical 必须出入参对应位置 identical
https://golang.org/ref/spec#:~:text=corresponding%20parameter%20and%20result%20types%20are%20identical%2C

3.2 interface 和*Obj 不 identical，因为一个是 interface type 另一个是 pointer type


ref/spec 虽然有点拗口，但又短又精髓，查起来非常容易

我做过不少次关于这个话题的分享，也列过类似的提纲，但这些都是不太重要的“结论”而不是核心的“理论”

理论很简单，想明白你的这个{技术,发布,架构, anything}方案 /文档的目标读者是谁，他（们）经常关注的重点 /痛点是什么，你们作为研发要同步给他们的信息是什么，把这些信息分门别类记录下来（因为你不会准备 10 份文档给 10 个部门看），就是一份好的技术文档。

另外别忘了目标读者还有一个是同一个需求的其他开发，同一个项目下一个需求的开发，也很可能包括 2 个月后的自己

基于这个理论和各个公司、部门、系统的不同情况，好的文档并没有一个统一的结构写法

对钱追求不高家里又没有帮助凭什么要房要车，生活成本高说明你的生活水平高于你的赚钱能力了而已，总有更穷的日子过法

要么吃苦赚钱满足自己的需求，要么躺平把乱七八糟的想法也扔了，没钱就不花钱