Redis里执行get或hget不存在的key或field时返回值在终端显式的是”(nil)”
127.0.0.1:6379> get notexist
(nil)
当使用lua脚本执行逻辑时，如果要判断这个值，很容易让人迷惑以为它是nil，从而导致判断不成立，实际它是一个boolean的值
127.0.0.1:6379> eval "local v=redis.call('get',KEYS[1]); return type(v)" 1 notexist
"boolean"
所以在脚本里判断获取的结果不为空，正确的方式还有判断false的情况：
local v=redis.call('hget',KEYS[1], ARGV[1]);
if (v ~= nil or (type(v) == 'boolean' and v)) then
return 'not-empty';
end
有些通过mac store下载的需要重新下载才可运行：
搜狗拼音无法使用，需要下载最新版本重新安装。
➜ cat stop-photoanalysisd.sh
#!/bin/bash
launchctl stop com.apple.photoanalysisd
launchctl unload -w /System/Library/LaunchAgents/com.apple.photoanalysisd.plist
感谢林晴、史珩、shahito、乐乐Joker 以及其他匿名用户的反馈，勘误表如下（另外，原书作者另写了一本伴生书，对文章的错别字以及个别代码样例错误做了纠正，伴生书pdf可从作者网站免费下载：http://blog.higher-order.com/assets/fpiscompanion.pdf 为了保持一致，伴生书中修订的内容在中文版中并没有修改。伴生书中指出的错误并不多，也不影响本书阅读，主要是为书中的练习做解释）
页数：目录
原文：1.3 引用透明、纯粹度以及替代模型
修改：1.3 引用透明、纯粹性以及代换模型
页数：目录 XI
原文：4 不是用异常来处理错误
修改：4 不使用异常来处理错误
页数：目录 XII
原文：第二部分 功能设计和组合子库
修改：第二部分 函数式设计和组合子库
原文：9.1 代数设计，走起
修改：9.1 代数设计
页数：目录 XIII
原文：第三部分 函数设计的通用结构
修改：第三部分 函数式设计的通用结构
页数：目录 XV
原文：14 本地影响和可变状态
修改：14 局部作用和可变状态
原文：14.3 纯粹是相对于上下文的
修改：14.3 纯粹性是相对于上下文的
页数：原推荐序
第一段中
原文：函数式编程作为书题出现在Scala中是个有趣的现象。
修改：《Scala函数式编程》是个有趣的书名。
第二段中
原文：它同时承认非纯粹函数和纯函数
修改：它同时允许非纯粹函数和纯函数
第五段中
原文：从第一个原理扩展到
修改：从首要原则扩展到
页数：第一部分 函数式编程介绍
第一段中
原文：我们以一个激进的前提开始读这本书
修改：我们以一种激进的前提开始这本书
原文：比如读取文件或修改内存时。
修改：比如读取文件或修改内存。
第二段中
原文：并给你一些有益的理念。
修改：让你对函数式编程的好处有些概念。
页数：8
原文：引用透明与纯粹度
修改：引用透明与纯粹性
原文：1.3 引用透明、纯粹度以及替代模型
修改：1.3 引用透明、纯粹性以及代换模型
// 统一翻译为“代换模型”
原文：我们称之为代替模型( substitution model )。
修改：我们称之为代换模型( substitution model )。
原文：其中一个例子的所有表达式都是引用透明的，可用替代模型来推导，
修改：其中一个例子的所有表达式都是引用透明的，可用代换模型来推导，
原文：让我们尝试在Scala解析器（也称作REPL，
修改：让我们尝试在Scala解释器（也称作REPL，
页数：10
原文：与之相反的是，替换模型则很容易推理
修改：与之相反的是，代换模型则很容易推理
原文：即使没有用过“替代模型”这一名词，
修改：即使没有用过“代换模型”这一名词，
原文：还对引用透明和代替模型进行了讨论，
修改：还对引用透明和代换模型进行了讨论，
页数：22
// andThan -> andThen
原文：同时还提供了一个 andThan 方法， f andThan g 等价于 g compose f
修改：同时还提供了一个 andThen 方法， f andThen g 等价于 g compose f
页数：23
原文：对于像这样小的一行层序，还不算困难
修改：对于像这样的一行小程序，还不算困难
页数：40
原文：不是用异常来处理错误
修改：不使用异常来处理错误
页数：41
原文：让替代模型的简单推导无法适用
修改：让代换模型的简单推导无法适用
页数：54
原文（最下面的注释）: 我们现在使用Scala标注库
修改：我们现在使用Scala标准库
页数：57
原文：如果表达式 f(x) 对所有的evaluates to bottom的表达是x，也是evaluates to bottom，那么f是严格求值的。
修改：如果表达式f(x)对于所有evaluates to bottom的表达式x同样是evaluates to bottom的，那么f是严格求值的。
页数：67
原文：目的是模拟投6面色子死亡法
修改：目的是模拟投6面体骰子
页数：73
原文：这是向右移的方式，
修改：这是朝着正确方向前进，
原文：用纯函数式API实现一个更加可测的死亡色子？
修改：用纯函数式API实现一个更加可测的投骰子？
原文：这里是一个死亡色子 rollDie 的实现，
修改：这里是一个投骰子 rollDie 的实现，
页数：77
原文：第二部分 功能设计和组合子库
修改：第二部分 函数式设计和组合子库
页数：81
原文：两边的表达式是无法实现平行执行的。
修改：两边的表达式是无法实现并行执行的。
注释2
原文：并在衍生下一个并行计算之前等待前一个并行计算完成，这样的计算比较高效同时也保证串行执行。
修改：并在衍生下一个并行计算之前等待前一个并行计算完成，这样的计算实际是串行的。
页数：90
原文：(法则常常是从标识的具体例子中得出来的)
修改：(法则常常是从恒等式的具体例子中得出来的)
注释8
原文：这里的标识我们想表达的是，在数学上指两个表达式相同或等价
修改：这里的恒等式表达的是，在数学上指两个表达式相同或等价
页数：91
//将 fascinating 翻译为了“醉了吧” 与整本书的语言风格不一致，删除。
原文：醉了吧！从最后的法则可以看出对于map而言unit明显是个多余的细节。
修改：从最后的法则可以看出对于map而言unit明显是个多余的细节。
原文：由于我们得到的这个第二法则或定理是自由的，仅仅是因为map的参数态(parametricity)，它有时也被称为自由定理(free theorem)。
修改：由于我们得到的这个第二法则或定理是免费的，仅仅是因为map的参数态(parametricity)，它有时也被称为免费定理(free theorem)。
注释10
原文：这和我们在代数方程式里做的简化过程一样。
修改：这和我们在代数方程式里做的代换和简化过程一样。
注释12 // 译注：在优化界有一个著名的定理叫“没有免费午餐定理”，这个论文的题目可能是想与之呼应
原文：”自由定理”的观点来自于 Philip Wadler 的经典论文《Theorem for Free》(http://mng.bz/Z9f1)
修改：”免费定理”的观点来自于 Philip Wadler 的经典论文《Theorem for Free》(http://mng.bz/Z9f1)
页数：103
原文：某些情况下，Gen[A] 的空间（domain）足够小
修改：某些情况下，Gen[A] 的定义域（domain）足够小
注释2
原文：这里的“空间”（domian）与函数空间一样
修改：这里的“定义域”（domian）与函数定义域一样
页数：108
// Refining 在编译器里更多翻译为”具化"
原文：8.2.5 精炼 Prop 的数据类型
修改：8.2.5 具化 Prop 的数据类型
页数：117
注释13
原文：回忆一下在第7章中我们曾介绍过的自由定理，
修改：回忆一下在第7章中我们曾介绍过的免费定理，
页数：117
// 风格不符
原文：9.1 代数设计，走起
修改：9.1 代数设计
页数：153
注释3
原文：因为借用了已经存在的数据抽象名称
修改：因为借用了已经存在的数学抽象名称
页数：164
// primitive翻译为原语，保持一致风格
原文：State中（除了unit和flatMap）其他原始的操作
修改：State中（除了unit和flatMap）其他原语操作
原文：它们和monadic原始操作(unit和flatMap) 一起构成了State数据类型的所有操作。monad一般都是这样的，它们都包括unit和flatMap，并且每个monad又有自己额外的原始操作。
修改：它们和monadic原语操作(unit和flatMap) 一起构成了State数据类型的所有操作。monad一般都是这样的，它们都包括unit和flatMap，并且每个monad又有自己额外的原语操作。
页数：172
原文：Applicative构建了上下文自由的计算，
修改：Applicative构建了上下文无关的计算，
页数：210
原文：本地影响和可变状态
修改：局部作用和可变状态
页数：212
注释1
原文：也无须每次在充分利用本地变更(local mutation)时使用。
修改：也无须每次在充分利用局部变更(local mutation)时使用。
页数：214
// primitive 统一翻译为原语
原文：这里依旧采用组合子库加一些基元函数(primitive)的形式，其中关于可变内存单元的应有的基元函数有：
修改：这里依旧采用组合子库加一些原语函数(primitive)的形式，其中关于可变内存单元的应有的原语函数有：
页数：217
// primitive 统一翻译为原语
原文：为此，我们需要先实现可变数组的基元组合子：
修改：为此，我们需要先实现可变数组的原语组合子：
页数：218
// 基元->原语，负责->复杂
原文：有了这些基元函数，我们便可以实现更负责的数组函数了。
修改：有了这些原语函数，我们便可以实现更复杂的数组函数了。
原文：我们不如把这变成一个基元函数：
修改：我们不如把这变成一个原语函数：
页数：219
练习14.3
原文：为 scala.collection.mutable.HashMap 实现一组最小的基元组合子。
修改：为 scala.collection.mutable.HashMap 实现一组最小的原语组合子。
页数：240
原文：链状混合(Zipping)是Tee特有的一种情况，
修改：拉链式操作(Zipping)是Tee特有的一种情况，
页数：242
原文：请用存在基元函数实现join，
修改：请用已存在的原语函数实现join，最近看到nginx plus收费版里有个session draining的概念，在用nginx做反向代理，要优雅停止后端应用的话，需要先在nginx层控制请求不再发到相应的节点，但与此同时已经建立的链接则要继续保持，一直等这些链接都结束了再停止应用。
其实在免费版的nginx/tengine就能实现这个特性，在以前的这篇nginx反向代理对后端某个节点优雅下线的问题 文章里测试过后端tomcat有一个耗时很长的请求，当tengine端健康监测已发现后端节点不可用的情况下，该请求并不会被tengine中止，而会等后端响应结束后再返回给客户端。
优化关闭应用并不只是在负载均衡或反向代理层面就能完美解决的，后端的应用本身也要考虑很多细节。举一个例子，Actor怎么有序的关闭，可以参考之前分享的Governor模式，所有干活的Actor由Governor创建，在创建时就设定好优先级。
在应用关闭的时候，对master发送PoisonPill，示例代码如下：
// 在你的容器或微容器里监听到应用关闭事件时触发shutdown，最简单的情况下是在shutdownhook里
def shutdown(): Unit = {
gracefulStopActors
system.terminate
Await.result(system.whenTerminated, Duration.Inf)
springContext.close
}
private def gracefulStopActors {
master ! PoisonPill
signal.acquire //wait
}
在governor角色里，当收到Terminated消息后顺序结束子actor
...
case Terminated(actor) if actor == observable => {
logger.info("===receive terminated message from: " + actor)
// 先顺序的杀死所有托管的子actor，并将结果发给自己
stopAll(managedActors.toList.sorted) pipeTo self
}
...
// 顺序的停止所有子actor
protected def stopAll(kids: List[OrderedActorRef]): Future[Any] = {
kids match {
case first :: Nil =>
logger.info("===graceful stop: " + first.actor)
gracefulStop(first.actor, stopTimeout).flatMap { _ =>
Future { AllDead }
}
case first :: rest =>
logger.info("===graceful stop: " + first.actor)
gracefulStop(first.actor, stopTimeout).flatMap { _ =>
stopAll(rest)
}
case Nil =>
Future { AllDead }
}
}
再举一个例子，应用里有一个线程一直轮询从redis里获取数据，你在关闭应用的时候如何优雅终止这个线程呢？下面用一段代码简单模拟这个场景；假设这个应用没有任何容器，结束就是靠收到kill信号，那么在ShutdownHook里，要阻塞的等待(一段时间)worker线程结束后再退出才算安全
public class Test {
static volatile boolean running = true;
public static void main(String[] args) {
Thread worker = new Thread() {
public void run() {
while (running) {
try {
System.out.println("i'm running.1");
Thread.sleep(1000);
System.out.println("i'm running.2");
Thread.sleep(1000);
System.out.println("i'm running.3");
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
};
worker.start();
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
System.out.println("receive shutdown signal.");
running = false;
while(worker.isAlive()) {
System.out.println("waiting for worker thread finish.");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
}
}
System.out.println("wroker thread finished!");
}
});
}
}