{希哲16年9月22日}{希哲16年9月22日の副日記}{解決している}{設けた}{直接指定}{最近の出振るい}{下がった}{急いでいた}{発生しやすい}{適った}...=}(164)

{希哲16年9月22日の開発 K#F85E/E74C-FB21}

新生全知検索整備ページ付け求頼改良サイトマップ改良不具合修正など。

サイトマップ改良急進展

特に長いこと課題だったサイトマップ改良急進展した。

これまでサイトマップ全知検索ページャー同様,一定輪数LIMITOFFSET区切ったページ返していた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時間ほどで済み結果としてサイトマップ速度ページ数対応期間の長さはるかに向上した現在時刻基準なので,上限輪数から漏れた分待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性効率性完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求適ったサイトマップ設計という,大きな問題また一つ解決した

輪数取得改良前後景時印導入などを経てサイトマップ高負荷求頼発生しやすい最後の箇所になっていたため,これでデライト安定稼動における不安要素払拭出来たページ付け求頼改良急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号直接指定上限設けたため,高負荷求頼問題一応解決している。これでページ付け求頼改良優先順位少し下がった

{希哲16年2月14日}{デラング}{進捗記録}{SySS}{持つ}{希哲16年2月14日の開発}{タグ記法}{活かせそう}{XML 化}{DXML}...=}(45)

{希哲16年2月14日10歩 K#F85E/E74C-6454}

客体表現への書き換えHTML タグ関連の整理差し掛かったため,少し概念的整理をして終了

これまでデラングでは HTML タグ一部をそのまま使える,ということにしていたが,将来的な拡張性考え,(ほぼ)HTML 互換XML 風タグ記法」を持つ,という考え方にすることにした。

例えば又情報埋め込みたいとか,独自要素使いたいという要求応えるなら,下手に独自記法拡張するより XML柔軟性利用する方が理に適っている

そのうちデラングXML 化した XDMLDXML なんてものも出来るのかもしれない。SyMLSySS経験活かせそうだ。

=}
{希哲16年1月26日}{進捗記録}{表示させたい}{大分類}{最初から}{記法的}{強調度}{希哲16年1月26日の進捗時限}{希哲16年1月26日の進捗}{注意記法}...=}(42)

{希哲16年1月26日18歩 K#F85E/E74C-5EC9}

補足記法注意記法拡張性について検討して終了

この手の記法最初から役割細分化し過ぎると気軽に使いにく応用が効かず,記法的統一感もなくなりがちであるため,大分類として補足注意に分け,強調度任意ラベル指定出来るように設計している。

ただ,将来的に役割応じてアイコン表示させたいといった要求が出てくる可能性もあり,その拡張性確保しておきたい。

とりあえずアイコンを指定する記法考えておくことにした。それと例えば !! 注意 -- のように所定ラベルを同時に指定した時に注意書き用のアイコン表示する,といった拡張考えられる

=}
{気になる}{良い刺激}{狭める}{ネタバレ注意}{本質的に}{折り畳み記法}{一般に}{折り畳む}{開始行末}{NSFW}...=}(36)

{折り畳み記法について K#F85E/E74C-1188}

折り畳み記法は渡括記法と融合させた方がいい気がする

折り畳み記法渡括記法融合させるというのは新鮮発想で,良い刺激になりました。

ただ,折り畳み一般にソース上にあっても構わないが表示上は折り畳んでおきたい,という程度の要求で使われるものでもあるので,本質的に共通部分はあってもどちらかがどちらかに包摂されるものではないと考えています。それを融合するということは,応用範囲狭めることになります。従って,互いに独立した記法として上手く組み合わせられるようにする方向実装する方針です。

現時点では,^ブロック開始行末加えるという記法を考えています。例えば,以下のように渡括記法組み合わせられるようにする予定です。

+{知名がラベルとなり内容は折り畳まれる K#XXXX/XXXX}^

これは他の様々なデラング記法にも応用が効くので,例えばネタバレ注意NSFW 的にも使えそうだと思っています。

{近象(キンショウ)}{s_T}{std::string}{Re:「近象」と「遠象」について}{希哲15年8月13日のツイスト}{希哲15年8月13日}{文字列型}{良い例}{変種}{単純な}...=}(43)

{「近象」と「遠象」について K#F85E/E74C-B093}

近象」というのは,感覚的身近抽象性のことです。言い換えると,「より単純包括的なもの」,つまり「輪郭」的なもの,ということになります。その反対が「遠象」です。

抽象」は,本来何かのために思考単純化するものですが,必ずしも感覚的近さ意味しません。数学のそれが良い例です。

例えば,「近象文字列」というのは,簡単に言えば「文字列直感的に扱えるように抽象化したもの」です。この直感的というのも厳密には「思いついたように扱えること」という意味で,「直想的」と表現していました。

C++文字列std::string と書きますが,様々な変種もあり,「文字列を扱いたい」という書き手単純な要求に対して直想的ではありませんでした。書き手の頭の中で,「文字列を使うこと」と「std::string を使うこと」の間に距離があるということです。C++ ではライブラリによって異なる文字列型を使い分けることが多々あるので,std::string固有名詞的に文字列を扱う手段の一つとしか認識されていません。

では,s_T として「細かいことはさておき大体の場面で使える文字列型」を提供することにしました。「文字列を使うこと」と「s_T を使うこと」が概念として普通名詞的に)一致するように設計されています。これを「近象文字列」と呼んでいました。

{SNS}{進捗記録}{希哲14年}{領当て}{希哲15年3月26日の開発}{運営者専用}{義務付け}{プロフィールページ}{法的な問題}{管理責任}...=}(60)

{希哲15年3月26日7歩 K#F85E/E74C-0204}

自我輪郭について再検討して終了。

自我輪郭として扱えるようにするというはずっと以前からあり,昨年には「自我輪郭」と呼ぶようになっていたが,導入に向けて本格的な検討を始めることにした。

動機は主に3つ,利用者への連絡手段確保自我ページ整備,そして公開範囲設定機能実装だが,どれも最近になって重要性が増したことばかりだ。機が熟したということだろう。

まず,現状では利用者への連絡輪郭に対する返信という形でしか出来ない。SNS煩わしさを持ち込みたくないということから,これはこれで良い距離感なのではないかとも思っていた。

しかし,運営者として現実的に今後の運営を考えた時,明確連絡手段が無いことは管理責任の問題になりかねない。例えば法的な問題が起きた時などにこちらから通知相談することが難しくなる。メールアドレス等の登録義務付け運営者専用の通知機能を加えるなども考えられるが,自我輪郭が使えればずっと簡単に済むことが多いだろう。

もう一つ,最近よく考えていたことに自我ページ整備がある。現状では自我知番での検索結果を表示しているだけだが,これをいわゆるプロフィールページとして整備したい。設定画面から bio 等を設定出来るようにしてもいいが,折角輪郭という柔軟情報単位があるのにもったいない気がしていた。領当て吊るし輪郭応用出来れば一番簡単だ。

最後の決め手は,つい一昨日考え始めた公開範囲設定機能実装だった。特定利用者だけで共有出来る輪郭を作りたい時,特定の自我知番を追加していくだけならともかく,グループを管理したいという要求が必ず出てくる。ここで輪郭柔軟性を使わない手はない。

これらの問題を全てすっきり美しく解決する手段自我輪郭しかないだろう。

=}
{頭の切り替えコスト}{希哲14年12月28日のツイスト}{希哲14年12月28日}{Notion}{個人知識管理}{出与え}{ツイスト}{要求}{}{形式}=}(10)
{要求}

{}