もう少し用合いの調整が必要かと思っていたが,高速化・領当て調整で必要十分な形にはなったので次の当努に移ることにした。
やはり輪数取得が性能低下の主要原因になっているため,抜本的な見直しを始めた。
自動ページ展開機能実装が一段落した。細部に課題はあるが,実用出来る水準に達した。出振るい・手定め済み。
これに伴い,正式離立前に試していた全知検索窓や新規描出フォームの固定表示を復活させる検討も大きく進んだ。また,輪郭一覧の動的追加の仕組みを整えたことで,検索や新規描出時にも応用出来るようになった。輪郭一覧の更新が効率的に行えるようになり,高速化にも大きく貢献するだろう。
AutoPagerize 対応をどうするかというのが難しい問題だったが,これは挿入を監視して削除,注意書きを表示する方向に落ち着いた。最初以外 .autopagerize_page_element
に display: none
を設定しておくことで表示には影響しない。
AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者が使っているのを見て私自身が使うようになったというのもあり,用者層の重なりは小さくない。出来るだけ混乱させないようにしたかった。
今後,広告の調整が重要になってくるため,ここで運営者・開発者向けにダミー広告を表示する仕組みを整えた(ダミー広告の様子)。
AdSense は,設置者によるクリックはもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた。
機能的に自動ページ展開機能と似たところがある描写後略機能の実装方針検討もほぼ完了。
内容の高さが高さ制限に足りない場合どうするかが最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した。
輪郭選り手抜控機能整備を概ね終え,ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。
この出振るいにより,中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり,抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また,周辺の交度整理も大きく進み,理腑としての意義も大きかった。
利便性・信頼性の向上はもちろんのこと,昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか,着手して間もないので,ここから思考を整理しやすくなる。
抜控機能整備が長引いた最大の原因は,他にやりたいことが多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間に設計方針が変わったり深刻な不具合に気付いたりしたので,時間をかけたことで円滑に片付いた面もある。
再描出は知番でいいとして,新規描出の鍵をどうするか,というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信の検索語まで取っていたため,これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった(4月28日20歩で書いた消失不具合の原因だろう)。これは求頼文字列から取ることで回避した。
下書き抜控一覧についても,表示条件や領当てなど色々考えることが多かった。検討の結果,再描出下書きは,検索語無しの場合(上部メニュー同様)のみ輪郭一覧の上に表示(画面撮り),新規描出下書きは,他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした(画面撮り)。邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発で決めた通り,一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下,消失リスクの増大(あるいはそれを補う作業コストの増大)に繋がる。目障りになったら消化するようにしてもらいたい。
一番難しかったのは鍵仕様の設計だった。一応,鍵仕様変更時の更新方法は考えていたが,手間を考えるところころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時,鍵に仕様変更日時を含めることを考えていたが,これは複雑化を招くだけなので廃案とし,Aejs_DG_rev
に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め,自我の切り替えにも対応した。
その他,これまで描写のみ保存していたのを知名にも対応する,消去ボタン・復元ボタンを実装する,などこまごまとした問題を片付ける必要があった。
出振るい後,軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが,本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に,3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。
少し迷ったが,時間が経つにつれ重要性が急速に低下する部分なので,調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから,深刻な問題は発生していないと判断した。今後,同様の処理を書く際の注意点として記憶しておく。