{メモサービス}{デライトの考え方}{デライトの使い方}{}{写真}{デライトの使い方}{輪郭}{以前}{一日一文}{サービス}(431)

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

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

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

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

なぜ「輪郭」なのか

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

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

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

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

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

読み込み中...
{進捗記録}{進捗}{希哲15年12月21日の開発}{円滑な移行}{熟れてきた}{仕切り直す}{構想段階}{大きくなってきた}{SLFS 環境}{再現性の低い}(61)

{希哲15年12月21日4歩 K#F85E/E74C-B8F6}

SLFS 開発手法についての検討終了

主力機更新本格的に検討するようになり再現性の低い SLFS 環境問題がより大きくなってきたため,円滑な移行のためにも SLFS整理急ぎたい。ここで,構想段階のまま中断していた SLFS 0.003お蔵入りにし,SLFS 0.004 として仕切り直すことにした。

SLFS 実機フジ型場当て利用するつもりだったが,やはり試行錯誤実機でするのは負担が大きい仮想機利用するのも出与え管理などをどうするかという問題があった。

この際親環境SLFS 実機との完全な出与え共有考えず1つSLFS 仮想機を作りそのフジ型場当て実験繰り返し,構築手順熟れてきたところで SLFS 実機再現試みることにした。この時にもフジ型場当て重要なので,親子二重利用することになる。

現行SLFS 環境混沌としていて移植しにくいため,作業用Linux 出来採りとして先日救出用 DVD採用した Slax使うことにした。

{開発}{開発記録}{描写部}{輪郭小窓}{希哲15年7月23日の日記}{難がある}{総合的に勝る}{開始操作}{二度押し}{希哲15年7月23日}(42)

{希哲15年7月23日の開発 K#F85E/E74C-8F83}

輪郭小窓引き入れボタンに加え,輪郭小窓から引き放ち出来るようにすることを考え始めた。タッチ端末での引き放ち式再現難しいという課題があったが,これで解決しそうだ。特に開始操作長押し舞覧機能干渉二度押しダブルタップダブルクリックに合わせたい)採用しにくかった。

引き放ち式個人機でも操作性挙動難があり,調整必要を感じていたため奇跡的丁度良かった

これが決め手となり,描写部に限らず前後景輪符輪郭小窓統一諸場も統一することを決めたタッチ操作ではページ移動に二回タップ必要になってしまうことから少し迷いがあったが,輪郭小窓利点総合的に勝るだろう。

{進捗記録}{知番}{進捗}{26時}{13時30分}{試象}{_dg}{_dg_oln}{握接}{希哲15年8月31日9歩}(75)

{希哲15年4月16日4歩 K#F85E/E74C-E7C9}

前後景輪数表示不具合修正

いったん終了。

この問題に気付いたのは今日正午前だが,昨日26時頃までは問題無かったため,この10時間ほどの間に発生したと思われる。

具体的には,_dg_oln自我知番K#F85E の場合に限り n_fgn_bg がそれぞれ一つの数値統一されてしまっているという問題だった。この数値は _dg前景後景の自我知番を検索した時の数値に一致することを確認した。

このことから,誤った UPDATE 求頼K#F85E の全ての輪郭更新をかけてしまった,ということは間違いない。その求頼がどのように発生したのか,ということまでは突き止め切れなかった。n_fg・n_bg を更新するのは dg_sync_n_fg()dg_sync_n_bg() くらいなので,直接的にはこれらの仕業だろう。


発見してすぐ全輪郭に対して dg_sync_n_fg()dg_sync_n_bg() をかけ,完了した13時30分頃には正常化したことを確認済み

最後に1輪だけ,修正されないまま残った輪郭があることに気付き調べてみると,知番 A- 以後が 0 の明らかに不正な輪郭だった。描出希哲9年6月26日知名は「イタリアの地方自治」だった。デルンもまだ不安定な時期だったので,こんな輪郭が紛れ込んでいてもおかしくはない。いずれにせよ存在してはいけない知番なので,当該輪郭は削除済み

一つの可能性として考えられるのは,この輪郭に誰かが握接し,不正知番dg_sync_n_fg()dg_sync_n_bg()誤作動を引き起こした,ということだ。最近,クローラー巡回激しいので,握接したのは誰であっても不思議ではない。

ただ,軽く試象してみた限り,問題箇所は見つからなかった。流石に,多少の不正知番WHERE 句致命的な狂い方をしないようにはしてある。

それほど深刻な問題ではないこと,概ね可能性が絞り込めたこと,復旧容易なことから,ここでいったん調査打ち切ることにした。今後はこの問題を頭の片隅に置いて周辺作業を進め,再現した時は再調査することにした。


元々前後景輪数表示に関しては多少狂うことがあるのを認識していたが,この復旧作業によってそれらもいったん正常化したようだ。

また,全輪郭再同期すると現状およそ1時間30分ほどかかることが分かったのも収穫だった。今後同様の対応が必要になった時の参考にする。

{進捗記録}{進捗}{デライト}{Android}{PWA}{希哲15年2月25日の開発}{操作不能}{希哲15年2月25日の進捗時限}{希哲15年2月25日の進捗}{ウェブアプリマニフェスト}(28)

{希哲15年2月25日1歩 K#F85E/E74C-3B29}

デライトの PWA 対応から間もなく気になっていたことだが,AndroidChrome引装した PWA で,外部サイトに移動してから戻った時にアドレスバーが残ってしまう問題についての調査再開

途中で終了。

以前にも軽く調査したことがあり,ウェブアプリマニフェストscope を弄ったりしたが解決しなかった。

そもそも不規則再現したりしなかったりする上,外部サイトからデライトに戻った時に残るアドレスバーは表示されるだけで操作不能というバグっぽい挙動なので対応に困っていた。

{進捗記録}{進捗}{Firefox}{不具合報告}{交度}{希哲15年2月16日の開発}{半角スペースが + に置き換えられてしまう不具合について}{%20}{原因判明}{@URI.dcd()}(46)

{希哲15年2月16日3歩 K#F85E/E74C-7917}

輪郭に空白名があると検索→新規作成の際にASCII加算符に置き換えられてしまう」という不具合報告について,ようやく尻尾が掴めた気がしたので再調査に入る。

原因判明修正完了

結局,decodeURIComponent()+半角スペース置換しないというよく知られた落とし穴のせいだった。

decodeURIComponent() に渡す前に置換処理をしておくというのが定石らしいので @URI.dcd()修正

+ と半角スペースという時点で URI 符号化絡みの問題なのは明らかだったが,最初の調査では交度論理的問題が見つからず,再現性明確ではなかった。

当然,全知検索窓に直接入力すれば問題なく,Firefox ではアドレスバーURI を直接編集して半角スペースを含んだ検索をしても問題なかった。問題は,アドレスバーに直接検索語を入力した場合で,この場合は %20 ではなく + に半角スペースが置換され,これが JavaScript 側ではそのまま通っていた。

更に問題をややこしくしていたのは,捌き手では問題なく + を半角スペースに復号していたため,そのような検索をすると表示上も描出も問題なく行われるが JS で制御している描出後の転送先のみ + が残った検索になっていたことだった。

さっき何となく半角スペースを含んだ検索語から描出したことで再現し,交度を見直してもやはり問題が分からず,まさかと思って decodeURIComponent()仕様確認したところで原因判明した。

今後のためにもなる勉強になって良かった。

{再現}

{}