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

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

実装の要点は次の通り。

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

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

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

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

（進捗時限記録中略）

隠し破りを KNEST の一部として体系化することにし，仕様まとめと交度修正などを一通り終えた。緊急性は低いため未出振るい。

KNEST では，%Y%m%d%H%M%S 形式の求頼変数を隠し破りとして扱い（例：?20230101000001），デライトでもこれで統一することにした。この時印形式を「詰め込み時印」（ts_jam）と呼んでおく。

隠し破り導入以後，スクリプトや装体書などの主要静的譜類には ?upd=K170101.1 のように，希哲紀元での日付と連番の形式を基本的に使ってきたが，自我アイコン隠し破り対応では ?icon&upd=[Unix 時間] になったり，添付譜類では ?[Unix 時間] になったりと，統一感がなくなってきていた。

実用上はなんでも良かったが，譜類添付機能実装以降は用者の目に触れやすくなったため，簡潔さと分かりやすさを両立させる必要性を感じていた。Unix 時間では非技術者が理解しにくいし，技術者でも意図を理解するのに時間がかかる。それが不安に繋がることは好ましくない。特に簡潔というわけでもない。

確実性を重視するならハッシュを使うのが定石だが，抽象性が低いということでもあり，擬制的に扱いにくく，融通が利かない場面が出てくる。冗長さは一部省略で何とかなるにしても，やはり分かりにくい。

総合的に，詰め込み時印のみが一番無難だろうと結論付けた。更新時印でも整合性を保つやり方はいくらでもある。用者が意図を推測しやすく，開発者も手動で扱ったり異常に気付いたりしやすい。

強いて欠点を挙げるなら，更新日時を知られたくない人もいるかもしれない，ということくらいだが，デライトでは大きな問題ではないだろう。そもそも更新履歴を見られるサービスや投稿と同時に上信される SNS なら秘密情報ではない。

ウェブ捌きの設定などで小細工しやすいように，upd= なり mod= なり ts= なりの値として表現することも再考したが，値として扱うことを想定していない文字列という特殊性を鑑みると，それはそれで違和感がある。14桁数字列の求頼変数は隠し破り，と明確に決めておけば十分だろう。

これを機に，これまでいちいち書き換えてきた主要静的譜類用の隠し破りの更新も，mk の bld-etc で自動化した。テンプレートの一箇所書き換えればいいようになっていたものの，積み重なるとそれなりの手間だった。

自動化するまでもない隠し破りの記述もいくつか残っているが，これは ?upd=K170101.1 なら ?20230101000001 というように置換しておいた。

（進捗時限記録中略）

第二次用合い改良。

途中で終了。

前後景部の同期処理でデラングと自我アイコンに対応。これまで同期処理が走るとデラングは素出になり自我アイコンは消えていた。実用上大きな問題ではなかったが少し気になる部分だったのですっきりした。

ついでにドラッグ＆ドロップ周りの不具合修正。

第二次用合い改良，輪郭小窓実装。

23時頃から中間出振るいへの追い込みを始め，25時頃には出振るいが出来たが，厄介な不具合にてこずった。

まず，本番環境でしか再現しないライブラリの記憶管理絡みの不具合が厄介だった。ただ，C/C++ ではありがちな不具合だと分かり，冷静に修正した。ここは経験に助けられた。

次に，タッチ事象が思うように制御出来ず，タッチ端末での挙動がおかしい問題に悩まされた。これはこれまでタッチ対応を疎かにしてきた経験不足のせいなので，良い勉強だと思うことにした。

結局，実用上大きな問題がない程度に問題を改善した頃には30時を過ぎていた（28歩の後も少し作業）。

まだ中途半端な状態なので，詳しいまとめは明日輪郭小窓実装を一段落させてからすることにした。

（進捗時限記録中略）

第二次用合い改良，輪郭小窓実装。

30時前，なんとか実用上問題ない程度に出来たので寝る。

（進捗時限記録中略）

不具合修正で終了。

最近，実用上深刻な問題ではないものの体感的に壊衝が増えていたが，握接録をよく観察してみると，ほとんど特定パターンの URL で発生していることが分かった。大きな原因は次の2つだった。

• DG_T::cnt_fnd() が番無し輪郭の旧い記法 K#A-XXXX などでの握接時に壊衝していた。
• 存在しないページへの握接時に返す 404 Not Found 用のページ定義が過去の整理で消えていたせいで，ここでも壊衝していた。

これらの URL にボットが握接したことによる壊衝が多発していた。

一応の修正・出振るい済み。まだ小さな問題はあるが，だいぶ安定しただろう。KNEST 隠し実装以後の排他制御の問題だとすると厄介だなと思っていたので一安心。

思わぬ収穫として，体感速度向上がみられる。

壊衝していたということは KNEST 隠しも十分活かせていなかったということで，最近感じていた体感速度低下の一因だったか。upub の導入ばかりが原因だと思い込んでいた。

Cμ 文字列処理改良，rgx_T の置換道手の引数順序変更，客体表現への書き換え。

文字参照周りの整理も終え，ここで「文字参照記法」として原則全ての文字参照を利用可能にした。

これまで，仕様としては未整理だったが，実用上必要性が高かった &，<，>，'，"，*，#，`，{，}，[，] のみが使えた。

これに関しては，実用性も無くはないものの，交度的，概念的にすっきりしたのが大きい。

手定め・出振るい済み。

結局脳爆発は止まらない。

Cμ 文字列処理改良の一服のつもりで，普段後回しにしてしまうような雑多な問題を片付けていたが，ふと思い立って始めた前次記法実装がやたら捗って，それなりのものが出来てしまった。

本当は，全知検索と知名の実用上問題がある部分を少し修正してから Cμ 文字列処理改良に戻るつもりだった。これも良い思い付きだったが，『希哲日記』を中心に前次関係のある描出も多いため，前次記法は出来るだけ早く導入したかった。

もう月庭・デライト転送から1年以上経っているが，そろそろ月庭も復活させたい。デライトだけでは，希哲館事業の全体像を知るのも読み物として読むのも難しい。

いずれにせよ新生デライトにはデラング文書が必要であり，ドメイン毎にサイト展開する範枠も必要になる。それと同時に，中断していた月庭改装を進めたい。「新月庭」を別の意味で使っていたことがあるため少し紛らわしいが，とりあえず「新生月庭」と呼んでおく。

（25日の振り返り日記）

今日は一日がかりで昨日分のまとめを終わらせるつもりだったが，3分の1くらいしか終わらなかった（15日10歩未完）。

それなりの内容でもあり，昨日の反動でぼんやりしてしまう時間があったこともあるが，デラング構想についての考え事が広がったのも大きかった。

文字装飾記法についての整理から，HTML 研究の必要性を感じた。ウェブアプリを作っているので実用上必要なことは当然知っているが，細かい歴史や設計については知らないことが多い。的確なデラング設計のためには表面的な理解では足りない。文字装飾記法でそれを痛感した。

さらに言えば，幅広く標記言語研究をしたくなった。これまでデラングは「理想の軽量標記言語」を目指してきたが，タグ記法によってその範疇に留まらない可能性を感じるようになった。デラングが目指すべきは「理想の標記言語」であって「標記言語の再定義」なのかもしれない。

ティム・バーナーズ＝リーは，WorldWideWeb を作り，URL を作り，HTML を作った。私は，デルンを作り，知番を作り，デラングを作っている。

デラングが発展するにつれ，Markdown が最高の“踏み台”になるという確信も深まる一方だ。やり甲斐に不足はない。