作業方針検討（4歩），閲覧専用模動実装検討（5歩），デラング整備・埋め込み記法処理改良（8歩〜13歩）。

埋め込み記法処理改良

これまで，埋め込み記法処理の中でも oEmbed を利用したものについては，Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが，埋め込み交度の取得処理を専用 API /mbd に委ね，前縁 Aejs から利用することにした。結果として，応答速度改善に成功した。

埋め込み記法（+[URL]）の URL が oEmbed を必要とする場合，Dex では適当な分類名を付与した <div> に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し，URL を /mbd に転送する。/mbd は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す，という流れになる。過剰な立求を抑止するため，Aejs には簡易的な隠しも持たせておいた。

想像していたよりすっきり実装出来た。

そもそものきっかけは，先日の SlideShare 対応だった。oEmbed が必要になったので，埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ，記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか，引っかかりはあった。

KNEST 隠しを使った SSR 的なことを考えていたことはあるので，その辺の都合だったのだろうと思ったが，現状，そこまで最適化する必要も時間も無い。出来たとして，隠しを有効利用出来る握接パターンは限られている。いずれにせよ，この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで，いったん，埋め込み処理は前縁に移すことにした。

CodePen の <iframe> による埋め込みはどうも UGC での利用を想定していない気がするので，sandbox="allow-scripts" を追加して終了。

手定め済み・未出振るい。

進捗時限法の利用を再開し，律動感を意識して過ごした。

開発では良い閃きがあり，課題だった自我ページと風船輪郭の実装イメージが急速にまとまった。特に，実装イメージが全くまとまらず新生デライトの要件にも入れなかった自我ページの早期実装が視野に入ったことは大きい。新生デライトがより完全なものになる。これがきっかけとなり脳爆発が始まった。

進捗時限法のおかげで何とか乗り切れたが，昨日はろくに休めず，寝不足な上に脳爆発と，体調面では悪条件が重なり，一日脳疲労感を引きずった。食事も睡眠も雑になってしまったので，しっかり生活律動を立て直したい。

（19日の振り返り日記）

新生全知検索整備，ページ付け求頼改良，サイトマップ改良，不具合修正など。

サイトマップ改良の急進展

特に，長いこと課題だったサイトマップ改良が急進展した。

これまでサイトマップは全知検索ページャー同様，一定輪数を LIMIT 句・OFFSET 句で区切ったページを返していた。OFFSET 句の値が多くなると遅くなるため，最大でも最新10,000輪（100輪×100ページ）が限度だった。upub 導入後は更に低速化したため，9,000輪まで減らしていたが，それでも後半になると応答時間が10秒以上になることがあった。

今回のページ付け求頼改良で時印を使ったページ付けに移行しようとしていたため，これをサイトマップにも応用出来るのではないかと考えていたが，サイトマップの場合，サイトマップインデックスで各サイトマップ URL の一覧を生成する必要があり，この効率性が問題だった。HTML 隠しの利用も考えたが，タイミングも難しく，大袈裟過ぎる気がしていた。

サイトマップの場合，各ページの輪数が揃っている必要はないのだから，一定期間で区切ってしまえばいいのではないか，ということに気付いてからは速かった。

まず，デライト上で最古の時印（2012-02-10 19:09:33）から現在時刻までを30日で割って必要なページ数を割り出し，サイトマップインデックスは従来通りの形式（/see?pg=[n]）で生成する。dg_see() ではページ番号から期間を計算してその範囲内で上限輪数までの最新輪郭情報を返す。上限輪数はとりあえず10,000輪にしておいた。数値は様子を見ながら調整していく。

インターフェイスはそのまま利用したため修正は最小限で済み，互換性も維持出来たが，元々 dg_see() に余計な列が多い問題があったのでそのあたりも最適化しておいた。

実作業は出振るい・手定めまで正味3時間ほどで済み，結果として，サイトマップの速度・ページ数・対応期間の長さがはるかに向上した。現在時刻が基準なので，上限輪数から漏れた分も待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性と効率性を完全に両立させることは不可能なので，ここが良い落とし所だろう。デライト特有の要求に適ったサイトマップ設計という，大きな問題がまた一つ解決した。

輪数取得改良，前後景時印の導入などを経て，サイトマップは高負荷求頼が発生しやすい最後の箇所になっていたため，これでデライトの安定稼動における不安要素が払拭出来た。ページ付け求頼改良を急いでいた理由でもあったが，最近の出振るいで，全知検索でもページ番号の直接指定に上限を設けたため，高負荷求頼の問題は一応解決している。これでページ付け求頼改良の優先順位が少し下がった。

（進捗時限記録中略）

14時過ぎ，用者の指摘で2ページ目以降の読み込みが異常に遅い問題に気付き，急遽修正作業。

結局，一昨日出振るいした公開設定機能で，SQL::cnd_prm_rd() が生成する条件式が上手く使えていなかった問題だった。直感的に問題なさそうな単純な条件式だったことと，管理者の自我では無効化していたことで気付かなかった。

1時間ほど SQL や索引をこねくり回して改善しなかったため，残しておいた dg_b_prm_rd() を使ってみたら，これで問題ないことが分かった。とりあえず，SQL::cnd_prm_rd() で dg_b_prm_rd() の呼び出しを生成するようにしておいた。

もともと dg_b_prm_rd() を使うつもりで実装したが，索引の利用などで将来的に問題がありそうな気がして条件式生成に切り替えていた。意外にも反対の結果となった。簡単な手定めではわずかに条件式の方が速い程度だった。条件式生成にもまだ確信が持てず残しておいたのが良かった。

とりあえず実用上の問題は解消したが，手定めしながら今後の課題についても把握しておいた。