mcfog

首先划掉饱腹，因为健康自然意味着均衡的膳食纤维，升糖指数，约等于饱腹 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 自己看预计送达吧，我感觉每次都不太一样

线下直接去深水埗 啥都有