先看这么一段Scala代码：

1
2
3
4
5
6
7
8
9
10
11

object PFBlog {

  def usePF(pf: PartialFunction[Option[Int], Int]) = {
    pf(Some(11))
  }

  usePF {
    case Some(x) => x + 1
    case None => 0
  }
}

声明一个usePF方法，接受一个PartialFunction作为参数，它的实现就是传一个 Some(11) 给pf。
pf的具体类型是 PartialFunction[Option[Int], Int] 所以传递给它一个Some(11)可以期待它会返回一个Int。

然后调用usePF，传递给usePF的是一个pattern match表达式。给Some加一，给None返回0。

这时问题就来了，这个pattern match表达式是怎么能够符合usePF需要的参数类型的呢？
这么单纯的一个pattern match表达式怎么变成PartialFunction[Option[Int], Int]的呢？

为了探寻答案，先把这几行Scala代码编译成class文件，然后把byte code反编译成Java来一探究竟吧。

我们来一起看一下两个程序员之间的故事。

以下示例代码是用Scala写的，不过本文所讲的话题并不仅限于Scala，任何有Future/Promise支持的语言都是适用的。
下面这个wiki页面罗列了各个有Future/Promise支持的语言，已经涵盖了大多数的常用语言。
Future与promise实现列表

我是异步函数的编写者

我写了两个异步函数,来提供给其他程序员同事使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type CallBack = Try[String] => Unit

def pretendCallAPI(callBack: CallBack, okMsg: String, failedMsg: String) = {
  val task = new TimerTask {
    override def run() = {
      val percentage = Random.between(1, 100)

      if (percentage >= 50)
        callBack(Success(okMsg))
      else if (percentage <= 30)
        callBack(Failure(new Exception(failedMsg)))
      else
        callBack(Failure(new Exception("network problem")))
    }
  }

  new Timer().schedule(task, Random.between(200, 500))
}

val searchTB = pretendCallAPI(_, "product price found", "product not listed")
val buyFromTB = pretendCallAPI(_, "product bought", "can not buy, no money left")

这两个异步函数: searchTB用来从淘宝搜索物品,另一个buyFromTB用来购买搜到的物品。

原文地址： https://blog.cleancoder.com/uncle-bob/2018/04/02/InTheLarge.html

原作者：Robert C. Martin (Uncle Bob)

自敏捷之开端始，我们就思考大规模敏捷的问题。我们是否能够把轻量级，迭代，增量，快速反馈等软件开发的原理应用于规模巨大的项目呢？

最初我们想到的答案是Scrum of Scrums之类的东西。这个想法是在更高的层次上递归地应用敏捷开发的原理。如果一个项目需要超过5-12个开发人员，那么可以组织两个这样的团队，以及一个更高级别的团队来“监督？”他们。

请注意上面的问号。当我们开始考虑大型项目时，我们不可避免地要谈及层级化的组织。但是敏捷似乎是厌恶组织层级的。毕竟，敏捷就是关于平等主义的。敏捷是拒绝命令和控制的。敏捷是拒绝计划和时间表的，还有…

无稽之谈！并不是这样的！

原文地址：https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html

原作者：Robert C. Martin (Uncle Bob)

在过去的几年中，我通过与人结对来学习函数式编程，他们中的很多人表达了反对OO的偏见。他们经常会说：“啊，这太像对象了。”

他们会这样说是因为他们认为FP和OO在某种程度上是互斥的。许多人似乎认为程序FP的程度等同于其非OO的程度。我认为这种观点是学习新事物的自然结果。

当我们采用一种新技术时，我们通常倾向于避开以前使用的旧技术。这很自然，因为我们认为新技术“更好”，因此旧技术就一定是“更糟”的。

在此博客中，我将说明OO和FP是正交的，但它们并不互斥。一个好的函数式程序可以（并且应该）是面向对象的。而且一个好的面向对象程序可以（并且应该）是函数式的。在此之前，我们必须非常谨慎地给FP和OO这两个词语下个定义。

身陷南洋囹圄，心系故园风物，无以聊赖之中，撰文权作慰藉。

从Neal Ford的一段话讲开去

前段时间看了Neal Ford的一个演讲，原视频

其中一段讲到了传统工程与软件工程的区别。

於我心甚有戚戚焉。

译如下：

最近快速浏览完了太祖的五卷选集。粗浅的尝试着总结一下太祖做事情和分析问题解决问题时都会运用一些什么样的套路。

性质决定形式

革命不是请客吃饭，不是做文章，不是绘画绣花，不能那样雅致，那样从容不迫，文质彬彬，那样温良恭俭让。革命是暴动，是一个阶级推翻一个阶级的暴烈的行动。

大家明白，不论做什么事，不懂得那件事的情形，它的性质，它和它以外的事情的关联，就不知道那件事的规律，就不知道如何去做，就不能做好那件事。

第一章一个好点子出炉了

基本的经济原则，这个原则可以提高人们的生活水平：消费不足，敢于冒险！

在经济学术语中，资本指的是一种设备，这种设备的建设和使用本身没有什么意义，其意义在于利用设备建设和制造其他需要的东西。艾伯想要的不是那张网，而是鱼。这张网或许可以给他带来更多的鱼。因此，这张网就是一种资本，是有价值的。

在艾伯孤注一掷去编织渔网之前，小岛上还没有什么储蓄之所。他决定冒险挨饿制造的这张网成了小岛上的第一件资本设备。这件设备接着会带来储蓄（为了让这个故事能够继续进行，我们假设这些鱼不会腐烂变质），而这种剩余产品就是健康经济的命脉。

工具改变了一切，使经济的出现成为可能。长矛帮助我们捕获猎物，铲子帮助我们种植庄稼，渔网帮助我们捕鱼。这些工具提高了我们的劳动效率。我们生产的东西越多，可以消费的东西就越多，我们的生活也就变得越美好。

努力使有限的资源（每种资源都是有限的）产生最大的效益以尽可能满足人类的需求，这就是经济这一概念最简单的定义。工具、资本以及创新是实现这一目标的关键。

随着持续集成，持续交付等理念的传播，很多软件开发团队都搭建了自己的staging、UAT等类生产环境。这些环境的软硬件及网络配置会尽量贴近真实的生产环境，起到沙盘演练的作用。

类生产环境毕竟前面还有一个类字，沙盘毕竟不是真实的战场，尽量贴近毕竟还不是完全吻合。

类生产环境与真实生产环境的一个重要差异就是访问量。稍具规模的互联网应用每天几百万访问量是很正常的，而类生产环境的访问量一般都会相形见绌。

有各种工具可以弥合这个差异，比如Apache JMeter，Gatling。测试人员可以和开发人员一起设计测试用例，以自动化或者半自动化的方式对类生产环境进行压力测试。

不过即便是精心设计出来的用例也还是用例，不是真实请求。真实请求具有多样性，会随着昼夜交替而变化，会随着时事热点而波动，这是很难用工具模拟出来的。

这就引出了这篇文章的主角-影子流量（shadow traffic）。

第一部分科技颠覆

20世纪，来自纽约、伦敦、柏林和莫斯科的全球精英讲述了三大故事，号称能够解释人类过去、预测全球未来。这三大故事是：法西斯主义故事、共产主义故事，以及自由主义故事。第二次世界大战打倒了法西斯主义故事，于是从20世纪40年代末到80年代末，世界成为共产主义故事和自由主义故事的战场。等到共产主义受挫，自由主义故事就成为人类了解过去的主要指南、未来无法取代的使用手册

1938年，人类有三种全球性的故事可以选择；1968年只剩下两个；1998年，似乎只有一个故事胜出；2018年，这个数字降到了0。

过去推动俄国、中国和古巴革命的，是一群对经济至关重要但缺乏政治权力的人；而2016年，支持英国脱欧和特朗普的，却是一群虽然还享有政治权力却担心失去经济价值的人。

自由主义分别学习了帝国主义、法西斯主义和共产主义某些最优秀的概念。

自由主义学习了共产主义，于是扩大了同理的范围，开始在重视自由之外也同时重视平等。

即使在第二次世界大战之后，西方自由主义者还是很少将他们所谓的共通价值应用到非西方人民的身上。所以，荷兰人在自己的国土被纳粹残酷占领5年，于1945年重新站起来之后做的第一件事，就是召集军队横跨半个地球，希望重新占领前殖民地印度尼西亚。尽管在1940年，荷兰人只战斗了4天就举手投降放弃独立地位，但为了压制印度尼西亚的独立，他们却鏖战了4年之久。这也就难怪全球许多民族解放运动所寄望的都是苏联和中国，而不是自诩为自由主义领导者的西方国家。

一首绝句作为定场诗，接下来开始正式的内容。

最近，我在网上进行了一些稀奇古怪的操作，于是乎我莫名其妙的得到了一个“众邦银行”的账户。

这个名字并不是很熟悉，查了一下，看起来还算是有头有脸的样子。

武汉众邦银行股份有限公司（简称武汉众邦银行，英语：Wuhan Zhongbang Bank Co., Ltd.，缩写：Z-BANK）是中华人民共和国境内第11家开业的民营银行，也是湖北省首家获批开业的民营银行。

以上是wiki的信息。

Stackable traits是一种怎样的特性呢？

来举一个🌰

1
2
3
4

abstract class IntQueue {
  def get(): Int
  def put(x: Int)
}

定义一个IntQueue，抽象类，定义了get和put，没有实现。

1
2
3
4
5
6
7
8
9

class BasicIntQueue extends IntQueue {
  private val buf = new ArrayBuffer[Int]

  def get() = buf.remove(0)

  def put(x: Int) = {
    buf += x
  }
}

再定义一个BasicIntQueue，把上述IntQueue实现了。
它的实现没有什么花样，就是先进先出。

_{此文标题党。更切题的标题应该叫做《如何用统计科学来黑星座》或者是《积极注册Facehub，促进统计科学蓬勃发展》}

锤子　JS Promise

最近对JS社区里的Promises/A+规范产生了很浓的兴趣，感觉Promise这套东西确实蛮不错的，给异步算法的编写者和异步算法的消费者之间提供了一套统一的沟通手段，也为异步算法的消费者提供了更悦目易读的代码组织方式。

自己把它实现了一遍:https://www.npmjs.com/package/RWPromise

然后在武汉办公室run了3次workshop:http://cuipengfei.is-a.dev/blog/2016/05/15/promise/。

手里有了这么一把锤子就总想找个钉子敲一敲。总在想能去哪里找N多异步操作来让我来组织一下呢?

Promise并不是一个新的概念,它已经有将近30年的历史.

其早期的雏形还有里氏替换原则的提出者Barbara Liskov的贡献在其中.

https://en.wikipedia.org/wiki/Futures_and_promises#History

而Promises/A+这个规范的出现,则为JavaScript世界中众多Promise实现库提供了一套统一的API和交互机制.

Promises/A+提供了配套的测试集:https://github.com/promises-aplus/promises-tests.

其中共有872个测试,如果你的实现能够让全部测试绿起来,则可以认为该实现符合了标准.

背景

Wifi，4G，3G，这些我们习以为常的东西，未必对所有人来说都是随时可用的。

以我当前所在项目为例，应用场景是某欠发达地区医疗服务机构的药品库存管理。

所谓欠发达，具体怎样呢？

• 没有台式电脑
• 没有笔记本
• 只能使用低端的安卓平板
• 4G，3G信号不要想
• 我们去过现场的一位同事甚至要爬到树上去，才能勉强收到2G信号
  
• 即便是2G信号，也是时断时续，非常不稳定

因此，需要随时保持连通的BS结构基本不可行，我们选择了重度依赖移动端设备本地存储的CS结构（胖客户端）。

2015年结束了，一如已经结束了的每一年，非常迅速。

按惯例，从博客说起。

博客

15年写了16篇博客，其中9篇是与Scala，Reactive，OODP相关的。这个数字倒还不算太坏。

14年总结的时候说：

明年可以改进的是不要嫌话题小，不要嫌话题不够深。 有了有价值的想法就记下来，形成惯性。

惨。

八月份上了一个大客户的项目，到了晚上没力气也没心情做任何事情。

博客

没写。上个季度六月的系列告一段落后7月没写。到了8月就不用说了。

读书

七月八月读了7本书，9月一本未读。

2015竟然这么快就过去一半了。逝者如斯夫。

博客

第一季度总结的时候说：

今年的博客主线任务定为OO与FP的比较和结合应用吧。

这个任务完成的不错，这个主题写了7篇博客。

迭代器已经irrelevant了，中介者和备忘录太简单就没写，状态模式没找到好的FP实现方式。
这样11种行为模式除去上述4个，算是基本覆盖完了。

模板方法模式定义了一个算法的步骤，并允许次类别为一个或多个步骤提供其实践方式。让次类别在不改变算法架构的情况下，重新定义算法中的某些步骤。

以上是wiki对模板方法的定义。

比较容易理解，我们有一个算法，其中某些步骤是确定的不太会变的代码。而另外一些步骤则需要变化并且自由组合。

《Head First Design Patterns》里有一个🌰：

假设我们需要制作咖啡因饮品，其实就是咖啡和茶。制作步骤有些类似，分为四步：1烧水，2泡，3装杯，4加调料。

其中第一步和第三步是稳定的代码，变化可能性不大，而第二步和第四步则每种饮品有自己的风味。

访问者模式是一种将算法与对象结构分离的软件设计模式。

这个模式的基本想法如下：首先我们拥有一个由许多对象构成的对象结构，这些对象的类都拥有一个accept方法用来接受访问者对象；访问者是一个接口，它拥有一个visit方法，这个方法对访问到的对象结构中不同类型的元素作出不同的反应；在对象结构的一次访问过程中，我们遍历整个对象结构，对每一个元素都实施accept方法，在每一个元素的accept方法中回调访问者的visit方法，从而使访问者得以处理对象结构的每一个元素。我们可以针对对象结构设计不同的实在的访问者类来完成不同的操作。

以上是wiki对访问者模式的定义。

这个定义着实难读。我们来看wiki给出的例子：

假设我们要为汽车建模，汽车有不同的组成部件，轮胎，车身，和引擎。

在开车之前需要先检查车辆每个部件的状况，然后依次启动所有部件以启动汽车。

观察者模式

观察者模式（有时又被称为发布/订阅模式）是软件设计模式的一种。在此种模式中，一个目标对象管理所有相依于它的观察者对象，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实作事件处理系统。

以上是wiki对观察者模式的解释。

举一个《Head first design pattern》中的例子：

比如说有一个气象站，每当气象有变化的时候就需要显示当前天气。
需要显示历史平均气温，最高气温和最低气温。
还需要根据气压预测晴雨。

这种情况就很适合使用观察者模式，每种需要显示气象的装置作为观察者，气象数据本身作为可以被观察的对象。
每当气象变化的时候，被观察的对象就会通知观察者来根据新的数据作出新的显示。

解释器模式

In computer programming, the interpreter pattern is a design pattern that specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialized computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate (interpret) the sentence for a client.

以上是wiki对解释器模式的描述。

这是一个学术性稍强的模式，不太好找到生活化的比喻。

就直接上代码吧。

Java

命令模式

在面向对象程式设计的范畴中，命令模式是一种设计模式，它尝试以物件来代表实际行动。命令物件可以把行动(action) 及其参数封装起来，于是这些行动可以被：

• 重复多次
• 取消（如果该物件有实作的话）
• 取消后又再重做

以上是wiki对命令模式的定义（术语像是台湾的）。

下面是来自《Head first design patterns》的一个例子：

假设你有很多家用电器：电灯泡，电视，音响，还有一个水疗浴缸。（就是没有手电筒）

职责链模式

责任链模式在面向对象程式设计里是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。

以上是wiki对职责链模式的定义。

举个例子来说，我们的系统中需要记录日志的功能。日志需要根据优先级被发送到不同的地方。

低优先级的日志输出到命令行就好了。而高优先级的错误信息则需要通过邮件通知相关人员并且输出到命令行。

这个例子也是来自wiki的。

策略模式

策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。

以上是中文wiki中对策略模式的定义。

In computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern that enables an algorithm’s behavior to be selected at runtime. The strategy pattern:

• defines a family of algorithms,
• encapsulates each algorithm, and
• makes the algorithms interchangeable within that family.

Strategy lets the algorithm vary independently from clients that use it.

声明

这系列博文的目标读者仅限于报名参加了这门课并且看完了视频，看完了作业的instruction之后仍有困难的同学。

这系列博文不会公布作业的答案，那是违反Coursera的code of honor的。

我只会试着解释作业中已有的代码，以及应该如何入手。

其实，写这个系列博文对我的帮助比对读者的帮助要大。

这周的作业不太难，主要就是一个观察者模式。