この記事は、mruby Advent Calendar 2016の12日目の記事です。
遅れてしまって申し訳ありません＞＜
mrubyを使い始めて3ヶ月ぐらいです。
mruby-cliでサーバー上で動くバイナリを作っています。
C側にはまだあまり手を出せてないですが、今作っているものは.rbファイルだけでも20ファイルを超えて、ちょっとした規模になってきました。
せっかくmrubyスクリプトでバイナリを作れるのに、デバッグがしづらいなぁというのが今持っている印象です。
そこで、デバッグの方法としてどういった手段があるのかをまとめるとともに、あわよくば皆さんがどうしているのかを伺えれば、という思いで書いてみました。
ここでは、デバッグの対象はmrubyスクリプトのみとします。
printデバッグ
基本でお手軽。
ただ効率としては決して良くはない。
mrdb
http://forum.mruby.org/docs/dmanual.html
mruby公式のデバッグ機能。
ブレークポイントを設定できたり、ステップ実行できたりと魅力的な機能があります。
が、mrubyスクリプト(.rb)、もしくはそれをコンパイルしたバイナリファイル(.mrb)単品のデバッグしかできないっぽい。
なのでmruby-cliで作ったようなバイナリをデバッグするのはできない…のかな？
nomitory
http://magazine.rubyist.net/?0050-nomitory
Eclipseのプラグインで、GUIでブレークポイントを設定できたりするらしい。
試してないけど、Eclipseというところでちょっと乗り気じゃない。
mirb
バイナリとともに生成されるmirbには、使用しているmrbgemsや自作のコードも含まれています。
なので、そのあたりのクラスなどの挙動の確認するのに便利なケースがあります。
ロガークラスを作る
print文を書いて消してしなくていいように、ロガークラスを作りました。コード中に書きっぱなしでも普段は機能しなくて、実行時に引数でデバッグモードを指定してやった場合にだけファイルにログを書き出すやつです。
処理の主要な部分と、例外発生時に来る部分とに入れておけば、比較的早く原因箇所が特定できます。
まだ作りが粗いので、整理してmrbgem化したい。
例外情報をAWS S3に上げてみる
デバッグというか、運用面を考えてのことですが、
例外発生時にAWSのS3に情報を上げる仕組みを作ってみました。
今は上げてるだけだけど、これをトリガーにしてslackに通知とかもできるはず。
ただ、本番環境で動いているものはビルド時にデバッグオプションを付けていないので、あまり情報量はない。。
まとめ
今のところ自分が把握している/用意した手段はこのぐらいです。
ロガー作ったあたりから比較的楽になった気もしますが、もっといい方法が無いかと模索中です。
みなさんどうされているか、ご教授いただけると幸いです！