{CSS}{WebP}{希哲17年4月16日の副日記}{希哲17年4月16日}{必要が生じる}{希哲17年4月の開発}{にわかに}{引き締まってきた}{関しても}{インポート機能}...=}(27)

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

主にインポート・エクスポート機能仕様検討（6歩，7歩，8歩）。

にわかにインポート機能の実装イメージが固まり，それに伴いエクスポート機能の実装イメージも引き締まってきた。

アイコンなどの画像形式に関しても，WebP と CSS の使い分けで当面の方針が固まった（2歩）。検討していた SVG 化は必要が生じるまで見送る。

=}(4){希哲17年4月16日8歩}{希哲17年4月16日7歩}{希哲17年4月16日6歩}{希哲17年4月16日2歩}
{希哲17年4月1日の開発}{希哲17年4月1日の進捗}{希哲17年4月1日}{切り替え用合い}{折り返し有り}{折り返し無し}{処理中}{rgba( 255, 255, 255, .5 )}{被り過ぎていた}{横スクロールバー}...=}(62)

{希哲17年4月1日8歩 K#F85E/E74C-6494}

（進捗時限記録中略）

交度部区装体調整で終了。

だいぶ洗練された（調整前・調整後）。装体のみ出振るい済み。

=}(2){交度部区の様子・装体調整後}{交度部区の様子・装体調整前}
{希哲17年3月3日の副日記}{利用出来た}{描写装体}{画面右下}{:focus}{以前に比べて}{<body>}{希哲17年3月3日}{省割キー一覧の様子}{?}...=}(63)

{希哲17年3月3日の開発 K#F85E/E74C-48B7}

諸場用合い改良。

装体整理などを進め，以前に比べて挙動がだいぶマシになったところで中断。出振るい・手定め済み。

省割キー整備。

省割キー一覧の表示・非表示を切り替える ? を実装した。出振るい・手定め済み。

とりあえず，簡単な一覧を画面右下に表示するようにした（様子）。閉じる用合いはスクロールやボタンを検討していたが，当面は ? によるトグルで十分そうだ。

小窓装体や描写装体を利用出来たので思ったよりすっきりした実装になった。

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

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

（進捗時限記録中略）

認証周りの全体的な検討を進めて終了。

暗証語再発行機能については，いくつかの仕様が明確になった。

暗証語再発行機能

再発行用メールアドレス

再発行用メールアドレスは同じものを複数の自我で登録可能とすることにした。

出場上での重複を禁じた場合，過去に適当に登録して忘れているせいでメールアドレスが使えなくなることが考えられる。登録時には確認用 URL への握接を要求するので他人のメールアドレスを登録することは出来ないが，自分でも忘れるのはネットではよくあることだ。

この場合，メールアドレスから自我が一意に特定出来なくなるが，これは問題ないだろう。どのみち暗証語再発行手続きでは，メールアドレスから引き出せる情報は最小限にしたい。多用するものでもないので，自我知番は都度入力してもらえばいい。

自我知番を忘れた場合も想定していたものの，そこまで思い入れが無い自我を復活させたいという人も稀だろう。

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

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

譜類添付機能（5歩，9歩），暗証語再設定機能（13歩），ダークテーマ（17歩）の実装方針が急速にまとまり，新生全知検索整備に戻る前に実装出来る見通しとなった。

エクスポート機能についても，実装時期は未定ながら想定より早期の実装が出来そうだ。

予てより検討していた日次出場抜控の整理方針も概ねまとめた。

とりあえず，当月を除いて直近12ヶ月分の日次出場抜控は温存し，それ以前のものは月内で最初の抜控を除いて削除することにした。最後の抜控よりは最初の抜控の方が日付が揃えやすい。温存期間は3ヶ月や6ヶ月でも大きな問題はないが，あとで調整しやすいように長めに取っておく。

現在の形式での抜控を始めた希哲13年6月6日分から整理作業に着手する。

ディスク容量の圧迫が限界に近付いているので，今後の抜控サイズ増加を考えるとこれ以上先送り出来ない。この日は脳爆発がひどく作業出来なかったため，明日一番にやりたい。

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

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

自我ページと風船輪郭

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

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

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

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

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

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

読み込み中...
=}(9){希哲17年1月4日の開発}{他自我内検索用合い改良兼自我ページ整備}{希哲16年12月22日の開発}{希哲16年12月22日12歩}{希哲16年12月19日の日記}{希哲16年12月19日16歩}{希哲16年12月19日15歩}{希哲16年12月19日14歩}{希哲16年12月19日10歩}
{デライト}{描写}{大輪郭整備}{知番}{知名}{希哲16年12月14日}{説明出来る}{大きな障害}{軟らか過ぎず}{硬過ぎず}...=}(193)

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

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

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

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

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

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

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

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

読み込み中...
=}(1){希哲16年12月14日の副日記}
{輪郭整備}{希哲16年11月21日}{振り返り日記}{日記}{第1木曜日}{週}{まとめられる}{週毎}{月の週番号}{年の週番号}...=}(38)

{希哲16年11月21日の日記 K#F85E/E74C-EFAE}

外出予定が延期になったため，半休で輪郭整備をしながら過ごした。

以前から検討していた，週を固有輪郭として扱う方法がようやくまとまった。比較的直感に適う ISO 8601 を月の週番号にも拡張し（第1木曜日を含む週をその月の第1週とする），これを「希哲館週番号」とすることにした。年の週番号（○年第○週）は日常的に扱いにくいため，主に月の週番号（○年○月第○週）を使うことにした。

これで，各日付の輪郭を週毎にまとめられるようになった。

（23日の振り返り日記）

=}(1){希哲16年11月21日の副日記}
{知番}{希哲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_fg）が1以上なら前景輪情報を取得する（dg_fg()）。
    3. 後景輪数（n_bg）が1以上なら後景輪情報を取得する（dg_bg()）。
  2. 輪郭一覧の輪郭情報を取得する（dg_fnd() か，吊るし輪郭の初期状態は dg_fg()，dg_bg()）。
  3. 各輪郭の自我情報・前後景輪情報を個別に取得する。
    1. 自我隠しが存在しなければ自我情報を取得する（dg_ego()）。
    2. 前景輪数（n_fg）が1以上なら前景輪情報を取得する（dg_fg()）。
    3. 後景輪数（n_bg）が1以上なら後景輪情報を取得する（dg_bg()）。
読み込み中...
=}(14){希哲16年9月18日22歩}{希哲16年9月18日21歩}{希哲16年9月18日20歩}{希哲16年9月18日13歩}{希哲16年9月18日12歩}{希哲16年9月18日11歩}{希哲16年9月18日10歩}{希哲16年9月18日9歩}{希哲16年9月18日8歩}{希哲16年9月18日7歩}...
{希哲16年8月21日}{希哲16年8月20日}{希哲16年8月の開発}{_dg}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}{選択肢が増える}...=}(102)

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

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

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

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

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

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

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

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

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

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

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

=}(13){希哲16年8月20日の日記}{希哲16年8月20日15歩}{希哲16年8月20日14歩}{希哲16年8月20日13歩}{希哲16年8月20日12歩}{希哲16年8月20日10歩}{希哲16年8月20日9歩}{希哲16年8月20日8歩}{希哲16年8月20日7歩}{希哲16年8月20日6歩}...
{検討していた}

{}