もぐてっく

人は1つ歳をとるたび、1ビットづつ大きくなれると信じてた。

mikutter Advent Calendar 2013 17日目 肉食系プラグイン作成術

はじめに

この記事はmikutter Advent Calendar 2013(http://www.adventar.org/calendars/120)17日目です。

まだまだカレンダーには空きがございます。チャンスです。
mikutterを使ってみての感想とか、短めのエントリも全然OKと思います。
ぜひともmikutterへの思いを繋いで行きましょう。


さてさて、皆さんご存知の通り、mikutterのプラグイン機構はとってもエレガント。
ほんの少しのコーディングで様々な機能をmikutterに追加することが出来ます。

例えば、クリスマスムード漂うあなたのTLを真っ赤に染める位なら、ほんの数行でちょちょいのちょいです。

# -*- coding: utf-8 -*-

Plugin.create :red_background do
  filter_message_background_color do |message, color|
    color = [65535, 0, 0]
    [message, color]
  end
end


でも「mikutterちゃんにこんなこともして欲しい(>_<)」がエスカレートしてくると、用意されたAPIでは実現できないことも出てきますよね。

そこで今回は「肉食系mikutterプラグイン作成術」と題して、少々強引な方法を使って、あなた好みのステキなmikutterをgetする方法を書いてみようと思います。

復習:1分で何となく分かるmikutterプラグイン

mikutterは処理の要所要所で「フィルタ」や「イベント」を通じて、プラグインと会話しようとします。
プラグインは興味のある「フィルタ」、「イベント」をハンドリングする事でmikutterの挙動を変更しする事が出来ます。

上記の真っ赤なTLの例ではfilter_message_background_colorと言うハンドラを定義して、つぶやきが描画される際に呼ばれる:message_backgroundと言うフィルタを捕捉しています。
そしてfilter_message_background_colorの中で色コードを設定することで、つぶやきの背景色を変更しています。

さて、本題

この様に強力なイベント機構によってダントツの拡張性を誇っているmikutterさんですが、残念ながらこのモデルは万能ではありません。


例えば、タブに表示されるアイコンのサイズを変更したいとします。

この場合、タブのアイコンが書き換わるタイミングに発行されるフィルタをハンドリングして、少し小さめのアイコンを返してやれば良いと言う発想になります。

しかしながら、mikutterには残念ながらそのフィルタは用意されていません。
フィルタが発行されない事にはプラグインは介入のしようがありません。困りました。


ここであきらめるのも悔しいので、抜け道が無いかソースコードを読んでみます。
タブのアイコンを表示する処理はgtkプラグインのtab_update_icon()と言うシンプルなメソッドで行われています。

def tab_update_icon(i_tab)
  type_strict i_tab => Plugin::GUI::TabLike
  tab = widgetof(i_tab)
  if tab
    tab.remove(tab.child) if tab.child
    if i_tab.icon.is_a?(String)
      tab.add(::Gtk::WebIcon.new(i_tab.icon, 24, 24).show) # ここの24が書き換えれれば・・・
    else
      tab.add(::Gtk::Label.new(i_tab.name).show) end end
  self end

直接gtk.rbを書き換えてしまえば話は早いのですが、これだけのためにgtkプラグインをフォークするのもアホらしいですし、ユーザにパッチ作業を要求するのも非常にアレです。

どうにかプラグインで実現出来ないか?

黒魔術ですべてを思いのままに


まどか「・・・私なら、何でも願いが叶うって言ったよね?」

QB「ああ、君ならどんな不可能も可能にできるだろう。さぁ、願いを言うんだ。まどか。」


すーっ・・・


まどか「すべてのメソッドを、生まれた後に書き換えたい!全てのインスタンス、クラスとモジュールのすべてを!この手で!!」


QB「そんな祈りが叶うとすれば、それはオーバーライドなんてものじゃない。オブジェクト指向そのものに対する叛逆だ・・・君は本当に神になるつもりなのかい!?」


なれちゃいます、神様。


思い出してください。
mikutterはRubyで作られています。

Rubyと言えば動的プログラミング。
別名「黒魔術」を使えば、任意のタイミングでクラスのメソッドを変える事すら、我々には不可能では無いのです。


早速、黒魔術でプラグインからtab_update_iconを上書きしてしまいましょう。

Plugin.create :tab_icon_size do
  Plugin[:gtk].instance_eval {
    # 独自のタブアイコンメソッドを上書き定義
    def tab_update_icon(i_tab)
      type_strict i_tab => Plugin::GUI::TabLike

      tab = widgetof(i_tab)
      if tab
        tab.remove(tab.child) if tab.child
        if i_tab.icon.is_a?(String)
          tab.add(::Gtk::WebIcon.new(i_tab.icon, 12, 12).show) # 半分の大きさになれっ!
        else
          tab.add(::Gtk::Label.new(i_tab.name).show) end end
      self
    end
  }
end

このコードが実行されて以降、tab_update_icon()が呼ばれると、上書きした方のメソッドが実行される様になります。
すげぇぜRuby


この手法は、巷では「モンキーパッチ」と呼ばれている様です。
元のソースコードを一切触らずパッチが充てられるので、アプリケーションのHotFixなどに有効活用されています。
オブジェクト指向が流行った時に言われてた「差分プログラミング」って奴ですね。

でも、モンキーパッチは便利な反面、どこぞのプラグインがこっそりメソッドの挙動を変更した場合、非常に分かりにくいバグを生む恐れもあります。

mikutterに於いては、複数のプラグインが同じメソッドをモンキーパッチした場合、先にロードされたプラグインが正常に動作しない事になります。
また、モンキーパッチによってmikutterのコアの動作を阻害する可能性もあります。

(後、mikutterの薄い本vol.4でとしぁさんがモンキーパッチをちらっとdisってたのもちょい気になります。)


複数のプラグインが共存できないと言う点で、もはやこれはプラグインではなく「MOD」とか呼んで区別した方がいいかもしれません。


しかしながら有益な技には違いないので、何とか副作用を抑えて活用して行きたいところですね。


例えば、何かしらモンキーパッチを検出する機構を作って競合を発見可能にすれば上記の事故は起こらないかもしれません。


・・・


さて、エントリがやたらと長くなってきたので、今回はこれ位で。
次回はこれまた黒魔術を使って、モンキーパッチ検出機構を構築して見ようと思います。

(そのうち続く)