{希哲15年9月13日の開発}{デマングリング}{改良の余地}{`pkill -11`}{容易に}{異常終了時}{セグメンテーション違反}{std::set_terminate()}{signal()}{c++filt}...=}(42)

{希哲15年9月13日18歩 K#F85E/A-E74C-1C7F}

デバッグ環境整備終了

少しだが,std::set_terminate()signal()SIGSEGVバックトレース出力するようにした。これで,セグメンテーション違反例外での異常終了時状況容易に把握出来るようになった。出力録保存機能との相性抜群だろう。

早く出与えを得たいので出振るいしておいた。pkill -11 でしっかり記録出来ていることも確認した。

まだ細部改良の余地はあるが,少しずつ調整していく。


backtrace()C ライブラリなのでマングリングされたシンボル出力されるが,デマングリングが少し面倒臭いので一応そのままにしておいた。大体の意味は分かるし,c++filt を通せば翻訳出来る。

=}
{希哲15年9月11日の開発}{将来的な}{必要なさそう}{噛み合っていない}{数MB}{数十kB}{上手く動いていた}{現行方式}{`tee -a`}{希哲15年9月11日の進捗時限}...=}(83)

{希哲15年9月11日4歩 K#F85E/A-E74C-BFAF}

デルン出力録整備deln出力録保存機能調整

昨日時点では「間に合わせ」に近い感覚だったが,調整を続けてみると機能性能ともに十分なものになったため,4月デルン出力録整備作った現行方式をいったん正式採用出力録保存機能に関しては一段落とすることにした。

deln.log 肥大化問題最終的解決したといってよさそうだ。

deln_log実装将来的な選択肢の一つとして保留しておく。


昨日の時点でも概ね上手く動いていたが,一つだけ気にかかることがあった。

watchdeln.log変化観察してみると,tail切り詰める一瞬合間に,数十kBから数MBサイズ極端増えることがあった。しかも大きい方のサイズは減ることなく,微増を続けている様子だった。

以前の deln.log 肥大化問題に比べればずっと緩やかなもので,直ちに問題があるほどではなかったが,時限爆弾のような気持ち悪さがあった。

挙動からして,tail譜類置換した後も tee累積した出力再作成し続けているとしか考えられなかった。最初はバッファか何かが上手く噛み合っていないのかと思い stdbuf調整してみたが変わらず,結局,tee -a を使うことで問題解消した。

これは tee仕様なのか,もっと基本的な譜類司組司組呼応の問題なのかは分からない


まずは速度改善してみようと tail -n 1000tail -c 50kB に変えてみたりもしたが,文字交度して Bashcommand substitution: ignored null byte in input という警告を出すので止めておいた。そこまでの性能必要なさそうだ。

=}
{寝不足続き}{信じよう}{勝手に}{悪いこと}{時間のゆとり}{甘やかしたくなかった}{見かけ}{脳裏をよぎった}{いつから}{満たされた生活}...=}(167)

{希哲15年9月7日の日記 K#F85E/A-E74C-895A}

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月までに収益目標達成出来れば「デライトの早期成功」とするとして,いまのところ失敗余地はないように思える。

また他に優先すべきことが出来て先送りになることがないとも言えないが,その時はその時の自分の判断信じよう


5時前起床を目指したが,寝不足続きだった上に5時間睡眠調整しようとしたせいで二度寝してしまった。

いまのところ早朝出振るい必要はないので,睡眠調整ゆっくり進めていくことにした。

{見せたくない}{判断を誤る}{危なかった}{考え出す}{Cμ の公開}{1日30分}{宣伝時間}{1日3時間}{頼らず}{おかしくない}...=}(98)

{希哲15年8月4日の日記 K#F85E/A-E74C-85D0}

新生デライト開発中の収益目標達成狙うことになり,第四次宣伝攻勢位置付け,引いてはデライト宣伝あり方について見直す必要を感じたため,今日は現状整理時間を費した

デライト高速化前の現状整理以来だが,この3ヶ月あまりの間にも数多くの出来事があり,ついこのあいだ脳爆発があったばかりなので,現在地よく分からなくなっていた。「新生デライト」というのも,そもそも何を意味していたのか忘れかけていた

第三次市場戦略以後,「新生デライト」は「理想的な完成度に達したデライト」に近い意味を持ってきた。その要件先月下旬まとまり,今月から「新生デライト開発」に入れるようになった。それも12ヶ月中の「完成」が視野に入っている。

意識の変化言葉の変化にも表れている。これまで「新生デライト宣言」という表現をよく使っていたが,これは明確な区切りのないものに「完成」の類を使うことに違和感を覚えていたことによる。「完成」が自然に使えるようになったのは,やはり要件がまとまり,新生デライト像明確になったからだ。

その完成を目指せるようになってはじめて,「新生デライト開発」という表現も出来るようになった。デライト開発新しい段階に入ったことは明らかだろう。

一方で,これまでの波状攻撃のようなデライト宣伝根底には,デライトの品質に対する不安があった。出来るだけ品質の高い状態で多くの人の目に触れるようにしたかった。逆に言えば,見せたくない状態が多々あった。それが今のデライトにも必要かというと,少なくとも明確な必要性感じていない

要するに,今のデライトはいつ誰に見せてもいいし,いつ飛当してもおかしくない。だとすれば,もう宣伝攻勢頼らずデライト宣伝日常的継続するべきかもしれない。具体的には,宣伝攻勢では1日3時間としていた宣伝時間1日30分にしてでも毎日する,といったことを考えた

いずれにせよ,新生デライトの完成まで宣伝待つことは出来ないので,新生デライト開発と宣伝は並行させざるをえない。並行させる以上,相乗効果を生むように作業優先順位などを調整していくことになる。

第四次宣伝攻勢をするかどうかは,結論を急ぐことでもないので保留とした。


からしばらくは良い調子だったが,昨年からのデライト開発駆け足振り返りCμ の公開まで考え出してしまったせいで,久しぶり分かりやすい脳疲労症状が出た夕食後には復調した)

しかし,ここで意識正しく更新出来て良かった。ぼんやりした意識のまま突き進んでいたら何かしら判断を誤っただろうし,危なかった

=}
{新生デライト開発}{新生デライトの要件}{厳しい目標}{希哲15年8月20日}{悟った}{新しいアイデア}{舞覧手定め環境整備}{希哲15年8月1日}{輪郭選り手}{ひたすら手を動かす}...=}(27)

{希哲15年8月1日の日記 K#F85E/A-E74C-61E8}

いよいよ新生デライト開発にかけるが始まった。

今日は定休利用して,時間に追われているとなかなか出来ない作業場清掃主力機清掃をし,舞覧手定め環境整備新生デライトの要件まとめ一段落させた。

新生デライトの要件についてはもう少し細かく考えるつもりだったが,輪郭選り手についての新しいアイデアが出てきてしまい,もうまとめている段階ではないと悟った。ここまで全体像が見えたら,あとはひたすら手を動かすしかないだろう。

月内新生デライト宣言厳しい目標だが,いつものように,まずは20日まで作業没頭し,状況によって調整を考える。

=}
{Meson}{新生デライトの要件}{日本語表現}{換配確認機能}{確認ボタン}{プレビュー機能}{開閉状態}{応用の可能性}{確認用}{ページ読み込み時}...=}(109)

{希哲15年8月1日の開発 K#F85E/A-E74C-7A28}

新生デライトの要件

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

舞覧手定め環境整備

舞覧手定め環境整備一環として,SLFSChrome59最新版92更新

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

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

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

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

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

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

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

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

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

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

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

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

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

=}
{調整}
{}