[HN Gopher] Show HN: Visualizing a Codebase
       ___________________________________________________________________
        
       Show HN: Visualizing a Codebase
        
       I explored an alternative way to view codebases to the typical
       folder/file list, showing a bird's-eye-view of its structure.
       https://octo.github.com/projects/repo-visualization
        
       Author : wattenberger
       Score  : 94 points
       Date   : 2021-08-05 15:09 UTC (7 hours ago)
        
 (HTM) web link (octo.github.com)
 (TXT) w3m dump (octo.github.com)
        
       | juancampa wrote:
       | This is cool but using rectangles instead of circles would help
       | this visualization. Circles waste real estate and not friendly to
       | labels (e.g. curved text that is harder to read)
        
         | wattenberger wrote:
         | There are definitely many trade-offs with using a circle pack
         | layout - I snuck a bit of the reasoning into the collapsed
         | section halfway through the write-up! Overall, this layout
         | worked best for me, with the nesting feeling very natural and
         | the circles feeling very "atomic".
         | 
         | 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!
        
       | anigbrowl wrote:
       | Nice implementation. I especially like the curved directory
       | titles.
        
       | snarkypixel wrote:
       | So cool and useful!
        
       | arriu wrote:
       | Very cool! Reminds me a little bit of gource.
       | 
       | https://gource.io/
        
       | akdas wrote:
       | I worked on something like this a few years ago, only in VR so
       | you could walk around the visualization and use your spatial
       | recognition abilities in 3D.
       | 
       | 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.
        
         | breck wrote:
         | My big bet (10% confident it's correct and will be world
         | changing), is that having languages that rely on spatial
         | position of tokens in a 2D or 3D grid will be a big leap
         | forward and make 3D visualizations quite natural.
         | 
         | 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).
        
         | dale_glass wrote:
         | That sounds interesting, can you give more details about that?
         | 
         | 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.
        
       | wattenberger wrote:
       | We always look at our code in a file/folder list - I explored an
       | alternative way to view codebases, showing a bird's-eye-view of
       | its structure. This write-up walks through the motivations, ways
       | to use the visualization, and potential future directions (there
       | are many!).
       | 
       | 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.
        
       | zkldi wrote:
       | Is this site critically slow in firefox for anyone else or just
       | me? It's running at around 1fps...
        
       | nvartolomei wrote:
       | The best tool I found for exploring code bases and navigating
       | large projects is https://www.sourcetrail.com/.
        
         | azinman2 wrote:
         | Looks like that's pretty zoomed in compared to this?
        
       | cameronbrown wrote:
       | Is there anything like this, but for visualising the connections
       | between git commits, files, GitHub issues, maybe even classes
       | etc...?
        
       | gus_massa wrote:
       | I tried with https://github.com/racket/racket and for some reason
       | it puts all the content of the subfolder "racket"/"src" in a
       | vertical strip near the middle of the circle instead of spreading
       | the parts evenly. How is each part arranged?
        
         | wattenberger wrote:
         | interesting! I'm seeing them grouped in the middle. It's a
         | tricky layout, using d3.js's circle packing algorithm, then
         | recursively using a force layout to relax each folder's
         | contents.
        
           | gus_massa wrote:
           | It's a strange directory because it mix the old and the new
           | implementation of Racket. But IIUC you are not looking at the
           | internal content of the files, only the size. Perhaps you can
           | fill a bug report in the d3.js package. (I'm not sure it's a
           | bug, or just a very weird case.)
           | 
           | 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.)
        
             | wattenberger wrote:
             | I also added it after your first comment so might have
             | snuck it by you ;) I'm curious what it is that you're
             | seeing, if you have the chance to leave an image!
        
               | gus_massa wrote:
               | Image with bad editing here: https://imgur.com/a/XxkzWZw
               | 
               | It would be nice that if I have chosen a repo above, the
               | link includes that repo instead of the default one.
        
       | fire wrote:
       | Oddly enough, the page partially loads, hangs, crashes the tab
       | and attempts to reload, hangs, and then crashes the entire
       | running mobile chrome instance on my phone.
       | 
       | 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 )
        
       | er4hn wrote:
       | Very fun! Would a similar visualization work for showing the
       | insides of a go binary?
       | 
       | 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)
        
       | hevalon wrote:
       | Personally I find it interesting as tools like these have been
       | helping me to understand the team's and delivery dynamics when
       | I'm joining new dev-teams.
       | 
       | 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...
        
       | ThePhysicist wrote:
       | Did something similar some time ago:
       | http://quantifiedcode.github.io/code-is-beautiful/
        
         | cyberge99 wrote:
         | I take it the domain quantifiedcode is not active? It was taken
         | over by LinuxSec.
        
         | [deleted]
        
       | agustif wrote:
       | I can't access it, HN hug of death?
        
         | wattenberger wrote:
         | Hmm, it should be loading! What OS/browser are you on?
        
       | imagineerschool wrote:
       | Very interesting and illuminating!
       | 
       | Please continue on this adventure, you're onto something great!
        
       | agucova wrote:
       | This is actually something I'd consider adding to all of my big
       | projects. It really does help with discoverability.
        
       | rckrd wrote:
       | My favorite tool for visualizing a codebase is Gource. Here's a 1
       | minute visualization of the Linux Kernel repository from
       | 1991-2015
       | https://twitter.com/mattrickard/status/1423366779590430721
        
         | onefuncman wrote:
         | I used Gource to visualize a hackathon, we had everyone start
         | from a templated repo so it was really easy to show the
         | entirety of participants coding activity (albeit at a macro
         | level)
        
       ___________________________________________________________________
       (page generated 2021-08-05 23:00 UTC)