Bot と一緒にインタラクティブに GitHub を学べる GitHub Learning Lab は素晴らしい学習体験だった

新しく技術を学ぶときに「どんな第一歩」を踏み出すか．僕は「体系的に学ぶ」ことが好きで，技術書を読むことが多い．全体感を把握することで安心できる性格であることも関係していると思う．さらに「実際に体験する」ことも好きで「学習コンテンツ」をよく使う．今までもチュートリアルサイト，Katacoda，YouTube など，いろいろ試してブログにまとめてきた．また現在は講師という仕事柄もあり，どのように「学習コンテンツ」を構成すると学習体験を高められるのか？という部分に強い興味関心があることも関係している．

GitHub Learning Lab とは？

今回は GitHub から提供されているプラットフォーム「GitHub Learning Lab」を紹介する．GitHub / GitHub Pages / GitHub Actions など，GitHub 関連のコースが揃っているし，さらに HTML / Python / React / CircleCI など，GitHub 以外の幅広いコースも公開されている．誰でもコースを作って公開できるという仕組みだからこそとも言える．そして「GitHub Learning Lab」が素晴らしいのは「Issue や Pull Request など GitHub の機能を活用した構成になっている点」と「Bot を活用したインタラクティブな構成になっている点」だと感じた．本当に素晴らしい学習体験だった👏

skills.github.com

（2022年6月に GitHub Skills に移行されました）

Introduction to GitHub コース

今回は GitHub の基本的な機能を学べる「Introduction to GitHub」コースを受講しながら「GitHub Learning Lab」の素晴らしさを伝えていく．まず「Introduction to GitHub」コースは「計8ステップ」で構成されていて，Issue と Pull Request を中心に学べる．

• ステップ 1「担当者になろう」
• ステップ 2「GitHub Pagesを有効化しよう」
• ステップ 3「Issueを閉じよう」
• ステップ 4「ブランチを作ろう」
• ステップ 5「ファイルをコミットしよう」
• ステップ 6「プルリクエストをオープンしよう」
• ステップ 7「レビューに対応しよう」
• ステップ 8「プルリクエストをマージしよう」

github.com

（2022年6月に GitHub Skills に移行されました）

なお，コースを完了すると GitHub Pages で配信されたサイト（reveal.js を使ったプレゼンテーション資料）にアクセスできるようになる．あくまで題材なので GitHub Pages の詳細まで学ぶなら「GitHub Pages」コースを受講すると良さそう．

セットアップの選択肢

まず「Start free course」ボタンを押してセットアップをする．リポジトリ公開設定／言語設定／Git 操作ツール設定を以下のように選べる．一部のコースは日本語に対応しているし，特に「Git 操作ツール」を3種類から選べるのは良かった．特に環境設定などを必要とせず，全て GitHub Web UI で学べるため，エンジニアじゃなくても学びやすくなる．今回は「日本語」と「GitHub Web UI」の組み合わせで進めていく．

• Public / Private
• 英語 / 日本語 など
• GitHub Web UI / CLI / VS Code

「Begin Introduction to GitHub」ボタンを押すと，コースで使うリポジトリ github-slideshow が自動的に作られる．必要なコード関連も初期コミットされている．さっそく進めていく．

Issue を活用した手順

「GitHub Learning Lab」では，Issue と Pull Request を活用して手順を進めていく．以下のように github-learning-lab Bot によって Issue が自動的に作られる．

まず「1. 担当者になろう」では，Issue の「Assignees 機能」を学ぶ．実際に Assignees に自分自身を設定すると，github-learning-lab Bot がそれを検知し，Issue に次のステップの手順をコメントしてくれる．できた！という達成感を得られるし，一歩一歩インタラクティブに進められる安心感もある．

次にリポジトリ設定から GitHub Pages を有効化したり，Issue を Close する手順を試すと，また次の Issue が自動的に作られる．

適材適所に YouTube も活用する

続いて「4. ブランチを作ろう」では，GitHub Flow とは何か？など，最低限の基礎知識も学べるようになっている．Issue に書いてある文章を読むだけでは理解しにくいところもあり，YouTube を観ながら理解度を深められるようになっている．YouTube など，適材適所に学習コンテンツを組み合わせている点もよく考えられていると思った．

Bot と Pull Request を作り上げていく

最後に「6. プルリクエストをオープンしよう」では，実際に Pull Request を作る．すると github-learning-lab Bot が「Markdown の5行目を修正しよう！」というコメントをしてくれる．実際に Markdown を修正してコミットをする「7. レビューに対応しよう」は，Bot（講師）とペア作業をしているような感覚で，実際に GitHub を使った開発フローを体験できた．

まとめ

「GitHub Learning Lab」の学習コンテンツは Issue や Pull Request など GitHub の機能を活用した構成になっている．そして Bot を活用したインタラクティブな構成になっているため，一歩一歩学べる素晴らしい学習体験だった．今まで何度も Git / GitHub を教えたり，学習コンテンツも作ってきたけど，今後は「GitHub Learning Lab」をペア作業で進めるスタイルも試してみたいと思う．また GitHub Actions など，最近使うようになった機能も学べるため，僕自身も「GitHub Learning Lab」を活用していくぞ！

リモートモブプログラミングで意識するべき15個の原則とは /「Remote Mob Programming」を読んだ

最近では，場所に制限されずに実施できる「リモートモブプログラミング」を採用しているチームも多いと思う．もともと「モブプログラミング」に慣れているチームなら，急に「リモート」に移行しても「特に変わらなかった」と感じるかもしれないけど，慣れていないチームだと苦労もあったりする．そして最近は相談を受ける場面も増えてきた．今回は「リモートモブプログラミング」で意識するべき原則を学べる本「Remote Mob Programming」を紹介する．

Remote Mob Programming

本書は Leanpub で購入できる．とは言え，内容はウェブサイトに無料公開されているため，最低価格は無料になっている．僕はウェブサイトとほぼ同じだと気付かず，推奨価格の $9.99 で購入したけど，正直購入しなくても良いと思う．著者に感謝の気持ちを伝えるなら購入を！

• MINIMUM PRICE : Free!
• SUGGESTED PRICE : $9.99

leanpub.com

以下のウェブサイトに無料公開されている！読むべし！

www.remotemobprogramming.org

目次

本書には「リモートモブプログラミング」で意識するべき原則が「計15個」載っている．「リモート」に限らず重要な原則も載っているため，今後モブプログラミングを採用するチームにも参考になる．なお，正式な日本語訳はなく，個人的に載せているため，参考程度にしてもらえればと！今回は個人的に気になった原則を紹介する．

• Remote Everybody（全員リモート）
• Camera Always On（常時カメラ ON）
• Regular On-Site Meetings（定期的なオンサイトミーティング）
• Small Team（小さなチーム）
• Same Time（同じ時間）
• Typist and the Rest of the Mob（タイピストと残りのモブ）
• Screen Sharing（画面共有）
• 10 Minute Intervals（10分インターバル）
• Git Handover（Git 引き継ぎ）
• Group Decisions（グループで決める）
• Constant Momentum（継続的な勢い）
• Learn from the Team（チームから学ぶ）
• Trust（信頼）
• Save the Planet（地球を守る）
• Dine with your Family（家族で食事）

Remote Everybody（全員リモート）

リモートモブプログラミングでは「全員リモート」を前提にする．同じ部屋に数名いると「情報の非対称性」の問題に繋がってしまう．リモートモブプログラミングを使えば「まるで同じ部屋にいるような感覚」になる！と書いてある．

リモートモブプログラミングに限った話ではなく，リモートワーク全般でよく聞く話だし，重要だと思う．僕もリモートモブプログラミングを実施するときは，できる限り「ローカルさ」をなくしていくように意識している．

Camera Always On（常時カメラ ON）

言葉だけではなく，ジェスチャーなど「ノンバーバル（非言語）コミュニケーション」を意識することが重要で「常時カメラ ON」にする．最初は違和感を感じるけど，慣れれば「同じ部屋にいるような感覚」にもなる！と書いてある．

個人的には賛成だし，実際にリモートモブプログラミングに実施するときは必ずカメラは ON にしている．とは言え「ネットワーク回線を圧迫」したり「カメラ ON に抵抗を感じる環境」も考慮すると，必須にする必要はないように思う．また「画面共有」を見ることに集中するため，本書に書いてある「視線が合う」という体験はあまりなさそう．なお，Zoom だと画面共有中に「左右表示モード」にすれば，画面共有とカメラを並べられるため，便利！

Small Team（小さなチーム）

リモートだと，基本的に複数人で喋るのは難しく，カブらないように意識的にタイミングを見計らったりする．だからこそ，人数が多くなると，集中力を維持しにくくなってしまう．本書では「4人」を推奨！と書いてある．

個人的な経験からも「4人」を推奨する．「5人」だと窮屈に感じてしまう．とは言え，アジャイル開発で4人以上の場合もあるから，意図的にミュートを活用したり，適切にコミュニケーションを取れるスタイルを確立すると良いと思う．例えば，Zoom で「挙手機能」を使ったり，実際にカメラに挙手をしてジェスチャーで伝えたり，Fist of Five Voting で合意形成をしたり．

Screen Sharing（画面共有）

ドライバー（タイピスト）の画面を共有し，全員同じ画面を見るようにする．通知を無効にしたり，集中力を維持する工夫もする！と書いてある．また「コラボレーション IDE はコラボレーションを悪化させた」という話もあった．

まず，モブプログラミング未経験者にトレーニングをすると，作業を効率的に分割しようとする人が多かったりする．例えば「僕 Google 検索してみますー！進めておいてもらえるとー！」など．そうすると戻ってきたときにリズムを止めてしまうことになるため，ドライバー（タイピスト）の操作を尊重する意識をして，全員で画面共有を見て検索をするように伝えている．

また，前に AWS Cloud9（コラボレーション IDE としても使える）でモブプログラミングを試したけど「全員同じ画面を見ているようで見ていなかった（ドライバーがどこを見ているのか共有できなかった）」という課題があり，難しかったため，本書に書かれている話も納得できる．あと最近試している Visual Studio Live Share にもコラボレーション IDE の側面がある．

visualstudio.microsoft.com

10 Minute Intervals（10分インターバル）

目標を達成するまでに数時間必要になる場面もあり，様々なインターバル時間を試したけど「10分」が適切である！と書いてある．

今まで読んできたモブプログラミング関連の本にも最初は短くはじめるべきと書いてあるし，長くても 1 ポモドーロ（25分）で交代すると良いと思う．当然ながら，コードを書くのには短すぎるけど，集中力を維持するには十分だし，なんとなく時間が過ぎてしまった！という状況を減らすために細かく作業を分割する意識も強まる．画面共有をするちょっとした時間もオーバーヘッドになるため，できる限りスムーズにできるように練習しておくのも良いと思う．

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Git Handover（Git 引き継ぎ）

リモートモブプログラミングだと，物理的にキーボードを渡すことができないため，作業用の Git ブランチを使って引き継ぎをする．特に Git 操作で時間を取られたり，コミットメッセージに悩む時間もオーバーヘッドになるため，迅速に行うべき！と書いてある．

簡単に言えば「git pull で始まり git push で終わる」となる．前に紹介した mob コマンドはまさに「Git Handover（Git 引き継ぎ）」を実現するツールだし，最近使っているけど，非常に便利だと思う．

kakakakakku.hatenablog.com

まとめ

今回は「リモートモブプログラミング」で意識するべき原則を学べる本「Remote Mob Programming」を紹介した．ウェブサイトに無料公開されているので，興味があったら読んでみると良いかと！もしもう1個原則を追加するとしたら，僕なら「小さな成功を喜ぶ！やったー！」を追加したいと思う．やったー！やったー！

www.remotemobprogramming.org

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 コマンド（サンプル）を実行した画面を載せておく．

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

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

2. VS Code Screencast Mode

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

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

まとめ

「入力したキー操作」を画面表示したデモ動画を収録する場合「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)

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

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.

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 を使って試した．

• Git 1.7
  • 2010年2月 リリース
  • git sparse-checkout 導入
• Git 2.25
  • 2020年1月 リリース
  • git sparse-checkout 機能改善
  • Highlights from Git 2.25 - The GitHub Blog
• Git 2.26
  • 2020年3月 リリース
  • git sparse-checkout add 追加
  • Highlights from Git 2.26 - The GitHub Blog

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 できる点も覚えておくと良さそう！