{希哲16年3月12日}{希哲16年3月11日}{希哲16年2月}{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}...=}(143)

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

進捗時限記録中略

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


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

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

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

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

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

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


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

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

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

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


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

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

{希哲16年2月21日}{色見本}{色見本記法}{進捗記録}{略す}{希哲16年2月21日の開発}{希哲16年2月21日の進捗}{まとめたい}{同時指定}{表記し分ける}...=}(52)

{希哲16年2月21日13歩 K#F85E/E74C-37C1}

進捗時限記録中略

色見本記法と,タグ記法にも応用出来る広義の色記法」について少し進展があったのでまとめて終了

色記法に関しては,背景色前景色をどう表記し分けるかが課題だったが,色見本記法でどうせ %使うのであれば,同時指定[fg]%[bg] として,それぞれ [fg]%%[bg]書けるようにするのが良いかもしれない。

さらに,[fg]%[fg]してもいいことにし,CSS との整合性考え ;区切り文字として使えるようにすれば,%[bg];[fg] のようにも書ける色見本%[bg]%書けるとすれば,%[bg];[fg]%短縮形ともみなせる

この考え方なら,十分な柔軟性明示性持たせられそうだ。以下のような記法概ね整合的解釈出来る。

%black%    <!-- 小さな色見本を表示 -->
%%`black`  <!-- 指定内容の前に色見本を表示 -->
`black`%%  <!-- 指定内容の後に色見本を表示 -->

%%`black;white`%% <!-- 大きな色見本を交度付きで表示 -->

%%black;white
白文字に黒背景
%%

<{white%black}>白文字に黒背景</>
<{white;%black}>白文字に黒背景</>
<{%black;white}>白文字に黒背景</>
<{black}>黒文字</>
<{black%}>黒文字</>
<{%black}>黒背景</>

ただ,まだ確信には至っていない。もう少し煮詰める必要がある

色見本記法がどれだけ必要とされるかは分からないが,デライト装体調整有用なことは間違いないので出来るだけ早くまとめたい

=}
{希哲16年2月19日}{輪結}{デライト}{用者}{デラング}{進捗記録}{希哲16年2月19日の開発}{本来の意味}{自サービス}{止めておく}...=}(131)

{希哲16年2月19日11歩 K#F85E/E74C-D1B5}

進捗時限記録中略前後

何気なくマイクロブログサービス用者ユーザー示せる記法欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので,軽くまとめ終了

とりあえず分散型 SNS使われている記法拡張し,@[用者名]@[ドメイン名]汎用記法整備する方向進めることにした。


要は@user書いたTwitter輪結したり,@user@example.com書いた分散型マイクロブログ捌き手輪結してもいいのではないか,と考えたことがきっかけだった。

ここで一つ,@user@example.comhttps://example.com/@user必ず対応するのだろうかという疑問湧いた以前にもなんとなく考えたことはあったが,ActivityPub というか WebfingerURL引き出したり,面倒臭そう気がし進展しなかった。このあたりの仕様がどうなっているのか,いまだによく分からない

もっとも,ざっと見渡す限り分散型マイクロブログ捌き手は大体 https://example.com/@user になっているし,自分で Mastodon 捌き運営していた時も出放りはこれだったので,事実上の標準とみなしていいのかもしれない。


Twitter@user でいいかと思っていたが,いくら普及しているとはいえ,これは特定サービス寄り過ぎだろうということで,@user@twitter.com統一することを考えた。ただ,Twitterプロフィールページ正規 URLhttps://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ,若干気持ち悪い

さらに,この時点では @user@twitter.com と書けば @user表示されるという仕様考えていたため,いずれにせよ特定サービス向けの処理追加出来るようにする必要があった

ここまで考えたところで,いっそのこと @[用者名]@[ドメイン名] として,外部サービス用者指すための汎用的な記法にしてしまえばいいのではないか,と思えてきた。これは, 氏が独自に同様記法使っているのを見ていたことが大きかった

[ドメイン名] は,@[用者名]@twitter のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名解釈輪結先調整し,それ以外は https://[ドメイン名]/@[用者名]輪結する。


少し困ったのは,簡潔分かりやすい名前見つからないことだ。一応平たく外部サービス利用者記法」を仮称としておく。

異邦人記法」というのも面白いかもしれないと思ったが,一見して意味分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。


デライト使う予定が全くなかったため,@[用者名] という表示Twitter のために使うつもりだったが,これは止めておく

そもそも SNS などでは自サービス上の用者に対する言及メンションという意味を持つ記法から来ているデライト使わなかったとしても,この種の記法必要とするサービスにはデラング応用出来ないことになってしまう。

ここから @[用者名]本来の意味考え始め知番輪符などと組み合わせる可能性気付いた。これは「言及記法」として別途検討することにした。

{希哲16年1月29日}{デライト}{HTML}{デラング}{進捗記録}{含まれる}{第三次デライト市場戦略}{第二次デライト市場戦略}{廃止}{越えて}...=}(187)

{希哲16年1月29日9歩 K#F85E/E74C-CC5B}

進捗時限記録中略

デライト市場戦略についての検討終了

デラングによる「対 Markdown 戦略」を市場戦略一環として加えることにした。昨日こんなツイスト書いてみて,デラングデライト市場戦略の中で大きな役割担えることを確信した

デライト市場戦略これまで

デライト市場戦略は,まず対 Roam Research 戦略中核としたところから始まり第二次市場戦略以後は対 Notion 戦略一環位置付けていた。要は,旧来個人知識管理通類限界越えようとするこれらのサービス流行利用して,最も根源的に個人知識管理革新目指すデライト売り込む,という目論見だった。

しかし,英語圏での事情多少異なるようだが,少なくとも日本ではどちらもそこまで大きなうねりにはなっていない。一番勢いのある Notion ですら,まだ「一部界隈の流行」の域を出ていない個人知識管理サービス市場も,全体としてそこまで拡大しているようには見えない

結局のところ,デライト必要になるというのは「既存の個人知識管理通類限界を感じている人」なわけで,その広がってくれることがデライトにとって一番の追い風だ。その当てが外れた格好になっていた。

個人知識管理サービス市場への苛立ち

第二次市場戦略以後は,こうした外部環境への依存から脱却しているので致命的な問題にはならなかったものの,個人知識管理サービス市場の拡大遅さに対する苛立ちというのは常にあった。

個人知識管理サービス」という枠組みこだわるべきではないのかもしれない,とも考えた

極端な話デライトを「ゲーム」として売り込むのはどうかと考えたことすらある。「マインドクラフト」という言葉造ったこともあるが,テキストによる箱庭ゲームと言えなくもないし,ゲームなら独自用語の多さも独特な世界観演出になる。

そこまで行かなくとも,KNS なのだから SNS 方面に売り込むかなどとも考えたが,結局,根想からこれまで練り上げてきたものを考えると,そう簡単な話ではない。中途半端あれこれやればますますややこしいものになってしまう。

個人知識管理サービス市場狭さ越えて

最近デラング整備急速な進展により,他の軽標記言語との比較研究も進む中で,Markdown想像以上に様々な分野浸透していることに気付いた

個人知識管理サービスでいえば,EvernoteNotionRoam Research と,これまでデライト意識することの多かったサービスはほぼ Markdown 対応であり,別種のサービス選り手などへの広がり非常に大きい。つまり,比較対象として,より幅広い関心集められる

これこそ,常々感じていた個人知識管理サービス市場狭さ」を越えていく道筋ではないかと思うようになった。

市場戦略としてのデラング

デラングはもともと「DIL」と呼んでいたデルン最初期から独立した言語だった。というのも,デルン初期実装では今でいう描写に使う言語選択式であり,プルダウンメニューから txtHTML などとともに DIL選択出来る,という設計だった。

ただ,長い描出経験の中でほぼ必要なかったので,単純化志向するデライト中心移行する過程でこの選択方式廃止となった。

この時点で,デラングにも岐路があった。単なる「デライト記法」の内部名称となるか,軽標記言語としてあえて主張するかだ。後者を取ったのは,「デラング」を正式名称として採用することにした昨年3月3日4歩のことだった。

デライト記法」,あるいは当時考えていた描写記法」とすると閉鎖的恣意的なものという印象を与えてしまうが,「デラング」という言語とすることで外向き体系的印象を与える。もちろん,当時から Markdown意識してはいたが,そこまで大きな位置付けではなかった。やはり,デラング整備進展とともに認識深まった感がある

それこそ,デラングMarkdown のように注目を集めるようになったら,デライト多大な利益がもたらされることは考えるまでもない知能増幅サービスとしてのデライト自体よりも,軽標記言語としてのデラングの方がはるかにその役割理解しやすいことを考えれば,そこまで非現実的でもないし,その技術手応え十二分にある。

まだデラング中心の「第四次デライト市場戦略」にすべきというほどの確信があるわけではなく,デラング整備新生デライト開発含まれるので,第三次デライト市場戦略有力武器加わったというところか。

{希哲16年1月23日}{用者}{進捗記録}{認識しやすい}{兼ねている}{おまけに}{多々ある}{二段階方式}{下見ボタン}{確認ボタン}...=}(90)

{希哲16年1月23日1歩 K#F85E/E74C-27DA}

換配確認機能」についての再検討終了。なお,この検討から「下見プレビュー機能」に改称した。

下見機能は,輪郭選り手左下下見ボタンを置く形でほぼ確定か。


デラング整備進展とともに重要性増している下見機能だが,用合いをどうするかについてはまだ少し迷いがあった。

一応最有力案は,輪郭選り手左下に「確認ボタン」を置くというものだった。左上公開設定機能右上取り消しボタン使いたいので,左下置くのが自然ではある。

完了ボタン並べるという捨て切れなかったが,押し間違い多発しそうで用合いとしては難がある

今朝ふと,確認ボタンから描き出し完了ボタンへの二段階方式浮上してきた。つまり,必ず換配確認をしてから描き出し描き直しを行うことになる。

二段階方式利点には用合い単純化初心者にとっての流れ分かりやすさおまけに捌き手負荷軽減見込めるが,使い慣れた用者にとっては煩雑になり過ぎる懸念があり,採用見送った

ある程度複雑なデラング記法使う場合など換配確認をしたいこともなくはないが,確認するまでもない描き直し多々ある。また,公開設定機能導入によって気軽に描き出し描き直しが出来るようになると,役割重複してしまう。

一つ,輪郭削除確認機能を兼ねられるかとも思ったが,そもそも知名描写にして削除というのが確認作業兼ねているためこれもやはり煩わしい

やはり,換配確認選択的機能にしておくべきだろう。

これまで,完了ボタンに近い位置に置くことも考えていたため,描出流れの中で分かりやすいように「確認ボタン」「換配確認機能」などと「確認」をプレビュー日本語表現として採用していたが,ある程度独立した機能として認識しやすいように今後は「下見」とすることにした。

{進展}

{}