Kozaneba開発日記2021-09-06
https://gyazo.com/3b1885028ba43611aedaae93f8879a39
---
起きたらやることを書く
最前面SVGレイヤーを追加
とりあえず矢印オブジェクトを作る
Nこうで
描画してみてアイテムのドラッグに対応するか確認
クリックハンドラをつける
まずは削除
矢印ヘッドの切り替え
今のPaste、IDを常に付け替えているが、重複する時だけにする
ファイルの依存関係を見るスクリプトを作りJSON生成
それをKozanebaに貼る
-----
今日は矢印レイヤーを作る
まずSVGエレメントを置く
https://gyazo.com/fe3d5b0065c375c28e68e84b1ead71e0
次は矢印を作ります、ポモドーロ開始
ポモドーロ終了
https://gyazo.com/d5f5b0cd7668bc0759fc5d4ddd493246
アイテムの位置に応じた線が描かれるようになったが端との交点の計算がまだ
次は交点計算を完成させて矢印っぽい外見にする
ポモドーロ開始
https://gyazo.com/8f5f5679a2472d6acd231c7c7fa3cc8e
✅最前面SVGレイヤーを追加
✅とりあえず矢印を描く
次は、今はハードコードしている矢印をデータから作る形に変える。
=矢印オブジェクトを作る
ポモドーロ開始
done
次はテストコードをもっと複雑な場面にして期待通りの表示になるか確認しよう
ポモドーロ開始
done
https://gyazo.com/60e1e72b13f43455c9bd800beb22fea3
https://gyazo.com/747d83d8fddf31626f07b8d61a36239f
今のPaste、IDを常に付け替えているが、重複する時だけにする
まず小さいJSONで矢印をインポートできることを試す
そもそも矢印をコピーできるようにする
ペーストの前にコピーを実装
部分的に選択されている場合は？
例えば3頂点からなる矢印の2頂点だけ選択してコピーしたら2頂点からなら矢印になるべき
関連して要素が削除された時はどうするか
描画のタイミングで気づくのは微妙
アイテムが削除される処理が走った後にアノテーションの更新処理が走るべき
replaceは？
IDが維持されるべき？
選択コピーは、なんせ「コピー」なので状態の更新を伴わない
ツリーになってないのでIDの付け替えの処理も別途必要
ペーストの前にコピーの実装が結構めんどくさいことが発覚した
ユーザが部分的に選択する可能性がある
まあ、だいぶ見えてきたから実装しよう
ポモドーロ開始
コピーペーストできた
ただしバグも見つかった
1ポモドーロ直して残った時間でPythonのライブラリを作ろう
ファイルの依存関係を見るスクリプトを作りJSON生成
途中でもう一つバグを見つけたのでライブラリははかどらなかった
ファイルの依存関係を見るスクリプトを作りJSON生成
それをKozanebaに貼る
実装上はできた(実用上はできてない)
こざね、全部0,0に生成したからw
https://gyazo.com/26cc13d9e4fbd41021fb2a3c156f95ad
物理演算入れたくなるな…
https://gyazo.com/3b1885028ba43611aedaae93f8879a39
---
nishio: Kozanebaに物理演算入れたくなっちゃうけど物理的な配置が知的生産物であるところに機械的に物理演算掛けちゃったらダメな気がするしなぁ nishio: むしろあれか、物理演算をオンにしたタイミングで近接していたものは「人間が近接によって表現した関係である」として近接関係が維持されるような物理演算にすればいいのか nishio: でもそれを言い出したら「少し離して置いてある」も「関係はあるがすぐそばに貼り付けるほどではない」という表明なわけで… nishio: 離れれば離れるほど関係は希薄になって維持する必要性が下がる pokarim: ただの思いつきなんでスルー推奨なのですが（すみません）一定距離を境に近いと引力、遠いと斥力にして近いもの同士の凝集性を高める、みたいなことできないですかね。摩擦力とかあったほうがいいかもです。知的生産系でそういうことがマッチするのかわからないですがどちらの結果でも気になります。 nishio: 「遠いとそれに比例して斥力」とするとビッグバンみたいに飛び散ってしまいますから「遠くに行くほどゼロに近づく」が必要で、「近いと引力」も素朴に実装すると一点につぶれるので知的生産をする上では「一定以上に近づくとそれ以上にめり込まない斥力」が必要です。その間の領域は工夫の余地あり nishio: 例えばこざね1個分より近づけると吸い付き、2個分より遠ざけるとさらに遠ざかろうとする、と固まりごとに別れようとはすると思います。水の中の油滴と同じですね。ただこれは長細いクラスタがあった時クラスタ内の離れた点通しで反発し千切れて丸いクラスタに別れる(これも油滴と同じ) pokarim: たしかにそうですね。うまく調整すればなにか面白そうな気がします。虫のいい話かもですが、そこの調整をわざとらしくない感じで「結果的にそんな感じになる」理屈が用意できたら理想的かもですね。 nishio: めり込むギリギリのところに強い「今の距離を保つ力」(物理で言うなら粘り気のある餅のような)を発生させたら反発力があっても千切れにくいかも… pokarim: なるほど、餅。餅というと近くにあるだけでくっついていないか、まさにくっついているかで大きく変わっくる感じですね。中心同士は引力で、こざねの輪郭線同士は斥力で、あとは距離と力の関係を調整すればめり込みは防げるような気もしますが、あとはちょっとやってみないとわからないですね。 https://gyazo.com/329fb606d91e2d8648243db600dd303d
nishio: 物理演算を入れたけど現状ではあんまり面白くないな pic.twitter.com/sWkyj00bh1 https://gyazo.com/de6730a0979920791d3cb494ffdb672d
nishio: 矢印が集まりまくってる頂点を削除したり、ディレクトリ階層をグループで表現したりする手はある nishio: あっ、AdaDeltaがイマイチ期待した動きしないと思ったらroot mean squareであるべきところmean squareじゃん！ nishio: あと、初期位置からユーザがドラッグして動かしたものはピン留めされて動かなくなるといい nishio: 流石にJSで物理演算をやると思いなぁと思ったがプロファイル取ったら遅いのはReactのレンダリングで、SVGのlineにkeyをつけてなかったせいだった nishio: 197ファイルの間に666のインポート関係があり、そのまま可視化すると…可視化されてない！ウニ！ gyazo.com/5723029877bfb6…
nishio: 物理演算以前の問題で、ungroupした時にも時間が掛かってるからこれSVGのline要素が2000個あるのが問題なのかなー nishio: 物理演算のステップ自体は200msくらいなので、単純に描画が重い。 まあ、この用途はメインの目的ではないので負荷テストみたいなものと解釈しておこう。
ソースコードの可視化という意味ではディレクトリをグループで表現して、それをまたぐ参照だけ矢印を引けば良い。
nishio: 明日は会議して動画編集してスクリーショットの取り直しをして時間が余ったらソースコード可視化の続きをしよう nishio: そもそも4000個のSVG line要素を書き換えるのって現代のブラウザで毎秒10回可能なもんなのだろうか