{理解され難い}{無理解者}{薄っぺらい}{誤解者}{毒される}{あしらい方}{振り回される}{思い込みの激しい人}{大切な人}{一日一文}...=}(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『阿部寛のホームページ』のように,速さを楽しんでもらえるくらいにしたいと思っている。是非楽しみにしていてほしい。

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

{交度英語のすすめ 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 に代わる要素位置記法」などにはその片鱗が見えるかもしれない。

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

{希哲15年4月12日の開発}{実出与え}{隠し管理}{握接頻度}{希哲15年3月中旬}{見通しの良い}{隠し実装}{散歩中}{希哲15年4月12日の進捗時限}{希哲15年4月12日の進捗}...=}(58)

{希哲15年4月12日10歩 K#F85E/A-E74C-C35E}

散歩中KNEST 隠し設計方針について進展があったため,軽くまとめ。

KNEST 隠し実装2月9日再開してからまた停滞していた。デルンデライト最適見通しの良い隠し実装について少し迷いがあった。

先月中旬頃だったか,自我情報の取得が削りやすいことに気付き,自我の隠し化から着手しようとは思っていた。比較的少数で全ての輪郭に関わり,出与え量は少なく更新頻度も低いため,最も隠しとして利用しやすい。

難しいのは輪郭ページ単位での隠し化で,とにかく膨大握接分散するため,自我と異なり工夫が必要になる。

少なくとも,握接頻度で隠し全体を一定の大きさに保っておかないと破綻するのは目に見えている。

ここで,握接のたびに浮上して,一定数を越えると沈んでいるものから破棄されていくようなリスト連想配列とは別に持っておくことを考えた。効率的理積み(特に重複の削除)は別に考える必要があるが,これなら隠し管理をだいぶ単純化出来る。

各隠しには隠し化した時点の時印を持たせておくことも考えていたが,これは応付にしておく。サービスの性質上,実出与え反映時間差を持たせたくない場面も多く,一律に持たせても無駄な出与えになる可能性が高い。

=}
{希哲15年4月12日のツイスト}{希哲15年4月12日}{公式サイト}{枯れた技術}{ツイスト}{アーカイブ}{採用}{GitHub}{FastCGI}{デルン}=}(10)
{希哲15年4月12日のツイスト}{希哲15年4月12日}{ClearSilver}{clearsilver.net}{デライト}{ツイスト}{困る}{デルン}=}(8)
{一日一文}{涙ぐむ}{途方もない}{呼吸を整える}{小休養}{ぶっきら棒}{希哲15年4月6日}{思い付いた}{凝り過ぎ}{興奮気味}...=}(67)

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

少し気持ち落ち着いてきたため,利楽しながら作業を進めた。それでも程度の進捗ぶりではあった。

短期集中生活とはいえ小休養必要は感じながらも,連日興奮気味でまともに睡眠も取れないということが続いていた。ここで少し呼吸を整えたい。


一日一文準備も進めた。

一日一文の歴史を遡っていて,久しぶりにブログ『道草録』思い出した希哲館事業最初期から WordPress運営していたブログで,ある面でデルン前身と言えなくもない。この「道草」という言葉は,希哲館事業途方もない大きさを前に全てが手探りだった当時心境をよく表している。色々な想い出が蘇えり,少し涙ぐんでしまった。

題名も気に入っていたので,希哲8年頃に私の随筆集として『道草録』再始動させようと考えたこともあったが,何となく立ち消えになっていた。一日一章を始めて間もない頃だったので,いずれ関連させようとは思っていたのだろう。

ここで,一日一文『道草録』素材にすることを思い付いた。これも一つの希哲館累新だ。

考えてみれば,月庭・デライト転送の開始以後,kitetu.com から窓口になるような献典が無くなっていた。ほぼ毎日書いている文章といえば『希哲日記』だが,これは当時の心境事実記録することに主眼を置いたもので,人に読ませることを意識したものではない。『希哲日記』に書き切れないことを書いておく所としても『道草録』という題名好ましい

読み手意識した文章として,メリハリを付けるためにも一日一文には敬体を使おうかと思ったが,気を使い過ぎて書きにくくなってしまう恐れがある。多少ぶっきら棒なくらいが良さそうなので,まずは常体で書き始めることにした。

続けるのが難しかった最大の理由は,書き始めるとついつい凝り過ぎてしまうということにあった。1時間以内で書こうと思っていても,結局数時間かけてしまうことが多かった。それが普通になると書き始めるのにも気力が必要になってしまう。

{よく頑張った}{一年余り}{希哲15年4月4日}{デライト小理腑}{『希哲日記』}{愛着}{デライト}{切なさ}{歩み}{感動}...=}(14)