Mac の「画面共有」を使って「配信用 Mac」と「デモ用 Mac」を使い分ける

「リモート研修」を配信する場合「配信アプリ / 配信機材 / Chrome / PowerPoint / Visual Studio Code / iTerm2」など，必要最低限なアプリに限定したとしても，Mac の負荷（特に CPU と Network）が高くなってしまう．なお，環境としては MacBook Pro 2017 (2.3 GHz Intel Core i5) を使っていて，MacBook Pro を新しくする選択肢もある．

少し重めのデモを紹介する場合

Mac の負荷が高いとは言え，配信自体は遅延も少なく実施できる．しかし，最近悩んでいるのは「配信中に少し重めのデモを紹介する場合」で，例えば Docker Desktop for Mac を使ってコンテナイメージをビルドをしたり，実装したコードをコンパイルしたり，ローカル環境に API サーバを起動したり．通常なら問題なくても，配信中だと顕著に遅くなってしまう．Amazon EC2 など，クラウド上にデモ環境を構築して SSH をしたり VS Code Remote Development を使う案もあるし，実際に使っているけど，やはり「ローカル環境で動かしたい場合」もある！

Mac の「画面共有」を使う

そこで今回は Mac の「画面共有」を使う案を考えた．特にアプリをインストールする必要はなく，Mac を複数台持っていればすぐに使える．簡単に言えば Windows で使える「リモートデスクトップ」と同じ．今回はドキュメントを参照しながら試していく．なお「画面共有」を使った構成図も載せておく．

support.apple.com

1. デモ用 Mac（サブ）

まず「デモ用 Mac（サブ）」で「画面共有」を有効化する．「システム環境設定 ➔ 共有」と選んだら「画面共有」にチェックを入れる．「アクセス許可」など，制限は適切に設定しておく．簡単！使わなくなったら無効化するのも忘れずに！

2. 配信用 Mac（メイン）

Mac を同じネットワーク (WiFi) に接続しておくと「配信用 Mac（メイン）」の Finder から「ネットワーク ➔ ${コンピュータ名} ➔ 画面を共有」と選べるようになっている．

もしくは Mac の「画面共有アプリ」を使って ${コンピュータ名}.local と入力しても同じ．

接続すると，以下のように Mac から Mac を操作できるようになる．まさに「リモートデスクトップ」と同じ！クリップボードも共有できるし，ショートカットも使えるし，レイテンシーも問題なく使える．今後は「少し重めの処理」を「デモ用 Mac（サブ）」で実施してみようと思う．検証環境で配信をしながら試したら「画面共有」自体の負荷は高くなく，問題なく使えていた．

まとめ

「リモート研修」を配信する場合に限らず，Mac の「画面共有」は知っておくと便利に使える場面もありそう！実際に使うと「解像度」を合わせておかないと，ウィンドウサイズを最大化できなかったり，気になるところはあるけど，使いながら模索しようと思う．

関連記事

• 仮想オーディオデバイス「BlackHole」を使って Mac から音楽を配信する - kakakakakku blog
• 便利すぎる！Mac のメニューバーでサウンド設定を変更するときは「Option キー」を使う - kakakakakku blog
• Mac で「なめらかに」デモを見せるために必須なアプリと機能 - kakakakakku blog

GitHub Actions と hadolint を組み合わせて Dockerfile の静的解析を自動化しよう！

GitHub Actions と hadolint (Haskell Dockerfile Linter) を組み合わせて，今まで雑に実装してきた Dockerfile の静的解析を自動化する環境を作った．できる限り Dockerfile Best Practices を意識していることもあり，警告はあまり多く出なかったけど，やはり CI (Continuous Integration) で気付ける安心感はある！

www.docker.com

hadolint (Haskell Dockerfile Linter)

hadolint を使うと Dockerfile に警告を出してくれる．また Dockerfile の RUN は，シェルスクリプトの Linter として有名な ShellCheck を使って警告を出してくれる．例えば FROM centos:latest のように FROM に :latest を使うと，バージョンを指定して！と警告が出る．意識していても漏れることもあり hadolint 便利！

$ hadolint Dockerfile
Dockerfile:1 DL3007 Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag

github.com

なお，hadolint の Wiki に現時点でサポートされているルール一覧と詳細が載っている．

• Home · hadolint/hadolint Wiki · GitHub

DL~ は hadolint のルールで，SC~ は ShellCheck のルールとなる．ShellCheck は他にもルールがある．

• DL3000 : Use absolute WORKDIR.
• DL3001 : Command does not make sense in a container.
• DL3002 : Last user should not be root.
• DL3003 : Use WORKDIR to switch to a directory.
• DL3004 : Do not use sudo.
• DL3005 : Do not use apt-get upgrade or dist-upgrade.
• DL3006 : Always tag the version of an image explicitly.
• DL3007 : Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag.
• DL3008 : Pin versions in apt get install.
• DL3009 : Delete the apt-get lists after installing something.
• DL3010 : Use ADD for extracting archives into an image.
• DL3011 : Valid UNIX ports range from 0 to 65535.
• DL3012 : Provide an email adress or URL as maintainer. 🚫DEPRECATED
• DL3013 : Pin versions in pip.
• DL3014 : Use the -y switch.
• DL3015 : Avoid additional packages by specifying --no-install-recommends.
• DL3016 : Pin versions in npm.
• DL3017 : Do not use apk upgrade
• DL3018 : Pin versions in apk add
• DL3019 : Use the --no-cache switch
• DL3020 : Use COPY instead of ADD for files and folders
• DL3021 : COPY with more than 2 arguments requires the last argument to end with /
• DL3022 : COPY --from should reference a previously defined FROM alias
• DL3023 : COPY --from cannot reference its own FROM alias
• DL3024 : FROM aliases (stage names) must be unique
• DL3025 : Use arguments JSON notation for CMD and ENTRYPOINT arguments
• DL3026 : Use only an allowed registry in the FROM image
• DL3027 : Do not use apt as it is meant to be an end-user tool, use apt-get or apt-cache instead.
• DL3028 : Pin versions in gem install
• DL3029 : Do not use --platform= with FROM.
• DL4000 : MAINTAINER is deprecated
• DL4001 : Either use Wget or Curl but not both.
• DL4003 : Multiple CMD instructions found. If you list more than one CMD then only the last CMD will take effect.
• DL4004 : Multiple ENTRYPOINT instructions found. If you list more than one ENTRYPOINT then only the last ENTRYPOINT will take effect.
• DL4005 : Use SHELL to change the default shell
• DL4006 : Set the SHELL option -o pipefail before RUN with a pipe in
• SC2046 : Quote this to prevent word splitting
  • SC2046 · koalaman/shellcheck Wiki · GitHub
• SC2086 : Double quote to prevent globbing and word splitting.
  • SC2086 · koalaman/shellcheck Wiki · GitHub

GitHub Actions + hadolint

GitHub Actions と hadolint を組み合わせる場合，Docker Hub に公開された hadolint の Docker イメージを使うこともできるけど，今回は GitHub Actions ですぐに使える Hadolint Action を使うことにした．

github.com

さっそく .github/workflows/workflow.yml に以下を設定する．GitHub に push をしたら，Hadolint Action を使って Dockerfile に対して hadolint を実行する単純なワークフローにした．

name: Workflow
on: push
jobs:
  build:
    name: Hadolint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Hadolint
        uses: brpaz/hadolint-action@master

今回サンプルとして，以下のヒドイ Dockerfile を実装し，GitHub に push をする．

FROM centos:latest

RUN vim hello.txt

RUN sudo pwd

ADD README.md /app/

EXPOSE 80000

GitHub Actions で実行結果を確認すると，以下のように「計5種類」の警告が出た．

• ❌ DL3007 : FROM で :latest を使っている
• ❌ DL3001 : vim コマンドを使っている
• ❌ DL3004 : sudo コマンドを使っている
• ❌ DL3020 : COPY ではなく ADD を使っている
• ❌ DL3011 : 0 ~ 65535 以外のポートを使っている

Dockerfile:1 DL3007 Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag
Dockerfile:3 DL3001 For some bash commands it makes no sense running them in a Docker container like `ssh`, `vim`, `shutdown`, `service`, `ps`, `free`, `top`, `kill`, `mount`, `ifconfig`
Dockerfile:5 DL3004 Do not use sudo as it leads to unpredictable behavior. Use a tool like gosu to enforce root
Dockerfile:7 DL3020 Use COPY instead of ADD for files and folders
Dockerfile:9 DL3011 Valid UNIX ports range from 0 to 65535

まとめ

最近 GitHub Actions を使う機会があり，使えば使うほど楽しくなって，今回は hadolint と組み合わせてみた．Dockerfile を GitHub に push すると，自動的に静的解析をしてくれるのは便利！オススメ！

関連記事

GitHub Actions に入門するなら「GitHub Learning Lab」を使うと便利！という記事を書いた．

kakakakakku.hatenablog.com

シェルスクリプトを実装するときは ShellCheck をよく使っている．2017年に CircleCI と組み合わせた記事を書いた．

kakakakakku.hatenablog.com

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 が作られる．

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

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 と表示されていた．

Step 7 : Incorporate the workflow

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

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

まとめ

「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 もパネラーとして参加されていて，ライブに参加できて本当に嬉しかった．

• モデレーター
  • Scott Ford ( @mscottford )
• パネラー
  • Lea Kovac Beckman ( @leakovac )
  • Mira Kottman ( @miraIsTesting )
  • Joe Yoder ( @metayoda )
  • Elizabeth Zagroba ( @ezagroba )
  • Woody Zuill ( @WoodyZuill )

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 のスライドも紹介されていた．気になるし今度読んでみよう！

• Delivering Value with Confidence "Swarming Patterns" - The Hillside Group

Swarm: Beyond Pair, Beyond Scrum from Danijel Arsenovski

www.slideshare.net

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

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

codekata.com

まとめ

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

mobprogrammingnewengland.com

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

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

• アイキャッチ画像（記事のサムネイル） - はてなブログ ヘルプ
• Qiita記事のOGPイメージが新しくなりました - Qiita Blog

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 として保存しておく．

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 画像ができている．おおおおお！

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 画像のデザインをカスタマイズできた．おおおおお！

まとめ

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

ladicle.com