daimatz.net

Some good revs are not ancestor of the bad rev.

2015-03-10T15:00:00+00:00

git bisect start
git bisect good 98765432
git bisect bad 12345678

すると

Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?

と言われることがあります。本人は至ってまじめなんですが。これ、実は過去にあったバグがいつ直ったかを探そうとしています。本来 git bisect は正常に動いていたものがいつバグったかを探すものです。意味が逆になっているのですが、 git bisect を「要は二分探索するんだろー」と思っているとハマります。ハマりました。

workaround としては、 good と bad の意味を逆にすることです。つまり

git bisect start
git bisect good 12345678 # バグっているコミット
git bisect bad 98765432  # バグがいつの間にか直っていたコミット

として、 bisect 中もバグが再現したら git bisect good, 直ったら git bisect bad としましょう。

混乱しそう。

Middleman と GitHub Pages でブログを作った話

2014-08-29T15:00:00+00:00

tl;dr

Middleman
GitHub Pages のユーザーサイト
独自ドメイン使用
ソースを push すると Travis CI がデプロイ

Middleman

Middleman は最近よく使われている気がする静的サイトジェネレータ。少し前から静的サイトジェネレータは Middleman 一強感あったので流行に乗り遅れまいと使ってみることにした。この種のソフトウェアで Ruby 製のものは古くから Jekyll が有名でしたが、 Middleman だと Asset Pipeline の概念だったりテンプレートに erb, haml, slim が使えたりといったところで Rails に近いっぽいところが受けているのだとか。

公式のチュートリアルと、その日本語版が充実しているので一通り読めばだいたいのことはできる気がします。以下、ハマったところやちょっとしたカスタマイズだけ。

後からブログ仕様にする

middleman init するときに --template=blog を付けずに実行してしまい (というかこんなオプションがあるのを知らなかった) 、ある程度サイトを作ってからブログ機能をつけることになってしまった。するとブログテンプレートを使った場合の config.rb や他のファイルの中身がわからないので、解説サイトを見ても何のことだかわからない、ということがあった。

middleman-blog/lib/middleman-blog/template にテンプレートファイルが一通り置いてあるので、これをコピーすれば良い。

VM 内で livereload

middleman-livereload という拡張があり、これは記事を書いている途中に保存すると勝手にブラウザがリロードしてくれるものです。使っている rack-livereload がファイルの変更を検知して WebSocket でブラウザ側に伝えて、 JavaScript でリロードとかやっているっぽい。以前似たようなものを書いたことがあるのであーあんな感じだろうなと想像しつつ。

最近は Vagrant で全部 VM の中でやるようにしているのですが、ネットワーク共有をポートフォワードでやっている場合は rack-livereload のデフォルトである 35729 番をフォワードしておく必要があります。あと、 middleman のプレビューのデフォルトである 4567 番もフォワードしておきます。

config.vm.network "forwarded_port", guest: 4567, host: 4567 # middleman
config.vm.network "forwarded_port", guest: 35729, host: 35729 # livereload

そして config.rb に activate :livereload を書いておく。すると

1	$ middleman

と打つと localhost:4567 でプレビューでき、 livereload もできる。

日本語で80行で改行するのを無視する

エディタで書くときは80文字で折り返したいのだけど、日本語の場合それを普通にレンダリングさせてブラウザで見ると改行位置で半角スペースが開いてしまう。それが嫌だったので、 Markdown レンダリングエンジンをいじって改行を取り除く処理をつけている。 Redcarpet での処理。

class Redcarpet::Render::HTML
  def preprocess(text)
    text.gsub(/([^\x01-\x7E])\n([^\x01-\x7E])/, '\1\2')
  end
end

これを config.rb に書いておけば良い。

シンタックスハイライト

シンタックスハイライトは Rouge を Gemfile に書いておくだけ。少し使ってみている限りは特に問題なさそう。

GitHub Pages のユーザーサイト

GitHub Pages は github.io ドメインで静的なファイルをホスティングできるサービス。 User や Organization のページと Project ごとのページの2種類あるが、ここでは個人ページを作ることを想定しているので User & Organization のほうを使う。

この場合、 User もしくは Organization に [user or organization].github.io というリポジトリを作り、その master ブランチに静的ファイルを push することで https://[user or organization].github.io にアクセスできるようになる。自分の場合は daimatz.github.io とする。

独自ドメイン使用

GitHub Pages で独自ドメインを使う場合やることは以下のとおり：

DNS レコードの設定
CNAME ファイルを置く

DNS レコードの設定

CNAME を設定する方法と A レコードを設定する方法がある。自分の場合は daimatz.net を使いたかったので、「apex domain の場合は A レコードを設定せよ」との指示通り A レコードを設定する。

ググると 204.232.175.78 を使うといい、という情報が見つかるのだが、一度それで push すると「その IP アドレスは deprecated なので公式ページに書いてある正しいものを使ってね」というメールが来た。そこから A レコードの設定ページに飛ぶと、現時点では

192.30.252.153
192.30.252.154

の2つを使えと書いてある。

自分は VALUE DOMAIN を使っているので DNS 設定ページで次のように記入した。

a @ 192.30.252.153
a @ 192.30.252.154

CNAME ファイルを置く

GitHub Pages リポジトリの master ブランチ直下に CNAME というファイルを置き、その中に独自ドメインを書く。すると、 http://[user or organization].github.io にアクセスされたときにそのドメインにリダイレクトしてくれる。

middleman を使う場合、 source/ 直下に置いて次のようにするのが良いと思う。

page 'CNAME', layout: false

ソースを push すると Travis CI がデプロイ

Travis CI は言わずと知れたクラウド CI サービスですが、これをデプロイに使おうとすると少し面倒な設定が必要になる。ビルドログがダダ漏れなので認証情報をそのまま書くわけにはいかない。

認証情報の持ち方

まず Travis が GitHub リポジトリに push できるようにする方法だが、これはアプリケーション登録して Access Token を設定すれば良い。自分の設定の Applications ページに行き、 Personal access tokens の Generate new token からトークンを生成する。

さて、そのトークンを Travis に教える方法だが、このために Travis CI に暗号化の仕組みがある。 travis コマンドを使って次のようにする。

$ gem install travis
$ travis encrypt -r daimatz/daimatz.github.io "GH_TOKEN=<token>"

そして .travis.yml に次のように書く。

env:
  global:
    - secure: ".............."

すると、ビルド時に復号化した GH_TOKEN=<token> が展開される。もちろんビルドログには表示されない。

Travis が master ブランチを push

[user or organization].github.io ではデプロイするファイルは master ブランチに置かなければならない。そこで、ソースはすべて source ブランチに置いておき、 source ブランチを push すると Travis が master ブランチに成果物を commit して push という手順をとることになる。 master に push する用のリポジトリを build というディレクトリで clone してきて、 middleman build したときに build ディレクトリに入るようにする。具体的には次のような感じ。

before_script:
    - git clone --quiet https://github.com/daimatz/daimatz.github.io build
script:
    - bundle exec middleman build
after_success:
    - cd build
    - git add -A .
    - git commit -m "Update [ci skip]"
    - '[ "$TRAVIS_BRANCH" == "source" ] && git push --quiet https://$GH_TOKEN@github.com/daimatz/daimatz.github.io master 2> /dev/null'

git push 時に --quiet を付けないとトークンが表示されてしまうので注意。

Travis ではコミットメッセージに [ci skip] という文字列を入れておくと、そのコミットについてはビルドしない。こうしないと Travis が master ブランチに push したコミットについてまた CI が走ってしまい、 .travis.yml がないためビルドが失敗してエラーメールが飛んでくることになる。

まとめ

ソースを見てもらうのが一番わかりやすい気がする。

関数型LT大会で話したこと

2014-05-11T15:00:00+00:00

関数型LT大会

クックパッド社で行われていたすごいHaskellたのしく学ぼう輪読会の完走を記念して関数型LT大会という会が開催された。クックパッド関係なく関数型に興味ある人が集まってワイワイする感じっぽかったので、ひとつなにか話して叩かれに行ってみるかと思って発表してきた。そういえばクックパッド社に行くのは2回目であった。

自分の発表

Scala で初めて Future という概念を知ったのだけど、触り始めの頃はどういうコードを書けばいいのかも全然良くわからなくて苦しんでいた。ふと「これって Haskell の IO と同じじゃね？」と気づいてから急に視界が開けた気がしたので、そのへんのことを話してきた。ググっても「Future と IO 似ているよね」という説は全然見つからず、「いや全然似てねえよバカ」とかマサカリが飛んでくることも覚悟していたけど概ね生暖かく迎えられたようで安心した。

後で @eagletmt 氏に「あれってモナドだって言ってるだけですよねえ」と突っ込まれたのでそのへんの話を追記した。たしかにモナドの特徴を言っているだけだが、重要なのは基本的に Future は一方向性のモナドであるということで、気軽にブロックして中身を取り出すようなことをやってはいけないのである。 Twitter の Effective Scala にもそのへんことが書いてあるし、 Finagle について書かれたドキュメントを見るとブロックするなと書いてあるのが頻繁に見つかる。 ~~そのへん理解してないんじゃないかなーと思うコードに以前苦しめられた過去が~~

ある関数内で Future を呼んでいるのにその戻り値が Future[A] というシグネチャになっていない関数 (こういう関数を簡単に書けてしまう) というのは、よほどのことがない限りアンチパターンである。具体的に許されるのは次の2パターンくらいしかないんじゃないかなーと思っている。

一番最後に IO 処理をして終わる場合
タイムアウトを設定し、それまでに戻って来なかったら切り捨てて計算を続ける場合

1 は Future 内で行われる IO 処理を「投げっぱなし」にすることで、その IO 処理内で適切にエラーハンドリングされており自分でエラーハンドリングを書かなくていいと確信できる場合である。その場合は途中で呼んだ Future を投げっぱなしにして、非同期で IO 処理だけさせてメインスレッドは次に進むということをやって良い。

2 は必要な情報が全部は集まっていないけどとりあえずレスポンスを返さなきゃいけないような場面において、呼んだ Future がタイムアウト前に返ってこなければ見捨てるというもの。ある意味同期処理なわけで、基本的にはやってはいけないがタイムアウトという条件が付いているなら話は別だ。タイムアウト時間とそのイベントハンドラを登録し、それが呼ばれた時点で対象の Future に対してそれが完了しているか否かを問い合わせ、完了していれば中身の値を取得して同期的に次の計算に移ることになるので Future の文脈は消える。戻ってこなかった場合はその Future をキャンセルしておく (com.twitter.util.Future では raise(new FutureCancelledException) を呼ぶ) のがたぶんマナー的に正しい。

twitter/util はこのへんうまく出来ていて、呼んでいる Future が戻ってきたら処理を続けるとか、あるいは同時に呼んでいるどれかが戻ってきたら処理を続けるみたいな、イベント駆動な設計になっている。 select とか epoll といった UNIX システムコールに関連した話になってくるわけだが、 com.twitter.util.Future には select と poll という名前そのままの API がある。 scala.concurrent.Future にはその手の話はないっぽい？システムコールレベルではまだあまり使ったことがないので触ってみないと…

他人の発表

勉強会での発表というものは自分が勉強するためにあるものであって、自分が勉強したことに比べれば話す内容は他人にとってもわかりやすくするものであると思っていた。だが他の人達の発表を聞いていても意図的にレベルを落としたように感じられるものはなく、むしろみんな全力で準備している感じがしてすごかった。「それ知ってるよ〜」という類のものはほとんどなかったし、自分の到底理解の及ばない型レベルガチ勢の方々の発表もわかりやすくて面白かった。 LLVM や TaPL, さらには圏論が一般教養として扱われていた感もあり関数型界隈はレベル高いなあと思った。

その他

@rejasupotaro さんとは以前第7回若手Webエンジニア交流会で少しだけ話したのだが、昨日はより突っ込んだ話をした。 Twitter のオープンソースのコードを読んでいると、 Scala の標準ライブラリに比べてケチくさい最適化を頑張っていないように見えるとか、 Twitter をしてもまだ Netty 4 に乗り換えられない感じなんだろうなあとか。結論としてはジャバこそが実用的な言語ということになった。

レジャスポ氏に「時代はジャバだ」と力説してしまった #functionalLT
— matsumoto (@daimatz) May 11, 2014

帰りで少し一緒になった @taiki45 さんともそんな話をした。もうちょっと我々のアプローチがどの程度どうなのかという話とか、他のカイシャさんでそのへんどうしているのとかいう話を聞きたい気もした。

あとは、今回も Twitter でしか見たことのなかった何人かの人達の存在を確認した。

twitter/util と twitter/finagle 読もうと言いつつ、いやそこそこ読んではいるんだけどどうしても finagle のタスクスケジューリング周りがつかめていなくて、困っている。標準版の Future は FuturePool を直接触る設計になっていて直感的だが、 Twitter 版の Future は finagle を普通に触っている限り FuturePool というかタスクスケジューラが一切表に出てこない。裏で謎スケジューリングしていたり、かといえば普通に ExecutorService を作っているところもあったりで、結局どこが実態なのかわかっていない。一人 finagle コードリーディングでも記録に残していくかなーと思っているところ。関連して twitter/util と netty もある程度読むことになりそう。

QPS コントロール

2014-03-26T15:00:00+00:00

QPS

QPS = Queries per Second, RPS = Requests per Second という言葉がある。読んで字の如し、秒間クエリ数を表す。例えば次のような HTTP アクセスログがあったとする。

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

このとき、ある一秒間を含むようなログの行数を数えれば QPS を出すことができる。

$ grep '10/Oct/2000:13:55:36 -0700' access_log | wc -l
123

QPS コントロール

リクエストを送る側が受ける側の性能の問題だったりで「500 QPS くらいで送って」と頼まれるときがある。そこでうまい具合に QPS をコントロールしたいのだが、そんなに自明な問題ではないことに気づいた。素朴には「メインスレッドが 500 個スレッドを作ってそれぞれがリクエストを飛ばし、メインスレッドは1秒寝る」みたいなことをやればいいと考えるかもしれない。

class Main {
    public static void main(String[] args) throws Exception {
        int arg = 0;
        while (true) {
            for (int i = 0; i < 500; ++i) {
                new Thread(new Task(arg++)).run();
            }
            Thread.sleep(1000);
        }
    }

    static class Task implements Runnable {
        private int arg;
        public Task(int arg) {
            this.arg = arg;
        }
        public void run() {
            sendRequest(arg);
        }
    }
}

しかし、これではメインスレッドが Thread や Runnable のインスタンスを作る分遅れ、遅れたところから 1 秒間眠ることになる。これでは正しく QPS コントロールされているとはいえない。ちょっとしたテストならそれでも良いかもしれないが、規模が大きくなるにつれて無視できないことになる。

また、リクエストを送ったがネットワークの気まぐれで失敗した場合にリトライしたいこともある。リトライのロジックを同じスレッドの中で行うとすると次のようになる。

class Main {
    public static void main(String[] args) throws Exception {
        int arg = 0;
        while (true) {
            for (int i = 0; i < 500; ++i) {
                new Thread(new Task(arg++)).run();
            }
            Thread.sleep(1000);
        }
    }

    static class Task implements Runnable {
        private int arg;
        public Task(int arg) {
            this.arg = arg;
        }
        public void run() {
            try {
                sendRequest(arg);
            } catch (Exception e) {
                run();
            }
        }
    }
}

しかしこれではリクエストが失敗したらすぐに同じリクエストが飛ぶことになり、これも QPS が狂ってしまうことになる。

問題

改めてきちんと問題を定義する。

毎秒与えられた数 n 回程度のリクエストを行う。
- ここでは n は一台のマシンが無理なく送れる程度 (〜2000 程度) とする。
失敗したときは m 回までリトライを行う。そのときも QPS は狂わないようにする。
- m 回のリトライでも失敗したときはエラーを吐いて捨てる。

タイマーを使った固定頻度実行

java.util.Timer の scheduleAtFixedRate というメソッドを使う。これを使って 1 秒ごとに実行されるようにしておけば、毎秒きっちり 1 回の頻度で実行されるようになる (イレギュラーなスケジューリングは考えない) 。

import java.util.Timer;
import java.util.TimerTask;

class Main {
    public static void main(String[] args) {
        Timer timer = new Timer();
        Task task = new Task();
        timer.scheduleAtFixedRate(task, 0L, 1000L);
    }

    static class Task extends TimerTask {
        public void run() {
            System.out.println("run!");
        }
    }
}

これで 1 秒に 1 回の割合でタスクが実行されることになる。実際にはこのタスクの中で n 回のリクエストを行いたいので、固定頻度で呼ばれる Runner と実際にリクエストを行う Task を分け、次のようになる。

import java.util.Timer;
import java.util.TimerTask;

class Main {
    static final int n = 500;

    static int arg = 0;

    public static void main(String[] args) {
        Timer timer = new Timer();
        Runner runner = new Runner();
        timer.scheduleAtFixedRate(runner, 0L, 1000L);
    }

    static class Runner extends TimerTask {
        public void run() {
            for (int i = 0; i < n; ++i) {
                new Thread(new Task(arg++)).run();
            }
        }
    }

    static class Task implements Runnable {
        private int arg;
        public Task(int arg) {
            this.arg = arg;
        }
        public void run() {
            sendRequest(arg);
        }
    }
}

リトライ

失敗した時のリトライを同じスレッドで行おうとするとどうしても QPS が狂ってしまうことは明らかである。そこでタスクキューにタスクを追加していき、次の実行の際にまとめて実行するという手段が考えられる。タスクのインスタンスはリクエストを送る際の引数とリトライ回数を保持している。

import java.util.LinkedList;
import java.util.Timer;
import java.util.TimerTask;
import java.util.Queue;

class Main {
    static final int n = 500;
    static final int m = 3;

    static int arg = 0;

    static Queue<Thread> tasks = new LinkedList<Thread>();

    public static void main(String[] args) {
        Timer timer = new Timer();
        Runner runner = new Runner();
        timer.scheduleAtFixedRate(runner, 0L, 1000L);
    }

    static class Runner extends TimerTask {
        public void run() {
            while (tasks.size() < n) {
                tasks.offer(new Thread(new Task(arg++, m)));
            }
            for (int i = 0; i < n; ++i) {
                Thread task = tasks.poll();
                task.run();
            }
        }
    }

    static class Task implements Runnable {
        private int arg;
        private int nRetry;
        public Task(int arg, int nRetry) {
            this.arg = arg;
            this.nRetry = nRetry;
        }
        public void run() {
            try {
                sendRequest(arg);
            } catch (Exception e) {
                if (nRetry > 0) {
                    nRetry--;
                    tasks.offer(new Thread(this));
                } else {
                    System.out.println("arg = " + arg + " tried " + m + " times, but failed.");
                }
            }
        }
    }
}

しかしこの実装では、メインスレッドの他にタスクに失敗したスレッドからもアクセスされるため、それが同時に発生するとまずい。そこで同期化されたタスクキューを使う。

import java.util.concurrent.LinkedBlockingQueue;
import java.util.Timer;
import java.util.TimerTask;
import java.util.Queue;

class Main {
    static final int n = 500;
    static final int m = 3;

    static int arg = 0;

    static Queue<Thread> tasks = new LinkedBlockingQueue<Thread>();

    public static void main(String[] args) {
        Timer timer = new Timer();
        Runner runner = new Runner();
        timer.scheduleAtFixedRate(runner, 0L, 1000L);
    }

    static class Runner extends TimerTask {
        public void run() {
            while (tasks.size() < n) {
                tasks.offer(new Thread(new Task(arg++, m)));
            }
            for (int i = 0; i < n; ++i) {
                Thread thread = tasks.poll();
                thread.run();
            }
        }
    }

    static class Task implements Runnable {
        private int arg;
        private int nRetry;
        public Task(int arg, int nRetry) {
            this.arg = arg;
            this.nRetry = nRetry;
        }
        public void run() {
            try {
                sendRequest(arg);
            } catch (Exception e) {
                if (nRetry > 0) {
                    nRetry--;
                    tasks.offer(new Thread(this));
                } else {
                    System.out.println("arg = " + arg + " tried " + m + " times, but failed.");
                }
            }
        }
    }
}

スレッドプールを使う

以上で QPS コントロールの要件は満たされたはずだが、さらに改善の余地がある。何度もスレッドを作っている点だ。これまでの実装ではスレッドが使い捨てになっており、毎回新しくスレッドを作るという点でパフォーマンス的に問題がある。そこで数の固定されたスレッドプールを使う。

java.util.concurrent.ExecutorService はスレッドプールを扱う API である。この invokeAll メソッドを使えば、引数の Iterable に入ったタスクを一気に発火することができる。その後タスクキューをクリアすればよい。

import java.util.concurrent.Callable;
import java.util.concurrent.Executors;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.Timer;
import java.util.TimerTask;
import java.util.Queue;

class Main {
    static final int n = 500;
    static final int m = 3;

    static int arg = 0;

    static LinkedBlockingQueue<Task> tasks = new LinkedBlockingQueue<Task>();

    static ExecutorService exe = Executors.newFixedThreadPool(n);

    public static void main(String[] args) {
        Timer timer = new Timer();
        Runner runner = new Runner();
        timer.scheduleAtFixedRate(runner, 0L, 1000L);
    }

    static class Runner extends TimerTask {
        public void run() {
            while (tasks.size() < n) {
                tasks.offer(new Task(arg++, m));
            }
            try {
                exe.invokeAll(tasks);
                tasks.clear();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }

    static class Task implements Callable<Void> {
        private int arg;
        private int nRetry;
        public Task(int arg, int nRetry) {
            this.arg = arg;
            this.nRetry = nRetry;
        }
        public Void call() {
            try {
                sendRequest(arg);
            } catch (Exception e) {
                if (nRetry > 0) {
                    nRetry--;
                    tasks.offer(this);
                } else {
                    System.out.println("arg = " + arg + " tried " + m + " times, but failed.");
                }
            }
            return null;
        }
    }
}

しかしこれでも、失敗時のタスクキュー追加のタイミングによって次の問題がある。

invokeAll の直前に追加された場合、追加されたぶんも含めて invoke されてしまう
invokeAll の直後に追加された場合、そのタスクが消えてしまう

解決策として次の2通りがある。

発火前後を synchronized で同期化する
発火前に本当に発火すべきタスクを正しく集める

ここでは後者を採用する。

import java.util.concurrent.Callable;
import java.util.concurrent.Executors;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.ArrayList;
import java.util.Timer;
import java.util.TimerTask;
import java.util.Random;

class Main {
    static final int n = 500;
    static final int m = 3;

    static int arg = 0;

    static LinkedBlockingQueue<Task> tasks = new LinkedBlockingQueue<Task>();

    static ExecutorService exe = Executors.newFixedThreadPool(n);

    public static void main(String[] args) {
        Timer timer = new Timer();
        Runner runner = new Runner();
        timer.scheduleAtFixedRate(runner, 0L, 1000L);
    }

    static class Runner extends TimerTask {
        public void run() {
            while (tasks.size() < n) {
                tasks.offer(new Task(arg++, m));
            }
            ArrayList<Task> toInvoke = new ArrayList<Task>();
            for (int i = 0; i < n; ++i) {
                toInvoke.add(tasks.poll());
            }
            try {
                exe.invokeAll(toInvoke);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }

    static class Task implements Callable<Void> {
        private int arg;
        private int nRetry;
        public Task(int arg, int nRetry) {
            this.arg = arg;
            this.nRetry = nRetry;
        }
        public Void call() {
            try {
                sendRequest(arg);
            } catch (Exception e) {
                if (nRetry > 0) {
                    nRetry--;
                    tasks.offer(this);
                } else {
                    System.out.println("arg = " + arg + " tried " + m + " times, but failed.");
                }
            }
            return null;
        }
    }
}

まとめと課題

失敗したときに何度かやり直すことを許すようなリクエストを送るときの QPS コントロールについて、問題を考察した。

単純にスレッドを作り実行するだけではいけない
失敗時に同じスレッドで実行すると QPS が狂う
スレッド使い捨て問題

これらについてそれぞれ解決策を示し、最終的にこの問題における設計パターンとコーディング例を示した。動作確認に使った動く完全なコード例を Gist にあげておく。

この実装の問題として、多くの場合毎秒処理されるタスクは1秒間のうち最初のほうに固まってしまい、いびつな間隔で実行されてしまうということがある。できれば 1 秒間のうちでうまく分散して実行されるようにしたい。

FF6 をやった

2014-02-11T15:00:00+00:00

FF6 が Android で出ているのでやった。

普段ゲームをやらない僕としては RPG に手を出すのは珍しい。というかもう RPG を一本やる元気と気力と時間がなく途中でやめる気がしていたのだけどなんとかエンディングまでは見ることができた。学生時代にも FF8 と FF10 を途中までやって飽きて放置しているのである。これらはたぶん二度とやることはない。

僕にとっての Final Fantasy とは FF7 で、小学生の頃兄がどこかから借りてきてやっていたのを後ろから見ていた記憶がある。その後自分でもやるようになり、ハマった。次にやったのは FF9 だった。まともにやった FF はこの2作だ。どちらかというとシステムは 7 のほうが好きで、ストーリーは 9 のほうが好きだった。「自分、自分て言いながら、自分のねえ奴だな……」というセリフは強烈に記憶に残っている。

で、 FF6 である。最初はシステムがわからないがやっているうちにのめり込んで来るというのは RPG というジャンルの特徴のように思う。魔石システムは FF7 のマテリアに慣れていたためかすんなり理解した。ただ最後までいっても結局主人公が誰なのかわからないし、なぜ仲間になったのかわからないキャラも多かった。これ自分が見ていないストーリーがたくさんあるからだろうか。それにしても仲間が最終的に 14 人て多すぎでは。

操作は最後まで慣れなかった。 Android 版では当然カーソルキーなどないので、タッチした点から動かした方向がカーソルキーに相当する操作になる。しかし最後まで思わぬ方向に行くという事態はなくならなかった。絶対的な位置にないは難しい。しかし普段 Mac のトラックパッドを使っていて不便に感じたことはないし、不思議なものだ。と書いてゲーム内ではカーソル操作の方向が8種類に限定されていたことによるのだろう、と気づいた。 Mac やノート PC のトラックパッドは実質無段階で方向調節でき微妙な調節ができるため不便には感じないのだろう。

いずれにしろここ数日は FF6 を飽きる前にやってしまわねば、という妙な脅迫感と戦っていた。エンディングまでは見たので自分の中ではとりあえず満足である。

Cake Pattern を理解する

2014-01-27T15:00:00+00:00

オブジェクト指向とテストについて

私はオブジェクト指向や特に自動テスト周りの実務経験に乏しいわけですが、最近になってようやくテストをきちんと書いたりテストファーストによって良い設計になるみたいな実感を得たりしています。長らくテストを書かない文化にいたので、注意しないとすぐにモノリシックな設計になってしまい、後から「テスト書くのどうすんだこれ」みたいになってしまうことも多い。

で、最近 Dependency Injection という依存性をうまいこと抽象化しておく仕組みについて学んだので、その Scala における代表的なデザインパターンである Cake Pattern で実装した話です。

Dependency Injection

依存性の注入とか訳される、依存しているオブジェクトを直接クラスの中に持っておくのではなくコンストラクタとかで受け取れるようにして依存性を分離しておく仕組みです。例えば Twitter のボットアプリケーションを想定した次のようなコード

object TwitterService {
  def tweet(text: String, inReplyTo: Option[Int]): Int = { ... }
  def getTimeline(count: Int): Seq[Status] = { ... }
}
object TwitterBot {
  def eventLoop() { ... }
}

において、 TwitterBot オブジェクトは TwitterService オブジェクトに依存しています。ここで

TwitterService.tweet(text, inReplyTo) はツイートした結果発言 ID を返す
TwitterService.getTimeline(count) はタイムラインの最新 count 件を取得する

ものとします。例が適当なため登場していないが実際他にもいろんなオブジェクトに依存していることでしょう。

ここで TwitterService はシングルトンとして定義されており、例えば次のように TwitterBot で利用されています。

object TwitterBot {
  def eventLoop() {
    val statusIds = action(10)
    ...
    Thread.sleep(60 * 1000)
  }
  def action(count: Int): Seq[Int] = {
    val tl = TwitterService.getTimeline(count)
    tl.map { status: Status =>
      TwitterService.tweet("@" + status.userId + " おやすみ〜", Some(status.id))
    }
  }
}

さてこの実装には問題があります。この場合、 TwitterService が直接 TwitterBot に出てきているため、これをモックして一時的に振る舞いを変えるということができないのです。すると TwitterBot を単体テストしようとしても必然的に TwitterService の動作を前提としてしまうため単体テストできません。単体テストができないとすべてを結合して粒度の大きなテストしかできなくなるため、問題が起きたときに問題の切り分けが難しくなります。この例はまだ単純だからよいのですが、他にもいろんなオブジェクトに依存しているとすると依存オブジェクト一つ一つを調べなければならないため、問題箇所の特定が難しくなるのです。

ではどうするのかというと、依存性を抽象的に宣言しておいてそのインターフェイスに対してメッセージを呼ぶということをやります。具体的には次のようにします。

trait TwitterService {
  def tweet(text: String, inReplyTo: Option[Int]): Int
  def getTimeline(count: Int): Seq[Status]
}

class TwitterBot(twitterService: TwitterService) {
  def eventLoop() {
    val statusIds = action(10)
    ...
    Thread.sleep(60 * 1000)
  }
  def action(count: Int): Seq[Int] = {
    val tl = twitterService.getTimeline(count)
    tl.map { status: Status =>
      twitterService.tweet("@" + status.userId + " おやすみ〜", Some(status.id))
    }
  }
}

TwitterService がトレイトになり、 TwitterBot がクラスになってコンストラクタに TwitterService のインスタンスを取るようになりました。注目すべきは、コンストラクタに渡している twitterService は TwitterService トレイトのオブジェクトであると言っているだけで、その具体的な実装クラスは指定されていないことです。

こうすると、 TwitterBot クラスの単体テストにはモックした TwitterService のインスタンスを渡せば良くなり、依存しているオブジェクトの振る舞いを一時的に変えるということができるようになります。

これを使った TwitterBot クラスの単体テストは次のように書けます。 Mockito と specs2 を使った例。

import org.mockito._
import org.specs2.mutable._

class TwitterBotSpec extends Specification {
  val twitterService = Mockito.mock(classOf[TwitterService])
  val twitterBot = new TwitterBot(twitterService)
  "action" should {
    "return status ids" in {
      val status1 = Status(id = 1, userId = "foo", text = "Hello")
      val status2 = Status(id = 2, userId = "bar", text = "Scala")
      val statuses = Seq(status1, status2)
      Mockito.when(twitterService.getTimeline(2)).thenReturn(statuses)
      val id1 = 100
      val id2 = 102
      Mockito.when(twitterService.tweet("@foo おやすみ〜", Some(1))).thenReturn(id1)
      Mockito.when(twitterService.tweet("@bar おやすみ〜", Some(2))).thenReturn(id2)
      twitterBot.action(2) must_== Seq(id1, id2)
    }
  }
}

この例では new TwitterBot(twitterService) としてモックしたオブジェクトを注入しており、さらにテストケース内では Mockito の機能を使って twitterService オブジェクトの振る舞いをモックしています。 TwitterBot.action メソッドのテストが、依存しているオブジェクトをうまくモックした状態で実行できているのがわかります。

このように、あるクラスが依存している別のオブジェクトを、そのクラス内で直接インスタンス化せず、後から注入 (inject) できるような設計にしておきます。テストの際には依存しているオブジェクトのところに挙動を適宜モック・スタブしたオブジェクトを渡せば、依存オブジェクトの振る舞いを一時的に固定することができ、テストしやすくなる。これを Dependency Injection といいます。

自分型アノテーション

Cake Pattern では Scala の自分型アノテーション (self-type annotation) という機能を使います。これはクラスを定義するときに自分の型をそのクラス以外にもできるというものです。

trait A { def print(x: String) = println(x) }
trait B { val x: String }
class C {
  // 自分の型は A と B をミクスインしたものである
  self: A with B =>
  def f() = print(x)
}

のようにすると、 C は外からはただの C として見えますが、自分の中からはトレイト A と B をミクスインしているとみなせます。 B.x の具体的な実装は書いていませんがコンパイルは通ります。ただし、 C をインスタンス化するときに問題が起こります。

scala> val c = new C
<console>:10: error: class C cannot be instantiated because it does not conform to its self-type C with A with B
scala> val c = new C with A with B
<console>:10: error: object creation impossible, since value x in trait B of type String is not defined

B.x が定義されていないためインスタンスを作成できないと出ます。そこでミクスインのときに B.x を定義してやります。

scala> val c = new C with A with B { val x: String = "Hello" }
scala> c.f
Hello

(A と B を両方不完全な実装にしておくと似たような構文 new C with A { def print() { ... } } with B { val x = ... } でインスタンス化することはできませんでした。これできるのか？)

これ何が嬉しいのという話なんですが、外からは C として見えるが実は A と B に依存しているというのが表せるのです。「C というクラスが A と B に依存していて、かつその依存している実装を後から指定できる」というわけです。 Dependency Injection の臭いがしてきました。

Cake Pattern

さて、ようやく Cake Pattern に入ります。以下は実戦での Scala: Cake パターンを用いた Dependency Injection (DI) を参考にしたものです。

ユーザーを表すケースクラスとそれを扱うクラスを定義します。

case class User(name: String, email: String)

class UserRepository {
  def authenticate(user: User): User = {
    println("authenticating: " + user)
    user
  }
  def create(user: User) = println("creating: " + user)
  def delete(user: User) = println("deleting: " + user)
}

ここで UserRepository クラスは単にユーザーを扱う関数を集めている名前空間の役割しかないため、 object として定義したくなる。しかし後のために普通のクラスとして定義しています。

次にもう少しユーザーを扱うために抽象化されているはずである UserService を定義します。

object UserService {
  def authenticate(name: String, email: String): User =
    UserRepository.authenticate(User(name, email))
  def create(name: String, email: String) =
    UserRepository.create(User(name, email))
  def delete(user: User) =
    UserRepository.delete(user)
}

上で見たとおり、ここで UserRepository に依存しているとテストしにくくなります。そこで UserRepository を注入してほしいオブジェクトとしておくのでした。

class UserService {
  def authenticate(name: String, email: String): User =
    userRepository.authenticate(User(name, email))
  def create(name: String, email: String) =
    userRepository.create(User(name, email))
  def delete(user: User) =
    userRepository.delete(user)
}

userRepository はここでは定義されていませんが、これが注入してほしいオブジェクトであることを覚えておきます。さて、ここからまず UserRepository を名前空間トレイトに包みます。ここで userRepository は後から注入されるべきオブジェクトとして宣言だけしておきます。

trait UserRepositoryComponent {
  val userRepository: UserRepository
  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)
  }
}

同じく UserService を名前空間トレイト UserServiceComponent に包みますが、そこで UserRepositoryComponent に依存していることを自分型アノテーションで示します。

trait UserServiceComponent {
  self: UserRepositoryComponent =>
  val userService: UserService
  class UserService {
    def authenticate(username: String, password: String): User =
      userRepository.authenticate(username, password)
    def create(username: String, password: String) =
      userRepository.create(new User(username, password))
    def delete(user: User) = userRepository.delete(user)
  }
}

最後に、これらのトレイトを継承した環境トレイトを作ります。ここでは実際にアプリケーションに使うものを RealWorld としました。そしてそのトレイト内で UserRepositoryComponent と UserServiceComponent をインスタンス化して保持しておきます。

trait RealWorld
  extends UserRepositoryComponent
  with UserServiceComponent {
  val userRepositoryComponent = new UserRepositoryComponent
  val userServiceComponent = new UserServiceComponent
}

こうしておくと、 Main オブジェクトで RealWorld を継承するだけでアプリケーション用のコードを書くことができます。すべての依存性が RealWorld トレイトに集まっているのがわかります。

object Main extends RealWorld {
  def main(args: Array[String]) {
    ...
  }
}

また、テスト時には次のようにすべての依存性をモックした TestEnvironment を使うことができます。

trait TestEnvironment
  extends UserRepositoryComponent
  with UserServiceComponent {
  val userRepositoryComponent = mock[UserRepositoryComponent]
  val userServiceComponent = mock[UserServiceComponent]
}

そして、単体テストしたいクラスは実際にインスタンス化して試すとよいでしょう。

class UserServiceSpec extends Specification with TestEnvironment {
  override val userService = new UserService
  ...
}

実際に動く完全なコードは一番下に GitHub へのリンクを置いておきました。これを見るとうまいこと依存性を分離して保管できており、しかもテスト時にもうまくモックできていることがわかります。

考察

自分型アノテーションを使うところ、べつに UserServiceComponent extends UserRepositoryComponent と書いても問題なく動くのだけど、自分型アノテーションを使うのは環境トレイトを作るときに依存性を見やすくすることが目的だろうか。つまり

trait UserRepositoryComponent {
  ...
}

trait UserServiceComponent extends UserRepositoryComponent {
  ...
}

trait RealWorld extends UserServiceComponent {
  val userRepositoryComponent = ...
  val userServiceComponent = ...
}

と書いても問題なく動くのだが、それより

trait UserRepositoryComponent {
  ...
}

trait UserServiceComponent {
  self: UserRepositoryComponent =>
  ...
}

trait RealWorld
  extends UserRepositoryComponent
  with UserServiceComponent {
  val userRepositoryComponent = ...
  val userServiceComponent = ...
}

と書くほうが RealWorld が extends しているトレイトと注入している依存性が一対一に対応するぶん見やすい。

あと Haskell で似たようなことできないかなーと思って探してみたら予想通り型クラスを使ったそれっぽい論文を見つけたのでそのうち読む。

まとめ

今回書いたコードは GitHub にまとめておいた。 TwitterBot の例も Cake Pattern で書いてみたよ！といっても同じことを繰り返しただけだけど…

daimatz/CakePattern