kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

Keycastr と VS Code Screencast Mode を使って Mac で入力したキー操作を画面表示する

ブラウザ/エディタ/ターミナルなどを使いながら「入力したキー操作」を画面表示したデモ動画を収録する機会がたまにある.今回は Mac で使える選択肢として「Keycastr」と「VS Code (Visual Studio Code) Screencast Mode」を紹介する.Mac で幅広く使うなら Keycastr を使って,エディタ操作に限定するなら VS Code Screencast Mode を使う.今すぐ必要じゃなくても「知っておくと便利な」ツールだと思う!

1. Keycastr

まず Keycastr を紹介する.brew でインストールしたらすぐに使える.

$ brew cask install keycastr

github.com

Keycastr を起動し,Mac のメニューバーに常駐している Keycastr のメニューから Start Casting を選べば,キー操作を画面表示できる.以下に iTerm2 で Linux コマンド(サンプル)を実行した画面を載せておく.

f:id:kakku22:20200605145611p:plain

要件次第では「ショートカット操作のみ」を表示したい場合もあると思う.Keycastr では Preferences にある Display only command keys を有効化すると,通常のキー操作は画面表示されず,Mac の Command に限定して画面表示できるようになる.例えば Command + A -> Command + C -> Command + V(全選択コピペ) や VS Code でよく使う Shift + Command + P(コマンドパレット) など.

f:id:kakku22:20200605150130p:plain

また Keycastr は,サイズや色などの設定をカスタマイズすることもできる.以下は極端な例として,Bezel Color を黄色にした.

f:id:kakku22:20200605150704p:plain

2. VS Code Screencast Mode

次に VS Code Screencast Mode を紹介する.VS Code ならデフォルトで使える機能となり,コマンドパレットで screencast と入力する.

f:id:kakku22:20200605151956p:plain

同じく Shift + Command + P(コマンドパレット) を画面表示すると,エディタにオーバレイされる.個人的には消えるまでの時間は短いと思う.なお,オーバレイする場所(高さ)は Vertical Offset 設定で変更することもできる.

f:id:kakku22:20200605152007p:plain

まとめ

「入力したキー操作」を画面表示したデモ動画を収録する場合「Keycastr」と「VS Code Screencast Mode」を知っておくと便利!Mac で幅広く使うなら Keycastr だけど,設定をデフォルト値にリセットしたり,カスタマイズした設定を保存する機能はなく,今後まだ改善される可能性もありそう.GitHub のリリース情報を確認しよう!

Dependabot の config.yml に「Automatic PR merging」を設定する

Dependabot を使うと「依存パッケージ」の更新を自動化できる.対応言語も幅広く,個人的には JavaScript / Ruby / Python / Docker をよく使っている.最高に便利なんだけど,例えば JavaScript などはリリース頻度が高く,すぐにプルリクエストが溜まってしまう(プルリクエスト数の制限はできる).最近は「Automatic PR merging(プルリクエスト自動マージ機能)」を使うことも多く,設定例を紹介する.

dependabot.com

Dependabot 設定画面

「Automatic PR merging」をすぐに試すなら設定画面を使う.true or false という単純な設定ではなく「ランタイム依存」と「開発依存」に対してアップデートレベルを設定できる.さらに特定のパッケージをホワイトリスト形式で設定することもできる.

  • Runtime dependency PRs to merge automatically(ランタイム依存)
    • None
    • Patch updates (security only)
    • Patch updates (all)
    • Minor updates
    • All updates
  • Development dependency PRs to merge automatically(開発依存)
    • None
    • Patch updates (security only)
    • Patch updates (all)
    • Minor updates
    • All updates
  • Whitelisted dependencies to merge automatically (all versions)

参考までに設定画面を載せておく.

f:id:kakku22:20200608102430p:plain

Dependabot config files

Dependabot には「config files」の仕組みもあり,リポジトリに .dependabot/config.yml を置いておくと設定ファイルを GitHub で管理できる.設定ファイルに「Automatic PR merging」を設定する場合は automerged_updates を使う.詳しくは以下の設定項目から選べる.

  • automerged_updates
    • dependency_type
      • development
      • production
      • all
    • update_type
      • security:patch
      • semver:patch
      • semver:minor
      • in_range
      • all
    • dependency_name

dependabot.com

設定例 1 : 全てのプルリクエストを自動マージする

サンドボックス環境など,全てのプルリクエストを自動マージしても大丈夫な場合は dependency_type と update_type に all を設定する.今回は JavaScript を前提にする.

version: 1
update_configs:
  - package_manager: javascript
    directory: /
    update_schedule: daily
    automerged_updates:
      - match:
          dependency_type: all
          update_type: all

設定例 2 : マイナーバージョンアップまではプルリクエストを自動マージする

基本的に「メジャーバージョンアップ」だと非互換な更新を含む可能性もあるため,例えば「マイナーバージョンアップまで」ならプルリクエストを自動マージするという戦略もある.その場合は update_type に semver:minor を設定する.

version: 1
update_configs:
  - package_manager: javascript
    directory: /
    update_schedule: daily
    automerged_updates:
      - match:
          dependency_type: all
          update_type: semver:minor

設定例 3 : 特定のパッケージに限定して自動マージする

例えば axios や react* など,特定のパッケージに限定して自動マージする場合は dependency_name にパッケージ名を設定する.ワイルドカードも使えるため,記述量を減らすこともできる.

version: 1
update_configs:
  - package_manager: javascript
    directory: /
    update_schedule: daily
    automerged_updates:
      - match:
          dependency_name: axios
      - match:
          dependency_name: react*
          update_type: semver:minor

まとめ

Dependabot の「Automatic PR merging」を使うとプルリクエストを自動マージできる.今回は「config files」の設定例を紹介した.

なお,自動テストがエラーになった場合にプルリクエストが自動マージされてしまうと困る.ドキュメントに書いてある通り,自動テストを設定している場合は,ステータスを確認する仕組みになっている.実際に CircleCI を使って,一時的に自動テストがエラーになるようにしても自動マージはされなかった.Dependabot will still automatically merge this pull request if you amend it and your tests pass. というコメントもある通り,自動テストを修正すればマージされる.今回は master ブランチ側でテストを直して,プルリクエストに @dependabot rebase とコメントしたらマージされた.

Dependabot will wait until all your status checks pass before merging.

f:id:kakku22:20200604113841p:plain

Dependabot 関連記事

kakakakakku.hatenablog.com

モノリポ時代に知っておくと便利な「git sparse-checkout」

今まで使っていなかった Git コマンドを学んでいく.今回は git sparse-checkout を試す.

git-scm.com

git sparse-checkout とは?

コマンド名にある sparse は「わずかな」という意味で,Git リポジトリの「一部」を取得できる.git clone --depth を使ってコミットを刈り取るのではなく,指定したディレクトリを取得する.モノリポ(モノレポ)構成のときに効果的に使える.git sparse-checkout は歴史的な変化もあり,今年になって改善されている.記事を検索すると Git 2.25 より前の git sparse-checkout を紹介した記事が多いように感じたため,今回は Git 2.26.2 を使って試した.

derrickstolee/sparse-checkout-example を使う

git sparse-checkout を試すために,そこそこ大きめな GitHub リポジトリを探していた.以下の GitHub Blog の記事を読んだところ git sparse-checkout を試す手順(Git 2.25 前提)と,サンプルリポジトリが載っていたため,今回は derrickstolee/sparse-checkout-example リポジトリ(モノリポ構成)を使うことにした.

github.blog

github.com

1. 既存リポジトリで git sparse-checkout を使う

まず,既存リポジトリ(git clone をした状態)で git sparse-checkout を使っていく.git clone をして,ファイル数をカウントすると 1585個 となる.ディレクトリ構成は GitHub Blog に載っている画像を見ればすぐ理解できる.tree で簡単に紹介すると,以下のようにモノリポ構成(2階層)になっている.例えば client/android ディレクトリや web/browser ディレクトリなど.

$ git clone git@github.com:derrickstolee/sparse-checkout-example.git
Cloning into 'sparse-checkout-example'...
remote: Enumerating objects: 21, done.
remote: Counting objects: 100% (21/21), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 1901 (delta 2), reused 11 (delta 1), pack-reused 1880
Receiving objects: 100% (1901/1901), 170.93 MiB | 2.56 MiB/s, done.
Resolving deltas: 100% (177/177), done.
Updating files: 100% (1560/1560), done.

$ cd sparse-checkout-example

$ find . -type f | wc -l
    1585

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
├── client
│   ├── README
│   ├── android
│   ├── electron
│   └── iOS
├── service
│   ├── README
│   ├── common
│   ├── identity
│   ├── items
│   └── list
└── web
    ├── README
    ├── browser
    ├── editor
    └── friends

さっそく,git sparse-checkout init --cone を実行して sparse-checkout を有効化する.--cone オプションはパターンマッチによりディレクトリ探索のパフォーマンスを改善するオプションとして付けておく.直後にファイル数をカウントすると,なんと 30個 に減っている.client/android ディレクトリや web/browser ディレクトリも除外されている.設定は .git/info/sparse-checkout ファイルにあり,意味としては「作業ディレクトリをルートにあるファイルに制限する」となる.

$ git sparse-checkout init --cone
 
$ find . -type f | wc -l
      30

$ tree -L 2
.
├── LICENSE.md
├── README.md
└── bootstrap.sh

$ cat .git/info/sparse-checkout
/*
!/*/

今のままだと重要なコードも除外されているため,例えば「Android アプリを開発するチーム」の場合は,git sparse-checkout set client/android を実行して,ディレクトリを設定できる.実際にファイル数は 56個 になり,client/android ディレクトリを参照できるようになる.

$ git sparse-checkout set client/android

$ find . -type f | wc -l
      56

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
└── client
    ├── README
    └── android

$ cat .git/info/sparse-checkout
/*
!/*/
/client/
!/client/*/
/client/android/

次に「フロントエンドを開発するチーム」の場合は,git sparse-checkout set service web/browser を実行する.すると service ディレクトリと web/browser ディレクトリを参照できるようになる.set は上書きする仕様になっているため,既に client/android ディレクトリは参照できなくなっている.さらに .git/info/sparse-checkout ファイルを見なくても git sparse-checkout list を使えばディレクトリを確認できる.

$ git sparse-checkout set service web/browser

$ find . -type f | wc -l
     636

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
├── service
│   ├── README
│   ├── common
│   ├── identity
│   ├── items
│   └── list
└── web
    ├── README
    └── browser

$ git sparse-checkout list
service
web/browser

なお,Git 2.26 から git sparse-checkout add も使えるため,ディレクトリを追加するときに毎回 git sparse-checkout set をし直していた手順をシンプルにできる.次の手順で add を使っていく.

2. git clone --filter=blob:none --no-checkout と組み合わせる

git clone をするときに --filter=blob:none オプションを付けると,オブジェクトのダウンロードをせずに clone できる(Partial Clone とも言う).さらに --no-checkout オプションを付けると,チェックアウトをせずに clone できる.新しくリポジトリを取得する場合は git clone --filter=blob:none --no-checkout と組み合わせるとオーバーヘッドを減らして,モノリポを管理できる.

$ git clone --filter=blob:none --no-checkout git@github.com:derrickstolee/sparse-checkout-example.git
Cloning into 'sparse-checkout-example'...
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 373 (delta 1), reused 7 (delta 1), pack-reused 360
Receiving objects: 100% (373/373), 76.78 KiB | 644.00 KiB/s, done.
Resolving deltas: 100% (18/18), done.

$ cd sparse-checkout-example

$ find . -type f | wc -l
      29

同じように git sparse-checkout init --cone を実行して sparse-checkout を有効化する.今回は add を使って client/android ディレクトリと service ディレクトリと web/browser ディレクトリを参照できるようにする.git sparse-checkout の手順は同じだけど,オブジェクトのダウンロードを後回しにできる点はメリットと言える.

$ git sparse-checkout init --cone

$ git sparse-checkout add client/android

$ git sparse-checkout add service web/browser

$ find . -type f | wc -l
     667

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
├── client
│   ├── README
│   └── android
├── service
│   ├── README
│   ├── common
│   ├── identity
│   ├── items
│   └── list
└── web
    ├── README
    └── browser

まとめ

今まで使っていなかった Git コマンドとして,今回は git sparse-checkout を試した.モノリポ(モノレポ)構成のときに効果的に使える.もし新しくリポジトリを取得する場合は git clone --filter=blob:none --no-checkout と組み合わせるとオーバーヘッドを減らして,素早く clone できる点も覚えておくと良さそう!

Slack で /zoom コマンドを使って Zoom Meeting を作る

Slack に「Zoom App」をインストールすると /zoom コマンドを使って Zoom Meeting を簡単に作れる.Slack から「Join」ボタンを押せばすぐに Zoom Meeting に参加できるため,例えば「クイックコール」をするときなど,便利に使える.

f:id:kakku22:20200601181118p:plain

インストール

「Zoom App」は Slack の「App Directory」からインストールできる.なお,インストール後に /zoom コマンドを使うと,初回は「👉Authorize Zoom」と表示される.Zoom にログインをして権限を付与しておく.

slack.com

/zoom meeting [topic] コマンド

例えば /zoom meeting group1 のように「トピック名」を指定すると,1 Slack Channel の中に複数の Zoom Meeting を作れる.

うまく活用すると「グループディスカッション」にも使える.Zoom に「ブレイクアウトルーム機能」はあるけど,Slack を軸にすることにより,Zoom Meeting ホスト側のセッション時間を気にする必要がなく,無料アカウントで問題なく運用できるようになる.当然ながら「40分」という時間制限はあるけど,もう1度 /zoom コマンドを使って別の Zoom Meeting に参加し直せば OK!

f:id:kakku22:20200601180904p:plain

コマンド一覧

個人的に /zoom コマンドと /zoom meeting [topic] コマンド以外は使わないけど,/zoom help でコマンド一覧を確認できる.

/zoom
/zoom meeting [topic]
/zoom join [meeting id/personal link name]
/zoom join me
/zoom call [@contact/phone number]
/zoom config
/zoom logout

まとめ

Slack に「Zoom App」をインストールすると /zoom コマンドを使って Zoom Meeting を簡単に作れる.「クイックコール」をしたり「グループディスカッション」をしたり,幅広く使えるため,入れておくべし!

リモートモブプログラミングで Git Handover をシュッと実現する「mob」コマンド

「モブプログラミング」を採用すると「全員で同じタスクに取り組む (WIP 1)」ため,複雑な Git ブランチ戦略は必要なくなる.例えば master ブランチと develop ブランチだけで運用することもできる.今回紹介する mob コマンドを使うと,モブセッションで繰り返し行なう「ドライバー(タイピスト)交代」をシュッと実現できる.特に「リモートモブプログラミング」だと GitHub に git push をしてドライバーを交代する(Git Handover と言う)ため,mob コマンドを使うと便利!

mob.sh

インストール

mob コマンドは brew コマンドで簡単にインストールできる.そこそこ頻繁にリリースされているため,定期的に brew upgrade をしておくと良さそう.今回の記事を書いてる間にも v0.0.13 ➔ v0.0.17 にバージョンアップしていた.

$ brew install remotemobprogramming/brew/mob
$ mob version
v0.0.13

$ brew upgrade remotemobprogramming/brew/mob
$ mob version
v0.0.17

なお mob コマンドは GitHub で OSS になっている.Go で実装されている!

github.com

mob : 基本コマンド

基本的に以下の「基本コマンド 3個」を使えば OK!簡単にワークフローを図解した(GitHub は例として).

  • mob start ... 「モブセッション」を開始する
  • mob next ... 次のドライバーに Git Handover をする
  • mob done ... 「モブセッション」を終了する

f:id:kakku22:20200531164129p:plain

1. mob start

「モブセッション」を開始するときに mob start を実行する.Git リポジトリに remote 設定をしておく必要があるため,リポジトリを clone しておく.mob start を実行すると,自動的に mob-session ブランチが作られて git push まで実行される.

(master) $ mob start
 ✓ git fetch --prune
 ✓ git pull --ff-only
 > create mob-session from master
 ✓ git checkout master
 ✓ git merge origin/master --ff-only
 ✓ git branch mob-session
 ✓ git checkout mob-session
 ✓ git push --no-verify --set-upstream origin mob-session
 > you are mob programming

(mob-session) $ 

2. mob next

開発を進めて,ドライバーを交代するときに mob next を実行する.すると,自動的に git add と git commit と git push が実行される.コミットメッセージはデフォルトだと mob next [ci-skip] となる.最後に master ブランチに切り替わる.

(mob-session) $ mob next
 ✓ git add --all
 ✓ git commit --message "mob next [ci-skip]" --no-verify
 ✓ git push --no-verify origin mob-session
 ✓ git checkout master

(master) $ 

3. mob start

ドライバーを交代したら,もう1度 mob start を実行する.すると,自動的に mob-session ブランチに切り替わり,開発を進められる.モブセッションでは,基本的に mob start と mob next を繰り返す.

(master) $ mob start 10
 ✓ git fetch --prune
 ✓ git pull --ff-only
 > rejoining mob session
 ✓ git branch -D mob-session
 ✓ git checkout mob-session
 ✓ git branch --set-upstream-to=origin/mob-session mob-session
 ✓ 10 minutes timer started (finishes at approx. 11:00)
 > you are mob programming
xxxxxxx 5 minutes ago <kakakakakku>

(mob-session) $ 

なお mob start 10 のように引数 minutes を指定すると,自動的にタイマーが起動する.指定した時間が経過すると,Mac の場合は AppleScript (osascript) を使って通知されるようになっている.さらに say コマンドを使って mob next と読み上げてくれる.例えば Mobster など,モブプログラミングに特化したタイマーアプリを使うこともできるけど,mob コマンドに同梱されているのは便利だと思う.

f:id:kakku22:20200531170258p:plain

4. mob done

「モブセッション」を終了するときに mob done を実行する.挙動としては mob-session ブランチを git push をして,さらに master ブランチに git merge までしてくれる.最後に 👉 git commit -m 'describe the changes' と表示されている通り,最終的な git commit はドライバーが行なう.個人的に使うなら mob done は使わずにプルリクエストを作る運用にするかなぁー.

(mob-session) $ mob done
 ✓ git fetch origin --prune
 ✓ git add --all
 ✓ git commit --message "mob next [ci-skip]" --no-verify
 ✓ git push --no-verify origin mob-session
 ✓ git checkout master
 ✓ git merge origin/master --ff-only
 ✓ git merge --squash --ff mob-session
 ✓ git branch -D mob-session
 ✓ git push --no-verify origin --delete mob-session
 👉 git commit -m 'describe the changes'
 
 (master) $ git commit -m'Well done 👍'

 (master) $ git push

Tips 1 : 環境変数を使う

mob config を実行すると,mob コマンドの挙動を決めている環境変数の値を確認できる.

$ mob config
MOB_BASE_BRANCH=master
MOB_WIP_BRANCH=mob-session
MOB_REMOTE_NAME=origin
MOB_WIP_COMMIT_MESSAGE=mob next [ci-skip]
MOB_VOICE_COMMAND=say
MOB_NEXT_STAY=false
MOB_START_INCLUDE_UNCOMMITTED_CHANGES=false
MOB_DEBUG=false

export で上書きできるため,例えば MOB_WIP_BRANCH を設定すれば mob-session 以外のブランチ名も使える.MOB_WIP_COMMIT_MESSAGE を設定すれば mob next [ci-skip] 以外のコミットメッセージも使える. direnv などを使って全員同じ環境変数を export できるようにしておくと良さそう.

$ export MOB_WIP_BRANCH=wip
$ export MOB_WIP_COMMIT_MESSAGE=mob next

(master) $ mob start
overriding MOB_WIP_BRANCH=wip
overriding MOB_WIP_COMMIT_MESSAGE=mob
 ✓ git fetch --prune
 ✓ git pull --ff-only
 > create wip from master
 ✓ git checkout master
 ✓ git merge origin/master --ff-only
 ✓ git branch wip
 ✓ git checkout wip
 ✓ git push --no-verify --set-upstream origin wip
 > you are mob programming

(wip) $ 

Tips 2 : Zoom で画面共有をする

mob share もしくは mob start 10 share のように share を付けると,Zoom で画面共有を設定するダイアログを表示できる.

$ mob share
$ mob start 10 share

f:id:kakku22:20200531172248p:plain

なお share を使う場合は Zoom で「画面共有を開始/停止 (Shift + Command + S)」の「グローバルショートカット」を有効化しておく.

f:id:kakku22:20200531172445p:plain

とは言え,今回使った mob コマンド v0.0.17 は share に対応しているけど,次にリリースされる v0.0.18 では mob share は削除されてしまう.そして mob start 10 share も DEPRECATED になり,将来的に削除されてしまう.実際に使う場面はなさそう.詳しくは GitHub の Releases を見てもらえればと!

まとめ

mob コマンドを使うと Git Handover をシュッと実現できる.特に「リモートモブプログラミング」をするときに便利!

関連記事

慣れた開発環境を使うことを優先し,個人的に Git Handover はリモートモブプログラミングじゃなくても使っていた.詳しくは2年前に公開した資料に載せてある.合わせて読んでもらえると良さそう!

kakakakakku.hatenablog.com

f:id:kakku22:20200531172758p:plain