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
masawada
November 29, 2025
Programming
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
210
Chikubeam
masawada
1
1.6k
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
言語を使う側から、作る側へ。 自作 Lisp で得た新たな気づき。
andpad
0
130
エンジニア向け会社紹介/Findy Company Profile
findyinc
6
360k
自作OSでスライド発表する
uyuki234
1
3.9k
1B+ /day規模のログを管理する技術
broadleaf
0
140
コーディングルールの鮮度を保ちたい for SRE NEXT 2026 / keep-fresh-go-internal-conventions-sre-next-2026
handlename
0
140
「正の参照」と 「負の導出」で組む ハーネスエンジニアリング
cottpan
1
140
フィードバックで育てるAI開発
kotaminato
1
120
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
500
act1-costs.pdf
sumedhbala
0
240
20260623_Loop Engineeringで自分の分身の問い合わせBotを作る
ryugen04
0
220
Even G2とAWSで推しのエージェントを召喚しよう!
har1101
1
170
【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
panda728
PRO
2
270
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
It's Worth the Effort
3n
188
29k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
400
First, design no harm
axbom
PRO
2
1.2k
Paper Plane
katiecoart
PRO
2
52k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
2
340
Reality Check: Gamification 10 Years Later
codingconduct
0
2.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
880
Odyssey Design
rkendrick25
PRO
2
730
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Exploring anti-patterns in Rails
aemeredith
3
450
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 みんなちがってみんないい