nDiki : YAML

定型書式で内容を記述していくのに便利な形式は?

今要求仕様書を LaTeX で書いている。 要求と仕様の組をまとめて longtable で記述しているのだが、 LaTeX らしい繁雑さがあってちょっと効率が悪い。 マクロを定義すればある程度書きやすくなると思うが、それでもそこそこまでな気がする。

文書の中にレコードの並びが書けて、レコードの並びの中に文章が書きやすいそんなフォーマットはないものかなぁ。

• LaTeX + マクロ
  • 整形は綺麗。
  • 記述が繁雑になりがち。\マクロ名とか {} とか。
• DocBook
  • 仕様デカスギ
  • 以前使ってみたことがあるが、手で書くのにはしんどい。
• XML
  • 構造的な情報の表現には良いのだが、手で書くのはしんどい。開きタグも閉じタグも。
  • 普通の章節や、マークアップのルールを考えなければならない(定義するか借りてくるか)。
  • LaTeX等へのコンバータを書く必要あり。
• YAML
  • レコードの並びだけだったら良いが、文書の他の要素を一緒に書くのには適さない。
  • ある程度の構造やボリュームがあると、思ったほど手書きしやすくない。
  • YAML Perl モジュールで痛い目にあっている。

Wiki に慣れきっている自分にとっては Wiki 文法のような感じで記述できて、一部に定型レコードの並びが書けて、そこの整形ルールだけ定義してあげれば LaTeX に変換できるとかそういった感じがのものが欲しい。 定型レコードの部分は RFC822 のヘッダみたいな感じで良くで、値の部分に長めの文章を複数行で書けるものがいい。

構造化テキスト用フォーマット、あるいはWiki フォーマットをアレンジするのがいいかもしれないな。 このあたりのフォーマットは、ソーステキストのままでも十分読み易いことを意識して定義されているので書くのは楽。

• reStructuredText
  • いいらしい。
  • HTML、LaTeX、XML へのコンバータがある。
  • 拡張性も考慮されているらしい。
  • でも Python。
• Markdown
  • reStructuredText よりもソーステキストが読み易いらしい。
  • Perl
  • HTMLへの変換しかない。
• WiKicker (Wiki)
  • かなり書き慣れている。
  • レコードの並びの書き方を考える必要あり。
  • 複数行にまたがる処理を書くのが面倒。
  • 自分で書いているシステムなので中身は何でも知っている。
  • マイナー。

レコード部分とは関係ないけれど reStructuredText や Markdown の「アンダーラインのあるテキストを見出しとする」っていうのはいいな。 普段メールやプレーンテキストでちょっと文書を打つときに使っているスタイルと一緒だ。

要求仕様書用に使うかどうかは別として、要チェック。

今日のさえずり: 「最初女性だと思っていました」

2010年11月01日

• 09:59 面接1箇所目10:00になった。
• 11:13 今日新しく入社されている人に思いっきりアカばれしてた。というかモロに会社名も実名も出していて全然隠してはいないので、今まで新しくきた人が何も言ってこなかった方が不気味。
• 11:14 「最初女性だと思っていました」ゴメンナサイ、オトコで。ネカマでもないです。
• 11:19 2つ目の面接は15:00に決定。そして要安全ピン。
• 11:24 Norton Internet Security 2010 で 2011 へのアップデート案内ダイアログが出たのでアップデート。何かマップがスパイ基地みたいで楽しい。
• 12:16 安全ピン入手した。
• 12:23 ついでにトミカも入手。
• 12:41 ヨド Edy 初チャージした。
• 12:49 幕の内弁当 398円。
• 15:46 「勧告的ロック」を検索しようとして「韓国的ロック」で検索してしまったが、それなりにヒットした。
• 17:08 \index{親!子}って毎回書くの面倒臭い。なんかいいマクロはないものか。 #LaTeX2e
• 17:15 idx ファイルを書き換えるスクリプト書けばいいか。
• 18:12 YAML ファイルとして書いておいた索引語変換辞書を読み込んで idx ファイルを置換する Perl スクリプト書いた。 RT @Naney: \index{親!子}って毎回書くの面倒臭い。なんかいいマクロはないものか。 #LaTeX2e
• 19:32 spモードメールアプリがシビレるぐらい重くなってきた。
• 22:44 目の前に広辞苑第六版があるので「たほいや」など調べてみた。

今日のさえずり: 社内 Wiki が死ぬと会議が死ぬ

2012年01月11日

• 15:37 社内 Wiki が死ぬと会議が死ぬ。
• 20:17 退勤。チョコパイ焼いたらしいので帰ります。
• 22:31 コープヌードル! (あの商品のイントネーションで お願いします)。 http://t.co/Cqlecv4r
• 22:35 1週間ほどATOK for Android のジェスチャー入力続けてみたけど全然速くならない。入力自体に集中がいってしまって短文しか打てんし。やめ。
• 23:14 @maru_kei お、音声入力使ってるんですか。
• 24:28 Android 用の Path をインストール。
• 24:35 First Name と Last Name が必須とかめんどくさい。

2012年01月12日

• 08:26 「Goodleしゃべって入力マッシュ」いれてみたけど、そもそも com.google.android.voicesearch が初期化で例外で落ちるという罠。
• 08:44 音声検索 1.4.7 (グレーアイコン)いれてみた。音声検索 1.4.1 (赤アイコン)と両方入っちゃうのか。
• 08:48 赤アイコンの音声入力アンインストールしたら「音声検索」「Googleしゃべって入力マッシュ」両方とも動くようになったよ。
• 12:39 Xperia SO-01B、2011年11月7日のエリアメール対応アップデートが成功しないので緊急地震速報もこない。
• 12:40 Google Chrome の 緊急地震速報 by Extension の方が、皆のケータイが鳴るより先だったので勝ち組。
• 13:02 HTML5 って a の中に p していいんだ。
• 17:29 YAML ファイル醜いのでコンバートしてチェックする。 s/醜い/見難い/
• 20:11 Tumblr のグループブログってどうなのかな。グループ内のプライベートなクリッピングシェア用に使えるのかな。
• 20:27 退勤。気のせいか昼より和らいでる。
• 22:05 大人のドラマって、それオジサンオバサンドラマ。
• 25:29 Tumblr 再設定だいたいできた。

Twitter API v1.1 対応とか、パイプでやりとりするの JSON でいいのとか

Twitter API v1.1 に対応していないスクリプトがあって、たしか OAuth 対応はしてあるけど RSS 形式を使っていたので JSON で取得して処理するようにしなければなーと思ってたんだけれど、そもそも OAuth 対応すらしてなかった。

なので Net::Twitter::Lite を使うように書き換え。

あと、いままで1つのスクリプトで「Twitter API を呼び出してタイムライン取得」「シリアライズしてファイルに保存」「Wiki 形式に整形して書き出し」をしていたんだけれど、UNIX 哲学に従って小スクリプトに分割してパイプで受け渡すように変更するなど。

スクリプト間のやりとりは構造化テキストデータなので JSON にしたんだけれど、若干これでいいのかなぁ感はある。テキスト形式だし最近の主流フォーマットではあるんだけれど、それでもシェルから見ると複雑な形式な気がするんだよね。でもあと軽量な構造化テキストフォーマットだと YAML ぐらいかなぁ。

百科事典型ナレッジベースに向いているナレッジベース Obsidian

以前ノート間リンクのできるノートアプリを探してみた時に触った Obsidian をもう少し試してみた。

• https://obsidian.md/

Obsidian はナレッジベースアプリケーションで、一般的なノートアプリよりも情報間のネットワークを重視している。ローカルホスト上の特定フォルダ以下に置いた個別の Markdown ファイルを [[ファイルベース名]] 形式で内部リンクしていくのが基本。

ファイルの拡張子が md 固定で txt では駄目というのが個人的に不便(拡張子 txt にできないと Google ドライブ的に困る)なのだけれど、過去のノートテキストファイルの拡張子を変更してお試ししてみた。

内部リンク

ファイルベース名を指定して内部リンクを文中に書いていくのだが、ファイル名の先頭を日付にする流儀との相性が良くないな。[[ファイルベース名|表示テキスト]] 形式でプレビュー時のテキストを指定できるけど、編集モードだと文章として読みにくい。各ファイルで YAML front matter 形式で別名を宣言しておけばその別名で内部リンクできる機能があるので、丁寧に管理すれば読みやすくはできる。

ただ Obsidian 方言で書きすぎると「ローカルホスト上の Markdown ファイルなので特定アプリケーションに依存しない」良さがスポイルされてしまう。Markdown のショートカット参照リンク形式で内部リンクを張れるようになると良いのになと感じた。

グラフ表示

1ファイル1トピックにしてきちんと内部リンクを張っていかないと価値あるグラフにならない。1日1ファイル + 個別トピックファイルというスタイルだと役に立たないかな。

その他

検索は使いやすい。TaskPaper ほど優れてた UI ではないけれど、フォールディングやアウトライン表示もできたりする。デフォルトのスタイルは個人的に見出しが大きいなと感じるので、常用するなら CSS をいじる必要がありそう。

パーソナルナレッジベースとして

「時間とともに記録・整理しておきたいことが変遷していく」「ナレッジベースを作ること自体が主目的ではない」パーソナルナレッジベースの世界では、静的な情報を丁寧にネットワーク化していく百科事典型よりも日誌/日記型の方が良いと思ってる。内部リンクは編集・維持コストが高いので、パーソナルナレッジベースでは頑張らないのが幸せだ。

Obsidian は百科事典型のナレッジベースが欲しい人にはあいそう。一方自分のような日誌/日記型派にはやはり検索主体の howm 系の方がいいなとあらためて感じた。

[ Mac アプリケーション ] [ ノート・日記はテキストファイルに ] [ ファイル名の先頭を日付にする ]

YAML front matter #nNote

ファイルの先頭に置かれたダッシュ3文字の行(---\n)の間に書かれた YAML データ。 Jekyll その他で採用されている。

採用しているアプリケーション:

• iA Writer
• pandoc (YAML metadata block)
• MultiMarkdown
• Marked 2
• Obsidian
• Zettlr

iA Writer

Markdown Guide: Basics, Tips and Tricks on how to use Markdown

front matter に書いた値を Markdown テキスト中に [%キー] と書くことでプレビュー時に展開するのに使用。

Obsidian

YAML front matter - Obsidian Help

ファイルの別名を指定するのに使用。

• キー: aliases

Zettlr 2日目

昨日から使い始めた Zettelkasten メソッドのための機能を備えた Markdown エディタの2日目。昨日の時点で使い続けるかちょっと迷ったんだけれど、もうちょっと使い方を探ってみようと今日も使ってみている。内部リンク(ノート間リンク)の活用方法がちょっと分かってきて楽しい。

内部リンクの使い勝手が良い

エディタ上で内部リンクを「command + クリック」「control + クリック」すると「リンク先のファイルを開く」と同時にその「リンク文字列での検索」が実行される。ファイルを開くと同時にいい感じに関連するファイルのリスト(実質バックリンクリスト)が表示されて便利。内部リンクを充実させたい気持ちが高まってきた。

ID を YAML front matter に埋め込む

アプリケーションに依存する Markdown ファイルを作らないという Zettlr の原則により Markdown ファイル中のどこに ID を書いてもいい仕様になっている。

自分としてはプレビュー時に文中に出ないように、昨日ひとまず ID を HTML コメントの形式で Markdown ファイルに埋め込んでみていた。 Zettlr やメインで使っている iA Writer、プレビューに使っている Marked 2 が YAML front matter に対応しているのでそこの方がわかりやすいかな。 front matter に ID を書くことにした。

ID のパターンは初期設定の「%Y%M%D%h%m%s」で

日時については基本「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/

というの納得。

内部リンクは独立した行に書き、 Marked 2 で消す

内部リンクは Zettlr をナレッジベースとして使う上で便利だが、単独の Markdown ファイルをエクスポートして共有する際には不要だ。

Markdown ファイルを各種フォーマットに変換する Marked 2 に自作のカスタムプリプロセッサを通す機能があるので、 Zettlr で管理している Markdown ファイルを共有する際は Marked 2 を呼び出して

 - [[...]]

を含む行を消してしまうように設定した。ノート関係の宣言のための内部リンクは上記のように独立した行に書いておこう。

これで個人的なナレッジベースとしてノート間リンクの充実させるという要求と、一部はエクスポートして共有したいという要求を満たせそうだ。

Zettlr 4日目、iA Writer に戻す

Zettlr 4日目。18,000 弱テキストファイルがあるディレクトリーツリーをワークスペースとして開いたらかなり重かった。使い込んでいくにはパフォーマンスに問題があるな。

Zettlr をしばらく使ってみて、UI とエディタが美しい iA Writter が恋しくなってきた。 iA Writer ならファイル数が 19,000 超えても問題ないし安心だし iA Writer メインに戻ることにしよう。

ローカルホスト上のテキストファイルで管理していると、アプリケーションを乗り換えやすくていい。

Zettlr を使っていいなと思った内部リンクのための記述方法

• %Y%M%D%h%m%s 形式の ID を YAML front matter に書く。
• - [[%Y%M%D%h%m%s]] の形でリンクを書く。

は 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 のエクステンション化もしておきたいな。

2021年2月3日追記

キーを「ID」ではなく「ZID」に変更した。

[ ノート・日記はテキストファイルに ] [ Zettelkasten ]

iA Writer でのノート間リンクのための PopClip エクステンション

 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 便利。

2021年2月3日追記

キーを「ID」ではなく「ZID」に変更した。

[ ノート・日記はテキストファイルに ] [ Zettelkasten ]

今日のさえずり: バックギャモンてタイプしたらバックギャモンってバックギャモンだっけてよく分からなくなってきた

• 09:02 天気が良くて明るくて寒くなくて雨上がりで潤っていて、呼吸が最高の朝。スギ花粉の季節前のボーナス。
• 09:27 雨の心配が無く折り畳み傘が不要なので、荷物を厳選しつつ RICOH GR III をティーニーテールメイトに放り込んできた。オランダせんべい・アルフォート・ルマンドも押し込んできた。
• 22:55 ストリーム。 #photography RICOH GR III #GR #GRIII #GR3 #ブラックミストNo05 https://t.co/yO9ng7zbak
• 22:56 ティーニーテールメイト、まだジッパー開閉が硬い。HDナイロンがこなれてくるのが楽しみ。
• 23:51 Markdown ファイルの YAML front matter に書いている ID を探して iA Writer で開くちょっとした PopClip エクステンションを作った。 iA Writer でノート間リンクできるようになって嬉しい。
• 25:21 バックギャモンてタイプしたらバックギャモンってバックギャモンだっけてよく分からなくなってきた。
• 25:22 バックギャモンしばらくやってないな。好きなのでまたやりたい。

ストリーム。#photography
RICOH GR III #GR #GRIII #GR3#ブラックミストNo05 pic.twitter.com/yO9ng7zbak

— Naney (@Naney) January 25, 2021

Obsidian 内部リンク形式を参照解決して Markdown 形式に置き換えるフィルタを書いた

Obsidian ノートとして内部リンク方言([[ファイルベース名]] や [[ファイルベース名|表示テキスト]])を書いた Markdown ファイルを HTML ファイルに変換する場合は Marked 2 から[[・]]を消す自作フィルタをプリプロセッサとして呼ぶようにしている。

単独ファイルとして HTML ファイルに変換する場合はこれで良かった。しかし最近はノート間のリンクを残しつつ変換したくなってきた。

ノートの YAML front matter にそのノートの URL (今だとノートを Google ドキュメントにして共有しているので Google ドキュメントの URL)を URL キーで宣言してある。内部リンク先の Markdown ファイルを探して URL が宣言されていれば [ファイルベース名](URL) あるいは [表示テキスト](URL) に書きかえるよう自作フィルタを改良した。

これでリンク元 Markdown ファイルではリンク先ノートの URL を記述しておく必要がなくなり、普通に Obsidian ノートして書くだけでよくなった。めでたし。

情報のアーカイブとして使う Obsidian vault ではノートタイトルの先頭を日付にする

いろいろ入れている Obsidian vault のノートタイトルの先頭を日付に戻す

ファイル名の先頭を日付にする派だが、 Obsidian では「内部リンクが醜くなる」「グラフビューが醜くなる」ということもあり、デイリーノートやプロジェクトのノートなど何でも入れてみている Obsidian vault でデイリーノート類以外についてしばらくタイトルから日付を外してみていた。しかし日付がタイトルにないとやはり検索時に日付順に並べ替えられなくて不便だった。

情報のアーカイブとしても使う Obsidian vault ではノートタイトルの先頭を日付にする方が便利だな。 YAML front matter に書いておいた日付をタイトルにつけ直した。

Obsidian Publish サイトのノートタイトルは先頭を日付にしないままにする

Obsidian Publish サイト nNodes は知のネットワークのスナップショットとして更新していくので、引き続きノートタイトルには日付を含めないままにする。

Obsidian vault の目的によって命名規則を使い分けるのがいい。

[ ファイル名の先頭を日付にする ]