作業中の当努の影響を受けないようにして,ここでいったん全体出振るい。手定め済み。
SNS における Twitter が,個人知識管理サービスにおける Evernote に似た位置付けになってきて,「SNS 戦国時代」の訪れを感じる。一時停滞感のあった「メモ戦国時代」も再び盛り上がりを見せており,KNS たるデライトにとっては最高の状況が出来つつある。
GAFAM は停滞期に入り,次の時代が模索されている。人工知能の実用化が急速に進んだことで,かつての「人工知能幻想」は鳴りを潜め,人間の知能が本当の問題であることに多くの人が気付きつつある。
KNS として,全知検索演心として,知能増幅技術として,この時代の課題に最も単純明快で最も強力な解答を提示出来るデライトは快調に開発を続けている。デライトと時代がようやく密致しつつあるのを強く感じる。
最近,Twitter の代替として注目されている Nostr を興味深く眺めている。ネット受けするのに,分かりやすさも使いやすさも信頼性も効率性も高度な機能も実は必要ない,ということの好例でもある。
既成概念の組み合わせである Nostr は難しいといっても多少の知識があれば理解出来るし共有出来る。適度な難しさだから共有したくなる。最も知識のある層にも理解し難いデライトとは出発点が違うものの,新生デライトの完成を目指した全力疾走の通過点として,こういう受容のされ方がすぐそこにあるかもしれないと思える。
埋め込み記法で埋め込まれている輪郭を描き直しても埋め込んでいる輪郭を描き直さなければ反映されない問題の修正,および一部機能で削除済み輪郭が取得出来てしまう問題の修正で終了。
前者の原因は単純に描写 HTML 隠しによるものだったが,報告を受け気付いた。
埋め込み記法処理も Dex_T
の外に出すかと考えたが,隠しの利用効率を考えると好ましくない。そこで,KNEST_T
に埋め込み関係の情報を持たせ,再描出時と輪郭削除時に描写 HTML 隠しを消去するようにした。これなら効率性と柔軟性を両立出来る。
作業中,削除済み輪郭が描写埋め込みや輪郭小窓から参照出来てしまう問題に気付き,これも修正しておいた。
dg_oln()
が b_del
を無視して輪郭情報を返すようになっていた上,一連の函数がそれを前提に実装されていた。これを機に違了処理も見直し,信頼性が向上した。
作業方針検討(4歩),閲覧専用模動実装検討(5歩),デラング整備・埋め込み記法処理改良(8歩〜13歩)。
これまで,埋め込み記法処理の中でも oEmbed を利用したものについては,Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが,埋め込み交度の取得処理を専用 API /mbd
に委ね,前縁 Aejs から利用することにした。結果として,応答速度改善に成功した。
埋め込み記法(+[URL]
)の URL が oEmbed を必要とする場合,Dex では適当な分類名を付与した <div>
に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し,URL を /mbd
に転送する。/mbd
は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す,という流れになる。過剰な立求を抑止するため,Aejs には簡易的な隠しも持たせておいた。
そもそものきっかけは,先日の SlideShare 対応だった。oEmbed が必要になったので,埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ,記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか,引っかかりはあった。
KNEST 隠しを使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
9日の SlideShare 対応後,意外にもすぐに若干の応答速度低下を感じるようになり,作業の優先順位が上がった。スライドの埋め込み自体はデライト公式での紹介輪郭でしか使われておらず,因果関係は不明だったものの,時期があまりにも一致していた。Google のクロール統計でも,9日以後はそれ以前と比べて100ms以上の平均応答時間増加が連日見られ,体感とも一致していた。
ざっと Aejs で oEmbed を利用する交度を書いて実行してみると,CORS の違了が発生し,一気に記憶が蘇ってきた。
元々前縁でやろうとしていたのを,CORS 問題が面倒で後縁完結にしたのだった。よほど高尚な理由がないとこの実装はありえないだろうと深読みしていたが,なるほど,単なる一時凌ぎという線があった。当時の記録も残っていた。
仕方ないので,当時面倒臭がってやらなかった専用 API を作ることにし,/mbd
を追加した。Aejs には埋め込み記法処理を集約する @mbd
を追加した。
中継サービスを利用するのが一番簡単な方法だが,信頼性や使い勝手などで不確実性が高い。
出振るい後,すぐに明らかな体感速度向上が見られた。もう少し様子見は必要だが,見込みは正しかったか。だとしても,応答速度低下の原因ははっきりしていない。原因究明にかけられる時間も無い。
一つの輪郭中の一つの oEmbed 通信がサービス全体の応答速度低下を招いたとは考えにくい。考えられるとすれば,握接集中で立求処理が詰まった,あたりか。SlideShare 対応によって気付かない内に何らかの問題を持ち込み,埋め込み記法処理改良によって解消したか,全く別の問題が偶然同時期に発生していただけ,という可能性もなくはない。
いずれにせよ,今回の埋め込み記法処理改良によってデライトの安定性・効率性が大きく向上したのは間違いない。従来の方式では,ページ内で oEmbed を利用する回数×通信時間の応答速度低下があった上に,描写 HTML のタグ削除をしている RSS でも無駄な通信が発生していた。
これは方式によらず発生しうる問題だが,下見機能などで頻繁に更新する場合,その都度 oEmbed 通信が発生していたことに気付き,@mbd
に客体変数を使った隠しを持たせておいた。役割分担が進んだことで今後はこうした最適化もやりやすくなる。/mbd
に隠しを持たせることも検討しておくことにした。
少し懸念していたのが埋め込み献典の描画速度だったが,これも全く気にならなかった。そもそもこの手の埋め込み献典の描画は遅いものなので,多少の変化では分からない。
新生全知検索整備,ページ付け求頼改良,サイトマップ改良,不具合修正など。
これまでサイトマップは全知検索ページャー同様,一定輪数を LIMIT
句・OFFSET
句で区切ったページを返していた。OFFSET
句の値が多くなると遅くなるため,最大でも最新10,000輪(100輪×100ページ)が限度だった。upub
導入後は更に低速化したため,9,000輪まで減らしていたが,それでも後半になると応答時間が10秒以上になることがあった。
今回のページ付け求頼改良で時印を使ったページ付けに移行しようとしていたため,これをサイトマップにも応用出来るのではないかと考えていたが,サイトマップの場合,サイトマップインデックスで各サイトマップ URL の一覧を生成する必要があり,この効率性が問題だった。HTML 隠しの利用も考えたが,タイミングも難しく,大袈裟過ぎる気がしていた。
サイトマップの場合,各ページの輪数が揃っている必要はないのだから,一定期間で区切ってしまえばいいのではないか,ということに気付いてからは速かった。
まず,デライト上で最古の時印(2012-02-10 19:09:33
)から現在時刻までを30日で割って必要なページ数を割り出し,サイトマップインデックスは従来通りの形式(/see?pg=[n]
)で生成する。dg_see()
ではページ番号から期間を計算してその範囲内で上限輪数までの最新輪郭情報を返す。上限輪数はとりあえず10,000輪にしておいた。数値は様子を見ながら調整していく。
インターフェイスはそのまま利用したため修正は最小限で済み,互換性も維持出来たが,元々 dg_see()
に余計な列が多い問題があったのでそのあたりも最適化しておいた。
実作業は出振るい・手定めまで正味3時間ほどで済み,結果として,サイトマップの速度・ページ数・対応期間の長さがはるかに向上した。現在時刻が基準なので,上限輪数から漏れた分も待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性と効率性を完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求に適ったサイトマップ設計という,大きな問題がまた一つ解決した。
輪数取得改良,前後景時印の導入などを経て,サイトマップは高負荷求頼が発生しやすい最後の箇所になっていたため,これでデライトの安定稼動における不安要素が払拭出来た。ページ付け求頼改良を急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号の直接指定に上限を設けたため,高負荷求頼の問題は一応解決している。これでページ付け求頼改良の優先順位が少し下がった。
kn
の外充て函数}{KNEST 隠し実装}{見込める}{作業範囲}(21)自我知番省略機能実装を終え,第二次知番改良も完了とした(20歩)。ここでやっておこうと思ったのも,途中で第零番節の削除に転換したのもあまりに急だったが,その割には終始円滑に捗り,収穫は想定をはるかに越えて多大だった。全体として大成功と言っていいだろう。
第二次知番改良を経て,知番は表記的にも内部的にも完成の域に達した。あとは仕様・実装の微調整を繰り返していく。
まず,当初の目的だった知番の簡略化は言うまでもなく大きい。これまで,一般のデライト用者は最短でも K#9-XXXX/A-YYYY
という15文字の知番で輪郭を扱う必要があった。それが第零番節の削除によって11文字の K#XXXX/YYYY
になり,自我知番の省略によって7文字の K#/YYYY
になった。知番表記仕様に関しては理想的な形だ。
「第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度・出場整理も劇的に進んだ。これにより,効率性と保守性が大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫に繋がった。未実装だった自動知番拡張もここで実装出来た。今のところ第二番節は私しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。
波及効果も想定以上に大きかった。出場の見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮が見込めるようになった。特に見通しが悪い課題だった KNEST 隠しの出与え構造がこの期間に固まり,一気に実装可能性が高まった。自我知番省略機能で Dex との連携が必要になったことで,他の記法でも活かせる出与え共有機構が整った。これが無番輪符改良などにも繋がっている。
将来的に長い知番が増えた時のための「知番略記法」を中心とした第三次知番改良の方針も固まった。この長年の課題にも解決の見通しが立った。
一つ見送ったこともある。自我知番が省略された知番の写し取り時に自我知番を付け,自輪郭の描写欄などへの貼り付け時に自我知番の省略をする(4月8日の開発記録),というのは,やはり用合いとしては理想的で盛り込みたかったが,今回は見送った。このあたりの事象は Aejs で整理中なので,どうしても場当たり的な交度になってしまう。他輪郭の素出から写し取りたい時や,外部媒体に厳密な知番を貼り付けたいという時には便利だが,現時点で必要としている人は少ない。共有目的なら共有ボタンがある。交度整理しながら適当な時期に実装することにした。
輪郭選り手抜控機能整備中,思いがけず事象処理整理が捗り始めた。
Aejs の事象委譲機構を整備した頃から @DG.bld.
に事象処理が集中するようになり,最初は全体像が把握しやすいという利点もあったものの,聴取子が増えるにつれ見通しが悪くなり,最近は問題に感じることが多くなっていた。
流石にそろそろ限界だろうと分散させ始めたところ,思いのほか上手く整理出来そうな感触を得た。
事象委譲を多用し過ぎると,客体指向的な整理が難しくなり,閉包子を利用した参照の簡略化も十分に出来なくなる。記述の複雑化もさることながら,思っていたより無駄な探索処理が増えていたことに気付いた。このあたりの理解不足による,効率性が落ちるのではないかという懸念が無くなったのが大きい。
多少目先の時間はかかるが,新生デライトの完成までを考えると間違いなく近道になる。急がば回れで事象処理整理も同時に進めていくことにした。
今後の Dex 設計方針についての検討で終了。これから越化参照が大活躍しそうだ。
まず,課題だった脚注記法の実装方針について検討している内に,越化参照が部区間通信に活用出来ることに気付いた。
部区毎に越化条件の変化などがあることから,各記法の解釈は部区個体に任せたい。しかし,脚注記法のように最上位部区との出与え共有が必要な記法もある。
このような場合,単純に考えれば指示体を通して部区個体間で変数を共有するということになるが,この種の記法が増えるたびに目的別の指示体を増やすのは設計として美しくない。汎用的な変数一つに集約するのも,効率性や厳密性の観点から難がある。
ここでふと,越化参照が使えることに気付いた。下位の部区個体で中途解釈した記法には目印となる越化参照を付け,上位の部区個体で変換処理を完了させる。
これに似た部区間通信の手法は Dex 初期実装から現 &_skp;
で使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲を広げなかった。紆余曲折を経て,これが一番単純性・効率性・保守性のバランスが良いということが分かった。
これで脚注記法や目次記法の実装は容易になった。他にも,輪郭情報の参照が必要な記法など,部区間通信が必要な場面全般で越化参照が活用出来るだろう。
1月21日4歩で,&_tgt;
や &_fin;
のような目印を付加することを考えていたが,付加的な越化参照では結局正規表現の複雑化が避けられないため,実用化出来ていなかった。
昨日終えた客体表現への書き換えで Dex 初期実装の交度を整理している時,再置換を避けるため記法の一部を越化参照(当時の疑似実体参照)に置換する手法を使っていたことを思い出した。これもあまり積極的に応用範囲を広げなかった手法だが,思っていたより合理的であることに気付いた。
例えば,http
は &_http;
のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なことの真価を理解するには時間がかかるということを改めて学んだ。経験不足だと,どうしてもより高度そうなことに目移りしてしまう。
直感で編み出した Dex 初期実装の手法を再評価する十分な経験が出来たこともあるが,「越化参照」という概念が完成し,積極的な活用を考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。
rgx_T
}{s_T
の補助函数}{幸いした}{書き換え作業}{置換作業}{必要な時期}{置換した}(69)Cμ 文字列処理改良,rgx_T
の置換道手の引数順序変更。
あとは rgx_T::rpl()
の引数順序変更で rgx_T
の置換道手の引数順序変更は完了だが,これまでの道手の呼び出し箇所が Dex のごく一部に限られていたのに対し,.rpl()
は Cμ 初期からあちこちで使っている置換道手なので,少し複雑な作業になる。
まず,いったん .rpl()
を適当な名前に変えて無効化し,呼び出し箇所を引数順序変更済みの .rpl_glb()
あるいは客体表現に置換するか,正規表現・客体表現を使うまでもない処理なら s_T
の補助函数に置換する。現時点で .rpl_glb()
は .rpl()
の冗長版に過ぎないため,置換したままにしておいて問題ない。交度整理をしていけば自然に戻るはずなので,あえて再置換はしないことにした。
置換作業に入る前に,作業に必要な s_T
の補助函数整備も必要だが,既存の「類型化正規表現」(rgx_x_T
)の置換道手も旧式の引数順序にならっているため,まず最初に客体表現(ojx_x_T
)への書き換え作業を済ませることにした。rgx_T
を直接使った交度から類型化正規表現への書き換え作業が想定より遅滞していたことが幸いして,現時点で類型化正規表現は多くない。
いずれにせよ,正規表現の総点検や客体表現への書き換えが必要な時期であり,保守性と効率性の大きな向上が見込める良い機会だ。