今日も休めないかと思ったが，意外と良い感じに肩の力が抜け，最低限のまとめ作業だけしてゆっくり過ごせた。昼頃散髪に出かけ，帰ってから誕生日であることに気付いた。折角の誕生日くらいはと自分に言い聞かせて半休にしていた。

珍しいことが重なるもので，久しぶりに大きめの地震もあった。

38歳という年齢には，思っていたほど感傷も感慨も無かった。強いて言えば，38歳という若さでよくここまで来られたと思う。これは希哲館事業の巨大さゆえの感情だろう。大事業にとって人生がどれだけ短いか散々思い知らされてきた。

若さというのは本当に相対的なものだなと最近よく思う。20歳くらいの若者がもう若くないなどと嘆いていると滑稽に思えるが，自分が10代や20歳そこそこだった頃も若さを満喫出来ていたかというと，そんな余裕は無かった。無力にもがき，幼さを憎み蔑んでいた。自分の若さを楽しめるようになったのは30代からだ。

老いへの恐怖は後悔と似ている。少なくとも，あの頃に戻ってやり直したいと思うことが無いのは幸せなことなのだろうし，これからもそういう最善の日々を生きたい。一昨日友人と話していてそれを再確認した。

（進捗時限記録中略）

動的引連 SVG アイコン実装。

途中で終了。

装体調整中，ダークテーマの共有小窓で <iframe> の背景色が白くなってしまっている問題に気付いた。color-scheme: dark の記述を外すとなぜか直る謎の現象だが，舞覧のバグにしては Firefox でも Safari でも Chrome でも再現する。現象自体は共有小窓以外でも起こっている。少し前から埋め込みツイートの角が白くなる現象が気になっていたが，同じ原因らしい。color-scheme は4月1日9歩で導入したが，すでにダークテーマの常用をやめていたので気付かなかった。

いまいち納得出来ないが，とりあえずダークテーマ時の <iframe> に color-scheme: normal を設定することで凌ぐことにした。

もしかしたら，ダークモードでは黒文字が黒背景に溶け込まないように透過背景を白背景にしているのかもしれない。

未出振るい。

デライトも公開から2年半ほど経ち，色々な人が興味を持ってくれたり，使ってみてくれたりした。遠くから眺めているだけの人，登録してみただけの人，たまに使う人，いつも使っている人……風変わりなデライトでも，出会った人の多様性は他のサービスとさして変わらない。

感謝

私は，そんな全ての“デライター”とデライターの卵達に深く感謝している。付き合いの長さも深さも関係ない。デライトに否定的な人ですら，知ってくれただけでありがたいと思う。

これがよくある社交辞令ではないということは，前回の一日一文，「デライトの歩み」を読めば分かるだろう。そもそも全く無謀な挑戦として始まったのがデライトだ。成功どころか，誰にも認められず終わるかもしれない。それならまだいい。弾圧や暗殺で命を失うかもしれない。10代の内にそこまで想像して葛藤を乗り越え，20年かけてここまで来た。

たとえるなら，デライトの歩みとは，真っ暗な巨大洞窟を一人で彷徨うようなものだった。どこかに新しい世界につながる出口がある。生きている内に辿り着けるかどうかは分からない。そんな洞窟を歩き続けていた時に見えた光，聞こえた人の声。それが私にとってのデライト利用者であり，デライトへの声だ。

そして今，デライトは「完全な成功」一歩手前と言えるところまで来ている。すでに夢のようなことだ。感謝せずにいられるだろうか。

代表的デライター

姉一家が来て少し騒がしかったが，動的引連 SVG アイコン実装では大きな手応えがあった。

一日一文を書きながら，知能増幅メモサービスとしての行き詰まりが KNS に救われたことと，CSS アイコン実装の行き詰まりが動的引連 SVG アイコン実装に救われたことが似ているのに気付いた。どちらも，次善の策として残しておいたものだ。

多様な選択肢の大切さを実感すると同時に，デライト市場戦略の少しまとまりに欠けると感じていたところが，実は大切な柔軟性だったということにも気付けて嬉しかった。

何かと気付きの多い一日一文の重要性も再認識したため，今日から毎日きっかり1時間（2歩分）だけ輪郭整備兼一日一文にあてることにした。

元々1時間程度で書ける内容というのは意識していたことだが，結局時間をかけ過ぎてしばらく書けなくなるということを繰り返してきた。一日で書き切れないということはもう常態化しているので，書けても書けなくても1時間で切り上げる。一日一文だけだと気が乗らない時に困るが，輪郭整備兼一日一文なら何かしら思考整理や献典整備に繋がるだろう。

よほど忙しい日や休養が必要な日は仕方ないとして，しばらく実験してみる。

（6日の振り返り日記）

（進捗時限記録中略）

デライト全体における添付譜類の方針検討で終了。

添付譜類はあくまでも添え物として最小限の役割に留め，エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。

元々添付譜類は添え物として設計しているが，実際に譜類添付機能が出来，エクスポート機能を実装しようとしてみると，実質的な役割の落とし所が意外に難しい。意図に反して，変に使われ過ぎるのも問題だ。

エクスポート機能では，とりあえずは代替 HTML などで済ませ，ゆとりが出来たら実譜類にも対応するか，などと考えていた。そもそも，どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし，そこまで神経質な人が手元に抜控を持っていないということも考えにくいので，実はさほど必要性の高い付徴ではない。とはいえ，エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから，将来的に対応しないというほどの動機もない。

しかし，添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え，それに伴い譜類保全の責任が増せば，将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様，ここは割り切った用者文化を育てていくべきだろう。

これに気付いてみて，最近，添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが，これも最小限に留めることにした。拡張子制限は制危面もあるが，献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める（例えば .bmp をそのまま上信して欲しくはない）。

デライトの強みは，知番による意味符号化で文字献典の情報密度を極限まで高め，その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降，その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら，どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。

描出公開原則のように何かこの方針に名前を付けたくなったが，「譜類添付機能」という名前で趣旨は表現出来ているので，それに立ち返るということで十分だろう。

設定ページ整備，エクスポート機能実装に戻った。

エクスポート機能ではひとまず輪括情報無しで出力することを考えていたが，外充て函数で輪郭形式の出力をしてしまえばかなり効率化出来ることに気付いた。dg_xpt() の実装を検討する。

新着確認機能実装を一段落させた。10日12歩の修正とともに出振るい・手定め済み。

新着確認機能により輪郭一覧の更新状況がぐっと把握しやすくなった。サービスの性質上，自動更新など気が散る実装を避けてきたが，あちこちページや画面を切り替えながら作業していると，輪郭一覧の鮮度が気になることが多々あった。必要以上に輪郭一覧を更新する癖がつく問題もあった。

実装の要点は次の通り。

• 待機状態では初期化から15秒間隔で4回，20秒間隔で3回，30秒間隔で2回，計約3分間・9回の更新確認を行う。
  • 捌き手の応答時間が長い時でも立求が詰まらないように，立求処理の完了後に遅来させる。
  • 輪郭一覧が更新されている場合，更新有り表示を行い停止する。
  • 輪郭一覧が更新されないまま9回の更新確認を終えると，更新不明表示を行い停止する。
• 交差監視により，画面内に更新輪結が入ると待機状態に入り，画面外に出ると更新不明状態に入る（更新有り状態ではない場合）。
  • 初回ページ読み込み時の始動も交差監視で行っているため，吊るし輪郭が長い場合，舞覧がスクロール位置を復元した場合など，更新輪結が見えなければ動作しない。
  • 更新不明状態の更新輪結が画面内に入ると，即座に更新確認を行い，最初から待機状態に戻る。
  • 全知検索窓固定機能同様，デライトにとって本質的な機能ではないため，新着確認機能自体 Intersection Observer API が使える環境でのみ有効とすることにした。
• 前縁では機能を @DG.upd に集約し，他機能からも輪郭一覧更新を促すなどの目的で利用しやすくなっている。
  • 引き入れ用合い改良からやりたかった，吊るし輪郭の輪括操作時の更新有り表示も実現出来た。
  • 再描出時にも更新有り表示に対応しておいた。
• 後縁では，形式上輪数を返せるように設計しているが，実際には更新有無を表す0・1の二値のみを返す。
  • 元々新着輪数表示を考えていたが，現時点では実用上不要と判断した。
  • 将来的な拡張は容易な状態になっている。
• 更新有り表示・不明表示のアイコンは，メニューの「使い方」・「利用規約」の疑問符・感嘆符アイコンに filter をかけて使っている。
  • 最初，赤・黄色の組み合わせを試したが，必要以上に目立ち過ぎ，違了にも見えてしまうため，黄色・灰色に落ち着いた。

新生デライト開発の当努としての新着確認機能実装は優先順位が低く，最後の方になるかと思っていた。最近になって，メニューのアイコンが使えること，輪数は必要ないこと，交差監視が使えること，と立て続けに実装上の気付きがあり，高い時間対効果・負荷対効果が望めるようになっていた。

マイクロブログなどの投稿数と異なり，1輪の長文もあれば10輪の知名のみの輪郭もあるのがデライトの輪数なので，文脈を限定せず，ましてや2桁程度の表示幅では情報量の尺度として機能しないことに気付いた。

全知検索窓固定機能で採用した交差監視が使えることに気付いたのが駄目押しだった。無駄な再読み込みを抑制する効果も望めるとはいえ，多少なりとも立求が増える機能なので，悪影響の懸念が拭えずにいた。交差監視によって無駄なく効果的に待機状態を制御出来る見通しが立った。流石に高速化までは行かないにしても，十分な低負荷実装になった。

譜類添付機能調整で終了。

JPEG，PNG の場合は一律最大長辺1920pxとしていたが，画面撮りなどで問題があることに譜類添付機能紹介文の様子を添付してみて気付いた。無駄に縮小されてぼやけてしまう。

とりあえず，自動縮小には「1MiBを越えた場合」という条件を加えた。

出振るい・手定め済み。

（進捗時限記録中略）

添付譜類埋め込みでの PDF 埋め込みについての検討で終了。

要望を受けた当初はデライト向きではないなと感じたが，やりようによっては悪くないことに気付いてから，するすると実装方針がまとまってしまった。

最初は Poppler の pdftoppm で切り出した1ページ目の画像を表示しておき，クリック／タップすると PDF.js とともに読み込みを開始する。これならすぐにでも実装出来そうだ。画像化は ImageMagick でも出来るようだが制危上の問題があるらしい。

PDF.js の輪郭は希哲7年に描き出しているが，流石に昔過ぎてすっかり忘れていた。