{空想的な}{時間を充てる}{本格的に}{変えていなかった}{間違える}{初期設計}{月内達成}{急速に発展}{思えた}{導かれていた}...=}(136)

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

昨日KNEST 隠し実装の再開決めたのが寝る頃で,消化不良だったため,今月中間まとめ兼ねて頭の整理をしておくことにした。再開によってデライト収益目標達成展望急に明るくなったような気がしたが,それが何故なのか理解出来ていなかった

そもそも今月に入ってから,新生デライト開発はまたもや不思議な軌道を描いていた。機能整備進めようという意識とは裏腹に,実際には高速化開発環境整備知機駒手整備手定め環境整備デバッグ環境整備多くの時間を割いた。また脱線しつつあるなと感じてはいたが,収穫大きかったので成り行き任せにしていた。これが KNEST 隠し実装の再開繋がったのは,単なる偶然ではなさそうだ。

いま思えば,8月頃からデライト収益目標達成に向けた具体的な道筋がこれまでにない鮮明さで見えてきて,具体的な数字掴めてくるにつれ,一つの不安浮上していた。それは,デライトにおける性能面の課題だった。現実装では,収益目標達成に必要握接量捌けないのは明らかだった。

ただ,これまでの自分なら,そんなことは気にせず問題が起きたらその時に乗り越えればいい,という感覚突き進んでいただろうし,意識の上ではまだそのつもりだった。無意識下でそれに反するような行動をしていたのは,日に日に増していくデライトの成功に対する現実感のせいでもあっただろう。空想的な見通しの甘さ許容出来なくなっていた。

今のデライトは,デライト高速化着実進展によって性能面でも健闘しているが,それは低負荷状態の0.1秒単位でのページ表示速度を上げていくようなもので,握接集中対策への突破口は見えていなかった。

その明らかな理由KNEST 隠し実装停滞であるということと,いまその再開最良の時期訪れていることに気付いた。この時,一気に展望明るくなったように感じた。これまでの不可解軌跡も,ここに導かれていたのだと思えた

現在,高速化機能整備文書整備同時進行させることにしているが,KNEST 隠し実装中断した5月から急速に発展展望が開けていた機能整備文書整備に対し,切り札を失ったままでいたのが高速化だった。ここでそれが復活したわけだ。

KNEST 隠し実装中断したのは,実装方針への迷いからだった。隠し初期設計間違える足枷になりやすく,早まった最適化になりかねない。しかし,7月から8月にかけて新生デライト像が固まったことで実装見通し劇的に改善している。これから機能整備文書整備を進めて集客本格化させようというところで,性能問題での機会損失極力避けたい確かに再開するとしたらこれ以上ない時期だ。


10月中のデライト収益目標達成に向けて組計調整することを決めたのは7日だったが,まだ月内達成可能性も見ていたため,ここまではあえて態勢変えていなかったKNEST 隠し実装の再開という大義名分も出来たところで,本格的に頭を切り替えることにした。

今月後半雑務処理をしっかりこなしたいので外出も多くなる見通しだが,とりあえず,中旬一杯は KNEST 隠し実装開発時間充て様子を見る

16日振り返り日記

{希哲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日の開発}{希哲15年9月9日の開発}{考えにくい}{問題があった}{並列実行}{直列実行}{`–prl`}{希哲15年9月10日の進捗時限}{希哲15年9月10日の進捗}{知機駒手整備}...=}(30)

{希哲15年9月10日5歩 K#F85E/A-E74C-93B7}

知機駒手整備終了

kn mk–prl 長応付追加し,対象並列実行出来るようにした。

もともと基本的には make に直接引数を渡す実装だったが,昨日の開発で指定対象は直列実行するようにしたため,個々の換配などに問題があった

直列実行並列実行のどちらを出放りにするかは少し考えたが,並列実行が必要なほど多くの対象を手作業指定することは考えにくいため,手入力多用する直列実行を出放りとすることにした。

=}
{改めて実感}{恵まれた状態}{透けて見える}{台所事情}{気になること}{実装技術}{揃えている}{儲からないサービス}{希哲15年9月5日}{過ごした}...=}(53)

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

定休日だったため,気まま考え事開発作業などをして過ごした

デライト収益目標達成ったこともあり,個人知識管理サービス収益性についてよく考えた。やはり,複雑鈍重になりやすい上,人口も限られているこの種のサービスはまだ「儲からないサービス」だ。分野として主流になれない理由だろう。

少し気になることがあり,開発通類でいくつかのサービス分析していたが,やはり実装雑さ開発現場状況台所事情透けて見える

しかし,高度最適化された実装技術単純見通しの良い設計KNS という根想超高効率経営など,デライトはそれを解決する揃えている。この少ない用者数収益目標達成が見えてきたのもそのおかげだ。奇跡的恵まれた状態にあるのだということを改めて実感した。

こんなことを考えていたら妙にやる気が出て,また夜更かししてしまった。あまり休めた気はしなかった。

6日振り返り日記

=}
{実装}
{}