个人认为没有必要。

无线耳机如果用蓝牙的话，带宽一般不够你听无损。但这个对音质的影响，都不如降噪模块的影响大。

你可以先用转接头或者便宜的小尾巴试试看能不能推动你的有线耳机。如果听不出来什么明显改善，那就带着耳机去店里试试人家的便携耳放。一般你用自供电的便携耳放能极大程度上改善听感。

但这玩意远比你用无线耳机累赘的多。

那个应该叫“DAC”。
简单地说，只是做个数字到模拟信号的转换。但通常需要带点功率放大器的功能，不然如果你耳机阻抗比较大，可能带不起来。

便宜的，随便找个转接头就行。比如苹果之前送的 Lightening 转换头，或者其他手机送的那些。

更贵一些的“小尾巴”，都是带有更好的耳机放大器功能。比如支持更纯净，更强的信号放大，更好的信噪比等等。

但恕我直言，如果你的耳机没那么好，那随便找个就行了。
而且就算几百上千的“小尾巴”，可能也没有很多人想象的那种“一耳朵区别”。真想要音质好一些好，还是要独立的耳放才行。整个系统里都不能有太明显的短板，最终声音才能好。

你可以问问看他们平时喝什么酒，照着香型买好点的就是了。

或者你就直接对应的口粮酒买一箱。

@nleg 个人意见，如果你想在数据库内设置一个字段用来控制到 ES 的同步，那么这个字段最好不要每次同步完就改，不然这些都是额外的 IO ，毫无意义。
特别是当你 ES 的索引有问题，你需要恢复状态或者全量同步的时候，你这么搞就完全做不了了。

你这数据量如果不涉及删除的话，只要增加个 update datetime 字段就行。如果修改也不要，那就 create datetime 就够了。
每次启动的时候，ES 里面找个最大的 datetime ，然后从 mongodb 里面找所有比他大的 document ，分批拉回来就行。

这样你不管差多少数据都能同步回来，控制好批量查询和插入的速度就行了。也不用在乎什么 oplog 或者 change stream 。

“坚持运动” 就可以一直坚持下去的。

我通常会撸铁，三分化练三休一。但如果天气好或者朋友约，就会替换成户外骑行。或者有的时候也换成跑步爬楼。如果觉得今天状态不好，那就换成低强度有氧，椭圆机或者简单骑骑车。状态再差的话，就出门散散步或者做点拉伸活动一下。

除了生病发烧，基本每天都会活动活动。

不要给自己上太大的压力，也别给自己设定特别高的及格线。运动贵在坚持，只有适合自己强度的才能坚持下去。你天天 996 ，半夜下班还撸铁一小时或者跑个半马。或者加完班了还要冲个 PR ，光是想想就坚持不下来。

MongoDB 有 Change Stream ，你可以理解为 bin log 。实际上是一部分的 oplog 。

他有个 token ，你可以拿到从这个 token 以后的所有数据库变更。

但实际上是基于 oplog 的，你如果太长时间没同步，或者那个 oplog 设置很少，操作太多的话可能就给顶掉了。如果你数据的变更不太多，或者你可以大部分时间实时同步下来，那就没问题。

也有很多方案是基于全量扫描然后自己找变更的，你如果数据量不太大倒还行，数据量大了这么搞相当于增加了额外的负担。

或者你数据库本身设计的很好，每个记录都有变更时间，那你每次只刷上次变更以后的就行，比刷那个 change stream 还要靠谱一些。只是删除需要额外处理，比如并不真的删除数据，而是给个 flag ，或者移到另一个 collection 里，那用这个方法倒也能同步了。

@jadec0der 那这个成本应该就上天了。。。


@Xusually 一楼就改了

更正，是 365 天里，在这 737 的机体中门上，发现了 392 个问题。。。。

@connor123 因为全程票是优先发售的。

本质上是高峰期运力不足，如果长短乘同概率发售，那么长途旅客永远别想回家了。毕竟你一个全程 10 站的路线，只要有人买了一站，那就要有一个全程旅客回不了家。那么如果按照运力资源收费的话，占用了全程资源收个全程票也合理啊。

之前也有乘务说过，买长乘短的骂他们想多赚钱，中途上车补票的骂他们不拦着短途旅客，他们全程票买不到。
横竖都是有骂的，很多时候全看你屁股坐在哪里。你觉得你买不到短程票是不公平，长途旅客也觉得他们这种长程旅途本来就难，经常抢不到也不公平。虽说我回家就是短途，现在已经很难买到票了，但我也不觉得这不合理，毕竟那些走全程的回趟家比我更难。

所以出了候补，你短途的挂着排队，有资源了先来后到，已经是现在这种状况下最合理的解决方案了，至少我想不到更好的办法。

@connor123 12306 的候补并没有加价吧？

FlashPad
http://www.haoxg.net/tools.html#flashpad

3M 的小工具，可以代替 notepad 随手记点什么。
单文件，纯绿色版，官网有代码。

不过这就是个简单的记录工具，不支持 markdown ，也不支持滚轮字体缩放等功能。

@worldqiuzhi 只有 2016 支持 docker 又不支持 wsl ，但它也是 hyper v isolation 。还不如你 hyper v 里开个 Linux 虚拟机。

对于一个商业产品来说，“成本”并不只有开发和运行成本，也要包括审计合规，法务，数据保护等等。

而 auth 这东西就属于，你不能没有，开发起来难度也不高，但合规处理非常麻烦，想要防御针对性攻击更加麻烦，同时也不是核心的业务数据资产。
对于大多数业务模型来说，用户这东西只要是个唯一 ID 就行了，至于他叫什么名字，用什么邮箱并不是很重要。

而合规这玩意，不同国家地区的法律并不相同。虽说很多时候你的业务数据可能也算需要做合规审计的用户数据，但 auth 里面的东西一定是要做合规的。

对于一个风险很高，法务处理很麻烦，又不是很重要的东西，最好的选择自然就是外包了。
让第三方去提供各种合规审计，各种防护措施。远比你雇一整个团队去做更省成本。

没意义，Redis 本身不支持 Windows ，你装它还要用 WSL ，那就不如直接 WSL 里跑 Docker ，然后其它的全用 Docker 部署了。

如果你用的是 Redis for windows 等等的第三方版本，你可以把你所有依赖的安装包收集好，然后写个脚本挨个调用解压或者安装就行了。

更麻烦的，你自己做个大的 msi 。Windows 支持很多安装部署功能，msi 可以做到非常复杂的多组件依赖处理。就看你要不要做了。

@BeautifulSoap 同意。叫不叫 DDD 无所谓，只要比现在一锅粥的架构强，那就有实践的价值。

很多东西完全按理论走结果肯定是最好的，但成本也不一定是所有人都能接受的。包括开发成本，人员的培训成本，PM 和客户的额外沟通成本等。

比如 Restful 设计，很少会完全按照它来设计 API 。但它的思想是好的，借用到项目里能有改善，那就值得去学习和尝试。

没事，800 顶多爆玻璃，不至于掉门的。
一般来说玻璃窗爆炸还不至于停飞，除非设计上有问题，但那就不会只炸这一次了。
https://www.channelnewsasia.com/asia/japan-all-nippon-airways-flight-1182-boeing-737-cockpit-window-crack-4045796