「手溢れ修訂(シューティング)」
また新生デライトの要件外ではあるが,ついさっき,急に実装イメージがまとまってしまった輪郭複製機能実装で終了。出振るい・手定め済み。
描写欄が空の状態の新規描出フォームで,自輪郭の輪符を知名欄に貼り付けるかドロップすると輪符から知名・描写が複写される。
複写に成功すると「複写完了」と表示,「複写失敗:自分の輪郭ではありません」と「複写失敗:描写が空ではありません」の違了表示も付け,自我知番の省略にも対応済み。使い勝手は非常に良好。
これまで通り「輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気で考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない。
輪郭複製機能については,昨年5月18日の開発で「知名・描写を複製して新規描出フォームに移動するボタン」として実装することを考えたが,その後の用合い改良を経て,抵抗感が募っていた。
輪郭を直接複製するような機能はやはり避けたい。手軽にし過ぎると誤操作や濫用の可能性が高まる。適切な手間という点で,新規描出フォームへの複写というアイデアは悪くなかった。ただ,現状の輪郭選り手が理想的にまとまっているので,極力ボタンのような要素を追加したくないと思うようになった。
さっきふと,「知名欄への輪符貼り付け」という案について考えていたら,これが急速にまとまってしまった。過去にも何度か脳裏をよぎった案だが,その時はいまいち気乗りしなかった。
貼り付け方式の最初の懸念は誤入力だった。復元ボタンだけでは心許ないので,知名が空であることを条件にしようとしたが,空の知名で書き始めることは少なくないので中途半端だ。複製したい輪郭を検索してから写し取り,貼り付けという流れを考えると,知名欄をいちいち空にしなければならないのは煩雑過ぎる。
間もなく,描写欄が空という条件なら全く問題ないことに気付いた。誤操作の懸念がなくなったので,ドラッグ&ドロップにも対応することにした。
もう一つ,自輪郭のみという制限を付けることにした。描写内の自我知番の省略に Aejs で対応するのが難しいという問題もあるが,濫用され著作権上の手溢れが増えることが予想される。他人の描写の扱いは慎重に,という意味でもこれくらいが適切だろう。
こうしてするする実装イメージがまとまり,一通りの機能を付けた実装も難なく完了した。余計な視覚要素を追加せず,それでいて直感的という,理想的な輪郭複製機能があっという間に出来てしまった。
最初の中間出振るいに成功。これにより,全知検索の応答速度,柔軟性,交度品質が大きく向上した。出振るい作業も円滑に進み,手溢れも無く,全体として大成功だった。
まず,期待通り,輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも,この種のサービスとしては並という程度から,はっきり速いと言える程度になり,快適度が数段上がった感覚がある。
これまでのデライト高速化施策の中でも最大級の効果を感じるが,これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは,相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。
これまで,ページに表示される輪郭情報の取得は,相振りから大体次の流れで行っていた。
dg_oln()
)。dg_fnd()
か,吊るし輪郭の初期状態は dg_fg()
,dg_bg()
)。この旧方式では,KNEST 隠しも一部でしか活用出来ておらず,中景輪数に応じて求頼が増え過ぎる問題があった。1ページあたり最大45回の求頼が発生する可能性があったことになり,当然,相振り・出場間の通信コストがそのまま応答速度低下に繋がっていた。
KNEST 隠し実装を一段落させた6月30日の開発でまとめた方針に基き,これを次のように改良した。
dg_fnd()
)。dg_oln()
)。dg_ego()
)。この新方式により,求頼は最大でも3回で済み,KNEST 隠しも十分に活用出来るようになった。同期と隠しのばら成しも良く,基礎として理想的だ。あとは必要に応じて HTML 隠しなどで補完すれば十分だろう。
upub
を導入した7月から微妙な応答速度低下が気になるようになり,検索演心からのクロール頻度や評価の低下といった悪影響もあったため,輪郭情報取得改良は高速化の特効薬としても新生全知検索整備の最優先当努だった。
最悪見込み違いという不安もなくはなく,これだけ大胆な改良だったので不具合多発の懸念も大きかったが,速度も安定性も申し分ない結果となった。Cμ 文字列処理改良,KNEST 隠し実装,前後景時印の導入といったこれまでの高速化施策がしっかり活かせるようになったのも嬉しい。
4月7日10歩から検討していた「検索属性」もここで「検索群類」として導入に成功し,異なる条件の輪郭一覧を結合出来るようになった。
最初に着手した b_bg_his
の削除もここで本番環境に適用され,上描き履歴は完全に廃止となった。
輪郭情報取得改良は一見単純なようで,実際にやってみると意外に複雑な交度が必要だった。当初,dg_fnd()
の SQL 周りが最難関だと思い込んでいたため,6日の開発での解決時には一山越えたと思ったが,その後のテンプレート処理の方が大変だった。
この誤算で,長いこと放置していたテンプレート周りの乱雑な交度も整理せざるをえなくなり,結果として自分でも驚くほど整理整頓出来てしまった。