kakakakakku blog

Weekly Tech Blog: Keep on Learning!

Autify を使って「スマホレイアウト」をレコーディングする

先週に続き「E2E テスト自動化プラットフォーム Autify」を試す.今回は「スマホレイアウト」をレコーディングする.Autify の基本的な操作などは以下の記事を読んでもらえればと!

kakakakakku.hatenablog.com

「スマホレイアウト」をレコーディングする

今回も kakakakakku blog を題材とし,スマホを使って画面遷移をするシナリオをレコーディングする.以下のステップを試す.

  1. 「kakakakakku blog」にアクセスする
  2. キーワード「github」で記事を検索する
    • ✅ URL を検証する : https://kakakakakku.hatenablog.com/search?q=github
  3. 「プロフィール」をクリックする
    • ✅ アカウント名を検証する : id:kakku22
  4. 「ブログタイトル」をクリックする

1.「シナリオ」を作る

まず「シナリオ」を作る.現在 Autify に「スマホに特化したレコーディング機能」はなく,前回と同じようにシナリオを作る.シナリオ名は「スマホ : kakakakakku blog 画面遷移 + 検証」とする.ウィンドウサイズは 1280x1024 とする(今回はウィンドウサイズは関係なし).

f:id:kakku22:20200501220707p:plain

レコーディングを開始し,Chrome の「シークレットウィンドウ」を起動したら,まず Chrome DevTools の「Device Mode 機能」を使ってスマホレイアウトに変更する.今回は「iPhone X」とした.あとはステップを進めていく.

f:id:kakku22:20200501220726p:plain

2.「シナリオ」を確認する

レコーディング結果を確認すると,正しくスマホレイアウトになっている.

f:id:kakku22:20200501220741p:plain

3.「テストプラン」を作成する

今回は「Chrome で今すぐ実行」を使わずに「テストプラン」を作成する.今回はテストプラン名を「iPhone 実行」とし,以下の設定をした.

  • 実行環境
    • iPhone 6/7/8 (Emulator)
    • iPhone X (Emulator)
  • シナリオ
    • スマホ : kakakakakku blog 画面遷移 + 検証

f:id:kakku22:20200501220759p:plain

実行環境は,例えば iPhone と iPad なら「計5種類」からエミュレーターを選択できる.エミュレーターではなく実機を希望する場合は Autify の Pro プランなどを検討する.契約次第と言える.

f:id:kakku22:20200501220819p:plain

4.「シナリオ」を実行する

「テストプラン」から「シナリオ」を実行する.「テスト結果」を確認すると,正しく実行されている.

f:id:kakku22:20200501220837p:plain

Autify FAQs

まとめ

E2E テストでは,デバイスのバリエーションを増やすことにより,サービスの品質を高めることができる.Autify では「テストプラン」で実行環境を複数選択することで実現できる.現状だと「スマホに特化したレコーディング機能」がなく,Chrome DevTools の「Device Mode 機能」を使う必要はあるけど,今後に期待かなと!

Autify 紹介記事

「iPad mini 4 + Elemiya タッチペン + Jamboard」で実現するデジタルホワイトボード環境

最近「リモート研修」「リモート勉強会」も多く「デジタルホワイトボード環境」を作る必要があった.既にペンタブレット(GAOMON 製 と Parblo 製)を比較のために購入したけど,在庫がなく5月末発送になるため,暫定対応(できる限り安く)を考えていた.

「iPad + Apple Pencil」の組み合わせは評判が良く,試したかったけど,残念ながら使っているのは iPad mini 4Apple Pencil に対応していなかった.今回は Amazon で「Elemiya タッチペン(正式な製品名はわからない)」を購入した.現時点だと「2950円」で買えるし,在庫もある.実際に使ってみて,ホワイトボード用途であれば問題なく使えるため,紹介する.

Elemiya タッチペン

「銅製極細ペン先(メモ用途)」「導電繊維ペン先(ゲーム用途)」があり,ホワイトボード用途だとほとんど「銅製極細ペン先」を使っている.非常に軽くスラスラ描ける.充電は Micro USB で行なう.

Jamboard

「デジタルホワイトボード」として使えるサービスは複数あるけど,個人的には Jamboard を1番使っている.ザッと以下のような機能があり,とても便利!複数デバイスから同時接続をしても,レイテンシはそこまで気にならないと思う.

  • 無料
  • Web / iOS / Android 対応
  • アクセス制限
    • 非公開
    • 限定公開
    • 一般公開
  • 複数フレーム対応
  • ペン / マーカー / 蛍光ペン / ブラシ
  • 付箋
  • 画像
  • AutoDraw(AI を使った物体認識のような機能)

iPad mini 4 + Elemiya タッチペン + Jamboard

雰囲気を伝えるために「iPad mini 4 + Elemiya タッチペン + Jamboard」で描いてみた.

1. 構成図のようなもの

個人的に文字をキレイに描くのは難しく,少し揺れてしまうけど,そこそこ複雑な構成図もスラスラと描ける.以下はサンプルとして Docker コマンドの構成図を描いてみた.基本的には「マーカー」「蛍光ペン」を使う.「ペン」はちょっと細すぎる.

2. イラストのようなもの

簡単なイラストも描いてみた.そもそも絵が苦手ではあるけど,雰囲気は伝わると思う💦

気になる点

iPad で Jamboard を使うと「元に戻す/やり直し」が右下にあり,右利きだと描きながら押してしまう.ツライ!

まとめ

「デジタルホワイトボード環境」を作るために「Elemiya タッチペン」を購入した.Apple Pencil に対応していない iPad mini 4 を活用できるし,Jamboard と組み合わせれば,ホワイトボード用途として問題なく使えた.値段も安いし,1本持っておいても良いかと!

関連記事

kakakakakku.hatenablog.com

E2E テスト自動化プラットフォーム「Autify」を使ってシナリオをレコーディングする

2019年10月に正式リリースとなった「E2E テスト自動化プラットフォーム Autify」を試す.今回は Autify の CTO 松浦さん (@dblmkt) に期間限定の検証アカウントを作っていただいた.ありがとうございます!

autify.com

今まで SeleniumCapybara (Poltergeist) を使った E2E (End to End) テストの導入経験はあるし,最近だと CypressPuppeteer を使う機会もある.とは言え,技術選択よりも「E2E テストを継続的にメンテナンスすること」に対して課題を感じる.仮説検証を繰り返すためにリリース頻度を上げていくと,あっという間に E2E テストも落ちてしまう.適当に XPath を修正したり,修正を諦めた経験もある.

今回紹介する「Autify」を使うと AI にシナリオのメンテナンスを任せられる.Alchemist Accelerator Demo Day のピッチを観ると「Autify の価値と熱狂」を感じられる.Autify を試す前に見ておくと良いかと!

vimeo.com

準備

まず,Chrome 拡張「Autify Recorder」をインストールしておく.さらに設定から「シークレットモードでの実行」を許可しておく.

chrome.google.com

1. Autify : レコーディング

Autify の雰囲気を把握するために,kakakakakku blog の画面遷移をするシナリオをレコーディングする.以下のステップを試す.

  1. 「kakakakakku blog」にアクセスする
  2. 「最新記事(1記事目)」をクリックする
  3. 「Envoy」カテゴリをクリックする
  4. アーカイブから「2019年」をクリックする
  5. 「GraphQL Pokémon」の記事をクリックする
  6. キーワード「github」で記事を検索する
  7. ページネーションから「次のページ」をクリックする
  8. 「ブログタイトル」をクリックする

Autify の UI は定期的に変わる可能性もあるからリリースノートを見ておくと良さそう.今回は 4/22 リリースを前提にスクリーンショットを取得した.

docs.autify.com

1-1.「シナリオ」を作る

最初に「シナリオ」を作る.サイドメニューから「シナリオ」をクリックして,右上にある「新規シナリオ」をクリックする.

f:id:kakku22:20200429115123p:plain

次に「シナリオタイトル」「ウィンドウサイズ」「開始 URL」を入力する.今回は以下の値とする.

  • シナリオタイトル : kakakakakku blog 画面遷移
  • ウィンドウサイズ : 1280x1024
  • 開始 URL : https://kakakakakku.hatenablog.com/

f:id:kakku22:20200429115138p:plain

「レコーディングを開始」をクリックすると,自動的に Chrome の「シークレットウィンドウ」が起動する.右下に Chrome 拡張「Autify Recorder」が起動していることも確認できる.あとはステップを進めていく.完了したら「保存」をクリックする.

  • 赤丸 🔴 : 点滅中はレコーディング中を意味する
  • チェック ✅ : 検証を追加する
  • 矢印 ↪️ : ページ遷移を追加する

f:id:kakku22:20200429115153p:plain

1-2.「シナリオ」を確認する

レコーディング結果は Autify で確認できる.修正もできるため,誤クリックをしても消せる安心感がある.事前に考えたステップをレコーディングできていた.

f:id:kakku22:20200429115223p:plain

1-3.「シナリオ」を実行する

シナリオ画面の右上にある「Chrome で今すぐ実行」をクリックする.実行が終わり,サイドメニューから「テスト結果」をクリックすると,正常実行されたシナリオを確認できる.

f:id:kakku22:20200429115241p:plain

フェーズごとに画面比較もできる.これは便利!

f:id:kakku22:20200429115256p:plain

2. Autify : 画面遷移 + 検証

E2E テストでは,画面を検証するコードを実装する.今度は先ほどと同じシナリオに検証を追加していく.Aufity ではシナリオを「複製」する機能もあるけど,今回はもう1度レコーディングした.

  1. 「kakakakakku blog」にアクセスする
  2. 「最新記事(1記事目)」をクリックする
  3. 「Envoy」カテゴリをクリックする
    • ✅ URL を検証する : https://kakakakakku.hatenablog.com/archive/category/Envoy
    • ✅ カテゴリ名を検証する : Envoy
  4. アーカイブから「2019年」をクリックする
    • ✅ タイトルを検証する : 2019-01-01から1年間の記事一覧 - kakakakakku blog
  5. 「GraphQL Pokémon」の記事をクリックする
  6. キーワード「github」で記事を検索する
    • ✅ 要素を検証する : 次のページ
  7. ページネーションから「次のページ」をクリックする
  8. 「ブログタイトル」をクリックする

2-1.「ページ情報」を検証する

レコーディングをしながら検証を追加していく.まず「ページ情報」に関する検証は以下の「計5種類」から選択できる.今回は 「Envoy」 カテゴリをクリックした直後の URL を検証するため「URL が ○○ であることを確認する」を使う.

  • ページに指定の要素が存在することを確認する
  • ページが ○○ を含まないことを確認する
  • タイトルが ○○ であることを確認する
  • URL が ○○ であることを確認する
  • URL が ○○ を含むことを確認する

f:id:kakku22:20200429115317p:plain

2-2.「要素」を検証する

次に「要素」に関する検証は以下の「計4種類」から選択できる.今回はカテゴリ名を検証するため「対象のテキストが ○○ であることを確認する」を使う.なお,要素を選択する体験は Chrome DevTools と同じくマウスホバーを使う.

  • 対象が表示されていることを確認する
  • 対象のテキストが ○○ であることを確認する
  • 対象のテキストが ○○ を含むことを確認する
  • 対象のテキストが ○○ を含まないことを確認する

f:id:kakku22:20200429115336p:plain

2-3.「シナリオ」を確認する

レコーディング結果は検証も含めて Autify で確認できる.

f:id:kakku22:20200429115353p:plain

3. Autify : 画面遷移 + 検証(エラー)

最後は「検証時にエラーが発生する場合」を確認する.

3-1.「シナリオ」を修正する

2個目に作ったシナリオ「kakakakakku blog 画面遷移 + 検証」を複製して,URL 検証の期待値を /category/Envoy ではなく /category/Envoyy とした.意図的にエラーを発生させる.

f:id:kakku22:20200429115410p:plain

3-2.「シナリオ」を実行する

同じように「Chrome で今すぐ実行」をクリックする.実行が終わり,サイドメニューから「テスト結果」をクリックすると,エラーを確認できる.ちゃんと「期待値」「結果」を確認できるため,問題判別も素早くできそう.

f:id:kakku22:20200429115427p:plain

まとめ

今回は Autify の雰囲気を把握するために,kakakakakku blog の画面遷移をするシナリオをレコーディングしてみた.レコーディングは簡単だし,シナリオを修正することもできた.XPath をゴニョゴニョする必要もなく,非エンジニアもシナリオが作れる点もメリットに感じた.まだまだ Autify の機能はあるため,引き続き試していく!

git diff の結果を HTML に変換する「diff2html-cli」

最近 git diff の結果を GitHub プルリクエストのようなインタフェース (HTML) に変換する必要があった.既にツールがあるだろうと思って調べたところ「diff2html-cli」を使えば git diff の結果を HTML に変換できるとわかった.今回は diff2html-cli を紹介する.

github.com

インストール

diff2html-cli は npm で簡単にインストールできる.今回は最新版 の v5.1.0 を使う.コマンドは diff2html となる.

$ npm install -g diff2html-cli

$ diff2html --version
5.1.0

今回はサンプルとして,GitHub リポジトリ redash-hands-onv7.0.0 リリース (Tags) と v8.0.0 リリース (Tags) の差分を使う.

github.com

diff2html-cli を試す

まず,以下のように git diff の結果(標準出力)を diff2html コマンドと --input stdin オプションにパイプする.すると GitHub プルリクエストのような HTML に変換できる.便利!

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin

f:id:kakku22:20200427121105p:plain

スプリットモードにする

diff2html のデフォルトスタイルは line(GitHub だと Unified)となる.--style オプションを使って side(GitHub だと Split)を指定すると,GitHub で個人的によく使う「左右比較スタイル」になる.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --style side

f:id:kakku22:20200427121121p:plain

Files changed を初期表示する

他にも --summary open オプションを使うと,デフォルトで閉じている「Files changed」を初期表示できるようになる.GitHub プルリクエストの画面だと「Jump to...」をクリックすると表示される.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --summary open

f:id:kakku22:20200427121137p:plain

書き出す HTML ファイルを指定する

Mac で diff2html を実行すると,デフォルトだと /private/var/folders の下に diff.html を書き出す.--file オプションを使うと,任意の場所を指定して HTML ファイルを書き出せるようになる.以下の例だと,カレントディレクトリに redash.html を書き出す.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --file redash.html

独自フォーマットを使う

デフォルトだと HTML に Diff to HTML by rtfpessoa という不要な文章も含まれてしまう.「diff2html-cli」を個人的に使うなら無視できるけど,HTML を公開するシナリオだと微妙だなと感じた.調べたところ,独自フォーマットを使うためのオプションとして --htmlWrapperTemplate も実装されていた.使うのは簡単で,以下のように事前に用意したテンプレートを指定する.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --style line --file redash.html --htmlWrapperTemplate template.html

README.md を読むと,テンプレートに Git 情報を埋め込むプレースホルダを実装すると書いてあった.プレースホルダの例も README.md に載っている.以下にサンプルとして template.html を載せる.<!--diff2html-css-->//diff2html-highlightCode などをプレースホルダとして埋め込んでいる.

<html>
  <head>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/highlight.js@9.18.1/styles/github.min.css">
    <link rel="stylesheet" href="./template.css">
    <!--diff2html-css-->
    <!--diff2html-js-ui-->
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const targetElement = document.getElementById('diff');
        const diff2htmlUi = new Diff2HtmlUI(targetElement);
        //diff2html-fileListToggle
        //diff2html-synchronisedScroll
        //diff2html-highlightCode
      });
    </script>
  </head>
  <body>
    <div class="header">
      <h1>kakakakakku/redash-hands-on</h1>
      <img src="./images/logo.png">
    </div>
    <div id="diff">
      <!--diff2html-diff-->
    </div>
  </body>
</html>

センタリングをするサンプル CSS template.css も載せる.

.header {
  text-align: center;
}

img {
  width: 200px;
  text-align: center;
}

diff2html を実行すると,独自フォーマットを使えるようになった.

f:id:kakku22:20200427121155p:plain

まとめ

git diff の結果を GitHub プルリクエストのようなインタフェース (HTML) に変換する場合は diff2html-cli が便利!最近まさに diff2html-cli を使う場面があって導入した.HTML を公開するシナリオだと独自フォーマットを使うと良さそう.

github.com

最高すぎる!Gmail のフィルタ設定をデプロイできる CLI「gmailfilters」

無限に届くメールを整理するために Gmail の「フィルタ設定」を使っている人は多いと思う.

  • ラベルを付けたり
  • アーカイブをしたり
  • 削除をしたり

僕自身 Gmail を10年以上(メールを遡ったら2006年頃から)使っているため,歴史的な経緯から「フィルタ設定」が増えすぎてしまって,もはや管理不可能になっていた.もともと「フィルタ設定」には XML 形式で「エクスポート」「インポート」をする機能があるけど,もっとシンプルに設定を記述し,GitHub で管理し,継続的にデプロイする「Gmail Filter as Code」 を実現できたら最高だな!と考えていた.

gmailfilters とは?

gmailfilters を使うと,TOML フォーマットで Gmail フィルタ設定を記述できる.以下の例はnotifications@github.com から届くメールに GitHub ラベルを付ける」という意味になる.そして gmailfilters CLI を使って「エクスポート」をしたり,実際に Gmail に「デプロイ」もできる.今回は Go で実装された gmailfilters を紹介する.導入して1週間だけど,本当に最高すぎる!

[[filter]]
query = "from:notifications@github.com"
label = "GitHub"

github.com

アジェンダ

  1. gmailfilters を使う前に
  2. 認証情報を取得する
  3. gmailfilters をセットアップする
  4. gmailfilters でフィルタ設定をエクスポートする
  5. gmailfilters でフィルタ設定を継続的にデプロイする

1. gmailfilters を使う前に

1-1. フィルタ設定をバックアップする

闇雲に gmailfilters を使うと,今までのフィルタ設定を消してしまう可能性もあるため,バックアップ用途で XML をエクスポートしておく.エクスポートした XML を grep したら「計155件」もフィルタ設定があって驚いた!多すぎる...

$ grep '<id>' mailFilters.xml | wc -l
     155

1-2. フィルタ設定とメール配信設定を精査する

フィルタ設定を精査したところ,不要なフィルタ設定が多くあった.特に「不要なメールを削除するフィルタ設定(通販サイト/旅行サイト/クーポン関連/SaaS 関連など)」が1番多かった.根本的な解決を目指すため,会員登録をしている不要なサービスを全て「退会」し,会員登録をしておくサービスは「メール配信解除 (unsubscribe)」にした.またフィルタ設定は OR 条件なども使えるため,関連するフィルタ設定をリファクタリングした.最終的に「計20件」まで減らせた.スッキリした!

2. 認証情報を取得する

gmailfiltersGoogle API を使うため,事前に「認証情報(OAuth クライアント ID)」を取得しておく必要がある.ザックリと取得までのフローを紹介する.まず Google API Console にアクセスし,新しくプロジェクトを作成する.プロジェクト名は gmailfilters にしておく.

console.developers.google.com

次に「API とサービスを有効化」から「Gmail」を検索し「Gmail API」を有効化する.

f:id:kakku22:20200421130447p:plain

サイドバーから「認証情報」「認証情報を作成」「OAuth クライアント ID」と進む.「OAuth 同意画面(外部)」を作成してから認証情報を作成する.「アプリケーションの種類」「その他」にした.

f:id:kakku22:20200421130501p:plain

最後にプロジェクトページから認証情報を取得する.デフォルトだと client_secret_xxx.json というファイル名になっていた.

f:id:kakku22:20200421130513p:plain

3. gmailfilters をセットアップする

やっと準備が整った!さっそく gmailfilters をセットアップする.インストールは go get で簡単に行える.

$ go get github.com/jessfraz/gmailfilters

$ gmailfilters version
gmailfilters:
 version     :
 git hash    :
 go version  : go1.13.1
 go compiler : gc
 platform    : darwin/amd64

次は取得した認証情報ファイルを環境変数 GMAIL_CREDENTIAL_FILE に設定しておく.今回は direnv を使って export するようにした.

$ export GMAIL_CREDENTIAL_FILE=client_secret.json

環境変数を設定したら gmailfilters コマンドを実行する.表示された URL にアクセスし,権限を付与すると,コードをコピーする画面になる.コードをコピーしたら,入力待機中のままになっている gmailfilters コマンドにそのままペーストする.

$ gmailfilters
Go to the following link in your browser then type the authorization code:
https://accounts.google.com/o/oauth2/auth?xxx

(中略)

INFO[0329] Saving credential file to: /var/folders/xxx/token.json
must pass a path to a gmail filter configuration file

f:id:kakku22:20200421235922p:plain

4. gmailfilters でフィルタ設定をエクスポートする

gmailfilters コマンドと --export オプションを使って,フィルタ設定をエクスポートする.ファイル名は filter.toml にした.

$ gmailfilters --export filter.toml
exporting existing filters...
Exported 20 filters

実際にエクスポートしたフィルタ設定を以下に載せておく.GitHub の README.md では queryarchive など,頭文字は小文字なのに,エクスポートをすると Go の構造体 (Struct) のまま大文字になっている.実装は微妙な感じもするけど,どちらでも使える.

[[Filter]]
Query = "from:notifications@github.com"
Archive = false
Read = false
Delete = false
ToMe = false
ArchiveUnlessToMe = false
Label = "GitHub"
ForwardTo = ""

設定できるフィールドは以下となり,概要と入力値を載せておく.

  • Query : クエリ (条件)
  • QueryOr : OR クエリ (条件)
  • Archive : アーカイブするかどうか (true or false)
  • Read : 既読にするかどうか (true or false)
  • Delete : 削除するかどうか (true or false)
  • ToMe : 自分宛てのメールかどうか (true or false)
  • ArchiveUnlessToMe : 自分宛て以外のメールをアーカイブするかどうか (true or false)
  • Label : ラベルを付ける (ラベル名)
  • ForwardTo : 転送する (メールアドレス)

5. gmailfilters でフィルタ設定を継続的にデプロイする

残るは filter.toml を継続的にデプロイしていく.デプロイする場合は gmailfilters コマンドをそのまま使う.簡単すぎる!

$ gmailfilters filter.toml

Decoding filters from file filter.toml
Updating 20 filters, this might take a bit...
Successfully updated 20 filters

最後に個人的に使っているフィルタ設定を紹介しようと思う.

設定例 : 添付メールに Attachment ラベルを付ける

添付メールを探す場面が多いため,has:attachment クエリで検索をして Attachment ラベルを付けている.

[[filter]]
query = "has:attachment"
label = "Attachment"

設定例 : 1MB を超えるメールに Attachment/Large ラベルを付ける

larger:1M クエリを使うとサイズで検索できる.1MB を超える重すぎるメールは Attachment/Large ラベルを付けている.なお,Gmail のフィルタ設定は階層表現ができるため,gmailfilters では label をスラッシュ区切りにする.

[[filter]]
query = "larger:1M"
label = "Attachment/Large"

さらに gmailfilters はデプロイ時にラベルを新規作成してくれるため,事前にラベルを作っておく必要もなくて便利!以下のログを確認すると Created label と表示されている.

$ gmailfilters filter.toml

Decoding filters from file filter.toml
Updating 20 filters, this might take a bit...
INFO[0002] Created label: Attachment/Large
Successfully updated 20 filters

設定例 : GitHub のリポジトリ名で絞り込む

GitHub のリポジトリ通知は全部読むには多すぎるため,個人的に以下のポリシーで「通知設定 (Notifications)」をしている.

  • 「リリース情報を確認したい」リポジトリ
    • Notifications : Releases only
  • 「プルリクエストまで細かく確認したい」リポジトリ
    • Notifications : Watching

その前提で,GitHub の通知は全て notifications@github.com から届くため,リポジトリ名を subject クエリに設定する.以下は「GitHub の通知に GitHub ラベルを付ける」「GitHub の envoyproxy/envoy の通知に GitHub/Envoy ラベルを付けてアーカイブする」という設定になっている.envoyproxy/envoy の通知には GitHub ラベルも GitHub/Envoy ラベルも付く.

[[filter]]
query = "from:notifications@github.com"
label = "GitHub"

[[filter]]
query = "from:notifications@github.com subject:(envoyproxy/envoy)"
label = "GitHub/Envoy"
archive = true

設定例 : Amazon 購買メールに Amazon ラベルを付ける

Amazon 購買メールは「注文確認」「配達完了」など種類が多く,メールアドレスも異なるため「OR 条件」を使ってフィルタ設定をしている.単純にクエリを書くなら,以下のように OR を使える.

[[filter]]
query = "from:shipment-tracking@amazon.co.jp OR from:auto-confirm@amazon.co.jp OR from:order-update@amazon.co.jp"
label = "Amazon"
archive = true

ただし「OR 条件」が増えると可読性が下がるため,gmailfilters では queryOr フィールドを使って配列を記述できる.最終的に Gmail にデプロイされるフィルタ設定は一緒だけど,個人的に queryOr を使っている.

[[filter]]
queryOr = [
  "from:shipment-tracking@amazon.co.jp",
  "from:auto-confirm@amazon.co.jp",
  "from:order-update@amazon.co.jp"
]
label = "Amazon"
archive = true

まとめ

gmailfilters を使うと,TOML フォーマットで Gmail フィルタ設定を記述できる.現在は filter.toml を GitHub のプライベートリポジトリで管理して,フィルタ設定を継続的にデプロイしている.個人的に今年1番「出会えて良かったツール」と言える.最高すぎる!

さぁ gmailfilters で Gmail のフィルタ設定をデプロイしよう!

f:id:kakku22:20200421130355p:plain