full knowledge search
知識の集合に対する検索。そのうち,描主が自身の知識を主な対象にするものを想起検索という。
いったん出振るいを終え,他自我内検索用合い改良兼自我ページ整備が一段落した。
開発時間が確保しにくい時期だったことや交度整理に時間をかけたことで12月22日に着手してから日数はかかったが,総合的に満足出来る結果となった。
特に,実装時期の予測すら出来なかった自我ページ整備が出来たことが大きい。これで新生デライト像が完全なものになった。自我ページ整備自体の作業時間は正味2日間程度で,時間対効果も非常に高かった。
今後はまず新生全知検索整備に戻り,輪郭整備兼文書整備と並行させ新生デライトの成立を目指すことになる。
12月19日の検討通り,他自我内検索時に自我アイコンを並べ,自我ページではこれをプロフィール風に見せることにした(整備後1,整備後2)。
見ただけではまずやり方が分からなかった他自我内検索が整合的かつ直感的に行えるようになり,自我知番による検索結果に過ぎず一見意味の分からない自我ページ(整備前)も一応プロフィールページらしくなった。
自我ページは,デライトにおける自己表現の入り口となる部分であり,初めてデライトに触れた人がまず覗いてみる部分でもあるので,直感的に理解出来るようになったことは大きな進歩と言える。最低限の又情報も設定したので多少の SEO 効果も望める。あとは風船輪郭が出来れば,デライトのプロフィールページとしては無駄なく十分なものになるだろう。
src
属性}{<script>
}{希哲16年12月19日の副日記}{付かない}{https:
}(192)長いこと課題だった自我ページと風船輪郭について良い閃きがあり,急速に実装方針がまとまった。
現状,自我ページは URL のみ正規化している(/KNo.XXXX
)が内容は単なる自我知番での検索結果であり,プロフィールページとしては貧弱過ぎる。自我輪郭などの案はあったが,既存機能や領当てとの整合性をとるのが難しく,自我ページとしてはなかなかイメージがまとまらなかった。かなり難航しそうだったため,新生デライトの要件にも入れなかった。
最近の大輪郭整備で必要性を強く感じるようになっていたこともあり,もう少し現実的に,低コストで実現出来る案でまとめてみることにした。
まず,他自我内検索の用合いを既存の自自我内検索と整合させるため,以下のように,自我アイコンを並べるか重ねるかして,& ボタンで段階的な切り替えが出来るようにする。さらに,自我アイコンの下に「○○さん K#XXXX の描き出しです。」と表示する。
これで,全知検索の機能性はそのままに,プロフィールページに最低限必要なアイコンと名前の表示が出来る。自我アイコンの複数表示自体はかなり以前から他自我内検索用合いの案としてあったが,これに名前を添えてプロフィールページの見出しを兼ねさせるというアイデアが新しかった。
大した作業ではなく,新生デライトの完成の遅れも今更なので,これは新生デライトの要件に追加することにした。
NULL
}{希哲16年12月19日の開発}(105)「社会」で全知検索した際,応答速度が異常に遅かった上に,表示された K#0001
の輪郭表示がおかしかった。K#0001
の輪郭に限って前後景輪数が異常な数値になっていて,輪郭知番が K#0001
と表示される輪郭があった。
前後景輪数表示不具合は以前特に番無しでよく起きていたものと同じで,特定自我の全ての輪郭の前後景輪数が不正な特定の値になっているというものだったが,最近は見かけなくなっていた。異常に遅いページも,9月までの諸改良でなくなっていたので意外だった。
出場を調べると,不正知番 K#0001/0000
を持つ輪郭が存在することが分かった(新規描出時印 2015-12-28 14:17:00
)。昔特殊用途で作ったものかと思ったが,知名が「社会」で,同知名の輪郭とは違って意図が全く分からなかった。情報価値もなく,デライトが依存している部分は無いため,これは単純に削除した。すると応答速度は正常化したため,応答速度の問題に関してはこれが原因であることが分かった。
前後景輪数表示不具合は例によって n_fg
,n_bg
を NULL
で初期化することでいったん解決。
他にも _kt_oln_1
と _kt_oln_2
が0になっている輪郭がないか調査したところ,一つだけ K#DF1B/0000
があった(新規描出時印 2019-02-28 23:56:22
)。これはデライト開発最初期,希哲13年2月28日のツイストで,当時の記憶をよく残しているものなので,複製輪郭を作ってから輪括とともに削除した。
もう体裁にこだわっていても仕方ないので公開手定め(テスト)でやっていくことにした。
恐らく手定め用と思われる自我から描出しているのもおかしいが混乱期だったのだろう。前後景輪数表示不具合修正では以前にも同様の不正知番を発見したことがあり(希哲15年4月16日4歩),やはり何らかの引き金になった可能性はある。
輪郭一覧動的更新対応については一段落。
全知検索窓からの検索,新規描出,更新輪結で輪郭一覧を動的に更新出来るようになった。これまで通りの握接も出来る。請い手にとっても捌き手にとっても負荷軽減になり,全知検索の感触が非常に良くなった。Safari ではページ遷移の発生時に動き付けが止まるため余計かくかくした感触だったが,これも解消した。
デライトでは相振りとしての可使性,ウェブサイトとしての可接性を両立させた HPA(hybrid paging application)を目指してきたが,自動ページ展開機能に続いてこれで概ね理想に近い形になった。第二次用合い改良と新生全知検索整備の交差点でもあり,感慨深かった。
更新時の動き付けは多少工夫が必要だった。最初は,更新前の輪郭一覧を完全に溶暗させ,更新後の輪郭一覧を溶明させるという動き付けを試したが,ちかちかして良くなかった。opacity: 0.7
まで少し溶暗させて置換してから溶明させるようにしたら良い感じになった。新規描出で輪郭一覧の上部に移動する時はスムーススクロールが鬱陶しいのでこの時だけ無効化するようにした。これで概ね満足出来た。
ここで広告の動的挿入も必要になったため機能を整えた。これまで自動ページ展開部分には広告を付けていなかったが,これを機に奇数ページで広告が表示されるようにした。
新生全知検索整備,ページ付け求頼改良,サイトマップ改良,不具合修正など。
これまでサイトマップは全知検索ページャー同様,一定輪数を 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時間ほどで済み,結果として,サイトマップの速度・ページ数・対応期間の長さがはるかに向上した。現在時刻が基準なので,上限輪数から漏れた分も待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性と効率性を完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求に適ったサイトマップ設計という,大きな問題がまた一つ解決した。
輪数取得改良,前後景時印の導入などを経て,サイトマップは高負荷求頼が発生しやすい最後の箇所になっていたため,これでデライトの安定稼動における不安要素が払拭出来た。ページ付け求頼改良を急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号の直接指定に上限を設けたため,高負荷求頼の問題は一応解決している。これでページ付け求頼改良の優先順位が少し下がった。