Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
dotfiles 式年遷宮 令和最新版
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
masawada
November 29, 2025
Programming
1.1k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
dotfiles 式年遷宮 令和最新版
https://kichijojipm.connpass.com/event/373896/
masawada
November 29, 2025
More Decks by masawada
See All by masawada
10年続くサービスのデータを1日未満のメンテナンスウィンドウで安全に移管する
masawada
5
2.6k
よりよいレビュー環境を求めて / A code review odyssey
masawada
0
3k
フロントエンドの秩序は保たれているか?
masawada
1
4.3k
Getting Started with ScratchX
masawada
0
800
GyaPC::Asia Tokyo 2015 LT
masawada
0
1.5k
Privileged Apps with Vue.js
masawada
0
220
Chikubeam
masawada
1
1.7k
Git講習 2014.04.15
masawada
1
370
Hack U at UEC 2014.03.27
masawada
0
1.5k
Other Decks in Programming
See All in Programming
freeeにおけるEvalsの実践例の紹介
freee
PRO
0
160
コンパウンドプロダクト開発のためのローカルプロセスマネージャー再発明 #layerxgo
izumin5210
0
530
MySQLとPostgreSQLって何が違うの?
akagami
0
150
Detecting Compromised CI with eBPF and Cilium Tetragon
lizrice
0
270
【デモ】Kiroで体験する仕様駆動開発|設計からコーディングまでAIと進める開発フロー
cmkudo
0
520
私のClaude Code活用法 (個人開発編) - PHPerKaigi mini #4(2026/08/24)
panda_program
1
190
レビュー履歴をAIに食わせて、 Compose移行を加速するs
shihochan
0
240
Gmail/Google DriveをトリガーにAIエージェントを動かそう! / Run AI agents with Gmail/Google Drive as triggers!
har1101
3
460
Hono + Inertia + React で LP を構築した話
oukayuka
2
190
楽しそうなつよつよエンジニアと目が死んでる僕/A brilliant engineer having a blast, and dead-eyed me.
3l4l5
2
260
仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話
freee
PRO
0
660
PyConJP2026_wat_Python × Signal Processing: How to Draw Pictures with Sound Using Spectrogram Art
wat
0
590
Featured
See All Featured
Color Theory Basics | Prateek | Gurzu
gurzu
0
440
Code Reviewing Like a Champion
maltzj
528
40k
We Have a Design System, Now What?
morganepeng
55
8.3k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
310
Making the Leap to Tech Lead
cromwellryan
135
10k
Building Flexible Design Systems
yeseniaperezcruz
330
41k
30 Presentation Tips
portentint
PRO
1
380
Utilizing Notion as your number one productivity tool
mfonobong
4
560
RailsConf 2023
tenderlove
30
1.5k
Odyssey Design
rkendrick25
PRO
2
780
Technical Leadership for Architectural Decision Making
baasie
3
540
Leo the Paperboy
mayatellez
8
2.2k
Transcript
dotfiles 式年遷宮 令和最新版 2025-11-28 Terminal Night #1 id:masawada
自己紹介 • id:masawada • サーバサイドエンジニア ◦ 2025/7まで: ブログやソーシャルブックマークなどサービスを 作る会社 ◦
2025/8から: 家計簿+プリペイドカードの会社 ◦ いまはRuby on Railsをやっていってます • 再現性のあるものがすき • 詳しくはポジションペーパー参照
今日はなすこと • dotfilesとは • dotfilesの類型 • 式年遷宮をやった/やらなかった事例 • 遷宮していくマインド・どうやっていくか •
みんなちがってみんないい
dotfilesとは • 設定ファイル(.bashrc, .vimrc など)を一箇所に固めて 管理する文化 • GitHubで各個人のものが公開されていることが多い
dotfilesは「一番身近な構成管理」 • 本番環境ほど気をつかわなくていい ◦ 環境を壊して困るのは自分だけ ◦ 仕事環境が壊れて困ることはある • 生活を便利にする包丁研ぎのような存在 •
推し進めていくと盆栽のような趣味になっていく
masawada/dotfiles • https://github.com/masawada/dotfiles • シェルスクリプトで構成管理 • Arch Linux / macOS
両対応 ◦ Arch Linuxをインストールするスクリプトがある ◦ CLIからGitHubにSSH鍵を登録するスクリプトがある ◦ 3コマンドくらい打って1時間くらい放置すると環境ができあがる • パッケージ管理、systemdやdefaultsなどのOS設定も管理
dotfilesはひとによって様々 • https://github.com/search?q=dotfiles&type=repositories • バリエーションが豊富 ◦ なにをどこまで管理するか、どうやって管理するか • 類型化して整理してみる
dotfilesの類型 • シンプルにするために2軸で整理してみる ◦ スコープ (S): 何を管理するか ◦ 運用モデル (M):
どうやって管理・適用するか • たぶん異論はたくさんありそう
スコープ (S) • S1: 設定ファイルだけ ◦ .bashrc, .vimrcだけを管理する • S2:
S1 + パッケージ / ランタイム ◦ bashやVim 自体のインストールも管理する • S3: S2 + OS / システム設定 ◦ systemd や defaults などOS自体の設定まで管理する
運用モデル (M) • M1: 手動適用 ◦ cp or ln -s
• M2: 手続き型的な自動適用 ◦ mitamae, chezmoi など • M3: 宣言的な自動適用 ◦ Nix など
masawada/dotfilesはどこにあてはまるか • S3: なるだけ再現性を高める • M2: 取り回しのよさを優先
式年遷宮とは • 日本の伊勢神宮で20年に一度行われる伝統行事 ◦ 古くなった建物を新しくする(棚卸ろし) ◦ 新しい技術や考え方を取り入れる(新しい技術のキャッチアップ) • ここでいう「式年遷宮」は、がらっと作り変えるくらいの意味 ◦
棚卸ろしやキャッチアップができたらいいね、くらい
遷宮した/しなかった事例
事例1: mitamae → bash • 背景 ◦ Arch Linuxでyayを実行する際に管理者権限の取り回しがやや面倒 ▪
yayはsudoを使うと警告を出してくる ▪ が、sudoのセッションがないと毎回パスワードを聞かれる • こうしました ◦ mitamae ベースから shellscript ベースに完全移行 ▪ sudoのセッションを引き回せるように ◦ S3-M2 の型は維持したまま、内部実装だけ入れ替え
事例2: macOS 対応 • 背景 ◦ 転職を契機にmacOSを利用することに ◦ macOSの構成管理も同じリポジトリで達成したい •
検討 ◦ Nix化: 宣言的で魅力的だが、追従コストや壊れ方の性質が変わる ◦ defaults全管理: 壊れたときの再現性をどこまで担保したいか • こうしました ◦ 元の仕組みを維持したまま、最新に追随+壊れたら直すスタイル を続行 ◦ defaults 管理は部分的に入れる
遷宮にどう立ち向かっていくか
コーディングエージェントでやっていく • 相性が良い • 既存構成の読解 → 生成 ◦ これは 生成AI
が得意な"構造化・変換"タスク • 先行事例がGitHubにたくさんある ◦ うまいこと学習してくれている ◦ 例: defaultsのことを結構知っている ▪ やりたいことを伝えれば精度高く書いてくれる
活用のコツ 1: 類型を意識する • 類型をもとに、ゴールを明確にする • いまどうなっている → こうしたい を伝えやすくなる
活用のコツ 2: TODO リストを作る • 現状のリポジトリを読ませ、「現状 → 遷宮後」の差分 TODO を
Markdown で出させる ◦ チェックリスト形式にしておく • 大量に変換しているとコンテキストが枯渇しがち ◦ 状態を保存する先として置いておくと便利
活用のコツ 3: 小さく apply • こまめに動作確認 ◦ VMなどで試す ▪ が、VM固有のworkaroundが入ることもある
◦ macOSは実機でやるしかなさそう ▪ 開発環境が壊れるとつらいのでもう1台買おう • ブランチを切って作業する • CIはどうでしょうね〜 ◦ 個人的には不要派 ◦ 結局は手元で動かさないと分からない
まとめ • dotfiles は スコープ × 運用モデル で整理すると見通しが 良いのでは ◦
というご提案 • すでにある人:自分の類型を把握し、どこに行きたいか 決める • これから始める人:ゴールの類型を決めて、生成AIに 初期構築を任せるのもアリ
ここで一句 dotfiles みんなちがってみんないい