{方向}{十分}{}{進捗記録}{進捗}{希哲17年4月14日の開発}{希哲17年4月14日の進捗}{希哲17年4月14日}{知った時}{それ以上に}(71)

{希哲17年4月14日14歩 K#F85E/E74C-CD6D}

{一通り}{一箇所}{十分}{}{サービス}{進捗記録}{進捗}{デライト}{希哲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 というように置換しておいた

{設定}

{}