{デラング}{進捗記録}{希哲16年2月14日の開発}{損われる}{本質的ではない}{記述しやすい}{珍しくない}{大規模サイト}{迷惑行為対策}{運営上の都合}...=}(65)

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

越化エスケープ周りの客体表現化考えるついでに文字参照の越化について再検討して終了

HTML 越化仕様決めた昨年5月20日12歩以来越化目的使う可能性がある文字参照のみを許容していたが,これは修正し,いったん全ての文字参照許容することにした。

4日21歩でも再検討したが,越化記法同様デラングにおける特殊文字白表方式管理するのは無理がある損われる保守性に対して利点乏しい

当初制危というより迷惑行為対策など運営上の都合必要になるのではないかと思っていたが,Wikipedia はじめ大規模サイト開放されている珍しくなく,少なくともデライト言語仕様にするほど必要制限とは言えない。文字参照制危上致命的な問題があればそれは舞覧問題だろう。迷惑行為対策としてもあまり本質的ではない

何か問題があれば制限する,で十分なはずなので,実装都合制限してもいいことにする。

文字参照には,表示入力難がある文字記述しやすいという有用性一応ある。

=}
{HTML}{デラング}{進捗記録}{含まれる}{第三次デライト市場戦略}{第二次デライト市場戦略}{廃止}{越えて}{デライト市場戦略}{Markdown}...=}(187)

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

進捗時限記録中略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{進捗記録}{Markdown}{部区}{希哲16年1月18日の開発}{希哲16年1月18日12歩}{行内埋め込み}{行内埋め込み記法}{書き分けられる}{視覚的な}{導入予定}...=}(161)

{希哲16年1月18日8歩 K#F85E/A-E74C-91F1}

進捗時限記録中略

埋め込み記法渡括記法)の応付子オプションなどについての検討終了

概ね方針が固まってきた

引数風の応付子

これまで埋め込み記法には,埋め込み方細かく指定するような機能がなく,例えば画像埋め込みでも表示サイズ水平方向寄せ方指定出来なかった。この問題当然当初から認識していたが,どうしてもごちゃごちゃしがちな部分なので,直感的美しい記法練るのに時間がかかった差し当たり欲しいのは画像埋め込み表示サイズ寄せ方指定出来る機能だが,他の埋め込み対象でも使える汎用的な枠組み整えておきたい

そこで,[寄せ方指定スペース]+([応付])[埋め込み対象]形式採用することにした。例えば,添付譜類PNG 画像100x100埋め込みたい場合,+(100x100)png書けるようにする。

丸括弧内は,函数引数風にコンマ区切りで,埋め込み対象毎に使える応付子設定する。引数名指定出来るように a=xa:x受け取ってもいいが,柔軟性必要なのであえて必須にはしない。スペースを含む文字列扱いたい場合考えられなくはないのでとりあえずコンマ区切りにしておくが,各引数扱い駒手欄感覚近い

他のとして,+100x100 png+100x100,png のように全てを引数的に扱うことも考えたが,あくまでも埋め込み対象とする応付役割まとまり一番分かりやすいという点で丸括弧採用する。また,埋め込み対象URL など長い文字列になることも多いため,応付+直後置く。あるいは,末尾に置く書き分けられるようにする。

水平方向寄せ方

水平方向寄せ方は,表組み記法採用予定スペースを使う方法応用することにした。以下のように,+ 前のスペース無しは無指定4つ未満は左寄せ4つ以上で中央寄せ6つ以上で右寄せとする予定

+png            <!-- 無指定 -->
  +png          <!-- 左寄せ -->
    +png        <!-- 中央寄せ -->
      +png      <!-- 右寄せ -->

直感性でいえば矢印のような記号導入することも考えられる。となるとまず <>使うことになるが,すでに多用しているため無闇役割広げる記号意味稀薄化しかねない。そうでなければ leftcenterright のようなキーワード導入するくらいしかないだろう。いずれにせよ,見た目的にもあまり美しくない

当初,以下のようにスペースの数表組み記法合わせようとした2つ中央寄せ3つ右寄せが,いくつか問題がある。

+png         <!-- 無指定 -->
 +png        <!-- 左寄せ -->
  +png       <!-- 中央寄せ -->
   +png      <!-- 右寄せ -->

まず,表組みにおけるセル内での編集に比べそこまで編集効率問題にならないためここまで短くする必要もなく,比較的長くなる後続文字列に対して目立ちにく過ぎる単純にスペース2つ中央寄せ3つ右寄せ表現には見えない

さらに致命的な問題は,いくつかの他記法との整合性だ。導入予定字下げ記法では,行頭全角スペース使う。あまり好き記法ではないが,Markdown4つの半角スペースを使う交度記法互換性のため導入する可能性がある。これらの記法混ぜ書いた場合,視覚的な整合性が取れない。

そこで,行頭に使う寄せ方指定スペース表組み記法とすることにした。交度記法にも使われる4つの半角スペース右寄せ一致するよりは中央寄せに一致した方が違和感がずっと小さい

行内埋め込み記法

おまけに,行内埋め込み記法についても少し考えた

これまで埋め込み記法部区として扱うことを主に考えてきたが,やはり行内埋め込み必要だろう。まだ草案段階だが,例えば以下のようにして画像回り込む段落が作れると便利だ。

++png++ 左上の画像に回り込む段落。
=}
{出振るい}{進捗記録}{希哲10年}{30分}{デライト}{希哲15年10月1日の開発}{致命的な問題}{良い経験}{繰り返していた}{落とされる}...=}(81)

{希哲15年10月1日9歩 K#F85E/A-E74C-3682}

障害対応まとめ

最近安定していたデライトが今日に限って妙に壊衝しているなと思い,17時30分頃から本腰を入れ調査開始

ここのところ出振るいしていないため実装の問題とは考えにくく,出力録を見ても違了痕跡が無いため,deln_tmo.cron誤作動であることはすぐに見当が付いた出力録譜類を見ると,昨日30日ちょうど23時から譜類激増していたため,何らかの期限による問題であると気付いた

試しに wget実行してみると,SSL 証明書検証失敗していた。有効期限はまだ少し先だが,調べてみるLet's Encryptルート証明書に関する問題で,以前から警告されていたらしい。

18時前,いったん –no-check-certificate を付けて対処した。似たような問題将来的にも起こりうるので,根本的な改善策見つけたい

今後,「古い環境」に Let's Encrypt 自体が正式には対応しなくなるという話だが,その古さというのが希哲10(2016)以前とのこと。もともとデライト古い舞覧への対応手が回っていないため,実質的な非対応舞覧に近く,大きな影響は無いだろう。

今後,対応舞覧を広げる時に Let's Encrypt採用継続検討することにした。


どうも1分間隔落とされては0.1秒後に再起動するということを繰り返していたようだ。違了処理輪郭選り手抜控機能おかげもあり致命的な問題にはならなかった。

さらに本腰を入れ調査開始してから30分ほどの解決で,ついこのあいだのデバッグ環境整備効果実感することも出来,障害対応良い経験になった。

=}
{致命的な問題}

{}