skinnyを使った開発をしたので記録しておく。
skinnyはRuby on Railsを意識したScala製のWebフレームワークだ。Ruby on RailsをやったことがなくてもPlayをやっていれば雰囲気は掴める。今となっては素朴なフレームワークだ。
躓いたところをつらつら書いていく
application.confの書き方が分からなかった
最初に dev とか prod とかのプレフィックスがついていて、default というプレフィックスがあったので、それらのプレフィックスの中に設定を追加するものだと思っていた。実際は、そういう設定にするかは使う側（主にscalikejdbc）の都合というだけだった。
今となっては、dev とか prod みたいに分けるんじゃなくて、ステージングや本番で違う値は全部環境変数に出して設定ファイル上にdevやprodみたいな分岐は存在しないのが望ましい。
DIがわからない
skinnyではscaldiと呼ばれるDIが標準で提供されているが、今回開発対象のものは特にそのようなDIライブラリが入っていないので、コンストラクタインジェクションをした。カタカナで書くとかっこよく見えるが、要は必要な依存はコンストラクタ引数にしただけだ。
改めてそういうところからちゃんとDIを考えてやると、DIは単体テストのためだなぁという感覚を思い出させてくれて良い。逆に言えば、DIが使えなければ単体テストを書くのが非常に難しくなる。今回一番時間がかかったのはDIが使えず単体テストを用意できなかったレイヤーだった。まぁ書こうと思えば書けたけど、ライブラリのファサードのDI書くのがなんかダルいなって思って端折ってしまった。他にもjava.security周りのインスタンスを作る必要があったりしてmockライブラリ使わずにそれらを用意するのがダルかった。
Javaライブラリは例外飛ばしすぎ
これは言語の文化の違いの気もする。内部で使うJavaライブラリ（標準ライブラリも含む）が、例外をバンバン飛ばしてくる。例外はキャッチしないと500エラーになっちゃうので、できるだけキャッチするようにしてみた。
Try {
例外投げまくる処理
} match {
case Success(a) => a
case Failure(e) => なんかいい感じのリカバリ処理
}
上でまとめる前まではfor式でTryをチェーンした形にしてたけど、あまりにもバンバン例外飛んでくるし、そもそも例外キャッチしたあとの処理が共通なら、いわゆるtry-catchの形で書けるのか、と1周回って関心した。
mountし忘れた
ルートオブジェクトを作ったら、それをmountする必要があるらしい。Playにはない工程だったので、忘れてしまっていた。
