{開発記録}{先入観}{}{}{十分}{デライト}{<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 隠し実装,そして中途半端な状態放置しているページ付け求頼改良があるが,どれも現時点での優先順位低い

読み込み中...
{『希哲日記』}{一段落}{日記}{}{輪郭整備}{希哲17年1月5日の体調}{労をねぎらう}{どっと来た}{疲れて当然}{あれだけ}(62)

{希哲17年1月5日の日記 K#F85E/E74C-32A1}

{進捗記録}{}{以前}{知名}{0}{希哲16年9月}{進捗}{デライト}{NULL}{希哲16年12月19日の開発}(105)

{希哲16年12月19日14歩 K#F85E/E74C-27E0}

進捗時限記録中略

偶然見つけた不正出与え修正終了

「社会」で全知検索した際,応答速度異常に遅かった上に,表示された K#0001輪郭表示おかしかったK#0001輪郭限って前後景輪数異常な数値になっていて,輪郭知番K#0001表示される輪郭があった。

前後景輪数表示不具合以前特に番無しでよく起きていたものと同じで,特定自我全ての輪郭前後景輪数不正な特定の値になっているというものだったが,最近見かけなくなっていた異常に遅いページも,9月までの諸改良なくなっていたので意外だった

出場調べると,不正知番 K#0001/0000持つ輪郭存在することが分かった新規描出時印 2015-12-28 14:17:00特殊用途作ったものかと思ったが,知名が「社会」で,同知名の輪郭とは違って意図全く分からなかった情報価値もなく,デライト依存している部分無いため,これは単純に削除した。すると応答速度正常化したため,応答速度問題に関してはこれが原因であることが分かった

前後景輪数表示不具合例によって n_fgn_bgNULL初期化することでいったん解決

他にも _kt_oln_1_kt_oln_20になっている輪郭がないか調査したところ,一つだけ K#DF1B/0000 があった新規描出時印 2019-02-28 23:56:22。これはデライト開発最初期希哲13年2月28日のツイストで,当時の記憶をよく残しているものなので,複製輪郭作ってから輪括とともに削除した

もう体裁にこだわっていても仕方ないので公開手定め(テスト)でやっていくことにした。

http://delite.kitetu.com/

恐らく手定め用思われる自我から描出しているのもおかしい混乱期だったのだろう。前後景輪数表示不具合修正では以前にも同様の不正知番発見したことがあり希哲15年4月16日4歩やはり何らか引き金になった可能性はある。

{開発記録}{知番}{知名}{描写}{CSS}{filter}{描写部}{希哲16年9月29日}{希哲16年9月29日の副日記}{導入時期}(123)

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

輪郭削除機能実装一段落させ新生全知検索整備り,全文検索機能実装入った

輪郭削除機能

用合い概ね予定通り知名欄描写欄空にする表示される削除ボタン実行する輪郭削除ボタンの様子

削除済み輪郭は,全体半透明化中景輪符知名部薄く削除済み」と表示知番打ち消し線付け描写部には「この輪郭は削除されました。」表示するスクリプト複雑化させないように,前後景輪符×輪結全知検索窓自我アイコン吊るし輪郭以外はpointer-eventsfilter使って CSS のみで無効化するようにした削除済み輪郭の様子削除済み吊るし輪郭の様子

後縁では,知名描写同時に空文字列送信される削除立求認識する出場dg_udrw())では b_delTRUE にし,n_olnn_fgn_bg減算し輪括一括削除する。復元問題もあるため出与え変更最小限留めた

KNEST 隠し最低限同期をさせつつ,効率的な同期不可能他輪郭前後景輪数ある程度不一致許容することにした。未公開輪郭のために使っていた「未公開輪郭が含まれています。」「表示出来ない輪郭が含まれています。」変更してある28日3歩

6月27日の開発dg_udrw() での最低限輪郭削除出来るようになっていたため,用合いの調整程度で終わるだろうと思っていたが,忘れていた輪括KNEST 隠し周りの調整時間がかかった性質上慎重を要する部分でもあった。とはいえ,所要日数3日で,現段階でなければここまで効率的に実装出来なかっただろうという実感があり,導入時期として最適解近いことが分かったので,それはそれで嬉しい発見だった。

出振るい円滑に成功した

全文検索機能

全文検索機能実装とんとん拍子み,出振るいまでもう一息というところまで来た

{『希哲日記』}{写真}{一段落}{日記}{輪郭整備}{希哲16年8月}{デライト}{希哲16年8月31日}{振り返り日記}{18時}(137)

{希哲16年8月31日の日記 K#F85E/E74C-2859}

月末の雑務片付けてから新生全知検索整備入ろう思っていたものの,画像生成人工知能Stable Diffusion使った輪郭整備熱中してしまった50枚ほどの画像作ってみて輪郭のイメージ画像最適だということが分かった。これは大きな発見だ。

少し前から,最近の画像生成人工知能ブームやそれに伴う騒動は,デライトにとって大きな追い風になるかもしれないと思っていた人工知能上手く利用する知能増幅技術意義示しやすくなる理解出来る限られている DeepL などよりもはるかに影響範囲広い

息抜きDream by WOMBO試したこともあったが,ほとんど漠然としたのような画像しか出来ないので具体的な活用法難しく,遊びとしてもすぐ飽きてしまったMidjourney登録制な上に Discord必要という面倒臭さ触らなかった今日Stable Diffusionデモ版見つけて何気なく触ってみたところでデライトとの相性の良さ気付いた

自分で撮った写真色々あるが,輪郭のイメージ画像使うには場面具体的過ぎたり,思い入れがあり過ぎたりしてかえって使いにくい自動生成画像ありそうでないいい加減感じ人間の記憶く,実はぴったりだった。自分で写真を撮ったり絵を描いたりするよりはるかに効率的であることは言うまでもない

元々デライト雑多な画像管理参照向いているので自動生成画像展示にも使えるが,それを目的にするには動機が弱い輪郭整備組み込むことで自然に利用しやすくなるだろう。

Stable Diffusion開素化されたのは今月のことで,輪郭小窓画像サムネイル的に参照しやすくなったのも今月のことだと思う運命的なものを感じる


結局午後18時頃まで輪郭整備熱中し,その後雑務片付け用合い改良微調整不具合修正などをして終わったどの道新生全知検索整備入るには中途半端な日にちだったのでキリが良いといえば良い。

この「第二次用合い改良」も,すでに満足感高いので,ここで一段落とすべきかどうか少し考えた包括的な作業枠組みとして有用ではある。とりあえず用合い関連当努取り込みながら継続することにした。

9月1日振り返り日記

{分かった}

{}