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

感謝

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

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

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

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

代表的デライター

埋め込み YouTube 動画で www 無しの場合に認識されなかったり，余計な求頼文字列が文字列として表示されてしまう不具合修正で終了。出振るい・手定め済み。

特に YouTube に関してはこの手の修正を繰り返しているが，あまり外部サービス URL の判定を厳密にすると相手サービス側の実装変更に対して脆弱になるため，今後は適度に緩やかな判定をすることにした。

ふと思い立ち，制脳のため，久しぶりに葛西臨海公園サイクリングを再開した。その甲斐あって，夜からは絶好調だった。

ぶらっと走って，少し休憩してきても2時間以内で帰ってこれる。脳爆発の反動でどうせ日中ぼーっとしてしまうことが多いのだし，これほど時間対効果の高い気分転換もない。また外出予定のない日が続く時期の日課にしたい。譜類添付機能実装後，またよく写真を撮るようになっているので，多少は献典整備にもなるだろう。

デライトの完全な成功に向けて突き進む日々の中で，どうしてもデライトに足りないものについてばかり考えてしまいがちだが，デライトが得てきたものの多大さをもっと自覚すべきだな，と思ったりした。

デライトの原点，あるいは正体を思い起こせば，明日にでもあのサービスに勝てるかどうかとか，その水準の悪戦苦闘が出来るようになっているだけで奇跡的な達成だ。デライト正式離立前の希哲13年にもこの公園をよくぶらぶらしていたことを思い出しながら，そんなことを考えていた。

Twitter 危機が深刻さを増す中で，次から次に代替 SNS の話題が膨らんでは萎んでいる。デライトはダークホース中のダークホースだ。ここで勝てば日本も世界も一変するという舞台に，勝てる武器を持って立てている。この日々の有り難さと楽しさを満喫しなければもったいない。

新着確認機能実装を一段落させた。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 というように置換しておいた。