(42)少し雑だが，std::set_terminate() や signal() の SIGSEGV でバックトレースを出力するようにした。これで，セグメンテーション違反や例外での異常終了時の状況を容易に把握出来るようになった。出力録保存機能との相性も抜群だろう。
早く出与えを得たいので出振るいしておいた。pkill -11 でしっかり記録出来ていることも確認した。
backtrace() は C ライブラリなのでマングリングされたシンボルが出力されるが，デマングリングが少し面倒臭いので一応そのままにしておいた。大体の意味は分かるし，c++filt を通せば翻訳出来る。
(38)出力録保存機能調整を進め，デルン出力録整備をいったん完結させた（4歩）。
結局，最小の実装コストで出力録保存機能を整えることが出来，昨日の思いつきから本当に思わぬ収穫となった。
今日は0時から24時前現在までに，意図的に落としたのを除けば2回しか落ちていないことが分かった。これは想像していたよりずっと少なく，0.1秒で復帰しているはずなので，現段階では十分な安定性と言える。根拠の無い不安を払拭することが出来，開発者心理が大きく改善した。
ほか Aejs 整備など。
(83)昨日の時点では「間に合わせ」に近い感覚だったが，調整を続けてみると機能・性能ともに十分なものになったため，4月のデルン出力録整備で作った現行方式をいったん正式採用，出力録保存機能に関しては一段落とすることにした。
deln.log 肥大化問題も最終的に解決したといってよさそうだ。
deln_log の実装は将来的な選択肢の一つとして保留しておく。
昨日の時点でも概ね上手く動いていたが，一つだけ気にかかることがあった。
watch で deln.log の変化を観察してみると，tail が切り詰める一瞬の合間に，数十kBから数MBへサイズが極端に増えることがあった。しかも大きい方のサイズは減ることなく，微増を続けている様子だった。
以前の deln.log 肥大化問題に比べればずっと緩やかなもので，直ちに問題があるほどではなかったが，時限爆弾のような気持ち悪さがあった。
挙動からして，tail で譜類を置換した後も tee が累積した出力で再作成し続けているとしか考えられなかった。最初はバッファか何かが上手く噛み合っていないのかと思い stdbuf で調整してみたが変わらず，結局，tee -a を使うことで問題は解消した。
これは tee の仕様なのか，もっと基本的な譜類司組や司組呼応の問題なのかは分からない。
まずは速度を改善してみようと tail -n 1000 を tail -c 50kB に変えてみたりもしたが，文字交度を壊して Bash が command substitution: ignored null byte in input という警告を出すので止めておいた。そこまでの性能も必要なさそうだ。
(13)(11)(15)(167)10日まで様子見をするつもりだったが，少し早めに，10月中のデライト収益目標達成に向けて組計調整することを決めた。
昨日察知した状況の変化により，先月29日の日記に書いたような「デライトの長期停滞」の懸念が後退し，無理に今月中の達成を目指す必要はなくなった。となれば，より確実な方を取るべきだろう。
当然，達成が早いに越したことはないので，引き続き，落ち着きながらも適度な緊張感は保って新生デライト開発を進めていく。
ここに来て，「デライトの早期成功」という概念について再考する必要を感じた。10月の収益目標達成が早期成功というのはいいとして，11月や12月なら早期成功ではないのかというと，それも違和感を覚える。
そう考えてみて，自分の中で，主観的な基準と客観的な基準が混在していることに気付いた。振り返ると，常に大体3ヶ月以内の収益目標達成を目指してきた。その時々の状況に合わせた結果として，それぐらい先の見えない道を歩んできたということでもある。収益目標達成が半年先や一年先になるということは，常に考えたくない「遅さ」だった。
希哲館創立14周年（11月1日）までの収益目標達成というのも，昨年11月に十分な猶予として決めたものの，結局はその遅さに耐えられず早めては延長を繰り返し，結果的に最近では早期成功の目安になっていただけだ。
つまるところ，これまで「早期成功」と呼んでいたのは，「現時点から3ヶ月以内くらいの収益目標達成」のことだった。だから，いま11月や12月の達成を遅いとは感じないわけだ。
ここで，「客観的な早期成功」とは何か，について考えた。状況を引いて見た時に，どこまでが大っぴらに早期成功と言えて，どこから言えなくなるのか。
まず思い浮かんだのは，「デライト2周年」（希哲16年2月13日）だった。サービスの成功という観点からいえば，離立から2年未満で十分な収益化を果せば早い部類と言えるだろう。それを過ぎると中途半端，微妙な印象になってくる。
研究開発を事業として成功させるまでにかかる標準的な時間を15年とするなら，希哲館創立から数えて14年と少しで，これも「やや早め」とは言える。自分の年齢も，36歳でこの規模の研究開発を成功させれば若過ぎるくらいだ。最終的な希哲館事業の成功を考えても，まだ遅くはない。
ここまで考えて，デライトの早期成功の目安は，デライト2周年，キリの良い所で希哲16年1月と認識を更新することにした。
主観的な目標意識も，それはそれで持っておいた方が適度な緊張感のためには良いが，それにとらわれて自分を追い込み過ぎると暴走してしまいかねない。そういう時に状況を客観的に見て冷静になれるように，目標は二重に持っておくべきだろう。
さらに踏み込んで，そもそも「デライトの成功」とは何か，ということまで考えてしまった。この調子で収益目標達成を果したとして，その時点ではじめてデライトの成功とするのか。未来から見ればそうではないかもしれない。だとすれば，デライトはいつから成功していたのか。
デライト開発自体は概ねずっと好調だし，私自身も「黄金生活」なんて言葉が出るくらい物心両面で満たされた生活を送ってきた。一日一文でも書いたように，ネットサービスなんて見かけでは分からない問題を多々抱えているもので，何をもってサービスの成功とするかは，そもそも難しい問題だ。
収益目標達成というのは，あくまでもデライト，引いては希哲館事業を発展させるための手段だ。目先の収益よりも優先すべきことを優先し，目的のために最善の道を歩んできた結果として，丁度良い時期に収益目標達成にも手を伸ばせるようになってきただけではないかという気もする。そういう意味で，成功と収益目標達成の因果関係は逆なのかもしれないと考えることがある。
デライトはすでに成功しているのかもしれない……という考えは，これまで何度となく脳裏をよぎったが，その度にかき消してきた。ただでさえ反餓精神に乏しい自分を甘やかしたくなかった。
ただ，ここ最近，それこそ絵に描いた餅が食べられる餅になったというような歓びを感じていたところに，時間のゆとりまで増え，もう勝手に成功した気分になってしまっている自分がいる。それが良いことなのか悪いことなのかは分からない。
何をもってデライトの成功とするかは結論を急ぐことでもないので，とりあえず来年1月までに収益目標達成出来れば「デライトの早期成功」とするとして，いまのところ失敗の余地はないように思える。
また他に優先すべきことが出来て先送りになることがないとも言えないが，その時はその時の自分の判断を信じよう。
(98)新生デライト開発中の収益目標達成を狙うことになり，第四次宣伝攻勢の位置付け，引いてはデライト宣伝のあり方について見直す必要を感じたため，今日は現状整理に時間を費した。
デライト高速化前の現状整理以来だが，この3ヶ月あまりの間にも数多くの出来事があり，ついこのあいだ脳爆発があったばかりなので，現在地がよく分からなくなっていた。「新生デライト」というのも，そもそも何を意味していたのか忘れかけていた。
第三次市場戦略以後，「新生デライト」は「理想的な完成度に達したデライト」に近い意味を持ってきた。その要件が先月下旬にまとまり，今月から「新生デライト開発」に入れるようになった。それも1〜2ヶ月中の「完成」が視野に入っている。
意識の変化は言葉の変化にも表れている。これまで「新生デライト宣言」という表現をよく使っていたが，これは明確な区切りのないものに「完成」の類を使うことに違和感を覚えていたことによる。「完成」が自然に使えるようになったのは，やはり要件がまとまり，新生デライト像が明確になったからだ。
その完成を目指せるようになってはじめて，「新生デライト開発」という表現も出来るようになった。デライト開発が新しい段階に入ったことは明らかだろう。
一方で，これまでの波状攻撃のようなデライト宣伝の根底には，デライトの品質に対する不安があった。出来るだけ品質の高い状態で多くの人の目に触れるようにしたかった。逆に言えば，見せたくない状態が多々あった。それが今のデライトにも必要かというと，少なくとも明確な必要性は感じていない。
要するに，今のデライトはいつ誰に見せてもいいし，いつ飛当してもおかしくない。だとすれば，もう宣伝攻勢に頼らず，デライト宣伝も日常的に継続するべきかもしれない。具体的には，宣伝攻勢では1日3時間としていた宣伝時間を1日30分にしてでも毎日する，といったことを考えた。
いずれにせよ，新生デライトの完成まで宣伝を待つことは出来ないので，新生デライト開発と宣伝は並行させざるをえない。並行させる以上，相乗効果を生むように作業の優先順位などを調整していくことになる。
第四次宣伝攻勢をするかどうかは，結論を急ぐことでもないので保留とした。
朝からしばらくは良い調子だったが，昨年からのデライト開発を駆け足で振り返り，Cμ の公開まで考え出してしまったせいで，久しぶりに分かりやすい脳疲労の症状が出た（夕食後には復調した）。
しかし，ここで意識を正しく更新出来て良かった。ぼんやりした意識のまま突き進んでいたら何かしら判断を誤っただろうし，危なかった。
(27)今日は定休を利用して，時間に追われているとなかなか出来ない作業場清掃・主力機清掃をし，舞覧手定め環境整備と新生デライトの要件まとめを一段落させた。
新生デライトの要件についてはもう少し細かく考えるつもりだったが，輪郭選り手についての新しいアイデアが出てきてしまい，もうまとめている段階ではないと悟った。ここまで全体像が見えたら，あとはひたすら手を動かすしかないだろう。
(109)もう考えていても仕方ない段階に来ているので，とりあえず雑に書き出しておく。
舞覧手定め環境整備の一環として，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 などのサービスを利用すれば十分だろう。
とりあえず，選り手が開いている場合に内容を同期させるようにだけしておいた。これで複数窓で同じ輪郭の選り手が開いていても混乱しにくくなり，内容が長い場合には複数窓で別々の箇所を編集することも出来るようになった。
現状，抜控のある選り手はページ読み込み時に開くようになっているが，閉じている場合でも別窓で抜控が出来た場合は開いたり，別窓で閉じた場合は自動的に閉じたりと，開閉状態の同期もしようかと思っていた。これは止めておいた。
開閉状態の同期はしない方が，一方の窓を編集用にして，一方の窓を確認用するなどといった応用の可能性が広がることに気付いた。
現状では描き直しの完了と選り手の閉じるが機能的に一緒になっているが，複数窓の有効活用を考えると保存と閉じるで分離すべきか。取り消しボタンを閉じるために使うかと思ったが，操作性を考えると，今の完了ボタンを保存・閉じるの二段階にする方向が良さそうだ。
そんなことを考えているうちに，保存せずに換配後のプレビューが出来る機能についても検討し始めた。概念・操作の複雑化を避けることを考えるなら，完了ボタンの機能は現状維持でプレビュー機能が本命かもしれない。
プレビューの日本語表現は「確認」が分かりやすいだろう。内部的には「換配確認機能」や「確認ボタン」と呼んでおくことにした。
