@ppd 销毁是因为你没有这个能力审计出对方到底做了什么事情留了哪些后门，销毁重建是这种情况下最经济的做法
即使你有信息安全能力，一样应当备份这个被攻击的镜像（离线研究）后销毁这个实例

如果你不具备信息安全知识，那么这个时候应该做的是销毁这个实例，修改所有这个实例上曾经存在的密钥、密码、token 等信息，重新学习信息安全知识以后再重新开一个实例正确地配置服务，以免损失继续扩大

@zthxxx unix 哲学恰好是反对银弹的，先 do one thing 再 do it well，这里 fzf 解决的就是“终端下从多行文件中选择一行或多行”这一件事，至于这个多行文件是历史也好是某个文件也好，还是另一个命令的输出也好，是否排序是否去重，选择完以后的结果做什么事情，fzf 一概不管，工程师自己去写脚本把工作流胶起来，这种工程师思维是简单高效的。如果你没有理解到为何这种设计行之有效，为何 fzf 选择不做去重，不做很多你觉得是理所应当的功能，我只能表示遗憾

k8s 的环境列表不在历史记录而在配置文件里，ssh 的机器列表不在历史记录而在 aws api 里，每天都有 auto scaling 机器可能都不一样，根本不可能依赖历史，常用工作目录更不是搜历史搜出来的了，至少我肯定不会反复 cd 完整路径到常用工作目录

@zthxxx 看了，不需要，直到你说了我才发现 fzf 是不去重的，我用 fzf 都是直接命中一个正确结果的，就算需要去重，我也会用 sort|uniq|fzf

fzf 的好处正是由于他并不是专门为了 history match 设计的，k8s 切环境，ssh 上机器，常用的工作目录切换等等，我日常工作的所有“选择题”都是 fzf 驱动的几行脚本，你告诉我其中某一个选择题可以用一个工具做的更好并不能打动我换工具

我还觉得你震惊错了方向，扳手有一百种功能，你看人用扳手来敲钉子，然后震惊扳手的设计者怎么那么不考虑体验然后设计出了锤子，这很好，锤子有锤子的优点，但对于平常用扳手四五十种功能，只是偶尔敲一下钉子的人来说，你的锤子再好用也没用，不用，谢谢

？你和产品说测试没测出来就不是背地说别人了？
测试被捅刀子了去和产品解释情况反而变背地说人了？

这事情就是你不懂怎么做事情。平时被口头改需求恶心了那么好的机会，和产品把逻辑对清楚了，这时候就该和产品说清楚啊，你改需求太随意了导致容易出这种错啊，下次改需求要同时维护文档啊，要周知测试啊，想怎么怼怎么怼，你偏偏怂不敢当面说，扯不在场的人乱甩锅

没有同感，我要是哪个仓库 fork 比 star 多而且还没有合理的 pr 的话，我会反省自己找错受众了，怎么就惹上一群用不来 github 的人了

还有，文章里截图的 repo 不是什么开源软件，虽然放 GitHub 没啥问题，但我还是希望这样的 repo 越少越好

fzf

@TomVista
我不太理解什么叫用 graphql(或 restful)实现数据库操作
你觉得不可行，但找不到理由为什么不可行的话，可以倒过来想想，这样做（比其他做法的）的好处在哪里，沙子造芯片是可行的，机器码写业务也是可行的

观察两家知名的 graphql 接口服务商脸书和 github，他们用 graphql 都是非常合适的

- 他们的后端（开放）接口 consumer 数量巨大，协作困难（不如说因为是提供给大量第三方，不可能单点和某家 consumer 协作）
- 支持更多的 consumer 对他们是有利的，形成生态的，他们有动力去改善 consumer 的开发体验（ DX ）
- 他们的业务核心逻辑和关系稳定多年不变（脸书的用户、好友关系、feed 流，github 的 repo、star 等），又有大量的字段、自资源、关联等情况，又愿意或者需要提供这些能力给外部

好的，所以国内几乎不存在满足上述条件的公司，就算国外我也想不到第三家了

哦，对接部门多到爆炸的大公司的某些核心部门的内部 API 网关可能也还能考虑用吧，但这种用了也不一定会有分享让外界知道

不知道楼主的整体是否很好地总结概括了这本书的风格。如果是的话，不推荐读这样的书，窜味儿，难受

别说出来啊，进了培训班面试手册怎么办，快删掉快删掉.jpg

你觉得 sofarpc 了不起，有解决 bug 的 pr 就很厉害了，面试官不那么认为

如果你不甘心，下次可以说具体一点，我解决了 sofarpc 里一个如何如何的疑难杂症，虽然我并不推荐

2FA 是帐号密码的一部分，如果光凭证号密码就能关闭已经打开的 2FA 岂不是没有意义了

找客服吧，应该需要其他方式验证账号的所属权，之前处理过 github 丢 2FA，是通过关联的 ssh pubkey 验证的

不不，不是你的谷歌云被攻击，而是你从你的谷歌云攻击别人

我就是因为没有同步功能所以用谷歌的，绑定时自己把绑定用的二维码（其实就是个 uri ）离线备份就行

@a62527776a next 仍然多余

提供这样一个不上不下的功能没啥意思，不如给用户完全控制框里的渲染和逻辑的方式
随便说几个场景吧：
a)取消也要异步 block 住
b)block 过程中用户希望在按钮上显示菊花 /其他文字
c)block 过程中用户希望改变框内主体的展示，变灰加字进度条都有可能需要
d)失败场景可能的需求有：框仍然消失 /框消失并通知外部改变状态 /框保留按钮变回可点 /框保留按钮状态改变 /弹第二个 alert 框告知用户失败并组合上述任意交互等等
不管你的默认行为怎么写，总会有其他需求，诱惑你再加更多 option 和 callback
问题的根源可能在于你没想清楚自己的组件的边界在哪里。我能猜到加这个 wait 的机制能满足你多数的需求，提高你的效率，但放到开源组件里，这个选项满足别人一半的需求，逼迫别人要么魔改 hack 要么不用，就是“不好用”的组件了

总体还行，挑些毛病的话：

已经 promise 和 async await 都上了还用 wait 这样的回调参数来做“后续干啥”，甚至这个回调参数里还有个 next callback 看着难受

活动页弹个窗这种小事还带上 vue 难受