k4a-logのVault運用

2025-01-28

k4a-log(システム)

前提

以前考えたobsidianをpublicとprivateで併用するでは、タイトルの通りVaultは1つで運用するつもりだった
しかし、現実的にはpublicとprivateを完全に同じにするのは難しい

public・private vaultの関係性

本当にprivateにしないといけない情報は実は少ないような気がする

「公開する必要もないが、公開してはいけないわけではない情報（ノイズ）」ノイズ的な情報もあるだろうが、これは閲覧者側の利便性が下がる（それもシステムの工夫次第）だけで、本質的な問題はない
「publicを前提として、どうしても見せられないものはprivateにする」の方がやりやすいのではないか
- 今はprivateで書いているので、publicを導入しようとするとどうしてもpublicが副に思えてしまう
- リスクを考えるならできるだけprivateに寄せたほうがよいが、僕の性格を考えると公開しない言い訳は少しでも取り除いておきたい
- メリデメ天秤にかけてpublicに寄せてみる

publicとprivateの整理

内容別

タスク
- 個人的な買い物や家事や外出、家族や友人との予定など→private
- 個人開発、挑戦、プロジェクトの進捗→public
- 会社と個人のタスク管理分けと考えればそこまで難しくは無いはず
  - 会社：public
  - 個人：private
チートシートやノウハウ → 企業秘密などに触れないのであれば基本public
ブログ → public
- ブログを公開しないという選択肢はよくわからない
ログ（下書き含む）
- 公開する必要もないが、公開してはいけないわけではない情報（ノイズ）のことを指す
- publicで良いが、純粋なログとドキュメントは分離した方が良い
- 例えばこのノートだったら以下のような3段階のリンク
```
k4a-log -> k4a-logのvault運用 -> 2025-01-30 k4a-logのvault運用を決める
```
- 一番最後のリンクは基本的には他からリンクされることはほぼ無い
- ADR(Architecture Decision Records)の過程を遡る記録用というイメージ
- 日常的には2番目のリンクまでが目に入れば良く、そこまではある程度整理された内容であるほうが好ましい
デイリーノート → private
- これが一番扱いに悩むが、デイリーはprivateだけでいいかもしれない
- デイリーからpublicへのリンクが必ずしも必要だとは思えない
- デイリーはかなり赤裸々で雑な書き捨て場として扱いたい（そういう場は少なくとも1つ必要）
- publicに日付情報を乗せたい場合は、明示的に[[2025-01-31]] **を追記のようなchangelog形式で書けば良い

privateの基準

#内容別と重複するがこちらからも整理

個人情報
他者（社）情報
赤裸々な悩み
公開する必要のない個人的な料理や掃除ログ
下書き（場合によっては公開）

なんとなくだが、全体の1~2割程度に落ち着くような気がする

ログ

2025-01-31
- 一旦以下でやってみて、不都合があれば随時変えていく
  - 今のprivateをいきなりpublicにするのではなく、publicを新たに立てるがprivateから概ね全て移植するつもりでそちらに整理しつつ移す
    - 2025-01-31現在、dv.pages().lengthによると2888ページあるらしいのでかなり大変
      - デイリーが数百単位であるとしても2000ページくらいは別でありそう
      - 途中で中断とかができないので一気にやらないといけない
      - 中身の整理や取捨選択を含めて1ページ1分で2000分→33時間！！！？？？？
      - どうやって進めるか
        
        ~~全部コピーしてpublic側で消したり整理していく
        
        把握していない公開してはいけない情報（特にアタッチメント）が紛れ込む可能性がある
        
        1つずつコピーしていく
        
        アタッチメントやリンクがうまく貼れない可能性がある
        
        時間はこちらのほうが掛かりそうだが、最初だけなのでこっちで頑張ってみる
      - コピーの仕方
        
        タイトル（リンク）は変えない
        
        意図しないリンク切れを防ぐため
        
        すべて移し終えたら変えても良い
        
        起点
        
        グラフビューの中心っぽいところから始めようかと思ったが、わけわからなくなりそうなので普通にファイルビューの上からやっていく
        
        プライベートからは消していく
        
        一応バックアップは取っておくが、消さないとどれが残りかわからなくなる
        
        アタッチメント
        
        2374個もある
        
        まるっとコピーしてリンク切れのものをプラグインで消して、残りは目視でダメなものを排除しようと思ったが、流石にこの数は...
        
        とはいえアタッチメントも1つずつ移していくのは厳しいので全体コピー形式で行こうと思う
        
        ノートを整理し終えたらアタッチメントの数も少なくなりそうなのでなんとかなるはず
  - 移せなかったもの、また整理前を残しておきたいものはprivateに残す
- と、ここまで書いてきたが、これはこれで違うような気がする
  - ==そんなに公開したいか？やりたかったことって、ブログと経験地図（Exp Map）のサイトを作ることじゃないのか？
  - 確かにlearn in public的に積極的に公開するのは問題ないのだが、一部以外のすべてを公開する勢いでやるのはおかしくないか？
  - そんなものを見たい人がいるとは思えないし、見せる意味もない
  - チートシート系も僕なんかのやつを他人が見てどうなるという感じ
  - 欲しかったのは外圧による良い効果なわけで、公開することが目的になってないか？
  - 数年経って結果的にほぼpublicになったとかなら良いけど、最初から全部publicにするのは気がはやりすぎな気がする
  - せめて1プロジェクトくらい進めてからでも遅くはない → 経験地図を1プロジェクト始める
  - そもそもの制約としてNextのFunctionが250 MB制限なのでアタッチメントで数百MB使うのが無理
    - publicもそのカウントに含まれる
    - ただこれは使い方が間違ってるだけなので別タスクにする
    - k4a-log - 静的ファイルを別ホスティングにする
- ~~private vaultの中の1フォルダをpublic vaultにする案
  - public側は問題ないが、private側からも触れちゃうので誤ってprivateをpublicに入れるリスクが高い
- ゆるい非公開はあってもいいかも知れない→これだけは実装してしまう 2025-01-31
  - 「公開してもいいけど、今は書き途中なのでできれば下書きとしたい」みたいな要素
  - frontmatterのdraftプロパティかdraftタグ
    - 検索しやすいのはdraftタグで、本来の目的的にもタグのほうがあってそう
  - テスト環境だと見られる感じで