この記事は、Elixir Advent Calendar 2015 9日目です。前日は Elixirでリバーシ でした。実は昨年のElixir Advent Calendar 2014にも参加させていただいておりまして、2014年のElixir1.0初心者 という題で、触り始めで良かった・困ったことなどを書くソフトな記事を書いておりました。
何を作っていたのか
- ネットワークゲームの通信を入力
- JSONをばらして内容を解析
- 解析内容を組み合わせて現在の状態を計算
- 適当に表示
ネトゲの(非友好的な)解析としては基本的なやり方のひとつです。
何が便利なのか
- アプリケーションを動かしたままコードを入れ替えられる
- アプリケーションは部分的に死ぬ (全滅しない)
真ん中の行、処理していないAPIは単にコンソールに名前を吐いています。この api_get_member/ship_deck が来たときにもコンソールに情報出しとくかー、と思いたったとしたら、ささっとコードを追加あるいは更新してリロード。メモリ上に保持したアレコレをそのままに、さらりと次回叩いたときから処理が動くように組み込めます。
(enemyとmap infoの間に追加情報が2行出るようになった!)
コード上では、 Kernel.ParallelCompiler のfiles/2に対象のファイル名を渡しています。保持しているデータ型を変えようとすると面倒になるはずですが、処理ロジックの入れ替えだけであれば、大したことはありません。
そして次の、アプリケーションが部分的に死んでくれるという特性について。ゲームしながら空き時間にいじるような注意力散漫なコーディングをしていると、よくエンバグしてこけます。言語に不慣れならなおさらのこと。あるいは、ある日突然JSONの構造が変わって、処理がうまくいかなくなることもあります。そういったときに、アクターモデル(Erlangプロセス)の仕組みは便利なものでして、JSONをパースしていくらかの計算をする部分、構成図でいうparseの部分が死んだところで、アプリケーション全体としてはなんともありません。その失敗した処理要求は、何も工夫しなければどこかに吹き飛んで消えてしまいますが、必要ならオペレーションを保持しておいて、処理関数を更新した後にリトライすれば復旧も可能です。Event sourcing的な。
Erlangを用いたシステムの高信頼性とは、「落ちてもいいように作る(そういう仕組みを作りやすい)」という面があって、趣味でだらだら遊ぶにも向いているのでは…!
Elixirによる自作ツールの可能性
以上、ちょっとしたツールにも便利ですよーという話でした。単純なスクリプトにお勧めはしませんが、処理を待ち受ける or 何かを監視する、生存期間がそれなりにあるツールには向いています。GUIが欲しければ、Phoenixを組み込んでしまえば良さそう。Elixirという言語&Erlangの実行系に慣れるという副次効果まで考慮して、遊びのツールを作るという路線、布教あるいは学習方法のひとつとして、いかがでしょうか。
0 件のコメント:
コメントを投稿