《TCP是怎样工作的》

书中有三个作者,其中主要的作者安永辽真写的是主要部分(《第4章 程序员必学的拥塞控制算法》)。还有两章(《第5章 CUBIC算法》和《第六章 BBR算法)写的是现在比较流行的阻塞控制算法。所以书名应该叫《拥塞控制是怎样工作的》。

图3.8 窗口控制、流量控制和拥塞控制之间的关系
图4.3 拥塞控制算法的状态迁移图
图4.4 本书介绍的拥塞控制算法
图6.2 端到端时延的构成

初期的以太网在逻辑上是“总线式”结构。换句话说,多台计算机是连接在同一根同轴线缆上的。在这种情况下,由任意一台终端设备发送出的数据可以被所有连接在这个网络上的计算机接收。也就是说,这个网络从原理上就无法进行一对一通信,所有的通信都是广播式的。
然后,所有已连接的设备共享同一个通信介质,一旦多台终端设备同时发送数据,就会发生信号冲突,导致数据丢失。发生冲突的范围称为冲突域(collision domain)。因此,当有多台终端想要发送数据时,需要按顺序来发送。实现这一功能的就是 CSMA/CD ( Carrier Sense Multiple Accesswith Collision Detection,带有冲突检测的载波侦听多路访问),这项技术也被认为是以太网的代表名片。

1984年的 Congestion Control in IP/TCP Internetworks(IP/TCP 互联网上的拥塞控制,RFC 896)中提出了 Nagle 算法,其目的是减少 TCPIP网络上待发送数据包的数量。可以肯定地说,Nagle 算法是一切为了防止TCP/P 网络出现拥塞崩溃而进行的拥塞控制相关技术的“鼻祖”。

介绍几个基本的拥塞控制算法,它们的思路是通过灵活运用以下几种算法,对拥塞窗口大小 cwnd 进行控制。
• 慢启动
• 拥塞避免
• 快速恢复

当出现以下两种情形时,便可以认为TCP报文段丢失了。
•重传计时器超时
• 收到多个重复的ACK

从通信数据包发送到接收为止的端到端的时延,主要由以下三部分组成:因链路上的交换机和路由器进行数据包处理而产生的处理时延(processing delay);因在链路上各个节点的队列中等待传输而产生的队列时延(queuing delay);从信号发送节点到目的地节点所需要的物理上的传播时延(propagation delay )。

在三大时延中,处理时延和队列时延可以通过提高通信节点的性能实现进一步的优化,而传播时延则只取决于传输距离。
因此,超远程节点间的通信往往无法忽视物理特性所导致的传播时延。例如,横跨太平洋的海底光缆,其传播时延超过50 ms。
此类宽带、高时延的通信环境就被称长肥管道。

在发生丢包之前,缓慢地增大拥塞窗口大小(additive increase,加法增大),拥塞发生之后,大幅減小拥塞窗口大小(multiplicative decrease,乘法减小),这便是 AIMD 控制算法。

《设计模式之禅(第2版)》

书里文字错误太多了

世界上最难的事有两件:一是让人心甘情愿地把钱掏出来给你,二是把自己的思想灌输到别人的脑子里。

对于单一职责原则,我的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。

里氏替换原则为良好的继承定义了一个规范,一句简单的定义包含了4层含义。
1.子类必须完全实现父类的方法
2.子类可以有自己的个性
3.覆盖或实现父类的方法时输入参数可以被放大
4.覆写或实现父类的方法时输出结果可以被缩小

狙击手,为什么叫Snipper?Snipe翻译过来就是鹬,就是“鹬蚌相争,渔人得利”中的那只鸟,英国贵族到印度打猎,发现这个鹬很聪明,人一靠近就飞走了,没办法就开始伪装、远程精准射击,于是乎Snipper就诞生了。

子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。

证明一个定理是否正确,有两种常用的方法:一种是根据提出的论题,经过一番论证,推出和定理相同的结论,这是顺推证法;还有一种是首先假设提出的命题是伪命题,然后推导出一个荒谬、与已知条件互斥的结论,这是反证法。

注意 在Java中,只要定义变量就必然要有类型,一个变量可以有两种类型:表面类型和实际类型,表面类型是在定义的时候赋予的类型,实际类型是对象的类型,如zhangSan的表面类型是IDriver,实际类型是Driver。

人和人之间是有距离的,太远关系逐渐疏远,最终形同陌路;太近就相互刺伤。对朋友关系描述最贴切的故事就是:两只刺猬取暖,太远取不到暖,太近刺伤了对方,必须保持一个既能取暖又不刺伤对方的距离。

不知道大家有没有听过这样一个理论:“任何两个素不相识的人中间最多只隔着6个人,即只通过6个人就可以将他们联系在一起”,这就是著名的“六度分隔理论”。

Single Responsibility Principle:单一职责原则Open Closed Principle:开闭原则Liskov Substitution Principle:里氏替换原则Law of Demeter:迪米特法则Interface Segregation Principle:接口隔离原则Dependence Inversion Principle:依赖倒置原则把这6个原则的首字母(里氏替换原则和迪米特法则的首字母重复,只取一个)联合起来就是SOLID(solid,稳定的),其代表的含义也就是把这6个原则结合使用的好处:建立稳定、灵活、健壮的设计,而开闭原则又是重中之重,是最基础的原则,是其他5大原则的精神领袖。

有一个对象UserInfo存储用户的所有信息(实际系统上还有很多子类,不多说了),也就是BO(Business Object,业务对象),这个对象设计为贫血对象(Thin Business Object),不需要存储状态以及相关的关系,本人是反对使用充血对象(Rich Business Object),这里提到两个名词:贫血对象和充血对象,这两个名词很简单,在领域模型中分别叫做贫血领域模型和充血领域模型,有什么区别呢?一个对象如果不存储实体状态以及对象之间的关系,该对象就叫做贫血对象,对应的领域模型就是贫血领域模型,有实体状态和对象关系的模型就是充血领域模型。

对象适配器和类适配器的区别是:类适配器是类间继承,对象适配器是对象的合成关系,也可以说是类的关联关系,这是两者的根本区别。

组合模式有两种不同的实现:透明模式和安全模式。

在这里我们使用了一个新的设计方法:双接口设计,我们的一个类可以实现多个接口,在系统设计时,如果考虑对象的安全问题,则可以提供两个接口,一个是业务的正常接口,实现必要的业务逻辑,叫做宽接口;另外一个接口是一个空接口,什么方法都没有,其目的是提供给子系统外的模块访问,比如容器对象,这个叫做窄接口,由于窄接口中没有提供任何操纵数据的方法,因此相对来说比较安全。

说到访问者模式就不得不提一下双分派(double dispatch)问题,什么是双分派呢?我们先来解释一下什么是单分派(singledispatch)和多分派(multiple dispatch),单分派语言处理一个操作是根据请求者的名称和接收到的参数决定的,在Java中有静态绑定和动态绑定之说,它的实现是依据重载(overload)和覆写(override)实现的。
双分派意味着得到执行的操作决定于请求的种类和两个接收者的类型,它是多分派的一个特例。从这里也可以看到Java是一个支持双分派的单分派语言。

《平面国》

神作

书中是挺有贬低女性的意味,可能是维多利亚时期的关系。

从他身上吸取教训吧:自满就是丑恶和无知,渴望和抱负比蒙昧无力的快乐好得多。

向上,而不是向北。

那位圆形曾说,先知和获得天启之人总是被大众看作疯子。

若从科学技术上看,今天的世界自然比维多利亚时代的世界进步了很多。但是在其他层面上,我们是否真如我们想象的那么先进?
男性是否已经停止用“双重语言”和“双重思维” 欺骗女性?
特权阶级留给普通人的上升通道是否仍然只是允许等腰三角形变等边三角形的统治艺术?
网络真的让我们接触更多信息、鼓励我们思考了吗?还是恰恰相反,科技允许我们制作出巨大的泡泡,每天生活于其中,只与和自己观点相近的人交流?若是后者,这种所谓的“交流”与点国国王的自言自语有何不同?
我们有时觉得和自己观点不同的人低等、愚昧、不可理喻,有时只想大声咆哮、堵住别人的嘴。那样的我们是固步自封的直线国国王?还是恼羞成怒的球?
理性和求知是人类最高贵的品质。我相信, 今日世界中许多令人痛心的东西——比如分歧和对立——都不是绝症。真正能对人类造成“降维打击” 的,只有愚昧和封闭。正因如此,我们永远不应放弃思考和探索。任何一种“信仰”或“价值观”都不该成为闭目塞听、阻碍思辨的封印。
愿探索能拓宽我们的想象。愿对更高维度的渴望和追求能引领我们飞向更高的地方。

“立体人,你们是比我更高级的物种,
愿探索能拓宽你们的想象,
并孕育出最罕见、最卓越的美德—谦虚。”
——正方形

《一生何求》

《一生何求》一个家族四代人的命运狂想曲

《风雨大作》主人公毕富海。
《余生之恋》主人公毕富海儿子毕文荣。
《世界上最后一个女人》主人公毕文荣女儿毕秋杨
《大雪之下》主人公毕秋杨儿子杨意夫。
《杀夫》主人公卢琪珍,本名陈琪珍。在《余生之恋》中由陈余生和胡蕙心所生。两岁时突发高烧,由其父战友卢江海代为抚养。后怕受其父国民党飞行员身份的影响,故改名卢琪珍。

人活着,就要在不可能里相信一点可能。

《霸王别姬》

本书收录《霸王别姬》《锅炉工的妻子》两部剧作

任何一种真正意义上的英雄,都敢于战胜或是藐视不是一切也是大部分既定的法则。彻底的蔑视和战胜是不可能的,所以彻底的英雄也是不存在的。项羽有项羽的不彻底处,司马迁有司马迁的不彻底处。一般的人,通体都被链条捆绑,所以敢于蔑视成法就是通往英雄之路的第一步。

欣赏奇才,爱听奇人奇事,是人类好奇天性的表现。而当今之道德社会,树了那么多的碑,垒了那么多的墙,派了那么多的岗,安了那么多的哨,目的实际很简单:防止人类好奇。所以从某种意义上来说,所有的社会,对人类的好奇天性都是一种桎梏。当然这是没有办法的事。

《面向对象是怎样工作的》

第7-12章好像和面向对象没多大关系,内容也有点水了。

第13章(函数式语言是怎样工作的)写的不错。

面向对象的起源可以追溯到挪威的两名技术人员在1967年开发的 Simula 67 编程语言。之后,任职于美国施乐公司的艾伦•凯率领的团队开发了 Smaltalk,沿用了 Simula 67 语言的结构,确立了面向对象的概念。除此之外,凯在 IT领域还做出了很多贡献,比如开发出图形用户界面(Graphical User Interface,GUI提出作为现代笔记本电脑原型的“DynaBook设想”等。
“预测未来最好的方法就是创造它。”(The best way to predictthe future is to invent it.)据说这句名言是公司高层追问研究内容的未来走向时,凯给出的回答。想必也只有提出了诸多创新性的技术概念的凯,才能讲出这样的名言吧。

NODM 由网络(Network)、开源(Open source)、小型化(Down-sizing)和多媒体(MultiMedia)这4个单词的首字母组成“,该词在日本20世纪 90年代前半期的 IT领域广为流行。不过,随着互联网的普及,NODM 所代指的技术都逐渐成了通用技术,因此该词自然也就不再被使用了。

好莱坞原则一词可以用来表示这种框架结构的特征。在好菜坞,电影制作者对演员说“Don't call us, we will call you”(不要给我们打电话,我们会给你打电话)。

《敏捷整洁之道》

这些管理方法之所以如此失败,是因为使用它们的管理人员不理解软件项目的基本原理。这一原理被称为项目管理的铁十字,约束着所有项目必须做出权衡,无法突破。
质量、速度、成本、完成,你只能任选3个,没法4个全要。可以要求高质量、快速、低成本,这样的话项目就做不完。也可以要求低成本、快速地完成项目,那样的话质量一定不会好。

布鲁克斯定律'指出:为延迟的项目增加人手反而会使它更加延迟。

一种非常适用于大型任务的技术是三元估算。这种估算由3个数组成,这3个数分别对应最佳情况、正常情况和最坏情况。这些数都是对信心的估计:最坏情况是指你有95%的信心认为能完成该任务的时间,正常情况仅具有50%的信心,最佳情况仅具有5%的信心。

故事遵循一组简单的指导原则,这组原则的首字母缩写是 INVEST。
•|:独立(Independent)。用户故事彼此互相独立。这意味着在实现它们时不必遵守特定的顺序。例如登录不是必须在退出之前实现。
• N:可协商(Negotiable)。这是我们不在卡片上写下所有细节的另一个原因:我们希望开发人员和业务人员之间可以就这些细节进行协商。
• V:有价值(Valuable)。用户故事必须对业务具有明确且可量化的价值。
• E:可估算(Estimable)。用户故事必须足够具体,以允许开发人员进行估算。
• S:小(Small)。用户故事不应大于一到两个开发人员可以在一个选代中实现的工作量。
• T:可测试(Testable)。业务部门应该能够提出用户故事的测试标准,通过这些测试就能表明用户故事己经完成。

TDD 可以描述为以下3条简单的规则。
• 先编写一个因为缺乏生产代码而失败的测试,然后才能编写生产代码。
• 只允许编写一个刚好失败的测试——编译失败也算。
• 只允许编写刚好能使当前失败测试通过的生产代码。

肯特•贝克很久以前就提出了敏捷的4个价值观:勇气、沟通、反馈和简单。

人使用和控制工具,不能让工具控制和使用人。

分解、合并和穿刺
合并故事很简单。你可以将几张故事卡夹在一起,把它们当作一个故事对待,只需将所有故事点相加即可。
拆分故事会更有趣,因为你需要保持故事的 INVEST 原则。
穿刺是一个元故事,或者叫“用于估算故事的故事”。之所以称为穿刺,是因为我们经常需要开发一个长而很薄的切片,来打穿系统的所有层。

QA病
然而,这还不是最糟糕的。把QA工作放在流程的尾端还会带来更糟糕的问题。如果QA处于流程尾端,组织如何知道他们是否做好了自己的工作?很简单,看他们能发现多少缺陷。如果 QA 发现了很多缺陷,他们显然做得很好,QA 经理可以吹嘘自己团队发现了多少缺陷,以此作为 QA 团队尽职尽责的明确证据。
于是,发现缺陷被认为是好事。
还有谁能从这些缺陷中获益呢?老程序员有这样的说法:“你可以给我设定任何交货期限,只要别要求软件正常工作就行。”还有其他人能从缺陷中获益吗?那就是那些需要去满足交货最后期限的开发人员。
什么话都不用说,什么协议都不用写,双方都明白,他们都能从缺陷中受益。一个缺陷的“黑市经济”出现了。这种“疾病”渗透到许多组织中,哪怕暂时还不致命,这种“疾病”毫无疑问使组织逐渐虚弱。

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

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

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

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

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

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

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

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

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

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