{開発}{開発記録}{先入観}{}{}{十分}{デライト}{<path>}{希哲17年5月4日の副日記}{方針変更}(118)

{希哲17年5月4日の開発 K#F85E/E74C-E5D4}

CSS アイコン実装から動的引連 SVG アイコン実装切り替えることにした。軽く実験してみたやたら捗ったため,改めて早期実装目指すことにした。

昨日の開発記録書いてみてCSS アイコン調整かかる時間馬鹿にならないなと考えながら何気なく Google 検索素出覗いていたら,意外に上手くアイコンSVG表現出来ているなとは思ったが,やはり HTML出力している引連 SVG アイコン気持ち悪い感じたここで,「行き詰まり防ぐための選択肢」として残すことにしていた4月27日の開発記録動的引連 SVG凌ぐことを思い付いた

これまで見てきた解説悪かったか,「SVG煩雑」という先入観がありずっと苦手意識持っていたが,引連 SVG 関しては<path>中心に削ぎ落とせ十分簡潔出来ることが分かった例えば従来のデライト+ アイコン以下の記述十分表現出来る

<svg viewBox="0 0 32 32">
  <path d="M 4 16 H 28 M 16 4 V 28" fill="none" stroke-width="5.5" stroke-linecap="round"/>
</svg>

引連 SVG なので,CSSJavaScript での各部分操作容易だ。直接編集やたら難しい言われているので面倒臭そうだなと思っていたが,何のことはないすぐに習得出来てしまったCSS アイコン調整比べれば直感的ですらあるし,拡縮時品質比べ物にならない。これで外部通類への依存という懸念払拭出来たあとはHTML の肥大化保守性の低下という引連 SVG二大欠点スクリプト補えばいい。動的引連 SVG なら部品再利用十分柔軟に出来る

元々 CSS アイコン中心とした枠組み応付だったので,作ってきた枠組みそのまま活かせるのも嬉しい所だった。動的引連 SVG中心にCSS アイコン応付として交代させるだけで大きな方針変更必要なかった

{開発}{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲17年1月25日の副日記}{多大な効果}(402)

{希哲17年1月25日の開発 K#F85E/E74C-7E8A}

23日の開発から急速に進展したデライト高速化一段落した

テーマ切り替えボタン用合い検討4歩新規描出フォームへの移動機能として吹き描き外背景ダブルクリック用合い復活10歩全知検索ページャー周りの調整16歩こまごまとした領当て装体調整17歩といった雑多ながら充実した作業片付けついに描写後略機能一段落させた21歩出振るい手定め済み

描写後略機能により,デライト最初期から吹き描き構造的問題だった「不必要な出与え読み込み多さ」という問題解消した表示速度向上通信量削減SEO 強化迷惑行為対策など多大な効果見込める

デライト高速化現状今後

昨年末の壊衝不具合修正以後デライト速度安定性ともにウェブ相振りとして十分な水準達していたが,今回の高速化経て明らかにもう一つ壁を越えた感がある体感として,「ウェブ相振りなら特に不満のない速さ」から「単動相振り比べても遜色のない速さ」になった。

一昨年4月9日掲げた全ページ0.3秒以内表示」という目標埋め込み利素考えると現実的ではない気がしてきたものの,軽いページでは200ms台重いページでも概ね300ms台応答出来るようになっている。実感として欲しかった速度手に入れられたし,最適化余地まだまだ残しているので「埋め込み利素除いてほぼ全てページ0.3秒以内表示」なら十分手が届くいよいよ本格的に速さデライトの武器になってきた。

ここで新生デライト開発におけるデライト高速化一段落とし,今後機能追加トラフィック応じた微調整留め別の機能整備集中することにした。

その先デライト高速化については,大きなところでは CDN 導入KNEST による水平拡大請い手隠し機能整備描写 HTML 隠し以外HTML 隠し実装,そして中途半端な状態放置しているページ付け求頼改良があるが,どれも現時点での優先順位低い

読み込み中...
{開発}{デラング}{軽量標記言語}{開発記録}{}{輪括弧}{希哲16年6月}{希哲16年7月21日}{開始する}{輪郭小窓実装}(146)

{希哲16年7月21日の開発 K#F85E/E74C-7F30}

無番輪符改良完了した。これでデルン長年の課題だった輪郭間輪結における知番依存解消した作業中輪符補完機能についての閃きがあり,脳爆発始まった


輪郭選り手上での輪符補完機能は,省割キーあるいはカーソルのある輪括弧表示されるボタン押すことで開始することにした。省割キー仮に Ctrl + {想定しておく。

また,これを機にタッチ端末向け記号入力ボタン本格的に検討することにした。軽量標記言語中心とした用合い課題として記号入力煩雑さがあったため,その解決策兼ねる

ここでようやく輪符補完機能実装イメージまとまった最近のデライト開発では最大の暗部になっていた部分で,極めて大きな収穫言える


漠然と輪郭小窓実装含めていた輪符補完機能だが,ここだけ実装イメージまとまらなかった一時後回しにすることを考えていた理由だった。

原因は,輪符補完自動開始前提としていたことだった。自動開始となると入力中デラング正確に解釈する必要があるが,デラング複雑性考えると交度の肥大化避けられそうになかった深刻な保守性の低下請い手低速化懸念される

更に問題なのは,そこまでの実装コスト払っても,用者体験の向上繋がるとは限らないということだった。この手の挙動好き嫌いがかなり分かれる上に環境との相性問題大きい多くの人満足する水準にしようと思えばキリがない

読み込み中...
{保守性の低下}

{}