{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{`Aejs_DG_rev`}{長期的視野に立って}{更新方法}...=}(224)

{希哲16年5月23日の開発 K#F85E/A-E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{希哲16年5月の一日一文}{囚われたくない}{狭苦しい}{よく使っている}{閉じた}{満たしたい}{知的探究心}{好きなだけ}{遠慮する}{他人に}...=}(96)

{デライトに“参加しにくさ”を感じている人へ K#F85E/A-E74C-E681}

デライト新規利用者増やすにはどうすればいいか,と考えてくれている利用者達もあまり触れないことに,私自身のアカウント問題がある。デライト普及にとって最大の障害か,といえば,あまりに癖の強い私の輪郭溢れかえっていること,というのが開発者として常に感じていることだ。自分が訪問者でも入りにくいな,と思う

実際最初の頃は,自分の輪郭目立たせないように,宣伝活動をした後しばらく描き出し避けるなんてことまでしていた。それはそれで使いこなし方分かりにくくなるので,あまり作為的なことはしないようになった。だから,初期利用者入ってきた時は,世の中には変わった人がいるものだな,としみじみ思ったものだ。そうは思いつつ,私も私で失礼気がして言いにくかった

利用者達が活発描き出ししてくれるようになったおかげで,だいぶ入りやすい雰囲気になったとは思う。それでも,客観的に見れば,まだ「変わった人達の集まり」なのかもしれないし,コミュニティとしてのデライトに“参加しにくさ”を感じている多いだろう。

デライトは,極力誰でも好きな時にて,好きなこと好きなだけ書けるように設計している。もちろん挨拶必要もないし,他人に遠慮する必要もない。個人情報どころか,名前すらいらない。私自身,狭苦しいクラスタ」だとか閉じたコミュニティ昔から嫌いだ。

あまり先入観持たず,まずは触ってみてほしい,というのが開発者としての願いではあるが,もしデライトコミュニティとしての特徴があるとすれば,自由に知的好奇心探究心満たしたい人達の集まりとは言えるかもしれない。「希哲フィロソフィー」という言葉よく使っているように,知的探究心以外のなにものにも囚われたくない人間にとって,機能的にもデライト最高の場所だ。


=}
{新生デライト}{難しい質問}{超かんたん}{自由市場}{デライト(なんでもメモ)}{分からなかった}{デライト}{階層関係}{森羅万象}{あれ}...=}(55)

{引き入れについてのご質問から考えたこと K#F85E/A-E74C-C61D}

大変回答が遅くなってしまい申し訳ありません。色々なことを考えさせられるご質問で,デライトにとって非常に重要な宿題を頂いたように感じています。ありがとうございます。

だいぶ時間が経っているのでお考えが変わった部分もあるとは思いますが,他の方の参考にもなるように文章を残しておきます。まずは,ご質問の内容に沿って,出来るだけ端的に書けることを書いてみます。

引き入れについて

宇田川さんは、知名のみの輪郭をよく引き入れられ欄に引き入れているように見受けられます。

まず,「引き入れられ欄に引き入れる」という概念が私の中に無かったので,難しい質問でした。「引き入れる」というのは,ある輪郭の中に他の輪郭を文字通り「引き込むように入れる」,ただそれだけの極めて単純な操作で,それをする方にとっては「引き入れる」,される方にとっては「引き入れられる」ということになります。

例えば,フォルダの中にフォルダを入れる操作に相当します。ただ,多くのツールでは,データの内容とデータ同士の関連性は別々の画面に表示されます(別のウィンドウやサイドバーなど)。輪郭は,輪郭の内容と他の輪郭との関連性を一緒に表示させる仕組みを持っているのが特徴的です。これは,画面を切り替えたり視線を大きく移動することなく,内容と関連性を確認したり修正したり出来るようにする工夫です。

「輪郭をどの輪郭に引き入れたいか」というごく単純な考え方で使えるように設計したつもりでしたが,この見た目が「引き入れ欄に引き入れる」や「引き入れられ欄に引き入れる」という複雑な考え方をさせてしまっているのかもしれません。

このように、知名のみの輪郭を引き入れられ欄に輪括させるのは、主にどのような効果を狙ってのことなのか、ご教示いただけませんか。
あるいは、実際に効果があったと感じた出来事・体験をお伺いしてもよろしいでしょうか。

特に「知名のみの輪郭」という意識をしたこともありませんでした。その時に知名だけで十分なら知名だけの輪郭が出来ますし,当然その後描写に書き加えることもあります。知名があるか描写があるかということに固定的な意味はありません。私にとっては,この「知名のみの輪郭」という意味ありげな概念もどこから生じたのか不思議でした。

t_w さんも書いているように,アウトライナー項目をざっと書き出していく感覚に近いかもしれません。ある項目をある項目の下位に移動させることも引き入れに似ています。

平面的なアウトライナーに対して,各項目が独立していて,どの角度からでも階層関係立体階層構造を作ることが出来る。これがデライトを「立体アウトライナー」と呼ぶ理由です。大袈裟な言い方をすれば,私はこれを使って「(普通のアウトライナーでは不可能な)森羅万象アウトラインを書き出している」ところです。その単位をそのまま「輪郭アウトライン」と呼んでいます。

アウトライナーで最初にざっと書き出してみた項目も,ご質問にある「知名のみの輪郭」も,言ってみれば「情報の」です。どのようにでも成長していく可能性があり,何がどのように役立つかは予め分かりません。ひたすら蒔いてみるしかないわけです。


効果」というのも正直困った部分でした。私は息をするようにデライトを使っていて,その恩恵に依存して生きているようなところがあるので,「空気に効果があったと感じた出来事」を聞かれているような感覚でしょうか。

ある言葉に関連する言葉がこういう形で連なっていれば,日々気付かされることは枚挙に暇がありません。思い出せなかったことを思い出すこと,気付いていなかった概念同士のつながりを発見すること……これ自体はデライトのごく基本的な使い方です。

全知検索について

当方が同じ操作を行う場合、短期的には全知検索の検索語として、未来の自分が検索することを見込んでいます。

しかしながら、ただ検索に引っ掛かるためだけに輪郭を増やしていくと、描写のない輪郭が増え、デライトの持つ「同じ知名の輪郭を複数作れる」機能の恩恵を受けられず、形だけの輪括だけが増えていってしまうように感じてしまいます。

これも理解の難しい部分でした。「同じ知名の輪郭を複数作れる機能の恩恵」,「形だけの輪括」が何を指しているのか分かりませんでした。「描写のない輪郭が増えることで何らかの恩恵が受けられない」と感じたこともありませんでした。

そもそも,「同じ知名の輪郭を複数作れる機能の恩恵」というのは,「絶対的な名前のない情報を扱えること」以上でも以下でもない,極めて単純自然なことだと思っています。例えば,ツイートのような思いのまとまりにいちいち名前を付けていられませんし,同じ文字列で表現されていても異なる物事がたくさんあるのが我々が住んでいるありのままの世界です。ウィキなどでは全ての物事に固有の名前を付けるという極めて不自然なことをしてきたわけです。それを排し,文字通り「なんでも」記述対象に出来るようにしたのがデライトです。

「検索に引っ掛かるためだけに輪郭を増やしていく」という表現から,どうも全知検索の趣旨が上手く伝わっていないらしいということは分かりました。全知検索というのは,「検索に引っ掛かるように輪郭を増やしていく」こととデライトに知識を蓄積していくことを同一視し,それを促進するための仕組みなのです。

引き入れによってある輪郭からある輪郭への関係が作られるということは,脳内にある情報が輪郭として表現され,それがつながっていくということです。これは頭脳をデータとして再現するということであって,デライトが実現したいことそのものです。それはそのまま検索結果を充実させることにもなるわけです。

たまに「検索用の輪郭」という表現が使われることがありますが,「検索用の輪郭」「検索用ではない輪郭」という分類も全く本質的ではありません。それが有用な分類であればそういう機能にしています。デライトではそれをあえて排しているわけですが,この意図もあまり上手く伝えることが出来ていません。頭の中にある情報は全てが他の情報を引き出す鍵でもあり,その意味では全て検索用です。それをそのままデライト上で表現して欲しいというのが全知検索の趣旨です。

私はデライトを使って自分の頭の中にある全ての物事を紐付ける作業を日々しています。それによって,頭の中で情報を引き出すようにあらゆる情報を自由自在に引き出すことが出来ています。これ以上「恩恵」のあるメモツールを私は知りません。

考え過ぎないこと

どうせ輪括するのであれば、もっと長期的な効果を見込みたく(そこそこの信念を持って輪括したく)、輪郭法を長年使い込んでいる先輩のご意見を頂戴できればと思います。

一つ助言するとすれば,個人知識管理においては「書く前に考え過ぎること」が最大の障害です。

デライトはその障害を最大限排するように設計されています。例えば,名前を付けなくても体裁を考えなくてもまずは書き出してみて,後からいくらでも修正出来るように作られています。こういった点においてデライト以上のものはなかなか無いと思います。

引き入れについても同じで,そこまで思い悩んで使うものとして作っていないのですが,実際にはあれこれ考えさせてしまうことが多いです。これは明確に伝え方の失敗であり,日々反省しているところです。

計画し過ぎないこと

「知名のみの輪郭」「検索用の輪郭」「形だけの輪括」……こうした利用者によって再発明されがちな区別を排して輪郭という単位であらゆる情報を平等化している理由は,情報が持つ役割を決めつけず,「設計」よる破綻を防ぐためです。

近年,Notion のように情報を自由に設計出来るツールが人気を集めています。それもそのはずで,誰でも最初は自分が思い描いたように設計出来ると嬉しいものです。絵に描いた餅を見ているわけですから。ただ,その大半がまず間違いなく失敗していきます。これは Notion どうこうではなく,人間の計画性というのはそんなものだからです。

個人知識管理の実践を重ねていくと,計画というものがいかに破綻しやすいかということを学びます。したがって,経験豊富な人ほど計画に依存しない方法を求めるようになります。これは,差別がなく自由市場のある社会の方が発展しやすいことにも似ています。人と同じで,情報も成り行き任せに育てていった方が強くなります。デライトは,どのツールよりもそこに最適化されたサービスです。

デライトは簡単です

デライトは,その必要性分からなかった人にとっては「意味不明な用語が多くて分かりにくいサービス」だと思います。見慣れない UI や用語に慣れようという動機が無いからです。

一方で,本当に使いたいと思っている人にとっては実は簡単過ぎるくらいのサービスです。用語といっても小学生でも分かるくらいの表現しか使っていませんし,量も他製品に比べて特に多いとは言えません。登録するのも使うのも実際には「超かんたん」です。というのも,デライトは誰でも使えるようなサービスとして設計され,誰でも理解出来るように努めてきたからです。

ただ,この徹底した「簡単さ」が,デライトの高度な部分に惹かれてきた人ととの間にすれ違いを生んでいるのではないか,という気がしています。小学生でも分かる 1+1 について考え込んでしまう大人がいることに似ているかもしれません。デライトは難しいもの,という先入観があると,簡単さにも構えてしまいます。

デライトは簡単に使えるように作られていますし,簡単に使えるものです。

感謝

cat さんは,数少ない初期デライトの重要な貢献者です。

その方から頂いたこの質問を読んだ時,最初から最後まで意味が分からなかったことに頭を抱えました。自分は一体どれだけ利用者について理解していなかったのか,という感じです。それから毎日,開発者と利用者の間にあるについて考えてきました。回答にここまでの時間を要した理由です。

それと同時に,デライトの大きな課題を解決するヒントがここに隠されているのではないか,という気がしています。これも,率直な勇気ある質問がなければ気付けなかったことなので,本当にありがたいことだと思います。

いまデライトは,「新生デライト」に向けて文書整備を一気に進めようとしているところです。cat さんに限らず,皆様には,ふだん疑問に感じていることがあれば遠慮なく投げかけて頂きたいです。どんな疑問であれ,それと向き合うことがデライトの財産になります。

{戦略眼}{開発}{設計}{}=}(4)
{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}{出来ていなかった}{付加的}{避けられない}...=}(143)

{希哲16年3月12日14歩 K#F85E/A-E74C-2A34}

進捗時限記録中略

今後の Dex 設計方針についての検討終了これから越化参照大活躍しそうだ。


まず,課題だった脚注記法実装方針について検討している内に,越化参照部区間通信活用出来ることに気付いた

部区毎に越化条件変化などがあることから,各記法解釈部区個体任せたい。しかし,脚注記法のように最上位部区との出与え共有必要記法もある。

このような場合単純に考えれば指示体通して部区個体間で変数共有するということになるが,この種の記法増えるたびに目的別指示体増やすのは設計として美しくない汎用的な変数一つ集約するのも,効率性厳密性観点から難がある

ここでふと,越化参照使えることに気付いた下位部区個体中途解釈した記法には目印となる越化参照を付け,上位部区個体変換処理完了させる

これに似た部区間通信手法Dex 初期実装から現 &_skp;使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲広げなかった紆余曲折を経て,これが一番単純性効率性保守性バランスが良いということが分かった

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


もう一つ,処理済み対象識別に関しても進展があった。

1月21日4歩で,&_tgt;&_fin; のような目印付加することを考えていたが,付加的越化参照では結局正規表現の複雑化避けられないため,実用化出来ていなかった

昨日終えた客体表現への書き換えDex 初期実装交度整理している時,再置換避けるため記法一部越化参照当時の疑似実体参照置換する手法使っていたことを思い出した。これもあまり積極的に応用範囲広げなかった手法だが,思っていたより合理的であることに気付いた

例えばhttp&_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なこと真価理解するには時間がかかるということを改めて学んだ経験不足だと,どうしてもより高度そうなことに目移りしてしまう。


面白いことに,どちらも原点回帰のような発見だった。

直感編み出した Dex 初期実装手法再評価する十分な経験出来たこともあるが,「越化参照」という概念完成し積極的な活用考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

=}
{設計}

{}