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
1
940
dotfiles 式年遷宮 令和最新版
https://kichijojipm.connpass.com/event/373896/
masawada
November 29, 2025
Tweet
Share
More Decks by masawada
See All by masawada
10年続くサービスのデータを1日未満のメンテナンスウィンドウで安全に移管する
masawada
5
2.5k
よりよいレビュー環境を求めて / A code review odyssey
masawada
0
3k
フロントエンドの秩序は保たれているか?
masawada
1
4.2k
Getting Started with ScratchX
masawada
0
770
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
360
Hack U at UEC 2014.03.27
masawada
0
1.5k
Other Decks in Programming
See All in Programming
コーディングルールの鮮度を保ちたい / keep-fresh-go-internal-conventions
handlename
0
230
DevinとClaude Code、SREの現場で使い倒してみた件
karia
1
1.1k
AI Assistants for Your Angular Solutions
manfredsteyer
PRO
0
160
我々はなぜ「層」を分けるのか〜「関心の分離」と「抽象化」で手に入れる変更に強いシンプルな設計〜 #phperkaigi / PHPerKaigi 2026
shogogg
2
330
Agentic AI: Evolution oder Revolution
mobilelarson
PRO
0
190
Redox OS でのネームスペース管理と chroot の実現
isanethen
0
420
Understanding Apache Lucene - More than just full-text search
spinscale
0
140
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
orgachem
PRO
7
3.1k
最初からAWS CDKで技術検証してもいいんじゃない?
akihisaikeda
4
170
安いハードウェアでVulkan
fadis
1
770
[SF Ruby Feb'26] The Silicon Heel
palkan
0
120
モックわからないマン卒業記 ~振る舞いを起点に見直した、フロントエンドテストにおけるモックの使いどころ~
tasukuwatanabe
3
420
Featured
See All Featured
Un-Boring Meetings
codingconduct
0
240
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
410
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
1
160
Thoughts on Productivity
jonyablonski
75
5.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.4k
Mind Mapping
helmedeiros
PRO
1
130
Code Review Best Practice
trishagee
74
20k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.4k
Practical Orchestrator
shlominoach
191
11k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.2k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
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 みんなちがってみんないい