{開発}{開発記録}{方向}{希哲16年5月30日}{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}(93)

{希哲16年5月30日の開発 K#F85E/E74C-DB91}

自動ページ展開機能実装一段落した細部に課題はあるが,実用出来る水準に達した出振るい手定め済み

これに伴い正式離立前試していた全知検索窓新規描出フォームの固定表示復活させる検討大きく進んだ。また,輪郭一覧動的追加仕組み整えたことで,検索新規描出時にも応用出来るようになった。輪郭一覧の更新効率的に行えるようになり,高速化にも大きく貢献するだろう。


AutoPagerize 対応どうするかというのが難しい問題だったが,これは挿入監視して削除注意書き表示する方向落ち着いた最初以外 .autopagerize_page_elementdisplay: none設定しておくことで表示には影響しない

AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者使っているのを見て私自身使うようになったというのもあり,用者層重なり小さくない出来るだけ混乱させないようにしたかった。


今後広告の調整重要になってくるため,ここで運営者開発者向けダミー広告表示する仕組み整えたダミー広告の様子

AdSense は,設置者によるクリックもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた


機能的に自動ページ展開機能似たところがある描写後略機能実装方針検討ほぼ完了

内容の高さ高さ制限足りない場合どうするか最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した


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

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

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

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

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

なぜ「輪郭」なのか

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

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

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

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

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

読み込み中...
{開発}{開発記録}{『希哲日記』}{写真}{日記}{}{輪郭整備}{デライト}{大輪郭整備}{希哲16年4月21日}(100)

{希哲16年4月14日の日記 K#F85E/E74C-8D6F}

輪郭整備兼写真整理始め大きな手応え得た

昨年11月30日から Galaxy S21 5G写真撮り始め写真上信環境整えたが,これをきっかけ第二次知番改良第二次快調期デライト開発急進展したため,11月30日最初の4枚しか上信出来ていなかった。写真よりも開発記録のための画面撮り上信活用することが多かった

最近良い春の写真溜まってきたこともあり,なんとかしたい思っていた大輪郭整備といいつつ輪郭整備もろくに出来ていなかったので,輪郭整備兼ねた写真整理という形が良さそうだと考えたものの,間もなく第四次宣伝攻勢という時期開発時間っていいものか,迷いがあった。

この日サイクリングという天気でもなく,姪達連れてくるので開発集中出来そうでもなく,とたまたま輪郭整備兼写真整理適した条件が揃った想像していたよりずっと手応えが良く,デライト豊か感じられる。やってみて,むしろこれは第四次宣伝攻勢前にやっておくべきことだと気付いた新生デライトが「仏作って魂入れず」になるところだった。

一日がかりでやれば S21 で撮った写真くらいは終わるかと思ったが,思いのほか量が多いので,開発作業合間少しずつやっていくことにした。過去の写真片付いたら新しい写真こまめに上信するようにし,デライトにおける日常表現をより豊かにしたい。また一つ停滞していた課題良い方向滑り出して清々しい気分だった。

日本では S22発売日今月21日になったが,一時考えたように待っていたらこの快調期は別の形になっていたかもしれず,良い春の写真撮り逃していただろう。そう考えると,あの機種変更奇跡的出来事思えてくる

15日振り返り日記

{開発}{開発記録}{点検}{希哲16年1月4日}{選り手}{編集モードと閲覧モードが切り替わる欠点}{規模的に}{欲しくなってきた}{書いてきた}{かなりの長文}(65)

{希哲16年1月4日の開発 K#F85E/E74C-441F}

雑多な考え事


SLFS起動管理系整えたことで,そろそろ画面管理系欲しくなってきた規模的に早期独自実装視野に入る


知機における自我認証PAM採用検討画面管理系について考えていたところで気付いた


現状輪郭選り手問題として,文章においても部分編集がしにくいという問題があり,用者からも指摘されている

予てから問題だとは思いつつ,その感覚的な問題らしさ反してかなりの長文書いてきたがあまり困ったことがないのが不思議だった。よく考えてみると,長文であればあるほど誤字脱字気になる箇所増えるし,まず修正箇所一点に収まることがないので,結局,最初からざっと点検しつつあちこち修正する,という作業をしていることが多い。こういう修正仕方だと,最初から全体選り手いてしまった方が無駄な表示切り替えなどがなく,かえって効率的とも言える。

とはいえ,こればかりは書き手によるところが大きく,手段多いに越したことはないので,部品単位編集一種として段落毎の編集可能にするなどで対応することになるだろう。

{整えた}

{}