{HTML}{HTML5}{進捗記録}{AsciiDoc}{主述記法}{決め手に欠ける}{優先的に}{普及状況}{寄せておく}{重視すべき}...=}(75)

{希哲16年1月15日6歩 K#F85E/A-E74C-98C8}

進捗時限記録中略

<dl>対応する語釈記法仮称についての検討終了

まずは,AsciiDoc複数行ラベル記法取り入れることにした。


以前から 氏が使っていたことで AsciiDoc 風記法導入考えるようになったが,末尾::名称空間知符として多用していたため,語句:: 定義単一行ラベル記法導入するとおかしくなる輪郭がいくらかあるという問題があった。

ただ,最近この手の文字列交度記法利用統一すべきという考えまとまっているため,移行作業問題はあるものの仕様として導入することに問題はなくなった。そこで,すぐに取り入れても問題なさそう複数行ラベル記法から取り入れ,どう拡張するかは追い追い考えていくことにした。

記法名仮に語釈記法」とした。HTML5<dl>〈definition list〉から〈description list〉意味合い変わっているが,語句に対する説明という大まか意味には適っている

AsciiDocラベル記法はもっと汎用的使えるものらしいが,デライト重視すべき HTML では意味付け重要なので,とりあえず <dl>用途寄せておく


他に,Markdown Extra などで採用されている行頭 :記法検討した。記法として悪くはないが,普及状況いまいちで,優先的に採用するには決め手に欠ける

=}
{進捗記録}{パンくず記法}{脚注記法}{デラング記法}{希哲16年1月11日の開発}{1階層}{紛らわしくなる}{決めかけていた}{階層関係}{輪郭間}...=}(37)

{希哲16年1月11日10歩 K#F85E/A-E74C-0F92}

パンくず記法についての検討終了

もともと輪郭間階層関係明示するために考え始めたパンくず記法だったが,用者の描出から,必ずしも輪符こだわる必要はないことに気付いた汎用的に使えた方がわざわざデラング記法として導入する意義増す

また,^ a > b > c形式決めかけていたものの,^ a のように1階層しかない場合検討中脚注記法などと紛らわしくなる可能性があることに気付いた実験段階では ^^ a > b > c のようにしておくべきか。もう少し他の記法との調整必要になりそうだ。

{進捗記録}{希哲15年7月6日の開発}{希哲15年7月6日の進捗時限}{希哲15年7月6日の進捗}{希哲15年7月6日}{キラキラ星記法}{空白類}{《★》}{ブラックスター}{つのだ☆ひろ}...=}(48)

{希哲15年7月6日9歩 K#F85E/A-E74C-826E}

デラング整備キラキラ星記法仕様検討で終了。

思いつきで,黒星白星明るい色付きで表示する記法導入することにした。最初は五つ星評価のための「五つ星記法」として考えたが,お気に入りの意で使われる場合も少なくないため,汎用的にしておく。

ただし,『幽☆遊☆白書』『遊☆戯☆王』TOM★CATつのだ☆ひろなど,この記号を使った固有名詞が意外と多いため,「空白類以外の文字隣接しない」という条件必要だろう。デヴィッド・ボウイのアルバム《★》と書いてブラックスターと読ませるものもある。

は,gold では明るい背景で見にくく,goldenrod では暗過ぎるため,orange を使っておくことにした。

遊びに近い記法で「星記法」というのも味気ないので,「キラキラ星記法」と名付けた

{開発}{デラング}{開発記録}{希哲16年1月31日13歩}{デラング文書}{知番}{デライト文書}{書き進められる}{目立たせ方}{デラングとは?}...=}(78)

{希哲15年6月26日の開発 K#F85E/A-E74C-F080}

ここからデラング文書整備最優先にすることにした。

デラング文書の導入

デラングとは?」が大分良い感じまとまってきた。

軽量マークアップ言語に関する予備知識の無い入門者にもその意義を伝えつつ,デラング特徴表現する難しさがあった。

ここで「軽量マークアップ言語」という翻訳語の限界を感じ「簡易マークアップ言語」を使うことにした。

前日に思いついた時は,独自用語のようになるとかえって理解が難しくなるかもしれないと思ったが,英語版 Wikipedia では〈simple markup language〉〈lightweight markup language〉同義語として掲げられていることもあり,こちらの翻訳語として採用することにした。

閲覧専用模動多重輪括弧

寝る前になって閲覧専用模動についての考え急速まとまった

輪郭を,閲覧専用に余計な装飾機能無し輪郭であることを意識せずに読めるような形)表示出来るようにする。デライト文書のために考え始めたが,広く有用なものなりそうなので汎用的設計にしておく。

(「公式模動」や「正装模動」という名前も考えたが,翌日のまとめ時点で,平たく「閲覧専用模動」とした)

いまデラング文書を K#F85E の描出として書いているが,これをどう公式文書として見せるかという課題があった。

kind() の技法で描写埋め込むこと自体は簡単だが,輪符の扱いが面倒だった。

ここで,デルン最初期構想ってきた。もともと,デルンでは通常の輪括弧二重輪括弧輪符目立たせ方を変え,ズームするようにボタンで表示水準切り替えられるようにする,という機能の構想があった。アイコンには {} や {{}} といった記号を使うことを考えていた。

この考え方が閲覧専用模動にそのまま使えた。この時のために取っておいた二重輪括弧をようやく使える。閲覧専用模動では,通常の輪符無視し,強調輪符多重輪括弧のみを輪結にする。

最近,輪符輪括弧を表示させる記法として二重輪括弧を使おうかと考えていたが,全知検索では二重輪括弧を括弧付きで表示する。閲覧専用模動でも括弧付きで表示したい場合のために三重輪括弧も使えるようにし,これを「多重輪括弧」と呼ぶことにした。

さらに,輪結先も閲覧専用模動にしたい自我指定出来るようにしたり,特定知番を別 URL に変換出来るような仕組みがあれば,任意の自我で描いた輪郭を違和感なく公式文書にすることが出来る。

全知検索から閲覧専用模動への移行は,各輪郭中景部丸みのある部分に三角形アイコン輪結を置くのが分かりやすそうだ。

これで K#F85E で心配せずデライト文書を書き進められる

{一日一文}{HTML}{デラング}{希哲館訳語}{デライト}{希哲15年5月の一日一文}{ルビ対応}{大枠}{ルビ記法整備}{デルン初期実装}...=}(43)

{日本語におけるルビの重要性について K#F85E/A-E74C-5DDE}

ここのところ取り組んでいたデラングルビ記法整備がようやく一段落した見本

実はこのルビ記法デルン初期実装からあったもので,月庭でも一時期よく使っていた。デラングではその仕様大枠を受け継ぎ,細部洗練させた。

今のデライトには他にも多くの課題があるが,それでもこのルビ記法への思い入れは強く,後回しに出来なかった。

ルビ日本語柔軟性を与えてくれるものだ。実験的用語導入などにあたっては,これが使えるかどうかは大きな問題になる。私の場合は言うまでもなく,希哲館訳語使いやすくしたい,という動機が強かった。

現状,HTML でも汎用的標記マークアップ言語でも,ルビはあまり重要視されていない。一部日本語サービス通類ツールの“独自記法”としては散見されるものの,冗長過ぎたり簡潔だが紛らわしかったり,どれも一長一短あり,集約される気配は無い。

デライトデラングルビ対応は,個人知識管理一般で使えるように自然簡潔かつ明示的であることを重視した,割と革新的なものだと思う。

よりよい日本語探求のため,これからもルビ最大限活用していきたい。

{開発}{デライト}{知番}{あれ}{思想臭さ}{大金脈}{時間が解決する}{百聞は一見に如かず}{新しい技術}{デライトの使い道}...=}(134)

{ご意見ありがとうございます K#F85E/A-E74C-FF6E}

率直真摯ご意見,本当にありがとうございます。今のデライトでは読みにくい長文になりますが,折角思いを込めて書いて頂いたので,こちらも相応の気持ちを込めて書かせて頂きます。

いまデライトをよくご利用頂いているユーザーの方々も,皆さん例外なく,最初はもとあじさん同様「半信半疑」で,初期の投稿もどちらかというと苦言に近いものでした。様々な問題点について率直に指摘して頂いたことで改善出来たことも多々あります。今回ご意見を頂いたことも色々反省しながら考えをまとめる良い機会になっています。

何より,デライトは,普及どころか開発成功するかどうかも分からない,という無謀プロジェクトとして始まり18年以上になります。開発者を殺しでもしない限りは折れようがないので,ご意見・ご批判に遠慮必要は全くありません。から始まった物が人様に少しでも気にして頂けるようになったわけですから,全てありがたく受け止めています。

デライトの使い道についてですが,これは最近私自身よく考えているところです。

デライトは,もともと「具体的限定的に,とりあえずこういう風に使う」ことを提示するために開発が始まったサービスです。

デライト採用している CMSデルン(deln)といいます。これはデライトよりもっと汎用的といいますか,「工夫次第で何にでも使える情報管理ツール」でした。さあこれを売り込もうと考えた時,あまりにも漠然としていて掴み所がないという問題直面しました。そこで,まずは気軽に使えるメモサービスにしてみようと始まったのがライト版デルン,つまりデライト(Delite)の開発でした。

ただ,メモサービスにしただけではまだ利用イメージがわかないという方も多いだろうと思いました。かといって,枚挙に暇がない利用例を列挙してもかえって本質がぼやけてノイズになってしまいます。概要実例を見てピンと来ない人が,だらだら長ったらしい利用例のリストを見る気になるかというと疑問です。もし具体的な利用例を提示するのであれば,訴求力の高いものを厳選する必要があります。それも,理想を言えば一つです。

そこで目を付けたのが SNS(厳密にはマイクロブログ)と個人知識管理サービス結合した KNS というアイデアでした。「とりあえず使い始めてもらう」ことを考えるのであれば,マイクロブログ以上の入り口はないでしょう。Twitter中心宣伝しているのもここに理由があります。

ここまでしてもまだ使い道が分からない,という方が多くいらっしゃるのも事実です。文書実装改善余地も多々あると思いますが,根本的なことを言ってしまうと,新しい技術について言葉説明するのは本来難しいことでもあります。百聞は一見に如かず概要を読んで分からなければ実際に使っている所を見てもらう,それでも分からなければ,その人にとってまだ機が熟していない,ということなのかもしれません。

個人的経験から言えば,私は最初期の Twitter使い道がよく分かりませんでした。最近,Googleゴミのようなページがよく引っかかるな,というくらいの感想でした。少しずつ話題や様々な使い方を目にすることが増え,ある時突然,今やりたいことにあれが使えるんじゃないか?と気付いた瞬間がありました。当時そういう人は多かったと思いますし,新しい技術に人が触れ始める時というのは得てしてそんなものではないでしょうか。

ある程度は時間が解決する問題なのであれば,今のデライトは非常に良い状況にあると思います。これが,ご指摘の中にもある「黄金循環」です。

実は,最近のデライトには右肩上がりトラフィックが集まっています。アクティブユーザー描出量や検索流入が増えていることに加え,もとあじさんのように様子見で読むだけの方も増えているのだろうと思います。

ご覧の通り,デライトは Twitter のようなマイクロブログよりも微細情報を扱うことが出来ます。Twitter なら書き手にとっても読み手にとってもノイズにしかならない本当の思いつきを問題なく垂れ流せるように設計されているからです。それでいて,知番という識別子によるリンクは,ウィキキーワードリンクよりも強力でまず切れません。更に,アウトライナー的に既存の情報がまとめられていきます。全てリアルタイム公開状態で,大小無数のページ意味的な結び付きとまとまりをもって増殖し続ける仕組みです。

デライト上で完成しつつある情報蓄積発信集客・(広告収益開発理想的好循環,これを「黄金循環」と呼んでいます。これがこのまま加速し続ければ,知的活動に直接根差した知識産業大金脈です。手前味噌ながら,昨今の SNS世界的影響力も踏まえれば,その社会的文化的可能性は計り知れません。

加えて,デライトは極めて効率的開発運営体制構築成功しており,全く収益が無い状態でも開発者が生きている限り,あと50年くらいは潰れようがありません。

要するに,デライトが多くの人の目に触れるようになるのは時間の問題だろう,と私は考えています。そして,人々の中でデライトについて意識する時間が増えることは,デライトの使い道について気付く機会が増えることでもあるのだろうと思います。

こうしたことは,ご指摘の思想臭さ難解さを隠さなくなった理由でもあります。目先集客にとらわれず,長い目で見て,しっかりとデライト理解して頂くための活動注力出来るようになったわけです。

だいぶ長くなってしまったので,これについては新しい輪郭(以下)で書きます。

造語について
思想について

{HTML}{進捗記録}{`dg_fnd()`}{希哲14年8月12日の開発}{SQL::lim_T}{SQL::ofs_T}{ページ番号管理}{doc::pgr_T}{希哲14年8月12日の進捗時限}{希哲14年8月12日の進捗}...=}(29)

{希哲14年8月12日3歩 K#F85E/A-5B28-496F}

前後景一覧整備,装体書整理ページ付け自輪郭検索

途中で終了。

デルン初期からある doc::pgr_T とは別に,汎用的pgr_T を作ることにした。旧実装は経験不足ページ番号管理から HTML出力まで詰め込んでいるが,今回はページ番号管理特化する。

SQL::ofs_T にも SQL::lim_Tページ番号を受け取る構築子を加える。

また,これまで dg_fnd() が空の検索語を受け取ると無名輪郭検索していたため,全輪郭を取得する dg_oln_all() を設けていたが,これは多少煩雑なので dg_fnd() でも空文字列による全輪郭検索に対応し,一本化していくことにした。

=}
{汎用的}

{}