文字数が多くて重いという不便ドリブンの切り出しをしてる
from 2024/08/12
4096文字ほどを閾値にします
そういえば/shokai/status barに文字カウントを表示する（event版）というのがあった
妙に2のべき乗だな。何かで測ってる……？
当日切り出しというワードが生まれてた
ぴったりな言葉なので使わせてもらおう
書くかどうか躊躇することだけど、当日切り出しにはまあまあ不満がある
少なくとも、不満がまったくないと言ったら嘘になる
理由は今まで日記ページの当日切り出し自由じゃなかったの草にだいたい言語化されてた
あとで追記しよ
とはいえ、
さんの行動を萎縮させたくもない
↑ 5 回くらい見たこの思考。歴史は繰り返す感ある
5回も繰り返してると言うことは、今のの思考特性がそれなんだろうな
自分の負の記述で誰かの行動に制約をかけるのが嫌
もっともさんはあまり萎縮しなさそうなタイプだと感じるが
2024-11-11他人のことはわからないと言っているくせに、勝手に他者の内面を憶測してないか
少し前にもやらかして、やはりツッコミが入った
自信満々になるとろくなことにならない。もっと自信を減らさなきゃ
人の行動を萎縮させることはそもそもできず、行動が変わったとしてもそれはその人が主体的に判断した結果だと思う
パワハラみたいな状況ならあり得そう、でも対等な関係なら相手の主体的な判断力を信頼してよさそう
逆に変に悩むのも、相手に主体的な判断力がないと思っているとも解釈できるか
相手が萎縮しがちでない人だと(自分が)信じているなら、excuseをおかずに完結に不満を表明すべきか
めっちゃ板挟みな気持ちになっている
とりあえず嫌なことを表明するのは大事だと思うので、取り急ぎ書いておく
嫌なことを表明するのは大事+1
意識して表明していきたい
これとは別にもう一つ、切り出しタイトルを考えずにそのまま切り出すという点も不満がないわけではないが、これはそれでもいいと思う
あえてタイトルを考えずに切り出すことで、カニンガムの法則でページの編集機会を増やせる
結局ページタイトルを変更するかどうかは周りにかかっているので、切り出した本人がページタイトルまで考えて欲しい気持ちもある
誰も変更する行動にでなければそのままになるというデメリット
まあここはメリデメをどう捉えるかもあるなあ
メリットが↑
デメリットはページの中身とタイトルとを合わせるていないこと
もちろん、中身とタイトルがあっていない不満を抱かせて、ページ編集を促せると捉えるなら、これもメリットに変わる
不満を表明されていながらあえてやるのは、表明された意見や表明した人を軽んじているように見える
相手によってはかなり不快になる行為だとは思います
今回に限っていうと、相手ならおそらく問題ないだろうと判断して切り出したのだと思いました
実際不快にはなってない。まあ際どいことをするなあくらいは感じましたが
/nishioのなにかのページを見てそう思うようになった
どれだったかな。あとで探す
わかる
実際に不快に思った人がいることがわかったので、以上のことを追記できました
自分のスペースのものは当日でも、本人であれば好きに切り出していいかな、という気持ちがある
納得した
正直なところ、さんの切り出しは内容と合っていないというか、全体像が分かりにくくなるときもある、と思っていた
のだが、文字数を削減せざるを得ない動機があるなら、切り出しの適切さ以前に切り出さざるをえないことになるのだろうと思った
正直私は重くないのでその動機がない
たぶんスペックの高い端末を使っているからだと思う
あるいは不満に鈍感
回線速度の問題もある？ さんの環境は、現代の固定回線のネットワークからするとかなり遅いと思われる（前どこかの日記ページで見た）
いや、数万文字だと重くなるだろうから、重いと感じる文字数の閾値が比較して高いのだろう
その前に文字を読むのが長くなりすぎて切り出したいという欲求が出そう
Cosenseって端末のスペックが上がっていくことが前提で、クライアント側に結構計算させてるんでしたっけ
編集差分の計算、関連ページのソート、リンク入力補完、記法のパースをclient側でやってます
おそらく長いページになるほど重くなるのは、記法のパースだと思われます
1文字打つたびにページ全体をパースし直している
また、UserScriptを使っている場合は、scrapbox.Page.linesを高頻度で呼び出すscriptを使うと顕著に重くなります
呼び出すたびに、ページ全体のパースし、そのデータをdeep cloneしている
結果、ページが長くなるほどUIが固まるようになる
関連ページのソートはworkerでやっているので、重くなってもちらつきはないはず
編集差分の計算はなんとも言えないです
最新のデータとかなり差分のある古いデータのままのページに書き込んだあと、serverと通信して最新のデータを取り込むときはかなり重い
UIスレッドでmerge計算しているため
別スレッドでやればいいのに
おそらく開発側で問題点と思っていないか、優先順位が低い
最初から最適化を目指さず、簡単な方法で実装できるならそれでいいというスタンスだったはず
本格的に困ったらworkerで実装するなど、やりようはいくらでもある
例えばこれ
> 差分が来たら、毎回サジェスト用の辞書を全再構築している
> 初期化時と差分時で2種類書くのが面倒だった
> 計算量的にWebWorker使えば問題ないだろと最初から狙ってた
> 1project10万ページで速度が足りなくなっても、ここをチューニングすればまだまだ行けそう
> という心の余裕として取っておく
私ならサジェスト用の辞書は「1時間ごとにサーバーで計算」だったな
人数分CPU食うって、結果をキャッシュしていればよさそうだけど
Scrapboxの100000ページの壁の話が関連として気になってくる
どちらかというとScrapboxの1000000ページの壁のほうかも
複数人同時編集はどうだろう
かなり力を入れているところだから、あまり重くないかも
なんか同期アクションゲーム（FPSとか）やってるみたいな計算だなって感じがしました
その反面、複数人で同時に編集するときに常に最新の状態が表示される体験はいいものではあるのだけど
結局端末のスペックが上がるというよりスペック据え置きで安い端末が出来て、分散が大きくなる結果になった
通信量も多い？
その設計も一つのやり方だろうけど、Cosenseの導入の壁になっているのではという気もする
Cosenseが快適に動くような"ハイスペック"な端末を持っている人の割合が多くないと、
Cosenseを使ってもらいたい＝ハイスペックな端末を買えということを暗にメッセージとして示すことになる（対象の母集団には依る）
そういうツールをおすすめしたいか、と言われると……躊躇する
重いのか、どれくらい重いのかはなんともわからないけど、パフォーマンスのツール選択への影響はボディーブローのように効いてくる感じがある
Cosenseの顧客（有料ユーザー）はそれなりのPCスペックを基本に持つ企業だから別に壁になってないのかな？ とも思ってきた
うおー楽しみです（負担をかけたいわけではないです、ご随意に）
井戸端だから重い？（ProjectCSSが多くなると重い？）
:has()みたいな計算量の重い記法を使いまくると重くなります