{デライト}{デラング}{進捗記録}{Markdown}{大きな意義}{深まる一方}{ごく自然}{無視出来ない問題}{デライト記法}{独立した言語}...=}(45)

{希哲16年1月26日19歩 K#F85E/E74C-C0CD}

デライトデラング結合性についての検討終了

デライトデラングの「参考リファレンス実装」と位置付けることにした。

デラングデライトにとっては描写用軽標記言語だが,では,デラングにとってデライトとは何か,という問題があった。デラングを単なる「デライト記法」でなく独立した言語として扱うのであれば,これは無視出来ない問題となる。

具体的には,デラング文書書き方などに影響してくる。デライトの「使い方」の一部としてデラング文書参照するにとって,その説明デライトが出てくることはごく自然なことだが,独立した言語としてのデラングについて知りたい人にとってはそうではない。かといって,いちいち前置きしていたら読みにくいものになってしまう。

そこで,デラング文書の最初の方でデライトを「参考実装」と定義しておくことにした。どの道,デライトデラング間の関係については説明する必要がある。

Markdown筆頭軽標記言語注目されるようになったこともあり,デラング整備が進むにつれ「デラング」という根想への確信深まる一方だ。デライト市場戦略にとって大きな意義がある。ここで頭の整理をしておきたかった。

=}
{読む}{技術ブログ}{もったいぶる}{低質記事}{嫌いではない}{読み飛ばしやすい}{駄目な記事}{希哲15年8月3日のツイスト}{希哲15年8月3日}{マシ}...=}(17)
{デライト}{lightgray}{出振るい}{silver}{進捗記録}{WhiteSmoke}{gray}{下線記法}{引用部区}{希哲15年6月21日の開発}...=}(160)

{希哲15年6月21日9歩 K#F85E/E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

どちらの問題も,少し前までは自動的解決出来るのではないかと考えていた。例えば,前景輪にある輪符自動的強調表示したり,知名と異なる名前で参照された輪符斜体にするなどということを考えていた

ただ,これは描出経験を積むにつれ無理がある感じるようになった。

まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪限定するのも不自然見え方になるだろう。輪符参照名をいちいち照合するのも軽い処理ではない。

描写隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与え一貫性保守性深刻な影響を及ぼすことは目に見えている。

それ以前に,自動装体スタイリング適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中目立たせたい輪符引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても,例えば,「知る」という輪郭を「って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。

最近では,デラング整備進展もあり,これは手動装体,つまり何らかの記法対応すべきなのではないか,と考えるようになっていた。

今日の進展

こうした問題解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体伊体依存した装体は避けたかった。ここで,強調輪符下線調整することを考え始めた。

強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体軽い参照重い参照表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短いでは破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線破下線一本下線輪結の強さ表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い視線の流れを遮ることなく,視線を止めれば容易に輪結と視認出来る按配理想として,破下線を極力薄くすることにし,白背景なら lightgray引用部区など WhiteSmoke 背景の上では silver最適結論付けた

Firefox調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)

強調輪符一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的下線を引きたい場合のために下線記法導入することも考えているため,兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るいonly-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。

総括

開発記録に書いておく。

{〈宇田川 浩行「非言語思考と論理実装主義」(希哲館)〉}{デライト}{一日一文}{デライト開発}{論組}{希哲15年6月の一日一文}{論理共感覚}{高度非言語思考}{もじり}{不思議な能力}...=}(86)

{非言語思考と論理実装主義 K#F85E/E74C-A114}

昨日の一日一文で「高度非言語思考」という言葉久しぶりに使ったので,今日はこれについて少し書いてみよう。

人間にとって,言語思考切り分けることは難しい。ある程度高度な概念を扱う思考をする時,言語自然に伴なうものだ。

他方,言語が無ければ思考出来ないのかといえば,そうではないのも明らかだ。言語獲得以前の幼児にもにも思考能力はある。こうした,言語を必要としない程度の非言語思考を「原始非言語思考」と私は呼んでいる。

通常は言語によって為されているような高度な概念を扱う非言語思考,これがつまり「高度非言語思考」だ。


私は,デライト基礎理論である輪郭法と,それを中核とした希哲館事業構想17歳くが,この時に実践していたのが高度非言語思考だ。

なぜそんなことを始めたのかと言えば,言語の制約を越えたかったからだ。当時の私は,技術以上に哲学関心がある少年で,様々な思想の対立や現代思想停滞乗り越えるには,「言語思考」の速度遅過ぎると思っていた。

つまり,概念名前を付けたり,文章的に整理するのではなく,直感に従って,手で組み立てるように思考を組み立て,言語表現については概ね形が出来上がってから後付けすればいい,と考えた。その結果が「閃き」だったわけだ。

デライト使い方理解している人なら,この思考法がデライトにそのまま反映されていることに気付くだろう。この頃の私は,まさに「あれ」だけで思考していた。


私にはもともと,「論理共感覚」と呼ぶ不思議な能力があった。論理視覚触覚連動しているような共感覚(異種連動感覚だ。子供の頃から,論理というものを,目の前にあるモノを目で見て,手で触るように扱えた。つまり,頭で考えるというより,感じるように思考を組み立てることが出来た。

論理共感覚は,高度非言語思考可能にすると同時に,論組プログラミングと強く結び付くことになった。ごく直感的論組プログラムを組み立てることが出来たからだ。「論組」という翻訳語自体,プログラム本質論理にあるという感覚に基いて造ったものだ。

そして,論組による実装最良知の裏付けとする考え方を「論理実装主義論理実証主義もじりと呼ぶようになった。デライト開発はまさにその実践と言える。

私は,高度非言語思考,論理実装主義から極めて独特な思想体系構築することになるが,当然ながら一文で書き切れることではないので,折に触れて少しずつ書いていこうと思う。

{デライト}{一日一文}{デライト離立補完}{用者}{新生デライト}{デライト開発}{第三次宣伝攻勢}{快調期}{開発}{デラング}...=}(174)

{デライト高速化前の現状整理 K#F85E/E74C-A2D0}

希哲15年4月14日本格的デライト高速化に入る前の現状整理について,ここに記録しておく。

2月後半を預っていたこともあり開発集中しにくかったが,3月の頭からデライト開発はいわば「快調期」に入った。この想定外快調でそれ以前の計画良い意味狂うことが多くなり,3月8日からは計画にとらわれず直感に従って作業を進めていくことにしていた(日記)。

この快調によって,より高い完成度での新生デライトを目指すことが出来るようになり(第三次デライト市場戦略),3月20日収益目標達成努力期限5月1日延長28日にはこれを必達期限として,同時に短期集中生活に入った(日記)。短期集中生活は今月10日に終え,やり残した待っ読ボタン実装昨日一段落した。これが「デライトこれまでのあらすじ」といったところか。

少し落ち着いたところで,次の作業に入る前に現状整理することにした。収益目標達成期限まで残すところ半月,作業の優先順位見極める必要があった。短期間にこれだけのことがあると,流石に頭の中も混乱気味だ。もやもやしたものを晴らしておきたかった。

現在のデライト開発速さ予測不可能性を考えると,やはり中途半端な計画足枷にしかならない。「黄金循環高速化」としてのデライト高速化中心に,機能追加文書整備宣伝等々,全てを臨機応変巻き込みながら片付けていく,というのが現状での最適解結論付けた。

デライトにとって最大の付徴輪郭法であって,枝葉末節機能ではない。それを磨き上げ伝わりやすくする作業でもある。


作業項目としての「デライト高速化」を意識し始めたのは2月17日の開発からだった。当初は機能追加よりも優先し,文書整備並行させることを考えていた。その後,快調期に入ってから機能追加優先順位が上がり,特に Dex によるデラング整備優先するようになっていった。

今月頭の時点での大まかな見通しは,10日までに必要な機能追加20日までに新生デライト仕上げ,文書整備を終え,21日から第三次宣伝攻勢を開始,並行してデライト高速化を進める,というものだった(1日の日記)。

ところが,@icl() 周辺整備をきっかけに入った小理腑が,1〜2日という想定よりも長引き(6日間),上旬がほぼ潰れた。更に,これが思わぬ体感表示速度向上に繋がったことで,一気に高速化への持ち辺が高まった。この頃から,どちらかといえば後回しにするつもりだった高速化を最優先にすべきではないか,と考えるようになっていた。待っ読ボタン実装を終えた昨日の時点でほぼ腹が決まっており,最終確認のためにこの現状整理をしているわけだ。この判断収益目標達成成否直結するだろう。


デライト高速化の主な意義としては,用者体験の向上,SEO負荷軽減の3つを当初から見込んでいた。

小理腑後は,これに開発効率描出効率向上という意義が加わった。手定め時間短縮にもなるし,より描出を上げを増やすことにも繋がるだろう。頭では分かっていたことだが,速いデライト体験して実感が出てきた。この「先行体験」をさせてくれた小理腑の影響が大きい。

Dex 以後,デラング活用することにした文書整備にも寄与することになる。


高速化に並ぶ大きな作業分類であるデラングを含む機能整備機能追加),文書整備と比べても,やはり高速化が優位だろう。何より,高速化は技術面でも設計面でもデライト向きであり,この中で最も「伸ばせる」ところだ。本領発揮と言ってもいい。

機能追加が訴求するかどうかは当たり外れが大きい。開発者が求めているものと用者が求めているものは異なることが多いが,用者が求めているものと必要としているものも往々にして異なる。要望に応えても,思ったより必要なかったということもある。これは用者が馬鹿だからではない。開発者ですら,思ったより要らなかった,要らないと思っていたが意外と便利だった,ということは多々ある。人間そんなものだ。それでも,十分な時間があれば「数撃ちゃ当たる」で成功確率を高めることは出来るが,今はそうではない。

そもそも,現状デライト活動用者極端に少なく,動向分析する標本にもならない。まずは入り口の手前にいる人達を呼び込む必要がある。そのためには,一部の用者しか使わない高度な機能よりも第一印象重要であり,これに寄与するのは高速化だ。

また,機能追加には程度の差こそあれ通信処理上の負荷が伴なう。予定している機能を現状のデライトに全て詰め込めば明らかに重くなるのは目に見えている。


文書整備に関しては,ある程度機能整備が済んだところか,少なくとも機能整備と並行させなければ作業効率上の問題がある。これだけ仕様変更機能追加が激しい状況でなまじ文書を追随させても修正回数が増えるだけだ。先の理由で機能整備を後回しにするなら文書整備も後回しにするほかない。

現状,「使い方」などの文書は離立補完を最後にほとんど更新しておらず,実装との乖離が激しくなっているが,逆に言えば,無駄な修正作業が省けたということだ。新生デライトが熟れるまで放っておくのも一つの手だろう。

宣伝においても体験重視するようになる中で,相対的な重要性が低下していたということもある。「良い文書のある悪い体験」よりは「悪い文書しかない良い体験」の方がマシだ。


黄金循環」は,1月から再認識し,2月までよく言及していたが,3月からは快調期目まぐるしさ横に置いていた。

振り返ってみると,2月20日の日記高速化との結合予期するようなことを書いている。ただ,それほど強く両者の結合意識していたわけではなく,黄金循環高速化手段明確ではなかった。「全知検索の改良」と言っても,基本的な部分で問題の多かった希哲13年頃に比べ,今では範囲が広過ぎる。

快調期以後,計画ではなく直感に従うという戦法難局を上手く切り抜けてきたが,「次の作業」を意識するようになった短期集中生活終盤あたりから,作業になるものが欠けていると感じていた。

ここで高速化黄金循環結合してそのとして機能し始めるのだから,劇的な展開と言うほかない。ここまでの経験が全て一つに繋がったことになる。

{進捗記録}{知番}{輪符}{希哲15年2月14日の開発}{空輪郭}{希哲15年2月14日の進捗時限}{希哲15年2月14日の進捗}{希哲15年2月14日}{空欄削除}{打ち消し線}...=}(36)

{希哲15年2月14日2歩 K#F85E/E74C-979B}

輪郭削除に関しては空欄削除の方向で固まっているが,すでに出場側での対応は出来ており,細かい調整だけで実装可能な状況にあるため,作業方針を練る。

知番のみの輪郭にも利用価値はあるため,空欄削除はあくまでも用合い上の手続きとして,知名描写をもたない輪郭の存在は許容することにした。また,これを「空輪郭」と呼ぶことにした。

削除直後の表示についても概ね方針が出来た。

中景部輪郭線を細くし,輪符のみの形にし,知名には「削除済み」を表示して知番には打ち消し線,「削除済み」の右肩に疑問符を付けて使い方該当箇所への輪結にする。これで十分だろう。

=}
{使い方}

{}