{新生デライト}{知能増幅メモサービス}{一日一文}{希哲16年4月の一日一文}{森を見て木を見る}{向けた}{研究期間}{科学的な}{粘り続ける}{粘り続けた}...=}(326)

{第四次宣伝攻勢に向けて K#F85E/A-E74C-668D}

デライトは,黄金週間初日となる明日29日4度目の宣伝攻勢第四次宣伝攻勢始めるこれを機に中断していた一日一文」の日課再開することにした。

デライトはいま,包括的な改良構想によって「新生デライト」に生まれ変わろうとしている。今回の宣伝攻勢コンセプトは“新生デライト開発実況”だ。この一日一文含めて開発状況開発者考えなどについて積極的に発信していきたい。

森を見て木を見る

3度宣伝攻勢から得た教訓色々とあるが,4度目の宣伝攻勢目前にしてつくづく感じていることは,結局やってみなければ分からない,ということだ。

ソフトウェア開発やっていると,ここが悪い,あそこが分かりにくいなどといったことばかり考えてしまいがちだ。とりわけデライト新奇見える代物なので,開発者利用者も,“デライトの問題点”について考え込み過ぎる嫌いがある。

問題点地道に改善していくのは当たり前のことだが,問題点ばかり見ていると,「問題があることが問題」であるかのような錯覚に陥りがちだ。問題のないソフトウェアなど存在しないので,これは「木を見て森を見ず」でもある。広く使われている全てのソフトウェアは,それぞれに問題抱えながらそれぞれの役割を果たしている。その全体像見ず問題の大きさ正しく見ることは出来ない

そもそも使いやすい UI分かりやすい文書……などと全て兼ね備えた優等生的なソフトウェア世の中どれだけあるだろうか。使いにくかろうが分かりにくかろうが,バグだらけであろうが,“使う必要”があれば使われる。それが現実だ。ツール文書も,必要ならユーザー作り始める昔からそうやってソフトウェア共有されてきた。

そこに革新性があればなおのことだ。誰でも戸惑いなく使える革新的なソフトウェア──そんなものは夢の中にしか存在しないデライトがそうであれば,私はとっくに世界一の有名人にして世界一の大富豪になっている。冷静に考えれば馬鹿馬鹿しい話だが,知らず知らずのうちにそれに等しいことを考えてしまうのが認知バイアス怖さだ。

最大の課題

デライト普及させる上で最大の課題換言すれば,最も手っ取り早い道筋は何かといえば,デライト目指していること理解してもらい,共感してもらい,必要としてもらうことに他ならない。またこういう文章書き始めた理由だ。

デライトは,よくあるメモサービス出来るだけ近付けた知能増幅(IA)サービス名付けて知能増幅メモサービス」だ。一時期「最も使いやすいメモサービスを目指す最も使いやすい知能増幅サービス」表現していたこともあるが,研究室臭いものになりがちなこの種のソフトウェアとしてはすでに驚くほど簡易的で,その点の達成度決して低くないはずだ。

とはいえ,全く新しい領域目指している以上,新しいやり方理解して慣れてもらうしかない部分どう頑張っても残るデライト初心者戸惑いがちなところは,デライトの目的のためにあえてそうしていることが多い多くの人にとっての分かりやすさだけを基準にして最終的に出来るのは,微妙に使いにくいよくあるメモサービスだ。レーシングカー難しさだけを問題視してオモチャの車にするわけにはいかない。

2年ほど前に公開してから,デライトにはそれなりに多くの人来てくれた例に漏れず大半の人黙ってり,一部の人サービスの問題点指摘して去っていった。私が開発者として一番痛切に感じていたことは,そうした問題点大きく感じさせるほどの利用動機小ささだった。「ここが使いにくい」などと言い残して去っていった人達本当に言いたかったことは,「それでもと使うほどの意義見出せなかった」ということなのだと思う

事実デライト使いにくさ分かりにくさ改善して利用者が増えた試しがない。いま日常的に利用してくれているのは,あらゆる面でいまとは比べ物にならないほどデライト貧弱だった時期に,どこかで私がデライトについて語っているのを見て,その可能性興味を抱いてくれた人達だ。

デライトの意義理解したにとってデライトの問題決して大きくない開発者として,そう確信出来る地点ようやく来られた気がしている。あとは伝え方問題なのだろう。

結局は運

もう一つ,商売において陥いりがちに,「生存者バイアス」としてよく知られた認知バイアスがある。成功例背後にある屍の山に,気付きにくい。そして,成功失敗要因として語られることは,結果論でしかないことが多いデライト成功するもしないも,結局は「」によるところが大きい,ということだ。

例えば,売れっ子芸能人がみんな親しみやす万人受けするタイプかといえば,全くそんなことはない。癖が強く,とっつきにくそう多い。彼らは売れたから「それが良い」と言ってもらえるけれども,同じ特徴持っていても売れずに「だから駄目なんだ」と言われているごまんといる万人受けしそうなタイプならタイプで,売れなければ無個性つまらない」などと言われる。そのは,巡り合わせとしか言いようがない

勝てば官軍ではないが,デライトの“とっつきにくさ”とされていることも,何かのきっかけ話題になってしまえば“面白さ”になりうる。その程度のことでしかないのかもしれない。

結局は運」というのは投げ遣りなようでいて,実は非常に前向き覚悟必要な考え方でもある。粘り強く試行繰り返していくこと以上に成功確かなものにするはない,ということだからだ。奇跡のような偶然も,サイコロ振り直し続ければ必然近付いていく

そしてこのデライト自体,すでにソフトウェア開発における奇跡的な生存例だ。ソフトウェア開発世界では,デライトよりずっと低い目標掲げていても,成功どころか動く物すら出来ず頓挫していくプロジェクトごまんとある。その中にあって,これだけの大風呂敷を広げ,この品質実装運用され,少ないながらも利用者がいて,ちょっとした収益化まで出来ている。こんなサービス世界見渡しても他にない

そんな奇跡がなぜ起きているのか。それはやはり,「粘り続けたから」としか科学的な説明のしようがない。デライト自体は公開から2年越えたばかりのサービスだが,研究期間含める20年近い歴史がある。その全て無駄なくデライト結実している。

味方に付けデライトの成功という奇跡起こすために,ひたすら粘り続ける。これを新生デライトの完成向けた宣伝攻勢所信表明としたい。


=}(1){あれ}
{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}{出来ていなかった}{付加的}{避けられない}...=}(143)

{希哲16年3月12日14歩 K#F85E/A-E74C-2A34}

進捗時限記録中略

今後の Dex 設計方針についての検討終了これから越化参照大活躍しそうだ。


まず,課題だった脚注記法実装方針について検討している内に,越化参照部区間通信活用出来ることに気付いた

部区毎に越化条件変化などがあることから,各記法解釈部区個体任せたい。しかし,脚注記法のように最上位部区との出与え共有必要記法もある。

このような場合単純に考えれば指示体通して部区個体間で変数共有するということになるが,この種の記法増えるたびに目的別指示体増やすのは設計として美しくない汎用的な変数一つ集約するのも,効率性厳密性観点から難がある

ここでふと,越化参照使えることに気付いた下位部区個体中途解釈した記法には目印となる越化参照を付け,上位部区個体変換処理完了させる

これに似た部区間通信手法Dex 初期実装から現 &_skp;使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲広げなかった紆余曲折を経て,これが一番単純性効率性保守性バランスが良いということが分かった

これで脚注記法目次記法実装容易になった。他にも,輪郭情報参照必要記法など,部区間通信必要場面全般越化参照活用出来るだろう。


もう一つ,処理済み対象識別に関しても進展があった。

1月21日4歩で,&_tgt;&_fin; のような目印付加することを考えていたが,付加的越化参照では結局正規表現の複雑化避けられないため,実用化出来ていなかった

昨日終えた客体表現への書き換えDex 初期実装交度整理している時,再置換避けるため記法一部越化参照当時の疑似実体参照置換する手法使っていたことを思い出した。これもあまり積極的に応用範囲広げなかった手法だが,思っていたより合理的であることに気付いた

例えばhttp&_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なこと真価理解するには時間がかかるということを改めて学んだ経験不足だと,どうしてもより高度そうなことに目移りしてしまう。


面白いことに,どちらも原点回帰のような発見だった。

直感編み出した Dex 初期実装手法再評価する十分な経験出来たこともあるが,「越化参照」という概念完成し積極的な活用考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

=}
{色見本}{色見本記法}{デラング}{進捗記録}{書く}{Markdown}{あれ}{特殊形}{交度埋め込み}{難があった}...=}(96)

{希哲16年2月15日18歩 K#F85E/A-E74C-E831}

進捗時限記録中略

交度コード記法埋め込み記法組み合わせた交度埋め込み記法仮称方針まとめて終了

例えばMermaid埋め込みたい場合,以下のような書き方になる交度部区コードブロック記法は「逆括点バッククォート2つ以上」にする予定

+``mermaid
...
``

あるいは

+mermaid``
...
``

最近デラングMermaid 対応についてぼんやり考えていたが,場当たり的拡張はしたくないので,「外部言語による表現埋め込む汎用的な記法」がまず必要だと感じていた

GitHubMermaid 対応という話題目にしたことがきっかけで,これが急速に進展した。GitHub も含め,Markdown での Mermaid 対応は,いわゆるコードフェンスをそのまま使った記法採用例多い。これは私が嫌だった場当たり的拡張そのものだった。

コードフェンスは,「交度提示する記法であって,単に交度が書ける記法ではない。そうでなければ従来用法矛盾が生じるのは明らかなので,これは言語設計として悪手としか言いようがない

ただ,その愚かさ瀕答ヒントにもなった。つまり,深く考えなければ,多くの人にとって交度記法違和感なくこの種の記法応用出来る,「直感的な記法」であるということだ。

もう一つ,逆括点代わりに埋め込み記法拡張として以下のように書けたらどうか,と考えていたことも瀕答になった。

++mermaid
...
++

これは何かと整合性難があったが,役割として埋め込み記法一番近いとは感じていた。この二つを組み合わせればいい,と気付いて出来たのが今回の「交度埋め込み記法」だ。


言語名逆括点の前でも後でも大きな違和感はない。前に付けられるようにした方が,行内交度記法応用しても一貫性がある。

交度埋め込み先例として KaTeX による数式記法があるが,これは以下のような交度埋め込み記法特殊形とみなすことが出来る。

+katex``
...
``

行内でも使える: ++katex`...`++

さらに,これは色見本にも応用出来る可能性がある。サービス通類ツールによっては,行内交度記法色符号カラーコード書く自動的に色見本付加するものがある。

流石にそれはお節介過ぎるが,「色見本記法」があるといいとはずっと思っていた希哲15年3月31日1歩。例えば,++`#000000`++色見本が出来てもいいかもしれない。

{高い}{消え入る}{垢抜けない}{L字型}{Markdown の見出し記法}{二本線}{使っていた}{見出し装体素案}{見出し装体}{思い出した}...=}(31)

{見出しについて思い出したこと K#F85E/A-E74C-0235}

余談ですが,L字型見出しスタイルは昔希哲館のサイト使っていたことがあったのを,おかげで思い出しました

というより,L字型自体は CSS見出し的なものを装飾するのに,昔から(とりあえずこれでみたいな感じで)よく使われているパターンなので,自然に試したのだと思います。 さんのアイデア面白いのはそれを複数本にするというところだと思うのですが,最初の第1階層がデザインとして野暮ったい上につまらない(昔の CSS 解説サイトみたい)のが個人的には痛いです。この第1階層は実際に使ってみても想像以上にダサい代物であるということは黒歴史として後世に伝えていきたいです。

それが階層の表現であることに気付く前に,とりあえず折り曲げてみた感じに見えてしまうというか……。デザインにおけるダサさというのは,要は「削れるものをとりあえずくっつけている」感じなのです。「いるかそれ?」と思われたら負けで,それが垢抜けない印象になるわけです。その意味では,むしろ「(見本のように)並べてみないと良さが分からないデザイン」になっていると思います。

ちなみに,その案に一貫性があるとすれば下層に行くに従って左線の数が増えていくことになりますが,この方式は階層的に小さい見出しが不必要な目立ち方をする上に気持ち悪いことになるのは目に見えているな,と思ってにしたのが見出し装体素案です。


経験上,見出しはとにかく目立つ要素で,下手に凝ろうとするとデザイン的な事故になる可能性高いので,「引き算」が重要と感じています。

その帰結が,文字下線だけで階層を表現する,という現在のスタイルです。初見では目立たない単なる区切り線ですが,二本線が次第に消え入るような一貫した表現で,階層を判別する必要十分な機能を持たせています。おまけに,デライトでも導入予定の Markdown の見出し記法にも一致しています。自分でいうのも何ですが,これ以上の案を出す,というのは結構難しいデザインの課題だと思います。

ただ,デザインというのは感覚でするものでも好き嫌いでするものでもないので,納得出来ないことをどんどん投げつけてくれる さんとのこういう議論言語化のために非常に有意義だとも感じています。

{一番}

{}