{希哲15年5月の一日一文}{検索品質}{気に入った}{全てを知る}{名付けた}{検索手法}{デライトの成長戦略}{遅かった}{一日一文}{相性が良い}...=}(112)

{全知検索について K#F85E/A-E74C-4287}

個人知識管理(PKM)サービスを「知能増幅(IA)サービス」に発展させ,まずは Google に代表される検索演心エンジンと,Facebook に代表される SNS からいわゆる GAFAM切り崩す……これがデライトの成長戦略だ。

既存の SNS に対する「KNS(knowledge networking service)という概念については比較的よく語ってきたが,既存の検索演心に対する「全知検索(full-knowledge search)については十分に語ってこなかった。デライトを使い始めた人がまず戸惑う部分でもあるので,考え方だけ簡単説明しておきたい。

全知検索というのは,各輪郭に付けられる知名輪郭名対象とする検索のことだ。一般に「ページ名」などと呼ばれる部分を主な検索対象とするわけで,一見不便なようにも思えるだろう。

ただ,輪郭同士の関連付け柔軟性利用することで,慣れてしまえばさほど問題なく,面白い検索体験が出来るようになっている。検索語から繋がる情報手作りしているような感覚とでも言えばいいのか,これは開発者である私にとっても意外なことだった。


実は,デライト基礎になっているデルンという CMS実用化した当初,当たり前のように全文検索(full-text search)基本にしていた。しかし,使い込んでいるうちに,これはこれで問題があることに気付いた

デルンは,これまでに無い手軽さ大量情報を相互に結び付けられるように設計された。頭の中にある情報を,輪郭同士の立体的入れ子関係で表現する。その関係をひたすら作っていくことが使い方基本だ。

ある言葉について検索した時,その言葉について何を考え,それが何と結び付いているのか,これがまずデルンの検索で得たい情報になる。ところが,全文検索では余計な情報が引っかかり過ぎてしまう。少し言及しただけの輪郭も引っかかるので,それを一覧でざっと見てからその検索語について新しく描出投稿するかどうか考える必要がある。これは,デルンの使い方を考えると明らかに遅かった

そこで,いったん知名だけを対象にしてみた。すると,最初にイメージした検索語を打ち込んで,それが有るのか無いのか,瞬時分かるようになった。その知名を持つ輪郭に関連する輪郭を関連付けていく,というデルンにとって本質的作業と非常に相性が良いことにも気付いた。

これを用者ユーザー認知に基いた全く新しい検索手法として「全知検索」と名付けたわけだ。「全てを知る」と見せかけて,実は無知自覚させるという「無知の知」的な皮肉を感じさせるところも気に入った

全文検索は本文にある情報検索出来るが,逆に言うと,本文に無い情報は検索出来ない。

例えば,画像のようにそもそも文字情報を持たない献典コンテンツのようにあえて直接的表現を避けた文章,内容を書き換えたくないがこの検索語で引かっかって欲しいという古い文章……こういったものにも,全知検索であれば検索の道筋を作ることが出来る。

Google 検索ですら長年解決していない検索ノイズ問題にも有効手段となりうる。

これまでの検索というと,機械が抽出した情報から,人間が要らないものを指定していくという,いわば「ブラック リスト検索」だった。全知検索では,最初から人間が結び付けたい情報を指定しておく。いわば「ホワイト リスト検索」だ。


……全知検索の考え方は大体こんなものだ。

ただ,デライトでも全文検索実装しないと決めているわけではない。補助的にあれば便利なのは間違いないので,何らかの手段で全文検索も出来るようにはするつもりだが,あまり優先順位は高くない。

結局,慣れてしまうと全知検索でも十分引っかかりやすいように書くようになるし,現状,誰よりもデライトを使い込んでいる開発者があまり必要を感じていないのだ。

全文検索に無い利点がある上,全文検索と比べてはるかに低負荷で動き,慣れてしまえば全文検索が無くても困らない実用性がある。これはもう検索においてページランク級の一大発明と言っていいのではないかと思っている。

ウェブ検索という分野では,Google ですらページランク以上の革新を生み出せず,継ぎ接ぎ対策検索品質を保っているのが現状だ。

全知検索には,かつてページランクがそうしたように,ウェブ検索を原理からひっくり返す可能性がある。

{}{デルン}=}(2)
{希哲15年4月22日の日記}{投げ遣り}{翻訳語整備}{掲示板スクリプト}{過言ではない}{希哲館訳語の原点}{phpBB3 日本語パック}{間違いない}{デライトの RSS 対応}{一日一文}...=}(66)

{希哲館訳語の原点,サブスクと待っ読(まっとく) K#F85E/A-E74C-B90D}

先日,デライトでも RSS 対応をした。以下のように,任意の輪郭一覧RSS で「待っ読(まっとく)ことが出来る。

この「待っ読」,フィードにおける〈subscribe〉あるいは〈subscription〉翻訳語として昔考案したものだ。

今のようにデルンデライト)で何でもかんでも記録するようになる前だったので,正確な考案時期は忘れてしまったが,デルンが実用化した希哲6(2012)年より前だったことは間違いない。ただ,しばらくはの一つだったようで,希哲8(2014)年に改めて採用することを決めている〈subscribe〉を「待っ読」と訳す

今となっては希哲館訳語蓄積膨大なものとなったが,そのほとんどはデルン実用化後に出来たものだ。「待っ読」は独自性を持つ最古の希哲館訳語と言える。「希哲館訳語の原点」と言っても過言ではない


この「待っ読」,すでにお気付きかもしれないが「積ん読」にちなんだものだ。

そもそも〈subscribe〉翻訳語を考えるきっかけは,phpBB3 という掲示板スクリプト日本語パックを作りたいと思ったことだった。希哲館事業発足間もない希哲2(2008)年のことだ。

phpBB3 は,希哲館情報交換のために使える掲示板として当時は有力な選択肢だった。かねてより必要を感じていた翻訳語整備も兼ねていた。今はデライトがあるが,このデライトを実現するためにデルンの実用化を目指すことになり,この望事プロジェクト自体は立ち消えとなった。

その中にこの用語があったが,直訳の「購読」では明らかに不自然だった。散々考えた挙句,投げ遣り気味に「積ん読」と訳すことを考えたRSS フィード等の “Subscribe” は「積ん読 (つんどく)」か。これは流石に無理があったものの,しばらくして「待っ読」の元になったわけだ。


それから十数年経ち,〈subscription〉という概念は,サービスなどの定額制を意味する「サブスク」として広く認知されるようになった。

しかし,フィード等の〈subscribe〉をどう翻訳するか,という問題は当時から未解決のままだ。

デライトでは,利用者が出来るだけ自然に使えるように,希哲館訳語のほとんどをあえて採用していない。見慣れない翻訳語に気を取られて欲しくないので,多少のカタカナ語には目を瞑っている。

それにしても,「サブスクライブ」も「購読」も自然分かりやすいとは言えない。なら「待っ読」でいいんじゃないか,と採用することになった。

最も思い出深い翻訳語がここで復活してくれたことに,運命的なものを感じざるをえない。

=}
{理解され難い}{無理解者}{薄っぺらい}{誤解者}{毒される}{あしらい方}{振り回される}{思い込みの激しい人}{大切な人}{一日一文}...=}(62)

{理解者より大切な人 K#F85E/A-E74C-07E9}

経験上突然過剰なほど好意を示してくる人は,あるとき突然離れていく。要するに,思い込みの激しい人だ。こういう人が世の中には一定数いる,ということをり,あしらい方を身につけるには時間が要る。特に若い頃振り回されたりする。

希哲館事業は今や世界で最も風変わり事業と言っても過言ではない。こんなことをやって生きていると,人間の誤解について色々と学ぶことがある。


かくいう私も,もっと若い頃は「理解者」を求めていたように思う。自分のことを理解してくれる誰かがいる,という幻想は,よくもこれだけ社会共有されるようになったものだ。それに毒されていたのだろう。

ただ,ある時ふと気付いた。そもそも,希哲館事業なんて思い付いた自分自身ですら理解しているとは言えないものだ。言語にならない閃きがあって,それをどう表現したらいいのか模索し続け,デルンのような「知能増幅技術」を作り,ようやく頭の中が整理出来るようになってきた。そんなものを理解出来る他人がいるはずもない。

理解者なんじゃないかと思っていた人が,たまたま都合が良かっただけの「誤解者」に過ぎなかった,ということにも気付いた。彼らとの関係は,「理解した気になっている」間だけの条件付きの関係に過ぎなかった。


そして最も重要気付きは,理解者なんて薄っぺらいものよりも,尊い無理解者」に自分が助けられてきたということだった。これまで自分を理解してくれないと思っていた人達が,実は,理解出来なくても無条件愛情を注いでくれる人であり,温かく迎えてくれる人であり,助けてくれる人だった。自分は随分そういう人達に恵まれてきたと思う。だからこんな理解され難いことを延々と自由にやってこれた。「青い鳥」とはこういうことなのだろう。

実際の所,私の周辺に私の理解者なんて人間はいない。家族親戚友人……みんな無理解者だ。いつも私のやることには首をかしげている。首をかしげながら,仕方ないと言って,様々な形で助けてくれる人達だった。だから孤独というわけでもなく,生活に困るでもなかった。

これはデライト用者ユーザーもそうかもしれない。デライトを理解出来た上で使い始めた人はいないだろう。理解したつもりになった人はいつの間にか去っている。よく分からなくても,何かを感じるから使い続けてくれる人達が少数ながらいる。そういう意味では,彼らも私にとって「理解者より大切な人」だ。

デライトの成功に向けた挑戦佳境に入る中,そんな無理解者達の大恩報いたい,という思いを新たにしている。

=}
{希哲15年4月16日の開発}{再同期}{問題箇所}{不正知番}{希哲9年6月26日}{dg_sync_n_bg()}{dg_sync_n_fg()}{突き止め}{UPDATE 求頼}{正午前}...=}(74)

{希哲15年4月16日4歩 K#F85E/A-E74C-E7C9}

前後景輪数表示不具合修正

いったん終了。

この問題に気付いたのは今日正午前だが,昨日26時頃までは問題無かったため,この10時間ほどの間に発生したと思われる。

具体的には,_dg_oln自我知番が K#F85E の場合に限り n_fgn_bg がそれぞれ一つの数値統一されてしまっているという問題だった。この数値は _dg前景後景の自我知番を検索した時の数値に一致することを確認した。

このことから,誤った UPDATE 求頼で K#F85E の全ての輪郭更新をかけてしまった,ということは間違いない。その求頼がどのように発生したのか,ということまでは突き止め切れなかった。n_fg・n_bg を更新するのは dg_sync_n_fg()dg_sync_n_bg() くらいなので,直接的にはこれらの仕業だろう。


発見してすぐ全輪郭に対して dg_sync_n_fg()dg_sync_n_bg() をかけ,完了した13時30分頃には正常化したことを確認済み

最後に1輪だけ,修正されないまま残った輪郭があることに気付き調べてみると,知番 A- 以後が 0 の明らかに不正な輪郭だった。描出希哲9年6月26日知名は「イタリアの地方自治」だった。デルンもまだ不安定な時期だったので,こんな輪郭が紛れ込んでいてもおかしくはない。いずれにせよ存在してはいけない知番なので,当該輪郭は削除済み

一つの可能性として考えられるのは,この輪郭に誰かが握接し,不正知番dg_sync_n_fg()dg_sync_n_bg()誤作動を引き起こした,ということだ。最近,クローラー巡回激しいので,握接したのは誰であっても不思議ではない。

ただ,軽く試象してみた限り,問題箇所は見つからなかった。流石に,多少の不正知番WHERE 句致命的な狂い方をしないようにはしてある。

それほど深刻な問題ではないこと,概ね可能性が絞り込めたこと,復旧容易なことから,ここでいったん調査打ち切ることにした。今後はこの問題を頭の片隅に置いて周辺作業を進め,再現した時は再調査することにした。


元々前後景輪数表示に関しては多少狂うことがあるのを認識していたが,この復旧作業によってそれらもいったん正常化したようだ。

また,全輪郭再同期すると現状およそ1時間30分ほどかかることが分かったのも収穫だった。今後同様の対応が必要になった時の参考にする。

=}
{『阿部寛のホームページ』}{最悪の事態}{実装可能}{遅かった}{9年}{デライト高速化}{デライト高速化前の現状整理}{一日一文}{実装難度}{デライト史}...=}(95)

{デライトはなぜ速いのか K#F85E/A-E74C-1187}

いまデライトでは,「高速化」の作業最優先取り組んでいる。その理由デライトの現状については,昨日,「デライト高速化前の現状整理」にまとめた。そちらは個人的覚え書きだが,興味があれば覗いてみて欲しい。

今日は,デライトの「速さ」の歴史について簡単に振り返ってみたい。


「デライトはなぜ速いのか」というに,デライト用者ユーザーは少し違和感を覚えるかもしれない。個人知識管理(PKM)サービスとしてのデライトは,速いと言えるほど速くはない。せいぜい「」だ。ただ,並の速さで動いているのが奇跡的に「速い」と言えるほど,実装難度が高いのだ。普通に実装すれば,遅過ぎてまず実用にならないだろう。

サービスとしてのデライトは,「デルン」という全く独自CMS で動いている。Wikipedia に対してウィキがあるようなものだと思ってもらえばいい。このデルンの実用化成功したのは,希哲6(2012)年,もう9年ほど前のことだ。

実は,最初にデルンが動いた時,使っていた論組プログラミング言語PHP だった。そして,あまりにも遅かった。ある程度のが出来たあと,すぐに C++書き直した。

これが出来たのは,当然,準備していたからだ。元々,デルン開発にあたっては速度重視していた。それは体感出来る速さのためというより,「遅さで使いものにならない」事態を避けるためだった。ほとんど前例が無く,全てが未知数手探りという状況だったので,そもそもデルンのようなものが現実的に実装可能なのかどうかすら分からなかった。作ってみたがまともに動かない……これを最悪の事態想定していた。

そうなると,利用する技術は少しでも速い方が良かった。手探りの開発過程でいわゆる技術的負債蓄積していくことも想定していたため,それを補ってくれるだけの速さが必要だった。言語で言えば,今なら Rust あたりも選択肢に入ったかもしれないが,デルンを構想し始めた当時は C++ くらいしか無かった。

一方で,当時の私はウェブ開発経験に乏しく,デルンに何が必要なのか把握出来ていなかった。そこで,PHP を使って試作品プロトタイプを作ってみることにしたわけだ。

案の定,PHP で出来たデルンは実用的速度で動かず,すぐに準備していた C++ に切り替えた。この移行作業円滑に進み,やがて という独自言語に変貌していく。

今のデライトは,この Cμ に FastCGIマルチスレッドnginx 等々と徹底的に速度を重視した構成で動いている。PostgreSQL出場(DB)側も Cμ で外充て(ストアド)函数にしている。徹底して単純化された設計も手伝い,ほぼ極限まで高速化出来る可能性がある。

これまでのデライトにとって,「速さ」は遅さを補うためのものだった。そして今,この速さを武器にするために高速化作業を進めている。どうせやるなら,有名dev.to『阿部寛のホームページ』のように,速さを楽しんでもらえるくらいにしたいと思っている。是非楽しみにしていてほしい。

=}
{希哲15年4月の月記}{デライト高速化}{デライト高速化前の現状整理}{空振り}{悪い意味}{注目に値する}{大当たり}{サービス改善}{受け入れられる}{安上がり}...=}(81)

{希哲15年4月14日の日記 K#F85E/A-E74C-15D7}

今日は数歩程度の進捗時限を使いデライト高速化前の現状整理をしてから作業に入ろうと思っていたが,結局,現状整理丸一日かかった。

ここでの舵取り収益目標達成直結することは間違いないため,等閑には出来なかった。「デライト高速化前の現状整理」にモヤモヤしていたことを大体書き出してみれば,振り返る余裕も無かったここ2ヶ月ほどのまとめになっていた。これだけ複雑なことを考えていればモヤモヤもするはずだ。

時間をかけた甲斐あって,霧が晴れたように視界はっきりしてきた。迷いなく収益目標達成に邁進出来そうだ。これが丸一日で済んだと思えば安上がりだった。

当面,「黄金循環高速化」としてのデライト高速化中心臨機応変作業を進めていくことにした。理屈そこに書いた通りだが,簡単に言ってしまえば,この方針によってデライトの成功がずっと想像しやすくなった,ということだ。

新生デライト機能文書仕上げてから第三次宣伝攻勢に入り……というこれまでの目論見では,いくら完成度自信があっても,それが受け入れられる保証はどこにも無い。全くの空振りに終わる可能性も無くはない。そこに一抹の不安があった。

それに比べて,高速化はサービス改善施策として外れが無い。何らかの効果確実に見込め,努力が報われやすい。小理腑によって「速いデライト」の価値体感出来たことが決め手になった。

高速化そのものは大当たりを狙えるような付徴でもないが,デライトにはすでに輪郭法という最大の付徴がある。すでに注目に値するものをデライトは持っている。あとは,それをいかに良く見せるか,伝わりやすくするかだ。これが今回の整理で得た大きな気付きの一つだった。

もう一つの大きな気付きは,デライト高速化が黄金循環高速化でもある,ということだった。直感任せ悪い意味無軌道になりつつあると感じていたが,「快調期」に入る前によく考えていた黄金循環がここでになるとは思いもしなかった。これによって全てが繋がった感がある。

黄金循環の黄金週間現実のものにしたい。


デルンの実用化以後よく思うことだが,デルンデライトが無ければ今頃自分のはどうなっていたか分からないな,と今日は改めて思った。

私にとってのデライトは,もはや知能増幅装置というより生命維持装置に近いかもしれない。


これだけ書いた後で一日一文を書くのは流石に辛いので,今日は「デライト高速化前の現状整理」を一日一文代わりとしておいた。

{略語を使わない}{略さず}{共有しにくい}{一日一文}{略す}{略さない病}{JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法}{デライト一日一文}{人工言語}{kbd 要素}...=}(112)

{交度英語のすすめ K#F85E/A-E74C-244F}

希哲館における珍奇語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが,実は,もう一つそれに負けず劣らず珍奇な言語関連望事プロジェクトがある。それが「交度英語」(Code English),略して「交語」(Codish)だ。

これは主に希哲館情報技術体系利用しているもので,簡単に言えば,「英語勘報機コンピューター向けに簡略化した人工言語」だ。


勘報コンピューティング世界では,技術者であれば誰でも理解出来るような略語というものが多数存在する。例えば,std〈standard〉int〈integer〉str〈string〉……といった具合だ。多くは「歴史的経緯」で定着したものだ。

一方で,こうした略語使用を避けるという文化優勢になっている。その主な理由は,「共有しにくい」からだ。特に新しい論組プログラミング言語では,英語略さずに使う傾向があるため,妙に冗長交度コードが増えた。

はっきり言おう。私は,これが非常に馬鹿げた考え方,いわば「略さない病」であると思っている。この病気によって世界から失われた効率性金額換算すれば天文学的なものになるに違いない。

よく考えてもみてほしい。略語というのは,どんな専門分野でも記録情報交換効率化のために自然発生するものだ。数学の一見意味不明略語記法は,数学者本質的仕事専念するために編み出したものだろう。日夜神経を磨り減らして交度と向き合う情報技術者がそれを封じるのは,狂気の沙汰と言ってもいい。

実際のところ,「略語を使わないルール徹底されているかというと,そうではない。例えば,String str; なんて記述は世の中に溢れかえっている。C++ には shared_ptr(pointer)Java には println()(line)なんてものがある。「モダン」なはずの HTML5 にも img(image)やら kbd(keyboard)やら残っている。こうした混在が当たり前になっているのが現状だ。なぜなら,「略語を使わない」というのは本来不自然なこと,無理のあることだからだ。

長い方に合わせるのは無理なのだから,短い方に合わせればいい。共有しにくいなら,「略語を使わない」のではなく,「略語の辞書を作る」ことを考えればいい。頻繁に使うものなら人間は慣れる。これがつまり,交度英語考え方だ。

交度英語では,すでに定着している英略語を基礎に,実践を通じて新しい略語提案問題があれば修正しながら語彙を作り上げていく。

具体的には,論組をしながら,どうせばいいのか分からない英単語にあたった時,私はまず適当に略してみて,それをデライト検索する。他に前例があればそれと突き合わせて修正することもあるし,無ければどういう意図で使ったかを描き出していく。これを繰り返すことで,デライトが自然と辞書役割を果し,妥当略語の使い方に導いてくれるようになる。

これは基本的に希哲館訳語で行っていることと同じであり,デルンデライトがはじめて可能にしたことでもあるのだろう。

希哲館ではまだ素交ソースコード公開などはしていないので,交度英語を使った交度の実例としてすぐに見せられるものは少ないが,最近書いた「JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法」などにはその片鱗が見えるかもしれない。

いずれ『希哲辞典』のように辞典として整えて公開することも考えているが,まずは考え方を紹介しておきたかった。

{デルン}
{}