{空想的な}{時間を充てる}{本格的に}{変えていなかった}{間違える}{初期設計}{月内達成}{急速に発展}{思えた}{導かれていた}...=}(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月3日}{後から付いてくる}{広さより深さ}{十分な収益}{収益が上がる}{動かしようがない}{一見}{寄り付く}{捨て切れない}...=}(125)

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

実装作業もそれなりに捗ったが,頭の整理もだいぶ進んだ一日だった。幸先が良い

組計整理み,当面組計見通しはさらに改善気持ちにも落ち着きが出てきた。

デライト市場戦略にも大きな進展が見られ,より一貫性が高まった。

なんとなく対 Facebook 戦略について考えていると,用者数30億人に迫る Facebook勝つのに50億人100億人目指すのはあまり賢くないな,という思い沸き起こってきた。

大きな風船量的大国には小さな弾丸質的大国ぶつけるしかない,というのはジパング計画考えてきたことだが,デライトに関しては,量より質という考え方徹底出来ず,まだ爆発的流行による成功という可能性捨て切れずにいた。

超高効率経営があり,安定拡大戦略があり,書き手読み手能力大きく依存する文字献典重視し,日本日本語重視し……と,全体として量より質志向すべき環境整っていた。現に,いまデライト運営なのは,異常なまでに知的好奇心旺盛リテラシー高い日本人用者しか寄り付いていないからだ。国内外から無闇に用者をかき集めていたら,いまごろ破綻している。

輪郭一覧にあるデライト広告も,どちらかといえば一見よりも描き手向けになっている。初期配置を決めてから何度再検討はしたが,ほとんど動かしようがなく,結果的にこうなっている。輪郭そのものに対して広告を付けると,単純描き手読み手双方にとっての快適性損うという問題もあるが,扇情的内容が増えれば増えるほど収益が上がる構造になり,信頼性モラル低下きかねない。

これだけの条件揃っていながら,まだ揺らぎがあった。問題は,こんな広告十分な収益を上げることが可能なのか,確証が掴めていないことだった。これについては先月実証され,最近では,全知検索使い込んでくれる重用者をいかに増やしていくか,という意識が高まっていた。これが最後のピースだった。

ここからは,デライト市場戦略でも,量より質広さより深さという考え方徹底していくことにした。デライト知能増幅メモサービスとしての完成度高めていけば,用者必ず後から付いてくる日本語圏限界に達する時には,世界中の人が日本語ばざるをえないだろう。

2日振り返り日記3日加筆修正

=}
{膨大な時間}{危機的な状況}{ツケ}{希哲15年8月31日}{希哲15年9月15日}{デライトの長期停滞}{暑さの峠}{希哲15年8月29日}{良い夏休み}{気持ちのゆとり}...=}(56)

{希哲15年8月29日の日記 K#F85E/A-E74C-7A21}

定休日なので,思いつきのままに軽い作業をしたり考え事をしながら過ごした。特に,来月以降の過ごし方についてよく考えた

10日まで様子見をするつもりだったが,それとは別に,15日までは月内収益目標達成目指した作業続けることにした。組計整理をした結果,多少使える日数増えた

デライトの早期成功のために,遅くとも10月中には収益目標達成確定させたい。となれば,現時点ではあくまでも9月中の達成を目指すべきだろう。ここまでの膨大な時間を得るにはそれなりのツケもあり,10月以降は単に延長というわけにはいかなくなってくる。この機会せば,デライト自体は潰れないまでも,開発長期停滞に入ってしまう可能性がある。

つまり,この2ヶ月早期成功にとって最後にして最良機会だ。久しぶりに「死に物狂い」という言葉思い出したが,日本にとっても危機的な状況がそれで何とかなるなら甘いくらいだろう。この期に及んでまだ気持ちのゆとりを持ち過ぎているような気もしていたので,丁度良い引き締めになった。

暑さの峠明後日から下り坂に入る予報で,やはり良い夏休みになったようだ。

{希哲15年8月28日の開発}{制危上の問題}{導入の敷居}{実験的 API}{簡易ウェブ捌き}{領下譜類}{Native File System API}{希哲15年8月28日の進捗時限}{希哲15年8月28日の進捗}{希哲15年8月28日}...=}(36)

{希哲15年8月28日8歩 K#F85E/A-E74C-9492}

公開設定機能領下譜類として扱う設定加える検討終了

デルン譜類管理系として利用するは以前からあり実験的なこともしていたが,簡易ウェブ捌きでも作らないと領下譜類を扱うのは難しいと考えていた。

しかし,どのみち高い導入の敷居を考えれば,Native File System API のような実験的 API拡張機能利用することを考えてもいいかもしれない。

ただし,輪郭の内容を領下に保存していても舞覧で扱う以上制危上の問題ゼロではなく,デライト側の瑕疵誤送信などが発生する可能性はあるので,あくまでも将来的可能性に留めておく。

=}
{希哲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()まとめる作業から始めることになるだろう。

=}
{囁かれている}{Linux ベース}{希哲15年8月19日のツイスト}{希哲15年8月19日}{核脳}{ツイスト}{可能性}{独自}{費用対効果}{時代}...=}(13)
{希哲15年8月18日の開発}{見つかった}{公開状態}{upub}{しっくりくる}{実装方針検討}{希哲15年8月18日の進捗時限}{希哲15年8月18日の進捗}{希哲15年8月18日}{直接参照}...=}(45)

{希哲15年8月18日8歩 K#F85E/A-E74C-F9AB}

公開設定実装方針検討終了

_dg_oln追加するをどうするかが課題だったが,未公開状態率直表現した upub とすることを決めたは以下のようになる。

0: 公開
1: ここだけ
2: 仲間だけ
3: 二人だけ
4: 自分だけ

描出公開原則考え方からすると,既存公開状態0表現したかったが,ようやくしっくりくる列名見つかった

SQL列挙型注意が必要なので使用せず,integer にしておく。公開設定に関しては熟考したので,変更可能性は小さい。

直接参照能否正負表現してもよさそうだ。

=}
{可能性}
{}