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
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
masawada
November 29, 2025
Programming
1
920
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
760
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
izumin5210のプロポーザルのネタ探し #tskaigi_msup
izumin5210
1
490
AIエージェントのキホンから学ぶ「エージェンティックコーディング」実践入門
masahiro_nishimi
7
1.2k
今、アーキテクトとして 品質保証にどう関わるか
nealle
0
200
AIと一緒にレガシーに向き合ってみた
nyafunta9858
0
450
日本だけで解禁されているアプリ起動の方法
ryunakayama
0
360
PJのドキュメントを全部Git管理にしたら、一番喜んだのはAIだった
nanaism
0
220
Agent Skills Workshop - AIへの頼み方を仕組み化する
gotalab555
13
7.4k
メタプログラミングで実現する「コードを仕様にする」仕組み/nikkei-tech-talk43
nikkei_engineer_recruiting
0
130
RubyとGoでゼロから作る証券システム: 高信頼性が求められるシステムのコードの外側にある設計と運用のリアル
free_world21
0
130
モジュラモノリスにおける境界をGoのinternalパッケージで守る
magavel
0
3.3k
Rで始めるML・LLM活用入門
wakamatsu_takumu
0
110
今更考える「単一責任原則」 / Thinking about the Single Responsibility Principle
tooppoo
3
1.2k
Featured
See All Featured
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
190
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
660
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
180
Evolving SEO for Evolving Search Engines
ryanjones
0
140
Speed Design
sergeychernyshev
33
1.6k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
1
140
A better future with KSS
kneath
240
18k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
2
65
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
220
Un-Boring Meetings
codingconduct
0
220
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
130
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 みんなちがってみんないい