実はここのところ NestJS を触っていました。これについての感想などはまたいずれ書くとして、DI コンテナそのものに不慣れだったので NestJS の DI でとても悩みましたという話を少々。（例によって分かってしまえばどうということはないんだけど）

※ 一応間違いないはずだけど、思い違いがあれば教えてください。

以下に（module定義を除いて）DI コンテナに登録する provider とそれを利用するコードを挙げる。仮に以下のようなコードだったとして、実際にどの部分のコードがどの順番で実行されるのかを確認し、それによって生じる制限と、その制限を克服する方法を整理する。

コード例

https://nestjs.com/

NestJS は TypeScript で動いてます。

@Injectable()
export class Dependee {
  constructor () {
    (1)
  }
}

import { Dependee } from '..'

export class Depender {
  constructor (
    dependee: Dependee
  ) {
    (2)
  }
}

• Depender が Dependee に依存している
• Depender の constructor で Dependee が inject される

実行順

• Dependee の constructor が実行され（default の provider の挙動）て、インスタンスが生成される
• 生成されたインスタンスが Depender の constructor で inject される

できないこと

常に Dependee が先にインスタンス化されるので、Depender の constructor で取得できる値を Dependee の constructor に渡す方法がない。

具体的にどう困るのか

例えば Controller で @Query や @Param で取得した値から「特定の値を持つ provider のインスタンスを生成する」ことは組み込みの DI の機能では実現できない。これは Controller の constructor が実行されるタイミングですでに Dependee のインスタンスは生成されていて、Action に該当するメソッドが呼ばれるタイミングは二周遅れになっているため。

ではどうするとよいのか。

Dependeeに値を渡す方法

どうにかして値を渡したい場合、どうするのがよいのか。方法としては大きく分けて2つ、全部で4つくらいありそう。

1. 最初にあり得る値をセットするインスタンス生成法を全部 DI コンテナに登録しておいて必要なものを必要な人が取得する
2. Inject の機構を利用せずに Depender の constructor の中で手動で Dependee をインスタンス化する
   • DI になっていない¹
3. 実行する処理そのものが書かれているメソッドに渡す
   • property ではなくメソッドのシグニチャで class の特徴を表すことになる
   • 複数のオブジェクトにそれらを渡しながら処理していく場合にインターフェイスの変更が高コストになるのでカッチリ設計が固まっている場合以外は工夫が必要。例えば context オブジェクトを導入するにしても今回の constructor の実行順の問題は同様に残る。
4. constructor に渡すのは諦めてsetter を用意して setter で値を渡す
   • この場合、Dependee の該当 property は readonly にはできなくなる
   • 言語の機能で immutable にはできないので、どうしてもこだわるなら何らかの工夫が必要

どうしてもインスタンスの初期値を最初に決めたのちは途中で挙動が変わってほしくない場合

1 は DI コンテナの機能も素直に活かしつつ、初期値で挙動を固定して途中で変わってほしくないという要望も完璧に満たすことができる。具体的には NestJS では provider 定義に useFactory を使うとこうしたことが可能となる。

Custom providers | NestJS - A progressive Node.js framework

ただし、例えば日付やお金など値の範囲が無限になってしまうものに対してはこの方法は使えない。曜日くらいなら可能。

2 は Dependee の挙動をインスタンス生成時に固定するという目的に対して最も解決が早く、新たな学習コストがない。ただし、用意された DI の機能は使っていないのでちゃんと依存関係の管理ができているかというとあやしくなってくる。

インスタンスの挙動が変わることを許容できるなら

いちばん素朴で素直なのは 3 かな。インスタンスそのものが何をするのか知っているという形ではなくなってしまうけど、その部分の責務をすべてメソッドに担わせる形。

副作用として interface でちゃんと設計を練ってあげてそれを type として利用するようにしておくと class そのものが変わっても耐えられる。こうなると本当に DI っぽい。

4 は 3 と似てるけど setter があるとメソッドの呼び出し順に依存するので避けられるなら避けた方がよさそう。setter で丸ごと放り込むのが雑にやるには早いのは早いけど。

さてすでに書きましたが最近 API づいております。できるだけ RESTful な API を作りたいなぁと思っているわけですが、そこで問題になったのがテスト環境。

まず、ブラウザは使いものになりません。

1. 通常の方法では GET, POST 以外のリクエストを投げられない
2. 通常の方法では html, xml, plain text な response body 以外は表示できない

からです。

まぁ今回テストしたかったのは read only な API なのでリクエストメソッドとしては GET, POST だけでも問題はないのですが、response が application/json だったので

毎回毎回「ダウンロードダイアログが出る -> ダウンロード -> ファイルを開く」

作業が必要になり、さすがにこれはやっとれんと思いました。

そこでまず目をつけたのは以前インストールだけしてあった Firefox extension RESTTest. 結構初期のバージョンだったけど普通に使えます。ただ、フォーカスの当たっているデフォルトのボタンが [ OK ] になっていて、何も考えずにエンターを押すとウィンドウを閉じてしまうのがものすごくイライラ。要するに連続してテストしようにも毎回マウスでちくちく [ Send ] を押さないといけない。これはダサイ。

それでもなんとかサーバ側のコードを書く方が優先なのでちくちくやってました。とりあえず基本形ができたところでマシなテストツールを探します。

まずは RESTTest の最新バージョン。なんか addons.mozilla.org にログインが必要とかぬかし始めている。もうその段階で却下。できれば自動化したいので Ruby で書かれたものがいいなと思い、rubyforge を rest で検索して探します。で、なんとなく目をつけたのは以下。

• RubyForge: open-uri for REST clients: Project Info (RESTful本に載っているもの)
• RubyForge: Ruby-On-Rest: Project Info
• RubyForge: Rest Client: Project Info

それぞれ適当に試したのですが、

rest-client は irb を利用したテストが可能というところに強く惹かれました。

使い方は以下のような感じ。（今回試したのは 0.7）

$ restclient
irb> RestClient.get( 'URI' )

これで response body が画面上に現れます。例えば body が JSON の場合は{{fn "restclient 自身が rubygems でインストールされているのでいきなり require 'json' で ok です。"}}

require 'json'
$KCODE='u'

しておいて、

irb> JSON.parse( RestClient.get( 'URI' ) )

すると目視チェックが可能になります。さらに

require 'pp'

しておいて

irb> pp JSON.parse( RestClient.get( 'URI' ) )

すればインデントもバッチリ、とても確認しやすいです。これはブラウザをそのまま使っていたときよりも RESTTest を使っていたときよりもずっといい。

XML の場合は require 'hpricot' して

irb> doc = Hpricot( RestClient.get( 'URI' ) ); puts doc.search( '//item' )[0]

なんて風に使えます。

もちろん irb なので Readline が効いていれば履歴をたどって何回も同じテストを実行しやすいです。

ヘッダが見たければログを設定

rest-client はデフォルトではヘッダの情報は取れません。ヘッダの情報がほしい場合は

irb> RestClient.log=DEST

としてログを取得する設定をします。DEST は

• ファイル名
• stdout
• stderr

が指定でき、stdout にした場合はそのまま irb 上に表示されます。

しかしここまでやっても実は取れる情報は

• status code
• Content-Type
• Content-Length

くらいのもので、例えば Last-Modified などは取れません。つまり、現状では cache が絡むような凝った client は rest-client では書けないということです。

また status 200, 201, 202, 301, 302, 303 以外は例外が上がるので、例えば

RSpec などと組み合わせてテストコードを書こう

とする場合はその辺をうまく拾ってあげる必要があります。

認証の必要なリソースのテスト

RestClient::Resource を利用します。

irb> r = RestClient::Resource.new( uri, user, password )

でリソースを作って、

irb> r.get

やら

irb> r.post

なんて風に使います。

ヒストリで右往左往

上で irb なので履歴を利用して同じテストを何回でも試せると書いたばかりですが、実は irb は標準では history をログに落としてくれないので、起動するたびに履歴は忘れてしまいます。しばらくこのことを Twitter 上でブータレていたのですが、現在のところ以下の動作を確認しています。

1. irb/ext/save-history を使う方法はリファレンスに 1.9 feature と書かれているが 1.8.4, 1.8.5 で問題なく動いている
2. restclint 実行ファイルを呼び出した場合は 1 の方法も rlwrap¹ をかます方法も使えない

ということで、結論としては

restclint 実行ファイルは利用せず、irb のプロンプトから require 'rest_client' してテストを行う

という形がベストのようです。いろいろ直接、間接に教えてくれた walf443 さん、eban さん、ありがとう！

なお、現在の自分の .irbrc は以下の通りです。

require 'irb/completion'
require 'pp'
require 'time'
require 'date'
require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 1000
$KCODE='u'

シンプルなもんです。これで require 'rest_client' を打てばすぐいけます。

まとめ

rest-client は API の開発に実に便利に使えそうです。今のところ自分の使っている範囲では cache 周りを除いては特に不満はありません。

またこれを利用すれば response body を Ruby の文字列として自由に加工可能なので、これまでブラウザ上で print デバッグしていたようなケースでも便利に使えることが分かってきました。例えば長過ぎる文字列をぶった切るとか HTML の一部を抜き出して確認するなんてことが比較的簡単に行えるので効率がいいのです。泥臭い print デバッグでも目印さえつけておけば rest-client + Hpricot 辺りでかなり楽できます。²そしてそれが Terminal だけで、つまりほぼキーボードだけでテスト可能なんてステキな話じゃないですか。

実は 「rest test」で探していたときは全然見つからなかったのですが、「rest client」で探すと Java のものとか Python のものとかいろいろ見つかりました。もしかするともっといいツールがあるのかもしれません。探すってやっぱ難しいですね。思いつかない言葉の組み合わせでしか見つからない情報は見つけられない -> 自分にとっては存在しないに等しい、って感じになっちゃう。

cf.

RestClient は 0.9 でヘッダが取れるようになってた

見た目に面白い写真を最優先で取り出すとこんなところ。ちなみにこの建物、普通に人が住んでいるそうですが、周りには観光客がうろうろ、ショップもあるという状態。住んでみたいがよく住めるなぁというのが正直な感想。

from CNET Japan

なんかスラドでぷちぷち祭りが起きてるけど。

前から決まってたことをくり返し述べただけだし、そもそも IE 6 が正式にサポートされてる現役 OS に 98 とか me とか入ってないんだし、騒ぐほどのことじゃないような。

単に MS ネタで騒ぎたいだけの人がやっぱスラドにはたくさん居るってことですか。

サポート対象サービスパック (microsoft.com)

前はもっと分かりやすく書いてあったのにな。一緒くたになってめちゃくちゃ見にくくなった。要するに 98/me は金払ったやつだけサポート対象、2000 はまだイケる。NT Server が年末で終わる。現実的にはそれほど大きな違いはないと思う。

5年くらい前？ もっと前？ から使っているボールペンのインクがなくなった。ちょっとかっこいいかなぁと思って買ったがすぐに書き味がイマイチということに気づいて、中身を見たら100円ボールペンと同じやんけーとショックを受けつつ使っていたシロモノ。これ、それなりにちゃんとした替え芯を使えるものなら替えようかなとも思うんだけど、そういうのはどこで聞けばいいんだろうか。文房具の専門店なんかこの辺で見かけないし、やっぱ文具店併設の本屋か？

つーか替え芯てなんでもいいのかな？ サイズにさえ規格があればそんでいいような気がするんだけど。

Mozilla Japan、Firefox Preview Release 日本語版を公開 (Mozilla Japan)

ま、9月22日の話なんですが。予想通りずいぶん動きが鈍くなりましたなぁ。

Thunderbird とか他のプラットフォームとか、とにかく全力でやってくれないものか。何しろモノはとっくの昔にできあがってるはずなんだから。Mozilla Japan は金と時間を無駄に食らっているなんて言われないようにね。

びっくりした。

何かと思ったら 7 の Trial を落とした日本のユーザーの情報を inspiration, inc. から入手したので連絡したとのこと。内容は日本語ユーザーのために inspiration, ins. は v.6 のサポート継続を表明しているという話なんだけど、OS X 使いとしてはちっとも嬉しい話ではない。7 が日本語化される話以外は嬉しくなんかないですよ。

OmniGraffle が Windows 対応するってのはあり得ない話だし、インスピレーション以上の操作性のものは未だかつて触ったことがない。ニッチな市場なのかもしれないが、この日本語アイディアプロセッサ＆ドローの不毛な状態はかなりつらい。誰かが REAL Basic とかでもいいから一から作ったらいきなり市場をリードすることだって可能だと思うんだけどなぁ。

韓国風キムチ味

「当社調べ」によると、辛さ指数は

になっている。期待。

辛い。いやマジ辛いです。いい。

でもこの5段階は絶対後付けだよな。

で、HTTP ヘッダの応答文字列を”抑制”できるらしいけど、明示的に FreeBSD と表示することはできないんだろか。