恰恰相反，我觉得有 copilot 以后写代码的乐趣比以前强太多了

写代码过程中少数无聊的事情恰好都是 copilot 最擅长的事情：写用户看不到只在联调撕逼用的 error message ，一辈子触发不到但也不能省略的 error check ，一个实现写对了要排比句写其他表 /模块的类似的代码，单元测试的 boilerplate ，还有注释，微妙的细节我写代码 copilot 补充注释，傻逼的地方我写注释让 copilot 写代码，简直完美

B 是 nas A 是移动设备的话，反过来在 B 上跑脚本将同步文件夹的内容定期移动走就可以了，让 syncthing 自动把删除动作同步回 A ，不要用 syncthing 的那些不删除或者多版本之类的策略

IOC 部分的设计决策非常符合我的偏好，app framework 部分就有点过重了，支持一下

我总结一下：条件不搞清楚查全表 boom 、已经引用的类库里的能力不用而自己写、已经有的接口自己重新实现
以上问题提醒、讨论过没有改变

我好奇的是这属于技术中上的话，UP 你的其他同事干活是什么状态

关于最后一个问题，我推荐一个支持生成各大语言 JSON 代码的命令行工具：protoc

@securityCoding 可以看看 https://github.com/bufbuild/connect-go

给自己和父母陆陆续续买了 3 台 realme ，没刷系统，就换了一下 launcher ，基本没有广告，谷歌直接装

能记得起来的广告只有安装应用有按钮劫持到内置商店，还有安装成功后的界面有 app 推荐位，刚买的时候短信 app 会推几条碎屏险后面就没了

近几年有好几次想用，研究以后的结论都差不多，wasm 社区心不齐很多波不同的人各搞各的，看不到未来

客户端性能优势完全错过窗口期 99%的场景性价比不如让千锤百炼的 JS 硬跑 JIT ；服务端 wasi 空有几个 runtime ，没几种语言支持实际写 wasi 模块，还和 AssemblyScript 闹掰了

希望干脆点客户端服务端分家算了，各玩各的可能反而发展迭代更快，客户端研究研究 app 之类的场景能不能拓展，想办法和 js/ts 互操作性更强一些；服务端看看 wasi 到底行不行，早点达成一致，不行赶紧来个替代者，后面 gc 什么的早点弄出来，语言（真正意义上）多支持几种，Docker ，IOT 这些场景落地落好

首先划掉饱腹，因为健康自然意味着均衡的膳食纤维，升糖指数，约等于饱腹 ok

其次把没有提到的要素：钱拉满来获取好吃方便健康同时满足的话答案很简单：雇营养师和厨师来给你做好吃又健康的东西

captcha 其实是个缩写 t 是图灵的 t
把工作量证明的 w 放前面这个名字有点黑色幽默
毕竟能跑得动工作量证明的那么多计算的，反而是机器

我的理解是微服务真正的创新在于“用服务化的手段解决架构服务化改造过程中遇到的问题”，因此更贴切的说法应该是元服务而不是微服务

公司基本都用飞书或者谷歌之类的云方案，本地文档用的最多的是 keynote ，一年也用不了几次处理 docx xlsx

office 订阅过期了没打算续，公司预装的 WPS 每次用也被这个坏东西恶心，我的做法是截图界面然后微信联合登录，反手举报微信公众账号出气

https://grpc.io/docs/guides/error/

大类别尽量套用 grpc status ，如果需要更详细的可以自己定义 detail 报文

说白了和 restful/restlike 有 http code 和 body 两个位置是一样的，唯一有点区别的是 grpc status code 设计目标更贴微服务架构也更现代一点

1. 一般而言在你不熟练的时候，把任务规模拆小是个很好的方向，建议粒度可以到半天，注意上班以后开机新建文件夹创建一个空白项目的消耗也是半天，如果公司有什么仓库要申请，权限要申请，那就是一天
2. 证明你的多个小任务合并起来就能完成整个需求，一般而言这个证明也可以叫做“技术文档”，因此，在技术文档完成之前，不要承诺任何排期
3. 你一定会被施加出排期的压力，这个时候不要违背第二点的原则，比较靠谱的应对方式是给出排期的排期，也就是你需要多久能把技术文档输出。另外，你应该特别关注的是你的前置依赖，把这些作为阻塞项抛出来请求其他人的帮助，包括产品需求不明确、对接的其他技术团队不明确或者不了解需求、环境部署和以前不一样需要运维参与等等
4. 无论团队层面是否有复盘，每次需求上线后，可以自己复盘一下当初的排期是否有没有考虑周全的地方，下次排期更准需要改进什么
5. 我个人从来不做乘法或者预留名为 buffer 的时间，技术工作的总体方向应该是持续消灭不确定性，我认为留 buffer 是与此背道而驰的。也非常不利于团队之间的信任感和自己的持续进步。
有其他部门或客观情况导致需求做的慢，我不会去争取什么 buffer ，而是直接摆到台面上，比如：预计这个项目开发需要 3 天，联调需要 10 天，联调特别慢的原因是基于过往与 XX 团队调试的经验预估的。 而不是模糊的说什么预计多少天 buffer 多少天之类的。
留模糊的 buffer 那么磋商排期就是菜场买菜讨价还价；而明确的时间细分出来，要缩短哪一块的时间就哪一块是提高效率还是砍掉不做还是怎么处理

京东自营直送的略快，也要 3 天

本地网购 hktvmall 自己看预计送达吧，我感觉每次都不太一样

线下直接去深水埗 啥都有

fish 之前甚至没有怎么考虑过 bash 兼容 && 2>&1 这些东西的支持都还是后加的