#mikutter 0.2.1 pre1

rev.1112を、当初12月25日にリリースする予定だった 0.2.1 のプレビュー版として公開します。ちょっとづつバグ修正をしながら、適当なタイミングで不安定版としてリリースします。

http://mikutter.hachune.net/download

ざっと行った変更を。

• 機能・仕様変更
• mikutterコマンドにアイコンを設定できるようになった
• commandメソッドの引数に :icon キーを追加。ファイル名（URLかローカルのパス）を指定する。サンプルはcommandプラグインを参照
• タブツールバー。タブレベルコマンドで表示設定とアイコン設定があるものは、タブごとに作成されるツールバーにアイコンが表示されるようになった。
• Twitter APIレスポンスのStatusオブジェクトのふぁぼフラグを無視するようにした
• 被ふぁぼRTのラベルをアイコンに変更
• ディレクトリ構造ちょっと変えた
• 環境対応
• Twitter API 1.1に対応
• 各エンドポイント毎にレートリミットが設定されています。mikutterで各エンドポイントのレートリミットを確認する方法はありません（やっつけでステータスバーに表示しているが実用的ではない）。
• 検索に非公式リツイートの形式でリツイートが表示される問題を解決
• その他、レスポンスが変わったことで若干動作が変わっている部分があります。大まかにはドキュメントの通り https://dev.twitter.com/docs/api/1.1/overview
• Developer Display Requirementsに準拠したUIに変更
• TLでは、名前よりスクリーンネームを後に表示。クリックするとプロフィールを開く
• Icon Over Buttonを廃止。アバターアイコンをクリックするとプロフィールを開く
• ツイートのタイムスタンプを相対時刻表示に変更。クリックするとブラウザでツイートのパーマリンクを開く
• 被ふぁぼ、RTのアイコンの右側にはそのユーザの名前を表示
• 全てのタイムラインの下にTwitterのロゴを表示、twitter.comにリンク
• ハッシュタグのリンク先をWebサイトの検索ページに変更。検索プラグインがWebサイトを開く機能を有していないため
• 各変更は必須要件なため設定によって変更することはできない。設定によってはね。
• バグ追加・修正
• Twitter API 1.1の挙動を把握しきれてないのでそのへんでなにかあるかも

若干予定を変更して、Twitter APi 1.1に対応しました。認証の問題が未だに起こっている環境では、このアップデートで改善される可能性が高いです。

同時にDRにも対応しました。予定変更の経緯は過去のエントリを。このへんのことをこのブログを見ていないmikutterユーザにどう伝えるのか、困ったものだ。

リアルでいろいろあってリリースを遅らせたので、ちょっと慎重にpre版とか言っていますが、API周りで何もなければこれでいくでしょう。また、mikutter 3周年記念リリースであることにも変わりはありません。だからと言ってなにか有るわけではないですが。

mikutter 三年目

はじめに

あけましておめでとうございます。 mikutterは2012年12月25日を以って3歳になりました。こんなことを三年もやってると思うと本当に残念な気持ちでいっぱいです。Twitter廃人とはよくいったものですが、相変わらず私は起きてる間しかPostしないエンジョイ勢ですよ。
とはいえ、まだしばらくずるずるとやってると思うので、よろしくお願いします。
例年通り、去年一年間にmikutterに起こったことを振り返ってみましょう。

去年の目標とかを振り返る

去年のブログから

アクティビティ情報がリアルタイムに取得できる Streaming API が出たらぜひ対応したい

ぷっ

いい加減、1.0ですかね

ぷっ

結論

来年のことを言うと鬼がふぁぼる。

年明け

この年の年明け、つまりちょうど一年前ですが、mikutterは0.0.4でした(0.1は存在したがpre版だった)。
現在0.2です。バージョン番号だけはやたらとジャンプアップしましたね。実際の機能はたいして変わってないです、上がり方の割りには。mikutterはバージョンなんてただの飾りだってことを僕達に教えてくれた。

mikutter自体のこと

0.1.x

before_api_section

APIのレートリミットがリフレッシュされる寸前にこれでもかというくらいAPIをリクエストしまくるサーバ泣かせな隠し機能です。きたないぞ！きたないぞmikutter！(標準ではリスト関連でしかしてなかったと思うけど)
こんな小さなことをわざわざ書いた理由は、間もなくこれが無意味なものになるからです。0.2.1では Twitter API 1.1に対応し、エンドポイントごとにレートリミットが設定されているため、このような処理をしても効果が薄いのです。残念。

リストのストリーミング

mikutterで表示するすべてのリストはリアルタイム更新されるようになりましたね。リスト自体がそんなに使われていない機能なので、これで喜んだ人はあまり多くなかったようですが、 API 1.1になってリストのタイムラインを15分で15回しか更新できなくなるので、15個のリストを表示していると1回で規制されますし、1アカウントが作成できるリストの数の条件である20個を表示している場合にいたっては、すべてのリストを取得することはできないという惨状です。
mikutterでは、このリストのストリーミングに対応しているため、ほとんど問題なくリストを使うことができます。他にない機能ということで鼻を高くしていましたが、PC用のメジャーなTwitterクライアントはこれを実装し、当たり前の機能となっていくかもしれません。スマートフォンではどうするんでしょうね。

アクティビティ

TwitterがアクティビティAPIをどうやらデベロッパに公開する気が無さそうだと悟るやいなや、自前でそれっぽいものを作成してしまいました。大量の通知の可視化という課題に対する革命的なソリューションであり、いまやmikutterのキラープラグインの一つです(自称)。

0.2

DSL拡張

プラグインにDSLカスタマイズをできるように、特定のプラグインに依存したプラグインを定義できるようにしました。最たる例がUI DSLです。プラグインがタイムラインやタブを構築するときに使うメソッドです。

gtkプラグイン

guiプラグインからgtkプラグインを分離してイベントでやり取りさせるようになりました。
UIの組立を任意のタイミングで実行できるようになり、体感速度が上がり、外部フィルタなどですべてのアクションに干渉できるようになりましたが、実際の処理ステップは増加しているので、起動時など大量のイベントが発生するときはやや動作がもたつくことがあります。とはいえ、速度改善は副産物に過ぎず、来年はこの仕組みを使った興味深いプラグインをたくさん提供できることでしょう。既に、標準のフォーカス移動関連の処理はこれらを使っています。

周辺の動き

mikutterの薄い本

1月15日、喫茶室長さんが、いろんな人が書いたmikutterにかんする記事をまとめた「mikutterの薄い本vol.1」を作成してこみトレで頒布しておくれました。確かtoshi_aとkatsyoshiさんが寄稿したと思いますが、vol.2からはもっと多くの方が書いてくれるようになりました。先日のコミケでは、vol.3を70部ほど頒布したそうで、こんなにも多くの人がmikutterに興味を持っているということに驚きを隠せません。
私自身は第一回から毎回寄稿させてもらっていて、ドキュメントを書く切欠に利用させてもらってます。まだまだ書かないといけないんですけど。

mikutterユーザ会

私がゴールデンウィークに東京に遊びに行った時、katsyoshiさんがmikutterユーザ会を企画してくださり、参加しました。要は単なる飲み会だったのですが、mikutterの名のもとにユーザやユーザじゃない人が集まってくれました。今思えばTwitter上で技術系クラスタの間で有名な人とかもいらっしゃったので、結構豪華なメンバーでしたね。当日お越しいただいた女帝さんに、緊張のあまり「ShootingStar作者のはるです」と自己紹介してしまったのが未だに気になっています(誤解されてないといいが)。不特定多数が参加できるmikutter関連のイベントに私が参加したのは初めてでした。

OSCに出展

8月4日に開催されたOSC Kyotoに「mikutter」として出展しました。今のところ唯一私が主催したもので、mikutterの開発者として不特定多数の人にお話をしたのは初めてでした。その時のことは OSC Kansai 2012に行ってきた というエントリにまとめました。

外の動き

ubuntu 12.04

Ubuntu 12.04がリリースされました。mikutterにとっては最初いくつか問題が起こりましたが、LTSでも簡単に新しめの動作環境を構築できるようになりました。やったね！

Twitter API 1.1

Twitterは9月かそこらにAPI 1.1を告知、過去のAPI 1.0を使用できなくするという発表をしました。いつかのBasic認証とかを思い出しますね。このAPIのアップデートによって、検索結果にリツイートが非公式リツイートのように紛れ込んでしまう問題などが改善しました。ありがたや、ありがたや。
あとは最近さんざん書いてるDisplay Requirementsの話とかがある。表示の仕方とかはmikutterの肝なので、新しくmikutterを使う人に誤解されてしまったら少し悲しいな。今年Twitterにあった最大の事件といえばこれですね。世界的にもこれは衝撃的だったようです。

反省

今年は結構コード書く以外のことをやった。その結果いろいろ面白かったんだけど、mikutterの開発速度が目に見えて落ちた。特にmikutterに使える時間が増えたわけではないのに(減ってる)、コードしか書かなかった時よりペースが落ちるのは当たり前か。一方で実装したい機能というのも、さすがにこれだけ続けていればひと通り出揃いつつある。私が魅力的に感じない機能はサードパーティプラグインで提供されたほうがいいし、これからはそういったものを作りやすい環境を整えることを考えた方がいい、気がしてる。
大袈裟な話じゃなくて、単にもうちょっとドキュメント書いたら割りと問題なくなると思ってる。みっくストアとかもあるけれど。今年はドキュメント書いていこうと思っていたけれど、前述のような理由や、書いたとしてもドキュメントというより日記みたいなことばかり書いていた気がする。全く、このブログを何だと思ってるんだ。「mikutter開発日記」だぞ。って、日記じゃねーか、これでいいのか。これでいい。

今年の目標

もう同じ過ちは犯さない。目標なんて立てたら全部達成できないんだ。だから胸のうちに秘めておくことにしよう。
そういえば、今年は元日未明に八坂神社を参拝してきて、mikutterの薄い本製作委員会がコミケに通りますようにってお祈りしてきました。
あっ

設定をつけよう

こんにちはー！

ごあいさつ

どうしようもない用事が入ってしまって年末までめっちゃ忙しくなったよ！だからmikutter 0.2.1のリリースは延期します！ 最優先にしても良かったのだが、ちょっと丁寧にやって少しでも安定した感じにしたほうがいいだろうと思ってね（思ってもない）。他の環境で動かなくても知ったこっちゃないがな！ぴょぴょぴょぴょぴょｗｗｗｗｗ
と、いつものご挨拶はさておきこの記事はmikutter アドベントカレンダー 25日目の記事です。あれ、おっかしいなぁ。俺4日目くらいに登録したと思ったんだけどな…？昨日のunaristさんお疲れ様、今回企画してくれたkatsyoshiさん、書いてくれた皆ありがとう。

お誕生日

今日はmikutterのお誕生日です。3歳になりました。ありがとう、これからもよろしく。今年を振り返る記事は正月中にこのブログで公開します。

閑話休題

折角なので、このブログで昔いつもやってたようなプラグイン開発のtipsを書くっていうのをやってみよう。 mikutterプラグインを作って公開している人は結構見かけるけど、こういうプラグインが割とよくある。
これは、ツイートを右クリックしてごぼうをクリックすると、そのツイートに対して「ごぼう♡」とリプライするプラグイン。一見、ごぼうの後の記号は GOBOU_SIGN を書き換えれば変更できるし、回数も GOBOU_QUANTITY を書き換えれば変更できるので柔軟性がありそうだが、こういったバリアブルな値を毎回ソースから書き換えるのは不便。
そんなわけで、mikutterには設定があるし、一部のプラグインは確かに設定に対応しているが、「こんなしょうもないプラグインが設定できてもなー、ていうかやり方がわからん」と思われることだろう。実際設定の提供方法は、意外なことにドキュメント化されてない（しろよ！）。はい、ということで、知ってる人にはつまらんと思うけど、このプラグインに設定をつけてみよう。

UserConfig

その前にUserConfigについておさらいしてみる。 UserConfigは設定を保存するためのkey-value型のデータストアみたいなもの。こんな風にHashのようにアクセスすることができる。未設定ならnilが返ってくるのもHashと一緒。

UserConfig[:gobou_sign]

書き込みも然り。

UserConfig[:gobou_sign] = "♡"

ただ、これで取り出したオブジェクトは全てfreezeされているので、ちょっと書き換えるだけでもコピーを取る必要がある。ArrayやHashをはじめ、JSONで扱えそうなデータはたいがい扱えるが、再帰的にfreezeされる。全プラグインで共通なので、キーのシンボルは「プラグインスラッグ_」からはじめるのが習慣になってる。あと、あまりでかいデータを入れると遅くなるはずなので気をつけよう。データのキャッシュとかちょっとしたデータベースが必要な場合はこれは使えないね。

setting DSL

つまりUserConfigに設定を書き込むのが最もスタンダードなやり方ということなので、定数にしていたのは全部これで置き換えれば問題無さそう。問題はGUIだけど、意外とつけるのは難しくない。少なくとも、Gtkなどを知る必要はない。具体的には以下のようなコード。

settings "ごぼう" do
  input "ごぼうの後の記号", :gobou_sign
  adjustment "ごぼうの量", :gobou_quantity, 1, 3
end

これだけで、スクショのような設定画面が出てくる。やったね。 input とか adjustment というのはウィジェットの種類。全てのウィジェットで共通しているのは、第一引数が設定の説明、第二引数が書き換えたい設定のキー、ということ。 adjustment は特殊で、特定の範囲の整数を入力させるために使うので、第三引数に最小値、第四引数に最大値を渡してる。
ごぼうプラグインも改良してみよう。
うん、これは素晴らしい。手軽にいろんな設定を増やせる。面倒そうで敬遠してる人も多かったようだけど、意外と簡単だと思ってもらえたんじゃないかな。mikutterの基本設定は、 /core/plugin/settings/basic_settings.rb に書いてあるから、参考になるかな。 あと、同じ階層の builder.rb に、input や adjustment のようなメソッドが定義してあるので、ここを見れば使いたいウィジェットがあるかどうか判断できる。さすがに、コード読めじゃあ記事の意味があまりないから、以下に列挙するけど。
（引数のLは説明の文字列、CはUserConfigのキーのこと）

メソッド名	引数	意味
multitext	L,C	複数行のテキスト
adjustment	L,C,min,max	minからmaxまでの数字
boolean	L,C	チェックボックス。チェックがついてる時がtrue
fileselect	L,C,dir	ファイル選択。設定にはファイルの絶対パスが文字列で入る。dirはダイアログが最初に開くディレクトリ。省略可
input	L,C	一行テキスト
inputpass	L,C	パスワード。一行テキストと同じだけど入力文字が隠れてるアレ
multi	L,C	複数テキスト。ユーザはテキストボックスを追加ボタンで増やすことができ、それらの値が配列で格納される
settings	L,&body	枠で囲む。先に上げたbasic_settings.rbの使用例を見てね
about	L,options	クレジット。mikutterのクレジットを表示するためのものなので、使わないかな
color	L,C	色選択ダイアログ。[RRRR,GGGG,BBBB]のような配列。各要素0xFFFFが最大値。
fontcolor	L,f,c	フォントと色。fのキーにフォントの情報が文字列で、cのキーには color ウィジェットと同じように
select	L,C,o,&body	oのHashの値から一つの要素を選択する。表示されるのはHashの値だが、格納されるのはキーの方。普通はコンボボックスだけど、bodyにウィジェットを入れたらラジオボタンになる
multiselect	L,C,o,&body	select ウィジェットの複数選択奴。選ばれた値がすべて配列で格納される。bodyにウィジェットがあればチェックボックスになる

とはいいつつ、意外とちゃんとまとめるとめっちゃボリュームありそう。aboutとかcolorみたいにほとんど使わなさそうなのもあるし。

とにかく

これでみんなも自分のプラグインに設定をつけてみたくなったんじゃないかな。自分用のちょっとしたプラグインも、こうやって設定できるようにしておくと、便利ですよ。

反省とか

説明がザックリですまんやでｗｗｗぴょぴょぴょぴょぴょｗｗｗｗ しかしね、最近こういう適当なエントリかかないから、適当なマニュアルもないという状態になってしまって、設定難民が出てしまうわけだよ。設定つけるためにソース読んだ皆も、諦めてた皆も、ごめんな！
なので、来年はこういうの書いていくようにしようと思う。ないよりあるほうがマシだしね。あと、半端なこと書いてるとこれはイカンやばいと思ってちゃんとしたのを書くモチベーションが上がるという話もある。ておくれ駆動開発みたいなやつ。

Display Requirements

TwitterがAPIを使うにあたって、ツイートの表示方法を制限してきたので、対応しないといけない。もうDisplay Requirementsはさんざん叩かれていて、どういうものかは皆わかっていると思う。この記事を書いた目的は、私がどのように解釈してどのような対応をするかという説明をすることなので、Display Requirementsの良し悪しについてはあまり言及しない。他のTwitterクライアントを作っているなら俺は悪くないということを強調する羽目になるが、mikutterのユーザは賢い方が多いと信じている。

その前に前提の確認

実はさんざん叩かれているDRだけど、mikutterはそんなには変わらない。2009年のTwitter Webを参考にして今のUIデザインがあるので、当然と言えば当然。実はDRはつい最近制定されたものではなく、もともとあったのが義務化されただけ（それに際して変更はされたが）。
とはいえDRとmikutterのUIは完璧に同じではない。具体的に言えば、私がTwitterのUIで不満に思っていたところを「改善」したのがおおよそmikutterのUIなわけだけど、そういうアレンジを全て取り払わなければいけない。
それによってユーザがどれくらい迷惑を被るかは、0.2.1のリリース後にわかるだろう。

must always

多くのTwitterクライアントがやってる、設定で変更できるというのは、個人的にはグレーじゃないかと思った。「しんどいとかあったら相談して！」みたいなことはちらっと書いてあるけど、やだって言って通用するならこんな規約そもそもないだろう。
あと、フォーラムのスレッドとか全部追っかけてるわけじゃないので、実は知らないだけで設定で無効にできるのは構わん、みたいな結論が実は出てて、相当恥ずかしいことを書いてるかもしれない。だったらそのことをDRに書き足しておけよっていう話だけど。
尚、設定で戻せるようにしてはならない、という明確な記述は見当たらなかった。いずれにせよ、後述する理由により（＝めんどい）、そのような設定は付けないと思う。

ぶっちゃけどうでもいいのでは

多くのクライアントが違反してるのでは、と言いたいわけではない。検問やって得するのはTwitterだけだ。DR　みんなで破れば　こわくない。
守らなくてもいいじゃんと言いたいわけではなく、バカ正直にやると文字通りバカを見るので、ある程度ユーザビリティを維持しながら、うまい落とし所を探っていく必要がある（多くのTwitterクライアントは、設定で戻せるというのを落とし所としたのだろう。悪いやり方だとは思わない）。

とはいっても決まりなので

インターネットは怖いところなので、決まりを守らないとユーザレベルでリンチされることがままある。たまにmikutterインストールしてしこたまハッシュタグ付きでdisったあと去っていくモヒカンがいるけど、こういう人たちの生態はまだ解明されていないので、急所は隠しておかないと不安で夜も眠れない。私の安眠のためにもやっぱり避けては通れない。
インターネットでは規約にとらわれないといけないのですね！

サドンデス

3/5まで実装しなきゃいいじゃん、というのはナシ。API 1.0、3/5までというバッファをもたせた順次移行というよりは、いつ使えなくなるかわからないサドンデスシステムが採用されていると思ったほうが事実に近い。API 1.0の不具合の修正がめちゃくちゃ遅いのだ。mikutter 0.2.0.1089で一応それっぽく動くようになったけど、明日TLを取得できなくなっていても不思議ではない。ユーザは以前のmikutterを使い続けられるけど、3/5までではなく、最大3/5までと考えたほうが、いざというときに寿命が縮まらなくて良いと思う。
v1.1への対応は急務であり、できるだけ同じタイミングでDR対応もしたいです。

ノーガード戦法

mikutterはどうするかというと、Twitterとの化かし合いの土俵には上がらず、あえてこれらに従い、ユーザビリティの低下を見過ごします。mikutterユーザはDRに準拠したUIを否が応でも強いられます。must always、設定で戻すことはできません。でも私は決められたことをしたに過ぎないのだし、Twitter社もユーザも、私を責めることはできません。残念でした。

見つからなきゃなにやってもバレない

多くの人気のTwitterクライアントとmikutterには、ソースが公開されているかどうかという大きな違いがあります。つまり皆さんが勝手に書き換えて、その結果DRに違反することになるのは何ら問題がありません。というか、それがどんな表示をしているかは確認できないしね。絶望するのはまだ早い。DRの実装の全てはそこに置いてきた。

プラグイン

mikutterのコアにはGUIは含まれません。つまりDisplay Requirementsの対応と言っても、標準プラグインの書き換えに過ぎないのです。プラグインは取り外し可能です。この意味がわかるな…？

display_requirementsプラグイン

いっけねー、コード同士の連携を粗にして見通しがよいコード書こうと思ってたら、display_requirementsプラグインになっちゃったー！これ外したらDisplay Requirementsに違反した使いやすいUIがもどってきちゃうわー。アップデートする度に削除するだけでもどってきちゃうわー。

あやしいプラグイン

あれれー？ https://github.com/toshia/display_requirements をインストールしたら、プラグイン削除してないのにDR非準拠な洗練されたUIを取り戻せたよー？
これじゃあ、各種ディストリが用意しているパッケージなどを用いてインストールしている等の理由で削除が難しい人も、手軽に無効化できちゃうわー

茶番乙

0.2.1でDRに対応する予定。開発中のコードはtrunkにあります。
API v1.1についても同時に対応中なので、まだ不具合が残ってます。DRに対応するとゆるふわ清楚系mikutterちゃんがどうなっちゃうのか早く知りたいなら止めないけど、trunkを試す時は設定などのバックアップは忘れずにね。とはいえまだDR対応も途中なので、工事現場が見れるというだけの話です。


雑感

私がmikutterにかけた時間は決して短くないし、Twitterに愛着もある。ならば当然この件について思うところはあるんだけど、開発を打ち切るという選択はしなかった。
もちろんここに思いの丈を書き散らしてもいいんだけど、2つのdisplay-requirementsプラグイン（標準プラグインと上記github上のもの）で私の思いを表現することにした。私の表現の場としては、これが一番ふさわしいのだ。

まとめ

• mikutter 0.2.1からはDRに対応します
• 設定で戻すことは不可能
• それプラグインでできるよ

これでよかったのかな。Twitterがこれの違反を根拠にシメあげてくることもないだろうから、多分死ぬまでそれはわからないね。

疲れた。これ25日までに間に合うのかな。

#mikutter 0.2.0.1089

• Twitterの一部APIによる不具合対策。認証ダイアログが何度も表示される、起動できなくなる等の問題を修正

Twitterの不具合対策です。既知の不具合にあげたのは、今回の不具合完全に回避できたわけではないので、以下のような症状が残っています。

• API RateLimit残数の表示が間違ったものになることがある（激しく増減する等）
• リストが更新されない、フォローフォロワーが正しく取得できないなどの問題が起こる可能性があります。

以前のバージョンでも同様の不具合は発生するので、アップデートをおすすめします。最近にわかに増えたふぁぼっていないツイートに★マークがつく問題もTwitterサイドです、遅くとも0.2.1で対応するでしょう。

前回もちらっと書きましたが、対策はAPI v1.1を使うことしかないので、0.2.1は予定を変更してAPI v1.1対応とDisplay Requirements対応になります。

#mikutter 0.2.0.1080

• アクティビティが自動スクロールアップしない問題
• アクセストークンが破棄された時の不具合の修正
• Twitterの不正な応答に暫定的に対応。約１時間毎に認証ダイアログボックスが表示される不具合の改善
• ツイートを選択していない状態でショートカットキーからプロフィールコマンドを実行するとクラッシュする問題

TwitterのAPI1.0で不具合と思われる挙動があり、現在調査中ですが時間が取れてなくてちゃんと原因を特定してません。これを期にさっさとAPI 1.1に乗り換えることも検討しています。このバージョンでのこの不具合に対する対応は暫定的です。週の半ばにもう一度問題を解決したバージョンを緊急リリースするかもしれません。

なお、上記の問題は初めてmikutterを起動した時にクラッシュしてしまうという問題も孕んでいるようです。こちらも現在調査中。

うーん、0.2.1の作業いろいろしたいけど、API1.1対応を先にやれという事か

#mikutter 0.2.0.1064 0.1.1.1063

0.1.1

• Twitterの仕様変更により初回起動時にトークンが取得できなくなっていた

0.2

• Twitterの仕様変更により初回起動時にトークンが取得できなくなっていた
• ディレクトリの整理
• 抽出タブを削除できない問題
• 設定画面の一部リストビュー（Twitterリスト機能等）において、レコードが一件もない時に新規追加ができない問題
• プラグインを大量に入れた場合、画面からはみ出た設定が表示されない問題
• Tumblr、はてなフォトライフの画像プレビューに対応

ここ数日（昨晩以降くらい？）でmikutterを導入した人はやってみよう。

Twitterがよくわからん変更を加えてきたので対策。一時的なものかもしれないけど、もともとの実装にも無駄な処理があったので。一応0.1.1にも適用したけど、新しくインストールするのでもない限り意味ないかもね。0.1.1は大きめの問題があればこうやってしばらくはアップデートします。大体みんな移行してるんだけどね。

0.2はそれに加えて、積み残していた優先度の低い不具合の消化と若干の機能追加があるのでアップデートをおすすめします。おすすめしないアップデートってなんだよって話だけど。

0.2.1の予定

ついでに0.2.1の予定を書いてなかった気がするので書いておきます。

• 高速化。アップデートの定番。何もしてなくてもとりあえずこう言っておけばいい。
• mikutterコマンドのUI関連。アイコンつけたり、階層構造にしたり
• Twitte API v1.1 に対応。メリットはほぼ無いけど古いAPIは運営のやる気がないようなのでさっさと引っ越すべき。Developer RejectionDisplay Requirementsどうするかね。
• マルチアカウントの準備。マルチサービスのためにね。
• 12/25にリリース。今回は三周年記念のバージョンアップなので、以上のことができてなくても、できてる部分だけでバージョンあげちゃいます。

高速化は実は0.2になったことで割と速くなったんだけど、それによって更に速くできる予知が生まれたのであえて書いた。Ruby2.0で高速になるという話もちらっと聞いたけど、追い風になるだろうか（1.8→1.9は凄すぎて、mikutterの1.8サポートを即切ったね）。

コマンドは、できることが増えたのでコマンドの種類も増えてしまい、探すのが大変なので。閉じるアイコンの出番がまた増えます。

v1.1の要件でもあるDR対応はやるけど、そうなると糞UIになるので、UIを過去のものに戻すプラグインも同時に公開しないといけません。mikutterがただのTwitterクライアントではないことは皆さんご存知の通り。

マルチアカウントっていうのは、もうとっくの昔からそうなってるんだけど、昔botだった頃のコードは流石にマルチアカウント対応になっていない。うまく行けば0.2.1からマルチアカウント対応にできるけど、なんか嫌な予感しかしないからどうするかね。遠い昔の夢だった、別のSNS等への対応のためにも必要なことだね。

来る12/25は皆さんご存知の通りmikutterの3周年です。オンラインでイベントもします（http://atnd.org/events/33737）が、この日のmikutter 0.2.1をリリースします。上に書いたことが一つも出来なかったとしてもバージョンを上げますバージョンは飾りなので。

また、アドベントカレンダー（http://atnd.org/events/33911）やコミケでの薄い本vol.3の頒布（http://home1.tigers-net.com/brsywe/mikutter/mikutter3.html）も行いますし（落ちたけど委託できたようです）、世間でもこの佳節を記念して、普段アニメ等を見ない私がハマったアニメ「けいおん！」の映画の地上波放映が行われる（http://www.tbs.co.jp/anime/k-on/k-on_tv/news/news.html#201211221700）など、過分な祝福を頂いております。

今年も、ただでさえ忙しい年末の貴重な時間を、mikutterでどんどん削りましょう！