在豆瓣上搜索这本书没有找到
原来这本《微信读书》上的书没有出版，自然也没有ISBN，所以并没有在豆瓣上查到

感觉不像是程序员，倒像是产品经理，还是偏算法端的
书中人物臧叔有点像刘润采访过的“网约车教父”臧勤
作者非常喜欢高度地图和享快打车这两款APP

全书出现最多的一句话：“一切都是最好的安排”
充满着互联网黑话，错别字有点多
最后的结尾也太突然了

这套跑车背后的逻辑就是必须要形成接单闭环。

什么样的预约单或者首单算得上是个好单？我的答案是离家近、开得快、金额高、连环单。

有的人出生在罗马，有的人一生在通往罗马的路上。

确实从概率上来讲，不顺是必然，太顺只是偶然。

心中若有阳光，窗外便是灿烂。

只有脑力的方向正确了，体力的拼搏才会有价值。

从解决问题的角度讲设计模式非常好，特别是两个解决统一问题的设计模式一起讲。

有一个小错误：P67 setUp()写成了steUp()

敏捷宣言
我们一直在实践中揭示更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下价值观：
个体和互动 优先于 流程和工具
工作的软件 优先于 详尽的文档
客户合作 优先于 合同谈判
响应变化 优先于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。

面向对象设计的原则
SRP 单一职责原则 就一个类而言，应该有且仅有一个引起它变化的原因。
OCP 开放-封闭原则 软件实体（类、模块和函数等）应可以扩展，但不可修改。
LSP 里氏替换原则 子类型必须能替换掉它们的基本类型。
ISP 接口隔离原则 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
DIP 依赖倒置原则 抽象不应该依赖于细节。细节应该依赖于抽象。
REP 重用发布等价原则 重用的粒度就是发布的粒度。
CCP 共同重用原则 一个包中的所有类应该是共同重用的。如果重用包中的一个类，那么就要重用包中的所有类。相互之间没有紧密联系的类不应该在同一个包中。
CRP 共同封闭原则 一个包中所有的类对同一类性质的变化应该是共同封闭的。一个变化若对一个包有影响，就会影响到包中所有的类，但不会影响到其他的包造成任何影响。
ADP 无依赖原则 在包的依赖关系中不允许存在环。细节不应该有其他依赖关系。
SDP 稳定依赖原则 朝着稳定的方向进行依赖。
SAP 稳定抽象原则 一个包的抽象程度应该和其他的保持一致。

很多团队迷失在追求文档而非软件上。这通常是个巨大的错误。有条简单的规则称为“文档的马丁第一原则”，意在防止此类错误发生：
除非文档紧急且重要，否则不要写。

“大千世界，唯一稀缺的是人类的注意力。”——凯文·凯利（KK）

每个软件模块都有三项职责。第一项职责是运行所完成的功能。这是该模块得以存在的原因。第二项职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能简单。一个难以改变的模块是拙劣的，即便能够工作，也需要对它进行修正。第三项职责是要和读的人沟通。对该模块不熟悉的开发人员应该能够轻松地阅读并理解它。一个不能沟通的模块也是拙劣的，同样需要对它进行修正。

在 SRP 的语境中，我们把职责定义为“变化的原因”（a reason for change）。如果你有超过一个的动机去改变一个类，那么这个类就具有多种职责。有时，我们很难注意到这一点。我们习惯于以组（group）的形式去考虑职责。

许多开发人员可能会对“合理假设”的行为这一概念惴惴不安。怎样才能知道客户真正的要求呢？有一种技术可以让这些合理的假设明确下来，从而支持LSP。这种技术就是基于契约的设计（Design By Contract, DBC）。梅耶（Bertrand Meyer）对此做过阐述［Meyer1978, p.331］。
使用 DBC，类的作者明确表达出对于这个类的契约。客户端的代码可以通过契约获悉可以依赖的行为方式。契约是通过为每一个方法声明前置条件（precondition）和后置条件（postcondition）来制定的。要让一个方法得以执行，前置条件必须为真。执行完毕后，这个方法要保证后置条件为真。
按照梅耶（Meyer）的阐述，派生类的前置条件和后置条件的规则如下：
在重新声明派生类中的方法（routine，例程）时，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的后置条件。［Meyer97,p.573］
换句话说，当通过基类的接口使用对象时，用户只知道基类的前置条件和后置条件。
因此，派生类对象不能期望这些用户遵从比基类更强的前置条件。也就是说，他们必须接受基类可以接受的一切。同时，派生类必须和基类的所有后置条件一致。也就是说，它们的行为方式和输出不能违反基类已经确立的任何限制。基类的用户不能被派生类的输出干扰。

包的设计原则
粒度：包的内聚性原则
重用发布等价原则（REP）
可以复用的粒度就是可以发布的粒度。
共同重用原则（CRP）
在包中的类可以一起被复用。如果你复用包中的某一个类，那么就要复用包中的
所有类。
共同封闭原则（CCP）
一个包中的类对于同一类型的变化应该是共同封闭的。对于一个包的更改会影响
到该包中的所有类，而不会影响到其他包。
稳定性：包耦合性的原则
无环依赖原则（ADP）
包之间的依赖关系图中不应该存在环形。
稳定依赖原则（SDP）
向着稳定的方向依赖。
稳定抽象原则（SAP）
包的抽象程度应该和其稳定程度一致。

书中两篇姐妹篇《台风来了》和《转学》写得不错，很是感动

命运就是我们跑出来的路。

我知道的，所有的去处，终究是我们的来处。

我们的思维方式即可归总于是——美并非在于物体，而在于物体与物体相合而生的阴翳之浓淡明暗。

元宇宙商业之父马修·鲍尔的著作，有关元宇宙的历史，还有八大元宇宙元素。

元宇宙还比较像游戏，不管是技术、引擎、网络，还是内容、互动。

“新IT”智能技术（Inteligent Technology），是“旧IT”信息技术（Information Technology）和“老IT”工业技术（Industrial Technology）的升级和升华。“老”“旧”“新”三种IT技术将融汇起来，开发我们面临的波普尔的“三个世界”；物理世界，以老IT工业技术为主；心理世界，以旧IT信息技术为主；人工世界，以新IT智能技术为主。

技术转型之所以难以预测，就在于它不是由任何一项发明、创新或个人推动的，而是许多变化共同作用的结果。

我在写作和讨论有关元宇宙的内容时，对元字宙的定义是：大规模、可互操作的网络，能够实时渲染3D 虚拟世界，借助大量连续性数据，如身份、历史、权利、对象、通信和支付等，可以让无限数量的用户体验实时同步和持续有效的在场感。

在“应用内购买”方面，苹果创建了三大类交易模式。第一类是针对实物产品的交易，例如用户从亚马逊购买多芬香皂或加载星巴克礼品卡。在这类交易中，苹果不收取任何佣金，甚至允许这些应用程序直接使用第三方支付渠道（比如 PayPal 或 Visa）来完成交易。第二类是针对所谓的阅读器应用程序的交易，其中包括捆绑非交易内容的服务（比如随心享用的奈飞、《纽约时报》、Spotify 订阅），或者允许用户访问他们之前购买的内容，例如一部之前从亚马逊网站上购买，但现在想在亚马逊的 Prime Video iOS 应用上播放的电影。第三类是针对交互式应用程序的交易，用户可以对其内容产生影响（比如在游戏中或云驱动器中产生影响）或对数字内容进行单独交易（例如在 Prime Video 应用程序上租赁或购买一部电影），这些应用程序只提供应用内计费选项。

根据“去中心化”资产具有“中心化”依赖性这一事实，我们可以得出两个主要结论。
第一个结论是，NFT 是无用的，伴随它的是欺诈、猜测和误解。
第二个结论是区块链对于元字宙的重要性。