《失业程序员日记:我在魔都跑网约车》

在豆瓣上搜索这本书没有找到
原来这本《微信读书》上的书没有出版,自然也没有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 是无用的,伴随它的是欺诈、猜测和误解。
第二个结论是区块链对于元字宙的重要性。

《ChatGPT:人类新纪元》

像读小说一样轻松的彩色科普读物

搜狗输入法之父——马占凯的第一本书

人类历史上一共发生了四次科技革命:
• 第一次科技革命,即机械革命,以蒸汽机为核心驱动要素;
• 第二次科技革命,即电力革命,以电力的应用为核心驱动要素;
• 第三次科技革命,即信息革命,以计算机和互联网的普及为核心驱动要素;
• 第四次科技革命,即智能革命,以通用人工智能为核心驱动要素。