{『希哲日記』}{黄金状態}{第一次生活習慣改善}{日記}{輪郭整備}{デライトの完全な成功}{希哲17年6月21日}{3年以上前}{デライト開発生活}{二つの夢}(69)

{希哲17年6月21日の日記 K#F85E/0758-6055}

生活習慣改善甲斐あって顔付き一段と良くなってきた過去最高の状態100点とするなら85点くらいにはなった。3年以上前撮った今のアイコン写真良くも悪くも80点くらいの状態なので,だいぶ取り戻した感があるこのまま100点欲を言えば120点目指したい

デライト開発生活ではなかなか難しかった睡眠改善食事改善大きな課題だ。


最近の生活習慣改善正式に第五次生活習慣改善」と呼ぶことにした。

輪郭整備をしながらこれまでの生活習慣改善について振り返ったりもしたが,やはり生活習慣改善黄金状態デライトあいだには切っても切れないものがある。第一次生活習慣改善デライト開発への助走のようなものだった。最近デライトの完全な成功への期待が高まる中にあって開発ブレーキをかける格好になったのも,心身の状態釣り合っていない感じていたからだ。

私にとって二つの夢同時に叶える唯一の希望デライトの完全な成功であり,黄金状態デライト車の両輪だ。これからの長期安定体制活用し最高の状態釣り合うようにじっくり調整していく

22日振り返り日記

{『希哲日記』}{日記}{}{希哲17年2月}{譜類添付機能}{希哲17年3月31日}{一年毎}{離れられなくなっている}{作業に没頭する}{消耗している}(88)

{希哲17年3月31日の日記 K#F85E/E74C-94C6}

今月の雑務片付き晴れ晴れとした気持ち過ごせるのはずだったが,親戚についての不吉な報せから聞いてしまい気分沈んだ

私自身このまま健康ならあと五十年粘れるが,待ってくれないものもある,という単純な事実思い出させられたここ数年一年毎くらいで似たようなことがあり,似たようなこと考えている気がするそういう年齢なのだろう。

希哲館事業の成功果したには恩返し償い出来ないままいなくなっているかもしれないと思う背筋が凍る雑務なまじ楽しくなってきて良くも悪くも緩んでいた気持ちが,思いがけず引き締まった

とはいえいま自分出来ることデライト開発着実に進めていくことしかない。杞憂消耗していても仕方ないので,気を取り直して平常心作業に没頭することにした。


今月の開発では閲覧専用模動譜類添付機能大きな収穫だったが,新生デライトの完成持ち越しとなった。

特に譜類添付機能中途半端に良い出来で,先月ダークテーマ全知検索窓固定機能のように調整作業から離れられなくなっている早く落とし所見つけたい

いずれにせよ年度替わり集客には不向き時期なので,また黄金週間睨んで調整していくことにした。

{開発}{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲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月25日の開発}{希哲17年1月25日の進捗}{希哲17年1月25日}{縦方向}{誤タップ}{ページ内移動}{定かではない}(109)

{希哲17年1月25日10歩 K#F85E/E74C-7A41}

進捗時限記録中略

吹き描き外背景ダブルクリックダブルタップ新規描出フォーム移動出来るようにして終了出振るい手定め済み

デライト最初期新規描出フォーム固定機能試していた希哲13年8月1日4歩用合いだったが,自分でも驚くほど忘れていた固定機能削除以後何度か再活用検討した記憶はあるが,今ほど全体的な用合い方向性定まっていなかったからか放置していた新規描出フォームへの握接について先日あれだけ検討していたのに全く思い出さなかったついさっきふと思い出した灯台下暗しというやつか。

初見分かりやすい用合い必要なので全知検索窓固定機能輪結予定通り実装するが,スマートフォン右手持ちではタップしにくい位置だとは思っていた個人機でもマウスカーソル移動距離短くない。しかし,これならよくある固定表示ボタンよりよほど賢い上手い補完手段出来た

面白い発見二つあった。

現状幅狭領当てでは吹き描き外背景小さ過ぎ誤タップしやすいが,これは縦方向吹き描きマージン調整していくことにした。

{開発}{開発記録}{希哲13年}{希哲17年1月18日の副日記}{迫られなかった}{目の前のこと}{多い方が良い}{取り戻せる}{触れなかった}{よく弄っていた}(58)

{希哲17年1月18日の開発 K#F85E/E74C-404E}

{開発}{開発記録}{最大}{}{}{デライト}{希哲16年9月22日}{希哲16年9月22日の副日記}{解決している}{設けた}(164)

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

新生全知検索整備ページ付け求頼改良サイトマップ改良不具合修正など。

サイトマップ改良急進展

特に長いこと課題だったサイトマップ改良急進展した。

これまでサイトマップ全知検索ページャー同様,一定輪数LIMITOFFSET区切ったページ返していたOFFSET多くなる遅くなるため,最大でも最新10,000輪100輪×100ページ限度だった。upub 導入後更に低速化したため,9,000輪まで減らしていたが,それでも後半になると応答時間10秒以上になることがあった。

今回のページ付け求頼改良時印使ったページ付け移行しようとしていたため,これをサイトマップにも応用出来るのではないかと考えていたが,サイトマップ場合サイトマップインデックスサイトマップ URL一覧生成する必要があり,この効率性問題だった。HTML 隠し利用考えたが,タイミング難しく,大袈裟過ぎる気がしていた

サイトマップ場合各ページ輪数揃っている必要はないのだから,一定期間区切ってしまえばいいのではないか,ということに気付いてからは速かった

まず,デライト上最古の時印2012-02-10 19:09:33から現在時刻までを30日って必要なページ数割り出し,サイトマップインデックス従来通り形式/see?pg=[n]生成するdg_see() ではページ番号から期間計算してその範囲内上限輪数までの最新輪郭情報返す上限輪数とりあえず10,000輪にしておいた。数値様子を見ながら調整していく

インターフェイスそのまま利用したため修正最小限み,互換性維持出来たが,元々 dg_see()余計な多い問題があったのでそのあたり最適化しておいた。

実作業出振るい手定めまで正味3時間ほどで済み結果としてサイトマップ速度ページ数対応期間の長さはるかに向上した現在時刻基準なので,上限輪数から漏れた分待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性効率性完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求適ったサイトマップ設計という,大きな問題また一つ解決した

輪数取得改良前後景時印導入などを経てサイトマップ高負荷求頼発生しやすい最後の箇所になっていたため,これでデライト安定稼動における不安要素払拭出来たページ付け求頼改良急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号直接指定上限設けたため,高負荷求頼問題一応解決している。これでページ付け求頼改良優先順位少し下がった

{調整していく}

{}