{開発}{開発記録}{十分}{悪い意味}{希哲17年1月20日の副日記}{概念的に}{両記法}{とらわれない}{態勢に入っていた}{理解しやすくする}(164)

{希哲17年1月20日の開発 K#F85E/E74C-D455}

全知検索演算子についての検討1歩交度埋め込み記法実装方針検討数式記法含めた概念整理5歩知名デラング対応方針についての検討7歩交度記法対応言語スクリプト動的に追加する方法についての検討12歩など,検討作業よく捗った

実作業も,交度写し取りボタン実装13歩16歩交度埋め込み記法調整などそこそこ捗ったが,特に大きかったのは,交度埋め込み記法数式記法概念整理出来たことだった。

交度埋め込み記法数式記法概念整理

交度埋め込み記法では,対応言語texlatexkatex追加したこれまで katex のみを追加するつもりだったが,意図の明示という観点から使い分けられる方が望ましい例えばKaTeX という実装こだわらず LaTeX書きたいということは十分に考えられる

また,これまで数式記法KaTeX 交度埋め込み記法糖衣構文程度考えていたが,ここで「数式のための TeX 風記法」と位置付け直すことにした。これにより,例えば mhchem などの数式以外応用交度埋め込み記法使うといった使い分け可能になる


Mermaid 対応以後交度埋め込み記法KaTeX対応する機会を窺っていた。これは同記法考案した時点考えていたこと希哲16年2月15日18歩で,いずれ対応するつもりではあったが,30分もあれば十分だろうという実装コストの低さにもかかわらずいまいち気が乗らなかった

数式記法糖衣構文として再定義する,それ以上意義見出せなかった整合性という大義名分はあったが,悪い意味での冗長性加えるような感覚もあり,なんとなくぼんやりしたすっきりしないものを感じていた

読み込み中...
{開発}{開発記録}{希哲13年}{出振るい}{SySS}{付徴}{握接}{理腑}{デライト高速化}{希哲15年4月8日の日記}(104)

{希哲15年4月8日の開発 K#F85E/E74C-86B0}

3日の開発から6日間に渡って続いたデライト小理腑をいったん終えた。

結果的には主に装体書整理テンプレート整理だったが,これにより,保守性体感表示速度大幅向上が見られた。


装体書テンプレートは, によるデルン初期実装から長いこと継ぎ足しで使ってきたため,古い記述譜類に埋もれて目的のものが探しにくいといった問題慢性的にあった。分割すべき記述が一つの譜類に詰め込まれている,逆に,一つにまとめておくべき記述が複数の離れた譜類に分散している,といったことがよくあった。今回の小理腑ではこの点が大きく改善した。

テンプレートの方は折に触れて整理してきたからまだマシだったが,装体書の方は適当に分割した譜類に大量の記述が詰め込まれている状態だった。そもそも SySS備立すら適当で,.syss 譜類があっても .scss が無いと換配されないなど,多数の譜類を管理出来る状態では無かった。これを機に備立方法から整備した。

装体書整理は当初,HTML の肥大化を恐れて埋め込み装体書見極めに時間をかけ過ぎてしまっていたが,この日,JavaScript や HTML に gzip 圧縮がかかっていなかったことに気付いた。ちょっとした deln.conf間違いだったが,これをきっかけ吹っ切れ作業捗るようになった。結局,転送量を大幅に削減出来た分,多少の冗長性には目を瞑ることにした。

これら作業の結果として,目的の装体テンプレートにすぐ握接出来るようになり,埋め込み装体書調整等も的確に行えるようになった。


表示速度は,ページにもよるが,DOMContentLoaded までの計測値0.5秒近く短縮した。これに装体適用合理化も加わり,体感表示速度ははっきり向上したのが分かる。溶明動き付けをいったん削除したのも大きいかもしれない。デライト初期実装読み込み中途半端遅さ誤魔化すため0.3秒の溶明を入れていた。

現時点でここまで高速化に繋がったことは思わぬ収穫だった。これまで,「デライト高速化」は後縁最適化中心に考えてきた。後縁最適化余地の大きさと負荷軽減重視していたこともあり,前縁最適化期待重視もしていなかった。

希哲13年前縁改革前縁の重要性は分かっていたつもりだったが,まだ認識が甘かったようだ。これに気付いたことも大きな収穫と言えるだろう。


そもそもスクリプト動的読み込みに使っている @icl() とその周辺整理によって生じた描画乱れ解消のために始めた作業で,あまり多くは期待していなかったが,結果的に大収穫となった。

ただし,10日までに盛り込むつもりだった付徴後回しになり,デライト収益目標達成にどう影響するかは不透明だ。

問題が解消するまで出振るい出来ず,他の作業が出来なくなっていたこともあり,作業項目としてのデライト小理腑はここでいったん完了とすることにした。整理が必要な部分はまだまだ残っているが,ほとんどは漸進的作業出来る部分だ。いま出来る範囲でまとまった時間を使ってやる理腑はこれが限度だろう。

{交度}{希哲13年9月2日のツイスト}{希哲13年9月2日}{ツイスト}{論組屋}{冗長性}{抽象化}{コード}{プログラマー}{日本人}(10)
{冗長性}{データベース設計}(2)

{データベース設計における冗長性 K#F85E/891E}

状態を表わすカラムは多少冗長でも作っておくべきか


あるデータのなんらかの状態を,最小限のカラム構成に保存しようとして既存のカラムの値の組み合わせで表現しようとしてしまいがちだ。

この場合,以下のような問題が起きやすい。

  • 明示性が無い(定義を知らなければその状態がどう保存されているのか分からない)
  • SQLやプログラム内での判定方法が複雑になる(アルゴリズムの複雑化)
  • 仕様変更に弱い(カラム間の関係性を利用するので,仕様変更に伴うバグが起きやすい)

よほど形式的に固められたシステムでない限り,柔軟性を損なう事が多い。

多少冗長でも,状態を表わすカラムを作っておくのが得策。

{冗長性}

{}