Redash v9 で採用されたジョブキューライブラリ RQ (Redis Queue) の基本機能を試した

Redash v9 で「ジョブキューライブラリ」として採用された RQ (Redis Queue) を試した．今までの Redash では Celery を使っていた．RQ は Redis を使って「ジョブ登録 (enqueue)」と「ジョブ実行 (work)」の機能をサポートする．ドキュメントを読むと，多くの機能が実装されているけど，今回は基本機能にフォーカスした．

github.com

検証環境

今回は Docker Compose で検証環境を構築した．役割としては，大きく4種類あり，以下に載せておく．簡単に構成図も描いておいた．

• enqueue コンテナ : ジョブ登録 (Python)
• queue コンテナ : キュー (Redis)
• worker1 コンテナ : ジョブ実行 (Python)
• worker2 コンテナ : ジョブ実行 (Python)

なお，検証環境を再現する場合は GitHub の sandbox-rq リポジトリを見てもらえればと！docker-compose.yml や enqueue.py や worker.py など，サンプルコードも全てコミットしてある．

github.com

1.「queue」コンテナを起動する

最初に queue コンテナを起動する．今回は RQ の Redis コマンドを確認するため，並行して queue に接続して redis-cli monitor を実行しておく．実行された Redis コマンドがストリーミングされるため，便利！

$ docker-compose up -d queue
Starting sandbox-rq_queue_1 ... done

2.「enqueue」コンテナを起動する

次に RQ のドキュメントの通りに，サンプルジョブ job.py を実装する．実装は簡単で count_words_at_url() 関数は requests を使って与えられた URL の文字数を返す．

import requests

def count_words_at_url(url):
    resp = requests.get(url)
    return len(resp.text.split())

python-rq.org

今度はジョブを登録をするために enqueue.py を実装する．同じくドキュメントのサンプルコードを参考にする．Redis に対するコネクションを作成したら enqueue() 関数を使ってジョブを登録する．引数には job.py に実装した count_words_at_url() 関数と引数となる URL を渡す．今回は kakakakakku blog の URL にした．RQ は非同期処理を前提にするため，もし結果を取得する場合は，数秒待機してから job.result で取得できる．

from rq import Queue
from redis import Redis
from job import count_words_at_url
import time

r = Redis(host='queue', port=6379, db=0)
q = Queue(connection=r)

job = q.enqueue(count_words_at_url, 'https://kakakakakku.hatenablog.com/')

time.sleep(5)
print(job.result)

動作確認をするために enqueue コンテナを起動する．

$ docker-compose up -d enqueue
Starting sandbox-rq_enqueue_1 ... done

redis-cli monitor の結果から，RQ は rq:queue:default キーにジョブをリスト型として RPUSH していることを確認できた．そして rq:job:${UUID} キーにはジョブ情報を HSET していることを確認できた．実際に HGET でキーの中身を見ると，以下のように enqueued_at や status や description を取得できた．

127.0.0.1:6379> LRANGE rq:queue:default 0 -1
1) "18d1bb26-4948-45f9-8195-0de1c06c395e"
2) "d391221d-7c31-4822-98ae-1e25be4306f4"
3) "dacbcd76-af61-4b91-8d95-6c702bd4d3ba"

127.0.0.1:6379> HGET rq:job:18d1bb26-4948-45f9-8195-0de1c06c395e enqueued_at
"2020-08-09T22:32:59.752159Z"

127.0.0.1:6379> HGET rq:job:18d1bb26-4948-45f9-8195-0de1c06c395e status
"queued"

127.0.0.1:6379> HGET rq:job:18d1bb26-4948-45f9-8195-0de1c06c395e description
"job.count_words_at_url('https://kakakakakku.hatenablog.com/')"

3.「worker」コンテナを起動する

最後にジョブ実行をするために，ドキュメントのサンプルコードを参考に worker.py を実装する．ポイントは Redis に対するコネクションを作成したら work() 関数でジョブを実行する．なお，実行結果は直接 Redis に HSET で更新される．

from redis import Redis
import rq
from rq import Connection, Worker

r = Redis(host='queue', port=6379, db=0)

with Connection(r):
    w = Worker(['default'])
    w.work()

なお，載せた worker.py を見るとわかる通り，ジョブに依存せず，汎用的な実装になっている．具体的には job.py をインポートせずに動く．仕組みとしては，RQ のドキュメントにも載っているけど，内部的には Python の pickle モジュールを使って，関数自体をシリアライズしている．pickle は今まで使ったことがなかった．

docs.python.org

worker1 コンテナと worker2 コンテナを起動して，常駐させておく．

$ docker-compose up -d worker1 worker2
sandbox-rq_queue_1 is up-to-date
Recreating sandbox-rq_worker2_1 ... done
Recreating sandbox-rq_worker1_1 ... done

4. 動作確認をする

最後に全体を連携させながら動作確認をする．enqueue コンテナに -d オプションを付けずにフォアグラウンドで実行すると，5秒後に「5649文字」を取得できている．

$ docker-compose up enqueue
sandbox-rq_queue_1 is up-to-date
Starting sandbox-rq_enqueue_1 ... done
Attaching to sandbox-rq_enqueue_1
enqueue_1  | 5649
sandbox-rq_enqueue_1 exited with code 0

まとめ

Redash v9 で「ジョブキューライブラリ」として採用された RQ (Redis Queue) の基本機能を試した．pickle モジュールを使って，関数自体をシリアライズして「ジョブ登録 (enqueue)」をしている仕組みなのは興味深かった．ドキュメントを読むと，RQ にはまだまだ他に機能があり，引き続き試していく．

• プライオリティ
• タイムアウト
• リトライ
• スケジューリング
• 監視
• etc

関連記事

RQ (Redis Queue) を使った「Redash v9.0.0-beta」の紹介記事は以下にある！

kakakakakku.hatenablog.com

最近 Cyber-Dojo に導入された「実行結果予測 : predict?」機能

環境構築に悩むことなく「テスト駆動開発」や「モブプログラミング」を試すときに「Cyber-Dojo」をよく使う．一部は Cyber-Dojo Blog にも載っているけど，今年4月頃（時期は少し曖昧）から「Cyber-Dojo」に新機能と機能改善がリリースされている．代表的な新機能を紹介する．

なお，本記事は「2020年7月30日 (木)」に書き終えたけど，なんと「2020年8月1日 (土)」と「2020年8月2日 (日)」にリリースがあり，紹介する新機能のデザインがさらに変わった！本記事の最後に最新リリースのキャプチャも載せておく😇

cyber-dojo.org

1. 実行履歴で最初と最後に飛べるようになった

今までは「信号🚥」をクリックする以外だと ◀ と ▶ をクリックして順番に遡る機能しか提供されていなかった．以下のキャプチャの通り，もう1個 ◀ と ▶ が追加されたことで，すぐに「最初」と「最後」の実行履歴を確認できるようになった．

2. 実行履歴で「チェックアウト」と「フォーク」ができるようになった

今までは「実行履歴」を確認する機能しか提供されていなかった．新機能「チェックアウト (checkout)」を使うと，選んだ「信号🚥」の状態から実装できる．試行錯誤した過程を一度捨てて，やり直すときなどに使える．便利！

さらに新機能「フォーク (fork)」を使うと，選んだ「信号🚥」の状態から新しくエクササイズを作れる．例えば，モブを分割して複数のアイデアを同時並行的に試したり，使いたくなる場面もありそう！

3. エディタの背景色を変えられるようになった

画面左上の theme? ボタンをクリックすると，エディタの背景色を「白 (light)」から「黒 (dark)」に変えられるようになった．隣の colour? ボタンをクリックすると，シンタックスハイライトを ON/OFF できる．colour? ボタンも今まではなかったけど，機能としてはあり，前は Highlight という名称だった．

4. 実行結果の信号を予測できるようになった

Cyber-Dojo を使って「テスト駆動開発」を教える場合，必ず「実行したらどういう結果になる？」という問いに答えてもらってから実行してもらっている．これは闇雲にトライアンドエラーをするのではなく，意思を持って実行してもらうためで，新機能 predict? ボタンを使うと，まさに「信号🚥」を予測してから実行できる．最高！

さらに「予測結果（⭕の回数と❌の回数）」も集計される．「テスト駆動開発」と predict? の組み合わせは本当に便利！

新デザイン : 2020年8月1日 (土)

冒頭に書いた通り，本記事を書き終えた直後にリリースがあった．以下のように「設定アイコン」をクリックすると，今回紹介した theme? と colour? と predict? をまとめて設定できる settings ダイアログが表示されるようになった．

新デザイン : 2020年8月2日 (日)

翌日にまたリリースがあり「設定アイコン」の位置が変わった．また feedback や help などは「情報アイコン」にまとまった．

Cyber-Dojo Blog

blog.cyber-dojo.org

blog.cyber-dojo.org

関連記事

kakakakakku.hatenablog.com

モブプログラミングパターンを紹介した記事「Harvesting Mob Programming Patterns」を読んだ

Agile Alliance の Experience Reports として公開されている記事「Harvesting Mob Programming Patterns: Observing how we work」を読んだ．本記事は「モブプログラミング」で遭遇する「振る舞い」を「モブプログラミングパターン」として紹介している．モブプログラミングは何よりも「楽しさを増幅」する．しかし，実際にモブプログラミングを効果的に行うのは簡単ではなく，だからこそ「パターン」を知っておくことに意味がある．本記事を読んでいくと「あるあるー！」という「パターン」も多かったけど，名前を付けることに価値があると思う．今回は本記事の翻訳ではなく，読んだ個人的な感想をまとめる！

www.agilealliance.org

Pattern Map（パターンマップ）

まず，本記事に載っている「Pattern Map（パターンマップ）」を見ると，大きく「1. Mob Role（モブロール）」と「2. Collaboration Pattern（コラボレーションパターン）」と「3. Driving Pattern（ドライブパターン）」の3種類に分類されていて，それぞれにパターンが紐付いている．「計18パターン」のサマリーは筆者の GitHub リポジトリにも載っている．日本語は参考程度にしてもらえればと！なお，本記事で紹介されているパターンに ✅ を付けておいた．

• 1. Mob Role（モブロール）
  • Facilitator（ファシリテーター）✅
  • Recorder（レコーダー）✅
  • Researcher（研究者）
  • Navigator（ナビゲーター）
  • Driver（ドライバー）
  • Devil’s Advocate（悪魔の代弁者）
• 2. Collaboration Pattern（コラボレーションパターン）
  • Punch List（パンチリスト）✅
  • Splinter Group（破片グループ）
  • Ridin’ Shotgun（助手席に乗る）✅
  • Mute your mic（マイクをミュートにする）✅
  • Fight Club（ファイトクラブ）
  • Natural Swap（自然なスワップ）
  • Forced Swap（強制的なスワップ）
  • Distracted non-Participant（注意散漫な非参加者）
• 3. Driving Pattern（ドライブパターン）
  • Thinking Out Loud（大声で考える）
  • Tell me what to write（何を書くのか教えて）✅
  • Driving on Autopilot（自動操縦で運転する）
  • Plowing Through（切り開いて進む）✅

github.com

1. Mob Role（モブロール）

まず「Mob Role（モブロール）」とは，名前の通り「モブプログラミング中の役割」を意味する．一般的には「ドライバー」と「ナビゲーター」をイメージすると思う．本記事を読むと「気付かずに他の役割も兼任していること」に気付かされる．計6種類ある役割の中で，本記事では「ファシリテーター」と「レコーダー」の2種類が紹介されていた．

🔵 Facilitator（ファシリテーター）

モブプログラミングに集中したり，正しく前進したり，作業時間が伸びているときに中断したり，モブプログラミング中にアドバイスが必要な場面がある．具体的には「休憩を取ろう！」や「モブを分割して進めよう！」など．このように，モブプログラミングに参加しながら「客観的な視点で提案をする役割」を「ファシリテーター」と言う．モブプログラミングを導入した序盤は僕自身がファシリテーターを担当することが多かったけど，慣れてくると全員がファシリテーターを担当できるようになっていたように思う．1番重要なのは「特定のナビゲーターにファシリテーターを担当してもらう」のではなく，モブプログラミングの「流れ」で，自然に「誰かが」ファシリテーターを担当していたという状態を目指すことと言える．

🔵 Recorder（レコーダー）

モブプログラミング中に設計をしたり，意思決定が必要な議論をするときに，モブプログラミングだからこそ意思決定を素早く行えるけど，必要最低限のドキュメントはある．本記事では ADRs (Architecture Decision Records) が紹介されていたけど，簡単に言えば「チームに必要な決定事項をまとめたドキュメント」となる．モブプログラミング中にドキュメントを書く役割を「Recorder（レコーダー）」と言う．モブプログラミングに参加しながら「レコーダー」を担当するのは難易度が高いように感じるけど，とても重要な役割だと思う．当然ながら「議事録担当」のように「レコーダー」を担当すれば「自分の居場所が確立されている」という意味ではないため，勘違いしないように！本記事には書いてなかったけど，例えば「ドキュメントをレビューするモブセッション」をするなど，レコーダーに負荷を偏らせずに進めることもできる．

adr.github.io

2. Collaboration Pattern（コラボレーションパターン）

次に「Collaboration Pattern（コラボレーションパターン）」とは，名前の通り「モブプログラミング中にコラボレーションを高めるパターン」を意味する．単純にドライバーとナビゲーターが実装をするだけではなく，ちょっとした「パターン」を適用すると効果的だと思う．

🔵 Punch List（パンチリスト）

モブプログラミング中に実装するとしても「アプローチ（実装の順番）」はメンバーによって異なる．例えば，最初からモジュール化をする人もいれば，全体を実装してから細かく分割する人もいる．ようするに実装を始める前に「アプローチ（実装の順番）」をタスクリストとして明確に整理しておくことを「Punch List（パンチリスト）」と言う．本記事を読むと，プライオリティ付きのタスクリストだけではなく，ホワイトボードを使ったグラフィカルなタスクリストも紹介されていた．やはり，ホワイトボードに図解することにより，コラボレーションも高められると思う．

🔵 Ridin’ Shotgun（助手席に乗る）

次は「アンチパターン」の紹介で「Ridin’ Shotgun（助手席に乗る）」と言う．別名としては「Dominate the Mob（モブを支配する）」とも言う．昔話として，馬車で移動するときに手綱を引く人は両手がふさがってしまうため，敵から身を守るために助手席に用心棒を雇っていたという話のメタファーになっている．ようするに「特定のナビゲーターばかり喋っている」というアンチパターンのことを意味している．短期的な効果はあるかもしれないけど，参加できないナビゲーターも増えてしまうため，長期的にはマイナスとなり，避けるようにする．

🔵 Mute your mic（マイクをミュートにする）

1個前で紹介した「Ridin’ Shotgun（助手席に乗る）」のパターンに当てはまっている場面など，多くのナビゲーターがうまくモブプログラミングに参加できてなく沈黙が続いている場合は，効果的なディスカッションにならないため，よく喋るナビゲーターに「意図的に数分間マイクをミュートにしてもらえないか？（もしくは喋らずに見ててもらえないか？）」と「ファシリテーター」から提案する．本記事では「気まずい沈黙 (awkward silence) はコラボレーションを促進する」と書いてあり，とても良い表現だと思った．

なお「マイクをミュートにする」のは，モブプログラミングから離脱するという意味ではなく，例えば「レコーダー」や「Researcher（研究者）」など，他の役割に専念することもできる．チームが前進するために必要な情報を調査する役割を「Researcher（研究者）」と言う．前に読んだ「モブプログラミング・ベストプラクティス」では「タイムボックス付きの探求」という表現になっていて，どちらも似ている．

kakakakakku.hatenablog.com

3. Driving Pattern（ドライブパターン）

最後に「3. Driving Pattern（ドライブパターン）」とは，タイピストとも呼ばれる「ドライバーの振る舞い」を意味する．

🔵 Plowing Through（切り開いて進む）

ドライバーはナビゲーターのアドバイスで作業を進めていくことに価値があるはずなのに，ドライバーが「勝手に1人で」作業をどんどん進めてしまう場面は少なからずあると思う．そういうドライバーの振る舞いを「Plowing Through（切り開いて進む）」と言う．「耕す」という翻訳も選択肢にあったけど，個人的には「切り開いて進む」が良いと思った．

ドライバーが勝手に進めてしまうと，ナビゲーターのアドバイスが採用されなかったり，チームでコードを理解する機会が得られないため，基本的はアンチパターンと言える．よって，ファシリテーターに注意してもらう．しかし，必ずしもアンチパターンであるというわけではなく，納期が厳しかったり，とにかく完了することに価値があったり，専門家の作業を見て学んでもらいたい場合には有効だと本記事には書いてある．そのときには「Thinking Out Loud（大声で考える）」と言うパターンを使って，ドライバーの思考を喋りながら進めてもらう．過去にチームで新しいプログラミング言語を採用したときは，詳しいメンバーに喋りながらドライバーをしてもらったこともあり，実体験としても重要だと感じる．

🔵 Tell me what to write（何を書くのか教えて）

実装をするときに必要になるコンテキスト（業務知識やモジュール構成など）を詳細に知っているメンバーがチームに数名しかいなかったりすると，モブプログラミングを進めたくても，正しい方向に進められないという不安もある．そのときはドライバーが「コードはどこにあるー？」や「どのクラスの責務なのー？」や「どのようにテストをすれば良いのー？」など，とにかく積極的にナビゲーターに質問をすることが重要で，この振る舞いを「Tell me what to write（何を書くのか教えて）」と言う．どこに向かっていくのかが明確になれば，うまく進めていくことができる．ドライバーに限らず，ナビゲーターも理解ができなかったら，遠慮なく「待って！」と言うべきだと思う．

まとめ

「Harvesting Mob Programming Patterns: Observing how we work」を読んだ．「1. Mob Role（モブロール）」と「2. Collaboration Pattern（コラボレーションパターン）」と「3. Driving Pattern（ドライブパターン）」にうまく分類されているし，実体験としても「あるあるー！」と感じられる点も多く，とても良かった．本記事には詳しく載っていなかった「Researcher（研究者）」や「Splinter Group（破片グループ）」や「Thinking Out Loud（大声で考える）」も個人的に重要だと思っているので，全パターンが詳細に解説されている記事があったら嬉しい！「モブプログラミングパターン」に興味があったら読んでみると良いのでは！

www.agilealliance.org

関連記事

最近は「リモートモブプログラミング」の話題も増えてきた．以下の記事を合わせて読んでもらえると参考になるはず！

kakakakakku.hatenablog.com

gibo コマンドを使って .gitignore のテンプレートを簡単に作成する

ブログに載せるサンプルコードを管理したり，仕事でプロトタイプを実装することが多かったり，とにかく Git リポジトリを新しく作る機会が多くある．そのときに毎回似たような .gitignore を作ることになり，面倒だった．共通的な設定はホームディレクトリの ~/.gitignore を使っているけど，同僚とコードを共有することもあり，やはりリポジトリ単位に .gitignore を作成したかった．この運用を軽減するために使っているツールとして，今回は .gitignore のテンプレート（ボイラープレート）を簡単に作成できる「gibo」を紹介する．

gibo とは？

「gibo (short for .gitignore boilerplates)」 を使うと，例えば Python や Ruby など，プログラミング言語ごとに用意された .gitignore のテンプレートを簡単に作成できる．正確に表現すると，GitHub のリポジトリ github/gitignore に公開されているテンプレートを gibo コマンドを使って取得できる．よって，ラッパーコマンドのような立ち位置と言える．非常に便利でよく使っている．

github.com

github.com

gibo をインストールする

Mac なら brew コマンドを使えば，簡単にインストールできる．今回は最新版 v2.2.4 を前提にする．

$ brew install gibo

$ gibo version
gibo 2.2.4 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

もし，ローカル環境にインストールしたくない場合は，Docker を使う案もある．

$ docker run --rm simonwhitaker/gibo version
gibo 2.2.4 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

gibo を使う

基本的には gibo dump コマンドを使って，標準出力をリダイレクトする．以下のように gibo dump Python とすれば，Python 用の .gitignore を作成できるし，gibo dump Python macOS のようにスペース区切りで複数指定すれば，Python と Mac 用の .gitignore を作成できる．ほら .DS_Store を間違ってコミットしちゃった経験は誰にでもあるよね？笑

$ gibo dump Python >> .gitignore
$ gibo dump Python macOS >> .gitignore

Docker を使う場合は，以下のように docker run をすれば OK！

$ docker run --rm simonwhitaker/gibo dump Python >> .gitignore
$ docker run --rm simonwhitaker/gibo dump Python macOS >> .gitignore

タブ補完をする

gibo は「タブ補完」もサポートしている．README.md に bash / zsh / fish の設定が載っているけど，僕は oh-my-zsh を使っているため，Wiki を参考に oh-my-zsh の設定を紹介する．以下のように plugins/gibo ディレクトリを作成して，GitHub に公開されている gibo-completion.zsh にシンボリックリンクを貼るだけ！簡単！gibo-completion.zsh は任意のディレクトリに置いておけばよくて，僕は dotfiles の中に置いてある．設定が終わったら，zsh をリロードしておくのを忘れずに！

• Using gibo as an ohmyzsh plugin · simonwhitaker/gibo Wiki · GitHub

$ mkdir -p ${ZSH}/custom/plugins/gibo/
$ ln -s ~/dotfiles/gibo-completion.zsh ${ZSH}/custom/plugins/gibo/gibo.plugin.zsh

以下のように gibo [tab] と入力すれば，コマンドが表示されるし，gibo dump P [tab] と入力すれば，P にマッチするテンプレートを補完できる．便利だし，むしろ使えないと困る！

$ gibo [tab]
dump     -- Dump one or more boilerplates
help     -- Display this help text
list     -- List available boilerplates
root     -- Show the directory where gibo stores its boilerplates
search   -- Search for boilerplates
update   -- Update list of available boilerplates
version  -- Display current script version

$ gibo dump P [tab]
PSoCCreator    Perl           Pimcore        Prestashop     Puppet
Packer         Phalcon        PlayFramework  Processing     PureScript
Patch          Phoenix        Plone          PuTTY          Python

他にもコマンドはある

gibo dump コマンド以外だと，例えば gibo list コマンドを使うと，サポートしているテンプレートの一覧を確認できる．とは言え，さっき紹介した「タブ補完」を設定すれば gibo dump [tab] と入力すれば良く，個人的にはあまり使っていなかったりする．

$ gibo list
Actionscript        Dart            NetBeans        Node
Ada         Delphi          Ninja           Objective-C
Agda            DM          NotepadPP       OCaml
（省略）

gibo root コマンドを使うと，GitHub のリポジトリ github/gitignore を clone したディレクトリを確認できる．ようするに，テンプレートはローカルにコピーされている．すると，今度はテンプレート自体の更新をどのようにするのか？という点が気になると思う．gibo update コマンドを使えば，簡単に最新に追随できる．

$ gibo root
/Users/kakakakakku/.gitignore-boilerplates

$ ls -1 /Users/kakakakakku/.gitignore-boilerplates | wc -l
     132

$ gibo update
From github.com:github/gitignore
 * branch            master     -> FETCH_HEAD
Already up to date.

まとめ

もし GitHub のリポジトリ github/gitignore からコピーして .gitignore を作成している場合は，gibo を使ってシュッと .gitignore を作成すると便利！使うときは「タブ補完」も忘れずに設定しておくと良いぞ！

github.com

2020年6月にリリースされた「Redash v9.0.0-beta」の新機能と機能改善を「計10点」紹介

2020年6月に Redash の最新バージョン「Redash v9.0.0-beta」がリリースされた．正式リリースまでに変更される可能性はあるけど，Change Log を読むと新機能と機能改善が多くあった．今回は実際に試しながら「 Redash v9.0.0-beta の新機能と機能改善」を「計10点」厳選して紹介する．Change Log は以下の CHANGELOG.md で確認できる．

• redash/CHANGELOG.md at master · getredash/redash · GitHub

目次

1. データソースが追加された
2. クエリ画面がリニューアルされた
3. Date Range パラメータで直近n日を指定できるようになった
4. グラフ上で使える Plotly Mode Bar を非表示にできるようになった
5. クエリ結果を TSV 形式でダウンロードできるようになった
6. アラート画面がリニューアルされた
7. アラートのカスタムテンプレート機能が正式にリリースされた
8. アラートをミュートできるようになった
9. Celery を廃止して RQ に移行した
10. Python 3 を正式にサポートした

1. データソースが追加された

Redash はバージョンアップごとにデータソースが増えている．Redash v9.0.0-beta では「計4種類」が追加されて「計55種類」になった．また今回は多くのデータソースに修正が入っているため，今まで困っていた挙動があれば，Change Log を見ておくと良いと思う．

• Amazon Cloudwatch
• Amazon CloudWatch Logs Insights
• Azure Kusto
• Exasol

2. クエリ画面がリニューアルされた

クエリ画面のデザインがリニューアルされた．Change Log にも easier to read for non-technical Redash users と書かれている通り，直感的になったと思う．例えば「クエリ結果」と「グラフ」をタブから選べるようになった．

3. Date Range パラメータで直近n日を指定できるようになった

今まで Date Range パラメータを使う場合は，カレンダーから正確な日付を指定する必要があった．ようするに「直近n日」という毎日変化する日付は指定できなかった．今回追加された機能を使うと「This week」や「Last 30 days」など「計11種類」の選択肢から選べる．ダッシュボードを継続的にモニタリングしている場合などに特に便利な機能では！

• This week
• This month
• This year
• Last week
• Last month
• Last year
• Last 7 days
• Last 14 days
• Last 30 days
• Last 60 days
• Last 90 days

4. グラフ上で使える Plotly Mode Bar を非表示にできるようになった

個人的に特に不満なく使っていたけど，グラフ上にマウスを乗せると表示される Plotly Mode Bar を非表示にできるようになった．

設定は Organization Settings の中にあるため，勝手に設定変更はせず，チームで決めておくと良さそう．

5. クエリ結果を TSV 形式でダウンロードできるようになった

今までは「CSV 形式」と「Excel 形式」でダウンロードできたクエリ結果を「TSV 形式」でもダウンロードできるようになった．残るは「JSON 形式」と「YAML 形式」あたり？選択肢が増えるのは良いと思う．

6. アラート画面がリニューアルされた

アラート画面のデザインがリニューアルされた．今までの設定項目だった Op や Rearm seconds など，わかりにくかった表現もなくなり，直感的に設定できるようになった．

7. アラートのカスタムテンプレート機能が正式にリリースされた

Redash v8 でサイレントリリースされていたアラートの「カスタムテンプレート機能」が正式にリリースされた．今までは Feature Toggle の環境変数 REDASH_FEATURE_EXTENDED_ALERT_OPTIONS を有効化しないと使えなかった．なお，Redash v8 とはテンプレートの構文が変わっているので，ドキュメントを見ながら試すと良いと思う．現時点では「計10種類」の組み込み変数をサポートしている．

• ALERT_STATUS
• ALERT_CONDITION
• ALERT_THRESHOLD
• ALERT_NAME
• ALERT_URL
• QUERY_NAME
• QUERY_URL
• QUERY_RESULT_VALUE
• QUERY_RESULT_ROWS
• QUERY_RESULT_COLS

redash.io

実際に以下の「カスタムテンプレート」を用意した．

Subject

🛑 Redash アラート : {{ALERT_NAME}}

Body

アラート状態が "{{ALERT_STATUS}}" になりました 👀
値 "{{QUERY_RESULT_VALUE}}" は閾値 "{{ALERT_THRESHOLD}}" を超えました 📈

設定してから「Preview」を使うと，実際に組み込み変数を展開した値を確認することもできる．便利！

Slack にアラートを投稿してみた．情報量を増やすことができて便利！「カスタムテンプレート機能」は必須機能の1つになりそう！

8. アラートをミュートできるようになった

今まではアラートをミュートすることはできず，Destinations のエントリーを一時的に削除する運用などをしていた．Redash v9.0.0-beta から「Mute Notifications」と「Unmute Notifications」を使って切り替えられる．運用目線で便利なのでは！

9. Celery を廃止して RQ に移行した

Redash v8 までワーカー処理などに使われていた非同期処理フレームワーク Celery を廃止し，Redash v9.0.0-beta からは RQ (Redis Queue) に移行した．Redash を使うときは何も影響はないけど，Redash 環境を運用するエンジニアは，知っておくと良さそう．

python-rq.org

10. Python 3 を正式にサポートした

Redash v9.0.0-beta から Python 3 を正式にサポートし，Python 2 はサポートされなくなった．RQ と同じく Redash を使うときは何も影響はないけど，知っておくと良さそう．プルリクエストを読むと Python 3 をサポートするために必要だった差分を確認できる．u'' を書かなくて良かったり，読みやすくなった気もする．

github.com

まとめ

2020年6月にリリースされた「Redash v9.0.0-beta」を試しながら「 Redash v9.0.0-beta の新機能と機能改善」を「計10点」厳選して紹介した．個人的には「アラート画面」のリニューアルは嬉しかった．「Redash v9」が正式にリリースされたら kakakakakku/redash-hands-on にも対応させる予定！お楽しみに！

github.com

過去の Redash 紹介記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com