{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{希哲17年1月15日}{放置しておく}{結論を出す}{占有される}{複数タブ}{使いものにならない}{デライト向きではない}{分かりにくくなっている}...=}(116)

{希哲17年1月15日10歩 K#F85E/E74C-36C0}

進捗時限記録中略

ついでに新規描出フォーム固定機能についても検討して終了

こちらは「限りなく廃案近い保留」となった。


全知検索窓固定機能同様デライト最初期実装削除したものだが,これは広告との相性以前に,用合いとしていまいちだったということが大きい

新規描出フォーム固定出来れば,輪郭一覧眺めながら描写書くことも出来便利違いない,と素朴な期待から実装してみたが,これが帯に短し襷に長しという感じ思いのほか使えなかった

大きな原因は,ページ遷移までのちょっとした固定されるだけ,という中途半端さにあった。あちこち飛びながら作業しているといちいち解除されるので,自然に使わなくなっていく

これに対処しようとすると画面分割機能近い大掛かり仕掛け必要になる画面分割機能何度も検討したが,やはりデライトには過剰判断して,複数窓使いやすくする方向単純性保ってきた今考えてもこれは英断だった。

自動ページ展開輪郭一覧動的更新がある今なら当時よりは使いようがあるかもしれないが,その分,ページ遷移条件分かりにくくなっているので,かえってストレスかもしれない。

複数窓使いにくいスマートフォンなどでも,新規描出フォーム柔品キーボード画面ほとんど占有されるため恐らく使いものにならない当時諸場使える状態ではなかったので想像ではあるが,複数タブ使う方がマシだろう。

結局構造的にデライト向きではないのだろうと思うが,急いで結論を出す必要もない。そのうち適当な活用法見つかればいいし,見つからなくても問題ない。というわけで,しばらく放置しておくことにした。

迷い一つ消えたのは収穫言える

{希哲16年7月21日}{希哲16年6月}{開始する}{輪郭小窓実装}{最大の暗部}{手動開始}{無期限保留}{相性問題}{用者体験の向上}{払って}...=}(146)

{希哲16年7月21日の開発 K#F85E/E74C-7F30}

無番輪符改良完了した。これでデルン長年の課題だった輪郭間輪結における知番依存解消した作業中輪符補完機能についての閃きがあり,脳爆発始まった


輪郭選り手上での輪符補完機能は,省割キーあるいはカーソルのある輪括弧表示されるボタン押すことで開始することにした。省割キー仮に Ctrl + {想定しておく。

また,これを機にタッチ端末向け記号入力ボタン本格的に検討することにした。軽量標記言語中心とした用合い課題として記号入力煩雑さがあったため,その解決策兼ねる

ここでようやく輪符補完機能実装イメージまとまった最近のデライト開発では最大の暗部になっていた部分で,極めて大きな収穫言える


漠然と輪郭小窓実装含めていた輪符補完機能だが,ここだけ実装イメージまとまらなかった一時後回しにすることを考えていた理由だった。

原因は,輪符補完自動開始前提としていたことだった。自動開始となると入力中デラング正確に解釈する必要があるが,デラング複雑性考えると交度の肥大化避けられそうになかった深刻な保守性の低下請い手低速化懸念される

更に問題なのは,そこまでの実装コスト払っても,用者体験の向上繋がるとは限らないということだった。この手の挙動好き嫌いがかなり分かれる上に環境との相性問題大きい多くの人満足する水準にしようと思えばキリがない

読み込み中...
{希哲16年6月16日}{}{第二次知番改良}{希哲16年6月16日の開発}{希哲16年6月16日の進捗}{優先すべき}{柔軟に}{有効な場面}{控えている}{ページ内容}...=}(80)

{希哲16年6月16日5歩 K#F85E/E74C-2C3A}

進捗時限記録中略

KNEST 隠しについての実装作業方針検討終了

第二次知番改良での交度出場整理経てKNEST 隠し実装イメージ急速にまとまってきた

まず,輪数隠しについては「輪数取得改良」として出場設計見直し含めた包括的な実装方針出来ている

課題だった共通の出与え構造については,任意隠し出与え更新時印持たせた map_ と,更新時印として本体set_持たせた map_基礎とすることを決めた。これで古い隠しから削除していくような処理簡単に実装出来る

探索効率保存効率単純性柔軟性兼ね備えた実装なかなか見つからなかったが,これで解決した昨年4月12日10歩から,「浮上式隠し」として独自の出与え構造考えていたものの,それも課題多く再考せざるをえなくなっていた。

昨年9月から最優先実装することを考えていた HTML 隠しについてはいったん後回しにすることにした。公開設定機能など,自我によってページ内容大きく変わる機能実装間近控えているテンプレート保存するにしても,有効な場面限られる柔軟に利用出来る輪数隠し自我隠し輪郭隠し優先すべきだろう。

{知番}{知名}{希哲16年5月17日}{輪結}{一日一文}{希哲16年5月17日の開発}{希哲16年5月17日の進捗}{新しい目印}{変わらなくなった}{目立たなくなる}...=}(89)

{希哲16年5月17日14歩 K#F85E/E74C-776A}

中景輪符改良

輪郭ページ知名選り手以外の知番輪結最大化アイコン追加していったん終了小さい変化だが効果は大きいだろう。

中景輪符知名輪結知番輪結役割動かしようがない旧デルン実装では,知名輪結輪郭ページび,再検索用に ?輪結置いていたが,再検索多用するので直感的な方がいい。輪符における知名知番役割から考えても単純性保ちつつ整合性を取るとこの形になってしまう。問題点として,初心者にはそれぞれの役割分かりにくかった

他方高さ固定解除する方法分かりにくいという問題もあった。最近最大化アイコン使った輪結をどこかに置くことを考えていたが,知番輪結同じ機能を別の輪結持たせる混乱を招く結局知番輪結固定輪結であり特定の輪郭注目する機能兼ねている,ということを自然に学べる用合い望ましい。ということで知番輪結一部であることが分かるようにした。

これによって,知番輪結機能分かりやすくなり,知名輪結との機能の違い発見しやすくなるだろう。

最近の一日一文で,読者高さ固定解除する方法気付きにくいという問題尚更気になっていた動的に解除する手段考えているが,これはこれで先々でも使えるだろう。

第零番節の省略自我知番の省略可能になることで知番目立たなくなるが,これで丁度良い感じになりそうだ。3月31日の開発輪郭ページ前後景検索ページ外観変わらなくなったため,新しい目印としても丁度良い

=}
{デライトの背景にある思想}{デライト(なんでもメモ)}{}{デライト}{希哲16年5月の一日一文}{一日一文}{他人の輪郭を見るということは,他人の頭の中を覗いているようなもので,めまいを覚えるなら正常}{賢くないデライターに俺はなる}{知能増幅メモサービス}{知能増幅}...=}(427)

{デライトの使い方の考え方 K#F85E/E74C-20C0}

デライトには「使い方」というページがあるのだが,これは最初の頃からまともに更新出来ていないデライト開発ありがたいこと快調で,いちいち更新していられないほど変化が激しかった。このあたりも近日中刷新するので,もうしばらくお待ち頂きたい。

もっとも,多くのデライト初心者躓いているのは,細かい操作方法というより,どういう考え方使っていくものなのか,という所なのではないかと思うデライト躓きやすい使い方の考え方」について,このあたりで少し補足しておきたい。

デライト風変わり慣れが必要なものではあるが,特に難解なものではない。開発者力不足による不親切さ多々あるものの,あくまで誰でも使えるものを目指している。まずは,ちょっとしたゲームのルール覚えるつもりで読んでもらいたい

なぜ「輪郭」なのか

デライトは,個人知識よりよく育て生活様々な場面役立ててもらうためのサービスだ。それを突き詰めた結果として,互いに入れ子出来る輪郭」という単位情報扱う仕組み持っている

ここでいう「輪郭」というのも,まずはごく普通言語感覚理解してもらえればいい。ある物事全体取り囲むもの,という意味だ。もっと具体的にイメージしたければ,輪っかり,目に見える風景一部分切り取って見てほしい。写真構図考える時などに似たことよくやるが,その時に作っている輪っかは,世界のある部分輪郭だ。

その輪郭を,自由に保存”出来たらどうだろうか。輪郭の中にまた輪郭作ることも出来る。一つの輪郭は,他の無数輪郭含むものであると同時に,他の無数輪郭含まれるものになる。そのようにして,“世界捉える”ことは出来ないだろうか。さらに,この考え方コンピューティング応用することで,従来の情報管理抱えていた問題解決出来るのではないか。ここからデライト輪郭という仕組み生まれた

例えば,ファイルフォルダディレクトリという入れ物分類管理する仕組み広く使われているものの,人間頭の中扱っているようには情報扱えない。一つの物事をどこに分類するかは,見方によっていかようにも変わりうるからだ。これは,一つの情報を一つの入れ物所属させるような「階層構造一般問題こうもり問題としてよく知られている

他方,こうした問題解決するため,より柔軟なネットワーク構造グラフ構造とも)利用した仕組み広く使われているWikipedia などで利用されているウィキはその代表例だ。ウィキは,ウェブハイパーリンクという仕組み最大限に活かし,縦横無尽リンク張り巡らしながら情報整理出来るように設計されている。しかし,こうした技術万能ではない柔軟な分,散漫乱雑になりがちで,焦点を絞って情報まとめることには向いていない

読み込み中...
{希哲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;使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲広げなかった紆余曲折を経て,これが一番単純性効率性保守性バランスが良いということが分かった

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

読み込み中...
{希哲16年2月4日}{違了}{用者}{デラング}{進捗記録}{数式記法}{軽量標記言語}{越化参照}{希哲16年2月4日の開発}{希哲16年2月4日21歩}...=}(139)

{希哲16年2月4日17歩 K#F85E/E74C-503B}

進捗時限記録中略

デラング整備越化記法越化参照疑似実体参照についての検討終了

越化エスケープ基本的な仕様について記法内部実装両面から急速にまとまった

単一文字越化

まず,バックスラッシュ使った単一文字越化では,全ての文字越化することにした。ただし,この「越化」は,「通常とは異なる特殊な解釈試みること」であり,論組言語等でのそれと同様必ずしもデラング記法としての解釈避けることではない。

非特殊文字扱い

軽量標記言語単一文字越化対象非特殊文字に付けた場合の挙動としては,「不明なエスケープシーケンス」などと違了出すわけにはいかないので,以下の2つ考えられる

読み込み中...
{単純性}

{}