He-Pin(kerr)

Scala 3 supports Top level definition.

When then member method is private, then the extension method with same method will win.

 ``` // auto-generated by sbt-boilerplate from UnzipWithApply.scala.template ```

Prepare code samples here.

1

I more prefer you organize the book's code samples here, in chapters with a set of SBT projects:)

some pictures are hard to read

3

like this one  very fuzzy

Migrate to rxjava2

2

test

问题： 我们有时候需要灵活的修改配置文件，以适应线上环境。通过sbt，我们可以轻松实现这点。 办法： ``` scala mappings in Universal ++= contentOf((resourceDirectory in Compile).value).map{ case (file,path)=> file -> ("conf/" + path) } scriptClasspath := "../conf/" +: scriptClasspath.value mappings in Universal += baseDirectory.value...

在Akka2.3里面，默认的实现我们是无法使得两个NAT后的Akka实例组成集群的，原因是这两个NAT是无法直接访问的。 拓扑结构可能是 ``` |---------------NAT1（Docker1）----------Akka Application A1 Net-----| |---------------NAT2（Docker2）----------Akka Application A2 ``` 这里，如果A1,A2绑定的地址可能是： - 127.0.0.1 - 172.x.x.x - 0.0.0.0 但是无论你绑定在什么地址上，默认的配置：`port`和`hostname`都是没法满足你跨NAT组建Akka集群的。原因是在Akka的Remoting的Transport实现里面，任意的两个相互能够通讯的节点之间，必须要建立两个连接，其分别是： 1. 对等节点到本机所绑定在`hostname:port`地址Socket上的一个连接。 2. 本机的一个随机地址到对等节点连接本机地址时所附带的地址信息的连接，本机将通过同样的方式连接对等节点。 > **需要注意的是**这里的地址信息不一定是TCP传输，协议是可以多样的，可能是TCP/UDP/UNIX也可以是其他的，但是在Transport的API层面都是一样的。`akka.://:`。同时上面的信息是关于2.3的默认的transport实现的。 这样带来的问题是，在2.3的默认实现里面，我们所捎带的信息是`0.0.0.0`等这样的信息，作为Server的这个NAT（Docker）后面的应用程序是无法通过这样的地址信息连接到对等节点的。这也就是观察到现象是，收到了接入信息，但是反向连接的时候，失败。 注：官方的收费版本可以在2.3使用该特性。 为了解决这个问题，Akka2.4引入了一个新的设置，`bind-hostname`和`bind-port`，这组配置和原来的配置在一起组成了下面的配置对： - hostname...

该模式也是Akka的核心思想之一，也是Akka的`Actor Kernel`的由来。该模式的核心思想是：`将重要的数据以及消息保留在根（root）上，并将危险的操作通过简历子actor，分配出去，同时监控它们。` 一个常见的场景是如何保证一个消息总能被处理而不会因为Actor重启而丢失？这种情况下我们可以通过下面的步骤来应用该模式： 1. 通过应用`单一责任模式`将高风险的操作移交到子Actor，并且需要监控子Actor。 2. 在收到消息后，将任务分配给（创建新的）子Actor来完成。 3. 子Actor通过Pull模型从父Actor拉取任务。 4. 任务完成后做对应的ACK。 5. 在任务失败或者子Actor挂掉后，应用对应的策略，比如重做，丢弃等。 该模式也可以结合kafka的pull 和手动commit以及Akka Persistence使用。