sbt プラグインをテストする

テストの話をしよう。一度プラグインを書いてしまうと、どうしても長期的なものになってしまう。新しい機能を加え続ける（もしくはバグを直し続ける）ためにはテストを書くのが合理的だ。だけど、ビルドツールのプラグインのテストなんてどうやって書けばいいんだろう？もちろん飛ぶんだよ。

scripted test framework

sbt は、scripted test framework というものが付いてきて、ビルドの筋書きをスクリプトに書くことができる。これは、もともと 変更の自動検知や、部分コンパイルなどの複雑な状況下で sbt 自体をテストするために書かれたものだ:

ここで、仮に B.scala を削除するが、A.scala には変更を加えないものとする。ここで、再コンパイルすると、A から参照される B が存在しないために、エラーが得られるはずだ。 [中略 (非常に複雑なことが書いてある)]

scripted test framework は、sbt が以上に書かれたようなケースを的確に処理しているかを確認するために使われている。

正確には、このフレームワークは siasia として知られる Artyom Olshevskiy 氏により移植された scripted-plugin 経由で利用可能だが、これは正式なコードベースに取り込まれている。

ステップ 1: snapshot

scripted-plugin はプラグインをローカルに publish するため、まずは version を -SNAPSHOT なものに設定しよう。

ステップ 2: scripted-plugin

次に、scripted-plugin をプラグインのビルドに加える。project/scripted.sbt:

libraryDependencies <+= (sbtVersion) { sv =>
  "org.scala-sbt" % "scripted-plugin" % sv
}

以下を scripted.sbt に加える:

ScriptedPlugin.scriptedSettings

scriptedLaunchOpts := { scriptedLaunchOpts.value ++
  Seq("-Xmx1024M", "-XX:MaxPermSize=256M", "-Dplugin.version=" + version.value)
}

scriptedBufferLog := false

ステップ 3: src/sbt-test

src/sbt-test/<テストグループ>/<テスト名> というディレクトリ構造を作る。とりあえず、src/sbt-test/<プラグイン名>/simple から始めるとする。

sff4s: simple future facade for Scala

future の実装には様々なものがあるけど、標準ライブラリの中に共通の親 trait があれば、特定のプラットフォームスタックにコードを依存させずにこの概念を表現できるのにと思っていた。そう思う人が他にもいるかは分からないけど、ライブラリの作者なんかには役に立つんじゃないかな。取り敢えずこれが、sff4s を書いた動機だ。

future って何?

多分名前ぐらいは聞いたことあるかもしれないけど、一応おさらいしよう。future値（promise とも呼ばれる）は未完の計算を表現する。

• future値は未完の計算を表現する。

これがよく使われる説明だけど、それだけでは分からない。ここで言外に含まれているのは、その計算は裏で行われているということだ。それは同じコンピュータ内の別のスレッドか、別のサーバの中かもしれないし、行列待ちでまだ計算は始まってさえいないかもしれない。とにかく、計算は現在の制御フローの外で行われているということだ。

• 計算はどこか別の所で行われる。

future値のもう一つの側面は、そのうちに計算結果を得られるということだ。Scala の場合は def apply() を呼び出すなどの明示的なステップを要する。計算が未完の場合は、ブロック(block)する。つまり、計算結果が得られるまで待たされる（もしくはタイムアウトする）。

• future値から計算結果を得ることができる。

最初に future値が宣言された時には計算結果は有るかもしれないし、まだ無いかもしれない。うまくいけば、ある時点で結果が到着し、オブジェクトの内部構造が変更される。これを、future値を「解決」(resolve)したという。勝手に状態が変わるものというのはプログラミングではあまり見かけないので、少し不気味ではある。

• 計算結果を解決するための裏口がある。

これまでで、最も単純な形の future値を記述した。実際に役に立つには他の機能も必要だけど、これでも使えないことはない。ちょっと使用例をみてみよう:

val factory = sff4s.impl.ActorsFuture
val f = factory future {
  Thread.sleep(1000)
  1
}
f() // => これは 1秒間ブロックした後で 1 を返す

細かい事は気にしないで、最後の一行の振る舞いだけ見てほしい。このように、計算結果を取得することを、強要(forcing)するともいう。最小限の API は以下のようになる。

Future v0.1

abstract class Future[+A] {
  /** 計算結果を強要して無期限にブロックする */
  def apply(): A
}

Scala から使用可能な future値の実装にはいくつかあるけど、どれも一から書かれてる。上のような共通な親クラスがあれば、特定のライブラリに依存しないコードを書くことができる。

まだ来ない?

Future v0.1 に対して唯一できる事が計算結果が戻ってくるまでブロックしてしまうので、あまりにも不便だ。待つことしかできないから future を使わないほうがいい。そのため、全ての future値が提供するもう一つの機能として、計算結果の用意ができたかを確かめるノンブロッキング(non-blocking)な方法がある。これは実装によって isDone、isSet、isDefined、isCompleted などと呼ばれているが、全て同じ意味だ。今のところ、僕の好みとしては def isDefined: Boolean がいいと思う。future を概念的に Option の変数として考えることができるからだ。

モナドはメタファーではない

Scala界の関数型プログラミング一派を代表する論客の一人、@djspiewak が 2010年に書いた “Monads Are Not Metaphors” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2010年12月27日 Daniel Spiewak 著 2011年5月29日 e.e d3si9n 訳

僕は今、約束を破るところだ。およそ三年前、僕は絶対にモナドの記事だけは書かないと自分に約束した。既にモナドに関する記事は有り余っている。記事の数が多すぎてその多さだけで多くの人は混乱している。しかも全員がモナドに対して異なる扱い方をしているため、モナドの概念を初めて学ぼうとする者は、ブリトー、宇宙服、象、砂漠のベドウィン (訳注: アラブ系遊牧民) の共通項を探す努力をするハメになっている。

僕は、この混乱した喩え話のサーカスにわざわざもう一つ追加するようなことはしない。まず、どの喩え話も完全には正確では無い。どの喩えも全体像を伝えきれていないし、いくつかは重要な点に関して露骨に誤解を招くような内容になっている。メキシコ料理や宇宙（そら）に思いをはせることでは、絶対にモナドを理解することはできない。モナドを理解する唯一の見方は、それをありのままの姿、つまり数学的概念として見ることだ。

実戦での Scala: Cake パターンを用いた Dependency Injection (DI)

Akka の作者として益々注目を集めている Jonas Bonér が 2008年に書いた “Real-World Scala: Dependency Injection (DI)” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2008年10月6日 Jonas Bonér 著 2011年4月22日 eed3si9n 訳

さて、実戦での Scala シリーズ第二弾の今回は、Scala を用いた Depenency Injection (DI) の実装をみていきたい。Scala は、備わっている言語機構だけを用いても何通りかの DI を実現できる非常に豊かでディープな言語だが、必要に応じて既存の Java DI フレームワークを使うこともできる。

Triental では、一つの戦略に落ち着くまで三つの異なる方法を試した。以下のように話を進めていく。まず、現行の DI の実現方法を詳しく説明した後で、試した他の方法も簡単にカバーする。

Cake パターンを用いる

私たちが用いている現行の戦略は、いわゆる Cake パターンに基づいている。このパターンは、Martin Odersky の論文 Scalable Component Abstractions において、Ordersky と彼のチームが Scala のコンパイラを構成した方法として最初に発表された。このパターンがどのようにして DI を実現するのかということを日本語で説明する事を試みるよりも、（私たちの実際に使っているコードに大まかに基づいた）愚直なサンプルコードをみてみよう。

注意: 順を追って、最終バージョンに向けてリファクタリングしながら説明していくので、最終バージョンを読んで理解するまでは、「ダメじゃん!」と叫ぶのは待ってほしい（もちろん、読了後にどうしてもと言うなら批判、賞賛、意見、アイディアなどを送ってもいい）。また、このサンプルコードは、このようなサンプルの例にもれず、非常に複雑な方法で取るに足りない事を行っているようにみえるが、我慢して大規模システムでの実際のサービスを想像して、どのように応用できるかを想像して欲しい。

まずは、UserRepository (DAO、Data Access Object) を実装しよう。

// 実際の永続化は何もしていなくて、画面にユーザを表示するだけのダミー。 
class UserRepository {  
  def authenticate(user: User): User = {   
    println("authenticating user: " + user)  
    user  
   }  
  def create(user: User) = println("creating user: " + user)  
  def delete(user: User) = println("deleting user: " + user)  
}

trait インターフェイスとその実装に分けて実装することもできたが、話を簡単にするために、敢えてここではそうしなかった。

Scala と Json で tweed を織る

次々とヤバいコードを紡ぎ出し NY Scala シーンの中心的存在であり続ける @n8han が二年前に書いた “Weaving tweed with Scala and Json” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2009年5月27日 n8han 著 2011年1月2日 eed3si9n 訳

抽出子は、Programming in Scala の 24章にのみ記述されている Scala の秘密機能で、この春の大ヒットだ。今までは皆 case Some(thing) => kerpow(thing) で満足だったのが、今では抽出子を書けなければ #scala freenode にも入れてもらえない。ズルをすれば Scala チャンネルの硬派な常連たちは君のコンピュータをハックして驚くほど馬鹿げたドールハウスを連続再生して（ただし混浴シャワーシーンを除く）、番組の「アクティブ」のように意味のあるタイピングを諦めなければいけない。

訳注。以下 Draco より抜粋 ロッサム・コーポレーションは人間の人格、経験をすべて消し、新しい人格を植え付ける技術を開発した。彼らはこの技術を用いて、戦闘用の人形アクティブを生み出した。 人形たちはドールハウスという施設で生活している。誰かの人格を移植され、任務に挑む。 アクティブの一人、エコーは記憶のリライト中にエラーが起こり、完全には記憶が消されていなかった。

この抽出子はちょっとチクっとしますからね

命からがら逃げ出した僕は抽出子をありとあらゆる状況に適用するよう努めた。例えば、JavaScript インタプリタが理解できるお洒落な文字列、Json オブジェクトだ。抽出子を使えば case 構文でこのように処理することができる:

import dispatch.json.Js
val echo = Js("""{"acting": "無表情で前を見ている"}""")
object Echo extends Js { val acting = 'acting ? str }
echo match {
  case Echo.acting(hmm) => hmm
  case _ => "pshaw"
}

res0: String = staring blankly ahead

Symbol 'acting に対して ? を呼び出すことで抽出子が作成される。Symbol には ? メソッドはないが暗黙の変換でそれをもつオブジェクトに変換されている。Echo　はいつも演技してるということが分かっているので、この抽出子を使って直接代入することもできる:

IntelliJ IDEA のための Twilight

Scala をやりながら他の IDE も試しましたが、結局 TextMate に戻っています。 今回巷で話題の IntelliJ IDEA に便乗するにあたって、Twilight theme を作りました。

型クラスによる XML データバインディング

結局の所，scalaxb のユーザはエンティティ・オブジェクトが表現する現実の問題に興味があるのであって，それがどう XML に永続化されるかといったことではない．だから，いつかデータバインディングの実装をシングルトン/コンパニオン・オブジェクトから追い出さなければいけないことは分かっていた．つい最近までデータバインディングの実装は以下のように生成されていた:

object Address extends rt.ElemNameParser[Address] {
  val targetNamespace = "http://www.example.com/IPO"

  def parser(node: scala.xml.Node): Parser[Address] =
    ...

  def toXML(__obj: Address, __namespace: String, __elementLabel: String, __scope: scala.xml.NamespaceBinding): scala.xml.NodeSeq =
    ...
}

つまり，scalaxb は Address そのものとは関係の無い XML データバインディングのために一等地をハイジャックしてしまったのだ．

adapter

まず最初に以下のような adapter オブジェクトに追い出すことを考えた:

object DefaultXMLAdapter {
  object AddressAdapter extends rt.ElemNameParser[Address] {
    val targetNamespace = "http://www.example.com/IPO"

    def parser(node: scala.xml.Node): Parser[Address] =
      ...

    def toXML(__obj: Address, __namespace: String, __elementLabel: String, __scope: scala.xml.NamespaceBinding): scala.xml.NodeSeq =
      ...
  }
}

この方法にはいくつかの問題がある．まず，scalaxb のランタイムである DataRecord が，今まではコンパニオン・オブジェクトの暗黙性を使ってたどっていた toXML にたどり着けないということだ．コンパニオン・オブジェクトの興味深い一面として「コンパイラは，暗黙 (implicit) の定義を変換元の型と変換先の型のコンパニオン・オブジェクトにも探しにいく」(Programming in Scala, p. 441) というものがある．

第二の問題は，アイデンティティー問題だ．ユーザのコードの邪魔にならないようにしようとしているのに，Address オブジェクトのためには DefeaultXMLAdapter.AddressAdapter，Item のためには DefeaultXMLAdapter.ItemAdapterなどと，　かえって目に障るものを導入してしまった．ユーザが知っている必要があるのは Address が XML に変換できるという事実だけあって，それがどう行われているかというのは余計な詳細でしかない．

第三の問題として，拡張性の問題がある．例えば，Address を定義する ipo.xsd と，Address を使う purchaseReport要素を定義する report.xsd の二つのスキーマがあるとする．問題は，report.DefaultXMLAdapter.PurchaseReportAdapter は ipo.DefaultXMLAdapter.AddressAdapter を参照するため，ipo.DefaultXMLAdapter を拡張してカスタムのデータバインディングをすることができないということだ．

sjson: Scala の型クラスによる JSON シリアライゼーション

Debasish Ghosh さん (@debasishg) の “sjson: Now offers Type Class based JSON Serialization in Scala” を翻訳しました． 元記事はこちら: http://debasishg.blogspot.com/2010/07/sjson-now-offers-type-class-based-json.html (翻訳の公開は本人より許諾済みです) 翻訳の間違い等があれば遠慮なくご指摘ください

長い間 sjson のシリアライゼーション API はリフレクションに依存するものだった．この方法の長所としては，縁の下ではリフレクションによる実装が頑張っていても API は使いやすくすることができたということだ．

しかし，JSON 構造と Scala のオブジェクトでは型情報の豊かさに大きな違いがあることを忘れてはいけない．Scala から JSON にいくときに何らかの形で型情報をシリアライゼーションプロトコルの一部として保存しないかぎり，可逆変換させるのは場合によってはとてもトリッキーで難しいことになる．特に JVM では type erasure のせいで JSON構造にシリアル化した Scala オブジェクトの中には元に戻すのがほぼ不可能なものもあるだろう．

ver 0.7 より sjson は元のものに加えリフレクションを使わない JSON シリアライゼーションプロトコルを用意した．これはユーザが任意のオブジェクトから JSON へシリアル化する自分のプロトコルを規定できるようになった．リフレクションによる JSON シリアライゼーションではアノテーションで行っていたものをカスタムプロトコルを自分で実装することで実現することができる．

sjons の型クラスによるシリアライゼーションは David MacIver による素晴らしい sbinary (現在は Mark Harrah によりメンテされいる) にインスパイアされており，同じプロトコルを使いまた実装レベルでも色々と盗ませてもらった．

型クラスの基礎的概念への入門，Scala での実装，そして型クラスを使ったシリアライゼーションプロトコルが Scala でどう設計できるかについては，数週間前に書いた以下の blog 記事を参照してほしい:

• Scala Implicits: 型クラス襲来
• Scala 型クラスへのリファクタリング

組み込み型の JSON シリアライゼーション

これは sjson でデフォルトのシリアライゼーションプロトコルを使った REPL セッションの一例だ…

Scala Implicits: 型クラス、襲来

Debasish Ghosh さん (@debasishg) の “Scala Implicits : Type Classes Here I Come” を翻訳しました． 元記事はこちら: http://debasishg.blogspot.com/2010/06/scala-implicits-type-classes-here-i.html (翻訳の公開は本人より許諾済みです) 翻訳の間違い等があれば遠慮なくご指摘ください．

先日 Twitter 上で Daniel と Scala での型クラスについて論議していると，突然このトピックに関する書きかけだった記事を発見した．これを読んでもあなたは特に目新しい事を発見するわけではないが，型クラスに基づいた思考はあなたの設計の幅に価値を与えることができると思う．この記事を書き始めたのはしばらく前に設計の直交性についての記事 (原文)を公開したときのことだ．

まずは GoF の Adapter パターンから始めよう．委譲型の Adapter はよく勧められる合成(composition)というテクニック用いて抽象体(abstraction)¹どうしをバインドする．

設計の直交性のときと同じ例を使うと，

case class Address(no: Int, street: String, city: String, 
  state: String, zip: String)

これを LabelMaker というインターフェイスに適合させたいとする．つまり，我々は Address オブジェクトを LabelMaker として使いたい．

trait LabelMaker[T] {
  def toLabel(value: T): String
}

インターフェイス変換を行うアダプターは…

// Adapter クラス
case class AddressLabelMaker extends LabelMaker[Address] {
  def toLabel(address: Address) = {
    import address._
    "%d %s, %s, %s - %s".format(no, street, city, state, zip)
  }
}

// この Adapter は Address オブジェクトに LabelMaker のインターフェイスを提供する．
AddressLabelMaker().toLabel(Address(100, "Monroe Street", "Denver", "CO", "80231"))

さて，上の設計で我々が副次的に導入してしまった複雑さはなんだろう？

Scala 型クラスへのリファクタリング

Debasish Ghosh さん (@debasishg) の “Refactoring into Scala Type Classes” を翻訳しました． 元記事はこちら: http://debasishg.blogspot.com/2010/07/refactoring-into-scala-type-classes.html (翻訳の公開は本人より許諾済みです) 翻訳の間違い等があれば遠慮なくご指摘ください．

二週間ほど前に Scala の暗黙の(implicit)パラメータを用いた型クラスの実装について書いた．型クラスはある抽象体(abstraction)についての直交した関心事を，抽象体そのものに直接組み込むことなくモデル化することができる．これでコアな抽象体から余計なものを取り去って，別々の独立したクラス構造に変えていくことができる．最近 Akka actor のシリアライゼーションをリファクタリングして型クラスの恩恵に関する実地的な知見を得ることができたので，ここに報告したい．

最初は継承と trait でうまくいくと思った…

… しかし，それは長続きしなかった．Jonas Boner と筆者の間で actor のシリアライゼーションに関して面白い論議があり，以下のような設計が生まれた …

trait SerializableActor extends Actor 
trait StatelessSerializableActor extends SerializableActor

trait StatefulSerializerSerializableActor extends SerializableActor {
  val serializer: Serializer
  //..
}

trait StatefulWrappedSerializableActor extends SerializableActor {
  def toBinary: Array[Byte]
  def fromBinary(bytes: Array[Byte])
}

// .. 以下続く

このような trait はシリアライゼーションという関心事をコアな actor の実装と結合(couple)させすぎてしまう．様々なシリアライズ可能な actor があるため，良いクラス名が足りなくなってきていた．GoF本が教えてくれる知恵の一つにインターフェイスを用いたクラスの命名に困るとしたら，間違ったことをやっている，というものがある．関心事をより意味のある方法で分割する別のやり方を探ろう．

型クラスだ

コアの actor 抽象体からシリアライゼーションに関するコードを抜き出し，別の型クラスにした．

/**
 * Actor 直列化のための型クラス定義
 */
trait FromBinary[T <: Actor] {
  def fromBinary(bytes: Array[Byte], act: T): T
}

trait ToBinary[T <: Actor] {
  def toBinary(t: T): Array[Byte]
}

// クライアントはそれぞれの Actor のための Format[] を実装する必要がある
trait Format[T <: Actor] extends FromBinary[T] with ToBinary[T]

actor をシリアライズ可能にするためにクライアントが実装する必要がある FromBinary[T <: Actor] と ToBinary[T <: Actor] という二つの型クラスを定義した．これをさらに Format[T <: Actor] という二つを合わせた trait に組み合わせた．