{開発}{開発記録}{先入観}{}{}{十分}{デライト}{<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年4月28日の開発}{希哲17年4月28日の進捗}{希哲17年4月28日}{保たれている}{高めず}{渡配無し}{調整出来る}(121)

{希哲17年4月28日6歩 K#F85E/E74C-9EF4}

進捗時限記録中略

デライトにおける νSJavaScript渡配トランスパイルについての検討などで終了

しばらくES5 への渡配やめて様子見することにした。備立環境調整済み次回の前縁出振るい本番環境にも反映されるだろう。

希哲13年8月23日の開発以来νS では ES2015基礎にしているが,同時に Babel導入し配信スクリプトES5渡配していた。それから4年近く経ちデライトの舞覧対応方針洗練されES2015対応舞覧十分な市影有しているもはや ES5 との互換性引きずるべきではないと判断した

とりあえず--presets 応付子外してbabel --no-babelrc --minified --no-comments だけで換配するようにしてみると,ae.js譜類サイズ20kB近く減った譜類サイズ削減以上にスクリプト複雑化伴うオーバーヘッド増加抑制期待出来る

ES2016 以上交度うっかり紛れ込む紛れ込んでいる可能性考えるES2015 への渡配をしておいた方がいいかと思ったが,どうもそういう考え方をする時代でもなく,Browserslist使った手法主流らしい。確かに舞覧対応状況非常に流動的なので実態合わせる方が合理的ではあるが,ブラックボックス化避けたいこれまで通り導入付徴対応状況個別に把握しておくことにした。デライトの能力活かせるだろう。

いずれにせよ Babel の設定後からいくらでも調整出来るので,いったん渡配無し様子見する


ついでに変数名などの短縮などについても再検討したが,やはり外部通類への依存度高めず保守性維持するのは難しいため見送った交度英語おかげで一定の短縮性保たれている

{進捗記録}{}{十分}{知番}{意味符号化}{抜控}{進捗}{デライト}{👍}{希哲17年4月17日の開発}(148)

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

進捗時限記録中略

デライト全体における添付譜類方針検討終了

添付譜類あくまでも添え物として最小限の役割留めエクスポート機能でも実譜類出力には今後対応しない方針固めた

元々添付譜類添え物として設計しているが,実際に譜類添付機能出来エクスポート機能実装しようとしてみると,実質的な役割落とし所意外に難しい意図に反して,変に使われ過ぎるのも問題だ。

エクスポート機能では,とりあえずは代替 HTML などで済ませゆとりが出来た実譜類にも対応するか,などと考えていたそもそもどんな大企業クラウドであれ消えて困るような譜類唯一の保管場所にすべきではないし,そこまで神経質な人手元抜控持っていないということも考えにくいので,実はさほど必要性の高い付徴ではない。とはいえエクスポート時負荷帯域だけが問題なら金で解決出来るのだから,将来的に対応しないというほどの動機もない

しかし添付譜類エクスポート出来てしまうことで譜類倉庫的な利用増え,それに伴い譜類保全責任が増せば,将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた描出公開原則同様,ここは割り切った用者文化育てていくべきだろう。

これに気付いてみて,最近添付譜類役割広げようとし過ぎていたことにも気付いた譜類添付機能サイズ上限拡張子制限緩和考えていたが,これも最小限留めることにした。拡張子制限制危面もあるが,献典として非効率だったり無意味だったりする譜類上信抑止といった効果望める例えば .bmpそのまま上信して欲しくはない

デライトの強みは,知番による意味符号化文字献典情報密度極限まで高め,その軽さ最大限に活かせることだ。譜類倉庫的な方面消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降,その微妙揺らいでいることはうっすら感じていた今日は妙にもやもやしていると思ったら,どうもがそれを訴えていたらしい。気付いたら非常にすっきりした

描出公開原則のように何かこの方針名前を付けたくなったが,「譜類添付機能」という名前趣旨表現出来ているので,それに立ち返るということで十分だろう。

{開発}{開発記録}{右側}{}{}{デライト}{希哲17年1月4日の副日記}{比較的深刻}{復元出来ない}{それ以外}(246)

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

いったん出振るい終え他自我内検索用合い改良兼自我ページ整備一段落した

開発時間確保しにくい時期だったことや交度整理時間をかけたことで12月22日着手してから日数かかったが,総合的に満足出来る結果となった。

特に実装時期予測すら出来なかった自我ページ整備出来たことが大きい。これで新生デライト像完全なものになった。自我ページ整備自体作業時間正味2日間程度で,時間対効果非常に高かった

今後はまず新生全知検索整備り,輪郭整備兼文書整備並行させ新生デライトの成立目指すことになる。

実装について

12月19日の検討通り他自我内検索時に自我アイコン並べ自我ページではこれをプロフィール風見せることにした整備後1整備後2

見ただけではまずやり方分からなかった他自我内検索整合的かつ直感的に行えるようになり,自我知番による検索結果過ぎず一見意味の分からない自我ページ整備前一応プロフィールページらしくなった。

自我ページは,デライトにおける自己表現入り口となる部分であり,初めてデライト触れたまず覗いてみる部分でもあるので,直感的に理解出来るようになったことは大きな進歩言える最低限の又情報設定したので多少の SEO 効果望めるあとは風船輪郭出来ればデライトプロフィールページとしては無駄なく十分なものになるだろう。

読み込み中...
{開発}{開発記録}{最悪}{最大}{}{十分}{知番}{サービス}{希哲16年7月}{希哲16年6月}(238)

{希哲16年9月18日の開発 K#F85E/E74C-5BA7}

新生全知検索整備

最初の中間出振るい成功これにより全知検索応答速度柔軟性交度品質大きく向上した出振るい作業円滑に進み,手溢れ無く全体として大成功だった。

輪郭情報取得改良

まず,期待通り輪郭情報取得方式改良により応答速度大きく向上した体感的にもこの種のサービスとしてはという程度から,はっきり速い言える程度になり,快適度数段上がった感覚がある

これまでのデライト高速化施策の中でも最大級の効果感じるが,これはボトルネック解消によるところが大きい6月Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果大きさ比べて本番環境での効果かなり小さい感じるようになっていた。考えられるボトルネックは,相振り出場間の通信回数多過ぎる輪郭情報取得処理だった。

これまでページ表示される輪郭情報の取得は,相振りから大体流れ行っていた

  1. 輪郭隠しにない吊るし輪郭があれば輪郭情報取得するdg_oln()
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
  2. 輪郭一覧輪郭情報取得するdg_fnd() か,吊るし輪郭初期状態dg_fg()dg_bg()
  3. 各輪郭自我情報前後景輪情報個別に取得する
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
読み込み中...
{開発}{開発記録}{最短}{}{}{知番}{Aejs}{希哲16年6月17日}{完成の域に達した}{表記的}(146)

{希哲16年6月17日の開発 K#F85E/E74C-9EA6}

自我知番省略機能実装終え第二次知番改良完了とした20歩ここでやっておこう思ったのも,途中で第零番節の削除転換したのもあまりにだったが,その割には終始円滑にり,収穫想定はるかに越えて多大だった。全体として大成功言っていいだろう。

第二次知番改良経て知番表記的にも内部的にも完成の域に達した。あとは仕様実装微調整繰り返していく

まず,当初の目的だった知番の簡略化言うまでもなく大きいこれまで一般のデライト用者最短でも K#9-XXXX/A-YYYY という15文字知番輪郭扱う必要があった。それが第零番節の削除によって11文字K#XXXX/YYYY になり,自我知番の省略によって7文字K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度出場整理劇的に進んだ。これにより,効率性保守性大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫繋がった未実装だった自動知番拡張もここで実装出来た今のところ第二番節しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。

波及効果想定以上に大きかった出場見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮見込めるようになった特に見通しが悪い課題だった KNEST 隠し出与え構造がこの期間固まり,一気に実装可能性高まった自我知番省略機能Dex との連携必要になったことで,他の記法でも活かせる出与え共有機構整った。これが無番輪符改良などにも繋がっている

将来的に長い知番増えた時のための「知番略記法」を中心とした第三次知番改良方針固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番省略された知番写し取り時自我知番付け自輪郭描写欄などへの貼り付け時自我知番の省略をする4月8日の開発記録,というのは,やはり用合いとしては理想的盛り込みたかったが,今回見送った。このあたりの事象Aejs整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{活かせる}

{}