19時過ぎ,40℃で約10分の全身浴。入浴剤は久しぶりのエプソムソルト。入浴前後に牛乳,麦茶で水分補給。
給湯器交換後の新しい浴室リモコンに時計が表示されていることに初めて気付いた。これは助かる。時間を計るのに出来るだけタイマーを持っていくことにしていたが,面倒なので実際には体感時間で済ませることが多かった。
添付譜類はあくまでも添え物として最小限の役割に留め,エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。
元々添付譜類は添え物として設計しているが,実際に譜類添付機能が出来,エクスポート機能を実装しようとしてみると,実質的な役割の落とし所が意外に難しい。意図に反して,変に使われ過ぎるのも問題だ。
エクスポート機能では,とりあえずは代替 HTML などで済ませ,ゆとりが出来たら実譜類にも対応するか,などと考えていた。そもそも,どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし,そこまで神経質な人が手元に抜控を持っていないということも考えにくいので,実はさほど必要性の高い付徴ではない。とはいえ,エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから,将来的に対応しないというほどの動機もない。
しかし,添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え,それに伴い譜類保全の責任が増せば,将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様,ここは割り切った用者文化を育てていくべきだろう。
これに気付いてみて,最近,添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが,これも最小限に留めることにした。拡張子制限は制危面もあるが,献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める(例えば .bmp
をそのまま上信して欲しくはない)。
デライトの強みは,知番による意味符号化で文字献典の情報密度を極限まで高め,その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降,その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら,どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。
描出公開原則のように何かこの方針に名前を付けたくなったが,「譜類添付機能」という名前で趣旨は表現出来ているので,それに立ち返るということで十分だろう。
日次出場抜控の整理作業(6歩),当努整理(7歩)を済ませ,デラング整備では Mermaid 対応を終えた(14歩)。出振るい済み。
Mermaid 自体は自分で使う予定もなく,他用者からの要望があったわけでもないが,個人知識管理サービス界隈では人気のある付徴なので一定の客寄せにはなるだろう。
今後の応用可能性を考えると,一年近く前に考案した(希哲16年2月15日18歩)交度埋め込み記法をようやく実装出来たことが一番大きな収穫だった。実際試してみると,Mermaid のような交度を埋め込む記法とはかくあるべきだと強く感じる。Mermaid 対応は交度記法をそのまま使った雑な実装が目立つ。言語開発者としての自信を深めることも出来た。
というか,GitHub 開発者よりデライト開発者の方が賢い証拠ではないか。つくづく不思議だったが,コードフェンスに Mermaid の素出を書いて図表を表示することを思いついた人は,コードフェンスに TeX の素出を書いても数式が表示されない理由について考えなかったのだろうか。それを平気で受け入れる人が多かったということは,それが普通の開発者の言語感覚なのか。