副日記としての開発記録は希哲12年9月23日から。
{希哲19年7月18日}{希哲19年7月18日の副日記}{呼び出されていない}{呼び出した}{出力できるようになった}{
宇田川浩行
SPI_finish()}{dg_xpo_fg()}{dg_xpo_bg()}{dg_xpo()}{希哲19年7月の開発}(31){希哲19年7月18日の開発 K#F85E/0758-13E6}
エクスポート機能実装
dg_xpo_fg()，dg_xpo_bg() の実装が一段落し，dg_xpo() で前後景輪符も出力できるようになった。懸念していた負荷も十分小さく，感触は良好。
dg_xpo() 内で呼び出した時に壊衝する問題に数時間悩まされたが，SPI_finish() が適切に呼び出されていないだけだった。
{希哲19年7月17日の副日記}{希哲19年7月17日}{宇田川浩行
dg_xpo_fg()}{dg_xpo_bg()}{取得部分}{一覧内容}{誤検知}{検知できる}{状態になって}{ノイズになる}(69){希哲19年7月17日の開発 K#F85E/0758-9A5D}
エクスポート機能実装
dg_xpo() だけでやろうとすると無駄に複雑化するため dg_xpo_fg() と dg_xpo_bg() を追加することにした。
デライト CSV の仕様についてはデライト公式の輪郭を閲覧専用模動で参照するようにしておいた。<details> にしようかと思ったが再利用性が低く，かといってわざわざ静的ページを用意するほどのものでもない。公式に閲覧専用模動を利用した最初の例となった。
新着確認機能
厳密に検知できる必要性は低いので，誤検知をなくすことを重視することにした。無駄に更新を促すことで負荷増大にもつながる。
{希哲19年7月16日}{希哲19年7月16日の副日記}{気が抜けていた}{閲覧できていた}{希哲19年7月の開発}{デライト}{無視できる}{開発}{開発記録}{運が良かった}(36)宇田川浩行
{希哲19年7月16日の開発 K#F85E/0758-A5F4}
SSL 証明書の更新
15時頃，もう少し猶予があると思っていたデライトの SSL 証明書が切れていることに出先で気付いた。その10分ほど前には閲覧できていたため時間差は無視できる程度だろう。16時頃には更新作業を終えて復旧。断帯約1時間。
エクスポート機能実装が落ち着いて少し気が抜けていたのもあるが，すぐ気付いて帰れる状況だったのは運が良かった。
{希哲19年7月15日}{希哲19年7月15日の副日記}{インポート向き}{認知負荷}{最小化できた}{豊富にある}{非標準的な環境}{標準的な仕様}{単純化した}{デライト書庫}(164)宇田川浩行
{希哲19年7月15日の開発 K#F85E/0758-5FB5}
エクスポート機能実装
前景輪符・後景輪符を省略した最小限の形で実装を終え，出振るいした（エクスポート機能の様子）。
検討開始から仕様検討を繰り返して5年近くかけての実装となったが，時間をかけただけあって，無駄を徹底的に削ぎ落とし，単純で軽快で柔軟で合理的という，非常にデライトらしい実装となった。結果的に実装と保守にかかる時間を最小化できた。
特に大きかったのは，想定用者を入門者と重用者に絞り込んだことだった。入門者にとっては試用しやすく，重用者にとっては定期的な抜控が可能で描出意欲を維持しやすいことが重要になる。移行目的での大量輪郭の一括エクスポートに利素を割く理由はないことに気付いた。そんな利素があるなら少しでもサービス改良に割くべきだろう。
最近，急速に「デライト CSV」の仕様が固まったのも大きかった。長く想定していた .oln と分割格納方式の「デライト書庫」はいったん保留し，CSV に単純化したことが功を奏した。デライト書庫は複雑性もさることながらインポート向きではないことが痛かった。
検討していた文字交度・改行交度の選択機能も排し，標準的な仕様で決め打ちとした。非標準的な環境の用者には自己解決能力も情報も豊富にあるという割り切りができた。もっとごてごてした機能になり用者の認知負荷と混乱への対策が必要になりそうだと思っていたが，はるかに単純明快になりその心配も払拭できた。
インポート機能の検討が進み，出与え形式共通化の必要性を感じていたことも一助となり，デライト CSV はデライトの出与え可搬性の基礎となりうる概念となった。
{希哲19年7月14日の副日記}{希哲19年7月14日}{設計していく}{再評価した}{標準とした}{明らかになった}{性能上}{疑わしくなってきた}{コスト対効果}{負荷増大}(84)宇田川浩行
{希哲19年7月14日の開発 K#F85E/0758-D190}
エクスポート機能実装も捗ったが，新生全知検索整備でも大きな収穫があった。
エクスポート機能実装
新生全知検索整備
全知検索ボタン拡張についての検討
希哲14年7月27日3歩から検討してきた全知検索ボタン拡張だが，これはいったん廃案とすることにした。
最新案では，検索語候補窓が表示されるタイミングで全知検索ボタン下部にメニューを開く記号を付けることを考えていたが，かえって用者を混乱させる可能性があることと保守性の低下，無用な描写検索が増えることによる負荷増大などコスト対効果が疑わしくなってきた。最初の案のように，単純に全知検索演算子をボタンに反映させるだけの実装でも問題は大差ないだろう。
最近の新生全知検索整備で知名検索の柔軟性が大幅に向上したこと，出場調安の進展で全文検索の性能上の限界がかえって明らかになったことなどで，知名検索を標準とした全知検索の合理性を再評価した。いたずらに補完手段を増やすよりも知名検索の利点が用者に伝わるように設計していくことの方が重要であることに気付けたのは大きな収穫だった。
装体修正
描写部 <a> 内の <code> に輪結色が反映されていなかった問題を修正。
出場調安
{デライト CSV}{希哲19年7月10日の副日記}{希哲19年7月10日}{新生全知検索整備}{希哲19年7月の開発}{開発}{開発記録}{エクスポート機能実装}{実装イメージ}{まとまった}(18)宇田川浩行
{希哲19年7月10日の開発 K#F85E/0758-6DBF}
{希哲19年7月9日の副日記}{希哲19年7月9日}{新生全知検索整備}{希哲19年7月の開発}{開発}{開発記録}{エクスポート機能実装}{作業方針検討}{調安}(9)宇田川浩行
{希哲19年7月9日の開発 K#F85E/0758-3558}
{開発記録}