{希哲17年1月11日の開発 K#F85E/E74C-A0C4}
宇田川浩行デラング整備では Mermaid 対応に入った。
全知検索演算子 ?!
や ??
に対応した全知検索ボタンの実装イメージが急速にまとまった。
方向性は変わらないが,用合いや交度のイメージがより明確になった。作業は新生全知検索整備の仕上げ段階になるか。
「簡易通知機能」(名称は12日のまとめ作業で考案)の実装イメージも急速にまとまった。
メニュー下部にくっつけるように通知領域を出すかなどと検討してきたが,領当てのばら成しを考えると,輪郭一覧の上に注意部区に近い形で出すのが無難そうだ。
表示条件は,録入り状態でのみ輪郭一覧がある全てのページを想定しておく。たまに利用規約の更新や保守作業を告知する程度の用途なので,クッキーに最新の確認日時でも持たせておけば十分だろう。
非録入り状態では継続的な用者ではない可能性が高いこと,描出の都度利用規約が提示されることから必要性が薄い。
{希哲16年12月23日の日記 K#F85E/E74C-5C73}
宇田川浩行{希哲16年9月18日の開発 K#F85E/E74C-5BA7}
宇田川浩行最初の中間出振るいに成功。これにより,全知検索の応答速度,柔軟性,交度品質が大きく向上した。出振るい作業も円滑に進み,手溢れも無く,全体として大成功だった。
輪郭情報取得改良
まず,期待通り,輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも,この種のサービスとしては並という程度から,はっきり速いと言える程度になり,快適度が数段上がった感覚がある。
これまでのデライト高速化施策の中でも最大級の効果を感じるが,これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは,相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。
これまで,ページに表示される輪郭情報の取得は,相振りから大体次の流れで行っていた。
- 輪郭隠しにない吊るし輪郭があれば輪郭情報を取得する(
dg_oln()
)。 - 輪郭一覧の輪郭情報を取得する(
dg_fnd()
か,吊るし輪郭の初期状態はdg_fg()
,dg_bg()
)。 - 各輪郭の自我情報・前後景輪情報を個別に取得する。