今要求仕様書を LaTeX で書いている。 要求と仕様の組をまとめて longtable で記述しているのだが、 LaTeX らしい繁雑さがあってちょっと効率が悪い。 マクロを定義すればある程度書きやすくなると思うが、それでもそこそこまでな気がする。
文書の中にレコードの並びが書けて、レコードの並びの中に文章が書きやすいそんなフォーマットはないものかなぁ。
Wiki に慣れきっている自分にとっては Wiki 文法のような感じで記述できて、一部に定型レコードの並びが書けて、そこの整形ルールだけ定義してあげれば LaTeX に変換できるとかそういった感じがのものが欲しい。 定型レコードの部分は RFC822 のヘッダみたいな感じで良くで、値の部分に長めの文章を複数行で書けるものがいい。
構造化テキスト用フォーマット、あるいはWiki フォーマットをアレンジするのがいいかもしれないな。 このあたりのフォーマットは、ソーステキストのままでも十分読み易いことを意識して定義されているので書くのは楽。
レコード部分とは関係ないけれど reStructuredText や Markdown の「アンダーラインのあるテキストを見出しとする」っていうのはいいな。 普段メールやプレーンテキストでちょっと文書を打つときに使っているスタイルと一緒だ。
要求仕様書用に使うかどうかは別として、要チェック。
Twitter API v1.1 に対応していないスクリプトがあって、たしか OAuth 対応はしてあるけど RSS 形式を使っていたので JSON で取得して処理するようにしなければなーと思ってたんだけれど、そもそも OAuth 対応すらしてなかった。
なので Net::Twitter::Lite を使うように書き換え。
あと、いままで1つのスクリプトで「Twitter API を呼び出してタイムライン取得」「シリアライズしてファイルに保存」「Wiki 形式に整形して書き出し」をしていたんだけれど、UNIX 哲学に従って小スクリプトに分割してパイプで受け渡すように変更するなど。
スクリプト間のやりとりは構造化テキストデータなので JSON にしたんだけれど、若干これでいいのかなぁ感はある。テキスト形式だし最近の主流フォーマットではあるんだけれど、それでもシェルから見ると複雑な形式な気がするんだよね。でもあと軽量な構造化テキストフォーマットだと YAML ぐらいかなぁ。
以前ノート間リンクのできるノートアプリを探してみた時に触った Obsidian をもう少し試してみた。
Obsidian はナレッジベースアプリケーションで、一般的なノートアプリよりも情報間のネットワークを重視している。ローカルホスト上の特定フォルダ以下に置いた個別の Markdown ファイルを [[ファイルベース名]] 形式で内部リンクしていくのが基本。
ファイルの拡張子が md 固定で txt では駄目というのが個人的に不便(拡張子 txt にできないと Google ドライブ的に困る)なのだけれど、過去のノートテキストファイルの拡張子を変更してお試ししてみた。
ファイルベース名を指定して内部リンクを文中に書いていくのだが、ファイル名の先頭を日付にする流儀との相性が良くないな。[[ファイルベース名|表示テキスト]] 形式でプレビュー時のテキストを指定できるけど、編集モードだと文章として読みにくい。各ファイルで YAML front matter 形式で別名を宣言しておけばその別名で内部リンクできる機能があるので、丁寧に管理すれば読みやすくはできる。
ただ Obsidian 方言で書きすぎると「ローカルホスト上の Markdown ファイルなので特定アプリケーションに依存しない」良さがスポイルされてしまう。Markdown のショートカット参照リンク形式で内部リンクを張れるようになると良いのになと感じた。
1ファイル1トピックにしてきちんと内部リンクを張っていかないと価値あるグラフにならない。1日1ファイル + 個別トピックファイルというスタイルだと役に立たないかな。
検索は使いやすい。TaskPaper ほど優れてた UI ではないけれど、フォールディングやアウトライン表示もできたりする。デフォルトのスタイルは個人的に見出しが大きいなと感じるので、常用するなら CSS をいじる必要がありそう。
「時間とともに記録・整理しておきたいことが変遷していく」「ナレッジベースを作ること自体が主目的ではない」パーソナルナレッジベースの世界では、静的な情報を丁寧にネットワーク化していく百科事典型よりも日誌/日記型の方が良いと思ってる。内部リンクは編集・維持コストが高いので、パーソナルナレッジベースでは頑張らないのが幸せだ。
Obsidian は百科事典型のナレッジベースが欲しい人にはあいそう。一方自分のような日誌/日記型派にはやはり検索主体の howm 系の方がいいなとあらためて感じた。
[ Mac アプリケーション ] [ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付に ]
ファイルの先頭に置かれたダッシュ3文字の行(---\n)の間に書かれた YAML データ。 Jekyll その他で採用されている。
採用しているアプリケーション:
Markdown Guide: Basics, Tips and Tricks on how to use Markdown
front matter に書いた値を Markdown テキスト中に [%キー] と書くことでプレビュー時に展開するのに使用。
YAML front matter - Obsidian Help
ファイルの別名を指定するのに使用。
昨日から使い始めた Zettelkasten メソッドのための機能を備えた Markdown エディタの2日目。昨日の時点で使い続けるかちょっと迷ったんだけれど、もうちょっと使い方を探ってみようと今日も使ってみている。内部リンク(ノート間リンク)の活用方法がちょっと分かってきて楽しい。
エディタ上で内部リンクを「command + クリック」「control + クリック」すると「リンク先のファイルを開く」と同時にその「リンク文字列での検索」が実行される。ファイルを開くと同時にいい感じに関連するファイルのリスト(実質バックリンクリスト)が表示されて便利。内部リンクを充実させたい気持ちが高まってきた。
アプリケーションに依存する Markdown ファイルを作らないという Zettlr の原則により Markdown ファイル中のどこに ID を書いてもいい仕様になっている。
自分としてはプレビュー時に文中に出ないように、昨日ひとまず ID を HTML コメントの形式で Markdown ファイルに埋め込んでみていた。 Zettlr やメインで使っている iA Writer、プレビューに使っている Marked 2 が YAML front matter に対応しているのでそこの方がわかりやすいかな。 front matter に ID を書くことにした。
日時については基本「2021-01-20-095836」という書式を使っているので Zettlr の ID のパターンも初日に「%Y-%M-%D-%h%m%s」にカスタマイズしたのだけれど「%Y%M%D%h%m%s」に戻した。過去のノートファイルに現在日時の ID を付与するというズレが心理的に気持ち悪かったので。
Also, our own experiences show that when one doesn't use easy-to-recognise IDs, one is less prone to assume stuff, making them better suited to cross-link files. Just try it yourself! -- https://docs.zettlr.com/en/academic/zkn-method/
というの納得。
内部リンクは Zettlr をナレッジベースとして使う上で便利だが、単独の Markdown ファイルをエクスポートして共有する際には不要だ。
Markdown ファイルを各種フォーマットに変換する Marked 2 に自作のカスタムプリプロセッサを通す機能があるので、 Zettlr で管理している Markdown ファイルを共有する際は Marked 2 を呼び出して
- [[...]]
を含む行を消してしまうように設定した。ノート関係の宣言のための内部リンクは上記のように独立した行に書いておこう。
これで個人的なナレッジベースとしてノート間リンクの充実させるという要求と、一部はエクスポートして共有したいという要求を満たせそうだ。
Zettlr 4日目。18,000 弱テキストファイルがあるディレクトリーツリーをワークスペースとして開いたらかなり重かった。使い込んでいくにはパフォーマンスに問題があるな。
Zettlr をしばらく使ってみて、UI とエディタが美しい iA Writter が恋しくなってきた。 iA Writer ならファイル数が 19,000 超えても問題ないし安心だし iA Writer メインに戻ることにしよう。
ローカルホスト上のテキストファイルで管理していると、アプリケーションを乗り換えやすくていい。
Zettlr を使っていいなと思った内部リンクのための記述方法
は iA Writter で取り入れてみてもいいな。
現在日時で %Y%M%D%h%m%s 文字列を生成する Alfred ワークフローを作った。それから
cd ~/notebook pt -l -e "^ID:\\s+$query" . | head -n 1
で見つかったファイルを iA Writter で開く Alfred ワークフローを作成し、ID を指定して iA Writer を開けるようにした。 もっとサクッと開けるように PopClip のエクステンション化もしておきたいな。
キーを「ID」ではなく「ZID」に変更した。
[ ノート・日記はテキストファイルに ] [ Zettelkasten ]
cd ~/notebook pt -l -e "^ID:\\s+$query" . | head -n 1
で見つかったファイルを iA Writer で開く PopClip エクステンションを作った。 iA Writer 上で 20210125215723 という文字列を選択したあとにポップアップした PopClip でこのエクステンションを実行すれば
YAML front matter に
--- ID: 20210125215723 ---
と書いておいた Markdown ファイルを iA Writer でささっと開ける。 iA Writer でのノート間リンクを実現。先週 Alfred で開けるようにしたものの PopClip 版。
PopClip 便利。
キーを「ID」ではなく「ZID」に変更した。
[ ノート・日記はテキストファイルに ] [ Zettelkasten ]
ストリーム。#photography
— Naney (@Naney) January 25, 2021
RICOH GR III #GR #GRIII #GR3#ブラックミストNo05 pic.twitter.com/yO9ng7zbak
Obsidian ノートとして内部リンク方言([[ファイルベース名]] や [[ファイルベース名|表示テキスト]])を書いた Markdown ファイルを HTML ファイルに変換する場合は Marked 2 から[[・]]を消す自作フィルタをプリプロセッサとして呼ぶようにしている。
単独ファイルとして HTML ファイルに変換する場合はこれで良かった。しかし最近はノート間のリンクを残しつつ変換したくなってきた。
ノートの YAML front matter にそのノートの URL (今だとノートを Google ドキュメントにして共有しているので Google ドキュメントの URL)を URL キーで宣言してある。内部リンク先の Markdown ファイルを探して URL が宣言されていれば [ファイルベース名](URL) あるいは [表示テキスト](URL) に書きかえるよう自作フィルタを改良した。
これでリンク元 Markdown ファイルではリンク先ノートの URL を記述しておく必要がなくなり、普通に Obsidian ノートして書くだけでよくなった。めでたし。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
※内容は個人的見解であり所属組織とは関係ありません。