+
+
+
- 名前: Yuhei FUJITA（藤田 悠平）
- X(Twitter): [@Yuhei_FUJITA](https://twitter.com/Yuhei_FUJITA)
- GitHub: [@YuheiFUJITA](https://github.com/YuheiFUJITA)
+- 所属: [株式会社バリューデザイン](https://www.valuedesign.jp/) / [アララ株式会社](https://www.arara.com/)
- 業務: 主に開発
-- コミュニティ運営:
[Vue Fes](https://vuefes.jp/) / [PWA Night](https://pwanight.connpass.com/) / [VS Code Meetup](https://vscode.connpass.com/)
+- コミュニティ運営: [Vue Fes](https://vuefes.jp/) / [PWA Night](https://pwanight.connpass.com/) / [VS Code Meetup](https://vscode.connpass.com/)
- 趣味: [キャンプ](https://twitter.com/Yuhei_FUJITA/status/1604238002578165761) / [フィルムカメラ](https://www.instagram.com/yuhei_fujita.film/)
@@ -61,17 +70,17 @@ layout: statement
# 陳腐化する理由
-## 1. 議論と更新が別れているから
+## 1.
議論と更新が別れているから
- すべての議論が終わってから更新しようとする
-- テストコードをあとから書くのと同じ
+- テストコードを後から書くのと同じ
-## 2. ドキュメントの更新コストが大きいから
+## 2. ドキュメントの
更新コストが大きいから
- Excel方眼紙やパワポのスライドは楽に見えて編集が大変
- バージョン管理まで考えると更新が面倒になる
-## 3. 直近の自分たちは困らないから
+## 3.
直近の自分たちは困らないから
- 記憶が新しいうちはドキュメントを見なくてもある程度はできる
- ドキュメントが活きてくるのは後から
@@ -124,6 +133,12 @@ layout: statement
layout: statement
---
+# ドキュメントは
書くためでも
更新するためでもなく
未来の誰かが読むためにある
+
+---
+layout: statement
+---
+
# Markdown
+
GitHub
+
VitePress
---
@@ -140,7 +155,7 @@ url: https://vitepress.dev/
---
-# Vitepressの使い方
+# VitePressの使い方
@@ -172,76 +187,71 @@ npm run docs:dev
-## 作成されたファイル構成
-
-```bash {all|2-7|5-7}
-.
-├─ docs
-│ ├─ .vitepress
-│ │ └─ config.js
-│ ├─ api-examples.md
-│ ├─ markdown-examples.md
-│ └─ index.md
-└─ package.json
-```
+
---
-# Markdown
+# フォーマットにMarkdownを採用した理由
-## 1. gitとの相性が良い
+## 1.
gitとの相性が良い
- テキストベースなので差分がわかりやすい
+- `git diff` を見れば変更内容がわかる
-## 2. 書くことに専念できる
+## 2.
書くことに専念できる
- フォーマットやスタイルを気にする必要がない
- Wordの改ページのような本来意識しなくてよいことから開放される
-## 3. CIを組み込める
+## 3.
CIを組み込める
- textlintやPrettierなどのツールを使って自動でチェックできる
+- 表記ゆれなども一元管理できる
---
-# GitHub
+# 管理方法にGitHubを採用した理由
-## 1. Issue/Pull Request駆動のドキュメント更新
+## 1.
Issue/Pull Request駆動のドキュメント更新
- Issue/Pull Requestを議論の場にできる
- Issue/Pull Requestのコメントがそのまま変更の経緯として紐づく
-## 2. Release Noteによるバージョン管理
+## 2. Release Noteによる
バージョン管理
- Pull Requestをまとめることで差分の概要がわかりやすい
- ファイル名にバージョンをつけて管理する運用から脱却できる
-## 3. GitHubによる従来の開発体験の継承
+## 3. GitHubによる
従来の開発体験の継承
- 新しい知識が不要なので導入が容易
+- コーディングと同じフローを踏める
---
-# VitePress
+# 生成ツールにVitePressを採用した理由
-## 1. 運用コストがほぼゼロ
+## 1. 運用コストが
ほぼゼロ
- GitHub PagesやS3 + Cloud Frontでホスティングできる
-## 2. 拡張性が高い
+## 2.
拡張性が高い
- `markdown-it`を使ってMarkdownの拡張ができる
- Vue.jsでカスタマイズできる
-## 3. 標準で必要十分な機能が揃っている
+## 3.
標準で必要十分な機能が揃っている
- Algoliaと連携して検索機能が使える
- git/GitHubとの連携が便利（更新日時の表示など）
- 最近AI Chat機能が追加された
+---
+layout: iframe
+url: https://yuheifujita.github.io/slide-20231206-findy/vitepress/
---
# 導入してみた感想
@@ -280,4 +290,11 @@ npm run docs:dev
# まとめ
-- ドキュメントは更新しやすく、見やすく、経緯がわかること
+- Markdown + GitHub + VitePressとドキュメントは相性がよさそう
+ - 書きやすさ・管理のしやすさ・読みやすさがいい感じ
+- これですべてを解決できるわけではない
+ - 無理にこの方法にこだわる必要はない
+ - 技術者目線にかなり偏っている点には注意
+- ドキュメントの最終目的は読まれること
+ - 書いて更新して終わりではない
+ - 未来の誰かが読むために書く
diff --git a/style.css b/slidev/style.css
similarity index 100%
rename from style.css
rename to slidev/style.css
diff --git a/vercel.json b/slidev/vercel.json
similarity index 100%
rename from vercel.json
rename to slidev/vercel.json
diff --git a/vitepress/docs/.vitepress/config.mts b/vitepress/docs/.vitepress/config.mts
index eea6d4a..2c377cb 100644
--- a/vitepress/docs/.vitepress/config.mts
+++ b/vitepress/docs/.vitepress/config.mts
@@ -5,6 +5,7 @@ import markdownItPlamtuml from "markdown-it-plantuml";
export default defineConfig({
title: "タスク管理アプリ",
description: "ドキュメント",
+ base: "/slide-20231206-findy/vitepress/",
markdown: {
config: (md) => {
md.use(markdownItPlamtuml);