In the same vein, gource is pretty cool. It shows the same sort of graph, but animated as it changes over time. So you can watch the project develop, and even see who was working on which files at which time. It's great to put up on a screen during launch celebrations or whatever.
Why does it move and wiggle? It makes it unnecessarily hard to click on nodes. Also, it took me at least 30 seconds to figure out how to start at all as I didn't notice the small inputs in the upper lefthand corner.
Because it's using a graph layout algorithm called Force Directed Graph Drawing, where you basically connect the nodes together with springs and then run a simulation.
The algorithm's really simple and works pretty well, but unfortunately it doesn't really have the concept of 'finished' --- you just keep simulating until it looks right. Some implementations watch for small deltas and when the change rate gets low they stop the simulation, but it can take a while and people frequently don't bother.
Up to about 1fps. The DOM tree continues to gather its factions together under one banner. Meanwhile, the smaller but more easily organized devtools and webidl factions are making an early power play.
I'm looking forward to one day being shown a "visualizer" that actually gives me sane insight into the structure, instead of some wibbly-wobbly animated node graph that I have to click around and zoom in/out. These things can sometimes look pretty, but usually I'm left none the wiser about the actual structure.
What would that look/behave like? I ask because I'm starting out on making some tooling for gaining insights into coupling and coherence in ruby, and I'm at a brainstorming phase.
E.g. automatic domain concept detection and suggested refactorings around domain concepts.
Re-organizing file systems into virtual filesystems based on multiple views/perspectives on the project, etc.
Any ideas you have would be really good timing to hear about
Not really regarding what, but on the how front, I remember that one guy invented what he called "hive plots", and he seems to be claiming they're some kind of a panaceum to so called "hairball" plots:
Completely agree - Gource is also mentioned here and does something similar.
Probably more useful tools are CodeCity and JSCity, that go beyond the layout of the repo and get to the function level, so they are able to give potentially useful insights like coupling or complexity of classes. In any case, there's a long way to go as far as the effort of running these programs actually being worth it.
I think it says good things about Wren that the largest section, by far, is tests. Then a big blob for docs. The actual language interpreter itself is quite small.
Being able to search/filter by name. I often find some file being included in the build and its a pain to track down exactly who uses it (ok, not a huge pain, but it would be so much easier to do it in this)
40 comments
[ 5.1 ms ] story [ 97.5 ms ] threadIt would be good to gracefully handle large graphs. I typed in "torvalds/linux" and my tab froze!
Here's what torvalds/linux looks like on the visualizer (pretty cool!): https://imgur.com/a/AHNcn
Here's a recording of the linux repo being parsed by gource. https://www.youtube.com/watch?v=5iFnzr73XXk
However as of right now this is a completely client-side JS app, it might take too much processing power and API requests to analyze individual files.
also would be cool to color/heatmap them by recent modification dates, filesize, LOC, etc.
[1] https://en.m.wikipedia.org/wiki/Mystery_meat_navigation
Might make it so that root level directories have their label always shown.
image: http://www.gravitypersists.com/assets/neo3.gif
https://github.com/neo4j-contrib/versal-cypher-gadget/blob/m...
http://gource.io/
Are interesting visualizations as well.
The algorithm's really simple and works pretty well, but unfortunately it doesn't really have the concept of 'finished' --- you just keep simulating until it looks right. Some implementations watch for small deltas and when the change rate gets low they stop the simulation, but it can take a while and people frequently don't bother.
At one frame per minute, I'm looking forward to where this goes
Edit: Progress report (~1h): https://nemu.pointysoftware.net/sink/nephscreen-1456335941.p...
Up to about 1fps. The DOM tree continues to gather its factions together under one banner. Meanwhile, the smaller but more easily organized devtools and webidl factions are making an early power play.
E.g. automatic domain concept detection and suggested refactorings around domain concepts.
Re-organizing file systems into virtual filesystems based on multiple views/perspectives on the project, etc.
Any ideas you have would be really good timing to hear about
http://www.hiveplot.net/
(His (?) earlier invention of a "circular graph" seems also to have gained some traction in sciency publications - see http://circos.ca/intro/circular_approach/)
Probably more useful tools are CodeCity and JSCity, that go beyond the layout of the repo and get to the function level, so they are able to give potentially useful insights like coupling or complexity of classes. In any case, there's a long way to go as far as the effort of running these programs actually being worth it.
https://wettel.github.io/codecity.html
https://github.com/aserg-ufmg/JSCity
https://en.wikipedia.org/wiki/Treemap
http://windirstat.info/
https://github.com/timqian/js-code-structure
http://i.imgur.com/x3yztG8.png
I think it says good things about Wren that the largest section, by far, is tests. Then a big blob for docs. The actual language interpreter itself is quite small.
Being able to search/filter by name. I often find some file being included in the build and its a pain to track down exactly who uses it (ok, not a huge pain, but it would be so much easier to do it in this)
is utter chaos, brings chrome to a crawl :P
https://github.com/timqian/js-code-structure
The idea to make it a website is great, I might build a similar website for js-code-structure