{希哲17年4月11日の開発 K#F85E/E74C-7F12}
宇田川浩行新着確認機能実装を一段落させた。10日12歩の修正とともに出振るい・手定め済み。
新着確認機能により輪郭一覧の更新状況がぐっと把握しやすくなった。サービスの性質上,自動更新など気が散る実装を避けてきたが,あちこちページや画面を切り替えながら作業していると,輪郭一覧の鮮度が気になることが多々あった。必要以上に輪郭一覧を更新する癖がつく問題もあった。
- 待機状態では初期化から15秒間隔で4回,20秒間隔で3回,30秒間隔で2回,計約3分間・9回の更新確認を行う。
- 交差監視により,画面内に更新輪結が入ると待機状態に入り,画面外に出ると更新不明状態に入る(更新有り状態ではない場合)。
- 前縁では機能を
@DG.upd
に集約し,他機能からも輪郭一覧更新を促すなどの目的で利用しやすくなっている。 - 後縁では,形式上輪数を返せるように設計しているが,実際には更新有無を表す0・1の二値のみを返す。
- 更新有り表示・不明表示のアイコンは,メニューの「使い方」・「利用規約」の疑問符・感嘆符アイコンに
filter
をかけて使っている。
新生デライト開発の当努としての新着確認機能実装は優先順位が低く,最後の方になるかと思っていた。最近になって,メニューのアイコンが使えること,輪数は必要ないこと,交差監視が使えること,と立て続けに実装上の気付きがあり,高い時間対効果・負荷対効果が望めるようになっていた。
マイクロブログなどの投稿数と異なり,1輪の長文もあれば10輪の知名のみの輪郭もあるのがデライトの輪数なので,文脈を限定せず,ましてや2桁程度の表示幅では情報量の尺度として機能しないことに気付いた。
全知検索窓固定機能で採用した交差監視が使えることに気付いたのが駄目押しだった。無駄な再読み込みを抑制する効果も望めるとはいえ,多少なりとも立求が増える機能なので,悪影響の懸念が拭えずにいた。交差監視によって無駄なく効果的に待機状態を制御出来る見通しが立った。流石に高速化までは行かないにしても,十分な低負荷実装になった。
NULL
}{希哲16年12月19日の開発}(105){希哲16年12月19日14歩 K#F85E/E74C-27E0}
宇田川浩行「社会」で全知検索した際,応答速度が異常に遅かった上に,表示された K#0001
の輪郭表示がおかしかった。K#0001
の輪郭に限って前後景輪数が異常な数値になっていて,輪郭知番が K#0001
と表示される輪郭があった。
前後景輪数表示不具合は以前特に番無しでよく起きていたものと同じで,特定自我の全ての輪郭の前後景輪数が不正な特定の値になっているというものだったが,最近は見かけなくなっていた。異常に遅いページも,9月までの諸改良でなくなっていたので意外だった。
出場を調べると,不正知番 K#0001/0000
を持つ輪郭が存在することが分かった(新規描出時印 2015-12-28 14:17:00
)。昔特殊用途で作ったものかと思ったが,知名が「社会」で,同知名の輪郭とは違って意図が全く分からなかった。情報価値もなく,デライトが依存している部分は無いため,これは単純に削除した。すると応答速度は正常化したため,応答速度の問題に関してはこれが原因であることが分かった。
前後景輪数表示不具合は例によって n_fg
,n_bg
を NULL
で初期化することでいったん解決。
他にも _kt_oln_1
と _kt_oln_2
が0になっている輪郭がないか調査したところ,一つだけ K#DF1B/0000
があった(新規描出時印 2019-02-28 23:56:22
)。これはデライト開発最初期,希哲13年2月28日のツイストで,当時の記憶をよく残しているものなので,複製輪郭を作ってから輪括とともに削除した。
もう体裁にこだわっていても仕方ないので公開手定め(テスト)でやっていくことにした。
恐らく手定め用と思われる自我から描出しているのもおかしいが混乱期だったのだろう。前後景輪数表示不具合修正では以前にも同様の不正知番を発見したことがあり(希哲15年4月16日4歩),やはり何らかの引き金になった可能性はある。