UserStreamが廃止になったので、それの代替手段を考えて対応したお話
なお、UserStreamと同等の機能のものを作ったという話ではない
環境
Raspbery pi 2 model B
PHP 7.0.3
ライブラリ
phirehose
GitHub - fennb/phirehose: PHP interface to Twitter Streaming API
twitterouath
TwitterOAuth PHP Library for the Twitter REST API
簡単な自分のbotの歴史
2010年末ぐらい
EasyBotterと@pagesを使って運用開始
当時なんか@pagesから負荷が重いって怒られた記憶がある
本当に申し訳ないことをした
(当時の記憶を辿るに、Notice、Warning、Errorの意味とかよくわかっておらず
めちゃくちゃな処理をphpファイルとしてサーバーに置いていた気がする
googleのcronとか使ってそのphpを叩いてbotの処理を行っていた
そら負荷かかるわ
なお、このbot制作は自分がプログラミングを始めるきっかけの1つでもあった)
2015年ぐらい
この5年間ぐらいずっと改良したり負荷軽減対策を行っていた
サーバーを自宅ラズパイへ移行+UserStreamを活用のためいったん停止している
たぶん
モデルはRaspberry Pi 2 Model Bだった気がする
2016年ぐらい
1年ぐらい経ってから復活、ただし管理者以外への反応は禁止した
ちょっと対応がというか、DBやらサーバーやら初めて触るに等しかったもので
動かすのに精いっぱいだったんだと思う
2018年夏
そして来るUserStreamの廃止
ここからの話を記事にする
Apply for developer access
なんかAPIの使用には登録が必要になったんだって
審査のために選択肢とか選ぶが、どうあがいてもhobby
300文字作文もhobbyとかツイートとかするよとか書いてたら普通に文字数クリアした
世間一般(観測できるtwitterアカウントの皆)様の書けないは芸に違いない
7月末に送って、3日で返信届いて受領してもらった
create app
API使うにはアプリを登録して色々と値を取得しないといけないんだけど
自分は元からあったので特に変更したり新規作成せずにそのまま
botの簡単なフロー
- TLからツイートを取得
- DBに登録
- 登録されたものを元にリプライやらなんやらツイートごとに挙動を決める
- 挙動の実行
ラズパイ移行まではDBを介さずツイート毎に直接挙動を決めていた
今回の対応までは、1のツイートの取得でUserStreamを使っていた
接続さえしておけば勝手にツイートが来るので楽だった
まぁ、前々から負荷対策の1つとしてフォロー絞りをしてたから
流れてくる数は少なかったけれども
UserStreamから変更
まぁゆーてツイート取得するだけですし・・・
適当にAPI漁って良さ気なのを持ってきた
twitterのapiリファレンスはここ
API reference index — Twitter Developers
APIのプログラムへの組み込み方は
ライブラリに説明が書いてあるのでそっちを参照して欲しい
自分は管理者と一般ユーザのツイートとわけたかったので
statuses/filter
POST statuses/filter — Twitter Developers
を管理者用に
statuses/home_timeline
GET statuses/home_timeline — Twitter Developers
を一般ユーザ用に使うこととした
filterの方は実はリアルタイムAPIなので、UserStreamと似たような使い方ができる
(ただし色々制限はあるし、ふぁぼとかの通知を受け取れない)
ここでは管理者のidと言語(ja)をパラメータに指定して使用した
なお、phirehoseでこのAPIを使うとき、なんかよく接続が切れたので
libのPhirehose.phpのreadTimeoutをnullにしたが、正しい対応かはわからない
一応phpのstream_selectとかその辺を参照した
PHP: stream_select - Manual
この使い方を怒られたら、おとなしくstatuses/user_timeline
GET statuses/user_timeline — Twitter Developers
を連打する他ないだろう
home_timelineはbotのアカウントで見えているTLが取得できる
定期的に叩いて、管理者のツイートを除外しつつDBへ登録する
UserStream代替とは言っても所詮こんなもんである
リプライなど
statuses/update
Overview — Twitter Developers
とかその辺使えばいい
結局
上記な感じで動いてるよ
所感
APIを1人で、1botのためだけに動かしてるから
自分から見ればリソースは豊富
ただ、サードパーティクライアント開発者からみたら地獄だろう、というか無理
有料APIも高いしねぇ
そういえばbot全盛期(2009-2012ぐらい?)だった時期から動いてるのってどれくらいいるのだろうか
昔はTLに沢山いたが、もはや自分のしか動いていないTLになった
Tips
TwitterのAPIで出てくる用語の解説
以下はツイートオブジェクトの中身
Tweet object — Twitter Developers
id_str:ツイートごとに発行されるユニークな文字列
text:ツイートの中身
source:投稿元
user->id_str:ユーザごとに発行されるユニークな文字列
user->screen_name:リプライを送る時に@の後についているid
user->name:名前、変えて遊ぶ人がよくいる
in_reply_to_status_id_str:リプライ先のツイートid文字列
in_reply_to_user_id_str:リプライ先のユーザid文字列