デライト高速化，KNEST 隠し実装，輪数取得改良。

途中で終了。

多少排他制御周りで懸念があったため交度整理をしていたが，長いこと散らかっていた app_srv.cl.u と周辺の交度もだいぶ整理されてきた。

輪郭選り手抜控機能整備を概ね終え，ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが，抜控機能整備についてはここで一段落とすることにした。

この出振るいにより，中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり，抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また，周辺の交度整理も大きく進み，理腑としての意義も大きかった。

利便性・信頼性の向上はもちろんのこと，昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか，着手して間もないので，ここから思考を整理しやすくなる。

抜控機能整備が長引いた最大の原因は，他にやりたいことが多過ぎたことだが，これ自体も決して簡単な作業ではなかった。ただ，この間に設計方針が変わったり深刻な不具合に気付いたりしたので，時間をかけたことで円滑に片付いた面もある。

再描出は知番でいいとして，新規描出の鍵をどうするか，というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので，基本的にこれを踏襲することにした。ただし，全知検索窓から未送信の検索語まで取っていたため，これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった（4月28日20歩で書いた消失不具合の原因だろう）。これは求頼文字列から取ることで回避した。

下書き抜控一覧についても，表示条件や領当てなど色々考えることが多かった。検討の結果，再描出下書きは，検索語無しの場合（上部メニュー同様）のみ輪郭一覧の上に表示（画面撮り），新規描出下書きは，他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした（画面撮り）。邪魔になり過ぎない程度に気付きやすい。また，4月10日の開発で決めた通り，一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが，やはり，用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下，消失リスクの増大（あるいはそれを補う作業コストの増大）に繋がる。目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様の設計だった。一応，鍵仕様変更時の更新方法は考えていたが，手間を考えるところころ変えるわけにもいかないので，長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時，鍵に仕様変更日時を含めることを考えていたが，これは複雑化を招くだけなので廃案とし，Aejs_DG_rev に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め，自我の切り替えにも対応した。

その他，これまで描写のみ保存していたのを知名にも対応する，消去ボタン・復元ボタンを実装する，などこまごまとした問題を片付ける必要があった。

出振るい後，軽微な不具合がいくつか見つかったが，一番気になったのが，鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが，本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に，3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。

少し迷ったが，時間が経つにつれ重要性が急速に低下する部分なので，調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから，深刻な問題は発生していないと判断した。今後，同様の処理を書く際の注意点として記憶しておく。

長い間課題だった描写拡縮ボタン，輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発で最大化アイコンが出来たことをきっかけに，描写拡縮ボタンの実装イメージが固まり，実装・手定めまで概ね完了した。想像以上に早く上手くまとまった。下見機能との相性も良い。ただし輪郭選り手抜控機能整備が途中であるため未出振るい。

• 描写拡大ボタンの様子・初期状態
• 描写拡大ボタンの様子・スクロール途中
• 描写拡大ボタンの様子・スクロール完了
• 描写拡大ボタンの様子・暗い背景色
• 描写縮小ボタンの様子

描写拡縮は機能的には単純だが，用合い，特に領当てが難しかった。最近，描写部下境界に重ねる形での実装を考えていたが，描写部を飛び出すと他の要素に干渉してしまう。かといって余白を無駄に広げたくない。これは，下部の陰影に重ねつつ，初期化時点でスクロール可能な場合は下余白を追加することで解決した。文字や暗い背景色と重なっても視認出来るように，半透明の白背景を付けた。

拡大ボタンはスクロール可能であることの目印としても効果的なので，これを活かして，スクロール完了時には透明度を上げ，それと分かるようにした。

これで，外観・操作感ともにデライトに調和した描写拡縮ボタンが出来た。描写部の高さ固定は一覧性を確保するために必要なものだったが，用合い上の弊害も小さくなかった。陰影付きスクロール，最大化アイコン，そして描写拡縮ボタンによって，ようやくこの問題が解決した。

輪郭複製機能

輪郭複製機能も課題としてずっと考えていたが，用合い上の難しさがあった。

ボタンを押すことで複製輪郭が出来る，というのは使用頻度を考えると誤操作の懸念の方が大きい。となると，目立たないように置くしかない。かといって，操作手順が増えると，選り手を開いて写し貼りするのと大差ない。

簡単に握接出来て，なおかつ制御しやすい用合いが必要だった。ここで，「知名・描写を複製して新規描出フォームに移動するボタン」があればいいことに気付いた。これなら，自輪郭に常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置に置けそうだ。

前後景一覧は別として，検索語無指定の場合の輪郭一覧で描写のない他輪郭を非表示にすることを検討。以前からあった案だが，いくつか懸念もあり見送ってきた。

輪郭の展示としては知名のみの輪郭は邪魔に見えることが多いが，非表示にする条件の導入により挙動が複雑になることで多少用者の混乱を招くだろう。読みやすくなる代わりに，内容のあることを書かなくてはならないという誤解で書きにくくなるかもしれない。また，知名のみの輪郭での表現にも有用なものはあるので，全て非表示というのももったいない。かといって，後景輪があるものを例外にすると中途半端で現状と大差ない。

いずれにせよ，自我で輪郭一覧の見せ方を変える仕組みは公開設定機能で整える必要があるので，その時に再検討することにした。

輪郭選り手抜控機能整備中，思いがけず事象処理整理が捗り始めた。

Aejs の事象委譲機構を整備した頃から @DG.bld. に事象処理が集中するようになり，最初は全体像が把握しやすいという利点もあったものの，聴取子が増えるにつれ見通しが悪くなり，最近は問題に感じることが多くなっていた。

流石にそろそろ限界だろうと分散させ始めたところ，思いのほか上手く整理出来そうな感触を得た。

事象委譲を多用し過ぎると，客体指向的な整理が難しくなり，閉包子を利用した参照の簡略化も十分に出来なくなる。記述の複雑化もさることながら，思っていたより無駄な探索処理が増えていたことに気付いた。このあたりの理解不足による，効率性が落ちるのではないかという懸念が無くなったのが大きい。

多少目先の時間はかかるが，新生デライトの完成までを考えると間違いなく近道になる。急がば回れで事象処理整理も同時に進めていくことにした。

脳過熱の懸念があるため半休にし，休み休み作業を進めた。久しぶりの快晴でのんびりサイクリングをしたり，良い閃きもあった。

激しい脳爆発を越えて調子も安定してきている。

（9日の振り返り日記）

昨日はせっかく早く就床したのに，一時間後には地震で起こされ，よく眠れなかった。しかし，あれだけの脳爆発に早くも頭の整理が追いついてきたようで，午後からは絶好調だった。

まだ疲労の蓄積が懸念される状態ではあるため今日も早く寝ることにした。

12日の脳爆発を引きずってまだ脳疲労感が残っていた。一ヶ月分にも相当するであろう収穫だったのだから仕方ないと，気分転換も兼ねて，半年ほど放置していた Aejs 整備を再開してみることにした。

まずは交度の見直しと軽く違了修正程度出来ればいいと始めたものの，驚くべきことに，作業の続きがよく捗った。これだけ間があくと，作業方針を思い出すのと再整理に時間がかかるのではないかと思っていたが，むしろ中断前より捗った気がする。この半年間での環境整備や設計方針の洗練，知見の蓄積がそれだけ大きかったのだろう。当時は，ゆとりがなく混沌とした状況でもあった。

金風で中断してからなかなか再開出来ず，中途半端な状態で出振るいも出来ず，前縁周りの作業が非常に進めにくい状況ではあったが，この間の収穫を考えれば仕方ないと思っていた。設計面・仕様面での変化も小さくなかったので，再修正の手間も省けた。唯一の懸念だった作業再開にかかる負担が全くと言っていいほど無かったのだから，仕方ないどころか大正解だったと言うべきだろう。

Aejs 整備の中断経緯について記録を振り返っている内に，もう一つの放置課題だった KNEST 隠し実装についても再整理が急速に進んだ。

輪郭選り手抜控機能整備がなかなか進まなかったことで Aejs 整備に入ったのが昨年9月9日だった。14日11歩を最後にそれも止まり，代わりに HTML 隠し実装からの KNEST 隠し実装に重点を移すことにした。頭の整理をしているうちに18日になり，金風が起きた。以後は何度か再開を試みているが継続出来ず，そのまま第二次快調期に突入した。

金風があまりに大きい出来事だったので，このあたりで記憶が分断されている感覚がずっとあった。特に Aejs 整備と KNEST 隠し実装は，第二次快調期でも置き去りになっていた部分で心残りだった。第四次宣伝攻勢に向けて新生デライト開発も佳境というところで二つの強力な武器を上手く取り戻せた。言うまでもなく，極めて大きな収穫だ。

ただ，結局どっちを向いても脳爆発で，脳疲労は癒えなかった。

今日は疲労回復のため休みにしたが，次回の陶練からランニングを再開することにした。

これも第二次快調期からほとんど出来なくなっていた。忙しさもあったが，生活習慣の乱れに寒さが重なり，1月には風邪を引いたりもしていたため，大事を取っていた。最近は，少しずつ生活習慣改善も再開出来，暖かくなってきたので大丈夫だろう。

最近の生活習慣改善を「第四次生活習慣改善」とするかと考えたところで，すでに金風以後の生活習慣改善を指して使っていたことを思い出した。用語として考えた12月9日から間もなく第二次快調期に入ったので，目まぐるしさで忘れていたのだろう。とりあえず「第四次生活習慣改善の再開」としておくことにした。

（16日の振り返り日記）

（進捗時限記録中略）

kitetu.com のサブドメイン設計についての検討で終了。

今後，デラングのように独立して参照出来るべき献典には積極的にサブドメインを与えていくことにした（例：dlng.kitetu.com）。

デラング的転回と同時にデラング文書に dlng.kitetu.com を与えることを決めたが，これを機に，知番や Cμ，SLFS 等々の公式文書にもサブドメインを与えることを考え始めた。

これまでサブドメインの追加には消極的で，例えば技術系の献典は tech.kitetu.com に集約することを考えていた。ただ，この手の URL 設計は，運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上，階層的な整理が難しいことも多々あり，変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合の対策として，経験上「最短原則」が最善であることは分かっていて，最近は駒手にせよ各種識別子にせよ知名（最短知名原則）にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業の要素は全て kitetu.com の階層下にある，ということだけは確かだ。もちろん，これとは別に，階層的な情報源もあった方がいいので，そこは tech.kitetu.com などに担わせる。

献典にドメインとしての独立性と統一感を同時に持たせられるのだから，むしろ，ここからがドメイン名統一の本領発揮になりそうだ。

2文字サブドメイン問題の解決

サブドメインを活用していく上で，一つ，「2文字サブドメイン問題」とでもいうべき問題があった。

例えば，Cμ にサブドメインを与えるなら cu.kitetu.com とするのが自然だが，CU はキューバの国家符号だ。

ドメイン名統一によって ccTLD を使わなくなっているため，将来的に地域別ドメインが欲しくなった時にはサブドメインを使うことになる。2文字サブドメインの使用は避けるべきかもしれない，と考えていた。キット＊メーネの mn.kitetu.com もモンゴルの MN に被っているのが少し気になってはいた。

ただ，その懸念も「もやもや」の域を出ていなかった。明らかに紛らわしいサブドメインは最初から使わないので，被るとしたら普段意識しないようなものだ。被ったとして，ドメインハックで ccTLD も有名無実化している今，そこまで神経質になることでもないだろう。そんなことのために，わざわざ不自然な表現もしたくない。とはいえ，サブドメインの選択肢が多いに越したことはない。

そこで，国家符号を表す何らかの接子の導入を考えた。Facebook のように，ja-jp と言語符号付きを基本として，言語符号がいらない場合は x-jp のように表記出来るようにするかとも考えたが，少し野暮ったい。

最終的に，4 接頭子を導入する方向で検討を進めることにした。例えば，キューバ向けのドメインは 4cu.kitetu.com として cu.kitetu.com と区別出来るようにする。衝突しなければ 4 接頭子は省略してもいいし，4ja のように言語符号に代えられてもいいだろう。4ja-jp のような表現が出来てもいい。これなら十分な簡潔性と柔軟性を兼ねられる。

例えば 4jp.kitetu.com なら www.kitetu.com と変わらない標準的な長さだし，むしろお洒落感すらあるので，これで統一して，4 接頭子無しは転送用にしてもいいくらいかもしれない。

いまのところ地域別ドメインの必要は感じておらず，将来的に必要になるかもしれない，という程度の問題なので，細かいことは追い追い決める。とりあえず理論上はすっきりしたので良かった。

（進捗時限記録中略）

昨日，15日24歩についてまとめながら，区切り線記法の線種と見出し階層の関係について整理する必要を感じたため軽くまとめて終了。

下線形見出しや階層区切り線で用いる線種は二本線・一本線・破線・点線の4種としていたが，それに対し，9日17歩で考えた10種は多過ぎる。どれが使えてどれが使えないのか，用者を混乱させる懸念がある。

4種に絞り込んでしまうことも考えたが，atx 式見出しとの互換性はともかく，10種案も極めて整合的なものではあり捨て難い。

ここで，二本線・一本線・破線・点線を出放りとしつつ，他の線種でも代替出来るようにすることを考え始めた。つまり，10の線種を4階層に振り分けてしまえばいい。以下のように，意外と綺麗に振り分けられる。

<!-- 第1階層 -->

=====
+++++
*****

<!-- 第2階層 -->

-----
= = =
+ + +

<!-- 第3階層 -->

- - -
: : :
* * *

<!-- 第4階層 -->

. . .

これに装体指定の機能を持たせてもいいだろう。元々第1階層見出しの下線は太い一本線だったので，代替しても大きな違和感はない。各見出し階層に相応しいように装体はいくらでも調整出来る。