主にインポート・エクスポート機能仕様検討(6歩,7歩,8歩)。
にわかにインポート機能の実装イメージが固まり,それに伴いエクスポート機能の実装イメージも引き締まってきた。
アイコンなどの画像形式に関しても,WebP と CSS の使い分けで当面の方針が固まった(2歩)。検討していた SVG 化は必要が生じるまで見送る。
rgba( 255, 255, 255, .5 )
}{被り過ぎていた}{横スクロールバー}...<pre.cd>
に設定していた padding: .5em
を削除,<code>
に padding: 1em .5em
を設定した。<pre.cd>
の境界との間隔4pxを2pxに縮め,円の背景色を WhiteSmoke
から rgba( 255, 255, 255, .5 )
へと変更した。<code>
の display
変更によるものだったため,予め display: block
を設定しておいた。:focus
}{以前に比べて}{<body>
}{希哲17年3月3日}{省割キー一覧の様子}{?}...装体整理などを進め,以前に比べて挙動がだいぶマシになったところで中断。出振るい・手定め済み。
touchstart
空設定を <body>
直書きから @win
へ移動し汎用化。:active
だけでは効果が一瞬過ぎて分かりにくいことがあるため,ページ遷移を伴う輪結などでは :focus
を活用することにした。省割キー一覧の表示・非表示を切り替える ? を実装した。出振るい・手定め済み。
とりあえず,簡単な一覧を画面右下に表示するようにした(様子)。閉じる用合いはスクロールやボタンを検討していたが,当面は ? によるトグルで十分そうだ。
小窓装体や描写装体を利用出来たので思ったよりすっきりした実装になった。
再発行用メールアドレスは同じものを複数の自我で登録可能とすることにした。
出場上での重複を禁じた場合,過去に適当に登録して忘れているせいでメールアドレスが使えなくなることが考えられる。登録時には確認用 URL への握接を要求するので他人のメールアドレスを登録することは出来ないが,自分でも忘れるのはネットではよくあることだ。
この場合,メールアドレスから自我が一意に特定出来なくなるが,これは問題ないだろう。どのみち暗証語再発行手続きでは,メールアドレスから引き出せる情報は最小限にしたい。多用するものでもないので,自我知番は都度入力してもらえばいい。
自我知番を忘れた場合も想定していたものの,そこまで思い入れが無い自我を復活させたいという人も稀だろう。
譜類添付機能(5歩,9歩),暗証語再設定機能(13歩),ダークテーマ(17歩)の実装方針が急速にまとまり,新生全知検索整備に戻る前に実装出来る見通しとなった。
エクスポート機能についても,実装時期は未定ながら想定より早期の実装が出来そうだ。
とりあえず,当月を除いて直近12ヶ月分の日次出場抜控は温存し,それ以前のものは月内で最初の抜控を除いて削除することにした。最後の抜控よりは最初の抜控の方が日付が揃えやすい。温存期間は3ヶ月や6ヶ月でも大きな問題はないが,あとで調整しやすいように長めに取っておく。
現在の形式での抜控を始めた希哲13年6月6日分から整理作業に着手する。
ディスク容量の圧迫が限界に近付いているので,今後の抜控サイズ増加を考えるとこれ以上先送り出来ない。この日は脳爆発がひどく作業出来なかったため,明日一番にやりたい。
src
属性}{<script>
}{希哲16年12月19日の副日記}{付かない}{https:
}{ツイートの埋め込み交度}{不正出与え修正}{〈delloon〉}{添えて}...長いこと課題だった自我ページと風船輪郭について良い閃きがあり,急速に実装方針がまとまった。
現状,自我ページは URL のみ正規化している(/KNo.XXXX
)が内容は単なる自我知番での検索結果であり,プロフィールページとしては貧弱過ぎる。自我輪郭などの案はあったが,既存機能や領当てとの整合性をとるのが難しく,自我ページとしてはなかなかイメージがまとまらなかった。かなり難航しそうだったため,新生デライトの要件にも入れなかった。
最近の大輪郭整備で必要性を強く感じるようになっていたこともあり,もう少し現実的に,低コストで実現出来る案でまとめてみることにした。
まず,他自我内検索の用合いを既存の自自我内検索と整合させるため,以下のように,自我アイコンを並べるか重ねるかして,& ボタンで段階的な切り替えが出来るようにする。さらに,自我アイコンの下に「○○さん K#XXXX の描き出しです。」と表示する。
これで,全知検索の機能性はそのままに,プロフィールページに最低限必要なアイコンと名前の表示が出来る。自我アイコンの複数表示自体はかなり以前から他自我内検索用合いの案としてあったが,これに名前を添えてプロフィールページの見出しを兼ねさせるというアイデアが新しかった。
大した作業ではなく,新生デライトの完成の遅れも今更なので,これは新生デライトの要件に追加することにした。
ちょっとした用事を片付け,第二次快調期からまともに出来なくなっていた書類整理も少し進め,あとは大輪郭整備や考え事をして過ごした。
考え事での大きな収穫として,文書整備にかかわるデライト用語体系の方針がまとまった。
デライト用語体系に関しては,従来の輪郭法新用語体系を基礎に,初心者向けの分かりやすい代替用語の導入などを検討していたが,これはやめ,基本的に新用語体系をそのまま踏襲し,説明体系を洗練させていくことにした。
例えば,知名を「輪郭名」,知番を「輪郭番号」などと説明することを考えていたが,元々技術としての固有性・独立性が高い知番に関しては早々に断念していた。「輪郭名」などを補助的に導入するかどうかで最後まで迷っていたのが知名だった。この問題を考える上で,「知名」という用語の妥当性についても再考する必要があった。
「知名」の必然性について直感的な確信はあったものの,言語化が意外と難しかった。それを象徴するかのように,いつからか,輪郭「知名」の選り手は開きっぱなしで,再描出下書き抜控一覧を実装した頃から常に表示されている唯一の輪郭になっている。
知名は単なる「記事名」でも「題名」でもなく,森羅万象に付けることが出来る認知上の名前であり,その性質は既成語では表現出来ない。更に,「輪郭の名前」として輪郭に従属するものではなく,あくまでも「知の名前」として理解される必要がある。そうでなければ,そもそも輪郭が何を目的として何を扱っているのか分からなくなってしまうし,自己目的化しかねない。ここに知名という用語の必然性がある。輪郭とは,知の名前と知の番号を鍵に知そのものを具現化するものだ。
この方向で説明体系を洗練させていけば,代替用語は複雑化を招くだけのものになる。「急がば回れ」で,多少時間はかかってもデライトを正しく理解出来る説明をしていくべきだろう。この点において,特に「輪郭」「知名」「知番」「描写」といった基礎用語には動かしがたい“正しさ”があり,それは十分わかりやすく説明出来る。ようやくその確信が持てた。
最初の中間出振るいに成功。これにより,全知検索の応答速度,柔軟性,交度品質が大きく向上した。出振るい作業も円滑に進み,手溢れも無く,全体として大成功だった。
まず,期待通り,輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも,この種のサービスとしては並という程度から,はっきり速いと言える程度になり,快適度が数段上がった感覚がある。
これまでのデライト高速化施策の中でも最大級の効果を感じるが,これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは,相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。
これまで,ページに表示される輪郭情報の取得は,相振りから大体次の流れで行っていた。
dg_oln()
)。dg_fnd()
か,吊るし輪郭の初期状態は dg_fg()
,dg_bg()
)。_dg
}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}{選択肢が増える}...応答速度が異常に遅い輪郭についての不具合調査から求頼改良・出場改良のアイデアがまとまり,一気に実装した。
_dg
は _dg_oln
と結合しないと揃えが出来ず,揃えで極端に遅くなる場合があることは認識していたが,時印を追加することは正規化の観点から避けてきた。
公開設定機能の導入で必要性が低くなった揃え用時印を廃案にすることを最近考えていたが,これに近い役割を持たせた ts_fg
,ts_bg
を追加することを思い付き,急速にまとまった。単なる複製ならやはり避けたかったが,より抽象的な時印を _dg
が持っていることは不自然ではなく,同期も引き入れ・再描出処理で行うだけでいい。
手定めしてみると,低負荷求頼では索引が使われず有意差は見られなかったものの,高負荷求頼では数倍から十倍程度までの高速化が見られた。求頼最適化の選択肢が増えることでサービス全体の負荷抑制が見込める。
領下での実装・手定めは終えたが,稼動させながらの _dg
の修正は無理そうなので明日早朝出振るいすることにした。
これにより応答速度が異常に遅い輪郭についても改善が見られたが,異常であることは変わらず,根本的な解決にはならなかった。
当初,輪括が膨大な輪郭特有の問題だろうと思っていたが,一見何でもなさそうな輪郭でも発生している。
ここで,検討していた揃え用時印(ts
)は正式に廃案とすることにした。
簡単な時印更新が可能になり,公開設定機能で目立たせない再描出も可能になったので必要性を感じなくなった。となると実装と用合いの複雑化の懸念が大き過ぎる。