0.3の予定

次のバージョンは0.3です。簡単に予定している変更を上げておきます。

i18n

mikutterは、開発リソースの少なさによる開発速度の遅さを補うためにできるだけ実装する機能をカットしていました。そのため、流暢な日本語で「英語対応してください」などと言われても、「日本語お上手ですね」と返答していました。しかしこの間ついに英語圏の人から英語のメールが来てしまったのです。もう逃げられないので、一応多言語化の仕組みだけ作る予定です。

コア機能の分割

mikutterのコアが肥大化してきたため、一部機能はRubyGemで配布します。この準備のために、0.2.2ではbundlerを使えるようにしました。勿論ビルドプロセスで、tar ballを作る時にこれらをbundlerなしで使えるようにするので、通常の使用においては何の影響もありません。

ライブラリを切り離すことで、mikutterのバージョンアップとは違うリリースサイクルを持てること、mikutter以外でもそのライブラリを使用できること、それによって品質の向上が期待できる等のメリットがあります。

ライセンス変更

現在のmikutterのライセンスはGPL3ですが、今となってはmikutterにこのライセンスは適切ではありません。GPL3は、mikutterから派生したコードに同じライセンスを適用することを要求しますが、私はそれを要求するつもりがありません。そのため、mikutterプラグインにGPL3以外のライセンスを適用することが可能なのかどうかが不透明になるという問題がありました。

そこで、mikutter 0.3からは、MITライセンスを適用することを検討しています。理由は主に、mikutterはTwitterクライアントではなくTwitterに特化したBotフレームワークであり、フレームワークのような再利用されることを目的としたコードには、上記のような理由から緩いライセンスのほうが良いだろうということです。似たようなソフトウェアとしては、Ruby on RailsやSinatraが同じライセンスのもとで配布されています。

ただし、mikutterは既に多くの人のパッチをいただいており、この変更にはその人たちの承諾を受ける必要があります。幸い、ある程度貢献度の高い人たちには直接話をして、既に意見を頂いています。そのうち、Redmineのニュースで開発者全員に正式にこのことについて説明をして、最終的な決定を下します。

タイムラインのレンダリング方法の変更

Twitterのタイムラインという非常に特殊な情報を表示するため、多くのTwitterクライアントは様々な工夫をしており、mikutterも例外ではありません。二年前に抜本的な再設計を行いましたが、更に効率的にする余地があります。うまくいく目処が立ったら、紹介するかもしれません。

みっくストアの標準プラグイン採用

これは0.3では厳しいかもしれない。

みっくストアは、githubにアップされているプラグインをgitを使用してクリックでインストールできるコンセプトプラグインです。これを洗練させて標準プラグインにして、標準プラグインをこの管理下に置けば、mikutterのリリースサイクルに囚われること無くプラグインを個別にバージョンアップできます。例えば、twitpicの仕様が変わって画像が開けなくなった時、mikutterのバージョンを上げなくても画像プレビュープラグインだけをバージョンアップできます。

方向性の確認

mikutterはプラグインホストです。その拡張性故にmikutterはTwitterクライアントさえも実装することができました。最近、「mikutterはどこに向かっているんだ」という励ましの言葉をいただきます。その認識は全くの誤りで、最初からそういうスタンスで開発してきたが、最近になって漸く皆さんがそのことに気がつき始めたのです。

その意味で、これからはTwitterクライアントとしての機能追加ではなく、より根本的な変更がメインになっていくと以前どっかに書いた気がします。0.3は、さらにmikutterエコシステムの発展に貢献する変更を加えることが根本的な目的です。

スケジュール

8月までは、多忙のためmikutterにはコミットできないと思います。0.3の開発は8月から本格的に開始するため、寒くなるころには出せたら良いかなといったところでしょうか。0.2.2の不具合修正もできないですが、報告は早いほうがいいと思うので、バグ報告はおねがいします。

#mikutter 0.2.2.1230

mikutter 0.2.2を正式リリースします。pre3と全く同じ内容です。

• 機能追加・仕様変更
• 実績機能
• ショートカットキー設定のUIの改善
• デーモンモードを試験的に実装
• bundlerを使って使用しているライブラリをインストールできるようにしてみた
• プラグインのGemfileに対応
• ふぁぼ・リツイート数をAPIから取得するように変更。
• 内部変更
• プラグイン・イベント周りの処理を大幅に変更。依存関係を満たしておらずロードできない場合は警告を表示するようにした
• サウンドを鳴らす方法を拡張できるようにした
• 高速化

サウンド関連プラグイン以外は0.2.1と互換性がありますが、そんなのあんまりなかったので関係ないと思います。今回はアップデートが大幅に遅れましたが、いろんな機能が追加できてよかったです。新機能についての詳細は、3月のエントリ「mikutter 0.2.2の新機能」をご覧ください。

#mikutter 0.2.2.1230 pre3

• 人をリムーブするとクラッシュすることがある (thanks @moguno)
• アクティビティに種類「ratelimit」を追加。他の多くのTwitterクライアント同様、規制されても通知を出さないようにした。あたかも規制されていないように見えて気分が良い。

細かいバグ修正です。もうこれでいけるやろって言うといけないということが改めて分かったので、言いません。でももし土曜日になっても新しい不具合が見つからなければ、これを以てリリースとします。

ここからは数カ月間忙しくなるので更新が停滞すると思います。不具合の対応も極めて遅くなると思われるので、運用でカバーしましょう。生きているって素晴らしい。

#mikutter 0.2.1.1142 and 0.2.2.1225 pre2

0.2.1.1142

• 未知の形式のエンティティを受信するとクラッシュする問題
• openimg: yfrogの仕様変更対応と、instagramの一部の画像の仕様に対応(thanks @negi_s)
• extract: Twitterクライアントで抽出するとクラッシュする問題の対策を0.2.2からバックポート
• directmessage: 自分自身にDMを送った時に適切なイベントが発火していなかった (thanks @nullpo_head)

0.2.2.1225 pre2

• 0.2.1.1142を取り込んだ
• TLのレンダリング中にエラーが発生した時にクラッシュしないようにした
• プラグインロード関連処理の修正

0.2.1のバグフィックスです。特定のツイートを受信するとクラッシュする問題がありました。TLにツイートが表示される間はクラッシュし続けるので良くないです。アップデートしましょう。

0.2.2ではそういう時はクラッシュする代わりにへんな画像を表示してお茶を濁そうとします。ことなかれ主義っぽくて日本的で良いと思います。

0.2.2のバグ修正殆ど無いですね。特に問題がなければこの土日で0.2.2を正式にリリースします。ていうかまだやってなかったのかよっていう。幾つかすごい細かいことが気になっている部分があるので、リリースまでに直すかもしれません。次期バージョン（0.2.3 or 0.3）についてもそのうち書きます。

#mikutter 0.2.2.1211 pre1

mikutter 0.2.2 テスト版を公開します。というか内部スケジュールが押してしまってこれ以上延期するといろいろ問題があるので…。主な変更は前に先走って投稿したエントリをご覧ください。
http://mikutter.blogspot.jp/2013/03/mikutter-022.html

簡単にまとめます。

• 機能追加・仕様変更
• 実績機能
• ショートカットキー設定のUIの改善
• デーモンモードを試験的に実装
• bundlerを使って使用しているライブラリをインストールできるようにしてみた
• プラグインのGemfileに対応
• ふぁぼ・リツイート数をAPIから取得するように変更。
• 内部変更
• プラグイン・イベント周りのコードを刷新
• プラグインのロード処理を大幅に変更。依存関係を満たしておらずロードできない場合は警告を表示するようにした
• サウンドを鳴らす方法を拡張できるようにした
• 高速化

今回から、バージョンの最後の桁はSubversionのリビジョン番号ではなく、ビルド番号になりました。mikutterの開発を始めてから経過した日数です。そんなにリビジョン番号と離れていなかったので違和感もないし、ぶっちゃけどうでもいいことです。今回公開したのは1211で、実は前に1201を公開したけれどアナウンスしませんでした。

テスト版なので、起動する前には~/.mikutterのバックアップを取っておいてください。実装したかった機能は残ってるけどだいたいバグは取ったのでリリースは近いか（フラグ）。

THE DAY

今年も、4月1日を無事に終えることができた。去年よりも多くの反応があり、ユーザの増加を実感した次第である。

四年目
あなたは何回mikutterと共にエイプリルフールを超えただろうか。エイプリルフールにアイコンを変更するのは今回で4度目だ。一度目は2010年。あの頃は開発が始まってまだ3ヶ月しか経っていなかったし、まだあまり時間をかけていなかったので、Twitterクライアントとして、ほとんど使用には耐えなかった。当時存在した数少ないユーザとは、たった16種類のアイコンで大いに盛り上がったのを今でも4年前の事のように覚えている。しかし、このいたずらを快く思わない人もいた。

mikutter開発の動機
初音ミクはかわいい。かわいいアイコンは素晴らしい。初音ミクアイコンは、考えうる最高のアイコンである。しかし現実はどうだ。ほとんどの人が初音ミクのアイコンを使っておらず、初音ミクアイコンの人をまとめたリストまで見られる。嘆かわしい限りだ。
アイコンを初音ミクにしないがために人々の心はすさみ、TLでは諍いが絶えず、Togetterは常に炎上、ついに運営チームの心も蝕まれ、サードパーティを排斥しはじめて久しい。これらはすべて、人々の心にミク分が不足していることが原因である。
このことを2009年にすでに予知していた私は、なんとかこの滅亡の戯曲の台本を書き換えようと試みた。そう、つまりクライアントサイドでアイコンを書き換えるのだ。mikutterが描こうとした世界は素晴らしいものだったが、私の声はTwitterに対してあまりにも小さすぎた。

約束の日
それから一年後、またエイプリルフールが訪れた。ユーザ数は40倍近くに増え、アイコンも128種類に増やした。やはりユーザが増えるとわかってくれない人もいる。ユーモアを必要条件に掲げているのに、ユーモア欠乏症患者は概して日本語が読めないので、平気で使いやがられるようだ。
だが、ここで私は数人の奇妙なケースを目の当たりにした。去年disっていた人が楽しんでいるではないか。彼らは心を腐らせていたにも関わらず、ふぁぼられる度にミクの声に心を浄化され、人の心を取り戻しつつあったのだ。
この時私は初めて、mikutterを作ってよかったと思えた。開始から一年を超えて、漸く私は、無意識にしか自覚出来なかったmikutterの真の目的を自覚することができたのだ。私はこの日を約束の日と定め、来年のその日のために早速一年のロードマップを打ち出した。

本質
私はもともとTwitterクライアントをつくろうと思ったのではなかった。ではなぜmikutterが今の形になったのだろうか。全ては約束の日のためである。一人でも多くの人に、心を取り戻して欲しい。もう「手遅れ」な人もいるかもしれない。しかし、「ておくれ」な人も多い。きっと彼らと来年はともに笑いあえることを信じて、私はキーを打ち続けている。
mikutterの本質はTwitterクライアントでは断じてない。約束の日のための単なる釣竿に過ぎず、ユートピアを映し出すスクリーンに過ぎない。あの便利な機能も、最適化も、全部エイプリルフールである。この間数年触っていなかったCで書かれたruby-gtk2のコードに必死の思いでパッチを投げたのもエイプリルフールのためである。つまり、Twitterクライアントとしての側面は単なる約束の日の準備であり、約束の日のタイムラインこそが、mikutterなのである。ユーザである（と、あなたは思い込んでいるのだろう）あなたたちは、私の手の上で踊らされていたのだ。

失敗
今年の約束の日は、一見無事に成功したように見える。去年同様、フィルタでほとんどのネットワーク経由の画像読み込みを差し替えた。そのことによってTwitterBirdも姿を変えることになったし、mikutterコマンドのアイコンも変わったが、癒されるので由とした。同様の理由で、昨年好評だった、通知のアイコンがエイプリルフールのままになる不具合は残しておいた。
正直に告白すると、私は今回やってはならないミスを一つ犯してしまったのだ。それは、環境によってある人のアイコンの見え方が異なる場合があるというものだ。判明したのは3月の終わりの方で、これに気づいたときはもうmikutterは終わったと思った。
しかし、やるしかない。問題を修正し、入念に確認したあと、すぐにそれっぽい不具合をでっち上げて、さもすぐアップデートしないとデータの破損を引き起こす可能性があるかのような虚偽のリリースノートを書いた。約束の日はmikutterにとって最重要と言うよりもmikutterの全てだ。そのためにはリリースノートを偽ることも、1コミットで2つの変更をすることも厭わない。全てを秘密裏に行い、その日を迎える必要がある。
今年は会社に泊まることはなく、自分の目で全てを見届けることができた。大きな失敗はあったが、去年以上に多くの人が楽しんでくれた。最初はわけがわからないと言っていた人も、1日が終わる頃には、ミク以外のアイコンに違和感を覚えるほどにまで精神を浄化されていた。今年もmikutterがその目標を達成できたという意味では、今年も成功したといって良いだろう。

手段の目的化
この一年、私はTwitterクライアントを作ることを目的にしてしまっていたのではないか。こんな機能が必要だ、こういうUIが良い、最近のデスクトップ環境のUXとの相性は…。もちろんそれは魚を釣るために必要なことだ。しかしそれはあくまでも餌で、本来の目的ではない。Twitterクライアントなんてどうでもいい。品質なんてある程度でいいんだ。そこがブレたから、守りの開発になった。何をやるにも違和感があった。そしてミスを許した。ユーザに対しても失礼なことだし、何よりmikutterがかわいそうである。

4月1日、自らが創りだしたTLに、自らの魂が浄化されるのを感じた。そうだ、これだよこれ。これがmikutterなんだ。Twitterクライアントではなく、mikutterを創っているんだ。ユーザを増やして、どこにも初音ミクなんて書いてないのに「ミク要素がない」と言った奴らに目に物見せてやるんだ。そういう思想的バックボーンがあったから、Twitterクライアントが飽和状態のWindowsのユーザでさえ、mikutterを羨むんじゃないか。

反省
先に一つだけ言っておきたいことがある。今年は直前になって、過去のエイプリルフールエントリ「約束の日」「謝罪」のリンクをTwitterに貼る人がいたが、これはやめていただきたい。mikutterのユーザは私も驚くくらい増えている。新参者がこのことを事前に知ることはできるだけ避けたい。

ではどれくらいユーザが増えたのだろうか。正確な数はわからないが、mikutterは約束の日のために、3月からサーバ上から当日のために画像を収集する機能が備わっている。そののため、サーバのログを見れば、おおよそのユーザ数をつかめるのだ。例年通り、統計データだけ公開する。

ユニークIPアドレス数　1989
当日ユニークIPアドレス数　332
3月ユニークIPアドレス数　1897

肝心のユーザ数の正確なところがわからないが、ユニークIPアドレス数というのが参考になる。勿論、家の他に学校や職場、モバイル回線でも使う人なら多重にカウントされてしまうので正確な数ではないが、例年と比べると明らかに増加傾向にある。

約2000なので、少なく見積もっても1000くらいはいきそうだ。10万トークンの上限を心配する人もいたが、これを見る限り、全く問題は無さそうだ。

ところで、0.2.1からDisplay Requirementsに対応したことで、Twitterの鳥をタイムラインの下に表示しなければならなくなった。実はこれはライセンス等の問題でmikutterには同梱されておらず、mikutterのWebページのサーバからダウンロードしてきているのだが、ついでにログを集計してみたところ、1736という数字が出た。こちらはエイプリルフールと違って、同じ設定ファイルを使いまわす限り必ず一度しかアクセスしないため、テザリングなどで頻繁にIPアドレスが代わる人を多重カウントしないのでより正確かもしれない。今年の予想人数（上のグラフ）はこの数字を採用した。

共犯者
今年使用したアイコンは、半分は @penguin2716 さん、もう半分は新たに @catina013 さんに描いていただいた。私も10枚ほど描いたが、合計256枚のアイコンを提供してくれた二人にはいくら星謝しても足りない。この場を借りて改めてふぁぼりたい★。

まとめ
当日はトラブルもあったが、概ねうまく行ったと私は思っている。しかし成否はあなた自身が決めることだ。今年も楽しんでもらえたなら何よりだし、例年または開始時はうっとおしい、区別がつかないと否定的な見方をしていた人が楽しめるようになったならこれほど喜ばしいことはない。最後まで人の心を取り戻せなかった人もたくさんいただろう。そういう人も、mikutterに触れていくうちに、必ず人間に戻れると私は確信している。

最後に、念のため書いておくが、以上の内容は全てエイプリルフールである。

プラグインに実績を追加する

mikutter 0.2.2から実績機能が追加されます。

これは、皆さん分かってると思いますが achievement というひとつのmikutterプラグインが提供している機能で、 achievement APIを使えば他のプラグインから実績を新しく追加することができます。

どんな風に実績を追加するか、実際のコードを見てみましょう。

これは、5favされたら解除される実績、「red_fav」を追加するプラグインです。実際にこれをインストールして起動すると、4行目の :hint の値がアクティビティに表示されます（他に未解除の実績があれば、そちらが表示される可能性もあります。表示される実績は毎回ランダムです）。ここに解除の仕方を書いておけば、ユーザは起動する度にそれを一定の確率で目にするので、実績を解除する手助けになります。

defacievement

実装についてもう少し詳しく見てみましょう。defacievementというプラグインメソッドが今回の肝です。

第一引数はスラッグ、第二引数には以下の値を指定します。

• description ... 説明。現在は見返す方法がないので、用意されているだけ
• hint ... 起動時にアクティビティに表示されるヒント。hiddenがtrueなら必要ない
• depends ... 前提実績。実績のスラッグをシンボルの配列で指定する。指定された全ての実績が解除されていないとヒントが表示されない。
• hidden ... 隠し実績。trueなら、起動時にランダムに表示されるヒントの抽選対象に入れない。

defacievement のブロック

ここには実績を解除するための条件を記述します。このブロック、そもそも実績が解除された状態では実行されません。解除するための条件なので、もう解除された状態では必要がないのです。
この例では、「on_favorite ...」という部分です。この中もプラグインの一部なので、こうやってイベントリスナを設定することができるのです。

Plugin::Achievement::Achievement

defachievement ブロックは一つの引数を取ります。これは実績オブジェクト(Plugin::Achievement::Achievement)のインスタンスです。実績の主要な情報を得たり、実績を解除するために使います。defachievementを呼び出す度にインスタンスが一つ作られる感じで、普段あまり気にするものではないです。

実績解除

Plugin::Achievement::Achievement#take! を呼びだせば実績が解除されます。このメソッドが呼ばれると、直ちに defachievement ブロック内でセットされたイベントリスナやフィルタ（例ではon_favorite）が解除されます。

それから、前提実績をチェックして、まだ解除されていないものがあればそれを待ちます。これは、前提となる実績より先に現在の実績が解除されるのを防ぐためです。この状態で前提実績が解除されたら、すぐにこの実績も解除されます。

そうやって実際に解除されたら、 achievement_took イベントが発火されます。

achievement_took(Plugin::Achievement::Achievement)

実績解除のメッセージはこのイベントをachievementプラグインが受け取った時に表示されるようになっています。実績解除をトリガーに何かをしたいということはあまり無さそうですが。

実績の例

mikutterの標準の実績は全て achievement プラグインに集約されています。以下のプラグインの100行目あたりから後は、全て実績の定義です。

http://dev.mikutter.hachune.net/projects/mikutter/repository/revisions/develop/entry/core/plugin/achievement/achievement.rb

実績を見てしまうとネタバレになるのですが、それぞれが全く異なった方法で実装されているので、これだけで例としては十分でしょう。このファイルの前半の方は、実績プラグイン自信の実装です。このプラグイン、mikutterプラグインとしても結構興味深いのですが、それについては別の機会に触れたいと思います。

ヒントのタイミング

最後に、一応、実績のヒント(hint)がユーザに提示される条件を説明しておきます。毎回mikutterが起動される度に、

• 未達成で
• hidden が偽か未指定

の実績のうち、ランダムに一つを選出します。その実績に上記条件に当てはまる前提実績があれば、再帰的にそれを辿って、最終的に一つだけ実績を選んでそのhintの値を表示します。

前提とされている数が多い実績のほうが、表示される可能性が高くなりますね。前提実績が解除の邪魔をしているような実績のヒントは表示されません。

また、ユーザには、mikutterを再起動する以外に新しいヒントを得る方法がありません。Twitterクライアントの使い方なんて一気に勉強するものではありません。ゆっくり覚えたらいいし、もっと言えばTwitterなんてしてないでとっととレポートを書くべきです。mikutterのせいで単位を落としたって、私にはふぁぼることしかできません。

まとめ

使えそうで使えない、楽しそうで案外どうでもいい、実績機能について紹介しました。かなり変な機能なので、構想はかなり前からあったにも関わらず、0.2.1では導入を見送っていました。DRを言いたかっただけです。