開発環境編このシリーズは今回で最終回の予定です。API」を使ってSKKを作りました、という話のシリーズなのですが、こういうものを作るときに何が一番厄介かといって、やっぱりデバッグだろうと思うわけです。IMEはデバッグをするのが非常に厄介なたぐいのソフトウェアです。うっかり変なことをすると完全に壊れて何もできなくなることすらあります。toolsもあるのでデバッグは相当楽なほうですが、それでもなかなか面倒な面もあります。面倒さの一つには、実機での動作確認が面倒だということが挙げられると思います。ChromeOSでは、まだセルフホスティングの開発環境が整っていません。extensionとしてロードして手元で動かして見ることができます。ChromeOSではローカルファイルを編集するためのテキストエディタがありませんし(と思ったら、そういう拡張機能もあるようですが)、なんだかんだでまだまだ大変な面が強いわけです。いうわけで、今回はMacで開発をしたのですが、じゃあどうすればいいのでしょうか。Macのほうで拡張機能のパッケージ化を行い、適当なサーバにアップロードして、ChromeOSのほうでダウンロードして......などとやれば出来ますが、毎度それをやるのはあまり実際的でもありません。いった状況を踏まえ、まず開発をするための実行環境を作ってみました。それがソースコード中のtestpageというディレクトリです。こいつのやることは簡単です。mock.jsというJSを読み込みます。こいつはchrome.input.imeというオブジェクトをグローバルに追加して、setCompositionとかclearCompositionとかのメソッドを登録します。この関数の実行結果は、適当にHTMLで画面に表示させます。一方でキー入力も適当なeditableな要素のほうで受け付けておき、onkeydown/onkeyupを使って適当なイベントリスナにキーイベントを横流しできるようにしておきます。しておいて、のこりの拡張機能で使うJSファイルをロードすると、ある程度は動作するようになるという仕組みです。実際に、前回の記事で書いたAppEngineのホストにくっつけて公開もしています→こちら前々回の記事で、AJAX-IMEのようにページ内に寄生するIMEっぽいJSの話に軽く触れました。API互換のレイヤを間に挟んでいる、という解釈ができるかと思います。この手法はなかなかうまく行きました。コードを書いたら、すぐ実際にキー入力してみてどう表示されるのか確認できる環境がある、というのはいいものです。確認できることによる全体的な開発の高速化もありますし、実際に動いているのを目にすることができるというのは、とくに開発初期においてモチベーションを高めるという意味もあると思います。ものが開発できたのも、この方式のおかげというのがあるかなあと個人的には考えています。実際には、APIのドキュメントをちゃんと読まずに実装したので、いざ実機にロードしてみたらちゃんと動かなかった、みたいなよくある失敗もあるし、JSやイベント処理まわりの無理解のために動かなかった、みたいなしょぼい問題もたくさん踏んでいるので、あんまり自慢するようなポイントではないような気もします。現状ではonKeyEventの返り値を見ていないので、一部の機能は全然動いていないように見えます。それに、動かして確認するといった単純な手法よりは、細かいコーナーケースではユニットテストをちゃんと書くほうが大事だったりします......このコードではテストを書いてませんが、IMEはコーナーケースばっかりなので本当はテストが大事です。個人的には、テスト環境を実装してみたら割と簡単に実装できて、これが思いの外便利だった、というハックがちょっと面白かったので、紹介してみた次第です。