インポート時には,文字化け対策を兼ねた内容の確認表示を挟むことにした。
まず先頭100件を表示,続けて非 ASCII 文字を含む行を検出して10件ほど表示,という感じになるか。
文字交度の自動判別に単純かつ確実な方法は無いので,人間に確認してもらうのが一番手っ取り早い。どのみち,間違った内容で送信される可能性を考えれば下見機能は必須となる。
新着確認機能実装を一段落させた。10日12歩の修正とともに出振るい・手定め済み。
新着確認機能により輪郭一覧の更新状況がぐっと把握しやすくなった。サービスの性質上,自動更新など気が散る実装を避けてきたが,あちこちページや画面を切り替えながら作業していると,輪郭一覧の鮮度が気になることが多々あった。必要以上に輪郭一覧を更新する癖がつく問題もあった。
@DG.upd
に集約し,他機能からも輪郭一覧更新を促すなどの目的で利用しやすくなっている。filter
をかけて使っている。新生デライト開発の当努としての新着確認機能実装は優先順位が低く,最後の方になるかと思っていた。最近になって,メニューのアイコンが使えること,輪数は必要ないこと,交差監視が使えること,と立て続けに実装上の気付きがあり,高い時間対効果・負荷対効果が望めるようになっていた。
マイクロブログなどの投稿数と異なり,1輪の長文もあれば10輪の知名のみの輪郭もあるのがデライトの輪数なので,文脈を限定せず,ましてや2桁程度の表示幅では情報量の尺度として機能しないことに気付いた。
全知検索窓固定機能で採用した交差監視が使えることに気付いたのが駄目押しだった。無駄な再読み込みを抑制する効果も望めるとはいえ,多少なりとも立求が増える機能なので,悪影響の懸念が拭えずにいた。交差監視によって無駄なく効果的に待機状態を制御出来る見通しが立った。流石に高速化までは行かないにしても,十分な低負荷実装になった。