有种流传甚广的说法：如果你想将咖啡豆磨成代码，那就去买台“程序员”好了。确实，如果你在一家编程高手云集的互联网公司工作，问问你身边那些 程序员们，他们一般什么时候效率最高，点子最好？得到的答案，大部分是半夜——不管前半夜，还是后半夜。有些习惯在早上四点起床，然后工作到日出，还有些 人则是习惯在早上四点后才睡觉。
如果只是为了避开无谓的干扰，何不关上门，带上耳机，为何一定要在深夜工作呢？
我认为主要有三条原因：创作者的日程表、困倦的大脑，以及闪亮的屏幕。
创作者的日程表
通常来说，这个世界有两种日程表，一种属于管理者，一种属于创作者。传统的管理者日程表将一天按小时划分，而通常十分钟的打扰，对于程序员来说，可能需要一个小时去重新整理思路。 阅读全文 >>
有时候我们要在 Play 应用中调用其他的 HTTP 服务. Play 是通过它的 play.api.libs.ws.WS 库对此支持的, 该库提供了进行异步的 HTTP 调用.
任何由 play.api.libs.ws.WS 发出的调用都必须返回 Promise[play.api.libs.ws.Response], 我们可以接着可用 Play 的异步机制来处理它.
Unmi 注: 这里有必须挪出 Play 1 和 Play 2 的 WS 稍加对比:
Play 1 中 play.libs.WS 类，Play 2 里是 play.api.libs.ws.WS，Play 2 中许多给外部调用的 API 都放在 play.api.libs 包中了。
Play 1 的 play.libs.WS.WSRequest 中有 get():HttpResponse, getAsync():Promise<HttpResponse>, put():HttpResponse, putAsync():Promise<HttpResponse>，它把同步和异步调用分得很清楚。
而 Play 2 的 play.api.libs.ws.WS.WSRequestHolder 里只有 get(): Promise<Response>, post(): Promise<Response> 这样方法，在这个位置上，它不再分同步还是调用，这个任务交给 Async 方法去决定。
对异步请求的数据获仍然是由 Action 处理，如 Play 1 中 Action 的各个 await() 方法; Play 2 里的 Action 用 Async 方法。 阅读全文 >>
默认的 Cache API 实现是用的 EHCache. 你也可以通过插件来提供自己的缓存实现.
访问 Cache API
缓存 API 由 play.api.cache.Cache 对象提供. 它需要注册一个缓存插件.
注: Cache API 尽力保持自身最小化，而允许插入多种实现. 如果你需要一个更具体的 API, 那就通过你自己的缓存插件来使用它.
Unmi 注: EhCachePlugin 的注册方式可以查看 play_x.x.x.jar(比如 $PLAY_HOME/repository/local/play/play_2.9.1/2.0.4/jars/play_2.9.1.jar) 包中的 play.plugins 中的内容：
|
1 2 3 4 5 6 7 8 |
100:play.api.i18n.MessagesPlugin 200:play.api.db.BoneCPPlugin 300:play.db.ebean.EbeanPlugin 400:play.db.jpa.JPAPlugin 500:play.api.db.evolutions.EvolutionsPlugin 600:play.api.cache.EhCachePlugin 1000:play.api.libs.concurrent.AkkaPlugin 10000:play.api.GlobalPlugin |
这是 Play2.0.4 默认注册的插件，其中就包含了 600:play.api.cache.EhCachePlugin 插件。 阅读全文 >>
Unmi 注: 当你采用 TDD 进行开发过一段时间后，很快你就会对 TDD 产生依恋了。没直正去实践过 TDD，对于测试先行的提法只会觉得是一种理想状态。其实不然，从此开发模式变成 测试->实现->重构，同时也指导你的设计，基础架构并不需要那么稳定，它总在应需而变。所以 TDD 让你不该总在项目中后期抱怨架构设计不好之类的事，因为主动权一直在你。废话一堆后就是：测试真的很重要，尽快进入角色吧。
测试你的应用程序
测试源代码文件必须放置在你的应用的 test 目录下. 你可以在 Play 控制台下用 test 和 test-only 任务来运行它们.
使用 specs2
测试一个 Play 2 应用默认的方式是采用 specs2.
单元规格须继承自 org.specs2.mutable.Specification 特质并应用 should/in 的格式: 阅读全文 >>
Unmi 注: 有了前面对 Play 2.0 的 Json 支持的了解。见：1. Play 2.0 中文资料 - Play JSON 库，2. Play 2.0 中文资料 - 处理和响应 JSON 请求， 3. Play 2.0 中文资料 - Play JSON 库使用泛型。现在来看 Play 2.0 对 XML 的支持就更简单了，原因是 Scala 使用 Json 还需依赖于第三方的库 Jackson，而 Scala 对 XML 的支持直接利益于它的内建语法。如在 Scala 控制台下：
上面演示了 Scala XML 遍历 XML，访问属性，文本节点。方法和遍历 JSON 类似，也有 \ 和 \\ 方法。例如 user\"@name" 访问 name 属性。
而且有了 Scala 这样的内建语法，想要实现 toXML, fromXML 方法也很简单。
处理 XML 请求
XML 请求是指请求体为一个有效的 XML 数据的 HTTP 请求. 必须用 Content-Type 头指定 MIME 类型为 text/xml. 阅读全文 >>
概述
当使用基于 JSON 库的 typeclass(Unmi: typeclass 还没摸准翻译成什么词较合适，此前译作 类型类，觉得有点不妥，所以暂时保留原样) 时，可能会把泛型支持包含进这些 typeclass 中来. 针对基于终端控制查询参数，使用基本的结构作为查询结果的 REST API 来说可能是一个很好的应用方式.
Scala 对泛型的支持
给定如下基本的结构作为搜索结果:
|
1 2 3 4 5 6 |
case class SearchResults[T]( elements: List[T], page: Int, pageSize: Int, total :Int ) |
Unmi 注: 上面 case class 涉及到了 Scala 的样本类的特性，Scala 会给这个类自动添加一些句法：1）添加与类名一致的工厂方法，2）参数列表中的所有参数前隐式获得了 val 前缀，即会由相应的的实例变量保持状态，3）自动添加了 toString, hashCode, 和 equals 方法。 阅读全文 >>
处理 JSON 请求
JSON 请求是一个以有效的 JSON 数据作为请求体的 HTTP 请求. 它必须指定 Content-Type 头为 text/json 或是 application/json 作为 mime 类型.
默认的， Action 使用 any content 作为 Body 解析器, 这让你接收 Body 并解析为 JSON (实际为 JsValue):
|
1 2 3 4 5 6 7 8 9 10 11 |
def sayHello = Action { request => request.body.asJson.map { json => (json \ "name").asOpt[String].map { name => Ok("Hello " + name) }.getOrElse { BadRequest("Missing parameter [name]") } }.getOrElse { BadRequest("Expecting Json data") } } |
更好的(也是更简单的)办法是指定你自己的 BodyParser 用以告诉 Play 把类容 Body 直接解析为 JSON: 阅读全文 >>
概述
推荐的处理 JSON 的方式是使用 Play 基于 JSON 库的类型类, 位置在 play.api.libs.json.
这个库是构建于 Jerkson, 之上的，它又是基于 Java 的超快的 JSON 库 Jackson 的 Scala 封闭。
Unmi 注：在 Play 1.x 所用的 JSON 库是 Gson，而 Play 2.0 后更换成了 Jackson。还得 Play 2.0 是基于 SBT 构建的，所以 Play 2.0 的所有的 jar 都是在 $PLAY_HOME/repository/local 目录中。
这样做的好处是无论是 Java 还是 Scala 的 Play 应用依赖了相同的底层库 (Jackson), 同时 Scala 用户可以享受到 Play’s JSON 所带来的额外的类型安全性.
play.api.libs.json 包含有七种 JSON 数据类型:
JsObjectJsNullJsUndefinedJsBooleanJsNumberJsArrayJsString上面的类型都继承自通用的 JSON 值类型, JsValue. 阅读全文 >>