{開発}{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲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年12月21日の開発}{希哲16年12月21日の進捗}{希哲16年12月21日}{不具合の原因}{違和感の原因}{戻らない}{再入力時}{押した後}(66)

{希哲16年12月21日10歩 K#F85E/E74C-3B09}

{開発}{デラング}{開発記録}{一通り}{知番}{点検}{希哲16年12月18日の副日記}{小さく感じる}{越化参照化}{復活させた}(253)

{希哲16年12月18日の開発 K#F85E/E74C-8AE4}

新生全知検索整備中間出振るい

領下手定め環境概ね問題なさそうだったため,新生全知検索整備中間出振るい踏み切った首尾良く完了し,大成功だった。これにより後縁最新の状態同期され自由自在開発体制取り戻した

21時30分出振るい作業開始断帯21時30分から約5分23時頃までには一通り点検不具合修正終えた

その後動作極めて安定しているdg_fnd() への輪数取得処理組み込み今回初出振るいとなるが,高速化効果は,毎回輪数計算必要になる場合検索数十ms求頼1回分短縮なので体感速度向上あまり期待していなかったしかし意外と検索時軽快感増している気がする最初はプラセボ効果近い開発者心理かと思ったが,自分の全知検索歴検索頻度考えれば感じ取れてもおかしくはない嬉しい誤算だった。

輪符知番輪結改良

安心して後縁手を入れられるようになったので,手始めに輪符生成する輪結で,第零番節付き知番そのまま輪結先などに反映されてしまう問題修正した

これにより,輪符知番K#9-XXXX/A-YYYY記述されていても,輪結先第零番節の削除をした /?fg=KNo.XXXX/YYYY/KNo.XXXX/YYYY となる。第二次知番改良経て司組生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符第零番節付き輪結生成していたため,クロール効率への悪影響懸念された出与え属性通して輪郭小窓知番表示にも反映されていたため,用合い上の問題なくはなかった

とりあえずは量が多い基本形輪符重い強調輪符でのみの対応

読み込み中...
{進捗記録}{進捗}{希哲16年7月15日}{希哲16年7月13日}{希哲16年7月15日の開発}{希哲16年7月15日の進捗}{希哲16年7月13日の開発}{把握しておいた}{わずかに}{反対の結果}(70)

{希哲16年7月15日12歩 K#F85E/E74C-70FE}

{進捗記録}{進捗}{希哲16年4月7日}{👍}{輪結}{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{ページ遷移無し}{停止する}{フォームの送信}(75)

{希哲16年4月7日14歩 K#F85E/E74C-D3A9}

進捗時限記録中略

細かい装体調整など。

iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元iPhone同様現象があり,気になっていたデライトの不具合にしては不可解なのでもしかしたら舞覧稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。

結局諸場舞覧自動拡大機能であり,text-size-adjust-webkit-text-size-adjust)という制御用CSS プロパティまで用意されていることが分かった。以下のようにして解決

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ諸場舞覧気になっていたことに,輪結ボタンタップ時妙な効果入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有機能で,-webkit-tap-highlight-color不可視出来た


スマホ弄っているうちに,iOSSafari全知検索ボタン動き付け止まっていることに気付いた

これはフォームの送信などで描画処理停止する Safari 特有仕様であることが分かったSafari の問題といえばそうだが,実用上の問題はなく,まともな解決策無さそうなので放っておくことにした。

全知検索整備方針定まったことだし,そろそろページ遷移無し輪郭一覧更新出来るようにしてもいい頃だろう。

{進捗記録}{}{進捗}{background}{画段}{希哲15年12月10日の開発}{放置していた}{ややこしそう}{役立った}{稲妻形引用部区 Safari 修正後}(40)

{希哲15年12月10日10歩 K#F85E/E74C-6D52}

稲妻形引用部区調整終了

これまでは「引用部区の装体・再改良後」を意図して以下のように background指定していたが,Safari では画段境界部分目立ち,変に立体的見えてしまう問題があった修正前

background: linear-gradient( 45deg, lightgray 50%, transparent 52% ), linear-gradient( 135deg, lightgray 50%, transparent 52% ), whitesmoke;

これを以下のように修正すると問題解消した修正後

background: linear-gradient( 45deg, lightgray, lightgray 50%, transparent 50%, transparent ), linear-gradient( 135deg, lightgray, lightgray 50%, transparent 50%, transparent ), whitesmoke;

ずっと気になっていた問題ではあったが,実用上の問題があるわけではなくややこしそうなので放置していた単純な解決策見つか良かった手定め機初めて本格的に役立った

{デラング}{『希哲日記』}{希哲11年}{金風}{日記}{振り返り日記}{用者}{デライト開発}{手定め}{遠ざかる}(93)

{希哲15年10月27日の日記 K#F85E/E74C-57D7}

昨日開発環境整備一環として消極的に考えていた SLFS 開発の再開だが,献典整備としての可能性もあることに気付き,新生デライト開発とともに再開することを決めた

当然ながら無駄に新生デライト開発圧迫するわけにはいかないので,相乗効果生み出すようにやっていきたい

SLFS希哲11年実用化してから,あえて深追いすることを避けてきた。ほとんどは実用上の問題が生じた時に設定パッケージ引装などを行うくらいで,それも SLFS 開発というよりは用者として使っているという感覚であり,事実上開発停止状態に近かった。

直接収益化結び付けるのは極めて困難予想されたため,パッケージ下信ダウンロード引装インストール手定めにかかる時間最小化するための極力良いネット環境高性能開発機,そして十分な時間用意する必要があると考えていた

SLFS希哲社にとっても大きな財産だったが,自分で使っているだけということに「死蔵」というべきもったいなさ常々感じていた時間の経過とともに忘れていること増え保守性落ちていた。これを改めて実感したのが昨日の核脳カーネル周りの調査だった。

SLFS 開発から遠ざかるようになっておよそ一年後デライト開発に入り,デラングも含めて描出環境描出手法飛躍的な発展遂げ今にいたる。希哲11年に比べ,技術記録もはるかに描き出しやすくなっている金風によって多少の時間的余裕も出来た。

こうした環境の変化によって,気付けば十分な時間対効果見込めるようになっている。SLFS にもようやく世に出せる時が来たということだろう。新生デライト開発の再開前に何かが引っかかっていたが,この時を待っていたのかもしれない。それなら遅らせた意義もある。


昨日に続き5時前起床は出来たが,短時間睡眠続きなので早く寝ることにした。

28日振り返り日記

{進捗記録}{進捗}{kn fly}{kn mk}{省割}{希哲15年9月9日の開発}{多用する}{mk}{fly}{希哲15年9月9日の進捗時限}(29)

{希哲15年9月9日13歩 K#F85E/E74C-8F24}

知機駒手方針再検討終了

これまで,「知機模動」を用意する,_ 接頭子を使うなどで省割出来るようにすることを考えてきたが,どれも中途半端実用上の問題があるため,混同の恐れがない知機駒手に関しては {kn K#F85E/A-5B28-27FA} を省ける省割提供することにした。

とりあえず,最も多用する kn mkkn fly対応した mkfly追加する。

{進捗記録}{}{描写}{進捗}{描写部}{選り手}{希哲15年3月10日の開発}{閲覧模動}{編集模動}{実用上の問題}(40)

{希哲15年3月10日11歩 K#F85E/E74C-C3D3}

描出フォーム仕様について検討

現状,知名欄描写欄が離れている描出フォーム装体について,両方開いている場合は合体させることにした。

美観上の問題も感じており,この自体は当初からあったが,もともと両欄は個別に開けるようにしていたため,挙動との整合性などを考えると難しい問題だった。

個別に開ける仕様自体は,閲覧模動編集模動区別明確にしつつ,出来るだけ操作感WYSIWYG に近付けたいという考えから編み出したもので,作業対象が絞り込みやすいこともあり維持したい。

少しずつ実装が変わり,最近では両欄が開いている時は一つの選り手とみなすようになっているため,合体させても違和感がなく,中止ボタン導入などを考えるとむしろ合体していた方が直感に適う。

これに関連して,中景部中景輪符描写部以外の部分を [Ctrl] + ダブルクリックして両欄を開くようにすることにした。これ以前から最近考えていたことだが,丁度良い。

現状,同操作は中景輪符描写部に対してのみ有効で,中景部の他の部分では反応しなかった。これは直感に反する挙動でもあり,描写部が空の場合の代置語を削除した最近の実装では同操作で描写欄が開けないといった実用上の問題もあった。

{実用上の問題}

{}