{希哲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月5日}{過ごした}...=}(53)

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

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

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

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

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

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

6日振り返り日記

=}
{儲からないサービス}{希哲15年9月6日のツイスト}{希哲15年9月6日}{Notion}{個人知識管理サービス}{用者}{収益性}{ツイスト}{明るい}{解決}...=}(16)
{比較にならない}{捗り出した}{よくやった}{軌道に乗った}{希哲15年8月31日}{良くなっている}{色々なこと}{新生デライト開発}{希哲15年7月下旬}{新生デライト像}...=}(37)

{希哲15年8月31日の日記 K#F85E/A-E74C-400B}

引き続き絶好調で,調子軌道に乗った感がある。

今月も終わってみれば,本当に色々なことがあった。7月下旬脳爆発全体が見えた新生デライト像をひたすら煮詰めた月だった。

実装作業没頭するつもりで迎えた月だったため,実装作業がなかなか捗らないことが終始気になっていたが,あの脳爆発わずか1ヶ月まとめたと思えばよくやった毎週のように脳過熱があったわけだ。

この月で解決した課題も多く,終盤になって実装作業捗り出したので,とりあえずは及第点以上としていいだろう。新生デライト開発収益目標達成も,月初とは比較にならないほど展望良くなっているのは確かだ。

これを結果に繋げられるかが今後2ヶ月勝負だ。

=}
{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}{AND 検索}{組み込み函数}{希哲15年8月23日の進捗時限}{希哲15年8月23日の進捗}{希哲15年8月23日}...=}(70)

{希哲15年8月23日7歩 K#F85E/A-E74C-ECC6}

全知検索整備についての検討終了

全文検索にはとりあえず pg_bigm採用しておくことにした。知名検索でも中間一致検索性能課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse()組み込み函数として提供されるようになっているので問題ないだろう。

後縁実装どうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能実装したい。これに関しても,だいぶまとまってきた

カンマAND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難&AND で AND 検索,|OROR 検索対応することにした。除外検索条件次第- を使えるようにしてもいいだろう。

部分一致検索については,省略記号 ...ダッシュ記法応用した ---対応する。

描写検索については,基本的には昨年7月27日3歩方針踏襲し,末尾に ?? を加える形で対応することにした。デラングとの兼ね合い検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。

一つの可能性として,検索ボタンダブルクリックダブルクリック検索対象切り替える機能があってもいいかもしれない。

いずれにせよ,まずは既存の検索語変換交度whr_kw()まとめる作業から始めることになるだろう。

=}
{新しい言語}{希哲15年8月17日のツイスト}{希哲15年8月17日}{ツイスト}{解決}{導入}{Rust}{容易}{犠牲}{安全性}...=}(14)
{解決}
{}