@patrickyoung https://feifeijin.github.io/ 目前都和日本相关，希望可以产生共鸣。

@davidqw 快去，说不定那天就闭店了。

我最爱的 Jazz Bar 就突然闭店，都没来得及去闭店 Party 。

@cloudzhou
我倒还好，其实我蛮开心的，有人说我写的像 AI 。

因为我现在最想听到对我手写代码工作的评价：你这个代码怎么写得像 AI ？我的老天爷，要是能听到这一句，我真的觉得这不是批判，而是一种至高无上的评价。

@gaoryrt 很喜欢你这个评论，就像是遇到了知音。

Boring Fact：op 昆明人，昆明有一个因此而建立的藤泽友谊馆，小时候也去参加过活动。

这个豆知识，非常少人知道，无论是昆明人还是藤泽人，所以现在会有一种宿命感，就是这个地方是等待着我住过来。

其他更 Fun 的 Fact ，下一篇也会展开一下下。

@lear7 宝，我扣着屁眼指着天发誓。
我唯一用 AI 的有两个地方：
一个是在想紫禁城和和他类似的牢笼时的一个对比手法， 我询问 AI 该用什么东西合适。

二个是，全文写完后让它去给我找错别字，我修正了一些，但现在读的时候发现还有。

最后：如果你要证据的话，我不会提供。因为那时候“要的不是真相，是肠子。”

还有我真的是真情实感码的字，若您感觉是机器人，那实在抱歉给您带去了不好的阅读体验。

@ccctttwww
@googlehub
@guanhui07

没有回国，短期也不打算回国，如果真的回也是以数字游民方式短居。

@zackkk
也想要探讨的一个问题，是东京这样？还是其实，背井离乡去到城市都这样。

会有一种孤独的疏离感，因为很多时候，自己想要逃离因为“东京”所以“梳理”这个框架去想问题。

所以才会有想到那些本身就是日本人，但是从各个地方上京后的体验，得去找点上京后的日本人聊聊天。

@agriphar 表面是孤独，其实孤独也是一种选择。


@fyzq 钱只是一部分很少的原因，更多的是对城市的倦怠。

@iamsk 下一篇杂谈里会讲到，远离城市后的生活愿景，希望还能继续阅读。

@river010 在日本腌入味了，会主动把“我”隐藏掉。

@Dispatcher Sorry ，还要继续使用呢。

@ajaxfunction
A7R4a

@xxxxxyz
云南人，小润润出省、大润润出国、终润润回家。
但不经历前面两润，也不会领悟最后一步。
笑死，都说山顶见，结果一共就抵达雪场见一面，午饭偶遇一面，最后集合一面。

@dumbass 那你一定要去 Blue Note Tokyo ，东京我第二爱的 Jazz Bar ，第一爱的闭店了。
《 Blue Giant 》非常地写实，它里面的 Blue Soul 就是结合东京 Blue Note 和 Body&Soul 两家店的名字。

@orion1 还想再继续待在日本一阵子。

@ShiBuYi
@ZettarYuFan
@KeeIan

其实是标题党，从东京搬家到隔壁神奈川乡下，人倒是还在日本，其实类似于从深圳南山桃园搬家到惠州。

然后分享一个有趣但无用的知识：第八章的作者是 Gay 。


看《 DDIA 》,刚打开第八章看到引言作者名字后面跟着 Carly Rae Jepen 。我心想“大事不妙啊，蹲妹都蹲到我专业领域来了吗？”。于是把整个部分放到 google ，然后发现讲这句话的人现在穿着 leather 参加 pride ，倒也没震惊我一百年，不过下次再有人问不写代码去做什么的时候，我就把此人 Twitter 给甩过去，看！这就是本人的商业转型！

DDIA 是一本绝对意义的好书，分享看第一版时的一些笔记。

#读书感悟/DesigningDataIntensiveApplication
第一章围绕构建系统的三个原则，
- Reliability
- Scalability
- Maintainability
工作超过五年，只要稍微看过几本关于分布式系统、微服务或 DDD 方面的书的话，对这些东西早已经滚瓜烂熟。这一章不过是把一些散落在天涯的知识进行归纳而已。如果是刚毕业读这本书必然从这里开始便能醍醐灌顶，但对于工作十年以上的老油条而言，但凡你经历过上线即宕机、负载过大仿佛被 DDoS 以及堆积如屎山的技术债，那么这章不过是在简单描述你经历过的惨事罢了。
不过里面提到两个例子还蛮有趣的，
- 一个是 Twitter 的信息流，从每次刷新 timeline 的时候去即时读取数据，转变为有人发 Twitter 就往粉丝的 timeline 里主动插入数据，把读的压力转换为写的压力。
- 另外是 Amazon 对于服务的 p99 ，致力于满足 99%的客户。动机很有趣，因为正是那 1 ％的客户使用频次高，他们才是核心用户。



#读书感悟/DesigningDataIntensiveApplication
第二章则是宽泛地介绍了数据库类型与选择。
- 关系型数据库 (MySQL, PostgreSQL, etc.)
- 文档型数据库 (MongoDB)
- 图数据库(Neo4J)
Data models 旨在去思考我们想要解决的问题，而不仅仅是数据如何在软件中存储。在现代化的编程模型中，细节都一层层的被隐藏了，比如对于我这个时代而言 DataLog 是所有数据库模型基础，也是今天才知道。对于下一代使用 Ai 或 No-Code 的人而言，他们可能连数据模型都不需要知道，这些复杂的行为可以被 in-advanced 语言所隐藏。
在现代编程思想里，万物皆可对象化，则万物皆可关系数据库化。不过世上没有银弹，应该在合适的场景下选择合适的数据库。
- 一对多，且只有 writen 时，NoSQL 是最优解，例如聊天记录。
- 多对多，以及超级复杂的数据模型时，Graphic Database 。比如社交网络关系，Page Ranking 。
- 其余读写频繁，且关系不复杂基本可以用 Relational Databse 。
本章宽泛地介绍了数据库基本选型，值得赞美是它并未陷入细节里，比如 MySQL 数据的存储方式、索引规则等等。它简洁明了地介绍 了各种数据库的使用场景，让你知道何时该选择什么样的数据库，也简述了数据库的发展发展历史。
从业这么些年，每次接触一个新系统，其实只要弄清楚它的数据流向，那么这个系统也就手到擒来，说到底。Information System 的根本还是围绕数据的上下游进行各种处理。


#读书感悟/DesigningDataIntensiveApplication
第三章主题是数据在内存和硬盘里的存储和获取。
对于 2010 年代后进入编程行业的程序员，数据库的存储细节也被现代化的数据库隐藏起来。从业良久，没有认真地去思考过数据的错处方式和细节，现在的感受就是：作为行业人员，真的好不合格。
从功能性出发分为两类：
- OLTP ，面向用户的数据库，写入大于读取，传统开发人员使用频次最高的数据库，几乎所有的关系性数据库都是 OLTP 。
- OLAP ，面向的用户是数据分析师，转精于大体量的数据查询。但凡是开发人员（数据工程师除外）使用较少的数据库，几乎都是 OLAP 。
数据最终是以文件形式持久化存储于磁盘的，这对于容灾备份、快速复制和数据恢复及节省成本都是有益的，而如何让数据快速的存储和读取则是我们需要考虑的问题。这里需要建立在一个鱼与熊掌的话题上：读写不可兼得。
- Index 的引入是增加写压力而增强读能力。
- Hash Index：Key-Value Index ，检索能力可以达到 O(1)。
- SSTable：MemTable 和 compatced LSM Tree 的最佳实践。LSM Tree 设计上是 imuteable ，因此 SSTable 也多用于 NoSql ，Apache Cassandra 和 Apache HBase 。
- B-Trees：Relational Database 的 Index 的流行通用实践，MySql 、MS SQL Server 和 Oracle SQL 都是使用 B-Trees 作为索引的存储结构。B-Tree 的 key point 是它有一个 worst predictable time 是 O(LogN)。
- Red-Black-Tree：是 B-Tree 的延伸 Variant ，当下流行数据库 PostgreSql 就使用了它。
还有其它对全文检索的 fuzzy idnex 、in memory index 等。
还有介绍到 Column-Oriented Storage 、Data Cube 和 Materialized Views 。
本章进入到数据存储和读取的核心原理，几乎是最痛的痛点进行讲解，而有没有去更深入到锁、同步、如何保持读写一致性等等都技术细节里，而是站在一个刚好适宜的位置去评价市面上主流和流行的数据库，这个尺度拿捏的恰到好处，读完本章节，已经开始对此书赞不绝口了。




从第三章开始已经停不下对它的赞美。

@prosgtsr
这种就是张无忌的所有招式都忘记了。

Berluti 很喜欢这个牌子的包包。

瘦的话买 paul smith

AI 和 Agent 结合以后，已经不许要特定语言了啊。

当然，精通一门语言自然更好，但不要给自己设限。

现在更重要的是全局官和知识广度。

今天的蔡徐坤就是昨天的周杰伦
周杰伦也是以前的某某某

流行音乐的生命周期就是围绕着中学 6 年。