Sheeprograming

RSS は廃れて久しい認識だが、Slack 等にも RSS の通知を出すアプリがあったりする（Slack に RSS フィードを追加する | Slack）。業務用途などでは必ずしももはや不要とは言い切れないだろう。

Discord についてはIFTTT を使って実現させるような紹介は見つかったものの、 RSS をチャネルに流し込むような bot は見つからなかった。ただ、これでやれてしまうのでわざわざそれを書く気にもならず、Discord に RSS を流し込む bot をこれを使って実現させたりした。冬休みだと言うのに何をしているのか……

サンプルソースコード

以下で取得そのものは上手くいった。このままえいっとさくらインターネットのレンタルサーバに CGI として置いても動く。なお、チャネルの ID は 111111111111111111、取得の為に使う Bot のトークンは BOTTOKENBOTTOKENBOTTOKENBOTTOKENBOTTOKENBOTTOKEN とする。

下のコードは恐らくチャンネル ID、Bot トークン、UserAgent のサービス URL を換えれば動く。

#!/usr/bin/perl

use LWP::UserAgent;

my $browser = LWP::UserAgent->new;
my $response = $browser->get(
  "https://discordapp.com/api/channels/111111111111111111/messages",
  "Authorization" => "Bot BOTTOKENBOTTOKENBOTTOKENBOTTOKENBOTTOKENBOTTOKEN",
  "User-Agent" => "DiscordBot (YOUR_SERVICE_URL, 6)"
);

print "Status: 200 OK\n";
print "Content-Type: text/json\n\n";

print $response->decoded_content;

exit;

注意点

いくつか見落としやすい点。まず、Authorization は Token の前に Bot という文字列が必要。詳しくは公式ドキュメント。

また、User-Agent の設定も必要。これも詳しくは公式ドキュメント。

中国の上海に用事があり飛ぶことになった。

中国はよく知られている通り QR コード決済が支払いの主流となっている。地下鉄やちょっとした売店でも QR コードで支払うことになる。しかし、海外からの渡航者は現地で使われる WeChat Pay や Alipay の機能が解放されず不便だ。これに対して Alipay の機能の一つ Alipay Tour Pass を使うと海外からの渡航者もクレジットカードから課金して簡単に現地での決済が可能となる。

Alipay を導入後、Alipay Tour Pass への課金および QR コードの表示が可能な状態にしておけば現地でも戸惑うことなくすぐに使える。私は QR コードを表示できるようにしていないまま現地入りしてしまい少々大変だった。

ただ、来月（2020年1月）から課金手数料が発生するようだ。これが現金と両替するのとレートにどの程度差が出るのかは少々不安である。

ソースコード

Jenkins の groovy pipeline で書いたもの。

                    approvalResult = input(
                        id: "myInput",
                        message: "承認しますか？",
                        parameters: [
                            string( name: 'comment', defaultValue: '承認します')  
                        ],
                        submitterParameter : "approver" 
                    )
                    wrap([$class: 'BuildUser']) {
                        if( approvalResult.approver.equals(BUILD_USER_ID) ) {
                            error "承認者と作業者が同じ人です！！";
                        } else {
                            echo approvalResult.comment;
                        }
                    }

ダブルチェック

一人で何でもできる状況でお仕事とか管理をしたりするとスムーズに事が進んで大変に楽なのだが「それやっちゃまずくね？」を止める人がいない。お仕事や管理の内容によっては不正やよろしくない判断をだれも止めることができない、ということになる。

それを防ぐために不正やよろしくない判断に基づく可能性のある作業に対しては作業者じゃない誰かが確認するプロセスを踏んだ方がよい、とされる。上述のソースコードはこの確認するプロセスを実現している。

解説

Jenkins の groovy pipeline の Input Step と BuildUser を使っている。

input を使うとビルドの最中にユーザの入力を受け付けることが可能となる。これを使ってビルドの途中で「承認しますか？」を確認する。承認時にはしばしば承認の根拠になる資料を添付したくなるのでそういう URL を添付しやすいようにコメントを書き込めるようにしてある。他にも様々な値を与えることが可能である。しかし、最も重要なのは submitterParameter だろう。これに指定した値を key とする value に承認者のユーザ ID が代入される。上述の例だと approvalResult.approver に承認者のユーザ ID が格納される。

しかし、この承認が作業者自身によるものだったらダブルチェックになっていない。別人が確認していることを確認するために作業者のユーザ ID が格納される BUILD_USER_ID と approvalResult.approver を比較し、双方が異なる値を持つことを確認している。

承認者を絞る

input の submitter パラメータを設定することでそもそも input に入力できる人を制限できる。これを用いれば BuildUser のチェックを省略したり、より高度な確認プロセスを作れるかもしれない。ただし、承認できる人の全リストのメンテナンスをしないといけなくなるので、若干面倒。そこのメンテナンス方法を考えていないと徐々に面倒になってくるはず。

https://shunshun94.github.io/shared/sample/discordMultiLogPicker.html に Discord の複数チャネルのログを一気にダウンロードするツールを出した。

最近知ったのだが Discord のチャネルは500弱くらいまでしか作れないらしい。古いチャネルを残したまま継ぎ足していくといずれ限界を迎える。なので、古いチャネルをログだけ DL して消す、というオペレーションが発生するなぁ、という話になり書いてみた。