演算子多重定義の大原則は意味的な整合性を破壊しないことなので最初はひどい言語だなと思ったが,「ノードを分割する」という意味まで考えているならむしろあっぱれ。
/
は意外と合理的かもしれない K#F85E/E74C-D499}演算子多重定義の大原則は意味的な整合性を破壊しないことなので最初はひどい言語だなと思ったが,「ノードを分割する」という意味まで考えているならむしろあっぱれ。
UNION ALL
}{希哲16年10月の開発}{新生全知検索整備}{UNION
}{検索群類}{開発}{全知検索演算子}(23)最初の中間出振るいに成功。これにより,全知検索の応答速度,柔軟性,交度品質が大きく向上した。出振るい作業も円滑に進み,手溢れも無く,全体として大成功だった。
まず,期待通り,輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも,この種のサービスとしては並という程度から,はっきり速いと言える程度になり,快適度が数段上がった感覚がある。
これまでのデライト高速化施策の中でも最大級の効果を感じるが,これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは,相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。
これまで,ページに表示される輪郭情報の取得は,相振りから大体次の流れで行っていた。
dg_oln()
)。dg_fnd()
か,吊るし輪郭の初期状態は dg_fg()
,dg_bg()
)。この旧方式では,KNEST 隠しも一部でしか活用出来ておらず,中景輪数に応じて求頼が増え過ぎる問題があった。1ページあたり最大45回の求頼が発生する可能性があったことになり,当然,相振り・出場間の通信コストがそのまま応答速度低下に繋がっていた。
KNEST 隠し実装を一段落させた6月30日の開発でまとめた方針に基き,これを次のように改良した。
dg_fnd()
)。dg_oln()
)。dg_ego()
)。この新方式により,求頼は最大でも3回で済み,KNEST 隠しも十分に活用出来るようになった。同期と隠しのばら成しも良く,基礎として理想的だ。あとは必要に応じて HTML 隠しなどで補完すれば十分だろう。
upub
を導入した7月から微妙な応答速度低下が気になるようになり,検索演心からのクロール頻度や評価の低下といった悪影響もあったため,輪郭情報取得改良は高速化の特効薬としても新生全知検索整備の最優先当努だった。
最悪見込み違いという不安もなくはなく,これだけ大胆な改良だったので不具合多発の懸念も大きかったが,速度も安定性も申し分ない結果となった。Cμ 文字列処理改良,KNEST 隠し実装,前後景時印の導入といったこれまでの高速化施策がしっかり活かせるようになったのも嬉しい。
4月7日10歩から検討していた「検索属性」もここで「検索群類」として導入に成功し,異なる条件の輪郭一覧を結合出来るようになった。
最初に着手した b_bg_his
の削除もここで本番環境に適用され,上描き履歴は完全に廃止となった。
輪郭情報取得改良は一見単純なようで,実際にやってみると意外に複雑な交度が必要だった。当初,dg_fnd()
の SQL 周りが最難関だと思い込んでいたため,6日の開発での解決時には一山越えたと思ったが,その後のテンプレート処理の方が大変だった。
この誤算で,長いこと放置していたテンプレート周りの乱雑な交度も整理せざるをえなくなり,結果として自分でも驚くほど整理整頓出来てしまった。
_dg
}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}(102)応答速度が異常に遅い輪郭についての不具合調査から求頼改良・出場改良のアイデアがまとまり,一気に実装した。
_dg
は _dg_oln
と結合しないと揃えが出来ず,揃えで極端に遅くなる場合があることは認識していたが,時印を追加することは正規化の観点から避けてきた。
公開設定機能の導入で必要性が低くなった揃え用時印を廃案にすることを最近考えていたが,これに近い役割を持たせた ts_fg
,ts_bg
を追加することを思い付き,急速にまとまった。単なる複製ならやはり避けたかったが,より抽象的な時印を _dg
が持っていることは不自然ではなく,同期も引き入れ・再描出処理で行うだけでいい。
手定めしてみると,低負荷求頼では索引が使われず有意差は見られなかったものの,高負荷求頼では数倍から十倍程度までの高速化が見られた。求頼最適化の選択肢が増えることでサービス全体の負荷抑制が見込める。
領下での実装・手定めは終えたが,稼動させながらの _dg
の修正は無理そうなので明日早朝出振るいすることにした。
これにより応答速度が異常に遅い輪郭についても改善が見られたが,異常であることは変わらず,根本的な解決にはならなかった。
当初,輪括が膨大な輪郭特有の問題だろうと思っていたが,一見何でもなさそうな輪郭でも発生している。
ここで,検討していた揃え用時印(ts
)は正式に廃案とすることにした。
簡単な時印更新が可能になり,公開設定機能で目立たせない再描出も可能になったので必要性を感じなくなった。となると実装と用合いの複雑化の懸念が大き過ぎる。
2月23日頃から検索結果の改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果の多段化を進めていくことにした。
現状,例えば括弧類を自動付加した検索は出来るが,その逆は出来ない。括弧付きで描出したい場合,括弧無しで検索して既存輪郭が無いことを確認した後,括弧を付けて再検索するということが多く,とりあえずこの手間を無くしたかった。全知検索演算子の制御に任意の括弧類を使えると好都合ということもあった。
文字数の昇順で揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面が多々あるので一時凌ぎの域を出ない。
将来的な拡張性も考えると検索結果の多段化が好ましい。風船輪郭や輪括内検索にも応用出来る。希哲14年7月30日8歩から輪括内検索は輪括内のみにすると使いにくいという理由で中途半端な状態になっていたが,優先表示で解決出来ることに気付いた。
整数値に揃えを兼ねた役割を与え,これを「検索属性」として利用出来るようにする。
ここまでは良いが,効率的な実装が難しい。単純に全ての検索パターンを UNION
で結合すればひどいことになるのは目に見えている。外充て函数で余計な検索を省くようにする,挿入・更新時に確定出来る情報はフラグ化しておくといったことに加えて,後縁での出力は最低限にして前縁で追加取得するといった工夫が必要になるかもしれない。
いずれにせよ後縁の対応は進めて問題ないだろう。設計方針さえ固まれば最適化はどうとでもなる。
希哲15年4月14日,本格的にデライト高速化に入る前の現状整理について,ここに記録しておく。
2月後半は姪を預っていたこともあり開発に集中しにくかったが,3月の頭からデライト開発はいわば「快調期」に入った。この想定外の快調でそれ以前の計画が良い意味で狂うことが多くなり,3月8日からは計画にとらわれず直感に従って作業を進めていくことにしていた(日記)。
この快調によって,より高い完成度での新生デライトを目指すことが出来るようになり(第三次デライト市場戦略),3月20日,収益目標達成の努力期限を5月1日に延長,28日にはこれを必達期限として,同時に短期集中生活に入った(日記)。短期集中生活は今月10日に終え,やり残した待っ読ボタン実装は昨日一段落した。これが「デライトこれまでのあらすじ」といったところか。
少し落ち着いたところで,次の作業に入る前に現状を整理することにした。収益目標達成期限まで残すところ半月,作業の優先順位を見極める必要があった。短期間にこれだけのことがあると,流石に頭の中も混乱気味だ。もやもやしたものを晴らしておきたかった。
現在のデライト開発の速さと予測不可能性を考えると,やはり中途半端な計画は足枷にしかならない。「黄金循環高速化」としてのデライト高速化を中心に,機能追加,文書整備,宣伝等々,全てを臨機応変に巻き込みながら片付けていく,というのが現状での最適解と結論付けた。
デライトにとって最大の付徴は輪郭法であって,枝葉末節の機能ではない。それを磨き上げ,伝わりやすくする作業でもある。
作業項目としての「デライト高速化」を意識し始めたのは2月17日の開発からだった。当初は機能追加よりも優先し,文書整備と並行させることを考えていた。その後,快調期に入ってから機能追加の優先順位が上がり,特に Dex によるデラング整備を優先するようになっていった。
今月頭の時点での大まかな見通しは,10日までに必要な機能追加,20日までに新生デライトの仕上げ,文書整備を終え,21日から第三次宣伝攻勢を開始,並行してデライト高速化を進める,というものだった(1日の日記)。
ところが,@icl() 周辺整備をきっかけに入った小理腑が,1〜2日という想定よりも長引き(6日間),上旬がほぼ潰れた。更に,これが思わぬ体感表示速度向上に繋がったことで,一気に高速化への持ち辺が高まった。この頃から,どちらかといえば後回しにするつもりだった高速化を最優先にすべきではないか,と考えるようになっていた。待っ読ボタン実装を終えた昨日の時点でほぼ腹が決まっており,最終確認のためにこの現状整理をしているわけだ。この判断は収益目標達成の成否に直結するだろう。
デライト高速化の主な意義としては,用者体験の向上,SEO,負荷軽減の3つを当初から見込んでいた。
小理腑後は,これに開発効率・描出効率の向上という意義が加わった。手定め時間の短縮にもなるし,より描出の質を上げ量を増やすことにも繋がるだろう。頭では分かっていたことだが,速いデライトを体験して実感が出てきた。この「先行体験」をさせてくれた小理腑の影響が大きい。
Dex 以後,デラングを活用することにした文書整備にも寄与することになる。
高速化に並ぶ大きな作業分類であるデラングを含む機能整備(機能追加),文書整備と比べても,やはり高速化が優位だろう。何より,高速化は技術面でも設計面でもデライト向きであり,この中で最も「伸ばせる」ところだ。本領発揮と言ってもいい。
機能追加が訴求するかどうかは当たり外れが大きい。開発者が求めているものと用者が求めているものは異なることが多いが,用者が求めているものと必要としているものも往々にして異なる。要望に応えても,思ったより必要なかったということもある。これは用者が馬鹿だからではない。開発者ですら,思ったより要らなかった,要らないと思っていたが意外と便利だった,ということは多々ある。人間そんなものだ。それでも,十分な時間があれば「数撃ちゃ当たる」で成功確率を高めることは出来るが,今はそうではない。
そもそも,現状デライトの活動用者は極端に少なく,動向を分析する標本にもならない。まずは入り口の手前にいる人達を呼び込む必要がある。そのためには,一部の用者しか使わない高度な機能よりも第一印象が重要であり,これに寄与するのは高速化だ。
また,機能追加には程度の差こそあれ通信や処理上の負荷が伴なう。予定している機能を現状のデライトに全て詰め込めば明らかに重くなるのは目に見えている。
文書整備に関しては,ある程度機能整備が済んだところか,少なくとも機能整備と並行させなければ作業効率上の問題がある。これだけ仕様変更・機能追加が激しい状況でなまじ文書を追随させても修正回数が増えるだけだ。先の理由で機能整備を後回しにするなら文書整備も後回しにするほかない。
現状,「使い方」などの文書は離立補完を最後にほとんど更新しておらず,実装との乖離が激しくなっているが,逆に言えば,無駄な修正作業が省けたということだ。新生デライトが熟れるまで放っておくのも一つの手だろう。
宣伝においても体験を重視するようになる中で,相対的な重要性が低下していたということもある。「良い文書のある悪い体験」よりは「悪い文書しかない良い体験」の方がマシだ。
「黄金循環」は,1月から再認識し,2月までよく言及していたが,3月からは快調期の目まぐるしさで横に置いていた。
振り返ってみると,2月20日の日記で高速化との結合を予期するようなことを書いている。ただ,それほど強く両者の結合を意識していたわけではなく,黄金循環高速化の手段も明確ではなかった。「全知検索の改良」と言っても,基本的な部分で問題の多かった希哲13年頃に比べ,今では範囲が広過ぎる。
快調期以後,計画ではなく直感に従うという戦法で難局を上手く切り抜けてきたが,「次の作業」を意識するようになった短期集中生活終盤あたりから,作業の軸になるものが欠けていると感じていた。
ここで高速化と黄金循環が結合してその軸として機能し始めるのだから,劇的な展開と言うほかない。ここまでの経験が全て一つに繋がったことになる。
アイコン制作続き。
共有ボタン・フィードボタン用のアイコンを作っていったん終了。
フィードボタン用のアイコンはごく一般的なものだが,一応自作しておいた。
共有ボタンの方は少し悩んだが,三点をくの字形に結ぶアイコンを少し修正し,矢印が伸びるようにした。より拡散のイメージが掴みやすい。
一点から二本の矢印が伸びるという共有アイコンの形は初期 Android で採用されていたが,なぜか現在の形に修正された。
拡散というよりはネットワークの結合というイメージを強調したかったのかもしれないが,直感的とは言えない。
iOS では基本的に四角から矢印が飛び出すような徹案になっているが,正直これは更に色々な意味で分かりにくいと感じる。
デライトの試作共有アイコンは,結果的に両者の折衷案になった。
主力機は記憶器をしっかり使ったまま24時間の安帯を越え,きびきびよく動いている。