These are diagrams from a sample Python GitHub repository which has been set up for testing GitUML's Python parsing capabilities. You can select this sample repository via the new diagram wizard if you want to get started quickly and just have something to play with.

The source code in the repository is not a coherent application, but rather various modules and classes which exercise the GitUML Python parser, including a mix of Python 2 and Python 3 files to ensure GitUML can handle both flavours of Python.

The following featured diagrams have been generated from Javascript, one of the most popular programming languages. If your Javascript module/file contains variables, functions and classes - then GitUML will visualise the module/file as a box with the M <<module>> stereotype - global variables and functions in that module are listed as if they were attributes/methods of a class.

Where is gets even more interesting is if your Javascript code has no classes an lots of functions - GitUML can visualise functions as boxes 🤯
- variables become box attributes and inner functions become box methods. How useful - check out the What 'JQuery' looks like diagram. See also:

• The Javascript UML fiddle default example visualises two levels of function nesting.
• Diagram 170 contains a large inner function - visualised as a box, plus some Literate Code Map commentary.
• Diagram 168 visualises ES6 Javascript classes

These Javascript diagramming projects relate to the classic "Rosetta Stone" TodoMVC project, which is simply a Javascript 'todo' application implemented in countless ways, using different Javascript frameworks. The following diagrams show the reverse engineering analysis into a Literate Code Map diagram of the TodoMVC Jquery implementation, as well as my new, additional implementations of TodoMVC using OO and ECS:

• TodoMVC-JQuery - editing use case - Literate Code Map.
• TodoMVC-JQuery - initialisation use case This is the initialisation use case of TodoMVC-Jquery - Literate Code Map.
  I found that the very act of building this diagram was a powerful way to understand how this particular implementation worked, and allowed me to more easily build my own TodoMVC implementations (see below).
• TodoMVC-OO TodoMVC implemented using traditional OO, Controllers and Events. (see accompanying article).
• TodoMVC-ECS TodoMVC implemented using a Entity Component System game architecture (see accompanying article).
  Note also the associated reverse engineering of the Jecs ESC Framework for Javascript, which I used in my TodoMVC-ECS implementation. View this diagram by clicking on the diagram 168 thumbnail below.