直接一句话：去掉 Log4J 的依赖，把 Slf4J, Logback, 和 log4j-over-slf4j 依赖加进来就行了，配置文件换成 logback.xml，这就完了，不要往下看了，都是些废话。当我们用 Serverless 命令sls create -t aws-java-maven -p hello-lambda创建的示例项目中直接用的是 Log4J 日志组件，而且也没用像 Slf4j, 或 Apache Common Logging 更上一层的通用日志框架。查看了几个 AWS 本身的组件 S3, SNS, 和 Kinesis 的 SDK, 它们内部是用的 Apache Common Logging 声明的日志变量import org.apache.commons.logging.LogFactory;
而我们自己的组件中通用日志组件是 Slf4j, 底层实现为 Logback, 所以我们希望在 Lambda 中使用 Logback 来写日志。
import org.apache.commons.logging.Logger;
private static final Log log = LogFactory.getLog(AmazonKinesis.class)
选用一个通用日志框架总是明智之举，因为一个项目经常杂糅了多种日志实现，使用 Slf4J 或 Apache Common Logging 可以把它们(Log4J, Logback, 或更多)输出到共同的目的地，并且有统一的日志输出接口。而我们认为通用日志框架还是 Slf4J 要先进些，所以我们在 Java Lambda 中的日志方案是 Slf4J + Logback，还需要把 Log4J 的日志桥接到 Slf4J 上来，再经由 Logback 输出。
回到前面创建的hello-lambda项目，看其中怎么用的 Log4J，先瞧瞧pom.xml文件怎么引入的 Log4J, 它是间接通过一个 AWS 定义的 Log4J Appender 引入的 Read More- AWS 的 Lambda 给了那些不想自己管理 EC2 服务器和配置负载人员很大的便利，所以 Lambda 被描述为 Serverless。真正的只关注业务就行，怎么调度，同时有多少个实例运行交给亚马逊去处理就是了。运行 Lambda 的环境也是亚马逊内部的 EC2 服务器，镜像是 Amazon Linux, 所以如果想运行系统命令，那是 Linux 的。Lambda 支持多种语言 Node.js, Python, C#(.net core), 还有 Java 8，我们就选择了 Java 8, 一开始还担心它与别的语言比起来会多大劣势，其实不然。而且所谓的 Java 8, 并非单指 Java 语言，而是指 JVM 平台，所以也可以用 Scala, Clojure, Groovy, Kotlin 来写。
Java 与脚本语言如 Node.js, Python 相比给人一个明显的感觉是启动慢，还有人用统计数据来比划 AWS Lambda cold start(pseudeo-)benchmark. 不过真不用担心，人家说的是冷启动，也就发生在部署后第一次执行启动会比较慢。要是我们的 Lambda 经常被调用，或每天触发比较集中，Lambda 在任务到来之前处理待续状态，就不会有冷启动的耗时过程。或者是每次任务要执行 3 分钟左右，又何必在乎毫秒级的冷启动时间。
说到底就是别理会下面的数据20ms startup time for Python ~ $0.04167540ms startup time for Node.js ~ $0.0833580ms startup time for Java ~ $0.1667
Lambda 实例重用
Java 的 Lambda 就是一个微服务，在首次触发时微服务冷启动有些慢，但一旦启动之后就可以用这个微服务实例接受后续的请求，只有在比较长的一段时间内未被触发 AWS 才会把这个微服务杀掉。 Read More 
第一章：整洁代码
- 代码即设计
- 童子军军规：把露营地清理得比来时还干净，签入代码前是否已做重构
- 你湎自行实践，且体验自己失败。你须观察他人的实践与失败
- 勒布朗(LeBlanc) 法则：稍后等于永不 (Later equals never)
- 赶上期限的唯一方法--做得快的唯一方法--就是始终尽可能保持代码整洁
- 缺乏“代码感”的程序员，看混乱是混乱，无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化
- 不好的代码引诱别人做没规矩的优化，搞出一堆混乱来
- 整洁的代码只做好一件事，糟糕的代码想做太多事，它意图混乱，目的含混
- 整洁的代码从不隐藏设计者的意图
- 整洁的代码只提供一种而非多种做一件事的途径
- 整洁的代码总是看起来像是某位特别在意它的人写的
- 回放我们编码过程显示，多多数时间都是在滚动屏幕，浏览其他模块
- 读与写花费时间的比例超过 10:1, 写新代码时，我们一直在读旧代码
- 编写代码的难度，取决于读周边代码的难度
Java 测试的 Mock 框架以前是用 JMockit, 最近用了一段时间的 Mockito, 除了它流畅的书写方式，经常这也 Mock 不了，那也 Mock 不了，需要迁就于测试来调整实现代码，使得实现极不优雅。比如 Mockito 在 私有方法，final 方法，静态方法，final 类，构造方法面前统统的缴械了。powermock 虽然可作 Mockito 的伴侣来突破 Mockito 本身的一些局限，但是我一用它来 Mock 一个构造方法就出错Caused by: java.lang.ClassNotFoundException: org.mockito.exceptions.Reporter
原因是 Mockito 变化太快，powermock 跟不上它的步伐 -- https://github.com/powermock/powermock/issues/684，于是我只能止步。
不得已再祭出 JMockit 这号称(也确实是)一无所不能的大杀器，在此见识一下它怎么 Mock 构造函数的
本篇实例所使用的 JMockit 版本是 1.30, 当前最新版 1.31, 由于尚未被 Maven 中央仓库收录，所以暂用 1.30。在 pom.xml 中如下方式引入 Read More
Spring 的 JdbcTemplate 为我们操作数据库提供非常大的便利，不需要显式的管理资源和处理异常。在我们进入到了 Java 8 后，JdbcTemplate 方法中的回调函数可以用 Lambda 表达式进行简化，而本文要说的正是这种 Lambda 简化容易给我们带来的一个 Bug, 这是我在一个实际项目中写的单元测试发现的。
下面就是我们的一个样板代码，在我们的UserRespository中有一个方法 findAll() 用于获得所有用户：1public List<User> findAll() { 2 List<User> users = new ArrayList<>(); 3 jdbcTemplate.query("select id, name from user", rs -> { 4 while (rs.next()) { 5 users.add(new User(rs.getInt("id"), rs.getString("name"))); 6 } 7 }); 8 return users; 9}
Read More