{希哲15年5月16日のツイスト}{希哲15年5月16日}{ダ行}{デライト}{ツイスト}{クエスト}{}{}{的確}{ドラゴン}...=}(14)
{一日一文}{希哲15年5月の一日一文}{抽象画}{パソコン音痴}{モノ}{大きな壁}{具象性}{悪い意味}{相性が良い}{立体階層構造}...=}(91)

{デライトはなぜ“抽象的”なのか K#F85E/A-E74C-AECA}

デライトに触れた多くの人が,デライトは“抽象的”だと言う。それもそのはず,我々認知しうる物事関連性徹底的抽象化することにより,あらゆる物事の関連性を一つの原理で捉えられるようにしたのがデライトの基礎にある「輪郭法」なのだから。

日常的会話の中で「抽象的」と言うと,捉え所が無いとか曖昧といった悪い意味に受け止められることが多い。しかし,抽象化という能力は,数学はもちろん,情報工学世界でも無くてはならないものだ。

工学における抽象性は,「汎用性」に近い意味を持っている。個別のものに共通する性質を取り出し,それらを一つの仕組みで捉えられるようにする。これが上手く出来ないと,論組プログラミングすら難しい

……などと御託を並べても,実際問題,デライトを多くの人に使ってもらうには,この抽象性が大きな壁であることに変わりはない。抽象的に物事を捉える能力には個人差が大きく,それも得意だという人の方が珍しい。当然ながら,これは市場戦略上の課題になる。

これを上手く解決する方法があるのか,実は開発者の中でも答えは出ていない。探せばあるのかもしれないし,結局無いのかもしれない。無いとしても,この抽象性がデライトにとって必要なものなら,無理にでも壁を乗り越えるしかない。


デライトは,これまで勘報機コンピューターでも多く利用されてきた単純な階層構造ネットワーク構造限界を越えるべく開発されたものだ。

特に「フォルダ」などとして広く使われている階層構造は,抽象性反対具体性具象性)と非常に相性が良い。いくら欠点があっても,人類が階層構造から離れられなかった大きな理由だ。

個人機(PC)の普及に大きく寄与したのが「デスクトップ メタファー」であったように,具体的モノ同士の関係として表現した方が多くの人は理解しやすい。その一方で,具体的なモノにはモノゆえの限界がある。

我々は,頭の中で多くの概念を縦横無尽に結び付けている。A にも B にも含まれている C という概念を頭の中では当たり前に扱えるが,フォルダのような物理的入れ物 A と B に同時に入っている C というファイル想像することは難しい。

こうした限界を越えようと様々な技術が開発されてきたが,フォルダのような“具体的”表現に頼っている限り,どうしても不自然で気持ちの悪いものになってしまう。「パソコン音痴」な人は,Windowsショートカットですら実体と区別出来ず混乱してしまうことがある。

それならいっそのこと,こうしたメタファーを廃してしまった方がいいのではないか。デライトの設計はそんな考えに基いている。だから,モノに喩えるのではなく,頭の中を直接表現した抽象画のようになっている。これをデスクトップならぬ「マインドトップ(mindtop,念頭と表現したこともある。

下図のように,デライトにおける「輪郭」は,視点によって一つの中身を共有出来る入れ物になっている。立体階層構造とでもいうべきこの構造を「輪郭構造」と呼ぶ。

この輪郭構造が,階層構造とネットワーク構造を{統合 K#F85E/A-3DCF}し,真に人間の{認知機能 K#F85E/A-E74C-CB77}に{調和 K#F85E/A-D4CF}するものになっている。大分長くなってしまったので,これについては後日改めて{解説 K#F85E/A-1EE6}しよう。

=}
{一日一文}{年月日}{文化的独立性}{気持ち悪さ}{時代感}{最重要視}{希哲前1年}{希哲8年}{希哲零年}{希哲館事業発足}...=}(77)

{希哲紀元とは何か K#F85E/A-E74C-DC33}

私はよく「希哲〜年」と書いている。例えば今年2021年なら希哲15年となる。これは「希哲紀元」という希哲館独自の紀年法だ。希哲館事業発足2007年希哲元年とし,そこから希哲2年希哲3年と数えていく。

この希哲紀元を私的に使い始めたのが希哲8(2014)年頃だから,もう7年ほど経つ。


希哲館訳語からも分かる通り,希哲館では日本語最重要視している。日本語の力を活かして知識産業革命を成し遂げ,日本語を世界中に広めたいと思っている。

ところがここで一つの問題があった。日本語で使える普遍的かつ合理的紀年法が無かったのだ。

我々日本人元号に慣れているし,愛着を持つ人も多いだろうが,元号はあくまでも天皇権威由来するものであり,外国人に押し付けられるものではない。紀年法としての分かりやすさ犠牲にする代わりに時代感共有しやすいなどと言われるが,それも国内の問題に過ぎない。

それでも日本人は元号を使うんだ,と言えるほど元号にこだわりがあるのかと言えば,実態はそうでもない。西暦も当たり前のように使われており,面倒だから西暦だけにしてくれという人もまた多い。ではその西暦に問題が無いのかと言えば,キリスト教価値観に基く紀年法が中立なわけはない。

キリスト教徒の少ない日本で,元号を捨てて西暦だけを使うようになった日本人というのも奇妙だろう。かといって,元号のみを使うのも皇紀を使うのも現実的ではない。併用している現状が良いのかと言うと,やはり面倒なことが多々ある。

残念ながら,日本語現状として,気持ち良く使える紀年法は無い。この気持ち悪さに自分なりに決着を付けたかった。希哲紀元を使い始めた動機はそんなところだ。


希哲紀元を初めて見た人はぎょっとするだろうが,実は,一つ一つの理屈単純明快だ。馬鹿正直過ぎるくらいかもしれない。

希哲紀元が希哲館事業発足の年を元年とするのは,希哲館にとってそれ以上に独立性を示せる出来事が無いからだ。宗教や特定の文化に依存することを極力避け,どこかに始点を置かなければならない以上,希哲館は希哲館の始まりを元年とするほかない。まあ,「苦節云年」を難しく言ったものだと思ってもらってもいい。

希哲紀元には,文化的独立性を保つという意義に加え,これまでの紀年法の欠点克服しようという試みもある。

希哲紀元は元号風だがあくまでも「紀元」なので,西暦と同じように改元は無い。ただ,「希哲」には元号同様,新時代への思いが込められている。それは今後数十年ではなく,半永久的に続く時代の名前だ。

さらに,希哲紀元には元年の前に「零年」がある。その前が「前1年」だ。つまり,歴史上の全ての年を整数として扱うことが出来,計算しやすい。これは西暦にない利点だ。


元号にも西暦にも使用義務は無く,あくまでも文化の一つとして任意で使うものだ。当然ながら,希哲紀元も私個人や希哲館の内部で使っているもので,無理に使わせたいということもない。これが本当に合理的なものなら,自然に広まっていくだろう。

ただ一つ,希哲紀元を使い始めてから年月日を書くのが楽しくてしょうがない。

=}
{デラング}{希哲15年3月30日の開発}{希哲15年3月30日の進捗時限}{希哲15年3月30日の進捗}{希哲15年3月30日}{見出し記法}{仕様検討}{装体}{検討}{進捗記録}...=}(22)

{希哲15年3月30日5歩 K#F85E/A-E74C-3AAE}

デラング見出し記法仕様検討

見出し記法に関しては,アスタリスクの数と見出し要素階層を合わせる単純な実装検討していたが,実際の階層の深さによって装体を変えることも検討に加えた。

つまり,第一階層を最大の見出しとして表示するのではなく,第二階層・第三階層と階層が深くなるにつれ上位階層の装体を大きくした方がいいかもしれない。階層と装体の関係が固定されていると,短い文章の中でちょっとした見出しが欲しい時に大袈裟になってしまう。更に,小さな装体のために上位階層を飛ばした見出しが作られると文書構造上の問題がある。

最初に現れた見出しを最上位階層の基準にすれば文書構造上の問題は解決出来るか。

装体を可変にするのは直感的ではないかもしれないために留めておく。特に,文書全体を見なければ階層の深さが分からないのは大きな欠点か。

=}
{ハイブリッド式}{遊画用語}{割り切り}{Markdown 研究}{Dex::buf_T}{buf_T}{デライトの AutoPagerize 対応}{希哲15年3月13日}{HTML 部区}{次ページ}...=}(79)

{希哲15年3月13日の開発 K#F85E/A-E74C-AE84}

デラング整備,特に Dex 実装作業没頭した。

28時までかけ,何度も書き直した Dex_T基本設計が一応の完成をみた。

模動応付を持てるバッファbuf_T)のスタックを中心に,模動切り替えながら処理振り分けていく。これにより部区入れ子も上手く扱うことが出来る。

最初はこのバッファを HTML 部区抽象化したものとして扱おうとしたが,杓子定規にすると非効率に,効率的に扱おうとすると不自然な部分が出てくるため,あくまで作業用バッファと割り切り柔軟に使えるようにした。

Dex::buf_T というのも語呂が良く,遊画用語っぽくて面白い


デラング研究一環として Markdown 研究も進み,Markdown利点欠点がよく見えてくるようになった。特に欠点の部分に関しては,最近 Markdown.pl をざっと読んでみて,技術的制約もあっただろうと推察する。

希哲前2年2004年)の Perl といえば,ちょっとしたサブルーチン呼び出しコストすら考えなければならない言語で,そこまで複雑なことは出来ない。

今の C++ 相当)に比べて,その遅さは軽く100倍を越えるだろう。

当時における見通しの良さ効率性バランスをとった結果が Markdown だったわけだ。


ある描出をきっかけに,デライトの AutoPagerize 対応を考え始めた(10歩)。

デライト上でも AutoPagerize検索してみるといくつか言及があった。

もともと無限スクロール導入は考えていたが,用合い広告SEO の様々な懸念から現状の全知検索ページャーになっている。

実際に試してみると,やはりこれはこれで便利で,検索演心でもあり SNS 的でもあるデライトにはハイブリッド式が向いていると確信した。

最近,次ページ輪結を押すとその場で追加されるという折衷案を考えていたが,これを体験すると中途半端霞む

独自の無限スクロール導入した場合,この種の拡張機能干渉しないように対策も考えておく必要がある。

{曝け出す}{ぼかす}{デライトの使い道}{描出公開戦略}{描出公開原則}{希哲15年1月25日}{希哲15年3月}{希哲15年2月}{希哲15年1月}{新デライト市場戦略}...=}(74)

{希哲15年1月25日の日記 K#F85E/A-E74C-5EE5}

描出公開原則再評価し,新デライト市場戦略一環,「描出公開戦略」として積極的に打ち出していくことにした。

もともと描出公開原則は止むをえず採用したようなものだったが,よくよく考えてみると,思っていたよりはるかに合理的だったことに気付く。知番によって秘密ぼかし記述がしやすいこと,知番譜類などとして外部利素管理出来ることが大きく貢献している。

例えば GAFA のような企業公開されたくない情報を預けるしかないサービスと,最初から公開されても構わないように書けるサービス,どちらが安全安心かといえば後者だ。不正握接流出はもちろん,内部の人間等に閲覧利用される懸念はどこまでも付きまとう。コストの問題を無視しても,デライト透明性圧倒的だ。コストの差まで考えれば大きな発明と言ってもいい。

これまで描出公開原則を過小評価していたのは,自分が用者としてあまりに特殊だったからだろう。膨大自由時間を持っていたこと,模体として全てを曝け出す覚悟が出来ていたこと,そして自分自身が開発者であり運営者であったこと……デライト文字通りの「なんでもメモ」として使えるのは自分くらいなのではないか,という不安が拭い切れず,先入観にもなっていた。

最近の試し文句ツイストにも表われているが,デライトの使い道はやはり人生の全てを鮮明に,知識として記録することにある,という思いを強くしていたところで,多くの人にとってになるであろう描出公開原則についても考えることが増えていた。これまで以上にしっかり分析してみて,知番が思いのほか上手く補完していることに気付いたわけだ。

描出公開原則は,用者にとっての欠点としてではなく,どのサービスよりも透明制危的利点として積極的かつ戦略的強調していくべきなのだろう。

昨年あれだけのことがあったので1月はどうしてもこんな考え事ばかりで開発が捗らなかったが,そろそろデライト収益化に向けた2月3月組計も練りたい。

{希哲14年10月10日の開発}{画像補完}{nil.png}{遅延読み込み}{2x}{ダミー画像}{二重読み込み}{data-src 属性}{noscript 要素}{希哲14年10月10日の進捗時限}...=}(49)

{希哲14年10月10日17歩 K#F85E/A-5B28-AF96}

デライト用合い改良

途中で終了。

.hl_b.x2_b を使った画像補完(今日から仮命名)について,微妙な欠陥発見試行錯誤していた。

src 属性を元に後から srcset 属性を追加するのは,いくら DOMContentLoaded でも間に合わず,二重読み込みが発生する。

src 属性省略しても事実上問題は無さそうだが,仕様上必須とされているため,どうも気持ち悪い。つまり,何らかの画像を読み込ませることは避けられない。

単純な img 要素noscript 要素で囲んでおき,スクリプト解除するという方法を思いつき,理論的には一番美しい気がしたが,レンダリング領当てが事前確保出来ないという致命的欠点があり断念。スクリプト側では noscript 要素の内容をテキストとしてしか取得出来ないのもすっきりしない。

スクリプト依存はいまさら仕方ないとして,ダミー画像を用意することにしたが,埋め込み画像保守性の観点から使いたくない。/img/nil.png あたりの名前を使うことにした。HTTP/2 も導入したことだし立求負担は軽い。

目的とする画像data-src 属性 に書いておくか,まだブラウザ解釈しやすい srcset 属性にするか少し悩んだ。2x だけを記述しておけば,場合によっては src 属性を無視してくれることも期待出来るが,記述がやや煩雑になる。遅延読み込みにも応用出来る data-src の方を使っておくことにした。

=}
{希哲14年9月22日の開発}{プルダウンメニュー}{希哲14年9月22日の進捗時限}{希哲14年9月22日の進捗}{希哲14年9月22日}{輪結}{検討}{補完候補}{固定表示}{全知検索窓}...=}(24)

{希哲14年9月22日8歩 K#F85E/A-5B28-0453}

デライト用合い改良

途中で終了。

全知検索窓固定表示調整して復活させることを検討し始める。画面高さをわずかに圧迫するくらいの欠点しかないが,広告との相性問題だった。

プルダウンメニューと被ってはいけないというのは明示されているが,補完候補が被ることまで流石に気にしないか。

この場合,検索への輪結は省ける。

=}
{希哲14年9月の月記}{デライト収益模体}{希哲14年9月5日}{デライトの宣伝}{筒路}{潜在意識}{『希哲日記』}{デライト収益化}{向かう所敵なし}{デライト開発}...=}(36)

{希哲14年9月5日の日記 K#F85E/A-5B28-ECD7}

今日の開発では,また一つ長い筒路を抜けて新しい展望が開けた感があった。

昨晩,珍しく絡みのを見た。荒唐無稽なものではなく,宝くじか何かで臨時収入のあった人からデライト開発資金調達が出来たという妙に生々しい夢だった。

滅多に見ない種類の夢だったことで細かく覚えているが,ちょうど今日デライト収益化に大きく接近したことを考えると,潜在意識変化があったのかもしれない。

希哲館事業は今,構想理論技術……その他諸々の条件をほぼ完璧に揃え,あとは収益化さえ実現出来れば向かう所敵なしという状況にある。その収益化も,少し前にはそれこそのような話だったが,デライト収益模体完成し,宣伝感触も良くと,限りなく現実に近付いている。

総合的到達点高さの中で,最後の欠点ともいえる収益性に対する意識は日毎強くなっているのだろう。

{知番付け検索}{希哲14年7月23日の開発}{希哲14年7月23日の進捗時限}{希哲14年7月23日の進捗}{希哲14年7月23日}{輪符}{選り手}{検討}{出場}{少考}...=}(32)

{希哲14年7月23日4歩 K#F85E/A-5B28-0F83}

18日の開発から検討している無番検索仕様について少考

旧全知検索ではいちいち出場更新してしまう欠点があったが,Web StoragePOST 道手選り手状態更新するだけなら問題ない。

残る問題は,輪符知番挿入するという機能をどう表現するのが直感的かということだが,これは知番の前に = 形のボタンでも付けておくのが良さそうだ。

こうなると置換箇所を分かりやすくするため contentEditable も早期に導入したいが,キリがない

今のところ,ボタンを押したら画面最上部に戻り,そこに書き換えたことが分かる何らかの表示をしておく,というのが無難か。

いったん終了。

{欠点}
{}