{希哲17年1月16日の副日記}{この手の}{埋め込み献典}{検討しておく}{発生しうる}{客体変数}{無駄な通信}{タグ削除}{通信時間}{従来の方式}...=}(242)

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

作業方針検討4歩閲覧専用模動実装検討5歩デラング整備埋め込み記法処理改良8歩13歩

埋め込み記法処理改良

これまで埋め込み記法処理の中でも oEmbed利用したものについては,Dex 内で埋め込み交度取得直接描写 HTML埋め込んで返していたが,埋め込み交度取得処理専用 API /mbd委ね前縁 Aejs から利用することにした。結果として応答速度改善成功した

埋め込み記法+[URL]URLoEmbed必要とする場合Dex では適当な分類名付与した <div>出与え属性URL埋め込んで描写 HTML返すAejs ではそれを検知し,URL/mbd転送する/mbdURL対応したサービス埋め込み交度oEmbed取得して返す,という流れになる。過剰な立求抑止するため,Aejs には簡易的な隠し持たせておいた

想像していたよりすっきり実装出来た


そもそもきっかけは,先日の SlideShare 対応だった。oEmbed必要になったので,埋め込みツイート使っていた Dex 内の oEmbed 埋め込み方法取り急ぎ使った。ただ,記法処理範枠同期通信処理組み込むというのは正気の沙汰ではないなんでこんな実装になっているのか,引っかかりはあった。

KNEST 隠し使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状そこまで最適化する必要時間も無い出来たとして,隠し有効利用出来る握接パターン限られているいずれにせよこの種の埋め込み記法利用増えてくれば破綻目に見えている。ということで,いったん埋め込み処理前縁移すことにした。

読み込み中...
{<script>}{希哲16年12月19日の副日記}{付かない}{https:}{ツイートの埋め込み交度}{不正出与え修正}{〈delloon〉}{添えて}{新しかった}{兼ねさせる}...=}(192)

{希哲16年12月19日の開発 K#F85E/E74C-E210}

自我ページ風船輪郭

長いこと課題だった自我ページ風船輪郭について良い閃きがあり,急速に実装方針まとまった

現状自我ページURL のみ正規化している/KNo.XXXX内容単なる自我知番での検索結果であり,プロフィールページとしては貧弱過ぎる自我輪郭などのはあったが,既存機能領当てとの整合性をとるのが難しく,自我ページとしてはなかなかイメージまとまらなかったかなり難航しそうだったため,新生デライトの要件にも入れなかった

最近の大輪郭整備必要性強く感じるようになっていたこともあり,もう少し現実的に低コスト実現出来るまとめてみることにした。

まず,他自我内検索用合い既存の自自我内検索整合させるため,以下のように,自我アイコン並べる重ねるかして,& ボタン段階的な切り替え出来るようにする。さらに,自我アイコンの下に「○○さん K#XXXX の描き出しです。」と表示する

これで,全知検索機能性そのままに,プロフィールページ最低限必要アイコン名前表示出来る自我アイコン複数表示自体かなり以前から他自我内検索用合いとしてあったが,これに名前添えてプロフィールページ見出し兼ねさせるというアイデア新しかった

大した作業ではなく,新生デライトの完成遅れ今更なので,これは新生デライトの要件追加することにした。

読み込み中...
{希哲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年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時間ほどで済み結果としてサイトマップ速度ページ数対応期間の長さはるかに向上した現在時刻基準なので,上限輪数から漏れた分待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性効率性完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求適ったサイトマップ設計という,大きな問題また一つ解決した

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

{URL}

{}