mikutterの最新の情報は、mikutter blogに引っ越しました。

2012年12月25日火曜日

設定をつけよう

こんにちはー!

ごあいさつ

どうしようもない用事が入ってしまって年末までめっちゃ忙しくなったよ!だからmikutter 0.2.1のリリースは延期します! 最優先にしても良かったのだが、ちょっと丁寧にやって少しでも安定した感じにしたほうがいいだろうと思ってね(思ってもない)。他の環境で動かなくても知ったこっちゃないがな!ぴょぴょぴょぴょぴょwwwww
と、いつものご挨拶はさておきこの記事は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のキーのこと)
メソッド名引数意味
multitextL,C複数行のテキスト
adjustmentL,C,min,maxminからmaxまでの数字
booleanL,Cチェックボックス。チェックがついてる時がtrue
fileselectL,C,dirファイル選択。設定にはファイルの絶対パスが文字列で入る。dirはダイアログが最初に開くディレクトリ。省略可
inputL,C一行テキスト
inputpassL,Cパスワード。一行テキストと同じだけど入力文字が隠れてるアレ
multiL,C複数テキスト。ユーザはテキストボックスを追加ボタンで増やすことができ、それらの値が配列で格納される
settingsL,&body枠で囲む。先に上げたbasic_settings.rbの使用例を見てね
aboutL,optionsクレジット。mikutterのクレジットを表示するためのものなので、使わないかな
colorL,C色選択ダイアログ。[RRRR,GGGG,BBBB]のような配列。各要素0xFFFFが最大値。
fontcolorL,f,cフォントと色。fのキーにフォントの情報が文字列で、cのキーには color ウィジェットと同じように
selectL,C,o,&bodyoのHashの値から一つの要素を選択する。表示されるのはHashの値だが、格納されるのはキーの方。普通はコンボボックスだけど、bodyにウィジェットを入れたらラジオボタンになる
multiselectL,C,o,&bodyselect ウィジェットの複数選択奴。選ばれた値がすべて配列で格納される。bodyにウィジェットがあればチェックボックスになる
とはいいつつ、意外とちゃんとまとめるとめっちゃボリュームありそう。aboutとかcolorみたいにほとんど使わなさそうなのもあるし。

とにかく

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

反省とか

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

2012年12月17日月曜日

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日までに間に合うのかな。

2012年12月15日土曜日

#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対応になります。

2012年12月10日月曜日

#mikutter 0.2.0.1080


  • アクティビティが自動スクロールアップしない問題
  • アクセストークンが破棄された時の不具合の修正
  • Twitterの不正な応答に暫定的に対応。約1時間毎に認証ダイアログボックスが表示される不具合の改善
  • ツイートを選択していない状態でショートカットキーからプロフィールコマンドを実行するとクラッシュする問題
TwitterのAPI1.0で不具合と思われる挙動があり、現在調査中ですが時間が取れてなくてちゃんと原因を特定してません。これを期にさっさとAPI 1.1に乗り換えることも検討しています。このバージョンでのこの不具合に対する対応は暫定的です。週の半ばにもう一度問題を解決したバージョンを緊急リリースするかもしれません。
なお、上記の問題は初めてmikutterを起動した時にクラッシュしてしまうという問題も孕んでいるようです。こちらも現在調査中。

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

2012年11月23日金曜日

#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でどんどん削りましょう!

2012年11月18日日曜日

mikutterプラグイン管理ツールの構想

本筋とは全く関係ない話。プラグインのパッケージ管理とかやってくれるのが欲しいと思って、ちょっとだけ作りかけてみました。

現状のプラグインシステムの問題点

mikutterはサードパーティプラグインを ~/.mikutter/plugin/ の中に入れたら動くようになっています。いちいちビルドとかしなくていいので楽ですし、単純なので理解しやすい(置く→動く!)のですが、単純過ぎる故に色々と問題がありました。

  1. プラグインを探すこれといった方法がない
    現状として、プラグイン纏まった場所がないので、プラグインを探す時はgoogle先生にきくしかなく、検索すべきキーワードがわからない、特に欲しいプラグインがないという時にダラダラ見れるリストは存在しないようです。
  2. 何が入ってるかパッとわからない
    プラグインディレクトリ見れば分かりますが、ねえ。
  3. mikutterのバージョンとプラグインが想定するバージョンを気にしなければならない
    多くはREADMEとかに書いてあると思うけど、ねえ。
  4. 最新版の確認を、全てのプラグイン毎に行う必要がある
    リポジトリを直接プラグインディレクトリにチェックアウトすると楽にできるけど、それにしたってステップ数が減るだけ
で、誰もがパッケージ管理みたいなことしてくれないのかよ、って思っていたのではないでしょうか。今まで挑戦した人もイタみたいですが、皆途中で一身上の都合又は音楽性の違いにより、完成には至らなかったようです。

私も以前一度やろうとしていましたが、既存のものを使って辺にこったものを作ろうとしてしまって頓挫しました。というのも、プラグインから提供してもらえる情報というのが意外と少ないんですよね。しかし、ちょっと0.2で状況が変わって来ました。

定義ファイルの導入

mikutter 0.2からプラグインの依存関係を記述する目的で、プラグインにYAMLで記述された定義ファイルを同梱しておく機能が導入されました。
これは、依存するプラグインを記述しておき、それが先にロードされるようにすることで、コアを書き換えるプラグインの機能に依存したプラグインを書けるようにという目論見です。
ついでに、プラグインのバージョンとかも書けるようにしました。詳しくは「プラグイン移行ガイド」の7章を見てください。

いろいろ書く割にはほとんどのキーが使われていないというのが現状ですが、この情報を利用したらパッケージ管理みたいなことができるのではないかと思ってやってみました。

理想
  1. リポジトリみたいなのに登録されてるプラグインを一覧したい。
  2. インストールはできるだけ簡単に。
  3. yumとかaptみたいな感じで、バージョンアップとか依存関係とか見てうまい感じにやってほしい
  4. app storeやGoogle Playみたいに評価とか付けれるようにしたい(審査ができないため、悪意のあるコードが入ったプラグインを実行してしまうと…。)
作ってみた


0.2で使えます。設定画面に「みっくストア」というのが増えてるので、そこからプラグインをダブルクリック(todo: なぜクリックで開かない)するとプラグインの説明が出てきて…っていうのはスクショ見たら大体イメージつくと思います。


はい。変なプラグインをインストールしてしまったのでインストール済みになってしまってます。プロトタイプなので使用はおすすめしませんが、現時点で以下のような機能があります。
  • プラグインをインストールする。
    通常のプラグインディレクトリにスラッグと同じ名前のディレクトリを作ってそこに設置。git cloneしてるだけなのでgitコマンド必須です。みっくストアを用いてインストールすると、すぐにmikutterにロードされるので再起動は必要ありません。
  • すでにインストールされてるプラグインを確認
    「導入」カラムに表示されているバージョンは、インストールされているプラグインのバージョンです。バージョンがないけどインストールされてるものは○、インストールされてないものは空白。「みっくストア」を用いずにインストールしたものも検知できます。
  • 開発者の気がふれていないか確認
    プラグイン開発者の頭に不具合がないか確認できます。mikutterプラグインはなんでもできてしまうので、信頼できないものは入れるべきではありません。こう簡単だとホイホイ入れちゃいそうだけど。
これ以外は何も実装してません。バージョンアップ、アンインストール等はそのうちつくんじゃないかな。
また投げ出してしまいそうだけど、最低限のものはできてるので、いい感じにできないかなー

mikutterプラグインの管理が楽になるといいですね

2012年11月7日水曜日

#mikutter 0.2.0.1054


  • ツイートにフォーカスしてなくても会話タブを開くコマンドが使える問題
  • 意味のないトレースをエラー報告として送っていたのをやめた
あんまり何も変わっていない。二週間経ったのでバージョン上げてみた。いつかみたいに大して何もなくても毎週バージョン上げるようにしたら危機感持てて、ちょっとは開発速度上がるかなとか思って。
パッチとかももらってるし割と残してるバグもあるんだけど、最近元気がなくてなかなかコードをかけてない。mikutterの薄い本製作委員会がコミケ落選したのは関係ないです。

0.2ではプラグイン開発者が嬉しい機能とかあるのでそういうのもまとめたいと思っているんだけどコードすらかけてないし全然時間が足りない!これから寒くなったら自分の部屋でコード書くのがかなりしんどくなってくるのに。