各社の Redash 運用 Tips を知れた「Redash Meetup 3.0.0」だった

参加してから1週間たってしまったけど「Redash Meetup 3.0.0」のレポートを書く．Redash Meetup のコミュニティ立ち上げを手伝わせてもらったのが去年12月で，早くも6回目のイベント開催を実現できているし，参加者もどんどん増えているし，ああ，大きくなったなぁーとしみじみ感じていた．

redash-meetup.connpass.com

受付

今回も受付を担当させてもらった．コミュニティ運営者なら事前に見込んでいると思うキャンセルだけど，今回もそこそこ多かった．とは言え，過去最大の参加者が集まっていて，Redash の盛り上がりを感じることができた．

• 一般参加枠 : 60
  • 参加 : 58
  • キャンセル : 40
• イベント関係者枠 : 8
  • 参加 : 8

Redash の API 活用事例

• Redash API で様々な操作ができる
  • クエリ情報取得
  • クエリ結果取得
  • などなど
• エンドポイントの一覧は redash/handlers/api.py を見る
• クエリの差分管理を GitHub で行う
  • GitHub - ariarijp/redashman

Redash API のエンドポイント一覧が載ったドキュメントがなく，結局 redash/handlers/api.py を見るというのは，超あるあるで笑ってしまった．Redash のクエリは変更履歴が残らないため，自動抽出して GitHub に残す仕組みは素晴らしいし，会社的に重要なクエリが壊れるとリスクなので，もっと詳細を聞きたかった．とは言え，基本的には他人のクエリを修正できず，フォークを使うので，少人数だからこそ相互編集ができる権限設定にしてる感じかな？

みんなが Redash を気持ちよく使うやり方を考える

• 社内でハンズオンを実施した
  • 非エンジニアも含めて，もっと気軽に Redash に触れられる雰囲気を作った
  • 自由に質問できる Slack チャンネルを作った
• クエリ乱立問題を改善した
  • カテゴリを設定した（大カテゴリ／中カテゴリ）
  • Redash の queries テーブルを使って，クエリ一覧を取得するクエリを作成した

Redash を導入したフェーズから，積極的に運用を回していくフェーズに移行するときに，必ず問題になる「クエリ乱立問題」にどう向き合ったのかという運用 Tips を聞くことができた．ある程度の規模になると，カテゴリなど，命名規則で戦うことになるのは必須で，さらにルールの脱線を見逃さないように誰かしら警察👮になると思う．メタテーブルを活用して「クエリ一覧を取得するクエリ」を作っているあたりは，上手な運用だなと思った．導入フェーズでは，僕の「Redash ハンズオン」を活用して頂いたとのことで，あざます！

Hidden gems in Redash

• Query Results データソース
  • SQLite の構文で，クエリ結果に対して，クエリが実行できる機能
• Python Results データソース
• Url Results データソース
  • Redash Style な JSON を返す API にクエリを実行できる
  • Script Results データソース
  • Querying URLs | Redash

マニアックなデータソースの詳細解説で，使ったことがないものもあり，深みがすごかった．Url Results は知っていたけど，実際に仕事で使う場面がなく，もしあれば聞いてみたい．

Redash 運用に付きまとう課題とその解決方法

• Pairs 管理画面の代替として，Redash が候補に挙がった
• クエリ増殖期
  • 命名ルールで整理する（しかし，途中で運用が止まった）
  • BI チームが承認すると [公式] マークを付けられる
  • グラフ線の配色ルールを決めた
• API 多用期
  • Google SpreadSheet を併用して，可視化を進めた
  • Redash のキューが詰まった
  • できる限り，スケールアップをした
• Tableau 併用期
  • KPI を深掘るときは Tableau を使っている

会社の規模が大きくなると，運用も大変だし，Tableau を併用したりするんだなーと，聞いていて感じた．クエリに [公式] マークを付けるという運用は超良さそうで，その視点は今までなかった！あとグラフ線の配色ルールも，デフォルトのまま使うことが多かったので，これも目から鱗だった．

Speaker Deck

公開された資料，参加レポートなどを見ていて，Speaker Deck の闇がまだ知られていなさそうなので，2記事を貼っておく．タイトルだけじゃなく，Hatena Blog の Embed も最近はうまく動かないので，知っておくと良いと思う！

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Redash ハンズオン

イベント中に 100 Star 🌟 達成！Redash 導入フェーズで是非活用頂けると！

github.com

関連記事

ariarijp.hatenablog.com

プロジェクトの成功を支える ZenHub と モブプログラミング

今日は「ランサーズ開発ランチ」で登壇をしてきた．依頼を受けたテーマは「プロジェクトリード」だったけど，最近登壇しているものを再演しても，既視感があるかなと思って，今回はあえて「ZenHub」と「モブプログラミング」を詳細に深掘るテーマにした．質疑応答も多くて，素晴らしい雰囲気だった！

lancers-engineer.connpass.com

発表資料

関連記事

モブプログラミングの基礎を学べる「Getting Started with Mob Programming」の書評は別の記事にまとめている．今日見たところ，既に Retired になっていて，販売中止になっていた！6月まで買えたのに...！

kakakakakku.hatenablog.com

「プロジェクトリード」に関しては，以下の2記事が参考になると思う．

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

レポート記事

engineer.blog.lancers.jp

syossan.hateblo.jp

楽しく！アウトプットを習慣化しよう

今日は大阪出張で「DevLOVE 関西」のイベントに参加予定だったけど，豪雨の影響でイベントが中止になってしまった．今回イベントに誘って頂いた @yohhatu さん，本当にありがとうございました！

devlove-kansai.doorkeeper.jp

発表する予定だった資料

せっかく作った資料なので，このままお蔵入りにするのではなく，公開することにした．ストーリーの軸は「なぜアウトプットを習慣化するべきなのか？」という点で，特に今回は「ブログ」にフォーカスを当てている．

ブログメンター

去年末から趣味（ボランティア）で取り組んでいる「ブログメンター（アウトプットメンター）」の話もする予定だった．特に「ブログネタ探し」のプロセスは面白いと思っていて，最初にメンティに「最低20個」出してもらって，それをさらにブラッシュアップして「30-50個」まで増やす．重要なのは「これもブログネタになるんだ！」という気付きの部分で，そこに気付いてしまうと，あとは自律的に「ブログネタ探し」ができるようになる．メンタリングでは「ブログネタがないから書けない」という理由（言い訳）を排除していくことからスタートする．

Requirements 駆動 ネタ探し

メンタリングの中で「Requirements 駆動 ネタ探し」を紹介する場合もあるので，今回の発表で話をする予定だった．詳しくは発表資料に書いてある通りで，興味のある会社の「エンジニア募集ページ」に書いてある Requirements と自分のスキルを比較することで，不足しているな！と感じるスキルがあれば，それこそが「ブログネタ」になる．僕自身も定期的に「Requirements 駆動 ネタ探し」をしている．

@year_progress をフォローしよう！

twitter.com

僕の大好きな Twitter アカウントに @year_progress がある．これは，名前の通り，1年間の経過を教えてくれるので，例えば「今年ももう 50% 終わったけど，成長実感ある？時間を無駄にしてない？」など，自分自身にプレッシャーを掛けることができる．フォローするだけで，意識が高まるので，本当にオススメ！

まとめ

「DevLOVE 関西」のイベント中止は残念だったけど，安全第一なので，素晴らしい判断だと思う．僕は新大阪に向かう新幹線の中で緊急停止となり，数時間待っているけど（今もまだ待っている），その時間を無駄にせずブログを書けたから良かった．ブログ，アウトプット全般に悩んでいる人がいれば，去年に発表した資料（今回の資料のベースになっている）も参考になると思うので，是非合わせて見てもらえると！

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

CodeDeploy のデプロイ実行とデプロイ完了待機を AWS CLI で試した

CodeDeploy のデプロイ実行を AWS CLI で試した．今回は GitHub からコードを取得する前提にしている．

コミットハッシュを取得する

CodeDeploy で GitHub からコードを取得する場合，対象となるコミットハッシュが必要になる．そこで，GitHub API から指定したブランチの最新コミットハッシュを取得する．また，プライベートリポジトリの場合はアクセストークンが必要になるため，Authorization ヘッダーに乗せている．

• Git Refs | GitHub Developer Guide

公式ドキュメントに載っている通り，以下のようなレスポンスが返ってくるので，sha からコミットハッシュを取得することができる．

{
  "ref": "refs/heads/featureA",
  "node_id": "MDM6UmVmcmVmcy9oZWFkcy9mZWF0dXJlQQ==",
  "url": "https://api.github.com/repos/octocat/Hello-World/git/refs/heads/featureA",
  "object": {
    "type": "commit",
    "sha": "aa218f56b14c9653891f9e74264a383fa43fefbd",
    "url": "https://api.github.com/repos/octocat/Hello-World/git/commits/aa218f56b14c9653891f9e74264a383fa43fefbd"
  }
}

デプロイを実行する

AWS CLI でデプロイを実行する場合 aws deploy create-deployment を使う．ポイントはコミットハッシュの指定で，github-location オプションを以下のフォーマットで指定する．

repository=string,commitId=string

• create-deployment — AWS CLI 1.15.51 Command Reference

デプロイの完了を待つ

aws deploy create-deployment は，デプロイを実行するだけなので，デプロイの完了を待つ aws deploy wait deployment-successful と組み合わせて使う．aws deploy create-deployment のレスポンスに以下のような deploymentId が含まれているので，これを指定する．

{
    "deploymentId": "d-N65YI7Gex"
}

• deployment-successful — AWS CLI 1.15.51 Command Reference

サンプルコード

最後にサンプルコードを貼っておく．実際に実装したコードはもっと複雑だけど，今回は単純化している．

実行

export BRANCH_NAME='master'
sh deploy.sh

deploy.sh

#!/bin/sh

#######################################
# 指定したブランチの最新コミットハッシュを取得する
# Arguments:
#   $1 BRANCH NAME
# Returns:
#   COMMIT HASH
#######################################
get_commit_hash() {
  curl -s -H "Authorization: token xxx" \
    https://api.github.com/repos/xxx/xxx/git/refs/heads/$1 | jq  -r '.object.sha'
}

#######################################
# デプロイを実行する
# Arguments:
#   $1 BRANCH NAME
# Returns:
#   DEPLOYMENT ID
#######################################
create_deploy() {
  echo $(
    aws deploy create-deployment \
      --application-name xxx \
      --deployment-group-name xxx \
      --github-location repository=xxx/xxx,commitId=$(get_commit_hash $1) \
      --deployment-config-name CodeDeployDefault.OneAtATime \
      --region ap-northeast-1 | jq -r '.deploymentId'
  )
}

#######################################
# デプロイの完了を待つ
# Arguments:
#   $1 DEPLOYMENT ID
#######################################
deploy_waiter() {
  aws deploy wait deployment-successful --deployment-id $1
}

deployment_id=$(create_deploy ${BRANCH_NAME})
echo "deploymentId: ${deployment_id}"

deploy_waiter ${deployment_id}

CodeDeploy 関連記事

kakakakakku.hatenablog.com

モブプログラミングに特化したタイマーアプリ「Mobster」

モブプログラミングをするときに，モブセッションの時間を意識することが重要で，事前に準備しておく MDE (Mob Development Environment) の中にも「Timer」が含まれている．シンプルにスマホのタイマーアプリを使っているチームも多い気がする．

kakakakakku.hatenablog.com

Mobster とは？

• Mobster - Pair and Mob Programming Timer for Mac, Windows, and Linux

そこで今回は，モブプログラミングに特化したタイマーアプリの「Mobster」を紹介する．アプリは OSS で公開されているので，実装を読むこともできる．

github.com

Mobster : ドライバーとナビゲーターを設定できる

「Active」のところにある「+ Mobster」フィールドから，モブプログラミングに参加するドライバーとナビゲーターを設定できる．ドライバーには青く「ハンドルアイコン」が付き，ナビゲーターには「地図アイコン」が付く．Mobster だと，2人目のナビゲーターには「地図アイコン」が付かず，なぜ？という疑問はある．メインナビゲーターのような感じなのかな？

さらに「サイコロ」アイコンを押すと，ドライバーを自動的に選ぶことができる．ドライバーを挙手制にすると，ある程度，心理的な影響が出る場合もあるので，自動的に選べるのは便利だと思う．

Mobster : モブセッション時間を設定できる

上のキャプチャにある通り，モブセッション時間と休憩時間を設定できる．僕のチームでは「ポモドーロテクニック」を採用しているので「25 + 5」という設定にしている．

Mobster : タイマーが画面右下に表示される

「Start Mobbing」のボタンを押すと，下のキャプチャにある通り，画面右下にタイマーが表示されて，常に意識しながらモブプログラミングを進めることができる．また，右下のアイコンを押すときなどは，自動的に左下にタイマーが移動するので（試してみるとわかる），そのあたりのイライラもなかった．ただし，Mac のフルスクリーン機能を有効にすると，タイマーが別のウィンドウに飛んでしまう場合があるので，ここはちょっと微妙な感じだった．

Mobster : 離席できる

モブプログラミングは，全員参加を強制するものではなく，ナビゲーターは自由に離席することができるため，Mobster には「Away」ボタンがある．「Away」ボタンを押すと，Inactive に入るので，ドライバーとナビゲーターに選ばれなくなる．このあたりは，モブプログラミングに特化しているなと感じる．

Mobster : Learn to mob game

メイン画面に「Learn to mob game」というボタンがあり，もしかしたらゲーミフィケーションでモブプログラミングを学べるのかな？と思ったけど，特にそんなこともなく，普通に Mobster が動くだけで残念だった．もしくは他の用途がある？

メリット／デメリット

Mobster はモブプログラミングに特化したタイマーアプリなので，ドライバーとナビゲーターを登録できたり，タイマーがエディタ上に表示されたり，非常に便利に使えると思う．ただし，前回の記事にも書いた通り，僕のチームでは MDE (Mob Development Environment) を揃えてなく，ドライバーのマシンを使う運営を推奨しているので，ドライバーごとに Mobster の設定をするのが手間になり，結局使わなかった．もし今後，統一の MDE (Mob Development Environment) を用意する場合は，Mobster を使おうと思う．

ウェブタイマー

現在の運営だと，タイマー専用のマシンをディスプレイの横に置いて，そこでウェブタイマーを動かしている．シンプルな機能で十分なので，以下のウェブタイマーを使っている．

• https://tomato-timer.com/
• Timer | fvstr.jp