「ソースコードを3Dアニメ化」記事へのコメント

ふぅ～む

[cyber205 (4374)]

xcruiseみたいなもんなのかなぁ。
構造が複雑化してボリュームが増えているのはわかるんだけど、
確かに、いまいち「わかりやすい」という感じがないっぽい。

でも、巨大で複雑なコードをビジュアライズして見せるって

Re:動作させてカーナビで診る

[sameshima (10060)]

こういうの好きです。
実際にコードを走らせて、活性化している
部分がピカッと光るようにして、見てみたいですね。
テストカバレッジに使えるかも（ずーっと暗いところが未テスト）

また、アーキテクチャ（PC)にマッピングして、
どのコードがどこのリソース（バス、プロセッサ、グラフィック等）
を食いつぶしているか見れたら、ボトル

方向オンチはプログラマになれない?

[Anonymous Coward]

これからは、プログラマになるための資質として、方向感覚が必要になってくるかもしれないですね。

ソースの依存関係が複雑になってくると、3次元空間では足りなくなって、4次元以上の方向感覚が必要とされるとか。

Re:方向オンチはプログラマになれない?

[G7 (3009)]

XCluiseはたしか、ファイル(path)名の文字列をもとにして座標を決定してるんでしたよね。

人間が3次元空間を見るという想定で「ファイル名」を座標に変換しようとすると、
1つの軸を表現する分解能として細かすぎない所を狙うには、
せいぜい2byte(65536段)くらいで1軸ってことになっちゃうんじゃないかな。
つまり(リニアにやればの話だが)6文字かそこらで3Dビジュアル的にはお腹一杯になっちゃう。

そう思うと、何十文字だろうが容易に識別できる(注：識別と暗記は別ですが)
文字列、というかその文字列を読む人間様の能力というか、は、たいしたもんだなと思います。

そして

文字列そのものの３D図での復権

[nash (7152)]

スレッド元の視覚化形式は線分と雲があるだけで、文字列もアイコンも出てこない(文字列は補助として出てくるだけ)ので情報量が少ないという気がします。

ノード間を「線分」でつなぐのではなく、「モジュール名を構成する文字を構成する線分」（←一画二画の画のことです）の一部が別のモジュール名を構成する文字を構成する線分に直接繋がっているというのはどうだろうか。

FILE____________________

Re:文字列間の納豆のような張力

[sameshima (10060)]

dasher [cam.ac.uk]みたいな感じで、
モジュール名が吹っ飛んできて、、
そんでそのときに、それぞれの
文字が納豆みたいに糸でつながってて、
情報の依存関係で張力が異なる感じ？
そんで
タスク分割するとき、タスク間の情報のやり取りが
多いときはたくさん糸を引いて、引き離すのに
力がいるとか。。

Re:文字列間の納豆のような張力

[nash (7152)]

dasherは知りませんでしたが、うーん、似ているような似てないような。
# 代書屋ってPOBOXのアニメーション版だなぁ。

3次元空間を使った可視化という線は外したくないです。糸を引いているのは確にそういうイメージ。
3次元なので情報量制御はピンぼけでしたいなぁ。マウスで指定する度に、あるいはincremental searchでヒットする度にピントが合っていくと。
（名付けてシュレディンガーの文字列)

> タスク分割するとき、タスク間の情報のやり取りが
> 多いときはたくさん糸を引いて、引き離すのに
> 力がいるとか。
こういうのだと僕は所先生の計算場理論を思い出す。