Silverbirdをforkする

提供: STUDIO DDT ONLINE
移動: 案内検索

前書き

2013年頃のはなし。毎日会社にサラリーマンのコスプレをして出かけているものの、俺って全然仕事がなくて暇なので、何か暇つぶしをやろうという話(だった)。

オフィスなどで隠れてTwitter廃人やろうとすると、こそこそ度合いの高めなクライアントとして、Chrome拡張のSilverbirdがあった。フォローするまででもないかな?的人たちをリストに分離するということは誰でもやっていると思うが、Unified Timelineとして合一したTLを表示してくれるため、とっても便利。

ただ、不満もあった。

  • リストのユーザの公式RTがUnified Timelineに載らないので載せてほしい
  • 公式対応も始まっている、改行付きツイートに対応してほしい
  • Twitterの仕様変更に追従してくれないので不具合が多い(リストとか)
  • 俺が使わない機能が多い

よろしい。ならばforkだ。(SilverbirdのライセンスはMIT)

環境を作る

前提

  • 元々のソースはGithub上にMasterリポジトリがある。
  • ビルド用にRakeを使っている。モダンな感じじゃない。
  • そもそも俺、本業プログラマじゃないよ。

Git for Windows

2013年3月現在では、便利なものでWindows環境向けにもGitの実装がある。Git for Windowsをダウンロードしてきてインスコ。このとき、パスの設定のところでRun Git from the Windows Command Prompt、つまりWindowsのコマンドプロンプト内でもGitが叩けるオプションを選んでおく必要がある。これは、後述するRakefileスクリプト内でGitのコマンドを実行しているため。

そうするとGit BashというBashライクなシェルが提供されるので、そこからリポジトリを操作するみたい。ディレクトリ構造はルートの下にドライブレター、各ディレクトリという構造でアクセスできるみたい。コマンド系はLinuxっぽい。シェルのプロンプトにユーザ名とカレントディレクトリとカレントブランチが表示されている。

Githubからcloneしておく。

あと、git config --global user.nameとgit config --global user.emailも忘れないように。(いつも忘れる)

Rake

cloneされたローカルのリポジトリを見てみると、Rakefileが置いてある。RakeはRubyで書かれたMakeの実装(だったと思う)。Chrome拡張のパッキングにRakeを使っているみたい。

Ruby for Windows

まずはRubyをインストールしなきゃならない。

といっても、(2013年当時ですら)RubyInstallerをダウンロードしてきてインスコするだけだった。この時は2.0系じゃなくて1.9.3系をダウンロードしてきたのだけど、特に理由があったわけではない。インスコ時にパスを通してもらう。

Windowsのコマンドプロンプトからruby -vとgem -vが動くことを確認。

Rake

コマンドプロンプトでgem install --remote rakeする。

Silverbirdのローカルリポジトリに移動して、試しにrakeしてみたがcrxmakeがねーぞと怒られたので、gem install --remote crxmakeすると、zipとcrxmakeがインスコされた。

ビルド

ためしにrakeしてみるとprivate key not existと怒られるので、Rakefileを読んでみる。Chrome拡張としてパッキングする部分はcrxmakeが担っており、リポジトリ外にある署名用の秘密鍵ファイルを参照している。当然だけど、開発者しか秘密鍵ファイルなんて持ってないから、適当な秘密鍵ファイルを自前で用意しないといけないが、crxmakeの機能として、秘密鍵ファイルの生成まで勝手にやってくれるっぽい。crxmake --pack-extension=ローカルリポジトリのディレクトリ --key-output=秘密鍵の出力先でcrxファイルと署名に使った秘密鍵ファイルが生成されるので、それに合わせてRakefileのKEY_FILEの内容を修正しておく。環境によってはTEMP_PACKAGE_FILEも修正しておこう。俺はテンポラリファイル作れねーぞ的な怒られ方をした。

これでrakeを実行すると、crxファイルとzipファイルが生成されるようになる。

動作確認

とりあえず、Chromeの拡張ページ(chrome://extensions/)を開いて、デベロッパーモードのチェックボックスを有効にしてしまい、crxファイルをドロップすればインストール可能。ただし、Chrome 43以降ではパッケージされたオレオレChrome拡張は危ないのでインスコできなくなった。未パッケージ状態なら、開発途中の拡張としてインスコできる。

Chrome Web Store向け

Chrome Web Storeに公開してみるにあたって、いつまでたってもアップロードが失敗してワケワカだった(エラーメッセージ見てもどう対処すりゃいいのか書いてない)のだが、どうもChrome Web Storeではサーバ側で署名を勝手にするようで、key.pemがZipファイル内に含まれているとアップロードを拒否されることがわかった(エラーメッセージ見てエスパーする必要があった)ので、いったん普通にrakeしてからZipファイル内のkey.pemを削除。それをアップロードする。

……ここまで来て気づいたわけだが、Chrome Web Store公開が前提の場合は、CRXファイルの配布なんてやらないので、Rakeでビルドとか要らないわけよ。

fork

ここからが本題。最初はgithub使おうと思ってなかったのでローカルにcloneしてそこだけで作業するつもりだったのだけど、週末挟んで自宅でも遊ぼうと思ったので、github使うことにした。今までやってた変更は大した変更でもないし、結果はわかっているので後でやり直しても大したことはない。まずはgithub上でリポジトリのforkを実行した。

forkするにあたって、manifestファイルのnameとかversionは変えてしまう。とりあえず名前はSilverbird Mにした。

機能追加などはこのfork用のブランチから再度ブランチして、あとでmergeするつもりだったんだけど、ぶっちゃけ面倒くさいのでほとんどmasterで作業してrebase -iしまくりで運用してる。計画持って機能をいじってるわけじゃないので、開発内容ごとにブランチ切ると、何をどこのブランチで作業していたのか忘れるし、ほとんどコンフリクトしてマージできやしないから。

コンシューマキーとコンシューマシークレットを変更する

まず手を付けるのはコレ。

なぜかというと、試しにChromeにインストールしてみると、ごく普通にSilverbirdとしてTwitterへのアクセス許可を申請しちゃうため。コンシューマキーとコンシューマシークレットが公開されているソースコードにそのまま記載されているみたい。俺がこのまま変な挙動をするクライアントアプリを書いてしまった場合に、SilverbirdそのものがTwitterからBanされるのは困る。

いちおう.gitignoreファイルを確認してみるとsecret_keys.jsが入ってるのだけど、manifest version2対応の時にlibの下に移動したようなので、そのときからアップロードされてしまっていたのかも。 fork元のほうはどうしようもないんだけど、forkした俺のリポジトリ上からは完全に履歴からも削除することにした。まずgit rmでlib/secret_keys.jsとGoogle Analytics用のlib/analytics.jsを削除してgit pushする。リモートでもファイルが一覧に出なくなったら、.gitignoreを変更してバックアップしてあったsecret_keys.jsとanalytics.jsを付け加えてもgitが認識しないことを確かめてから、gitの全履歴から当該ファイルの記録を削除する。これはググって見つけたので、必要なひとは適宜やってください。

Twitter APIにアクセスできるようにする

さて、あらためてコンシューマキーやコンシューマシークレットを取得しなおす。具体的には、Twitterに対してクライアントアプリケーション作りますよ、という登録をする。ふだん使ってるTwitterアカウントを開発で使うのも色々とアレなので、専用のアカウントを取得しておくことにした。@Silverbird_Mです。

アプリケーションを登録する

Twitterの開発者向けウェブサイトに、作成した専用のアカウントでログインし、アプリケーション登録をする。これでConsumer keyとConsumer sercretが利用可能になっているはず。とってもかんたん。

最初はApplication TypeのAccessパーミッションはRead onlyになっているので、SettingsタブからAccess levelを変更する。いちおうフル機能のTwtterクライアントなので、Read, Write and Access direct messagesに変更しておく。Twitterのウェブサイト経由でログインする(というかOAuth用か)ので、Allow this application to be used to Sign in with Twitterのチェックも必要。

サーバサイドアプリやBotの場合は必要なのだと思うが、ここではCallback URLの入力は必要がない。manifest.jsonを見るとcontent_scriptsが指定されており、Oauthの結果画面からPINコードを自動取得するスクリプトが動作する。ここでは単純な文字列(silver birdという文字列)のマッチを確認していたので、この評価部分を合わせたら自動的にPINコードを認証してアクセストークンを取得するつくりのようだ。

コンシューマキーとコンシューマシークレットを変更する

変更対象ファイルは/lib/secret_keys.js。もうすでに.gitignoreの編集や履歴からの削除をやっているのでアレだが、該当部分はすぐにわかるので、文字列を変更してアプリケーション認証させてみると、Silver BirdからSilverbird Mの認証画面に変わった。

ちなみに、最初コンシューマキーとシークレットを編集しようとsecret_key.jsを開いたら、identicaとyfrogとtwitpicのAPIアクセスキーも記載してあってウォォォォォ!identicaはともかく、yfrogとtwitpicのAPIキーは取得して記載してみた。

Google Analytics関係

オリジナルのsilverbirdではmanifestファイルにGoogle Analytics使ってる感のある設定があるので、どこかにアプリケーションキーが埋まってるのかなーと思ったらlib/analytics.jsにキーが埋まってた。

汁Mでは、誰かの動作をトラックしてデバッグに利用したりする気はない(つまり俺以外の利用者からのフィードバックを受け付ける気がない)ので、スパっとGAは削除。

URL Shortener と Expander

短縮URL作成と展開にウェブサービスを活用しているようなのだが、APIキーとかそのまんま埋まってるし、現在ではサポートされていない形式のままだったりした。

汁Mでは、このへんの実装を大きく変えた。詳しくは後述。

日本語ロケールに対応してみる

アプリケーション内でSilver Birdとなっている部分をSilverbird Mと置換しようと思うと、_localesディレクトリ下部にある各言語ファイルも置換する必要がある。せっかくなので、jaロケールを追加して日本語化した。ベースになっている英語、つまるところenディレクトリをコピーしてjpにリネーム。中身は単純なJSONファイルになっていて、ちくちくとそれらしい単語やら訳文やらに置き換えるだけ。

オプション画面の最下部にLocales Reportというリンクがあるのでクリックしてみると、ローカライズの抜け部分の指摘がされていて、赤く変わっている部分がなくなればローカライズ完了となる。ただ、各ロケールのmessages.jsonの値を横断的に表示しているだけのよう。俺は日本語しかまともに解さないので、スペイン語とかよくわかんないロケールは削除した。今後も一切サポートする気はない。

また、「retweet by ○○」みたいなものは「○○さんのリツイート」のようにしないと日本語としては不自然なので、泥臭く翻訳を適用できるように組み替えている。

jQuery関係

Silver Birdではサードパーティライブラリという位置づけでjQueryとjQuery UIを主に使っている。ただし、コアは1.4.2、UIは1.8.1と、現行のjQueryよりも超絶古い。CSP準拠のためにjQueryは1.5.2にアップデートしてみたが、それでも古い。最新化せねばならない(強迫観念)。

jQueryコアをアップデート

さて、いろいろ試すと、1.5.2から1.6.4にアップデートすると、タイムラインのページングがうまくいかない。1.5系と1.6系で大きく変わったのは、HTMLの属性およびjQueryオブジェクトのプロパティへのアクセスとしてattr()が利用されていたようなのだが、どうもHTML属性にアクセスしているのか、jQueryオブジェクトのプロパティにアクセスしているのかを明確に使い分けようぜ、という風潮がでてきて、なにやらprop()という奴が増えたそうな。attrを使っている箇所をgrepして適宜propに入れ替えるとjQuery 1.6.4にアップデートできるようになった。さらに1.7.2に更新してみたが問題なし。

調子に乗って、1.9系へのマイグレーションガイドを読み、on/offへと、ajaxのイベントハンドラ周りを大きく変える。そこまでくれば2.0系への移行は問題なかった。現在では、常に最新のjQueryを同梱するようにしている。

jQuery UIをアップデート

次はUI側。単純に1.8系の最終版1.8.24にアップデートする分には問題なかったが、1.9〜1.10とアプデすると仕様変更があるようで、アップグレードガイドを見ながら修正する必要があった。

1.9系にすると、オートコンプリートとツールチップ系はプラグインに頼らなくてもjQuery UIだけで完結できるようになった。ほんとはActionMenuとかコンテキストメニューはどうにかしたいのだが、いろいろと根深いことがわかっていて、面倒くさいので放置している。キャプチャリングフェーズでイベントハンドラを登録していたりするせいで、jQueryなどのイベント管理外にあるためにメモリリークの温床っぽい。

Twitter API 1.1に対応してみる

当初の予定ではもっとあとにやろうと思っていたのだが、たまにTwitterのAPI 1.0のエンドポイントを停止するテストなんかをやるせいで、先に片付けることになった。

もともと、Twitter API 1.0ではどのAPIを使っても一時間あたりの回数以内なら問題がないという作りだった。これがAPI 1.1では各API毎に15分単位で呼び出し可能な回数が決まってしまっているので、本家Silver birdではポップアップを開いて閉じて開いて閉じて……というのを15分のなかで何回もやると、それだけで一部のAPI呼び出し回数が超過してしまっていた。

これを根本的に変えるためには、APIを呼び出すポイントをBackgroundページに集約しなければならない。BrowserActionでポップアップするページ内では、Backgroundページで保存した値にアクセスするだけにして、Backgroundページで定期的にその内容をリフレッシュしてやるだけだ。とはいえ、そこそこ仕組みを変える必要があったし、ちょっとタイミング依存なものを小汚く実装してしまっている。

なお、これに関連するのだが、オリジナルのSilverbirdではAPI使用回数のグラフが見られた。しかしAPI 1.1では全体の使用回数のグラフなど見ても意味がない(単位時間あたりに各APIエンドポイントにアクセスできる回数がそれぞれ異なる)ので、機能ごと削除することにした。

また、大雑把には文句を言われない程度にTwitter Display Requirementsの記載を守っているつもり。

機能追加関係

短縮URL展開とサムネイル対応を根本的にどうにかする

これは簡単。一つ一つ短縮URLサービスとかURL展開サービスとかオンライン写真ストレージサービスを見に行くと、だいたいURL展開やサムネイル閲覧用のAPIが整備してある。???「司令官!そいつを増やしていけばいいじゃない!」「よし増やすか」

まぁ、最初はそういう方針で俺得な感じのやつを増やしていったのだが、廃止になるサービスもあったり、そもそもAPIがないものもあったりしたので泣いてた。そこで考え方を変え、XMLHttpRequest Level2のresponse URLと、OpenGragh Protocolで公開されている画像URLを利用することにした。

XHRはもともとリダイレクトをフックすることができない(ChromeのWebRequest APIやHTML5世代のFetch APIなんかではリダイレクトをフックする仕組みがある)。つまり何度かリダイレクトされる程度なら、XHRでアクセスすると最終的なコンテンツのURLが得られるのだ。???「もうこれでいいじゃない司令官!」

これでURL展開サービスは完全に要らなくなった。ただし、ただのURL展開にGETは大げさなので、この部分にはHEADを使っている。

サムネイルはナウなヤングにバカウケのチョベリグなOGPをフル活用する。OpenGraphはHTMLのヘッダにMicroformat的に埋め込まれているメタデータ。外部から認証なしにアクセスできるようなサムネイルのURLなんかが載せてあったりするし、サムネとか関係ないサイトでもサイトのロゴとかサービスロゴとか載せてる場合が多い。ほほぅそれは好都合、とそいつを使おうとするなら、HTMLをGETしてスクレイピングをやる必要がある。「一度HEADしてURL展開してから、やっぱりスクレイピングのためにGETしてんのかよ!」……というのはおっしゃるとおりなんだが、モダンなウェブサイトならOGPに対応していないことはあんまりないし、これをやるだけでサムネイル取得し放題なわけよ。やるっきゃ騎士なわけよ。

なお、Twitter/VineとニコニコとPixivに対しては特別な対応(これは汁Mが俺得でなければ意味がないため)をしている。Pixivはログイン済みのセッションクッキーがあるだけではダメで、ChromeのWebRequest APIを使ってRefererを付けてやっている。ゴリ押しすごい。

高速化できないかどうか

当初のボトルネックは2点あった。

  • tweet_assemblerでrenderTweetを各タイムラインの取得済みTweet全てに適用してタイムラインを作り終えてから表示しているので遅い
  • 一番叩かれるrenderTweetとparseEntitiesでjQueryのメソッドコールとDOM操作が多いので遅い

考え方としては、

  • 全部終わってからレンダリングに回さずに、Tweet一つだけ表示してsetIntervalとかで非同期処理にする
  • DOM操作をしないで、全て文字列にしたのを最後の一回だけinnerHTMLに突っ込んで高速化する

の2点しかないと思っているが、前者はスクロール位置の保存と再スクロールの調整でうまいこと実装を思いつかずに頓挫しており、後者は確かにすべて文字列化するとparseEntitesあたり3msくらい速くなるのを確認したのだけど、ハッシュとメンションのリンクがぶっ壊れてしまうのを解決する実装を思いつけずにいた。これは後者の方法をどうにかすることができたため、全要素の生成は文字列を連結するだけにして、あとは閲覧時にイベント動作でクリックだのポップアップだのを処理させるように分離できた。

ちなみに、最近の汁Mではホームタイムラインでフェッチしてくるツイート数をレンダリング速度から逆算するように仕様変更した。要は、利用者が「200件フェッチしろよボケ」と思っても、クソみたいなスペックのPCで使っているひとは、フェッチしてくる数がだんだん減っていくようになっている。レンダリングが250ms程度であれば「ぱっ」と表示されるように感じると思う。これはなぜかというと、RTや特定の情報でタイムラインをフィルタさせることを考えると、画面上に表示されるエントリの数と設定上の件数を一致させるのはアホらしいくらい面倒だからだ。自動で件数が上下するなら、どれだけフィルタされてもユーザが件数を意識することはないので、そんなふうに落とし込んだ。

とはいえ、汁Mあんまり早くない。Core i7の端末だとさくさくだけど、Core2 Duoとかだとちょっとかなりアレ。

RAM消費を抑えられないか

俺がまったく使わない機能であるところの既読管理をスパっと削除したら稼働中の使用メモリ量がザクっと減るようになったので、味を占めた。

でもその後いろいろやってもあんまり減らない。そのうえしばらく使ってると、徐々に使用メモリ量が増えていく。これはリークしてるんだと思うんだが、ぶっちゃけどこで漏れてるのかわかんない。(なにせポップアップを開いて閉じて開いて閉じてだけでも徐々に増えていくからだ。

まぁ、このへんは諦めが肝心。Chrome拡張をリロードさせればRAM上は初期化されるので、ザクっとRAM使用量が減る。

キーボードショートカットを有効にしているひとはポップアップページ上でAlt+Shift+Rキーで拡張をリロードできるので、しょぼいRAM環境のひとは定期的にリロードしよう。そうでない人は汁Mのポップアップページがバックグラウンドページ上で開発者コンソールを開き、chrome.runtime.reload()すりゃいいよ。

キーボードショートカットを実装する

RSSリーダーとしてLivedoor Readerを愛用しているのだが、こいつの特徴のひとつにVimライクなショートカットキーの存在があるじゃん?ふだんLinux上のエディタとしてVi/Vim系を使うことはあまり多くないし、別に好きでもなんでもないのだが、j/kキーで記事移動ができるのはGUIとして便利だと思っていた。TwitterもRSSと同じで、ある時間軸上に複数のエントリがある構造ではあるので、j/kキーで上下のつぶやきに移動できれば良いし、タブ切り替えもキーでできるとより良いだろうと思ってた。

やっつけで実装。

ポップアップが表示されているときは、jで下の記事、kで上の記事、h/aで左タブ、l/sで右タブに移動する。tでタイムラインの最上部、rでカレントタイムラインのリロードをする。拡張の設定で、キーボードショートカットでSilverbird Mがポップアップするように設定すれば(別にmanifest.jsonで_execute_browser_actionにしても良いんだけど)、普段のTL監視はキーボードだけでやることも可能になった。

これ、エントリ位置を描画後に保存してスクロール量を決めているんだが、Compose表示中やアップデート通知中は座標がズレてしまって期待したようにスクロールできない。いちいち再計算させればいいんだけど、Compose表示を分離して新しくしたいと思っているので、この辺はアップデートなし。

Chrome28のRicher Notificationに対応してみる

Chrome28に導入された機能の一つに、Richer Notificationというものがある。これは、HTML5としてのNotificationではなく、よりリッチな通知機能を実現するもの(らしい)だ。ぶっちゃけ、現状はテンプレートとして見たときは、まぁリッチかなという程度で、window.webkitNotification.createHTMLNotificationで作成できた、完全にHTMLベースのデスクトップ通知よりもできることは限られている。

この機能自体は別に使うつもりもなく、ふーん、と思っていたのだが、Windows版Chrome28でデスクトップ通知ができないという状態になって困った。デバッガで追うと、そのcreateHTMLNotificationで例外が出ている。Richer Notificationが導入されていないMacやUbuntuのChrome28ではいつもどおりなので、Windows版に先行導入されたRicher Notificationが原因なのは明らかだ。window.webkitNotification.createNotificationでHTMLじゃないシンプルな通知を出してみると、これはちゃんと表示される。つまるところ、Windows版Chrome28以降で、createHTMLNotificationを呼ぶときだけ、例外が投げられる。こうなると、Silver birdの仕様ではデスクトップ通知の設定が、オンページ通知にフォールバックしてしまっていた。いちおう設定は反映できる(ように見える)んだが、一度でもデスクトップ通知をしようとすると、その時に例外をフックしてオンページ通知に設定上も切り替えてしまう。エゴサーチしてみると、デフォルト設定で使ってる人たちは、設定が勝手に戻る現象を見て混乱してる人もいた。

まぁ、仕方がないのでRicher Notificationに切り替えた。現在は通知を呼ぶ前にツイートの内容をパースする構造になっていないし、Richer Notification 自体もHTMLDOMElementを内包するような作りになっていないっぽいため、通知の中にリンク張ったりすることはできない。 Silverbird Mの現仕様では、通知がされたあと通知に触る、あるいは通知を放っておけばタイムアウト設定時間後に勝手に消えて通知センターにも残らないようにした。当初は通知上のユーザ名などもカスタマイズが効くようにしていたのだが、バカバカしいので削除した。通知コンテンツが気に入らないなら、通知をつかわなければいい。また、リプライとふぁぼくらいはボタンを作れそうだけど、あまり興味ない。

なお、オンページ通知はものすごいゴリ押しで実装されていてウンコだったし、オンページ通知使うことって俺の中ではなかったので、機能ごとごっそり抜いた。最新のChromeでは別の権限が必要になっているため、silver birdのオンページ通知もそのうち動かなくなるんじゃないかな。

なお、Chromeでは46から通知センター自体が廃止になってしまった。

ES6機能を導入してみる

ChromeでもFirefoxでも、ECMAscript6で導入予定の機能がいろいろ実装されている。たいていの場合で、新しい機能のほうが既存のJavascriptのものよりも便利だったりパフォーマンスがよくなるようになっているので、いくつか汁Mにも実装を試している。主に、Set、Map、Template literals、Classとか試しに使ってるけど、ほんと試しに使ってみたままろくにアップデートしてないところあるよ。

そんなことよりStringに追加されたイテレータ機能のほうが重要。最近Twitterに対してEmojiを入力できるようになっていることもあってEmojiの利用者が多いのだが、Emojiの多くがUnicodeでサロゲートペアというコードポイントを割り当てられていて、旧来のJavascriptのString系メソッドでは適切に扱えていなかった。具体的には、Emojiの含まれるツイート内にハッシュタグやリンクが含まれている場合に、適切なリンク文字列を生成できていなかった。これは文字数のカウントにString.substringを利用していたためで、サロゲートペアを含む場合にカウントが1文字分ずれてしまっていたから。これをちゃんと直そうとすると、(俺はまったくわかっていない)Unicodeのコードポイント構成を正規表現で検索して〜、とかいろいろやらないとダメ。でも比較的最近Javascriptに導入されたString向けのイテレータがサロゲートペアを認識してくれるので、これを使うようにゼロから書き直した。 動くことは動いているっぽいのだが、すべての文字を配列化してループ回して処理しているせいか、旧バージョンよりちょっとパフォーマンス落ちた感じある。

Web Fontsを使ってみる

ぶっちゃけ俺はWindows環境でMS Pゴシックが表示されるのが嫌で、汁Mでもいろいろやっていたのだが、Google先生がGoogle FontsにNoto Sans Japanese(のサブセット)を提供してくれたのですぐさま導入した。ついでにアルファベット等用にRobotoをデフォルトにした。このため、WindowsでもMacでもLinuxでも、基本的にほぼ同じ文字が表示されているはず。でもこのフォントは容量を抑えるためにサブセットになっていて半角カナなんかは含まれていない。Windows環境だとsans-serifがMS Pゴシックだったりするため、半角カナだけガタガタのフォントが見えちゃっている。

Twitterの新機能に対応してみる

汁Mでは複数の画像ファイルを添付できるように対応している。また、引用ツイート(コメント付きRT)に対応している。このへんは仕様がちょいちょい変わるので、追いかけるの面倒くさい。

なお、動画とアニメーションGIFのアップロードもいったん実装してみたことがあったのだけど、アップロードは成功してもメディアIDを投稿できないという謎状態をクリアできなかったのでスルーしてる。

ソース

githubに置いてます。

いちおうChrome Web Storeでも公開してます。DMとかはまったく俺が使っていないので、ぜんぜんテストしてないけど、誰かが困っても俺は知らないよ。

ダメなところ

  • 低機能(リスト操作できないとか)
  • デザインがアレ(気にすんな)