Vim 自 7.0 开始支持 tab 页了，这就像很多数文本编辑器那样方便在多文件中切换，而不是只能使用 Buffer 暗地里来回切。默认时标签上显示 tab 序号加上当前打开的文件名。

注：Visual Studio Code 1.1.1 目前尚不支持 tab 功能。

Vim 中关于 Tab 的操作命令如下：

vim -p file1 file2 file3....   在多标签中打开多个文件

:tabe[dit] 或  :tabnew          在当前标签后打开新的标签

:tabn[ext] 或 gt         切换到下一个 tab

:tabp[revious] 或 gT   切换到上一个 tab

:tabn [N]    切换到第 N 个 tab

:tabfir[st]   切换到第 1 个 tab

:tabl[ast]    切换到最后一个 tab Read More

现在的 JMockit 已经偷偷升级到了 1.23 版了，在 JVM 上的 Mock 工具中就数它最无敌了，因为它抢夺了最佳控制点  --javaagent， 可以说它是无所不能的。一般我们使用 JMockit 是通过两种方式，new MockUp 和 new Expectations. JMock 不仅能够 Mock 类的所有方法，还能部分 Mock -- 这个是 new Expectations 的默认行为。 所以这里我们来看下在使用 new Expectations 的情况下如何对类的部份静态方法或部分实例方法进行 Mock。

大致表述一下，共分为三种情况

1. 针对类进行 Mock, 只有录制的静态方法被 Mock 住，其他的静态方法或实例方法都会调用实际实现
2. 针对某一实例进行 Mock，只在调用该实例已录制的方法才被 Mock 住，静态方法或新建实例调用任何方法都是实际实现
3. 针对类进行 Mock，但录制的是一个实例方法，那么该实例或任何新建实例在调用该录制方法时都会被 Mock 住

不知道上面在说什么，本来就是空洞无凭，所以还是下实例，假定要测试下面这个类，或者说是测试使用到下面类的其他类 Read More

在 sbt 中我们可以定义 settingKey, taskKey 和 inputKey. inputKey 接收输入的任务更具灵活性，虽然在 sbt 中 taskKey 和  inputKey 数量比例为 25:1，但仍然不可忽视了 inputKey 的贡献。

起初在阅读 sbt 关于 inputKey 的资料时，一不小心就被带入到 Parser 上去了。其实还不如开门见山，先跳过 Parser 部份，示范 inputKey 任务中直接处理用户的原生输入。

这里有两个最简单的 sbt inputKey 的示例

一. 命令后非空格起全部输入当作一个字符串

1import complete.DefaultParsers._
2
3val demo1 = inputKey[Unit]("Demo1 inputTask")
4demo1 := {
5 val input = trimmed(any.* map(_.mkString)).parsed
6 println(input)
7}

trimmed() 方法能去除了两边的空格，如果是 token(any.* map(_.mkString)).parse 则两边空格都会算上，在 demo1 abc  的 abc 两边的空格也都会算在输入参数里

> demo1 abc "abc"
abc "abc"

sbt  的  input task  参数居然默认是紧接着命令开始的，如上面如果输入是 demo1xxx, demo1 任务接收到的参数是 xxx. 如果同时也定义了另一个任务是 demo1x, 那么输入 demo1xx 就会执行 demo1x 任务，参数是 xx. 从后往前进行匹配任务名。这个还有点奇怪，因为我以前任何时候都是自然的把命令与参数用空格分开， 它却可以把命令与参数写在一起。

二. 像调用 main 方法一样传入参数

在 Scala 中借助于斜撇号我们可以使用关键字或任何字符为作为变量或方法名，例如下面的方法都是合法的：

scala> def `if`: Unit = {}
if: Unit

scala> def `我是谁?`: Unit = {}
我是谁$qmark: Unit

scala> def `just do it`: Unit = {}
just$u0020do$u0020it: Unit

对了，Scala 2.11.6 在显示有些字符时会进行编码，像上面的 ? 和 空格。而用 2.11.7 的 Scala  控制台下居然原样显示，不编码(这是在进一步试难时发现的)。

我们在用 Scala 写 JUnit 风格的单元测试, 由于 JUnit 不支持像 TestNG 那样在方法名上加描述，所以方法名必须完成自我描述。依照严格的方法命名的话，势必要用驼峰方式或下划线把单词分开，如

ef getOneHunderIfSixtyPlusFouty: Unit = { ... }
def get_one_hunder_if_sixty_plus_forty: Unit = { ... }

注：如果用 Scala 写 Spec 测试代码另当别论，因为有些情况下必须用 JUnit 风格(就用 JMockit 时)

PlayFramework 已全面向 Google Guice 演进, 由于我们的项目是从 Play 2.0 开始搭建, 现虽已升级到了 2.4.6, 但对 Guice 的还没抱得那么的紧, 有点积重而慢步前挪. Google Guice 也是一个依赖注入(DI) 容器, 据说它比 Spring 快了很多很多, 是轻量级项目或框架首选, Google 出品俱是精品.

既然它是轻量级的 DI, 那么必须呈上一个最轻量级的入门, 官方的 Get Started 文档其实啰嗦了点, 对于 BillingService 依赖的 CreditCardProcess, TransactionLog, 和 Receipt 都未有交待, 算不上一个完整项目. 所以我这里尽量简化, 又不偏离一个最简单的项目模型. 那就是下面那个例子, 它实现了在不同时间发出不同的问候.

项目需要依赖 Guice 及它的子依赖, 这得看你是用什么来管理依赖的, 依照  http://mvnrepository.com/artifact/com.google.inject/guice/4.0 根据实际情况加上依赖配置, 前面这个链接默认为 sbt 的, 我还真偏爱了 sbt, 若是 Maven 就配置 Maven 的 pom.xml 吧. Guice 的引入带上以下几个依赖包

   +-com.google.inject:guice:4.0
     +-aopalliance:aopalliance:1.0
     +-com.google.guava:guava:16.0.1
     +-javax.inject:javax.inject:1

Guice 目前是 4.0. Read More