{希哲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 という警告を出すので止めておいた。そこまでの性能必要なさそうだ。

=}
{希哲15年9月10日の開発}{考えている}{動いている}{deln_log}{希哲15年9月10日の進捗時限}{希哲15年9月10日の進捗}{効率上の問題}{希哲15年9月10日}{良い思いつき}{デルン出力録整備}...=}(35)

{希哲15年9月10日11歩 K#F85E/A-E74C-2FAE}

散歩中良い思いつきがあり,デルン出力録整備再開。以前仕組みは作ったものの効率上の問題が大きく無効化保留していた。

いまのところデライトそれなりに安定して動いているが,たまに壊衝しているため,やはり欲しい

segmentation fault はともかく,例外ならバッファに溜めておいた吐き出すくらいのことは出来そうだと考えていると,出力を一時的に預かっておいて deln.fcgi が落ちた時に書き出す論組があればいいことに気付いた。これを仮に deln_log としておく。

少し仕様を練って終了

=}
{希哲15年9月8日の開発}{変えたくない}{検索向き}{下げている}{クロール効率}{SEE}{希哲15年9月8日の進捗時限}{希哲15年9月8日の進捗}{希哲15年9月8日}{輪郭小窓}...=}(36)

{希哲15年9月8日13歩 K#F85E/A-E74C-2741}

SEE 見直し終了

どうも描写内輪符輪結先輪郭の正規 URL ではなく後景検索になっているのがクロール効率をかなり下げている気がしてきた。canonical があるとはいえ,URL分散させているのは間違いない

この仕様は,輪郭ページよりも後景検索の方が検索向きになっていることから来ているが,輪郭小窓によってその必要がなくなるかもしれない。

すぐに修正してみてもいいかと思ったが,SEO効果測定時間がかかることもあり,あまりころころ変えたくない現時点では致命的問題でもない。もう少し観察してみることにした。

=}
{微に入り細に入り}{無理はない}{考えなければならない}{周辺的}{働いてくれている}{働いてくれない}{希哲15年8月19日}{実装方針検討}{感じられる}{作業手順}...=}(63)

{希哲15年8月19日の日記 K#F85E/A-E74C-91DF}

引き続き脳過熱状態で,日中久しぶりぐったりした。半休にして少し心身休めることにした。

夕方頃から復調してみると,新生デライト開発優先順位整理が概ね付いた。気付いてみれば,作業手順から細かな仕様まで,自覚していたよりずっと整理進んでいる新生デライトの完成はもちろん,デライト広告検索流入良い兆候もあり,収益目標達成イメージも一段と具体的になってきたように感じられる

やはり,頭脳というのは,思うように働いてくれないようでいても,意志計画を越えて働いてくれているものだと改めて実感した。収益目標達成に向けての開発宣伝運営組計……と,微に入り細に入り網羅的思考をさせていたのだから,脳過熱になるのも無理はない

結果的に,中旬実作業より実装方針検討仕様検討環境整備組計調整など周辺的仕事の方が捗った目先の収穫よりも二手・三手先の収穫優先した格好だが,問題は,時間制限間に合うかだ。

そろそろ9月以降のことも考えなければならないようだ。

20日振り返り日記

{新生デライト開発}{新生デライトの要件}{新生デライト}{すっと}{肩の力が抜けた}{作業の合間}{付徴追加}{長大化}{出来るだけ早く}{喜べなかった}...=}(68)

{希哲15年8月3日の日記 K#F85E/A-E74C-70F9}

今日の開発では仕様検討実作業ともによく捗ったが,夕方頃まで気分もやもやしていた。

ここ数日,新生デライト像完成に近付くにつれ気分重苦しくなり,悪い意味緊張がほぐれない感じていた生活律動矯正停滞にも表れているが,今日は全知検索仕様検討が進んだことでそれが限界に達したようだった。

新生デライトの要件仕様まとまってきたことは当然ながらデライト開発にとって大きな進歩だ。死角がなくなり,手戻り最小化しやすく,連鎖的課題解消狙いやすくなる全体最適化間違いなく進んでいる。しかし,なぜか単純喜べなかった

新生デライト開発長期化することで,収益目標達成困難になるような想定更新出来ていなかったからだと,よく考えてみて気付いた

直近想定では,8月中に出来るだけ早く新生デライトを概ね完成させ,第四次宣伝攻勢を始め,9月中頃の収益目標達成目論んでいた。新生デライトの要件長大化し続けたことでこれが極めて厳しい目標になっていた。

昨日の日記にも近いことを書いているが,もはやこの順序こだわるべきではないのだろう。今となっては,付徴追加報告ツイストなど,作業の合間に出来る時間対効果の高いデライト宣伝8月中の収益目標達成9月中頃に新生デライト完成,という方がよほど現実的に思える。視点を変えてみれば,むしろ収益目標達成近付いている

これに気付いてから,すっと肩の力が抜けた

{仕様}
{}