はじめに
こんにちは、サーバーサイドエンジニアの@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の使用経験
- 使用感: 旧PCでfish shellを使用していた期間は、概ね満足していました。特に、ユーザーフレンドリーなインターフェースや豊富な機能は高く評価しています。
POSIX非互換の問題
しかし、fish shellの最大の欠点はPOSIX非互換であることです。 これにより、一部のスクリプトやコマンドが期待通りに動作しない場合があり、開発効率に影響を与えることがありました。 実際、私と同様にこの問題に直面し、zshに戻る開発者も多く見かけました。
zshへの回帰
- 理由: POSIX互換性の重要性を再認識し、より一般的なシェルスクリプトやツールとの互換性を高めるために、zshへ戻ることを決めました。
- 結果: zshに戻ってからは、互換性の問題に悩まされることなく、スムーズな開発が可能になりました。
この変更は、開発環境の安定性と互換性を考慮したものです。 POSIX互換性は、多様な開発環境やツールとの互動において重要な要素であり、これによりより幅広い開発作業を効率的に行えるようになりました。
ターミナルの変更：iTerm2からWarpへ
開発環境の改善の一環として、私はターミナルアプリケーションをiTerm2からWarpに変更しました。
Warpとは
- Rust言語ベース: WarpはRustで開発されており、高速で安定したパフォーマンスを提供します。
- スタイリッシュなUI: モダンで直感的なユーザーインターフェースが特徴です。
- 動作環境: 現在WarpはmacOSでのみ利用可能です。
- 登録が必要: Warpを使用するには、事前にサインアップが必要です。
Warpの機能
Warpには機能が多く搭載されていますが、詳細な紹介は省略します。
公式のDemoがありますので、興味がある方はご覧ください。
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 }
この関数により、ghq で管理しているリポジトリを fzf で効率的に検索し、選択したリポジトリへ素早く移動できるようになりました。
移行完了と感想
新しいMacBook Proの開発環境でのビルドやテストを実行して確認し、無事移行作業を完了しました。
移行アシスタントを使わない選択は、大正解だったと感じています。
開発パフォーマンスも向上したと感じます。特にDockerの起動速度の向上は感動しました。
この記事が皆さんのPC移行の参考になれば幸いです。
終わり
トレタでは一緒にチームで働いてくれるエンジニアのメンバーやプロダクトマネージャーとして活躍してくれる人を求めています。飲食店の未来をアップデートする事業に興味のある方はお気軽に話を聞きにきてください。
