そろそろ KNEST 隠し実装も一段落し,本格的な集客に備えられる……と思っていたこの時期に,まさかの握接急増が始まってしまった。次回出振るいまでデライト宣伝は控え,KNEST 隠し実装に集中することにした。

{希哲16年6月24日2歩 K#F85E/E74C-3BE9}

{希哲16年6月1日の日記 K#F85E/E74C-2E1F}
そろそろ第四次宣伝攻勢・新生デライト開発の中間まとめをすべき時期であるため,振り返りと現状整理をした。昨日やろうと思いつつ,開発に熱中したり姪達の世話に追われたりして出来なかった。
ある程度考えはまとめたが,珍しく早い時間に眠たくなってきた。早寝は最近の課題なので,この日記は明日書くことにして早く寝た。
宣伝攻勢現況
第四次宣伝攻勢は最初から事前想定と少し異なる展開を見せたものの,概ね状況は良好であると言っていい。特に5月前半,一日一文に時間をかけたのが予定外だった。後半から開発時間を増やして,そちらも想定外に発展していき,直接的な宣伝活動にはそこまで多くの時間を割いていない。
当初,朝昼晩1時間ずつ宣伝活動に割くことを想定していたが,昼晩30分ずつという日が多く,これで丁度良い気もしている。高速化と歩調を合わせる必要があることに加えて,一日一文などでこれまでにない好感触を得ている。今は,無闇に人をかき集めるより,デライトにとっての理解者をじっくり増やしていく時期なのだろう。
それは「宣伝攻勢」なのかという気がしないでもないものの,その程度のこともしない時期が長かったから意義もなくはない。
用者動向は水物なので,努めて一喜一憂しないようにしているが,最近のデライトでは明らかに良い変化が起こっている。比較的深いところまで知ってくれる人が増えたし,常連用者の使い方も変わっている。これまで,開発者が何を考えているのか分からないままみんな手探りで使っているという感じだったが,ある程度デライトの根想を踏まえた上で使ってくれるようになった。良い意味で方向感が出てきて,初心者にとっても良い見本になる。
一方,初期のデライト宣伝で感じていた,「面白そう」止まりの表面的な反応は減っている。「面白そうだけど使わないよ」というダーウィンの海は乗り越えつつあるように感じる。
回り道と振り返り
なかなか出来なかった振り返りをしながら,「回り道」についてよく考えた。
開発では3月に中断していた中間的デラング整備に戻ったが,ここで以前とは比べ物にならないほど手定め効率が向上していることに気付いた。Aejs 整備から下見機能付きの新輪郭選り手出来たからだ。これが当時 Aejs 整備を終わらせたかった理由だったことを思い出した。
そろそろ一日一文も続きを書くか,と思えば,文章の閲覧性が飛躍的に向上している。5月後半,一日一文を中断して,最大化アイコンや描写拡縮ボタンの追加,自動ページ展開機能実装を一気に進めたからだ。これは,「デライトの歩み」という題材があまりに重かったというのもあるが,文章を読む媒体として閲覧性に課題を感じていたことも大きい。写真上信を始めた頃に感じていたことでもあった。せっかく良い写真が撮れたり良い文章が書けたりしても見にくいのではもったいない。
こう思うと,的確過ぎる回り道に自分でも驚く。デライト開発が快調を維持してこれたのは,こういう良い回り道を重ねてきたからだと改めて実感する。見えている出口に向かって,時間があるだけいくらでも改善出来る柔品は珍しい。大抵は技術的負債に潰されてしまう。良い回り道が出来ないからだ。
回り道をする以前の当努に戻るまでそれを忘れていたから余計驚く。特に第四次宣伝攻勢以後,軍隊の行進のようにひたすら前進を意識してきたため,振り返る余裕がなかった。
デライトの進歩は冷静に見ると驚異的に速い。ここ2ヶ月だけでも見違えるほど進歩した。ただ,逆茹でガエル状態というか,進歩しているのがデライトの日常になっているせいで,たまに振り返ってみないとその速さが分からなくなる。振り返りの重要性を再認識したので,また旬毎に振り返りの時間を持つことにした。

{希哲16年6月1日6歩 K#F85E/E74C-6B75}

{希哲16年5月6日の散歩 K#F85E/E74C-5467}

{希哲16年5月4日の日記 K#F85E/E74C-5BD0}

{希哲16年4月21日の開発 K#F85E/E74C-FDDC}
輪郭選り手抜控機能整備中,思いがけず事象処理整理が捗り始めた。
Aejs の事象委譲機構を整備した頃から @DG.bld.
に事象処理が集中するようになり,最初は全体像が把握しやすいという利点もあったものの,聴取子が増えるにつれ見通しが悪くなり,最近は問題に感じることが多くなっていた。
流石にそろそろ限界だろうと分散させ始めたところ,思いのほか上手く整理出来そうな感触を得た。
事象委譲を多用し過ぎると,客体指向的な整理が難しくなり,閉包子を利用した参照の簡略化も十分に出来なくなる。記述の複雑化もさることながら,思っていたより無駄な探索処理が増えていたことに気付いた。このあたりの理解不足による,効率性が落ちるのではないかという懸念が無くなったのが大きい。
多少目先の時間はかかるが,新生デライトの完成までを考えると間違いなく近道になる。急がば回れで事象処理整理も同時に進めていくことにした。
-webkit-tap-highlight-color
}{妙な効果}{タップ時}{用意されている}...
{希哲16年4月7日14歩 K#F85E/E74C-D3A9}
「iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元の iPhone で同様の現象があり,気になっていた。デライトの不具合にしては不可解なのでもしかしたら舞覧の稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。
結局,諸場舞覧の自動拡大機能であり,text-size-adjust
(-webkit-text-size-adjust
)という制御用の CSS プロパティまで用意されていることが分かった。以下のようにして解決。
-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;
もう一つ,諸場舞覧で気になっていたことに,輪結やボタンのタップ時に妙な効果が入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有の機能で,-webkit-tap-highlight-color
で不可視に出来た。
スマホを弄っているうちに,iOS の Safari で全知検索ボタンの動き付けが止まっていることに気付いた。
これはフォームの送信などで描画処理が停止する Safari 特有の仕様であることが分かった。Safari の問題といえばそうだが,実用上の問題はなく,まともな解決策も無さそうなので放っておくことにした。
全知検索整備の方針も定まったことだし,そろそろページ遷移無しで輪郭一覧の更新が出来るようにしてもいい頃だろう。
@tgt_evt.bld..off()
}{以前にもあった}{単純な仕組み}{加えたくない}{論理的欠陥}...
{希哲16年3月19日3歩 K#F85E/E74C-D3A4}
昨日,ボタンの要素分類名を置換した時に上手く事象処理が出来ないという問題に少し時間を取られたが,事象と委譲元の1つの組み合わせには1つの聴取子をあて,聴取子内で処理を分けることにしていったん解決した。
この問題は,以下のように,同一要素を指す .foo
,.bar
の発泡事象を祖先要素 prn
に委譲した場合に起こる。
prn.on_clk( '.foo', fn_foo )
.on_clk( '.bar', fn_bar );
この時,fn_foo()
内で .foo
を .bar
に(遅延なく)置換すると,.bar
の click
事象向け聴取子も実行されてしまう(恐らくは発泡を捕捉した時点での分類名だから?)。似たような問題は以前にもあったが,未解決だった(希哲14年10月27日16歩)。
最初は不可解な現象だったが,だんだん Aejs の事象委譲に原因があることが分かってきた。ただ,久しぶりに @tgt_evt.bld..on()
を読み直したものの,目立った論理的欠陥は無かった。捕捉した事象の判定をしているだけの単純な仕組みなので,同一事象・同一要素に対して聴取子を分ける使い方自体が問題のような気がしてきた。大張りを考えると余計な処理も加えたくない。
そろそろ @tgt_evt.bld..off()
を追加してもいい頃だが,とりあえずは以下のように書き換えておくことにした。
prn.on_clk( '.foo, .bar', fn ( evt )
{
if ( evt.tgt().b( '.foo' ) ) {
// .foo 向け処理
} else {
// .bar 向け処理
}
} );

{希哲16年3月15日の整清 K#F85E/E74C-E2DC}
