Slack の過去の投稿を再投稿して 90 日制限を回避する

えっと。はじめに断っておきますが、ネタ記事です。

Slack が 90 日前までしか見えなくなったので、だったら期日前のメッセージを再投稿したれと作ったシナリオ。
N 日前のメッセージを検索してスレッドに投稿し直します。 pic.twitter.com/a57yGVGgzq

— ずみっくす (@srz_zumix) July 23, 2022

「Slack 初の料金改定とフリープランの内容変更のお知らせ | Slack」

Slack の改定により、フリープランでは 90 日間の履歴しか閲覧できなくなりました。
この変更は結構困っている人は多そうで、Twitter などでもちょこちょこつぶやいている人を見かけました。
これを機に Slack から別ツールへ移行する人も多いようですが、私は今現在は主に通知用として使っているだけなので、特になにもせずに使い続けようと思ってます。
ただ、メモ置きとして使っていたような気もするので、実はそのうち困るかもしれません。。

そこでひらめきました！（のび太の画像）
90 日前までの履歴しか見えないのであれば、見えなくなる前に投稿し直せばいいのでは？

というわけでサクッと Make formary Integromat でシナリオ書いてみたのが冒頭のツイート。
ネタだけどちょこっと解説していきます。Integormat についてはこのブログでも何度か書いてるのでそのへんを参考にしてください。

シナリオ解説

概要

処理の流れは大体こんな感じ。トリガーは一日一回。

1. 検索日（現在時刻から指定日数前の YYYY-MM-DD）と検索チャンネルの変数をセット
2. Slack Search モジュールで検索
3. 一度バンドルを集計（ホントはここで filter かけて集計したかった）
4. 再投稿用のスレッドの親メッセージを投稿
5. 集計したバンドル配列で以下の処理を各要素繰り返し
1. 投稿ユーザー情報を取得（ユーザーのアイコンつけたかっただけ）
2. 検索したメッセージとユーザー情報を使って、内容を再投稿

5 の前に検索結果が空でないかのフィルターをセットしてます。

また 6.1 の前にユーザー情報が取得可能でフィルターをセットしてます。

検索結果のバンドルをそのまま流して再投稿することも可能ですが、スレッドにしたかったので一度集計してバンドルを１つにしてます。（Integromat はモジュールの output バンドルの数だけ以降のシナリオが実行される仕組みです。集計してバンドルを１つにすることで、スレッドの親メッセージの投稿処理を１回だけにしてます。）

関係ないけど Slack の Block Kit Builder を初めて使いました。便利でした。

Blue print

Integromat は Blue print でシナリオの export/import が可能なので Gist に置いておきました。これを見る、もしくは import してもらって見たほうが理解しやすいと思います。

補足

• Blue print の connection は筆者の Integromat のものなのでそのままでは使えません。もし import したら conection を更新してください。
• 今回のシナリオは Twitter モジュール使ってないので Integromat のフリープランの範囲で使えます。
• ただし、そこそこオペレーター数を使うシナリオ、かつ Slack のメッセージごとに消費するので、メッセージが多いと Integromat のフリープランを超えてしまします。
  Pricing & Subscription Packages | Make
  ざっくり計算で１日あたり 7 件のメッセージを処理するのが限界じゃないかなーと思います。
  動作優先でオペレーターの最適化してないのでもっと減らせる（※）とは思いますが、仮に不可能ではありますが 1 オペレーターでシナリオが書けたとしても、Integromat のフリープランの最大 1,000 件は越えられないです。
  （※スレッドやめるとかアイコンやめるとか、１週間分まとめて処理するとか）
  
• あと再投稿したスレッドがまた期日を迎えたときにどうなるかとか、ボットどうするかとか、添付ファイルとか、いろいろ確認してないので、ちゃんとやりたい人は頑張ってください。

（期日内であれば）件数無制限という点について

これは Slack からのお知らせのスクリーンショットです。

変更前だと直近 10,000 件しか閲覧できてなかったのですが、今回の改定で期日以内であればこの件数制限がなくなったようです。
（この記事書いてて気づいたレベルなので自分は困ってなかったみたいだ）

さて、もうお気づきかと思いますが、実は紹介した方法を使うとなんと！日数制限も超えてメッセージを無限に扱えるようになっちゃいます！

やってることは検索して再投稿なので Slack API 叩けば誰でもどこでも出来ちゃいます。GitHub Actions とかでやらせることもできちゃうと思います。（それなら Integromat とかの RPA よりも無料の範囲でできそう）

つまり（使いやすいかどうかは置いておいて）実質無制限になったわけですw

いやー、私はまぁそこまでして使おうと思いませんが。。

（でもこれ書いてて思ったけどファイルストレージは意外と？）

最後に

90日間を永遠に繰り返す Slack という空間に閉じ込められた俺達は・・

— ずみっくす (@srz_zumix) July 23, 2022

なんか書けそうな気がする。。

Integromat migrate to Make (formerly Integromat)

Integromat は新しいサービスの Make に生まれ変わりました。
Integromat のサポートは 2023 年に終了するとこのことなので、そろそろ移行したいと思います。

この記事はその作業ログです。

はじめに

なんで Make って名前にしたのかな？めちゃくちゃ検索しづらい名前で最低。
ロゴはそのうち変わるのかもしれないけど、Make formerly Integromat って書いちゃってるし！

make (formerly integromat)
integromat のままで良かったのでは？ pic.twitter.com/gzIYHDkmpY

— ずみっくす (@srz_zumix) July 3, 2022

サービスとしてどうかわったのかとか全く見てないので Integromat より Make のほうが優れてて素晴らしいのかもしれないけど、名前だけはダメだ。

。。。

まぁ名前はともあれ移行していきます。
ちなみにこのブログでは今後 Make formerly Integromat を正式名とし、略称として Make と呼びます。
（単に Make だとややこしすぎるので、タイトルとかには略称さける。。。）

Pricing

と、その前に料金プランを比較しておきましょう。

https://www.make.com/en/pricing

価格帯はほぼほぼ同じですが、Integromat は $9/月 でしたが、Make の場合年間払いで同じ $9/月 になります。単月だと $10.59/月。

BASIC と Core プランを比較してみました。

表記載のもの以外にも違いはありますが、Make のほうが全体的に条件が良くなっているので嬉しいですね。

移行前の注意点

移行後の Integromat

Make に移行後の Integromat Oraganization は readonly mode に設定され、シナリオの作成・編集・有効化などができないので注意してください。
筆者の場合、移行時に Integromat 側のシナリオを無効、Make に移行したシナリオを有効にする設定で Migrate したため、readonly mode になっているのかもしれません。

支払情報

Make に先に SignUp して支払情報の登録まで済ませてしまうと、移行後の処理に時間がかかるそうです。支払情報の登録は Integromat から移行後にしたほうが良さそうです。

手順書

公式に手順書があるのでそれに沿って移行していきましょう。
Integromat には Blueprint という形式で import/export できましたが、それでの migrate は非推奨らしいです。こちらの手順書に従って Migration tool を使うことが推奨されています。

1. Before you start

まずは移行作業前の注意点です。

Make のアカウントが必要になります。先に作ってもいいけど Upgrade hub でもできるらしいので Upgrade hub にまかせようと思います。

次に Make に組織（Organization）とチームが最低１つは必要になるそうです。
これも Upgrade hub でできるらしいのでおまかせ。

次、エラーがあるシナリオは移行できない。
しばらく動かしてないシナリオとかあるのでそのへんどうなるのだろう？
エラーはおそらく実行時のエラーではなく、下のようなシナリオのエラーのことだと思うので多分大丈夫だと思いますが、とりあえず何もせずにやってみる。

Make では Webhook や Mailhook は1つにつき1シナリオの制約になったそうです。
Integromat では1つの Webhook で複数のシナリオをトリガーできてましたが、そのようなシナリオは Upgrade hub では移行されないようです。
移行したい場合は各シナリオごとに Webhook を用意するようにしましょう。

最後にサービスが変わったことで IP も変わるので IP 制限かかっているサービスと連携している場合は注意が必要です。
例えば社内サービスで Integromat を許可IPに入れてた場合は更新が必要ですね。
自分は個人的に使ってるだけで、そういったサービスはないので気にしなくてよさそうです。

注意点は以上。確認して問題なさそうであれば「Let's start」で次に進みます。

2. Login to accounts

Source に Integromat Legacy を選択、Target は Make 。
それぞれ「Sign in to source/target」があるので Sign in します。

クリックするとポップアップが出るのでアカウントを選択します。

結局ここで Make のアカウントは作ることになります。

アカウント作ると組織（Organization）の作成画面でてきます。
移行する組織を選択してください。私の場合は有料アカウントの組織と無料アカウントの組織を使い分けていたので2つありますが、まずは有料アカウントの方を移行しました。

region を EU/US のどちらにするか選べますが、なんとなく GDPR のことが気になったので US にしました（US は US で CCPA とかあるけど）（JP 選べると気軽でいいんですけどね）

「Begin upgrade」ボタンを押すとポップアップウィンドウの中で Upgrade hub の続きが始まるってるので一回閉じてしまって良いです。もう一度「Sign in to target」で Make に Sign in しアカウントを選択してください。
（※ Make に Sign up したときに Integromat に Sign in 済みだったので Upgrade が始まったんだと思います）

もとの画面でアカウントを選択すると次に進めるようになります。

2.1 Teams & organizations

（Make に Sign up した際に Organization を作ってしまったので、作らなかった場合にどうなっていたのかはわかりませんが）Source / Target ともに Organization を選択する画面が出てきます。
Make のほうには Team もありますが、まだ特になにもしてないのでデフォルトのものを選択しておきます。

選択したら次へ進みます。

3. Data selection

3.2 Collision detection

1つの Webhook を2つのシナリオで使用していたため、修正もしくはスキップを選択する画面が出てきました。
こちら 3.2 となっていますが、筆者の場合 3.1 が出てきませんでした。
おそらくエラーのあるシナリオがあると 3.1 で同じようにどうするか対応を要求されたのだと思います。

今回は単純にバージョンアップ時に別シナリオにしていただけなので最新のシナリオだけ移行させました。

3.3 Scenarios

移行するシナリオを選択します。
特に理由がなければ Select all でいいと思います。

「Migrate manually」と「Fast migration」があります。
Upgrading to Make によれば複雑なシナリオがあると自動では無理らしく、そういうシナリオがあると手動 migrate が出てくるらしいです。（単純なシナリオだけだと出てこない？or manually が濃色で表示される？）

3.4 Data selection（Migrate manually を選択した場合）

3.3 で「Migrate manually」を選択するとまずは Webhook の移行方法の選択画面が開きます。

「Duplicate webhook」と「Duplicate webhook and forward traffic」がありますが、どちらも Make で新しい webhook が作成され、それが使用されます。後者の場合は Source （Integromat）側の Webhook そのままで Make のシナリオをトリガーできます。
なので、後者であれば Webhook を使ってる側は変更不要です。
ただし、Integromat のサービス終了とともに使えなくなるので、早めに新しい Webhook URL に移行しましょう。

「Next」にいくと connection 系の移行方法選択になります。

筆者の場合は特に移行方法を選択するものはありませんでした。

「Next」にいくと Key の移行方法選択になります。 

こちらも筆者の場合は特に選択肢はありませんでした。

「Next」にいくと Data store の移行方法選択になります。 

こちらは「Duplicate data store and migrate contents」と「Duplicate data store without contents」が選べます。
前者は Data store とその中身も複製します。後者は Data store だけで中身のデータは複製されません（空の Data store になります）。筆者は、ちょうど中身消したい Data store があったのでそれだけ後者を選択しました。

「Next」にいくと Data structure の移行方法選択になります。 

こちらも筆者の場合は特に選択肢はありませんでした。

「Next」にいくと Folder の移行方法選択になります。

こちらも筆者の場合は特に選択肢はありませんでした。

「Next」にいくと 4.1 Migration settings へ進みます。

3.4 Data selection（Fast migration を選択した場合）

3.3 で「Fast migration」を選択するとデバイスの移行方法の選択が出ます。
「Fast migration」だと設定はこれのみでした。
「Next」にいくと 4.2 Migration settings へ進みます。

4. Migration process

4.1 Migration settings

移行後のシナリオをどうするかを Source/Target で決めます。
デフォルトだと Source 側（Integromat）のシナリオを無効化、 Target 側（Make）のシナリオ（Active なもののみ）有効化します。

とりあえず設定だけ移行して、実行はおいおい切り替えていくのであれば変更しましょう。

4.2 Migration settings

これで Migration の設定は完了です。「Start migration」をクリックすると移行処理が始まります。

少し待てば移行が終わります。そんなに時間かかりませんでした。
以下のように移行結果が表示されます。

「Go to target」で Make を開くと以下のような画面が出ます。

これで移行完了です。お疲れ様でした。

支払情報の移行

Integromat を無料で使っていた方は以降の対応は不要です。
筆者は有料でも使っていたので、Integromat に支払った分を Make でも使えるようになっていました。
（月末にやればよかったなと思いつつ、ちゃんとサポートされててよかった）
（Integromat の使用量 + Make の使用量になってる？）
（Integromat で繰越した Operations は Make には移らない？）

ただし、支払い情報は移行されていないため、翌月以降の支払いは Integromat で引き続き行われます。Integromat が終了すると支払いが止まるため、継続利用する場合は Make に支払情報を登録しましょう。

最後に

Make に移行したシナリオが元気に動き出しました。

ちゃんと動いてる pic.twitter.com/U7az8VgcaG

— ずみっくす (@srz_zumix) July 5, 2022

今の所移行でのトラブルはありません。
今回は以上。ではでは。

DockerHub Automated Build の Webhook の代わりに GitHub Actions workflow_dispatch を使う

DockerHub の料金改訂により Automated Build が無料プランでは使えなくなりました。
Changes to Docker Hub Autobuilds - Docker Blog

DockerHub に image push するのに一番楽で良かったのですが、しょうがないですね。
今は GitHub Actions があるのでそこから build して push するのが簡単だと思うので、そちらに移行しました。

移行したリポジトリたち

• https://github.com/srz-zumix/docker-arm-none-eabi
  
• https://github.com/srz-zumix/docker-googletest
• https://github.com/srz-zumix/docker-lizard
• https://github.com/srz-zumix/docker-oneapi-cxx
• https://github.com/srz-zumix/docker-unityhub
• https://github.com/srz-zumix/docker-zapcc
• https://github.com/srz-zumix/review-retrovert

build と push は  アクションを使えばとても簡単です。
下記、もしくは上記リポジトリの workflows を参考にしてみてください。

さて、定期的なビルドは GitHub Actions の cron トリガーを使えばすぐに対応できます。
また hook の post_push も必要な環境変数を与えたうえで run すれば問題ないでしょう。

問題は Webhook トリガーで、私の場合は PyPI や gems のリリース RSS をトリガーに Webhook を叩いてビルドしていました。
例：「ブログズミ: PyPI のリリースを検知して Dockerhub の image を更新する」

これを GitHub Actions でやる場合は「workflow_dispatch」を使うことになると思います。
actions 側は特に難しいことはなくて、on のところに workflow_dispatch を追加するだけです。
一方 Webhook を送信してた側は dispatch イベントを API で送信することになります。
API ドキュメントは↓
Actions - GitHub Docs

以下は、Integromat で dispatch イベントを送る設定方法です。
repo 権限のついた GitHub の Personal Access Token が必要なので発行しておきましょう。

まず、ただの Make request モジュールから Make a Basic Auth request モジュールに変更しています。
Credentials が必要になるので Add ボタンから先程作成したトークンを入力します。
Username は「token」です。

URL には下記の {} で囲まれた部分を適宜変更して入力します。
/repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches
workflow_id は Action を開いたときの URL でわかるとは思いますが、面倒なのでファイル名指定がおすすめです。（ファイル名には拡張子も含める必要があるので注意してください）

Method は「POST」、
Headers には「Name: Accept, Value: application/vnd.github.v3+json」を追加します。

Body type を「Raw」にし、Content type は「JSON (application/json)」にします。
Request content には「{ "ref": "master" }」（今は main の場合もあるでしょう）を入力します。workflow_dispatch には任意の input パラメータを設定できますが、それらの設定はここにつけ足すことになります。

設定できたらモジュールを右クリックし、「Run this module only」を実行して、トリガーできるか確認しましょう。
Integromat での設定例を紹介しましたが、他の場合でも対応方法は同じような流れになると思います。

今回は以上。では。

Blogger の投稿を Integromat でツイートする Ver.2

Ver.1 の紹介記事を書いた気がしてたのですがなかったので、

まずは概要を紹介します。

Integromat とは

Intergromat は IFTTT みたいなやつ（iPaaS/RPA）です。
様々サービスのイベントをトリガーに他サービスと連携することができるものです。
操作の自動化をする RPA ツールとはちょっと違うので注意してください。
詳しいことは拙著を見てね^^

「詳解Integromat iPaaS完全入門」

Blogger で記事公開したらツイートするシナリオ

Integromat を使って「ブログズミ」で更新があったら Twitter にツイートするシナリオを活用しています。

（注意： 現在 Integromat の Twitter App は有料プランの登録が必要です）

Blogger は RSS フィードがあるのでそれをトリガーにツイートするシナリオになっています。

私が使っているシナリオは間にいくつかステップがありますが、単純にツイートするだけであれば、RSS の情報からツイート本文を書くだけでシナリオが作れると思います。

Ver.2 で変わったところ

Blogger のラベルをツイートのタグに変換

ツイートにタグをつけるようにしました。
ラベル→タグ変換は以下の２つのモジュールで行いました。

最初の Tools モジュールでラベルの配列に「 #」を追加しつつ、１つの文字列にしています。
「{{replace("#" + join(1.labels; space + "#"); ":"; space)}}」
「#Re:VIEW」 のような記号を含むものは記号より後ろがタグとして認識されないので、ここで空白スペースに置換もしています。（「:」のみ対応）

次に Text parser モジュールでタグとタグの間のスペース以外のスペースを削除します。

「s/\s([^#])/$1/g」

これだけではわかりにくいので、実際に処理されたときの様子を見てみましょう。

入力されたラベルは以下の図の通りです。
ここでは「Re:VIEW Starter」のラベルに着目しましょう。

Tools モジュールによって「#Re View Starter」と変換されます。

最後に Text parser で「#ReViewStarter」となります。

あとは、加工済みのテキストを Twitter モジュールで使うだけです。

新規公開か追記かの判定

追記があった場合は RSS フィードの公開日と更新日が入ってるので、それぞれの時間を比較して判定しています。
まず、Tools モジュールで公開日・更新日に setSecond をして 0:00 の時刻に揃えます。

「{{setSecond(1.dateUpdated; 0)}}」

そして、公開日と更新日が同じなら新規投稿、更新日が新しい場合は追記として分岐します。

Blueprint

最後にシナリオの Blueprint を公開します。

※Blueprint は有償機能です

※インポートしてもコネクションは筆者 organization の ID になっているので付け替え必須

以上です。では。

【技術書典10】「詳解 Integromat iPaaS 完全入門」の販売を開始しました

 こんにちは。
表題の通り、技術書典10 で「詳解 Integromat iPaaS 完全入門」の販売を開始しました。

Integromat は IFTTT や Zapier などと同じ iPaaS で様々なサービスと連携して自動化ロボットを作れるサービスです。

本書では Integromat の基本機能の解説と連携サービスから一部をリストアップしています。

Integromat は私自身お気に入りのサービスなのでユーザーが増えると嬉しいなと思っております。

RPA/iPaaS の入門の一冊として検討していただけたら幸いです。

本書は GitHub にてコンテンツ以外を公開しております。
本書へのフィードバックはこちらへお願い致します。

https://github.com/srz-zumix/book-integromat

chrome://tracing で並列処理の可視化をしてみたらすごく便利だった話

前回「ブログズミ: [C++] -ftime-trace オプションと Chrome でビルド時間の可視化」の続きです。

chrome://tracing の活用として iutest で使用している CI サービスの並列具合を調べて可視化してみました。

レポート集計の構成

各 CI サービスから並列具合を可視化するために使用したのは、 Intergromat と Google スプレッドシートの２つです。
構成は下図のようになっています。

まず各 CI サービスからはジョブごとに処理の開始・終了時に、Integromat で用意した Webhook URL に情報を送信します。

各 CI サービスで並列化する方法は ci-parallel リポジトリ の YAML を確認してください。

Webhook には「CIサービス名」「commit hash」「名前」「並列番号」「時刻」「開始・終了イベント」などの情報が付与されて来ます。

その情報から、Integromat で Google Drive から CI サービスごとのスプレッドシートを検索し、そこにコミットごとにシートを作成して情報を書き込みます。

そこから Chrome の tracing で表示するための json ファイルに GAS を使って変換しダウンロードします。

あとは、ダウンロードした json ファイルを tracing で読み込めば可視化が完成です。

tracing 用 json への出力

chrome://tracing の json フォーマットはこちらを参考にしました。

Trace Event Format - Google ドキュメント

また、GAS を使って json ファイルをダウンロードする部分は「【GAS】スプレッドシートからCSVをダウンロードする1クリックボタン/メニューを作成しよう - ポンコツエンジニアのごじゃっぺ開発日記。」を参考に作成しました。

function getData() {  
  var sheet = SpreadsheetApp.getActiveSheet();
  var maxRow = sheet.getLastRow();//行数 -
  var maxColumn = sheet.getLastColumn();//列数 |
  var keys = [];
  var ret = [];

  //1列目のkeyの名前取得
  for (var x = 1; x <= maxColumn; x++) {
    keys.push(sheet.getRange(1, x).getValue());
  }

  var base = 0;
  //データ
  for (var y = 2; y <= maxRow; y++) {
    var json = {};
    for (var x = 1; x <= maxColumn; x++) {
      var k = keys[x-1];
      var v = sheet.getRange(y, x).getValue();
      if( k == "ts" ) {
        var d = new Date(v);
        if( base == 0 ) {
          base = d.getTime();
        }
        v = (d.getTime() - base) * 1000;
      }
      
      json[k] = v.toString();
    }
    ret.push(json);
  }

  //整形してテキストに
  return JSON.stringify(ret, null, '\t');  
}

行のヘッダー名と要素は Integromat で tracing フォーマットに合わせて書き出しているので、ほぼほぼそのまま json にしています。

時間だけ最初のレコードを起点にした差分時間に変換しています。

結果

こんな感じになりました。

詳細は ci-parallel リポジトリを確認してください。

最後に

CI サービスの並列具合を可視化しようと思い、最初は BI ツールを転々と試していたのですが、 tracing がベストマッチでした。

もちろん何をどのように可視化したいかによって、 BI ツールを使うべき場合もありますが、可視化の選択肢として tracing は覚えておいて損はなさそうです。

そして、今回は単純な Duration イベントのみを使いましたが、他のイベントも使うともっといろいろな表現ができそうです。

参考：「パフォーマンス計測に困らない！tracing活用術100 - Qiita」

メモリの追跡はありですね。やってみようかな。

あと、今回はスプレッドシート使いましたが、BigQuery とか使ったほうがイケてるのかな？
この辺今まで触ってこなかったので覚えていきたいですね。

宣伝

「#技術書典　応援祭」始まりました。
「あつまれ CI サービス　タダではじめる継続的インテグレーション生活」の PDF 版を販売してます。
よろしくお願いします :Dhttps://t.co/igsHDPy9P2
BOOTH でも販売中https://t.co/Ks4GhSE9ib

— ずみっくす@あつまれCIサービス (@srz_zumix) March 7, 2020

「技術書典　応援祭」で販売した本には今回調べた並列処理の比較はありませんが、次回作に向けて鋭意活動中です。そちらには収録を予定しています。

「あつまれ CI サービス　タダではじめる継続的インテグレーション生活」は現在 BOOTH にて販売中です。

既刊および次回作をよろしくおねがいしますmm

今回は以上です。では。

「PVをツイートするサービス」から「Integromat」に引っ越ししました

長らく「PVをツイートするサービス」を利用させて頂いて来ましたが、Integromat の Basic プラン($9/mon) を使っていることもあり、なるべくそっちを使おうということで引っ越ししました。

昨日のブログズミのPVは 425 (UP 386, UU 345, Time 4:42 ) でした。https://t.co/Bw1i3gjLqj

— ずみっくす :X (@srz_zumix) August 5, 2019

特に難しいことはなくて、Google Analytics の APP を使って欲しいメトリクスを選択して取得したら、あとはいつものとおりにツイッターに流すだけです。

詳細

PV 以外にも色んな情報が取れますが、最終的に以下のようにツイートさせるようにしました。

それぞれ以下の Metrics を取得しています。

Pageviews	ga:pageviews
1 Day Active Users	ga:1dayUsers
Sessions	ga:sessions
Avg. Time on Page	ga:avgTimeOnPage

Avg. Time on Page は秒数が入ってるので、Tool の Set Variable オペレータで、「分:秒」テキストに変換しています。

{{toString(floor(round(2.`ga:avgTimeOnPage`) / 60))}}:{{toString(round(2.`ga:avgTimeOnPage`) % 60)}}

ハマったこと

Error 400 (badRequest): Selected dimensions and metrics cannot be queried together.

Metrics によっては、Dimensions と一緒に取得しなければいけないものがあるそうです。
なので、「metrics and dimensions」を選択して、「Dimensions」には適当に Date を指定するといいと思います。

どこにあるのかわかりづらい

ハマったというか、使いづらいなぁ・・・と思ったところです。

Metrics からはいろいろな情報が取得できるのですが、Integromat の UI から目的の要素を見つけるのがクソ面倒でした。

月間PVの対応

「PVをツイートするサービス」は、月初に先月の PV もツイートしていたのでそちらにも対応しました。

先月のブログズミのPVは 11,174 でした。https://t.co/Bw1i3gjLqj

— ずみっくす :X (@srz_zumix) August 1, 2019

できたシナリオはこちら。

Google Atalytics の設定

まずは一月分のメトリクスを取得する必要があります。
期間の設定を「先月の1日0時」から「今月の1日0時」までにします。
以下のように計算しました。

先月の1日0時：

{{addMonths(parseDate(formatDate(now; "YYYY/MM"); "YYYY/MM"); -1)}}

今月の1日0時：

{{parseDate(formatDate(now; "YYYY/MM"); "YYYY/MM")}}

そして、取得するデータの数がデフォルトだと 10 になっているので、
一ヶ月分取得できるように 31 にしておきます。

月間PV数を計算

Google Analytics オペレータからは日毎の結果が入ってくるので、各日の PV 数を Aggregate で配列にして Iterator で Sum して、月間PVを算出しています。
（これもう少し簡単にかけると嬉しいな）

Notification

最後にツイートです。
PV数を桁区切りするようにフォーマットしてるくらいで、あとは普通にテキストを指定しています。

先月のブログズミのPVは {{formatNumber(12.result; 0; "."; ",")}} でした。
https://srz-zumix.blogspot.com/

最後に

Basic プラン使ってることもあって、オペレータ数とかあまり気にせず作りましたが、工夫すれば少し減らせると思います。（変数セットをツイートオペレータにベタ書きとか）
daily/monthly で実行するものなので、起動回数的にも消費リソースは少なくて済むはずなので、無料プランでも運用できるかな？と思います。

最後に、ながらくお世話になった「PVをツイートするサービス」に感謝 m(_ _)m