{使い方}{開発}{開発記録}{}{}{1}{0}{サービス}{デライト}{希哲17年4月11日の副日記}(203)

{希哲17年4月11日の開発 K#F85E/E74C-7F12}

新着確認機能実装一段落させた10日12歩修正ともに出振るい手定め済み

新着確認機能により輪郭一覧更新状況ぐっと把握しやすくなったサービス性質上自動更新など気が散る実装避けてきたが,あちこちページ画面切り替えながら作業していると,輪郭一覧鮮度気になることが多々あった必要以上に輪郭一覧更新する癖がつく問題もあった

実装要点次の通り

新生デライト開発当努としての新着確認機能実装優先順位が低く,最後の方になるかと思っていた最近になって,メニューアイコン使えること,輪数必要ないこと,交差監視使えること,と立て続け実装上気付きがあり,高い時間対効果負荷対効果望めるようになっていた。

マイクロブログなどの投稿数異なり1輪長文もあれば10輪知名のみの輪郭もあるのがデライト輪数なので,文脈限定せずましてや2桁程度表示幅では情報量尺度として機能しないことに気付いた

全知検索窓固定機能採用した交差監視使えることに気付いたのが駄目押しだった。無駄な再読み込み抑制する効果望めるとはいえ,多少なりとも立求が増える機能なので,悪影響懸念拭えずにいた。交差監視によって無駄なく効果的に待機状態制御出来る見通しが立った流石に高速化までは行かないにしても,十分な低負荷実装になった。

{進捗記録}{}{以前}{知名}{0}{希哲16年9月}{進捗}{デライト}{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_fgn_bgNULL初期化することでいったん解決

他にも _kt_oln_1_kt_oln_20になっている輪郭がないか調査したところ,一つだけ K#DF1B/0000 があった新規描出時印 2019-02-28 23:56:22。これはデライト開発最初期希哲13年2月28日のツイストで,当時の記憶をよく残しているものなので,複製輪郭作ってから輪括とともに削除した

もう体裁にこだわっていても仕方ないので公開手定め(テスト)でやっていくことにした。

http://delite.kitetu.com/

恐らく手定め用思われる自我から描出しているのもおかしい混乱期だったのだろう。前後景輪数表示不具合修正では以前にも同様の不正知番発見したことがあり希哲15年4月16日4歩やはり何らか引き金になった可能性はある。

{}{0}(2)
{0}

{}