Pensieve: 2405

2024-05-25 16:42

所读所观所玩

这个月书读的不算太多, 就三本. 首先是读完了上个月开始的严歌苓的芳华, 虽然还没重读过不过可以感觉这本应该挺耐重读. 这本的叙事让我想起了石黑一雄的Never let me go. 引出故事时很谨慎和收敛, 不咸不淡地讲着故事, 种种不经意间却暴露出了巨大的悖论和缺失: 这个世界中的一切都仿佛禁不起推敲. 另外, 这本可以配合不明白播客最近的一期专访来读. 第二本是马家辉的鸳鸯六七四, 这本书一样让人读起来有荒诞感, 虽然和前一本的荒诞感完全不一样. 从味觉上讲, 前一本可能是麻辣, 而这一本算是泡椒味的. 这本书的荒诞感也让我想起子弹列车. 缺点是收束得很奇怪, 仿佛是陨石遁一样. 最后一本是xkcd作者写的What if. 实话实话, 大概只能给到8分, 因为很多问题不需要他解释我大概就能猜到或推理到结论. 最后那个中子星密度的子弹挺有意思.

这个月看了两部电影和一部剧. 剧是Netflix上的蓝眼武士, 感官刺激挺重, 让我想起冰与火之歌. 电影第一部是Ocean’s Thirteen, 看了之后挺觉得不值, 剧本挺烂, 而且构思也太不精巧了, 老油条Al Pacino的表演也没怎么出彩. 另一部电影是飞驰人生2, 仍然是热血片, 知道会卖感动, 但是看完还是很感动. 它让我想起The Book of Basketball里面这段:

Our society enabled the competitor that Michael Jordan became: we value athletes who treasure winning, maximize their own potential, stay in superior shape, pump their fists, slap asses and would rather maim themselves then lose a game. … We will always love the guys who care just a little more than everyone else, just like we will always hate the ones who don’t. Why? Because we like to think that we’d play that way if we were blessed with those same gifts. Or something.

手机上原神在仆人卡池最后收尾之前又压了三十抽左右, 无事发生. 现在手上不到30颗球, 4.7/4.8准备直接跳过了. 仆人的圣遗物现在水准还是挺一般, 虽然借着氪金来的命座和专武, 伤害打得还算好. 现在的纯火队玩得有点腻了, 在考虑要不要把Candace(虽然没有6命)拉起来玩玩. 活动里面风行迷踪一开始很抗拒, 不太高兴玩, 后面多玩了几次就觉得这个活动还挺有意思了. 当游侠拿过200个修理点, 拿猎手也抓过人拿过胜利, 而且有一次好像对手随机得比较弱, 零封了对面.

Switch上王国之泪仍在继续, 第五位贤者也解锁了. 不过除了地下可以坐在机器人身上免得踩红水外好像也没什么用. 地下的Lightroot大概到80%左右了. 天空上的主要区域也探得七七八八了(没看攻略地图, 不过肯定还是有缺失的神庙就是了). 种子进展仍然很慢. 不知不觉又想拿来和荒野之息比较: 荒野之息里面爬山很有动力, 山顶的小石头底下肯定有种子; 而王国之泪里面山顶没种子不提, 不少神庙还在地下, 很难找到入口(我真很不争气地怀念原神里的分层地图了). PS上带着娃玩空洞骑士不过把自己玩进去了, 在PS上除了一些收集元素外, 该打的boss都打了, 懒得去折腾白宫和苦痛之路了. 不过这次玩的时候发现手感还是在的, 愚人斗兽场里面前两个难度没花多少重试就通过了. 另外试了下PS Plus里的几个游戏, 比如Two point hospital/Planet Coaster/Inscryption, 不过都没完全吸引我. 后面在想是不是开Ratchet & Clank: Rift Apart或者对马岛之魂.

一个算法问题: 找重复文件

一直觉得算法题对DevOps这个行当没任何意义, 因为DevOps不需要高性能. 但是我最近倒是遇到了一个比较有趣的算法问题. 问题的背景是我们有两个repo A和B, A和B中有部分go代码重复, 重复的代码都是从B中复制过来的, 即B是source of truth. 现在想把A合并到B, 在合并过程中我们不希望将重复的代码. 问怎么找到这些重复代码? 这儿有几个限制条件, 首先两个repo里的文件名可能不一样, 文件路径也可能不一样, 另外, 文件的内容也可能不完全一样, 因为A中的代码可能有滞后的情况.

如果代码的内容没有变更的话, 实际上两边都计算出一个md5的字典, 由文件名映射到校验值, 然后通过重复的校验值来做判断是不难的. 但是对于有修改的情形, 这种手段就不能使用了. 我最初的设想是以目录为单位, 按固定顺序将某个目录的所有文件全部合并成一个文件, 然后将AB两边每个可能的目录都丢给Python的difflib.SequenceMatcher来计算ratio. 后来和同事讨论, 有人建议不需要使用这样的办法, 直接在A目录中找以pb.go结尾的代码, 然后去B里面找对应的代码即可. 因为大多数情况下, 这种代码都是通过protobuf生成的. 而对于不是protobuf生成的代码, 我们直接使用文件校验值来判断就好, 如果文件校验值不一样, 应该是合并repo后使用中再来慢慢具体问题具体分析, 慢慢处理. 经验教训就是, 在实际工作中, 不要太急于建模, 兼听则明, 往往这种四两拨千斤的办法能够比抽象建模得到的结果/手段更出色.