microblog
{マイクロブログ K#F85E/C034}

新着確認機能実装を一段落させた。10日12歩の修正とともに出振るい・手定め済み。
新着確認機能により輪郭一覧の更新状況がぐっと把握しやすくなった。サービスの性質上,自動更新など気が散る実装を避けてきたが,あちこちページや画面を切り替えながら作業していると,輪郭一覧の鮮度が気になることが多々あった。必要以上に輪郭一覧を更新する癖がつく問題もあった。
@DG.upd
に集約し,他機能からも輪郭一覧更新を促すなどの目的で利用しやすくなっている。filter
をかけて使っている。新生デライト開発の当努としての新着確認機能実装は優先順位が低く,最後の方になるかと思っていた。最近になって,メニューのアイコンが使えること,輪数は必要ないこと,交差監視が使えること,と立て続けに実装上の気付きがあり,高い時間対効果・負荷対効果が望めるようになっていた。
マイクロブログなどの投稿数と異なり,1輪の長文もあれば10輪の知名のみの輪郭もあるのがデライトの輪数なので,文脈を限定せず,ましてや2桁程度の表示幅では情報量の尺度として機能しないことに気付いた。
全知検索窓固定機能で採用した交差監視が使えることに気付いたのが駄目押しだった。無駄な再読み込みを抑制する効果も望めるとはいえ,多少なりとも立求が増える機能なので,悪影響の懸念が拭えずにいた。交差監視によって無駄なく効果的に待機状態を制御出来る見通しが立った。流石に高速化までは行かないにしても,十分な低負荷実装になった。
この界隈ですら,「内容に名前を付けて書く」という(ごく常識的な)発想がまだまだ根強いなあ。
デライトは,「内容に名前を付けて書く」以前の,名前はあるけど内容を書く時間がないことや,内容はあるけど名前のないことを書けることを重視している(そうでなければ知能増幅技術としては「遅過ぎる」)ので,そこをどう理解してもらえるか,が一つの鍵なのだろう。が,この調子だといつになるやら。
「あれ」がずらっと並んでいるのを見た時,ただ分かりにくいと感じるか,その特徴によって名前を付けにくいことも大量に書き出せている(その人の思考を知る手がかりが残せている)のだと考えるか。内容も名前も「書かなくていい」だけで「書けない」わけではないので,他の媒体では形にならないことがデライトでは形になっているだけなのだが,初見者にはそれがノイズに見えてしまうというのは,ナノブログ普及の壁。
ただ,マイクロブログも最初は情報量の無いページが乱立しているサイトにしか見えなかったわけで,時間の問題だろうとは思っている。
microblog
blogには「Web」を接頭しているのにこちらにそうしないのは非合理的では?
しかし「短Web文録」というのは語感が悪すぎる。