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対応を先にやれという事か