シリコンMacへの開発環境移行体験談

はじめに

こんにちは、サーバーサイドエンジニアの@shiroemonsです。

こちらはトレタAdventCalendar2023 19日目の記事です。

この記事では、開発用PCをインテルMacからシリコンMacに移行した際の経験を共有します。

背景

私の開発PCは、頻繁ではないですがフリーズやパフォーマンスの低下を経験していました。

特に、Google Meetでの会議中のフリーズは、作業の妨げになっていました。

そんな中、M3チップを搭載したMacBook Proの発表があり、これを機に新しいMacBook Proへの移行を決意しました。

12月9日に新しいMacBook Proが届いたことで、移行のプロセスが始まりました。

スペックの変化

移行前後のPCのスペックを比較すると、大きな変化がありました。

メモリが増えたことにより、複数の開発ツールやアプリケーションを同時に動かしてもスムーズに作業できるようになりました。

	旧PC	新PC
種類	13インチ, 2019, Thunderbolt 3ポート x 4	14インチMacBook Pro
仕上げ	スペースグレイ	スペースブラック
メモリ	16GB	36GB
ストレージ	512GB SSD	512GB SSD
プロセッサ	2.8 GHz クアッドコアIntel Core i7	1コアCPU、14コアGPU、16コアNeural Engine搭載Apple M3 Proチップ

移行アシスタントを使用しない理由

新しいMacBook Proへの移行にあたり、私は意図的に移行アシスタントの使用を避ける選択をしました。この決断に至った理由は以下の通りです。

同僚の経験からの学び

私の前にインテルMacからシリコンMacへ移行した同僚から、移行アシスタントを使用した際の経験を聞きました。彼らの体験によると、移行アシスタントを使用しても、チップの違いにより多くのアプリの再インストールが必要でした。

再インストール vs 新規インストール

移行アシスタントを使用する場合と同様にアプリを再インストールする必要があることから、新規インストールの方が状況に応じてより柔軟で、手軽な方法と考えました。

クリーンな環境の維持

移行アシスタントを使うことにより、必要のない古いファイルや使用していないアプリが新しいPCに転送される可能性がありました。新しいPCをできるだけ「クリーン」な状態に保ちたいという思いから、手動での移行を選択しました。

このように、移行アシスタントを使用しないことで、必要なアプリやファイルのみを選択し、新PCを最適化された状態で使い始めることができました。

移行方法

新しいMacBook Proへの移行は、移行アシスタントを使用せず、手動で行いました。以下は、移行プロセスの主なステップです。

必要なアプリのインストール

プロセス: 私はまず、旧PCから新PCで使用するアプリのリストを作成しました。次に、このリストに基づいて新PCに必要なアプリを一つずつインストールしました。
目的: 新しい環境にのみ必要なアプリを選び、不要なものは除外することで、新PCを最適化しました。

ファイルの共有

方法: 重要なファイルやローカル環境の設定ファイルなどは、AirDropを使用して新PCに転送しました。
利点: AirDropの使用により、ファイルの移行を迅速かつ簡単に行うことができました。

進捗管理

ツール: 移行作業の進捗は、Notionに記録していきました。
効果: これにより、作業の進行状況を把握し、計画的に進めることができました。

認証情報の管理

ツールの利用: 移行の際、同僚からのアドバイスに従い、認証情報やログインデータは1Passwordで一元管理しました。
成果: この方法により、移行中のログインや認証プロセスがスムーズに行われ、特に大きな問題は発生しませんでした。

このような手動での移行プロセスは、新しい開発環境を清潔かつ整理された状態で維持することに役立ちました。また、必要なアプリやファイルのみを移行することで、効率的かつ最適化された作業環境を実現しました。

開発環境の変更点

Shellの変更：fish shellからzshへ

今回のPC移行に伴い、Shellをfish shellからzshに変更しました。

fish shellの使用経験

fishshell.com

使用感: 旧PCでfish shellを使用していた期間は、概ね満足していました。特に、ユーザーフレンドリーなインターフェースや豊富な機能は高く評価しています。

POSIX非互換の問題

しかし、fish shellの最大の欠点はPOSIX非互換であることです。これにより、一部のスクリプトやコマンドが期待通りに動作しない場合があり、開発効率に影響を与えることがありました。実際、私と同様にこの問題に直面し、zshに戻る開発者も多く見かけました。

zshへの回帰

理由: POSIX互換性の重要性を再認識し、より一般的なシェルスクリプトやツールとの互換性を高めるために、zshへ戻ることを決めました。
結果: zshに戻ってからは、互換性の問題に悩まされることなく、スムーズな開発が可能になりました。

この変更は、開発環境の安定性と互換性を考慮したものです。 POSIX互換性は、多様な開発環境やツールとの互動において重要な要素であり、これによりより幅広い開発作業を効率的に行えるようになりました。

ターミナルの変更：iTerm2からWarpへ

開発環境の改善の一環として、私はターミナルアプリケーションをiTerm2からWarpに変更しました。

Warpとは

www.warp.dev

Rust言語ベース: WarpはRustで開発されており、高速で安定したパフォーマンスを提供します。
スタイリッシュなUI: モダンで直感的なユーザーインターフェースが特徴です。
動作環境: 現在WarpはmacOSでのみ利用可能です。
登録が必要: Warpを使用するには、事前にサインアップが必要です。

Warpの機能

Warpには機能が多く搭載されていますが、詳細な紹介は省略します。

公式のDemoがありますので、興味がある方はご覧ください。

youtu.be

bindkeyの非対応

Warpの主な注意点として、bindkey コマンドの未対応が挙げられます。これはGitHubのIssueでも取り上げられています。私は、ghq と fzf を使ったリポジトリ検索に bindkey を使用していましたが、以下の関数を用意することでこの問題を回避しました。

# fzf + ghq を使用したリポジトリ検索
fg() {
  local repo_name="$(ghq list | fzf-tmux --reverse +m)"
  if [[ -n "$repo_name" ]]; then
    cd "$(ghq root)/$repo_name"
  fi
}