{用影}{希哲17年1月14日の開発}{復活させたい}{思い入れが無い}{忘れた場合}{希哲17年1月14日の進捗}{希哲17年1月14日}{暗証語再発行用メールアドレス}{検討を進めている}{外充て函数化}...=}(146)

{希哲17年1月14日10歩 K#F85E/E74C-1CAF}

=}
{譜類添付機能}{希哲17年1月13日}{希哲17年1月12日の副日記}{作業出来なかった}{取っておく}{調整しやすい}{揃えやすい}{抜控サイズ}{限界に近付いている}{12ヶ月分}...=}(77)

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

{デライト}{src 属性}{<script>}{希哲16年12月19日の副日記}{付かない}{https:}{ツイートの埋め込み交度}{不正出与え修正}{〈delloon〉}{添えて}...=}(192)

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

自我ページ風船輪郭

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

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

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

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

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

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

読み込み中...
{デライト}{描写}{大輪郭整備}{知番}{知名}{希哲16年12月14日}{説明出来る}{大きな障害}{軟らか過ぎず}{硬過ぎず}...=}(193)

{希哲16年12月14日の日記 K#F85E/E74C-B161}

ちょっとした用事片付け第二次快調期からまともに出来なくなっていた書類整理少し進め,あとは大輪郭整備考え事をして過ごした


考え事での大きな収穫として,文書整備かかわるデライト用語体系方針まとまった

デライト用語体系関しては従来の輪郭法新用語体系基礎に,初心者向け分かりやすい代替用語導入などを検討していたが,これはやめ基本的に新用語体系そのまま踏襲し,説明体系洗練させていくことにした。

例えば知名を「輪郭名」,知番を「輪郭番号」などと説明することを考えていたが,元々技術としての固有性独立性高い知番関しては早々に断念していた。「輪郭名」などを補助的に導入するかどうかで最後まで迷っていたのが知名だった。この問題考える上で,「知名」という用語妥当性についても再考する必要があった。

知名」の必然性について直感的な確信はあったものの,言語化意外と難しかった。それを象徴するかのように,いつからか輪郭知名」の選り手開きっぱなしで,再描出下書き抜控一覧実装した頃から常に表示されている唯一の輪郭になっている。

知名単なる記事名」でも「題名」でもなく,森羅万象付けることが出来る認知上名前であり,その性質既成語では表現出来ない更に,「輪郭の名前」として輪郭従属するものではなく,あくまでも知の名前」として理解される必要がある。そうでなければ,そもそも輪郭目的として扱っているのか分からなくなってしまうし,自己目的化しかねない。ここに知名という用語必然性がある。輪郭とは,知の名前知の番号そのもの具現化するものだ。

この方向説明体系洗練させていけば,代替用語複雑化招くだけのものになる。「急がば回れ」で,多少時間はかかってもデライト正しく理解出来る説明をしていくべきだろう。この点において,特に輪郭」「知名」「知番」「描写」といった基礎用語には動かしがたい正しさ”があり,それは十分わかりやすく説明出来るようやくその確信持てた

読み込み中...
{知番}{希哲16年9月18日}{希哲16年7月}{希哲16年6月}{希哲16年9月18日の副日記}{適用される}{着手した}{大変だった}{一山越えた}{解決時}...=}(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()
読み込み中...
{希哲16年8月21日}{希哲16年8月20日}{希哲16年8月の開発}{_dg}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}{選択肢が増える}...=}(102)

{希哲16年8月20日の開発 K#F85E/E74C-1175}

応答速度異常に遅い輪郭についての不具合調査から求頼改良出場改良アイデアまとまり,一気に実装した

_dg_dg_oln結合しないと揃え出来ず揃え極端に遅くなる場合があることは認識していたが,時印追加することは正規化観点から避けてきた

公開設定機能導入必要性が低くなった揃え用時印廃案にすることを最近考えていたが,これに近い役割持たせた ts_fgts_bg追加することを思い付き,急速にまとまった単なる複製ならやはり避けたかったが,より抽象的な時印_dg持っていることは不自然ではなく,同期引き入れ再描出処理行うだけでいい。

手定めしてみると,低負荷求頼では索引使われず有意差見られなかったものの,高負荷求頼では数倍から十倍程度までの高速化見られた求頼最適化選択肢が増えることでサービス全体負荷抑制見込める

領下での実装手定め終えたが,稼動させながらの _dg修正無理そうなので明日早朝出振るいすることにした。


これにより応答速度異常に遅い輪郭についても改善見られたが,異常であることは変わらず根本的な解決にはならなかった。

当初輪括膨大な輪郭特有の問題だろうと思っていたが,一見何でもなさそうな輪郭でも発生している

これは別途調査することにした。


ここで,検討していた揃え用時印ts)は正式に廃案とすることにした。

簡単な時印更新可能になり,公開設定機能目立たせない再描出可能になったので必要性感じなくなった。となると実装用合い複雑化懸念大き過ぎる

{検討していた}

{}