{進捗記録}{一通り}{一箇所}{十分}{}{サービス}{進捗}{デライト}{希哲17年4月10日の開発}{希哲17年4月10日の進捗}(148)

{希哲17年4月10日12歩 K#F85E/E74C-A47E}

進捗時限記録中略

隠し破りKNEST一部として体系化することにし,仕様まとめ交度修正などを一通り終えた緊急性低いため未出振るい

KNEST では,%Y%m%d%H%M%S 形式求頼変数隠し破りとして扱い(例:?20230101000001デライトでもこれで統一することにした。この時印形式を「詰め込み時印ts_jam呼んでおく

隠し破り導入以後スクリプト装体書などの主要静的譜類には ?upd=K170101.1 のように,希哲紀元での日付連番形式基本的に使ってきたが,自我アイコン隠し破り対応では ?icon&upd=[Unix 時間] になったり,添付譜類では ?[Unix 時間] になったりと,統一感なくなってきていた

実用上なんでも良かったが,譜類添付機能実装以降用者目に触れやすくなったため,簡潔さ分かりやすさ両立させる必要性感じていたUnix 時間では非技術者理解しにくいし,技術者でも意図理解するのに時間がかかるそれが不安繋がることは好ましくない特に簡潔というわけでもない。

確実性重視するならハッシュ使うのが定石だが,抽象性が低いということでもあり,擬制的扱いにくく融通が利かない場面出てくる冗長さ一部省略何とかなるにしても,やはり分かりにくい

総合的に詰め込み時印のみが一番無難だろうと結論付けた更新時印でも整合性を保つやり方いくらでもある用者意図推測しやすく,開発者手動ったり異常に気付いたりしやすい。

強いて欠点を挙げるなら,更新日時知られたくないいるかもしれない,ということくらいだが,デライトでは大きな問題ではないだろう。そもそも更新履歴見られるサービス投稿同時に上信される SNS なら秘密情報ではない。

ウェブ捌き設定などで小細工しやすいように,upd= なり mod= なり ts= なりのとして表現することも再考したが,として扱うことを想定していない文字列という特殊性鑑みると,それはそれで違和感がある14桁数字列求頼変数隠し破り,と明確に決めておけば十分だろう。


これを機にこれまでいちいち書き換えてきた主要静的譜類用の隠し破り更新も,mkbld-etc自動化したテンプレート一箇所書き換えればいいようになっていたものの,積み重なるそれなりの手間だった。

自動化するまでもない隠し破り記述いくつか残っているが,これは ?upd=K170101.1 なら ?20230101000001 というように置換しておいた

{大きい}{}(2)
{小さい}{}(2)
{開発}{開発記録}{最大}{}{}{デライト}{希哲16年9月22日}{希哲16年9月22日の副日記}{解決している}{設けた}(164)

{希哲16年9月22日の開発 K#F85E/E74C-FB21}

新生全知検索整備ページ付け求頼改良サイトマップ改良不具合修正など。

サイトマップ改良急進展

特に長いこと課題だったサイトマップ改良急進展した。

これまでサイトマップ全知検索ページャー同様,一定輪数LIMITOFFSET区切ったページ返していたOFFSET多くなる遅くなるため,最大でも最新10,000輪100輪×100ページ限度だった。upub 導入後更に低速化したため,9,000輪まで減らしていたが,それでも後半になると応答時間10秒以上になることがあった。

今回のページ付け求頼改良時印使ったページ付け移行しようとしていたため,これをサイトマップにも応用出来るのではないかと考えていたが,サイトマップ場合サイトマップインデックスサイトマップ URL一覧生成する必要があり,この効率性問題だった。HTML 隠し利用考えたが,タイミング難しく,大袈裟過ぎる気がしていた

サイトマップ場合各ページ輪数揃っている必要はないのだから,一定期間区切ってしまえばいいのではないか,ということに気付いてからは速かった

まず,デライト上最古の時印2012-02-10 19:09:33から現在時刻までを30日って必要なページ数割り出し,サイトマップインデックス従来通り形式/see?pg=[n]生成するdg_see() ではページ番号から期間計算してその範囲内上限輪数までの最新輪郭情報返す上限輪数とりあえず10,000輪にしておいた。数値様子を見ながら調整していく

インターフェイスそのまま利用したため修正最小限み,互換性維持出来たが,元々 dg_see()余計な多い問題があったのでそのあたり最適化しておいた。

実作業出振るい手定めまで正味3時間ほどで済み結果としてサイトマップ速度ページ数対応期間の長さはるかに向上した現在時刻基準なので,上限輪数から漏れた分待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性効率性完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求適ったサイトマップ設計という,大きな問題また一つ解決した

輪数取得改良前後景時印導入などを経てサイトマップ高負荷求頼発生しやすい最後の箇所になっていたため,これでデライト安定稼動における不安要素払拭出来たページ付け求頼改良急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号直接指定上限設けたため,高負荷求頼問題一応解決している。これでページ付け求頼改良優先順位少し下がった

{}

{}