{進捗記録}{文字装飾記法}{<small>}{置き換えられる}{補足部区}{注意部区}{一段階目}{希哲16年1月24日4歩}{強調度}{注意記法}...=}(73)

{希哲16年1月24日16歩 K#F85E/E74C-1FEF}

注意記法補足記法についての再検討終了

4歩を以下のように修正した。強調度に応じて三段階となる補足記法同様

!--
小さな注意書き
--

!!--
通常の注意書き
--

!!!--
重要な注意書き
--

装体は,23日2歩下敷きに,境界線背景色無しで font-size: 0.8em 程度にした小書きのものを加える。この場合,一段階目注意部区補足部区装体的に区別出来なくなるが,そもそも小さな注意書き補足違い曖昧なものなので自然といえば自然だ。


そもそも注意書き目立つように書かれるものばかりではない,というところに引っかかっていた

二段階三段階かは迷ったが,二段階にして後から追加出来なくなるよりは,三段階にして一段階目無用の長物になる後悔の方が小さい


当初,記号の数で「重要度」を表すことにしていたが,内容重要性装体目立たせ方は必ずしも一致しないので,「強調度」程度の意味合いにしておくべきかもしれない。


ダッシュ記法への応用考えた

例えばデラング文書では,目次項目末尾<small>----輪郭記法</small> などと書いているが,これを ?----輪郭記法置き換えられるかもしれない。

23日12歩書いた小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあった」とはこのことだったが,あくまでも文字装飾記法の一種である文字サイズ記法フォント記法<small> 相当の表現完全に代替は出来ない。

{開発}{開発記録}{新生デライトの要件}{輪郭小窓}{希哲15年7月25日2歩}{輪郭選り手}{希哲15年7月24日3歩}{無限スクロール機能}{希哲15年7月22日13歩}{付帯作業}...=}(29)

{希哲15年7月21日の開発 K#F85E/E74C-999C}

昨日輪郭小窓についてまとまったことをきっかけに,柔軟性のためにあえて曖昧にしていた新生デライトの要件急速固まった

付帯作業細かい調整は別として,大きな作業項目としては以下の通り。

仕様検討終えたものばかりなので,あとは実装作業のみ。


暗証語忘れ対策として,メールアドレス一時的認証手段としてのみ利用する機能盛り込むことも考えたが,これは制危上検討事項多いためいったん保留


自我削除機能については,いずれにせよ確認のため2段階程度の操作暗証語確認最終確認)にするつもりでいたので,いつでも復活出来る休眠削除段階にしてもいいかもしれない。このあたりも実装作業都合次第という部分があるため保留

=}
{進捗記録}{廃止}{希哲15年5月29日の開発}{KNEST::add()}{KNEST::add_xg()}{希哲15年5月29日の進捗時限}{希哲15年5月29日の進捗}{希哲15年5月29日}{旧デルン実装}{前後景輪}...=}(24)

{希哲15年5月29日16歩 K#F85E/E74C-64AB}

デラング整備Dex 改良記法実装整理

途中で終了。

KNEST 初期に作った KNEST::add()役割曖昧で,前後景輪の追加時に描写など無駄な要素を設定していたため,KNEST::add_xg() として役割を明確化した。

デバッグ邪魔も無くなり,多少負荷も減っただろう。

ついでに,旧デルン実装から引き継いで使っていない木霊用の変数をいったん廃止することにした。

=}
{進捗記録}{部区}{Dex 改良}{Dex 行処理仕様}{希哲15年5月19日の開発}{特殊文字列}{現在行}{部区個体}{デラングの不具合}{end()}...=}(64)

{希哲15年5月19日13歩 K#F85E/E74C-E14D}

デラング整備Dex 改良

途中で終了。

ここで Dex 実装Dex_Tにおける行処理仕様確定させておくことにした。

確定仕様

次行への移行は Dex::bl_T 個体Ctn() で自身を指す指示体を返すか,指示体を通して現在行変数に特殊文字列(現在は仮に"&amp;&amp;skip;"を設定した場合のみとし,それ以外は原則として現在行を維持する。

経緯

これまで,とにかく動くことを優先させて不明確な部分だったが,流石にそれで保守性維持するのは難しい規模になっていた。

10日の開発デラング不具合修正から Dex 設計見直し記法実装へと移行してきたが,これも仕様方向性を決めるためだった。一昨日の開発リスト記法実装途中で,ある程度こうあって欲しいという仕様が見えてきて,昨日の開発で入ったのが「Dex 改良」だ。

これまでのデラングの不具合で多かったのが部区切り替え失敗することだが,これも行処理の仕様が曖昧だったことが大きな原因としてある。

単純に入力を行毎に読み込み,それを部区個体スタックで処理していくという実装だったため,「現在行が勝手に進んでしまう」という問題があった。これへの対応を部区実装毎にやろうとすると複雑化してしまう。

意図

そこで,新しい部区や上位部区への移行時には現在行を維持し,同一部区での処理を継続する場合にのみ行を進めることにした。部区移行時にも明示的に次行に進める手段として,現在行を特殊文字列に置換する方法を使う。これは部分的に実装して好感触を得ていたため,部区毎ではなく共通処理化する。

bgn()Ctn(),Ctn() と end() の間でも現在行を維持することにした。後者は従来通りだが,前者では次行に進んでしまっていたため,混乱することがあった。これは少し悩んだが,bgn() と Ctn() は共通処理が多くなるため,この仕様の方が単純化する場面が多いだろうと判断した。

要するに,特定条件でなければ現在行が動かないようにすることで挙動把握しやすくする,というのが本仕様の意図だ。

課題

本仕様で概ね問題ないと思われるが,しいて言えば,各部区個体Ctn() 実装を厳密にしないと,容易に無限循環に陥いる。これまでのように行処理が勝手に進んで勝手に終わってくれないためだ。

ただ,無意味な循環を検知するような対策は難しくないので,大きな問題ではないだろう。

{デライト}{一日一文}{開発}{デライト市場戦略}{論組}{希哲15年5月の一日一文}{抽象画}{パソコン音痴}{モノ}{大きな壁}...=}(91)

{デライトはなぜ“抽象的”なのか K#F85E/E74C-AECA}

デライトに触れた多くの人が,デライトは“抽象的”だと言う。それもそのはず,我々認知しうる物事関連性徹底的抽象化することにより,あらゆる物事の関連性を一つの原理で捉えられるようにしたのがデライトの基礎にある「輪郭法」なのだから。

日常的会話の中で「抽象的」と言うと,捉え所が無いとか曖昧といった悪い意味に受け止められることが多い。しかし,抽象化という能力は,数学はもちろん,情報工学世界でも無くてはならないものだ。

工学における抽象性は,「汎用性」に近い意味を持っている。個別のものに共通する性質を取り出し,それらを一つの仕組みで捉えられるようにする。これが上手く出来ないと,論組プログラミングすら難しい

……などと御託を並べても,実際問題,デライトを多くの人に使ってもらうには,この抽象性が大きな壁であることに変わりはない。抽象的に物事を捉える能力には個人差が大きく,それも得意だという人の方が珍しい。当然ながら,これは市場戦略上の課題になる。

これを上手く解決する方法があるのか,実は開発者の中でも答えは出ていない。探せばあるのかもしれないし,結局無いのかもしれない。無いとしても,この抽象性がデライトにとって必要なものなら,無理にでも壁を乗り越えるしかない。


デライトは,これまで勘報機コンピューターでも多く利用されてきた単純な階層構造ネットワーク構造限界を越えるべく開発されたものだ。

特に「フォルダ」などとして広く使われている階層構造は,抽象性反対具体性具象性)と非常に相性が良い。いくら欠点があっても,人類が階層構造から離れられなかった大きな理由だ。

個人機(PC)の普及に大きく寄与したのが「デスクトップ メタファー」であったように,具体的モノ同士の関係として表現した方が多くの人は理解しやすい。その一方で,具体的なモノにはモノゆえの限界がある。

我々は,頭の中で多くの概念を縦横無尽に結び付けている。A にも B にも含まれている C という概念を頭の中では当たり前に扱えるが,フォルダのような物理的入れ物 A と B に同時に入っている C というファイル想像することは難しい。

こうした限界を越えようと様々な技術が開発されてきたが,フォルダのような“具体的”表現に頼っている限り,どうしても不自然で気持ちの悪いものになってしまう。「パソコン音痴」な人は,Windowsショートカットですら実体と区別出来ず混乱してしまうことがある。

それならいっそのこと,こうしたメタファーを廃してしまった方がいいのではないか。デライトの設計はそんな考えに基いている。だから,モノに喩えるのではなく,頭の中を直接表現した抽象画のようになっている。これをデスクトップならぬ「マインドトップ(mindtop,念頭と表現したこともある。

下図のように,デライトにおける「輪郭」は,視点によって一つの中身を共有出来る入れ物になっている。立体階層構造とでもいうべきこの構造を「輪郭構造」と呼ぶ。

この輪郭構造が,階層構造とネットワーク構造を{統合 K#F85E/A-3DCF}し,真に人間の{認知機能 K#F85E/A-E74C-CB77}に{調和 K#F85E/A-D4CF}するものになっている。大分長くなってしまったので,これについては後日改めて{解説 K#F85E/A-1EE6}しよう。
=}
{デライト}{進捗記録}{希哲14年9月24日の開発}{HTTP/2}{あれ}{推奨動作環境}{埋没時間}{希哲14年9月24日の進捗時限}{希哲14年9月24日の進捗}{希哲14年9月24日}...=}(56)

{希哲14年9月24日2歩 K#F85E/5B28-A037}

昨日,アイコンスプライト化3歩ほど試行してみて,やはり保守性問題を感じた。

ドメイン シャーディングにも言えることだが,最適化のために実装意図曖昧遠回しにする,というのは全体最適化観点から避けるべきことだ。開発者としてはどうしてもここにひっかかる。

そんな時,HTTP/2 のことを思い出した。RFC 7540 が出来た頃に情報収集した記憶があるが,流石にその時は時期尚早導入は考えにくかった。現状月庭も含めてデルンHTTP/1.1 で動いている。

改めて調べてみると,採用実績は十分にある。請い手側の普及率調査によって中途半端なところもあるが,時間解決する問題であること,そもそもデライト比較的新しいブラウザ事実上推奨動作環境としていることから問題ない。

kitetu.com の HTTPS 統一 はすでに実現しているため,手定め環境nginxngx_http_v2_module導入するだけで環境は整いそうだ。

スプライト化に費したのは,デライト・アイコン集制作の時に配置工夫したこと,昨日の3歩くらいで正味数時間だろう。埋没時間はほぼない。

早速 HTTP/2導入試験を始めることにした。

ちょうど11月から GooglebotHTTP/2 に対応するらしいので,今が好機なのだろう。

=}
{デライト}{『希哲日記』}{勝つ}{デライト宣伝}{希哲14年9月の月記}{希哲14年10月}{戦い方}{希哲14年9月16日6歩}{デライト用合い改良}{希哲14年9月16日}...=}(45)

{希哲14年9月16日の日記 K#F85E/5B28-A946}

ぼんやりしていたデライト最後の壁が,ひょんなことから明確になった。

18日から始める予定だった短期集中生活を今日から始め,デライト用合い改良全力を尽くすことにした。

デライト宣伝一時停止し,18日までに用合い改良を一段落させ,宣伝再開の手応え20日までには勝負結果が見えるだろう。上手くいけばその後は最適化注力して握接急増に備える。

頭の中を整理するのに多少時間がかかったが,まだ曖昧迷いがあった北極6丁目戦い方見極められたのは大収穫だった。

ぼんやりしたまま長引くことも想像していたが,勝つにせよ負けるにせよはっきりした結果が出そうだ。

ここで長期戦可能性は完全に捨て,最長でも10月一杯までの短期決戦に全てをかけることにした。現時点で辛うじて引き延ばせそうな期限であり,希哲館創立13周年米大統領選直前という,成功するにはこの上ない時期だ。

今月中に良い決着がつけばそれに越したことはないが,今から来月にずれ込むことは想定して調整を進める。

{曖昧}

{}