基本的には見た目に変化はないことですが、サイトのデータの管理方法を大きく変えました。

　これまではDynalist上で書いてDynalistからAPIでデータを取得してサーバーサイドでサイト用データに変換していましたが、全てmdファイルにしてローカルに置き、そこからサイト用データを生成する形にしました。
　Dynalistの構造を利用して表現していた記法を機械的にMarkdownとHTMLに置き換えてmdファイルを生成しているため、一部表示が変化したり乱れたりしている箇所があり得ます。軽くチェックした限りでは概ね大丈夫だとは思いますが、リンクの置換ミスが稀にあったりするので、しばらく「あれ？」と思うような部分が残るかもしれません。
　お知らせは以上です。
　

　
　ここからは変更の経緯などを記録として書いていく。
　当初、自分の文章の公開方法はBloggerというサービスを利用してのブログだった。Bloggerはブログサービスとしては編集もしやすく昔から使っていたもので馴染みもあって気に入っていたが、やはりデータが自分の手元にないということが不便だった。記事を編集するとなればいちいちその記事の編集画面を開いて編集して保存してということをやらなければならないし、複数の記事について一括で置換する的な処理はできない。何もかも手動でやらなくてはならない。
　そこで全て自分の裁量でデータを扱えるように自分でサイトを作ることにして、現在はDeno Deployというサービスを使って公開している。記事データについては最終的にサイトを開いた時に読み込まれるJSONができていればいいので、どういう経路でそのJSONに至るかはなんでも構わない。今回の変更もJSONを生成する手前の話なので、サイト自体のコードはなんにも変わっていない。
　今の形式でエディタとして利用できる手段は「APIで自分のデータを自由に取得・編集できるアプリケーション」または「ローカルファイルを編集できるアプリケーション」ということになる。前者の例がDynalistやNotionで、後者の例がObsidianや一般的なテキストエディタである。
　
　Dynalistは文章エディタとして非常に優秀だ。それは「文章のアウトラインが作れるから」という意味ではない（それも重要な要素ではあるが、私にとってはさほど大事なことではない）。それ以上に、行単位で子要素を持てたりノート欄を持てたりすることによって、自分向けの情報も機械用の処理の指示も自由自在に文に付属させられることが大きなメリットである。
　たとえばMarkdownに専用の記法がない折りたたみなども、「この記号で始めたノードは子要素を中身としたdetails要素にせよ」ということを（コーディングの知識があれば）柔軟に定義できて、detailsタグなどを文中に記述する必要はない。自分が文章を書く上でそのような異物が混じらないことは重要だ。
　最終的に文章に反映させない、いわゆるコメントなどもノート欄や子要素で表現できる。加えて、没にする部分についてはプログラミングと同様の形でコメントアウトの記法も定義している。
　行単位でメタデータや構造を持てることによって、アイデアを思いつきさえすればなんでもできるのだ。
　
　ただしDynalistでは不自由な面もある。それがネットワークの作りにくさだ。
　Dynalistにもノードリンクという機能があるのでそれを使えば「この記事へのリンク」ということは表現できるが、サジェストを使おうとすると全てのノードが対象になってしまうがゆえにノイズだらけでまともに機能しない。ノードリンクについては以前書いたが（ノードリンクを活用し全てのノードに意味のあるアウトラインを作っていく）、ノードリンクを機能させるには使い方に注意を払う必要がある。
　全てのデータが上から下に並んでいなければならないというのもネックだ。データが全て時系列のブログ的記事なら公開日順に並んでいればそれでいいのだが、例えばキーワード単位で作るデータ（当サイトでは「用語集」としている）については、順番に並ぶことに必然性がないので、自分の認識とDynalist上で表現されているデータの並びとが一致しない。
　それゆえに用語集部分だけ先にネットワーク型の管理方法に移転していたのだが、そうするとツールが別になるので記事とリンクが直接繋がらない。これまでどうしていたかというと、Dynalistのタグを用語集に含むキーワードと一致させることで、JSON生成時にサイト上でリンクになるよう処理を可能にしていた。サイトのデータを作るという意味ではそれでも良いのだが、自分の手元でリンクになっていないので作業が直感的にならないという問題があった。
　
　また、Dynalist（というかアウトライナー）に情報を蓄積させ続けるのが果たして妥当かということもある。Dynalistは仕組み上データベースであるし、検索機能が充実していることもあって主観的にもデータベースらしく使うことは不可能ではないが、しかしデータベースとしての活用が向いているかというととてもそうは言えない。無限に増え続けるタイプの情報を扱うなら他に相応しいものがある。

補足（クリックで開く）

　以前Dynalistのデータベース化について書いたが（アウトライン型データベースとしてのDynalist）、それは今話していることと少しレイヤーの異なる話である。というのは、データベースと言ってもひたすらに情報を蓄積していく種のデータベースと、何かを表現するにあたってそれを構成するデータの集まりとして必要なデータベースとがあって（データベースというものに詳しい訳ではないのでふわっとした言い方になってしまうがご容赦願いたい）、前回は後者のためにデータベース然とした形式から解放され自由に文脈を添えられる有機的なデータベースを考えることが有効だという話をした。 　サイトの記事データというのもある程度までの規模は「サイトを構成するためのデータの集まり」という性格が強かったが、やはり何百件も蓄積して更に今後も増え続けるとなると（既に800件近くある）、これらは単にサイトの構成のためのデータではなく自分の歴史と一体になった情報であり、データベースとしての性格も変わったと言える。 　最初から増え続けるタイプのものだというのはわかっていたわけだから限界は予見できたはずのものだが、やってみなくては「向いてなさ」の形が見えてこなかった。 　実際、今後もDynalistに蓄積させ続けるのも無理なことではない。もしデイブ・ワイナー氏のようにアプリケーション自体を自分で作っていてDynalistに不足している要素を自力で完全にカバーできるのであれば、アウトライナーという形態自体が欠点になることもない。アウトライナーであるというのは単にデータの表現形態のひとつに過ぎないからだ。 　ただ現状、Dynalistのシステムでは何千件のような単位の膨大な件数を管理することに特段のアドバンテージはない。データの読み込みのタイミングからしても、何千ノード程度ならいいとしても一件が何十から何百のノードで構成され得るデータが何千件となるとかなり厳しい。画像を多く含めば通信量が嵩むし、ノード数が増えすぎると差が認識できる程度に挙動も重くなる。 　 ---

　Dynalistのノードはどうとでも解釈して使えるという利点があると同時に、自力で解釈を加えないと特定の範囲を一件のデータとして扱えないという難点がある。個別のデータとして形が定まったならば、それはNotionやObsidianのようなデータベースらしく使えるツールの方が扱いやすいし、年月が経った後でも未来の自分が認識しやすい。 　アウトライナーは情報を流動的に扱えるのが武器であり、基本的には「今ホットなもの」のための場であった方がよいと思う。過去のものになった情報、つまり情報として固定的になったものは、流動性の乏しさの代わりにデータとしての扱いに長けている種のツールを使った方が後々便利だろう。 　 　そのようなわけで、サイトのデータはmdファイル化し、Obsidianを用いて管理することにした。 　ただしDynalistで書くのが楽なので、Dynalistで初稿を書くというのは継続する。一通り書いたらプログラムでmdファイルに変換し、以降はmdファイルを編集する。 　書き終わったものの管理はObsidianを使えるmdファイルの方が楽だが、これから書くものはアウトライナーの方が良い。形が定まっていない曖昧な状態で置いておけるからだ。