{輪郭 K#F85E/A-4686-96D1}

やや軌道から逸れながらも，それを補う程度には成果を出している新生デライト開発に負けず劣らず，輪郭整備が最近意外な発展を遂げている。

律動的集中生活に入ってから，朝の輪郭整備や朝のデライト宣伝のような日課としての描出は休止しているが，ここのところ，作業の合間などでついつい輪郭整備に時間を費してしまう。

デライト自体が日に日に快適になっていること，描出手法が洗練されてきたこと，素材として利用出来る輪郭も充実してきたことなどで，単純に描出が楽しく，ハマってしまっている。中毒性があるのはネットサービスとしては良いことだが，新生デライト開発の時間を奪ってしまっている面もある。

ただ，輪郭整備は，見本，献典拡充，SEO，手定め，学習など，多方面に効果のある作業だ。確実にデライトの肥やしになっているという感触もあるので悪いとも言い切れず，少し戸惑っている。

（15日の振り返り日記）

気になっていたデライト高速化に関する問題をいくつか片付け，出振るいした。結果として大きな体感表示速度の向上が見られた。

離立備立・デバッグ備立の切り分け

やや混乱していた kn cpl などを整理しながら，離立備立とデバッグ備立を切り分けられるようにした。5月のデバッグ出力整備でデバッグ出力と録出力を切り分けておいたことも奏功し，作業は円滑に進んだ。

これまで，本番環境でも deln.fcgi も libxtd も xpo.Pg もデバッグ出力を無効化していなかった。特に大きな負荷になる要素ではないが，高負荷時の性能低下要因を極力減らしたかった。

精神衛生的な面でも効果が大きかった。長い実験段階を終え，一つの製品として完成に向かうデライトを象徴する出来事のような気がして嬉しかった。

デライトの WebP 対応

一般用者の自我アイコンも WebP 化を完了し，添付画像を除き，現時点で出来るデライトの WebP 対応は完了した。

添付画像の仕様再検討

先月31日12歩ではすっかり忘れていたが，互換性の問題があるため，当面は元画像と WebP を共存させておくことにした。特に，Safari の対応が遅かったため，まだ WebP への統一は時期尚早だろう。

非対応舞覧の市影は小さく，デライトにおける譜類添付機能もそれほど本質的な付徴ではないため，割り切って無視出来なくもないかとも考えた。いずれにせよ，気になるのはストレージ容量なので，それが問題になるまでは様子見することにした。

外部スクリプトの選択的読み込み

輪郭を含むページで無条件に読み込んでいた KaTeX と highlight.js を，必要な場合だけ後縁で出力させるようにした。

体感表示速度への影響はこれが一番大きかった。

交度記法における言語の管理にも応用出来る。

実装作業もそれなりに捗ったが，頭の整理もだいぶ進んだ一日だった。幸先が良い。

組計整理が進み，当面の組計の見通しはさらに改善，気持ちにも落ち着きが出てきた。

デライト市場戦略にも大きな進展が見られ，より一貫性が高まった。

なんとなく対 Facebook 戦略について考えていると，用者数30億人に迫る Facebook に勝つのに50億人や100億人を目指すのはあまり賢くないな，という思いが沸き起こってきた。

大きな風船（量的大国）には小さな弾丸（質的大国）をぶつけるしかない，というのはジパング計画で考えてきたことだが，デライトに関しては，量より質という考え方を徹底出来ず，まだ爆発的流行による成功という可能性を捨て切れずにいた。

超高効率経営があり，安定拡大戦略があり，書き手・読み手の能力に大きく依存する文字献典を重視し，日本と日本語を重視し……と，全体として量より質を志向すべき環境は整っていた。現に，いまデライト運営が楽なのは，異常なまでに知的好奇心旺盛でリテラシーの高い日本人用者しか寄り付いていないからだ。国内外から無闇に用者をかき集めていたら，いまごろ破綻している。

輪郭一覧にあるデライト広告も，どちらかといえば一見よりも描き手向けになっている。初期に配置を決めてから何度も再検討はしたが，ほとんど動かしようがなく，結果的にこうなっている。輪郭そのものに対して広告を付けると，単純に描き手・読み手双方にとっての快適性を損うという問題もあるが，扇情的な内容が増えれば増えるほど収益が上がる構造になり，信頼性とモラルの低下を招きかねない。

これだけの条件が揃っていながら，まだ揺らぎがあった。問題は，こんな広告で十分な収益を上げることが可能なのか，確証が掴めていないことだった。これについては先月実証され，最近では，全知検索を使い込んでくれる重用者をいかに増やしていくか，という意識が高まっていた。これが最後のピースだった。

ここからは，デライト市場戦略でも，量より質，広さより深さという考え方を徹底していくことにした。デライトが知能増幅メモサービスとしての完成度を高めていけば，用者は必ず後から付いてくる。日本語圏の限界に達する時には，世界中の人が日本語を学ばざるをえないだろう。

（2日の振り返り日記。3日加筆修正）

公開設定機能に領下譜類として扱う設定を加える検討で終了。

デルンを譜類管理系として利用する案は以前からあり実験的なこともしていたが，簡易ウェブ捌きでも作らないと領下譜類を扱うのは難しいと考えていた。

しかし，どのみち高い導入の敷居を考えれば，Native File System API のような実験的 API や拡張機能を利用することを考えてもいいかもしれない。

ただし，輪郭の内容を領下に保存していても舞覧で扱う以上制危上の問題はゼロではなく，デライト側の瑕疵で誤送信などが発生する可能性はあるので，あくまでも将来的な可能性に留めておく。

デライト広告についての検討で終了。

現状，広告掲載ページが少な過ぎるため，運営関係者の輪郭には手動で広告表示を指定出来るようにすることを検討。

デライト広告と公開設定，著作権問題についての整理で終了。

とりあえず，「自分だけ」に設定した輪郭に限り，私的複製と解釈することにした。アカウント共有などで著作権侵害が行われる可能性もあるが，これに関しては関知しえない利用者の違法行為とみなす。

そうした輪郭が含まれるページに広告配信した場合，広告配信業者のポリシー違反になるかどうかは分からない。

「近象」というのは，感覚的に身近な抽象性のことです。言い換えると，「より単純で包括的なもの」，つまり「輪郭」的なもの，ということになります。その反対が「遠象」です。

「抽象」は，本来何かのために思考を単純化するものですが，必ずしも感覚的な近さを意味しません。数学のそれが良い例です。

例えば，「近象文字列」というのは，簡単に言えば「文字列を直感的に扱えるように抽象化したもの」です。この直感的というのも厳密には「思いついたように扱えること」という意味で，「直想的」と表現していました。

C++ の文字列は std::string と書きますが，様々な変種もあり，「文字列を扱いたい」という書き手の単純な要求に対して直想的ではありませんでした。書き手の頭の中で，「文字列を使うこと」と「std::string を使うこと」の間に距離があるということです。C++ ではライブラリによって異なる文字列型を使い分けることが多々あるので，std::string も固有名詞的に文字列を扱う手段の一つとしか認識されていません。

Cμ では，s_T として「細かいことはさておき大体の場面で使える文字列型」を提供することにしました。「文字列を使うこと」と「s_T を使うこと」が概念として（普通名詞的に）一致するように設計されています。これを「近象文字列」と呼んでいました。

公開設定機能（公開範囲設定機能）についての検討で終了。

描写埋め込みでは，公開設定を無視出来ることにした（ただし，自輪郭に限ってなど何らかの制限は必要だろう）。

一つの動機として，引用などの著作権的な問題を回避出来そうということがあった。

引用の主従関係については，文書としての輪郭の特異性から何とも言い難いところがあったが，引用文だけの輪郭が増え過ぎれば NAVER まとめの二の舞になりかねないという危惧もあった（もっとも，サービス全体としては独自性のかたまりなので単なるパクりサイトとは言われないだろうが）。

とはいえ，引用文を輪郭として保存して再利用したいというのは自然の流れで，法的な問題なくそういう活用が出来る環境を整えたいと思っていた。

公開設定機能と描写埋め込みが出来るようになれば，引用文だけの輪郭を未公開非共有にして私的複製扱いにしつつ，公開輪郭に埋め込んで利用するといったことが可能になる。

新生デライトの要件

もう考えていても仕方ない段階に来ているので，とりあえず雑に書き出しておく。

• デラング整備
• デライト文書整備
• デライト高速化
• 機能整備
  • 輪郭選り手整備
    • 抜控機能（途中）
    • 譜類添付機能
  • 輪郭小窓
  • 自動ページ展開機能
  • 新着確認機能
  • 風船輪郭
  • 検索語提案機能
  • 輪郭削除機能
  • 設定画面
    • 自我削除機能
    • エクスポート機能
    • 暗証語再設定機能
  • 暗証語再発行機能
  • 公開範囲設定機能

舞覧手定め環境整備

舞覧手定め環境整備の一環として，SLFS の Chrome（59）を最新版（92）に更新。

3月15日7歩でも試みているが，その時は libxkbcommon の不足で失敗，依存性地獄を懸念して中断した。

libxkbcommon の引装には Meson，Ninja の引装が必要で，Meson と Ninja には Python 3 の引装が必要だったものの，それ以外に直接必要なライブラリはなく，意外とあっさり更新出来た。

これで SLFS では Firefox，Chrome の最新版が使えるようになり，手定め用の iPhone 7 も近日中に手に入る予定なので，舞覧手定め環境整備はここで一段落とする。

Android 端末向けの舞覧は手持ちのスマホで，Edge 含め，Windows 向けの舞覧は Windows 仮想機で使える。

実機・仮想機では主に最新舞覧を使い，古い舞覧などは LambdaTest などのサービスを利用すれば十分だろう。

輪郭選り手抜控機能整備など

描き直しの選り手も同期するように調整。

とりあえず，選り手が開いている場合に内容を同期させるようにだけしておいた。これで複数窓で同じ輪郭の選り手が開いていても混乱しにくくなり，内容が長い場合には複数窓で別々の箇所を編集することも出来るようになった。

現状，抜控のある選り手はページ読み込み時に開くようになっているが，閉じている場合でも別窓で抜控が出来た場合は開いたり，別窓で閉じた場合は自動的に閉じたりと，開閉状態の同期もしようかと思っていた。これは止めておいた。

開閉状態の同期はしない方が，一方の窓を編集用にして，一方の窓を確認用するなどといった応用の可能性が広がることに気付いた。

現状では描き直しの完了と選り手の閉じるが機能的に一緒になっているが，複数窓の有効活用を考えると保存と閉じるで分離すべきか。取り消しボタンを閉じるために使うかと思ったが，操作性を考えると，今の完了ボタンを保存・閉じるの二段階にする方向が良さそうだ。

そんなことを考えているうちに，保存せずに換配後のプレビューが出来る機能についても検討し始めた。概念・操作の複雑化を避けることを考えるなら，完了ボタンの機能は現状維持でプレビュー機能が本命かもしれない。

プレビューの日本語表現は「確認」が分かりやすいだろう。内部的には「換配確認機能」や「確認ボタン」と呼んでおくことにした。

希哲15年7月18日，換配後編集支援の輪郭候補窓として閃く。

輪郭候補窓自体は何度か検討したことがあるが，少ない情報では輪郭の識別が難しいという理由で見送ってきた。これを機に，個人的な描出では空にすることが多い描写の役割を見直し，輪郭の特徴付けという本来の役割を明確に負わせることにした。

20日，知番付きの輪郭情報を表示する機能も加えた「輪郭小窓」としてまとまる。