https://store.steampowered.com/app/1931770
锐评《巴别塔圣歌》：7/10
喜欢我语言学奥林匹克幼稚园版吗（暴言）
老少咸宜，完全没有上手难度的解谜游戏，难度设计得也很合适
题材很新颖，几种文字的设计都很巧妙也很到位不会产生令人费解或者沮丧的交互桥段
美学设计得很好
本来想给8/10，扣分主要有两点，一是笔记的画比陌生语言本身还抽象，二是潜行用鼠标操作有点让人感到脑淤血，要是设计上潜行每次被抓都稍微调快主角的速度（或者增大操作的时间窗口）就好了
锐评《巴别塔圣歌》：7/10
喜欢我语言学奥林匹克幼稚园版吗（暴言）
老少咸宜，完全没有上手难度的解谜游戏，难度设计得也很合适
题材很新颖，几种文字的设计都很巧妙也很到位不会产生令人费解或者沮丧的交互桥段
美学设计得很好
本来想给8/10，扣分主要有两点，一是笔记的画比陌生语言本身还抽象，二是潜行用鼠标操作有点让人感到脑淤血，要是设计上潜行每次被抓都稍微调快主角的速度（或者增大操作的时间窗口）就好了
Steampowered
Chants of Sennaar on Steam
In this award-winning puzzle adventure game, play as the Traveler on a quest to reunite the Peoples of the Tower. Observe, listen, and decipher ancient languages in a fascinating universe inspired by the Myth of Babel.
锐评叮咚买菜的猪肚鸡火锅预制菜：跟杭州外边餐厅的猪肚鸡味道没差，鉴定为全是预制菜。
还算好吃，汤味道也还可以（指不全是味精口感），乡思了可以买一锅，然而比起你们两广走地鸡现杀煮出来的确实味道有显著差异。
既然平安夜吃了猪肚鸡，现编一个习俗故事：传说以前有个老表很穷，到了冬至看到家家户户都在食腊鸭，饿得受不了了，许愿说：“圣誕老嘢保佑，畀我隻雞過冬至”，然而家里连只袜子都找不到了，只好把劏猪剩下的猪肚挂到速生桉上当口袋。圣诞老嘢骑鬼火路过他家门口，看到了十分感动，就塞了只鸡进去，还以为这人要按西方做法做烤鸡，于是塞了包胡椒。这人醒来后把整包料下锅炖煮，没想到煲出来的汤味道鲜香。后来就有了平安夜吃猪肚鸡的习俗。
还算好吃，汤味道也还可以（指不全是味精口感），乡思了可以买一锅，然而比起你们两广走地鸡现杀煮出来的确实味道有显著差异。
既然平安夜吃了猪肚鸡，现编一个习俗故事：传说以前有个老表很穷，到了冬至看到家家户户都在食腊鸭，饿得受不了了，许愿说：“圣誕老嘢保佑，畀我隻雞過冬至”，然而家里连只袜子都找不到了，只好把劏猪剩下的猪肚挂到速生桉上当口袋。圣诞老嘢骑鬼火路过他家门口，看到了十分感动，就塞了只鸡进去，还以为这人要按西方做法做烤鸡，于是塞了包胡椒。这人醒来后把整包料下锅炖煮，没想到煲出来的汤味道鲜香。后来就有了平安夜吃猪肚鸡的习俗。
银行系统和互联网系统最大的差别就在于对风险的厌恶，这也导致金融科技在整个计算机和网络发展历史上产生一种脱节感。连续性很重要，但所有接口无论如何都能平账，比连续性更重要。
就以某核心上线停业停一天为例，停业一整天虽然业务损失比较大，观感不好，但这是计划内的可控的风险；而如果采取一般互联网服务端惯用的双写等策略，要管理的状态就远远更多，而纯相信金融科技人员对这些状态的管理能力——会带来更多不可控的风险，而且这些风险责任就是实打实压在特定的一些科技人员头上，再闹大些，科技部门就可以吃人行银监的大罚单了。
实践上，国产化要求反而在这几年推动国内银行核心系统搞大跃进，“大跃进”这说法不是批评说信创不好，而是单纯信创方案太灵车了。玩硬件的朋友可能知道一些很灵的方案，不过银行至少还是会选择相对稳健的（kp/hygon/phytium）。
真正灵车的点反而在于软件。站在互联网开发比较前沿的视角（不要迷信国内大厂，他们只是轮子造得多，其实并不前沿）来看，国内银行科技实践上还是被外包商主导的（刚提到银行系统厌恶风险，这种情况下一些风险责任就可以转移到外包商头上），然而金融科技外包实际的研发水平并不比政务外包好太多，不会脱离培训班那套分布式Java Web+Redis+MySQL的典中典范畴。于是导致本世代所谓新一代分布式核心的技术真的很土，MySQL上分布式中间件嗯叠（某大厂），魔改Pgsql（某大厂），然后一万台pc，堆一堆k8s，美其名曰单元化治理，数个注册中心（甚至得做好几级的cache），事务整点Kafka或者火箭投递一下，Java微服务飞来飞去，只要业务在跑就不算输。
可是为什么不能用互联网那套模式呢？还是得说到风险，国内金融科技外包生态无非是在实战中积累出了强大的风险规避和特殊场景适配经验，包括但不限于：
1. 在114514家小银行积累过的记账对账流水查询组件。因为有充分的使用场景和时长，可以认为涉及到钱的根本逻辑没什么缺陷，动都不会动；
2. 水里抓只海豚训练一周都能上岗的魔改框架。此类一般是自家Web界面表单甚至Excel宏搭配XML调出来大蒜风味的史一般的DSL，然后再生成代码。这样搞，一是为自己公司构建迁移壁垒，二是用土方法、低成本构建出维护人员可替代的方案，外包今天离职，明天立刻可以来个人直接上手；
3. 适配过各种恶心场景的适配器。因为金融科技有自己的弯路，SWIFT、ISO8583、银联密钥体系、OS/400、AIX、HP-UX、COBOL……互联网向来是不太愿意处理旧史的，再怎么旧也不过SOAP XML之类罢了；但一想到SWIFT在本世纪初才从X.25切换到TCP/IP，而许多银行里头核心还跑着Z系主机上RPG语言吐出来的EBCDIC、CP935编码的定长报文，潜心研发新技术的公司哪愿意处理这些陈年意面呢？处理出来能确保自己的适配器转换正确吗？
后面想到再写
就以某核心上线停业停一天为例，停业一整天虽然业务损失比较大，观感不好，但这是计划内的可控的风险；而如果采取一般互联网服务端惯用的双写等策略，要管理的状态就远远更多，而纯相信金融科技人员对这些状态的管理能力——会带来更多不可控的风险，而且这些风险责任就是实打实压在特定的一些科技人员头上，再闹大些，科技部门就可以吃人行银监的大罚单了。
实践上，国产化要求反而在这几年推动国内银行核心系统搞大跃进，“大跃进”这说法不是批评说信创不好，而是单纯信创方案太灵车了。玩硬件的朋友可能知道一些很灵的方案，不过银行至少还是会选择相对稳健的（kp/hygon/phytium）。
真正灵车的点反而在于软件。站在互联网开发比较前沿的视角（不要迷信国内大厂，他们只是轮子造得多，其实并不前沿）来看，国内银行科技实践上还是被外包商主导的（刚提到银行系统厌恶风险，这种情况下一些风险责任就可以转移到外包商头上），然而金融科技外包实际的研发水平并不比政务外包好太多，不会脱离培训班那套分布式Java Web+Redis+MySQL的典中典范畴。于是导致本世代所谓新一代分布式核心的技术真的很土，MySQL上分布式中间件嗯叠（某大厂），魔改Pgsql（某大厂），然后一万台pc，堆一堆k8s，美其名曰单元化治理，数个注册中心（甚至得做好几级的cache），事务整点Kafka或者火箭投递一下，Java微服务飞来飞去，只要业务在跑就不算输。
可是为什么不能用互联网那套模式呢？还是得说到风险，国内金融科技外包生态无非是在实战中积累出了强大的风险规避和特殊场景适配经验，包括但不限于：
1. 在114514家小银行积累过的记账对账流水查询组件。因为有充分的使用场景和时长，可以认为涉及到钱的根本逻辑没什么缺陷，动都不会动；
2. 水里抓只海豚训练一周都能上岗的魔改框架。此类一般是自家Web界面表单甚至Excel宏搭配XML调出来大蒜风味的史一般的DSL，然后再生成代码。这样搞，一是为自己公司构建迁移壁垒，二是用土方法、低成本构建出维护人员可替代的方案，外包今天离职，明天立刻可以来个人直接上手；
3. 适配过各种恶心场景的适配器。因为金融科技有自己的弯路，SWIFT、ISO8583、银联密钥体系、OS/400、AIX、HP-UX、COBOL……互联网向来是不太愿意处理旧史的，再怎么旧也不过SOAP XML之类罢了；但一想到SWIFT在本世纪初才从X.25切换到TCP/IP，而许多银行里头核心还跑着Z系主机上RPG语言吐出来的EBCDIC、CP935编码的定长报文，潜心研发新技术的公司哪愿意处理这些陈年意面呢？处理出来能确保自己的适配器转换正确吗？
后面想到再写