2022年7月26日火曜日

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

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

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 の前にユーザー情報が取得可能でフィルターをセットしてます。

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

関係ないけど 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
    ざっくり計算で1日あたり 7 件のメッセージを処理するのが限界じゃないかなーと思います。
    動作優先でオペレーターの最適化してないのでもっと減らせる(※)とは思いますが、仮に不可能ではありますが 1 オペレーターでシナリオが書けたとしても、Integromat のフリープランの最大 1,000 件は越えられないです。
    (※スレッドやめるとかアイコンやめるとか、1週間分まとめて処理するとか)
  • あと再投稿したスレッドがまた期日を迎えたときにどうなるかとか、ボットどうするかとか、添付ファイルとか、いろいろ確認してないので、ちゃんとやりたい人は頑張ってください。

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

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

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

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

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

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

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

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

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

2022年7月13日水曜日

Integromat migrate to Make (formerly Integromat)

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

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

はじめに

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


サービスとしてどうかわったのかとか全く見てないので 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)とチームが最低1つは必要になるそうです。
これも 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 に移行したシナリオが元気に動き出しました。



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




2022年7月5日火曜日

Git 2.37.0 で FSMonitor daemon が追加されたことで status が早くなったそうです

むかーし以下の記事で git status が遅かったのが submodule 巡回のせいだったので ignoreSubmodule=dirty で改善したよって記事(※)を書いたのですが、Git 2.37.0 で追加された FSMonitor で速度が大幅改善するそうです。

ブログズミ: git gc --aggressive するそのまえに
Improve Git monorepo performance with a file system monitor | The GitHub Blog

core.fsmonitor と core. untrackedcache を true にすると FSMonitor が有効になり、git status が爆速になるらしい。
試してみたところたしかに速くなってました。9秒だったのが2秒くらい。
(初回はキャッシュ構築するので今まで変わらない速度、2回目以降速くなる)
ちなみに git status --ignore-submodule=dirty だと 0.1秒くらいです。。

まぁこのへんはどんな repository なのかやマシン環境で違うとは思いますが、FSMonitor でたしかに速くなってたので有効にしておきたいと思います。
では。


※自分のブログに書いたほうは、パフォーマンス情報を出力してなんで git コマンドが遅いのか調べて解決しようねって内容で、ignoreSubmodule=dirty の話はおまけではある。