強制録落ちに関する接渉管理見直し。

まず，握接毎の無駄な譜類上書きを無くした。これだけで衝突耐性はかなり上がっただろう。手定め環境でさっきすぐに再現した強制録落ちが再現しなくなった。

具体的に検討してしまうと，多糸譜類ロックの設計は意外と難しく，早まると禍根を残しそうだ。前縁・後縁間で録入り状態に齟齬があった場合の違了処理を先に実装すべきなのだろう。

いずれにせよ作業の時期は見極める必要があるので，とりあえずここで出振るいし，いったん輪郭選り手抜控機能整備に戻ることにした。手定め済み。

（進捗時限記録中略）

全知検索整備の方針検討で終了。

2月23日頃から検索結果の改良について本格的に考え始めていたが，「検索属性」を導入し，検索結果の多段化を進めていくことにした。

現状，例えば括弧類を自動付加した検索は出来るが，その逆は出来ない。括弧付きで描出したい場合，括弧無しで検索して既存輪郭が無いことを確認した後，括弧を付けて再検索するということが多く，とりあえずこの手間を無くしたかった。全知検索演算子の制御に任意の括弧類を使えると好都合ということもあった。

文字数の昇順で揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが，上手く行かない場面が多々あるので一時凌ぎの域を出ない。

将来的な拡張性も考えると検索結果の多段化が好ましい。風船輪郭や輪括内検索にも応用出来る。希哲14年7月30日8歩から輪括内検索は輪括内のみにすると使いにくいという理由で中途半端な状態になっていたが，優先表示で解決出来ることに気付いた。

整数値に揃えを兼ねた役割を与え，これを「検索属性」として利用出来るようにする。

ここまでは良いが，効率的な実装が難しい。単純に全ての検索パターンを UNION で結合すればひどいことになるのは目に見えている。外充て函数で余計な検索を省くようにする，挿入・更新時に確定出来る情報はフラグ化しておくといったことに加えて，後縁での出力は最低限にして前縁で追加取得するといった工夫が必要になるかもしれない。

いずれにせよ後縁の対応は進めて問題ないだろう。設計方針さえ固まれば最適化はどうとでもなる。

こまごまとした問題を片付けた。

• 全知検索窓に <input type="search"> を導入。
  • 以前導入を試みた時は WebKit が余計な装飾・機能を加える問題で面倒臭くなり type="text" に戻した。
  • 諸場舞覧では柔品キーボードに検索ボタンが表示されるなど多少の恩恵がある。
• 輪郭ページと前後景検索ページで×輪結（未録入りでは扉への輪結になっているデライト語体）・共有ボタンの表示条件を共通化し，常に×輪結か扉輪結に加えて共有ボタンを表示するようにした。
  • これまで，輪郭ページでは共有ボタンと未録入りなら扉輪結，前後景検索ページでは×輪結のみと切り替えていた。
    • 自分でも輪郭ページからの戻り方に迷うことがあった。
  • 共有ボタンが見えやすくなった。
  • 未録入りでは前後景検索ページの×輪結が扉輪結になり，若干操作性の問題があるが，誘導効果もあり微妙なところなので様子見。
• 「Ctrl + ダブルクリック / Enter で描き出す」としていた通注を「Ctrl + Enter（ダブルクリック）で描き出す」に変更（再描出フォームでは「〜で完了」）。
  • 一見意味が分かりにくかったが，ダブルクリック操作を主としていた歴史的経緯なども絡み，分かりやすく簡潔な表現にしにくかった。
  • 最近のボタン用合いの進歩もあるので，ここはキーボード操作を優先にしていいだろう。
• 後縁で出力する JSON の越化が出来ていなかった問題を修正。
• ほか装体調整など。

就寝前に閲覧専用模動に関して閃きがあり，また脳爆発が始まってしまった。

漠然と，中景部の角丸周辺がボタンとして使えそうだとは思っていたが，これで吹き描きを長方形にして前後景部を隠し，さらに中景輪符の波括弧を角括弧に変えれば吹き描きの意味ともデラングとも調和する。詳細はまだ練る必要があるが，かなりの有力案になりそうだ。

外部スクリプトの選択的読み込みに関する交度整理。

ついでに，埋め込みツイートも同様に後縁から出力させるようにした。

widgets.js の選択的読み込みはスクリプトで行っていたため，描画過程が露出しているのが気になっていた。これにより解消するかと思ったが，気休め程度に改善したような気はするものの，やはり描画過程は見える。

ただ，公式ページも含めてどこもそんなものなので，割り切ることにした。デライトの場合はファーストビューに入りやすいせいで気になるのかもしれない。

未出振るい。

気になっていたデライト高速化に関する問題をいくつか片付け，出振るいした。結果として大きな体感表示速度の向上が見られた。

離立備立・デバッグ備立の切り分け

やや混乱していた kn cpl などを整理しながら，離立備立とデバッグ備立を切り分けられるようにした。5月のデバッグ出力整備でデバッグ出力と録出力を切り分けておいたことも奏功し，作業は円滑に進んだ。

これまで，本番環境でも deln.fcgi も libxtd も xpo.Pg もデバッグ出力を無効化していなかった。特に大きな負荷になる要素ではないが，高負荷時の性能低下要因を極力減らしたかった。

精神衛生的な面でも効果が大きかった。長い実験段階を終え，一つの製品として完成に向かうデライトを象徴する出来事のような気がして嬉しかった。

デライトの WebP 対応

一般用者の自我アイコンも WebP 化を完了し，添付画像を除き，現時点で出来るデライトの WebP 対応は完了した。

添付画像の仕様再検討

先月31日12歩ではすっかり忘れていたが，互換性の問題があるため，当面は元画像と WebP を共存させておくことにした。特に，Safari の対応が遅かったため，まだ WebP への統一は時期尚早だろう。

非対応舞覧の市影は小さく，デライトにおける譜類添付機能もそれほど本質的な付徴ではないため，割り切って無視出来なくもないかとも考えた。いずれにせよ，気になるのはストレージ容量なので，それが問題になるまでは様子見することにした。

外部スクリプトの選択的読み込み

輪郭を含むページで無条件に読み込んでいた KaTeX と highlight.js を，必要な場合だけ後縁で出力させるようにした。

体感表示速度への影響はこれが一番大きかった。

交度記法における言語の管理にも応用出来る。

全知検索整備についての検討で終了。

全文検索にはとりあえず pg_bigm を採用しておくことにした。知名検索でも中間一致検索の性能は課題だったので，これも解決出来そうだ。後方一致検索に関しては，PostgreSQL 9.1 から reverse() が組み込み函数として提供されるようになっているので問題ないだろう。

後縁の実装はどうとでもなるが，難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので，まずは検索演算子として各種機能を実装したい。これに関しても，だいぶまとまってきた。

カンマを AND 検索に使うという構想があったが，& ボタンとの兼ね合いもあるので，まずは無難に & か AND で AND 検索，| か OR でOR 検索に対応することにした。除外検索は条件次第で - を使えるようにしてもいいだろう。

部分一致検索については，省略記号 ... とダッシュ記法を応用した --- に対応する。

描写検索については，基本的には昨年7月27日3歩の方針を踏襲し，末尾に ?? を加える形で対応することにした。デラングとの兼ね合いで検索寸片をどうするかという課題は残るが，デライトではそれほど多用するものではないので，まずは普通に引っかかるだけで十分だろう。

一つの可能性として，検索ボタンをダブルクリック／ダブルクリックで検索対象を切り替える機能があってもいいかもしれない。

いずれにせよ，まずは既存の検索語変換交度を whr_kw() にまとめる作業から始めることになるだろう。

主にデライト高速化，違了処理整備。

Aejs の整理をしつつ，前縁の違了処理実装を大方終えた。

ついでに，崩れていた問題発生ページ，保守作業中ページを整え直し，出振るい作業などに再び活用出来るようにした（19歩）。

これらの作業により，用者・検索演心への影響を最小限に抑えながら後縁に手を入れることが出来るようになり，信頼性・開発効率の大きな向上が見込める。

後回しにしてきた課題だったが，デラング整備に加えてデライト高速化まで活発化している今，後縁の出振るい頻度が高まり，それに伴う不具合の増加・多様化も予想されるため，ここで解決しておきたかった。

デラング整備，埋め込み部区実装，@Tw 実装。

ツイートの埋め込みが一段落して終了。

埋め込み記法によるツイート埋め込みは前縁でやるべきかと思ったが，CORS の問題で素直には出来そうになかったので後縁で処理することにした。

Cμ に JSON ライブラリが必要になったため，以前の調査で見つけていた RapidJSON を仮に使っておくことにした。

後縁からは script 要素を出力しないようにし，@Tw では，公式寸片を参考に，blockquote.twitter-tweet を発見したら効率的にウィジェットを読み込むようにした。

ツイート埋め込みに関してはとりあえず十分なものが出来た。

3日の開発から6日間に渡って続いたデライト小理腑をいったん終えた。

結果的には主に装体書整理とテンプレート整理だったが，これにより，保守性と体感表示速度の大幅な向上が見られた。

装体書とテンプレートは，Cμ によるデルン初期実装から長いこと継ぎ足しで使ってきたため，古い記述や譜類に埋もれて目的のものが探しにくいといった問題が慢性的にあった。分割すべき記述が一つの譜類に詰め込まれている，逆に，一つにまとめておくべき記述が複数の離れた譜類に分散している，といったことがよくあった。今回の小理腑ではこの点が大きく改善した。

テンプレートの方は折に触れて整理してきたからまだマシだったが，装体書の方は適当に分割した譜類に大量の記述が詰め込まれている状態だった。そもそも SySS の備立すら適当で，.syss 譜類があっても .scss が無いと換配されないなど，多数の譜類を管理出来る状態では無かった。これを機に備立方法から整備した。

装体書整理は当初，HTML の肥大化を恐れて埋め込み装体書の見極めに時間をかけ過ぎてしまっていたが，この日，JavaScript や HTML に gzip 圧縮がかかっていなかったことに気付いた。ちょっとした deln.conf の間違いだったが，これをきっかけに吹っ切れ，作業が捗るようになった。結局，転送量を大幅に削減出来た分，多少の冗長性には目を瞑ることにした。

これら作業の結果として，目的の装体やテンプレートにすぐ握接出来るようになり，埋め込み装体書の調整等も的確に行えるようになった。

表示速度は，ページにもよるが，DOMContentLoaded までの計測値で0.5秒近く短縮した。これに装体適用の合理化も加わり，体感表示速度ははっきり向上したのが分かる。溶明の動き付けをいったん削除したのも大きいかもしれない。デライト初期実装で読み込みの中途半端な遅さを誤魔化すため0.3秒の溶明を入れていた。

現時点でここまで高速化に繋がったことは思わぬ収穫だった。これまで，「デライト高速化」は後縁の最適化を中心に考えてきた。後縁の最適化余地の大きさと負荷軽減を重視していたこともあり，前縁最適化は期待も重視もしていなかった。

希哲13年の前縁改革で前縁の重要性は分かっていたつもりだったが，まだ認識が甘かったようだ。これに気付いたことも大きな収穫と言えるだろう。

そもそもスクリプトの動的読み込みに使っている @icl() とその周辺整理によって生じた描画乱れ解消のために始めた作業で，あまり多くは期待していなかったが，結果的に大収穫となった。

ただし，10日までに盛り込むつもりだった付徴が後回しになり，デライト収益目標達成にどう影響するかは不透明だ。

問題が解消するまで出振るい出来ず，他の作業が出来なくなっていたこともあり，作業項目としてのデライト小理腑はここでいったん完了とすることにした。整理が必要な部分はまだまだ残っているが，ほとんどは漸進的に作業出来る部分だ。いま出来る範囲でまとまった時間を使ってやる理腑はこれが限度だろう。