本記事は株式会社Works Human Intelligenceのアドベントカレンダー、「Develop fun!」を体現する Works Human Intelligence #2の2日目になります。
弊社ではアドベントカレンダーを2枚実施しておりますので、1枚目もぜひご覧ください！
@takeC74 氏の昨日の記事から引き続きSlackネタでお送りいたします！
また、1枚目の2日目には、@yociya-nakada 氏の手になるツール開発のすゝめ が上がっています。
本記事で紹介するような、社内でのちょっとした「困った」を解決したり、業務をより楽しくするためのツール作りの魅力を綴った記事になりますので、こちらもぜひご賞味ください！
はじめに
弊社では今年の4月からQiita Organizationを運営しております。投稿記事のSlack通知のため、一番最初はSlackのRSS Appを利用していましたが、以下のような理由
から、RSS Appの利用をやめ、GASを利用してRSSを定期的に走査しSlackに投げるBotを運用していました。
(Botの作者は弊社でSREを務める @kabik 氏です。彼のアドベントカレンダーは1枚目の12/16に投稿されますので、ぜひ楽しみにしていてください！ )
しかし、現状のBotの仕組みだと、アドベントカレンダーとして投稿した記事ではうまくSlackに連携されないことが発覚したため、今回筆者が改修を行いました。
本記事では、元々のBotの仕組み、なぜその仕組みではアドベントカレンダーがうまく連携されないか、どのように改修したか、を紹介していきます。
元々のBotの仕組み
さて、元々のBotの仕組みは以下のようなものです。
- GASの時間主導型トリガーでWHIのQiita OrganizationのRSS を1時間ごとにチェック
- チェックした時刻がX時Y分だとすると、X-1時台に投稿されたものがSlackの特定のチャンネルにポストされる
- 例1: 13時51分にチェック→12時台に投稿されたものが対象
- 例2: 0時15分にチェック→前日の23時台に投稿されたものが対象
- Slackにポストする時は、投稿した人へのメンションと投稿した記事をポストする
- Qiita IDとSlack IDの紐づけはGSS
しかしアドベントカレンダー始動直前である11月27日、社内からの指摘で、この仕組みでは「一度限定共有で投稿後、公開設定に変更した記事」はSlackに連携されないことが発覚しました。
なぜ連携されないか
それはRSS内のpublished(投稿日時)が、「限定共有から公開に切り替えたタイミング」ではなく、「限定共有/公開問わず、最初に記事を投稿したタイミング」であるためです。
OrganizationのRSSのXMLは以下のような構造です。
<?xml version="1.0" encoding="UTF-8"?>
<feed xml:lang="ja-JP" xmlns="http://www.w3.org/2005/Atom">
<id>tag:qiita.com,2005:/organizations/works-hi/activities</id>
<link rel="alternate" type="text/html" href="https://qiita.com"/>
<link rel="self" type="application/atom+xml" href="https://qiita.com/organizations/works-hi/activities.atom"/>
<title>株式会社Works Human Intelligence の記事</title>
<description>Qiita で 株式会社Works Human Intelligence に所属するユーザの最近の記事</description>
<updated>2020-11-26T17:05:00+09:00</updated>
<link>https://qiita.com/organizations/works-hi</link>
<entry>
<id>tag:qiita.com,2005:PublicArticle/1343957</id>
<published>2020-11-26T17:05:00+09:00</published>
<updated>2020-11-26T17:05:00+09:00</updated>
<link rel="alternate" type="text/html" href="https://qiita.com/e99h2121/items/873281d73cc504e5a64d"/>
<url>https://qiita.com/e99h2121/items/873281d73cc504e5a64d</url>
<title>「失敗を許容する」なんて言われても失敗したくないです</title>
<content type="html">
<h2>
<span id="この記事は" class="fragment"></span><a href="#%E3%81%93%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%AF"><i class="fa fa-link"></i></a>この記事は</h2>
<p><a href="https://qiita.com/advent-calendar/2020/whi">Develop fun!を体現する Works Human Intelligence Advent Calendar 2020</a><br>
<a href="https://qiita.com/advent-calendar/2020/whi-2">Develop fun!を体現する Works Human Intelligence #2 Advent Calendar 2020</a></p>
<p>Works Human Intelligence アドベントカレンダーの投稿練習第二弾です。タイトルとは裏腹に、失敗を許容すると言われてもなお失敗したくない、それって「怒らないから正直に言いなさい」っていう先生じゃんと思ってしまう人（私）向けに書きました。</p>
中略
</content>
<published>2020-11-26T17:05:00Z</published>
<updated>2020-11-26T17:05:00Z</updated>
<author>
<name>e99h2121</name>
</author>
</entry>
<entry>
<id>tag:qiita.com,2005:PublicArticle/1343307</id>
<published>2020-11-25T16:25:11+09:00</published>
<updated>2020-11-25T16:36:19+09:00</updated>
<link rel="alternate" type="text/html" href="https://qiita.com/magnoliavine/items/4bd29e2384d45cf73ab4"/>
<url>https://qiita.com/magnoliavine/items/4bd29e2384d45cf73ab4</url>
<title>Electronの`shell.openExternal`が上手く動かない際の注意すべき点</title>
<content type="html"><p>先日Electronを使用したWindowsアプリケーションを作成している際、Electronの<a href="https://www.electronjs.org/docs/api/shell#shellopenexternalurl-options" rel="nofollow noopener" target="_blank"><code>shell.openExternal</code></a>が上手く動かないトラブルにハマりました。<br>
原因としては非常に初歩的なうっかりミスだったのですが、誰か同じ点で躓いている方のお役に立てばと思い記事にさせていただきました。</p>
<h2>
<span id="やりたかったこと" class="fragment"></span><a href="#%E3%82%84%E3%82%8A%E3%81%9F%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8"><i class="fa fa-link"></i></a>やりたかったこと</h2>
<p>「外部ブラウザで何か画面を開き、自分のウィンドウは閉じる」みたいな処理をしたい</p>
GASの1時間ごとのCronでは、entryの子要素のpublishedによって連携対象かどうかを判断しているわけですが、この日時が「最初に記事を投稿したタイミング」である、ということです。
そのためこの仕組みでは、限定共有から公開に切り替えた記事の場合、「Cron => 限定共有 => 公開 => Cron」というケース以外は取りこぼしてしまうことになります。
アドベントカレンダー参加者の皆さんはご存じの方も多いと思いますが、Qiitaのアドベントカレンダーでは、限定共有記事を登録しておくと当日午前7時に自動で公開設定に変更される機能があります。
弊社のアドベントカレンダーでもこの機能を活用することになっているので、このままだとほとんどの記事がBotで通知されないぞ！これはよろしくない！となったわけであります。
ではどうするか
publishedではなくupdatedで走査する？
上記XMLから分かる通り、publishedと同階層にupdatedがあります。
これを利用すれば、公開に設定変更したタイミングが取得できそうです。
しかし、公開後にさらに編集を加えた場合にもBotの通知対象になってしまいます。
通知した記事を保持しておいて差分を取得する！
そもそも記事の投稿日時を利用してやっていることは、前回までにSlackで通知したものより新しい記事のみを抽出する、ということです。
日時を利用した仕組みでは難しいのであれば、シンプルに通知した記事の一覧自体を保存しておいて、RSSの一覧と比較すればよいだけです。
記事を示す一意の要素といえばURLです。GASを使っているわけですし、先述の仕組みの通り、SlackIDとQiitaIDの紐づけにGSSのシート上のデータを引っ張ってきているので、通知済URLに関してもGSSに保持することにします。
しかし、ここでふと思いついてしまいました。 普通の記事とアドベントカレンダーの記事の通知、混ざらないほうが良くね、と。
せっかくのアドベントカレンダー記事の投稿通知なんだし、通知メッセージも今までのメッセージとは少し変えたい。そもそも宛先のチャンネルだって専用のものを作ったほうがよさそうだ。
ということで、アドベントカレンダー用のBotの要件は以下のようにします。
- 今までのQiita記事の連携先とは異なるチャンネルに通知する
- 連携する記事は以下の条件を満たす
- 過去連携されたことがない記事である
- アドベントカレンダーの記事である
- 弊社の記事である
改善後の仕組み
タグで絞り込みたい！
上記、連携する記事の条件のうち、1.は先述のURLをGSSに持っておいて比較する方法で対応できます。
しかし、OragnizationのRSSを見る限り、アドベントカレンダーの記事であることを示す要素はなさそうです。
アドベントカレンダーのRSSもありますが、XMLの構造がOrganizationのものとだいぶ異なり、対応にはGASの改修に少し手間がかかりそうです。
であれば自分でアドベントカレンダーであることを示す要素を入れてしまおう。
Qiita記事におけるカテゴライズといえばタグです。adventみたいなタグで絞りこんであげれば…… あれ？OrganizationのRSSの中にはタグも、ない？
……うーむ、困った。どうしよう。
アドカレ用のタグを作って、タグのRSSを使おう！
……ひらめきました。OrganizaionのRSSがだめであれば、弊社のアドカレでのみ使うタグを作って、そのタグのRSSを読みに行けばいいじゃないか、と。
後はQiitaにタグのRSSがあるかどうかですが、是非はググればすぐ判明します。
XMLの構造もOrganizationとほぼ同じなので、既存のGASのコードをある程度流用することができます。
この方法の欠点は、
- タグは誰でも付けられるため、完全にはOrganization外の記事を弾くことができないこと
- 5個までのタグの枠を1つ使ってしまうこと
です。
しかし、以下のような方法も考えましたが、タイトルに制約が出るほうが弊害が大きそうだ、ということや、GASの実装が複雑になる(1.のリスクを回避するためにそこまでするか？)ということから、今回はシンプルにタグのRSSだけを見る方式にします。
- 記事タイトルに「アドカレ」などの特定の文字列を入れてもらう
- タグのRSSとOrganizationのRSSの両方を見て、かぶってる記事だけを通知する
SlackのIncoming Webhook のメッセージにおける小技あれこれ
メッセージ中にメンションやリンクを入れる
先述の通り、このBotで通知するメッセージには、投稿者へのメンションと、投稿された記事へのハイパーリンクが含まれております。
メンションに関しては、普通に文字列で@SlackIDと書いてもメンションに変換されることはありません。
またリンクに関しては、普通のURLであればURLの文字列を送ればSlack側でリンクとして表示されますが、ハイパーリンクに関してはそうはいきません。
双方とも工夫が必要です。ググりましょう。ありました。
SlackのIncoming Webhooksでメンションを飛ばす方法
Slack の 🍣 にリンクを貼る
流石Qiitaですね！
通知メッセージに絵文字を入れたい
アドベントカレンダー専用の通知メッセージにする以上、クリスマスっぽい雰囲気を出したいわけで、すなわち絵文字は必須です。
ただご存じの通り、絵文字はいわゆるサロゲートペアであり、扱いがとても面倒です。
まぁでも面倒なだけでできないわけじゃないし、fromCodePointとかを使ってやるしかないかなぁ、と考えていたところ、もしかしてSlackの絵文字の記法が使えるんじゃないか、と思いつきました。
少しググってみると…ありました。思った通り、Slackの絵文字記法を含んだメッセージを送れば、Incoming Webhook越しでも絵文字に変換されるようです。
実際に試してみると…
function generateMessage(slackId, articleUrl, articleTitle) {
articleTitle = sanitizeSlackMessage(articleTitle);
return "<@" + slackId + "> さんのアドカレ記事が投稿されました！:santa: \n<" + articleUrl + "|" + articleTitle + ">";
}
ちゃんとメンション、ハイパーリンク、絵文字になっています！
最終的にこうなった
-
GASの時間主導型トリガーで、毎日午前8時~9時に以下のロジックを実行
- タグ
whi-adventのRSSに存在する全記事のURL、タイトル、投稿者を取得 - GSSの「連携済み」シートから、Slack通知済みURLの一覧を取得
- 1.のリストをループで回す。URLが2.のリストに含まれていない場合は以下を実行(含まれていた場合は何もしない)
- GSSの「連携済み」シートにURLを追加
- Slackに、投稿した人へのメンションと投稿した記事をポスト(Qiita IDとSlack IDの紐づけはGSSの「メンバー管理」シート)
- タグ
ちなみにGAS実行を午前7時~8時ではなく、午前8時~9時にしているのは、Qiitaの限定共有から公開への変更が厳密に7時きっかりに行われるのかが不明だったためです。
例えば記事の公開への変更が午前7時2分に行われた場合、GAS実行が7時1分に行われると取りこぼしてしまいます。それを嫌い安全側に倒したというわけです。 後7～8時とかまだ寝てる人も多いし、メンション付けるのはよくない
ソースは以下で公開しています！
https://github.com/cold-wisteria/SlackBot_QiitaRSS
最後に
GASは非常に手軽かつ強力なツールです。
実現したいfunctionalityは自由度の高いスクリプトで実装しつつ、定期実行やパラメータストアといった共通要素はGUIで設定できる組み込み設定として準備しています。
スクリプトでは、Google Workspaceのアプリケーション群の操作はもちろんのこと、通信やparseのための豊富な関数を用意し、一方で自身もWebhook URLを公開してWebAPIとしてふるまえる。
Qiitaをはじめネット上に情報はゴロゴロ転がっている。
まさしくAPI連携によるSaaSツール同士のコラボレーションによりワークフローを実現する現代の業務にビタッとハマるツールと言えるでしょう。
Google Workspaceを導入している会社であれば活用しない手はありません。
GASをはじめとした連携の仕組みにより業務をSlackにインテグレーションし、Slackを起点に業務を行う、というのが現段階においては手軽さと業務効率を両立する一つの解ではないでしょうか。