ファイル階層を使ってメモは分類しない方がいいと思う

ファイル階層を使ってメモは分類しない方がいいと思う
Photo by Andri Aeschlimann / Unsplash

結論から

ObsidianやNotionを使ってメモを取るときはファイル階層(ディレクトリ階層?)を使って整理するのではなく、リンクを使ってメモを接続することで整理する方がいいと思う。

たとえば大学の講義ノート

フォルダーで管理をするとこんな感じでメモを管理することになると思う。


📂月曜3限専門英語

📝第1回講義メモ

📝第2回講義メモ

📝第3回講義メモ

📝第4回講義メモ

📝第5回講義メモ

📂月曜5限環境経済学

📝第1回講義メモ

📝第2回講義メモ

📝第3回講義メモ

📝第4回講義メモ

📝第5回講義メモ


見た目にはきれいに分類できていい気分になれるのがメリット。

問題はディレクトリは管理という意味以外をもたないこと。

知識というのはそれぞれが海上の孤島のように存在していて、それらをつなげていくことが大事なのかなって思っている。

リンクで管理するとこんな感じ。


📝2025年1学期

🔗📝専門英語

🔗📝第1回講義メモ

🔗📝第2回講義メモ

🔗📝第3回講義メモ

🔗📝第4回講義メモ

🔗📝第5回講義メモ

🔗📝環境経済学

🔗📝第1回講義メモ

🔗📝第2回講義メモ

🔗📝第3回講義メモ

🔗📝第4回講義メモ

🔗📝第5回講義メモ


ファイルの中にMarkdownのリンク(めもめも)[どこどこ]を埋め込むことでWebサイトのようにリンクをポチポチするだけでお目当ての場所にたどり着けるようになっている。

具体的にはこんな感じ。

## Markdownのメモメモ

これはいろんなメモをまとめるスーパーメモ

サブメモを列挙していく

- (サブメモその1)[./サブメモその1.md]
- (サブメモその2)[./サブメモその2.md]
- (サブメモその3)[./サブメモその3.md]
## サブメモその1

いろんなことをメモしていく。

めもめもめもめも。

📝2025年1学期のページをホームページのように扱うことで、階層構造をリンクとして表現したつもり。

ちなみにリンクを使ってメモを管理し始めるとファイルが一つの階層にたくさんできるので気になる人は気になる。

Obsidianでの使い方になるが、Obsidian Vaultのフォルダーにたまっていくことになる。

さすがに自分のメモと周辺の情報は異なるので、「自分が書いたメモ」と「他人の書いたメモ」と「添付ファイル」の三つに分けている。

添付ファイルはattachmentフォルダーにたまっていき、Webページの切り抜きはClippingフォルダーに保存するようにしている。

欠点は新規メモの作成はともかく、それをリンク形式で整理するのがめんどくさい。例えば第6回のメモを作ったとして、それをいちいちリンクとして書き込むのがめんどくさい。まあ、慣れです。

真意

Markdownがディレクトリ構造の変化に弱いことは結構言われること。

しかもわかりやすさのために、デフォではWikiリンクとなっているので普遍的なフォーマット化といわれると結構微妙。MarkdownなんだからMarkdownのお作法にそっていればいいのに。

また、Obsidianはデフォルトでノート間のリンクにWikilink形式の記述を採用しています。Wikilinkはフォルダ階層の変更に弱いだけでなく、ソフトウェアによって解釈がまちまちであるため堅牢性に欠けるので推奨できません。

https://jmatsuzaki.com/archives/28115

ディレクトリ構造の変化に弱いのだから、いっそ全部一つのディレクトリで管理してやろうと考えたわけ。ディレクトリはいじらない前提の使い方をすることで、うっかりリンクが壊れてしまうことをなくせるし、そもそもディレクトリをいじる用事がなくなる。

フォルダーを開いたときにずらっと表示されるので事実上の使い道もなくなるので、そもそもフォルダーを使う気すら起きなくなるはずだ。

必要なノートは検索機能を使ってノートのタイトルや全文検索機能でキーワードを頼りに検索していけばいい。最悪grepしてもいいし。

それにせっかくObsidianはネットワークとして表示してくれる面白機能があるのだから、それぞれのメモがどうつながっているのかネットワークとしてみてみるのは面白いじゃない。

Obsidianを使い始めたばかりの人の記事を見ていると、多くのメモが孤立しているネットワークグラフを見ることがある。

知識はつながってこそなのだから、せめて構造だけでもネットワークに落とし込んじゃえという感じ。

ファイルの場所を気にしなくて済むので、Ctrl + nでメモを一瞬で書き始められる。

めっちゃいいよ。

Read more

TailscaleのSubnet Routesを消す

SynologyのNASにTailscaleを導入し、便利に使っている。 TailscaleにはSubnet routersという機能がある。 これは、Tailscaleネットワークに接続されたデバイスが、そのデバイスが接続されているローカルネットワーク(サブネット)全体へのアクセスを他のTailscaleデバイスに提供できる機能だ。つまり、Subnet routerとして設定されたデバイスを経由することで、Tailscaleネットワーク上の他のデバイスから、そのローカルネットワーク内の機器にアクセスできるようになる。 Subnet routers · Tailscale DocsUse subnet routers to give devices outside your local network access to services within specific subnets. Extend your private network with Tailscale.Tailscale 便利そうだなと思って設定をしてみたものの、結局使うことがなかった。 公式ドキュメント

By Sakashita Yasunobu

Boids

群れに指揮者はいない 鳥の群れは、誰かが指示を出しているわけではない。魚の群れも同じ。それぞれが周囲を見て、少しだけ動く。その繰り返しが、全体として秩序ある動きを生む。 これを1986年にCraig Reynoldsがコードで再現した。名前は Boids(bird + oid)。個体に与えるルールは3つだけ。 1. Separation ── 近すぎたら離れる 2. Alignment ── 周囲と同じ方向を向く 3. Cohesion ── 群れの中心に寄る これだけで、群れは群れらしく動く。 なぜ作ったか 群れの動きは、見ていて飽きない。 * 単純なルールから複雑な動きが生まれる ── 創発(emergence)の典型例。設計していないのに、設計したかのように見える。 * 自分のブログに置きたかった ── 静的なページに、動くものがあると空気が変わる。 * Web Components で作りたかった ── どこにでも持っていける部品として。 設計の話 見えないときは止める 画面外でアニメーションを回し続けるのは無駄。Inte

By Sakashita Yasunobu

Days Elapsed

一年を「面」で見る 一年は365日。数字で見ると多いけど、並べてみると案外少ない。 12ヶ月を並べて、過去を塗りつぶして、今日を光らせる。それだけのカレンダーを作った。進捗バーが「一次元」なら、これは「二次元」の進捗表示。 Year Progress一年は50週ちょっとしかない 2026年を週で数えると、52週とちょっと。 カレンダーで見ると長そうなのに、週で数えると急に短くなる。そんな感覚を形にしたくて、このページの上の方に進捗バーを置いた。 やっていることは単純で、「今年が何%進んだか」をリアルタイムで表示しているだけ。 なぜ作ったか 理由は3つある。 1. 時間を「量」として見たかった ── イベントや予定ではなく、単純に「どれだけ経ったか」を数値で見たかった。 2. 目に見える形にしたかった ── 抽象的な「一年」を、動く数字に落とすとどう感じるか試したかった。 3. 自分の場所に置きたかった ── 誰かのツールを借りるのではなく、自分のブログに自分で作ったものを置きたかった。 実装の話 せっかく作るなら、

By Sakashita Yasunobu