2013年12月18日

Reblog,Tombloo,Tombfix

(この記事は tumblr reblogging enviroment Advent Calendar 2013 18日目の記事です。)

Reblog

いつもReblogしてる。
マウスでReblogしてる。
マウスボタン1が j
マウスボタン2が k
Tombfix の設定、ショートカット(マウス)が LEFT_DOWN + RIGHT_DOWN になってて、
マウスボタン3押すと、左クリック + 右クリックされる。

この設定がTumblr用マウスプロファイルで、Firefox のTumblr Profileと連動して勝手に切り替わる

マウスのプロファイルはアプリ/コマンド別にいくつか定義してて、
コード書く時は Ctrl, Shift, Alt, BS, Enterボタン、Ctrl+S の定期実行 切り替えボタン、 あと function とかテンプレートでぽちぽちやってる。
マウスカーソル、クリック、キー操作のマクロは Lua で組んでるけど、クリップも含めマクロの管理がひどいのでどうにかしたい。
最近だと JavaScript でクリップボードマクロ書けるようにした けど、実行環境どうにかならないかなって探ってる (Nodeで実行したかった…。SpiderMonkey, NILScript でいけたかも…)。
こんな環境は参考にならないだろうし、どうせハードに依存するなら、脳波Reblog してみたい。

Tombloo

Reblog 始めたと同じくらいに Tombloo を知って、 なにこれすごい、どんだけサービス対応してるの!?
そん
なに
ってTombloo のソースコード読んでたら、楽しくて。いつの間にか JavaScript のことばかり考えるようになった。 以前から ECMAScript が好きで、mozilla のソースコードとか見てたりしていたけど、 やっぱり Tombloo で衝撃受けて、普段利用するサービスがどんどん増えて、 パッチという存在を知って、なんとか書けそう、Reblog 環境, もっとこうしたい、ああしたいと、 よくわからんパッチばかり書くようになって 気付いた時には Tombloo が自分にとって一つの開発環境みたいなものになってた。
いつの間にか道を外れて迷子になることが多い。

今でも、ライブラリとかコード読んでる時、最終的に Tombloo (Tombfix) を見てることが多い。
1個1個の小さな処理、reduce とかの流れや deferred-chain, addBefore/addAround とか、 XPCOM を constructor にして自然に new して違和感なく扱ってたり, 今でも学ぶことが多いし発見がある。コードを追っていて楽しい。
あれだけ多くのサービスに対応できる機能が詰まっていて、 extractors でページ内容抽出、models でサービスにPOST。
大雑把に言えば、メンテナンスのほとんどは models と extractors だけみてれば済むようになってる。 service, ui, action、構造。アーキテクチャがきれい。 今までほとんど 1つの処理、1つの区切り、小さな粒ばかり見てきてしまっていた気がする。
本を読んでたつもりが、好きな単語やフレーズを見つけて満足し、ストーリーはもう頭の中になかった、 そんな Quote みたいな。

SoundCloudPlayer

最近、SoundCloudPlayer という Firefox アドオン を作っていて、 ある程度動くようになったものの、全体をあらためて見た時あまりにもひどい作りで 勝手に自分でガッカリした。
単に1個の Object にどんどん関数つっこんでるだけで、デザインパターンも何もない。
"とりあえず動くようにしよう" 的な作り方を, 改善したい
今は 別のブランチ で書き直し中。
自分でもたまにトラック作っているから (とってもチープなものだけど…)、 作り手からすると、SoundCloud 上で聴いてもらって再生数とかLikeが増えるのが嬉しい (もちろん DL されてローカル再生も嬉しい)。 どことなく Tumblr notes に似てる。 SoundCloudPlayer はあくまでサブのプレーヤで、メイン画面 (アクティブな SoundCloud のタブ) へのショートカット的な、そんなサポート的な位置にいられたらなって思う。

Tombfix

Tombfix で対応したいことは、Issues の解決、できそうなのあるかなって見てはいるけど、 多少構造を変えないと対応できなさそうだったり、単に pull req して close。といかなそうなのが増えてきて、 たいした考えは浮かんでない。けど、できる限り関わっていきたい。
あと、パッチの整理。できれば統合したい。
何も考えずに ちょっとこうしたいなって思ったらなんでもパッチにしてたものだから、 数が多すぎて中身も冗長で自分で書いたのがよくわかんなくて、もう手がつけらんない。
当時使ってたサービスも最近は使ってなかったりとかあって、動作チェックまでたどり着いてなかったりするのも多い。
需要がありそうなもの等で優先しながら、本体に取り入れるか、pixiv パッチのように最小限で分離するか、 tombfix/patch に入れるか、止まらない程度に進めたい


Models/Extractors

Tombfix において 各サービスを集約してる Models / Extractors について。

例えば Tumblr dsbd の UI が変わった時、ほんの少しの変化、div の className が変わっただけでも動かなくなる可能性があり、 そのたびに Extractors.Tumblr を修正して push してリリースしなければ対応できない現状。
ひどい例とすると icon, favicon の URL が変わっただけでも対応が必要で (ICON がボタンになったりしてるから)、 少なくとも応急パッチみたいので対応してきた。
この問題は以前から指摘されてる




Models と Extractors を外に出す。 syoichi さんも言っていたように、「日頃そのサービスを使ってる人が対応」できると理想的。 それには pull request して本体のリリースを待つより、簡単なステップで対応できるような何かが必要と思う。

Models と Extractors を本体のリリースに依存しないよう別の場所に置く

GitHub とかに公開されたパッチ (script) の URL は、そう変化するものじゃないとして、
  • インストールした script の URL を保持しておく
  • 起動時、script をローカルから読み込む前に、保持している URL を調べ、script が更新されてないか確認する
  • 更新されてたら script をアップデート。その際、必要に応じて確認ダイアログを表示
これによりアップデートが自動化され、利用者はサービスの UI の変化や、「また動かなくなった!」など気にしないで使用できる。 (動かなくなった時の対応が速ければ…)。
若干思っていることは、1つのレポジトリに集約しようとすると、Tombfix 自体の拡張性を縛ってしまっているんじゃないかなって。
「野良パッチ」と呼ばれるくらい、Tombloo/Tombfix のパッチはいろんなところにあって、 今更パッチのフォーマットを決めようとか、@updateURL どうのこうのとか、めんどくさいし、ルールが増えるほど書き手も減ると思う。 (自分で 一括インストールパッチ とかでフォーマット決めておいてアレだけど…)。
パッチフォルダ内の script は現状、ソート順に読み込まれる。 これを、例えばフォルダ内に .json とかで、サービス名と models / extractors の URL が書いてあるファイルがある場合、 読み込み順序や自動更新など扱いやすくなるかもしれない。
直列になってるパッチの読み込みを、Tree な構造にするとか、 script は addBefore/addAround により、CSS のようにカスケード状に扱えるようになっていて、まだ具体的にこうすればいいかもって浮かばないけど、いい方法はありそう。

とか書いてたら、Taberareloo Canary !? と、驚きと感謝を込めて

おしまい

なんだかこれといった内容のない記事になってしまいました…。
明日は poochin さんです。よろしくお願いします!

0 件のコメント:

コメントを投稿