{サービス}{開発記録}{デライト}{希哲17年4月11日の副日記}{制御出来る}{拭えず}{立求が増える}{本質的な機能}{負荷対効果}{優先順位が低い}...=}(203)

{希哲17年4月11日の開発 K#F85E/E74C-7F12}

新着確認機能実装一段落させた10日12歩修正ともに出振るい手定め済み

新着確認機能により輪郭一覧更新状況ぐっと把握しやすくなったサービス性質上自動更新など気が散る実装避けてきたが,あちこちページ画面切り替えながら作業していると,輪郭一覧鮮度気になることが多々あった必要以上に輪郭一覧更新する癖がつく問題もあった

実装要点次の通り

新生デライト開発当努としての新着確認機能実装優先順位が低く,最後の方になるかと思っていた最近になって,メニューアイコン使えること,輪数必要ないこと,交差監視使えること,と立て続け実装上気付きがあり,高い時間対効果負荷対効果望めるようになっていた。

マイクロブログなどの投稿数異なり1輪長文もあれば10輪知名のみの輪郭もあるのがデライト輪数なので,文脈限定せずましてや2桁程度表示幅では情報量尺度として機能しないことに気付いた

全知検索窓固定機能採用した交差監視使えることに気付いたのが駄目押しだった。無駄な再読み込み抑制する効果望めるとはいえ,多少なりとも立求が増える機能なので,悪影響懸念拭えずにいた。交差監視によって無駄なく効果的に待機状態制御出来る見通しが立った流石に高速化までは行かないにしても,十分な低負荷実装になった。

{ちょっと面白い}{👍}{あれ}{あれ}{ナノブログ}{マイクロブログ}=}(6)

{ちょっと面白い K#F85E/E74C-C743}

この界隈ですら,「内容に名前を付けて書く」という(ごく常識的な)発想がまだまだ根強いなあ。

デライトは,「内容に名前を付けて書く」以前の,名前はあるけど内容を書く時間がないことや,内容はあるけど名前のないことを書けることを重視している(そうでなければ知能増幅技術としては「遅過ぎる」)ので,そこをどう理解してもらえるか,が一つの鍵なのだろう。が,この調子だといつになるやら。

「あれ」がずらっと並んでいるのを見た時,ただ分かりにくいと感じるか,その特徴によって名前を付けにくいことも大量に書き出せている(その人の思考を知る手がかりが残せている)のだと考えるか。内容も名前も「書かなくていい」だけで「書けない」わけではないので,他の媒体では形にならないことがデライトでは形になっているだけなのだが,初見者にはそれがノイズに見えてしまうというのは,ナノブログ普及の壁。

ただ,マイクロブログも最初は情報量の無いページが乱立しているサイトにしか見えなかったわけで,時間の問題だろうとは思っている。

{マイクロブログ}{Web文録}{微文録}{マイクロブログ}=}(4)

{短文録 K#D657/C1F1}

microblog

blogには「Web」を接頭しているのにこちらにそうしないのは非合理的では?
しかし「短Web文録」というのは語感が悪すぎる。

=}
{マイクロブログ}

{}