https://octo.github.com/projects/repo-visualization
There's also an interactive tool to check out your own repos and a GitHub Action if you want to integrate a diagram into a README.
Is it just a visualization of the directory structure?
I expect code visualization to more or less ignore the file structure and focus on semantic analysis. For example, show the major components of the system and how they interact. Perhaps the major components are represented by some kind of a module, or a collection of modules. I don't have any concrete ideas. But I was expecting something in this vicinity.
This particular is great, as it reminds me of a book that I had read a while back; Your Code as a Crime Scene [1] by Adam Tornhill.
Adam is trying to explain something similar, but takes the whole concept onto the next level by explaining how tech debt and hidden coupling can be discovered using the git history and similar file structure visualisations.
[1] https://pragprog.com/titles/atcrime/your-code-as-a-crime-sce...
they're here:
https://github.com/gilesbowkett/rewind
but they're a bit stale at the moment. one major weakness they have is that they work on a per-repo basis. no problem at all for monorepos, but for a company with a lot of repos, it'd make sense to use the GitHub GraphQL API to find out which repos see the most activity.
Edit: the more I play with it the more I like it. Also just noticed their feature to deep link to repos (example: https://octo-repo-visualization.vercel.app/?repo=owid%2Fowid...). The future directions they mention also sound really exciting. Seeing files that cause a lot of CI failures, files by # of authors, files by # of changes, all that stuff would be really cool.
Here's a render I made in December, "1500 Commits (39 months) in 1 and a half minutes": https://www.youtube.com/watch?v=szhYhph4C2U
And he's another one I made a few years ago, "100 Commits (18 months) in 1 minute": https://www.youtube.com/watch?v=aIN4mOdL0d0
The "you can see really quickly..." text is scrolling by and I'm like... "Nope, that picture still means nothing to me." :(. It starts highlighting different parts and I'm completely at a loss on what is highlighted.
I do think this can be very effective once I'm trained on it. Such that I plan to play with it. But I just don't visually think of programs in anything close to this manner.
Anyone know if studies that explore how we think of our programs?
I feel like this visualization goes a long way to showing the distance I feel when working on the code, but that’s only because the visualization captures the lexical distance and we generally group functionally close things together.
I also confess that I think my best understanding from code is not at all linear in the textual representation, either. Sure, small code fragments are easy to reason about in a top down, left right fashion. But most of my understanding is a lot more disconnected than that.
Frustrating, as I do like pure functions, when I can get them. But... I also like knowing what the "metaphor" for a program is such that I can also reason about what it is doing.
This is best termed for me, ironically, in a graphical sense. Seeing a cube that is rotated 45 degrees is easier to understand in a Logo like language where the directions are the same, except for the initial condition. (I may just have a soft spot for Turtle Graphics. :D)
One part we struggled with was evolving the visualization with the codebase. I see in the demos at the bottom that small changes to the codebase can have a large impact on the visualization (unless I'm missing something), making it difficult to treat the visualization as a fingerprint over time. I wonder if there are plans to address this.
This is an area I'm very interested in, happy to chat about it any time.
I think 3-D visualizations of 1-D languages (all our current programming languages are 1-D) will not be so helpful, as you will be looking at transformations, not the actual code as it exists.
If anyone is intrigued and wants to write a function that takes as input a parsed Tree Notation program (https://jtree.treenotation.org/designer/) and outputs a a https://www.mecabricks.com/ file, get in touch! I could even fund something like that, if needed. Such a function would then be able to generate a LEGO version of any program written in a Tree Language. From there, I think there could be interesting discoveries to be made related to future version control systems and collaborative editing algos (I think you could beat CRDT/OT/et al).
I believe there should be a presentation layer separate from the code. Give people tools to build an empty building (or city) via floorplans; allow them create pleasing spaces in VR. Then the actual code machinery (literally represented as machines) is built inside the various rooms.
My hope is that organizational/bikeshed concerns are funneled into the architectural/interior decoration layer, whereas engineering is housed in those 3D spaces relatively undisturbed. The needs of the code would exert influence on the architecture as new spaces would be required for new functions, or rooms would be rearranged to better reflect dependencies and coupling.
This is the part that I disagree with. The source code is linear, sure, but the structure that ties the different components in a codebase together is high-dimensional. For example, the symbol usage graph is really useful to visualize in 3D, as is the general package structure.
And most of these visualizations we see don't even touch on runtime analysis like I was working on! There, seeing different types of data arranged either by where the data is coming from in the source code or where the data is coming from at runtime (analogous to lexical vs. dynamic scoping) is a visualization that benefits from 3D.
I work on Vircadia (https://vircadia.com/) and have been thinking for a while that it would be cool to have in-world visualizations of things like the project's structure and github activity. It's a big one, so perhaps the right 3D representation would make the project's structure more understandable at a glance.
The multiplayer aspect is immensely valuable. Having multiple developers walk around the same codebase together, discussing the architecture and the code, is helpful for debugging, onboarding, brainstorming, all the different ways we collaborate as developers. This kind of visualization is not a solo activity, so I can see where Vircadia would come in.
- Labels are way too small, so you'll need to zoom in..
- ...but if you zoom in, you'll need to pan...
- ...and if you need to pan, you lose context
- Hovering over "connected files" is just a jumbled mess
I don't mean to be overly negative, but it's just not a good visualization and no one will ever seriously use this.
You knew you were being harsh and let your emotional response get to you. But, you should remind yourself that a person was on the other side of this post, and she cared enough to share it. Even if you feel the visualization is unacceptably bad, you should seek to find a way to provide constructive criticism. You’ve got the beginnings of actionable feedback, it’s just covered in invective language (though directed at the work not the person, so that’s something!).
For me this was like a second blow. Criticism always hurts, but at least the first guy thought I was tough enough to take it. You, on the other hand, not only agree with the first guy, you think I'm so feeble that I need a "nice" person like you to shield me.
When people stick their neck out they will sometimes get hurt. This is totally normal and a natural way of learning and developing. Safe spaces don't make successful people. The comment you are replying to didn't even seem emotional to me and certainly didn't attack the person. It was just honest feedback.
But I also don't think they're trying to present this as a new killer feature they've been working on for years.
I'm pretty sure this is just an experiment/exploration done by a few people over a few months to see what they found, then they presented their results.
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
I think it's pretty cool and would love to have the option to navigate repositories like this.
I have needed quick visual fingerprints of repos for a very long time, even just a crude outlay of the filesizes was what I needed but this provides even more. I just don't like the tone of this criticism, and nobody would ever do Show HN's ever again if "it's just not a good visualization and no one will ever seriously use this" was the standard for commentary.
Plus, even if the result isn't perfect, the fact people are exploring alternatives to a tree structure is great, because trees suck for anything that's broad and deep, especially in a language you're new to that doesn't have familiar patterns.
In the part that says "direct link to your own repository" you can add a link icon for people (like me) that doesn't read all the text. (I was going to suggest that as a feature, but looking again I found it.)
The "eralchemy" tool (https://github.com/Alexis-benoist/eralchemy) is also excellent at visualizing SQL databases: https://github.com/WhiteBeamSec/WhiteBeam/wiki/SQL-schema
I don't think I've ever seen that before! I'm guessing the page is just memory heavy and android 11's memory manager can't figure out how to deal with it.
( chrome mobile, pixel 3 xl, android 11 )
It would be super cool to have a way to visualize how different modules add bloat in size (and may pull in other bloaty modules as well)
But big picture, this write-up isn't tied to the current visualization! It's more focused on exploring _how_ a visual representation could help our understanding of codebases. There are tons of jumping off points, including different vizes!
This would be great for a presentation where I'm trying to make our codebase look flashy and cool. But for actually getting work done, I'll take a tree map any day. Check out the mac app GrandPerspective if you haven't seen it - great use of tree maps for cleaning up hard drive space.
Case in point in the author's create-react-app example: in one of the scrolling "comment boxes", the author calls out that the "tasks/" folder is mainly CSS files which made me raise an eyebrow...why would a tasks folder be mainly CSS files? -- and upon closer inspection of the colored legend .sh files are a VERY similar green. Just to satisfy my curiosity I visited the repo and sure enough, it was just .sh files, without a single .css file.
It makes me doubt the experience of the author...how can a folder called tasks/ (in any repo) be .css files?
There are several public conference talks that cover this visualization and related use cases: https://www.youtube.com/watch?v=fl4aZ2KXBsQ
There are lots of examples of OSS projects visualized here: https://github.com/facebookarchive/pfff/wiki/Examples
For this, i believe that Gource is a lovely tool, which you can just point at a Git repository and it will visualize it: https://gource.io/
It's a nice bird's eye view. One thing I'd like is for there to be multiple metrics to use for the size of packages e.g. lines of code, number of files, number of methods etc.
That way you can make sense of what are the heavyweight parts of the codebase.
Guess there's an upper limit on the size of the repo, or perhaps it's more geared to different "shapes" of layouts.
Please continue on this adventure, you're onto something great!
Can we just not do these cute UI gimmicks?