kakakakakku blog

Weekly Tech Blog: Keep on Learning!

GitHub Actions に入門するなら GitHub Learning Lab の Hello World コースを受講しよう

GitHub を学ぶときに「GitHub Learning Lab」を使うと便利!という紹介記事を6月に書いた.最近 GitHub Actions を使う機会があり,入門するために「GitHub Learning Lab」「GitHub Actions: Hello World」コースを受講した.今回も非常に良かった!

kakakakakku.hatenablog.com

GitHub Actions: Hello World

「GitHub Actions: Hello World」GitHub Actions を学ぶ入門コースとなる.現在はまだ日本語に翻訳されてなく,英語を選択する必要はあるけど,Bot / Issue / Pull Request を活用したインタラクティブな構成になっていて,楽しく学べる.以下のステップを進めていくことになり,最終的には GitHub Actions を使って,Docker イメージをビルドして実行できるようになる.

  • Step 1 : Add a Dockerfile
  • Step 2 : Add an entrypoint script
  • Step 3 : Add an action.yml file
  • Step 4 : Start your workflow file
  • Step 5 : Run an action from your workflow file
  • Step 6 : Trigger the workflow
  • Step 7 : Incorporate the workflow

lab.github.com

セットアップ

まず「Start free course」ボタンを押してセットアップをする.今回はリポジトリ公開設定として Private を選ぶ.すると,自動的にコースで使うリポジトリ hello-github-actions が作られる.

f:id:kakku22:20200707004432p:plain

さっそく Issue に Bot から Step 1 の手順がコメントされる.進めていくぞ!

f:id:kakku22:20200707004504p:plain

Step 1 : Add a Dockerfile

最初に Issue を読みながら GitHub Actions の概要を学んでいく.「アクション」には「Docker Container (Linux)」「JavaScript (Linux, MacOS, Windows)」の2種類があり,今回は「Docker Container」を使っていく.

help.github.com

まず,first-action ブランチを作り,以下のように action-a/Dockerfile を実装したら Pull Request を作る.GitHub の基本的な操作は書いてなく,慣れていない場合は前提コース「Introduction to GitHub」コースを受講しておく必要がありそう.

FROM debian:9.5-slim

ADD entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Step 2 : Add an entrypoint script

次に ENTRYPOINT に指定したスクリプト action-a/entrypoint.sh を実装する.単純に echo するだけではなく,GitHub Actions の inputs シンタックスを試すため,環境変数も含めておく.

#!/bin/sh -l

sh -c "echo Hello world my name is $INPUT_MY_NAME"

Step 3 : Add an action.yml file

今度は GitHub Actions のアクションを定義していくため action.yml を作る.ポイントは runs シンタックスを使って Dockerfile を指定している点と,inputs シンタックスを使って環境変数のデフォルト値を設定している点になる.branding シンタックスはアクションを GitHub Marketplace に公開するときに使えるアイコン設定(Feather から選べる)となり,今回は関係なさそう.

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
  MY_NAME:
    description: "Who to greet"
    required: true
    default: "World"

runs:
  using: "docker"
  image: "Dockerfile"

branding:
  icon: "mic"
  color: "purple"

help.github.com

Step 4 : Start your workflow file

アクションを定義したため,次にワークフローを定義していく.設定ファイルは .github/workflows/main.yml に置く.

  • name : ワークフロー名
  • on : ワークフローを実行するトリガー設定
  • jobs : アクション設定
    • uses: actions/checkout@v1 : リポジトリをチェックアウトする(現在は既に v2 もリリースされている)
name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: ./action-a
        with:
          MY_NAME: "Mona"

docs.github.com

github.com

Step 5 : Run an action from your workflow file

実際にワークフローを確認すると,正常に実行されていた.

Step 6 : Trigger the workflow

標準出力に Hello world my name is Mona と表示されていた.

f:id:kakku22:20200707004724p:plain

Step 7 : Incorporate the workflow

最後は Pull Request を master ブランチに Merge する.

最終的に Issue / Pull Request は以下のようになっていた.今回も非常に良かった!楽しかった!

f:id:kakku22:20200707004739p:plain

まとめ

「GitHub Learning Lab」「GitHub Actions: Hello World」コースを受講して,GitHub Actions に入門した.一歩一歩インタラクティブに進めることで理解度を高められる点は,やはり「GitHub Learning Lab」の最大のメリットだと思う.実は「GitHub Learning Lab」には,コースとドキュメントをまとめた「Learning Path」という仕組みもあり,例えば「DevOps with GitHub Actions」という Learning Path もある.「Publish to GitHub Packages」コースは特に気になる!

  1. GitHub Actions: Hello World
  2. GitHub Actions: Continuous Integration
  3. GitHub Actions: Publish to GitHub Packages
  4. GitHub Actions: Continuous Delivery with Azure
  5. GitHub Actions: Continuous Delivery with AWS
  6. GitHub Actions: Writing JavaScript Actions
  7. GitHub Actions: Write Docker container actions
  8. GitHub Actions: Using GitHub Script
  9. Migrating from Azure Pipelines to GitHub Actions
  10. Migrating from Jenkins to GitHub Actions
  11. Migrating from CircleCI to GitHub Actions

lab.github.com

Woody もパネラーに!Mob Programming Gathering 2020 に参加した

6/26 にリモート開催された「Mob Programming Gathering 2020」に参加した.イベントは「Agile New England」コミュニティによって開催された.なお,開催時間は 12:00 - 14:30 EDT となり,日本時間だと 1:00 - 2:30 JST だから少し仮眠をしてから参加した.

mobprogrammingnewengland.com

YouTube 動画

イベントは Zoom で開催された.参加者は観測できた範囲だと「120人 - 160人」だった.Zoom レコーディングはもう YouTube に公開されているので,興味があったら観てみると良いかと!

www.youtube.com

スピーカー

今回は「パネルディスカッション形式」で進行した.モデレーターとパネラーは以下の通り.デザイナーやテストコンサルタントなど,モブプログラミングを使っている領域の幅広さも特徴的だったと思う.そして!なんと言ってもモブプログラミングを世界に広めたと言われる Woody Zuill もパネラーとして参加されていて,ライブに参加できて本当に嬉しかった.

f:id:kakku22:20200703183945p:plain

Mob Programming Gathering 2020 に参加して

通常のプレゼンテーションとは違ってスライドがなく,聞き違えている部分もあると思うけど,イベントに参加して,印象に残った話をまとめておく.特に Zoom コメントは YouTube に公開されてなく,興味深かった情報もあったため,合わせてまとめる.

モブプログラミングを普及していく

序盤に「どのようにモブプログラミングを普及していくか?誘惑していくか?」というテーマがあり,モブプログラミングを普及するときに「ガラスでセパレートされた部屋」を使うことにより,別の部屋からモブプログラミングをしている姿が見えるようにしたという話があった.自分たちと違うスタイルであることを見せることにより,興味を持ってもらえたという話は面白かった.

また BDD (Behavior Driven Development) を採用しているチームでは「部屋にお菓子をたくさん置いておく」ことで,お菓子を食べに来るときに要求仕様を整理するセッションに参加してもらったという話もあった.お菓子は正義!

モブプログラミングを機能させる

次に「どのようにモブプログラミングを機能させるか?」というテーマでは,ドイツ語を使うチームに新しくハンガリー語を使うメンバーが新しく入ったときに,オンボーディングも含めて共通言語がなかったことに苦労したという話だった.最終的には共通言語として英語を使うことにして,うまくモブプログラミングを機能させられるようになったということだった.

メンバーを固定するべき?最大人数は?

参加者から「メンバーを固定するべきか?(Fixed Team と聞こえた)」という質問があった.知識を共有できることに価値があり,ホワイトボードに情報を書き出すとしても,理解するのは簡単ではないため,固定すると良いという話に聞こえた.しかし DevOps / Database / Testing など,技術横断的な部分に不足を感じた場合はチームを広げていくのも良いとのこと.

さらに「では最大人数は?」というテーマに繋がり,「3人以上」というよく聞く話以外に「7人」「14人」でも良いし,流石に「20人」は多かったという話もあった.個人的な経験だと「6人」で限界だと思っていたため「14人」には驚く.

別の観点としては,モブを部分的に分割する「Swarming Patterns」の話も出ていた.Joe Yoder の論文があり,チャットに URL が流れていた.また共著者の Danijel Arsenovski のスライドも紹介されていた.気になるし今度読んでみよう!

www.slideshare.net

モブプログラミングを教える

後半では参加者から「どうやってモブプログラミングを教えれば良いか?」という導入に関する質問があった.簡単なタスクから始めたり,リリース前のテストから始めたり,可能ならコーチを雇ってしまうというアドバイスもあった.チャットには仕事のコードを書くんじゃなくて CodeKata で練習しているというアドバイスも出ていた.特に Woody は「モブは仕事をするスタイルにオプションを与えることだから何にでも適用できる」と言っていて,本質的にはその通りだなと思う.

codekata.com

まとめ

日本時間だと深夜帯で少し厳しかったけど,6/26 にリモート開催された「Mob Programming Gathering 2020」に参加した.モブプログラミング(モブワーク)をしたり,実際に教えたりしている立場として,海外のイベントに参加してみたかった.今回はパネルディスカッションで,多くのトピックに対して,ロールの異なるパネラーから経験談が聞けて面白かった.特に Woody Zuill の話をライブで聞けたことは思い出になったし,Woody の強調して使っていた High Level CollaborationBetter Decision, Better ExperienceSustainability という言葉に今もまだ興奮している.参加して良かった!

mobprogrammingnewengland.com

Hugo の OGP 画像を自動生成できる「tcardgen」を試した

Twitter などソーシャル上でブログ記事に興味を持ってもらうために「OGP 画像」を設定することは重要で,必ず何かしらを設定するようにしている.代表的なブログプラットフォームだと,デフォルト画像だけじゃなく,記事からリッチな OGP 画像を自動生成できたりもする.

Hugo だと

「ブログメンタリング」をしていると Hugo を使っている人も多く「OGP 画像を必ず付けましょう!」とアドバイスをすることがある.Hugo だとテンプレートに og:image が含まれていることはあるけど,デフォルト画像になってしまうため,記事から OGP 画像を自動生成したい Hugo ユーザーもいると思う.

Twitter Card Image Generator (tcardgen)

今回は「Twitter Card Image Generator (tcardgen)」を紹介する.tcardgen コマンドを使うと,Hugo の「Front Matter(記事と一緒に記述するパラメータ情報)」から OGP 画像を自動生成できる.まだリリースされたばかりということもあり,Go の実装を読みながら試した部分もあったけど,とても便利だと思う.Hugo ユーザーに喜ばれそう!

github.com

1. 準備する

tcardgen コマンドは go get でインストールできる.現状は tcardgen --version のようなオプションは実装されていなかった.

$ go get github.com/Ladicle/tcardgen

README.md を参考に Kinto フォントもダウンロードしておく.今回は検証用の Hugo 環境を使って(実は持っている!)フォントを static/fonts/kinto/ に保存しておく.Hugo ディレクトリ配下に保存しなくても良さそう.

github.com

2. テンプレート画像を作る

次に「テンプレート画像」を作る.今回は Keynote で雑に作った.驚くほどデザインセンスがなく,ヒドイ仕上がりになってしまった(笑)サイズは examples を参考に 横 1200 px / 縦 628 px にした.作ったら static/ogp/template.png として保存しておく.

f:id:kakku22:20200702142114p:plain

3. OGP 画像を自動生成する

サンプル記事として content/tcardgen.md を作って,以下のように Front Matter を書いた.

---
title: "Hugo の OGP 画像を自動生成できる「tcardgen」を試した"
date: 2020-07-02T00:00:00+09:00
author: ["kakakakakku"]
categories: ["Hugo"]
tags: ["Hugo", "Tools"]
draft: true
---

さっそく tcardgen コマンドを実行する.実行時にはオプションとして--fontDir(フォントディレクトリ)」--outDir(アウトプットディレクトリ)」--template(テンプレート画像)」を指定する.

$ tcardgen \
    --fontDir static/fonts/kinto \
    --outDir static/ogp \
    --template static/ogp/template.png \
    content/tcardgen.md

Load fonts from "static/fonts/kinto"
Load template from "static/ogp/template.png" directory
Success to generate twitter card into static/ogp/tcardgen.png

自動生成した static/ogp/tcardgen.png を確認すると,ちゃんと OGP 画像ができている.おおおおお!

f:id:kakku22:20200702142142p:plain

4. カスタマイズする

tcardgen コマンドはデザインをカスタマイズできる.具体的には「色」「位置」「サイズ」などを自由に決められる.今回は static/ogp/tcardgen.yaml を以下のようにした.「タイトル」「アカウント名」「タグ」のデザインをカスタマイズしている.

title:
  start:
    px: 126
    pY: 180
  fgHexColor: "#333333"
  fontSize: 65
  fontStyle: Regular
info:
  fgHexColor: "#FF6600"
tags:
  fgHexColor: "#000000"
  bgHexColor: "#FFFF33"
  fontSize: 50
  boxSpacing: 10

tcardgen コマンドにオプションとして--config(設定ファイル)」も追加で指定する.

$ tcardgen \
    --fontDir static/fonts/kinto \
    --outDir static/ogp \
    --template static/ogp/template.png \
    --config static/ogp/tcardgen.yaml \
    content/tcardgen.md

Load fonts from "static/fonts/kinto"
Load template from "static/ogp/template.png" directory
Success to generate twitter card into static/ogp/tcardgen.png

デザインセンスがなく,よりヒドイ仕上がりになってしまったけど,ちゃんと OGP 画像のデザインをカスタマイズできた.おおおおお!

f:id:kakku22:20200702142200p:plain

まとめ

今回紹介した「Twitter Card Image Generator (tcardgen)」を使えば Hugo「Front Matter」から OGP 画像を自動生成できる.Hugo ユーザーに喜ばれそう!git diffxargs を組み合わせたり,詳しくは tcardgen の作者 @Ladicle さんのブログに書いてあるぞー!

ladicle.com

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ステップ」で構成されていて,IssuePull 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」では,IssuePull 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」を紹介する.

f:id:kakku22:20200614223642p:plain

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 だと画面共有中に「左右表示モード」にすれば,画面共有とカメラを並べられるため,便利!

f:id:kakku22:20200608143733p:plain

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