用 IDE 写了一段代码，目的是遍历某一目录下的所有文件，并对所有以
.xml结尾的文件进行处理，代码如下：1try (Stream<Path> pathStream = Files.list(Paths.get("data"))) { 2 pathStream.filter(path -> path.endsWith(".xml")) 3 .forEach(System.out::println); // do something with the file 4} catch(IOException e) { 5 //... 6}看起来很直截了当，filter 中对 path 用
endsWith(String)方法过滤出所有以.xml结尾的文件，然而在目录中存在*.xml文件的情况下却没有任何输出。假如测试时未该发现问题，在运行期大有可能当成是该目录中未找到任何以.xml结尾的文件而怀疑是数据问题。这样的代码即使是让人工进行 review 也未必能发现有什么问题，遍历
data目录下的文件，如果文件以.xml结尾就进行处理，很自然，正确啊。要是前面的代码中使用了
Read Morevar来修改pathStream就更不太可能在 Code Review 时发现问题，像
本文初衷是要专注在 Docker 内的应用进程如何与外部发过来的 Linux 信号进行响应。具体应用在当运行为一个 ECS 的 Docker 容器时，对 ECS 的 AutoScaling 以及部署时如何让应用能正确收到相应的信号。可是一提及这一话题，思维就产生了极大的发散，很想好好捋一捋进程与 Linux 信号之间关系和相关的概念。 关于 Linux 的 Signal 请参考 Wikipedia 的 Signal(IPC).
本文以渐进的方式，从信号的简介，本地 C, Bash, Java 程序与信号，然后将在下一篇学习本地 Docker 容器内进程与信号的处理，ECS 的容器与 ASG，部署行为的信号响应。
Read More- 继续阅读本书，编程语言处理数值都有可能出现问题，如溢出，整数的最大最小值不对称，Double.NaN 等。
由于 Java 学了 C，也用 0 开始的数字来表示 8 进制数，如 037, 010 分别是十进制的 31 和 8，这与现实不相符。因为如果你在纸上写下 037, 010, 几乎所有人(除了某些程序员)都会认为它们就是十进制的 37 和 10。但是 Java 表示 2 进制, 16 进制的方式没有问题的，如 0b10, 0x37。IntelliJ IDEA 看到使用 0 开头的 8 进制数会不建议那么使用. 8 进制数字的范围是 0~8, 所以 09 是错误的, 但是 Java 编译器似乎对此很陌生.
int a = 09;
IntelliJ IDEA 会提示Integer number too large, 编译器提示说java: ';' expected, 有点驴唇不对马嘴.
现在几乎没有必要使用 0 开始的 8 进制数的方式, 或许还有用的就是表示 Unix 下文件权限, 如
int fileMode = 0644
所以任何时候看到 0 开头的数字都必须仔细检视, 基本可以禁止使用这种方式 Read More - Java 一路突突突， 版本 16 在 2021-03-16 都发布了, 而我们一直碍于 Java 9 的大改还在 Java 8 上原地踏步, 以往每当有新版本 JDK 发布后都是很快就验证，立马升级。Java SE versions history) 列出了所有 Java 的历史版本的发布日期。在今天(2021-05-04) 网站 Java SE Downloads 上直接提供下载的 Java SE 版本有以下三
- Java SE 16.0.1
- Java SE 11.0.11(LTS)
- Java SE 8u291
两个 LTS(长期支持) 版 8 和 11，外加一个目前最新的非 LTS 版本 16, 其他的版本都被归档到了 Java Archive. 查看一下 Java 支持的 roadmap, 几个 LTS 版本的服务支持年限版本本 发布日 原定支持至 延期支持至
注意到 Java 8 将比 Java 11 和将来的 Java 17 生命力还顽强，一下就觉得这么久坚守在 Java 8 的阵地上不应觉得有什么好害羞的。眼看着下一个 LTS 版本的 Java 17 就要在今年 9 月份发布了，Java 11 看来是要错过了，等准备好和 Java 8 告别时要直接跳到 Java 17 了。 Read More
Java 8 2014/3 2022/3 2030/12
Java 11 2018/9 2023/9 2026/9
Java 17 2021/9 2026/9 2029/9 
在进行数据流处理过程中，需要一个高效苗条的流处理组件，比如对输入流能进行分组(窗口)，能进行流量控制(Back Pressure - 背压)，这也就涉及到响应式编程，流处理框架。这方面如果直接基于 Akka actor 来构建 Akka ActorSystem 也是比较复杂，依赖的组件也不少。还有构筑在 Akka actor 之上的 Akka Streams，再往上的 Flink Streaming，它们都有像滑动，滚动窗口的概念，但是依赖更不得了。一个基本的 Flink Streaming 的项目会依赖到 45 M 以上的第三方组件，如果用它来写一个数据流处理的共享组件，那真是要命。Spring 5 也开始带上了自己的 Reactive-Streams 实现 Spring Reactor, 想要把它从 Spring 中单独抽离出也非易事。Flink Streaming 组件依赖：org.apache.fling:flink-streaming-java_2.12:1.80, 会依赖于其他诸如 akka-stream, akka-actor, flink-core, flink-clients, scala-library 等非常多的东西
而另一个著名的响应式框架 RxJava 2 就清爽多了，完全没有第三方依赖，要说有也就是定义了四个接口的 reactive-streams(2 KB 大小)，就自身那个 rxjava-2.2.9.jar 包只有 2.3 M，这才叫轻量级。因为它设计来是能被应用于 Android 客户端应用的，Andriod 上的 rxandriod-1.2.1.aar 只有 9 K。所以 RxJava 2.x 太适合用来写一些小的共享组件了。 Read More
在我们对数据库 DAO 类进行单元测试时，通常不应该依赖于一个外部数据库，所以会选用特定比较接近于真实数据库类型的内存或嵌入式数据库，如 HSQLDB(HyperSQL), H2, Derby 等。但总难免会用到特定数据库的特性，这时候就无法用前述各种数据库进行测试了。非要单元测试中覆盖到所用的数据库特性的话可以选择用 docker，如 Testcontainers, 经过模块扩展，它可以由 docker 来启动许多种类型的数据库，MySQL, Postgres, Oracle-XE, MS SQL Server, Couchbase 等等，详情见 Database containers。刚了解到的是它的模块化的无限可能，像支持 Kafka Containers 和 Localstack Module 等。
这里就不走 Testcontainers 那条路 -- 要求构建服务器上也要有 docker。早先希望能找到一种嵌入式或内存 PostgreSQL 数据库，后来发现 PostgreSQL 未能提供 In-Process 和 In-Memory 的启动方式，好在 PostgreSQL 是开源，有人可以把它改造为小型的可由测试代码启停的本地数据库。有两个具有代表性的组件，分别是 OpenTable Embedded PostgreSQL Component 和 Embedded PostgreSQL Server，它们都号称是 Embedded，所谓嵌入式，其实是进测试进程外的数据库。
下面简单体验下两个组件的用法 Read More