少し前に公開されたIFTTTのMakerチャンネルを使って、GitHubリポジトリーのWebhookをPubSubHubbubの公開POSTリクエストに翻訳するようにした。GETを使った公開リクエストがあまり行儀が良くなさそうなことが前から気になっていたので、Makerチャンネルを使えば良いかなと試したところうまくいった。
まずはMakerチャンネルのページへ行き、Connectボタンを押す。するとユーザーごとに専用のエンドポイントURLが作成されるので、How to Trigger Eventsというリンクをクリックして、それを確認しておく。
https://maker.ifttt.com/trigger/{event}/with/key/{secret_key}
エンドポイントURLはこのような形になっている。{event}は後ほど好きに指定することになる。{secret key}はユーザーごとに発行されるユニークな文字列に置き換えられて表示される。第三者にバレるとまずそうなので、気を付けた方が良い(再生成することは可能)。
各リポジトリーの設定からWebhooks & Servicesのページにアクセスし、Add Webhookボタンを押す。Payload URLにIFTTTのMakerチャンネルで作成された専用のエンドポイントURLを指定する。ここではGitHub PagesがビルドされたらPubSubHubbubで公開したいので、{event}はpage_buildにしておいた。GitHubリポジトリー側のイベントに対応させた名前にすると良いだろう。データを受け取ってゴニョゴニョするわけではないのでContent typeはどちらでも良いが、Secretは指定する必要がある(と思う)。
イベントはPage builtのみに絞っておくと良いだろう。
Trigger側では先ほどGitHubリポジトリー側で指定したエンドポイントURLで使ったイベント名を指定する(ここではpage_build)。Action側では、以下のように指定すれば良い。
| フィールド | 値 |
|---|---|
| URL | https://pubsubhubbub.appspot.com/ |
| Method | POST |
| Content Type | application/x-www-form-urlencoded |
| Body | hub.mode=publish&hub.url=http:%2F%2Fexample.com%2Ffeed |
Bodyフィールドで指定するRSSフィードのURL以外は同じで良いはずだ。Bodyフィールドでは自前でURLエンコードして指定しているが<<<と>>>で生URLを括るときっとURLエンコードされるだろう。
これでGitHubリポジトリーのgh-pagesブランチへpushしGitHub Pagesのビルドを走らせると、一連の動作が確認できる。
GitHubリポジトリー側では、該当Webhookの管理画面にRecent Deliveriesというログが残っているので、そこでIFTTT側から200が帰っていることを確認することでリクエストが成功していることを確認できる。IFTTTのレシピ側では、Personal Recipe triggeredというログで、レシピが走りPubSubHubbubハブへのリクエストが成功していることを確認できる。更にGoogleのPubSubHubbubハブに用意されているPublisher Diagnosticsを使ってRSSフィードのURLを調べると、最後に記事を受け取った時刻と内容がわかるので、それを照らし合わせることで公開がうまくいっているか確認できる。
気になる人はFeedlyなどPubSubHubbubによる購読に対応しているフィード・リーダーを使うと公開即反映されているかも確認することができる。
某アプリのおかげでRSSフィードが本来想定されていたような機械的に処理することのできるフォーマットのコンテンツとして復権する可能性がある。それと同時にポーリングではないPubSubHubbubによる公開と購読の重要性も上がるのではないかと考えられる。折に触れPubSubHubbubに言及することにより、少しでもPubSubHubbubによる公開を行ってくれるウェブログ(とウェブログ・ホスティング・サービス)が増えることに期待したい。