我个人是比较反感，“工作没有什么有挑战的技术问题，因此学不到什么东西” 这种想法的。

对于工作来说，业务和技术是相辅相成的。技术并不只是单纯被动为了业务服务，也可以想办法为业务提供扩展增强的能力。

而且学习这种东西完全是你自己的事，公司没有任何义务要给你提供学习条件。

你说 “业务流程复杂”，那你有没有想过要如何整理这些复杂的流程，做出更加抽象通用化的设计？
比如使用工作流引擎抽象统一所有的流程，甚至可以做一个通用的平台，让业务自己去配置流程。
过程中可以帮助业务梳理一下流程，同时也可以也能找到流程里可以优化改进的点。

工作的目标是业务定的，但如何完成工作是你可以自己决定的。
如果只能看见眼前的工作，想着靠换工作被动学习技术的话，那等最后换不动工作的时候，就只能锁死在那家公司了。

@ASpiral 之前发过公告，优先远途旅客。个人体感是先放票的都是远程的，中间的区间票放的很少，基本开票就是候补。但这时候你直接候补，只要不是排的特别靠后，基本也能买上。应该是留了一部分专门给区间票的额度，但只是最后才放。如果实在运力不够可能就不放了。

而且今年还有个好的地方是你可以选接受增开新列车的票。选个自己期待的时间段就行。感觉应该是会后台统计，如果要增开新车的话，会优先选好票的这些人。


@3M 有的地方大雪。如果路过那边的话，始发站也会晚的。

如果你是中途的短程票，大概率能中至少一个。

短程票基本都是最后几天才放，就按你第一天候补的顺序排的。

大企业都一样的，很多 SaaS 的 Enterprise 版本卖点就是私有化部署。

其实软件的话，就两种方法
要么 hook 类的，比如 PowerToys 。但有的软件会顶掉你的 hook ，比如 mstsc 。
另外就是驱动级的，比如 https://github.com/cajhin/capsicain 这类的。虽说他们用的驱动也是签过名的，但这种非常底层的映射也有可能被某些程序视为恶意软件。


最好用的，找个支持硬件改键的键盘。有的键盘固件支持这种功能，之前大 F 的某些款甚至还带跳线开关，不过开关只能映射几个键。

自己选个方案，随便找找就行了。

个人认为没有必要。

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

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

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

那个应该叫“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 的候补并没有加价吧？