一路阅读完第五章直接跳跃到第十章有关宏的内容，宏的录制和回放功能是多数编辑器都会提供，但我却基本不用这一功能。在 Vim 中宏比点号(.) 更有效的处理重复性操作，既然作为一个 Vimer, 以重复操作为耻，因而十分有必要对它加以了解和掌握的，又是一个一分钟上手需一辈子来掌握的东西。
1. 宏是录制在某个寄存器中，用 q{register}启动录制，例如qa, 然后执行一系操作，再次按q结束录制，第一次回放用@{register}, 如@a,以后多次执行上一次宏回放可用@@.也可以支持数字,如10@a, 或10@@.:reg a可查看寄存器a中宏的内容
2. 录制宏的一条金律是：确保每一条命令是可重复的。h,j,k,l, 没什么意义，而0e,A,I就是可重复的。当回放宏时遇到光标移动失败时, 如光标已在行首，宏中有h操作，那么后续的操作被放弃，根据visualbell配置可能有响声提示。宏的 motion 失败即放弃的特性让我们在重复执行宏时可以用一个足够大的数字，如200@@, 反正无副作用
3. 宏的序列执行与并发执行，当用5@a执行宏"a 0f.r)w~j, 其实是把宏放在一个队列里，往下跳行执行，其他任何一行执行失败，后续行将得不到更新。如果针对宏"a 0f.r)w~, 对选择的多行执行:'<,'>normal @a时效果就不一样了，它的意思是针对选择的多行单独执行宏，任何行的失败互不影响，所以它是并发执行的 Read More
很早就想写下这篇日志的，因为实际使用 AWS S3 来存取文件使用什么样的 Key 对性能的影响是极其大的。当然，如果你对 S3 的并发请求在 50 以内是无所谓的，要是并发要求很高的话，Key 的选择就变得至关重要的，不可不察。S3 Key 从第一个字符算起的任意长度子字符串都被称作前缀(prefix), 而对 S3 文件访问性能影响不在完整的 Key, 恰恰是那个前缀。
背景：我们最初在使用 S3 时，存储的文件的 Key 直接用了数据库的自增 ID，于是保存到 Bucket 中大概下面那样子的examplebucket/12134850.csv
Bucket 中有百万个文件，当初测试时 60 个左右的 Lambda 实例同时访问这个 Bucket 中不同的文件时，加载每个 S3 文件的时间大约在几百毫秒，然后并发上到 70， 80 后加载同样大小的 S3 文件的时间陡然增加到 10 秒以上，并发继续上到 100 以上直接导致众多 S3 的请求超时。后来了解到虽然一个 Bucket 中放多少个文件是没有限制的，而且官方文档说了文件多了并不影响访问的性能，但背后却有一个文件的分区存储机制，这个才是关键。
examplebucket/12134851.csv
examplebucket/12134852.csv
examplebucket/12134853.csv
examplebucket/12134854.csv
examplebucket/12134855.csv
examplebucket/12134856.csv
examplebucket/12134857.csv
examplebucket/12134858.csv
S3 的分区存储就像是硬盘分区，或文件分布在不同硬盘上的效果。试想一下，如果我们多个线程同时从一块硬盘上读取数据，每个线程需共同一个磁头来读取数据，性能就差; 但如果那些线程同时从不同的硬盘上读取各自的数据，那性能就大大提升了，它们互不干扰。在使用机械硬盘时我有过这样的体验，在同一个磁盘上拷贝文件比从一个磁盘拷贝到另一个磁盘要慢很多。 Read More1. 学习完前面的三大模式：正常模式，插入模式和可视模式后，现在步入了命令模式。
:,/或?, 和<C-r>=分别进入到Ex命令，搜索和表达式，它们都被称作命令模式, 以前还常常把正常模式说成是命令模式。:后的是Ex命令，是因为我们仍然沿袭了 Vim 的前身 Ex。我在 Mac 下输入命令ex就会看到这个
进入到 Vim 的 Ex mode, 输入
visual命令就是正常的 Vim 界面。Vim 之于 Ex 就像 Gui 之于 Shell, Vim 的 Ex 命令可以做任何操作，见:h ex-cmd-index。2. 命令模式在
:提示符下输入时可以使用插入模式下的很多命令，如<C-w>,<C-u>,<C-k>,<C-v>,<C-r>{reg}, 甚至是<C-r>=，就是不能用 motion 命令，光标移得靠方向键3. 在阅读本章之前对 Vi 的命令模式只能用不觉明厉来形容，它对我的贡献仅仅是
:wq之类的，模式查找，简单替换，再就是执行一些未设置快捷键插件功能。也一直未理解替换怎么是%s/abc/dev, 只是依葫芦画瓢，现在终于可以在本章中理解那些命令了。从中真的能体会到 Ex 命令模式的乐趣，Ex 是不会把整个文件内容显示在屏幕上的, Ex 命令通常由 范围 + 命令 组成。:2 -- 光标跳到第一行，正常模式下可以 2G, 或 2gg
:print -- 打印当前行的内容范围和命令一般会写在一块，范围可借用同样意义的特殊字符，默认操作当前行，因此下面一系列的命令就好理解了 Read More
Spring 项目中把大量的 SQL 分散在 Java 代码中，无 Here Doc 的情况下用加号来连接写着实在是不爽，于是之前思考这个 Spring 项目中把 SQL 语句写在 .sql 文件中 -- 把它们写在 *.sql 文件中，但是这个 *.sql 需要特定的格式来标识属性 Key--!select.user
而且还需要一个额外的类 SqlPropertySourceFactory 来解析上面的 *.sql 文件, 识别出 select.user 是 Key, 紧接着后面的块是相应的属性值，用注解引用它时还有点额外的 factory 属性来配置，如
select id, firstname, lastname, address --!update.user
update ........@PropertySource(value = "classpath:sql/queries.sql", factory = SqlPropertySourceFactory.class)
所以一直在思考是否能够再简单些，是否能用一个自定义的注解，如@SqlPropertySource("classpath:sql/queries.sql")
捉摸了很久，似乎有点难度，不过再不断发掘的过程中找到了这个类org.springframework.core.io.support.PropertiesLoaderUtils, 有下面的代码片断 Read More
三个月前写过一篇 Mockito 中捕获 mock 对象方法的调用参数，一般项目中 Mockito 不决求助于 JMockit, 同样的在 JMockit 也需对捕获被 Mock 的方法调用参数。当我们用new Expectations(){{}}打桩并在后面断言了返回值，那就无需捕获参数来断言，匹配到了方法调用即证明传入的参数也是对的，如下面的代码所示1public class UserServiceTest { 2 3 @Mocked 4 private UserDao userDao; 5 6 @Test 7 public void couldCallUserDaoToAddUser() { 8 new Expectations(){{ 9 userDao.findById(123); 10 result = "Yanbin"; 11 }}; 12 13 UserService userService = new UserService(userDao); 14 String user = userService.findBy(123); 15 16 assertThat(user).isEqualTo("Yanbin"); //这里断言成功也就证明了 userDao.findById(123) 方法被调用，参数必须是 123 17 } 18}
但如果是未打桩的方法，或打桩是用的模糊参数(withInstanceOf(String.class)), 或是无返回值的方法就要事后对是否调用了某个方法以及传入什么参数的情况进行断言。 Read More
第四章：注释
- 别给糟糕的代码加注释 -- 重新写吧
- 什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧，提供错误信息的注释更有破坏性
- 若编程语方足够有表达力，或者我们长于用这些语方来表达意图，就不那么需要注释 -- 也许根本不需要
- 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败
- 不准确的注释要比没注释坏得多。它们满口胡言。代码，只有代码能忠实的告诉你它做的事
- 好注释不多，如法律信息，警示等。我都不觉得
TODO是多好的东西 - 大多数注释都是坏注释，甚至一些 IDE 自动生成的代码也加一堆的废话注释，分散阅读注意力。我也写过那种日志式注释，这本是版本控制系统干的事。
- 很奇怪 IntelliJ IDEA 还在自动为新建的类加下创建者，代码是团队共有，时间长了根本就与作者无半毛关系。我经常碰到这种写有作者的代码哭笑不得，直接把原作者改了或删了也不太好，还不如把文件删了，新建一个没有作者注释的类
- 直接把代码注释掉是种讨厌的做法，自己可能不会再启用，其他人以为很重要更不敢删。不用了最好果断删掉，版本控制系统会帮你记住历史。
- 个人认为，注释会胡说八道，产品代码和测试代码不会撒谎。有功夫写注释还不如写好测试用例，测试需要维护，它本身就是最真实的文档。
修改私有属性来 Mock 可能不是一种很好的测试方式, 因为属性名是动态的，但有时不得已而为了，例如下面的代码：1public class UserService { 2 private ExternalApi external = ExternalApi.default(); 3 private UserDao userDao; 4 5 public UserService(UserDao userDao) { 6 this.userDao = userDao; 7 } 8 9 public User findUserById(int id) { 10 return userDao.findById(external.convertId(id)); 11 } 12}
测试时欲隔离对 ExternalApi 的外部依赖, 当然可以把它也作为构造函数的一个参数，这样创建 UserService 实例时就可以 Mock external 属性。不过 external 经常是不变的，所以作为方法参数的必要性也不大。这就希望能在构造出 UserService 之后对 external 私有属性进行 Mock 处理。
在 Mockito 1.x 和 2.x 下要使用不同的方式，分别使用到 Whitebox 和 FieldSetter 类，它们都来自于mockito.internal.util.reflection包，可见 Mockito 打心底不推荐直接使用它们，但谁叫它们是 public 的呢。还有一种方式是使用 PowerMock + Mockito, 这是后话。 Read More- 一句话概要：对 Lambda 环境变量的任何改动都会引起一次 Lambda 的冷启动，大可放心在 handleRequest(...) 方法外使用环境变量。
从 AWS 上 Java Lambda 应用记要 中，我学到了 Lambda 的实例是跨请求共享的，所以为使用 Lambda 配置的环境变量时曾写出了下面复杂而多余的 AWS Lambda 代码:这段代码看起来很在理，既然 Lambda 实例是共享的，那么在必变环境变量之后就可能不会重新初始始化实例，所以在每次的请求方法中对比如果环境变量值改动了就重新用最新的配置值来初始化线程池。然而上面的代码结结实实是多余的，真是把 Lambda 想得太简单了，如果是很多环境变量岂不是逐一判断。 Read More1public class Handler implements RequestHandler<SNSEvent, String> { 2 3 private int threadPoolSize = getThreadPoolSizeFromEnv(); 4 private ExecutorService threadPool = Executors.newFixedThreadPool(threadPoolSize); 5 6 @Override 7 public String handleRequest(SNSEvent snsEvent, Context context) { 8 int configuredThreadPoolSize = getThreadPoolSizeFromEnv(); 9 if(configuredThreadPoolSize != threadPoolSize) { 10 threadPoolSize = configuredThreadPoolSize; 11 threadPool = Executors.newFixedThreadPool(threadPoolSize); 12 } 13 14 return "Hello Lambda"; 15 } 16 17 private int getThreadPoolSizeFromEnv() { 18 return Integer.parseInt(System.getenv().getOrDefault("threadpool_size", "50")); 19 } 20}