![見出し画像](https://assets.st-note.com/production/uploads/images/131271015/rectangle_large_type_2_a738e9c9b0cf447bed6fb4d32a2df4cb.jpeg?width=1200)
会社支給の Mac に開発環境を構築する 2024
はじめに
転職などを機に開発マシンが新しくなるタイミングは、開発環境を見直す絶好のチャンスになります。
今年に入って私も職場が変わり、新しいマシンが段ボールで届きました。
いい機会なので、これからの新しい仕事にわくわくしつつ、自身の開発環境を見直してみようと思い立ちました。
以下、最新の構築手順を自分用のメモ程度にまとめましたが、何かの参考になれば幸いです。
環境
macOS Sonoma 14.1
Apple M3 Pro
IT 企業だと MacBook Pro が開発用マシンとして支給されることが多いですね。
私も仕事では Mac を使っていますが、個人開発では Surface Pro を使用しています。WSL と VS Code と Dev Container のおかげで Windows でも普通に開発できるようになりました。Windows 機を支給する会社も増えていきそうです。
方針
カスタマイズは最小限に抑える
エンジニアをやっているとあれこれマシンをカスタマイズしたくなる気持ちもありますが、カスタマイズが多いと何かの拍子に環境が壊れやすくなりますし、問題を解消するための調査の難易度も上がります。
多少のカスタマイズは許容しますが、最低でも公式ドキュメントに記載されているくらいのものが望ましいです。
ローカル環境を可能な限り汚さない
アプリケーション開発においては基本的にコンテナを使用し、ホスト環境へのソフトウェアのインストールや設定変更は最小限に留めます。
ホスト環境の変更が少ないほど、開発環境を作り直すのも容易です。
巨人の肩に乗る
目的にもよりますが、開発環境構築においては流行っている技術やケツモチに信頼できる企業や団体がいる技術を選んでおくのが無難かなと思っています。
これをエンジニアの言葉にしてみる。「どうでもいいことは流行に従い、重大なことは標準に従い、ドメインのことは自らドメインフレームワークを設計し実装する」 https://t.co/in3CD1PtSj
— Akihito Koriyama (@koriym) March 30, 2019
VS Code
最近はほぼデファクトみたいな感じになってます。強いこだわりやプロジェクトの制約がなければこいつを選んでおけば問題ないかなと思います。あと Dev Container を使うとさらに無敵になります。
Mac 用のパッケージを選んでぽちぽちインストールします。
サインイン
VS Code の機能をフル活用するためにも、GitHub アカウントで VS Code にサインインしておくとよいでしょう。
設定の同期を有効化しておくと、開発環境を作り直すときにいちいち settings.json を編集し直さなくて済むのでよいです。
また、GitHub Copilot や Live Share を使っての開発時も GitHub アカウントでのサインインが基本的には前提となります。
code コマンドの追加
エディターは全て VS Code で統一します。
ターミナルから任意のファイルやフォルダを code コマンドで開けるように、VS Code のコマンドパレットから CLI をインストールしておきます。
Git で使用されるエディターも VS Code に変更しておきます。
% git config --global core.editor "code --wait"
Hyper
ターミナルには Vercel 製の Hyper を使います。
Vercel がまだ ZEIT だった頃に職場の先輩に教えてもらい、そこから長く使っています。
どシンプルなターミナルですが、Web アプリケーション開発で特に困ることはないです。
Mac 用のパッケージを選んでぽちぽちインストールします。
Hyper の設定
~/.hyper.js を自分用にカスタマイズします。
% code ~/.hyper.js
fontSize: 20
大きいディスプレイで小さい文字を読んでいると目が疲れるので、基本大きめに設定しています。
shell: ‘/bin/zsh’
Mac のデフォルトのシェルは何年か前から zsh になっていますが、Hyper では明示的に指定する必要があります。
Hyper を再起動し、zsh に切り替わっていることを確認します。
% echo $SHELL
/bin/zsh
お好みで hyperpower などのプラグインを入れておきます。
Oh My Zsh のインストール
zsh はカスタマイズすることでより便利になりますが、自分で .zshrc を書き換えたり管理するのは避けたいです。
そこで Oh My Zsh をインストールします。これで特に手を加えずともいい感じの使用感になります。
README に記載のとおり、Hyper から curl を叩いてインストールします。
% sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
Git
git コマンド自体は Mac の場合デフォルトで使えるようになっています。
GitHub CLI による認証情報の連携
Git を使い始めるにあたりまず認証周りの設定が必要ですが、GitHub CLI を利用した認証方法が便利です。
gh auth setup-git コマンドを実行しておくことで、git コマンドを叩く際に GitHub CLI のログイン情報を使ってくれるようになります。
CLI のログインのため、事前にスマホに GitHub Mobile アプリをインストールしておきます。
% brew install gh
% gh auth login
% gh auth setup-git
% git config -l
credential.helper=osxkeychain
init.defaultbranch=main
credential.https://github.com.helper=
credential.https://github.com.helper=!/usr/local/bin/gh auth git-credential
credential.https://gist.github.com.helper=
credential.https://gist.github.com.helper=!/usr/local/bin/gh auth git-credential
core.editor=code --wait
GPG 鍵によるコミット署名設定
実はこれまでやっていなかったのですが、コミット偽装のリスクなどを回避するためにやっておくに越したことはないので、今回コミット署名の設定をしてみたいと思います。
ローカルで GPG 鍵を生成します。
% brew install gnupg
% gpg --list-secret-keys --keyid-format=long
% gpg --full-generate-key
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ご希望の鍵の種類を選択してください:
(1) RSA と RSA
(2) DSA と Elgamal
(3) DSA (署名のみ)
(4) RSA (署名のみ)
(9) ECC (署名と暗号化) *デフォルト
(10) ECC (署名のみ)
(14) カードに存在する鍵
あなたの選択は?
ご希望の楕円曲線を選択してください:
(1) Curve 25519 *デフォルト
(4) NIST P-384
(6) Brainpool P-256
あなたの選択は?
鍵の有効期限を指定してください。
0 = 鍵は無期限
<n> = 鍵は n 日間で期限切れ
<n>w = 鍵は n 週間で期限切れ
<n>m = 鍵は n か月間で期限切れ
<n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0)
鍵は無期限です
これで正しいですか? (y/N) y
GnuPGはあなたの鍵を識別するためにユーザIDを構成する必要があります。
本名: My Name
電子メール・アドレス: example@users.noreply.github.com
コメント:
次のユーザIDを選択しました:
"My Name <example@users.noreply.github.com>"
名前(N)、コメント(C)、電子メール(E)の変更、またはOK(O)か終了(Q)? O
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。
gpg: ディレクトリ'/Users/myname/.gnupg/openpgp-revocs.d'が作成されました
gpg: 失効証明書を '/Users/myname/.gnupg/openpgp-revocs.d/6A9990EE48CEDA15DB9C7423F7152593E75419EE.rev' に保管しました。
公開鍵と秘密鍵を作成し、署名しました。
pub ed25519 2024-02-17 [SC]
6A9990EE48CEDA15DB9C7423F7152593E75419EE
uid My Name <example@users.noreply.github.com>
sub cv25519 2024-02-17 [E]
% gpg --list-secret-keys --keyid-format=long
gpg: 信用データベースの検査
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
[keyboxd]
---------
sec ed25519/F7152593E75419EE 2024-02-17 [SC]
6A9990EE48CEDA15DB9C7423F7152593E75419EE
uid [ 究極 ] My Name <example@users.noreply.github.com>
ssb cv25519/F42AE856697F2DAE 2024-02-17 [E]
鍵をエクスポートして GitHub に追加します。
秘密鍵は環境を作り直す際に必要になるので、適切な手段でバックアップを取っておきます。
% gpg --armor --export F7152593E75419EE > public.asc
% gpg --export-secret-keys F7152593E75419EE > private.asc
% gh auth refresh -s read:gpg_key,write:gpg_key
% gh gpg-key add public.asc
% gh gpg-key list
EMAIL KEY ID PUBLIC KEY ADDED EXPIRES
example@e... F7152593E75419EE xjMEZc1pS...jpiY+f5s= less than a minute... Never
git config でコミット署名を設定します。
% git config --global user.signingkey F7152593E75419EE
% git config --global commit.gpgsign true
% git config --global user.name "My Name"
% git config --global user.email "example@users.noreply.github.com"
% git config -l
credential.helper=osxkeychain
init.defaultbranch=main
credential.https://github.com.helper=
credential.https://github.com.helper=!/usr/local/bin/gh auth git-credential
credential.https://gist.github.com.helper=
credential.https://gist.github.com.helper=!/usr/local/bin/gh auth git-credential
user.signingkey=F7152593E75419EE
user.name=My Name
user.email=example@users.noreply.github.com
commit.gpgsign=true
コミット用のメールアドレスには noreply メールアドレスを設定します。
Email settings で、
Keep my email addresses private
Block command line pushes that expose my email
の 2 つにチェックを入れておきます。
実際にコミットしてみたところ、
"fatal: failed to write commit object"
というエラーが出て署名に失敗しました。
調べたところ、GPG がパスフレーズを求める際に現在のターミナル (Hyper) が使用されるように環境変数の設定が必要なようです。
下記を実行してターミナルを再起動します。
% echo 'export GPG_TTY=$(tty)' >> ~/.zshrc
Scheduled reminders の設定
新しい職場の Slack workspace および GitHub organization に参加したら、まずリマインダーの設定を忘れずにやっておきます。
https://github.com/settings/reminders を開いてぽちぽち設定します。
HTTPie
API クライアントには最近は HTTPie を使っています。
デスクトップアプリも便利です。
ぽちぽちインストールしておきます。
Dev Container
参画するプロジェクトの状況にもよりますが、冒頭の方針でも述べたように、基本的には Dev Container を使用して開発を進めていくのが望ましいと思います。
Docker Desktop for Mac のインストール
まずは Docker をぽちぽちインストールします。
所属組織の状況に応じてライセンスの設定も忘れずに。
コンテナイメージの作成
公式のコンテナイメージをベースに、必要に応じて適宜 features を追加します。features で足りなければ extensions を追加します。
extensions はこの辺を入れておくことが多いです。
VSCODE POWER MODE は新しい職場でウケることが多いです。
GPG 鍵の共有
VS Code のターミナルや GUI で GPG 鍵によるコミット署名を伴う Git 操作を行う場合は、ホストとコンテナ間で GPG 鍵が共有されるように追加の設定が必要です。
Mac 用の GPG Suite をぽちぽちインストールします。
GPG Suite を開き、GPG 鍵によるコミット署名設定 の項でエクスポートした秘密鍵 (private.asc) をインポートします。
Dev Container の Dockerfile を編集し、gnupg2 をコンテナにインストールします。
RUN apt-get update && apt-get install gnupg2 -y
Dev Container を Rebuild し、VS Code のターミナルで git commit を行うと、GPG Suite にパスフレーズを聞かれるようになっているはずです。
おわりに
以上が自分なりの最低限の開発環境構築手順となります。
数年前と比べるとだいぶやることが減ったなぁという印象です。
しばらく職場が変わることはないと思いますが、また新たな技術が出てきたらアップデートしていきたいと思っています。
この記事が気に入ったらサポートをしてみませんか?