Visualisation is becoming such an important part of development – it allows a level of understanding you simply don’t get from staring at text. Take a recent post from a co-worker (for those of you inside EDS it’s here) post from Keith H, noting how he’s starting to feel the love for Subversion. Having been a long time Subversion user and also a great lover of Tortoise, I understand where he’s coming from. Almost everything I do (both here and at home) ends up in a Subversion repository somewhere. I have a subversion server here at work, hosting all the support tools I’ve written to help with our project, but I also have a dedicated subversion box at home, hosted on a 500gb Synology DS106. I found out how to add packages to the embeded linux system that’s running using a telnet hack, the whole process being documented on my public blog. Well, here’s a view of one of my folders, under source control (showing TortoiseSVN in operation)
Notice the nice little overlay icons – Green Ticks show that a file is up to date with the one in the repo, whilst the red exclamation marks show that the file has been modified locally. Whilst Tortoise comes with a graphical diff tool as Kieth points out, there are much better tools which can be used in conjunction with the Tortoise Shell interface. The best is definately P4Merge, the free diff/merge tool from Perforce. Their Source Control system is one of the best available too, but unfortunately we’re stuck with the suck-fest from Borland 🙁 Having used Perforce , I think it even out classes Svn, but then Svn is free, and that easily out-classes the Borland junk. (heh, can you guess, I’m not a Borland fan yet? Thats another post entirely.) If you’re after SVN integration, we can do that too, there’s a host of svn tools that show the same graphical cues inside DevStudio like AnkhSVN & VisualSVN, and IntelliJ has SVN integration out of the box.
Anyway, the feature that Kieth finds usefull on the TortoiseMerge tool, the graphical views of the code changes is taken to a new level with P4Merge, where the graphical representation is much easier to digest because there’s an explicit graphical ‘connection’ point showing where the changes happened. So instead of just showing coloured bars representing where the code changes happened and leaving the burden of finding the re-synced code to you, there’s a handy dandy visual link, showing you exactly where the changes happened. But wait, there’s more! The graphical synchronisation works like a charm, as you scroll one pane, the second pane containing the diffs adjusts its scroll rate as the changes go by, and the connection point graphic slides smoothly up the middle. When the code is re-synced, the panes scroll at the same rate. It’s much easier to see in use than to describe! Anyway, a picture is worth a thousand words, here’s p4merge in operation on some LMS code.
I understand where Kieth is coming from, command line tools still have their place, but given the rich visualisation options we have available today, I find I’m using command line tools less and less, and becoming increasingly frustrated when they’re not available. This isn’t because I’m lazy, I’m just more productive when rich tools are available, so I tend to fight for that productivity.
Here’s another area where visualisation becomes worthwhile. Take the LMS source code – as part of an automated build system I’ve set up, a full set of on-line documentation is generated on a daily basis. Here’s an example dependency graph of the header files
in one of the source files.
Here, we can see that some header includes are duplicated, something that would have been difficult to show with just a bunch of text output, or by viewing the source in isolation.
Using tools to visualise source allows for a much greater understanding, and often alleviates the need for supplementary documentation that would have been written by hand. Object graphs, or class diagrams being another good example. The documentation generated as part of the build process also a call graphs for all of the functions in the code.
An example of a call graph, showing the code’s possible execution paths.
These static images don’t do the hyper-linked web pages any justice. Having the ability to quickly look up a piece of code, and have it visualised in some way is one of the key factors in improving understanding.If you have access to the EDS*Lan the live documentation site is here. Admittedly, these examples are using old legacy code, Tuxedo services written in C, but it’s still valuable to be able to visualise these legacy systems, and having the all the code cross referenced and hyper-linked is invaluable. And all the tools are available for more modern environments, like .Net & Java, producing not only dependency graphs, but visualisations available for almost every facet of your application, from the source code to execution timings. Take a look at ZaneBug. Not only does it let you run your unit tests (fully supporting mbUnit too!) , but you can also visualise many other facets of your application. Checkout the following screen shots
This shows an at a glance representation of the status of your unit tests (oh, wait a minute – we dont DO unit tests in code…) While the following one shows how child windows containing any of the available windows performance monitors can be added into the Perfmon tab. At a glance, you can see if your app is causing excessive page faults, how many exceptions are being thrown, how many .net objects you have allocated, which generation they’re at, or when they’re collected, your working set.. etc, all without writing a single line of code.
And finally my personal favourite, AntlrWorks by Jean Bovet. An awesome tool providing excellent support for Antlr V3, but also some incredibly usefull source visualisations for many things from DFA Decision trees :
to output parse trees :
Command line tools may still be usefull, but Visualisation Rocks!