VAST improvements: Navigation in Config Maps

I’ve spent quite some time merging code recently, releasing Applications into Maps and Changing Required Map versions in other maps in an effort of porting a significant amount of existing VA Smalltalk code from Version 7 to the latest version 8.5.2.

There is a lot to say about how you should or should not structure your code and the fact that merging code and releasing lots and lots of open editions can be a hard job. You need to be fully awake and always be careful not to make mistakes that only adds to the pile of tiresome and demanding work to do. But there are a few ideas for small improvements to the configuration map browser that would make life so much easier and I thought I’d start with a little collection here and ask people to comment on them or add their own. Hopefully this will lead to a list that Instantiations considers as an inspiration for improvements in the tool…

  • First of all, I painfully missed a back/forward button. Really. You jump between maps and map editions all the time and loose a lot of context without the ability to just jump back.
  • A cheap alternative would be the option to spawn a new config map browser for certain lookups. My most painfully missed ones was the “find” menu item on the required maps list and the “Dependents” family of menu items on the maps list. Let me elaborate a lttle on the dependents thing: You are in process of releasing new apps or app editions to a config map and now need to find out which other maps need to be updated because this new edition needs to be released as a required map to these. All that VAST offers right now is that it selects all dependent maps in the same list. This is really stupid, because as soon as you click on one of them to change the required maps there, the other selected dependent maps are deselected. Bummer. So you after releasing into the first of the dependent maps, you have to navigate back to the one you came from (which sometimes is hard to remember if you’ve been doing this for hours now), search for dependents again and go to the second hit just to start the whole cycle again. So how did I help myself here? I did the search for dependent maps, went to the Transcript, opened a new Config Maps browser and navigated  to all the hits marked in the first browser one after the other. Was that a good experience? No. Because you need to dig down deeper on each of them, so you end up with 5 or more config maps browsers open and get lost very easily. So a first and cheap improvement would be to let the search for dependent maps open a new config map browser with only the found dependent maps in it. The window title could be “Maps dependent on MyConfigMap (Immediate)”. This wouldn’t really keep me from loosing track from time to time, but it would help me stay much more focussed on my job than the existing tool chain.
  • The MED Required Maps browser is of great help when it comes to understanding what maps and editions thereof are going to be loaded when you load a map. Such a tree is a great way to visualize what you’re dealing with. But it is a read-only tool You always have to have a normal config map browser open next to it in order to act on what you see.
  • When you load a map with required maps, and one of the maps in that graph is referenced/used in more than one edition, VAST warns you about it before it loads the code. But it doesn’t really support you in finding where these ambiguous references are. I may miss some existing menu item in the config maps browser, but I wished for an option to find all occurrences of editions of a certain config map in a given graph of required maps of one particular map edition. It can be very hard to resolve the issue at hand without it. The same of course applies to application editions/versions. Two maps in a graph can load an app in separate editions, but there is no way that I’m aware of that you could search for these occurrences. It is hard enough to decide if that may or may not be a wanted constellation (like “I want to load this feature, but there is a fix to a class in that particular application that I need to load a newer version of on top of that”), but as VAST stands today it is already hard to find out that there is such an issue at hand. Or maybe I am just missing some menu item and someone can shed some light on it for me…
  • In the real world, projects tend to build up code structures over the years where there are lots of ambiguous references, circular and conflicting required maps associations and there’s a lot of stuff that can go terribly wrong in such code bases. One case where such problems show their ugly face is migrations of code between VAST releases. You typically open up all maps during the process and produce lots of open map and application editions. Every time I try to resolve such issues, I start doing the very same thing: take a sheet of paper and draw boxes (for map editions) and connecting lines (for req. map relationships), just to understand the graph of code artefacts at hand. In this particular project, I simply gave up on it after a few hours, because 3 sheets of paper simply didn’t suffice. I knew there are lots of unnecessary req. map relationships but without a visual way of understanding the whole graph, it is almost impossible to decide which relationships may or may not be superfluous. So what would really help a lot would be a tool that visualizes the required maps graph of a map. This graph should at least show all relationships between maps, but it would best also include version numbers / edition timestamps.

So I am eager to learn what other VAST users think of these suggestions, where they see potential for improvements, what kind of tools they wrote (we do use a little box of utilities of our own as well), or what tricks people use to solve the kinds of problems i describe here. Feel free to comment and let’s start some discussion that could help Instantiations improve VAST and Envy tooling in future releases…

2 thoughts on “VAST improvements: Navigation in Config Maps

  1. Joachim, the ability to move back and forth in the drill down of config maps was one of the reasons I hung onto Trailblazer for so long. It’s actually far more powerful than a “back” button because one can arbitrarily jump back several steps into an analysis.
    As for searching for specific versions of a config map in a tree, I have some extensions to Monty Kamath’s GoodStart tools that lets me dump a tree of required maps into a workspace. From there, I can do a search to discover where the problem lies. I can also browse or report differences between the current image and an arbitrary map, or identify application version inconsistencies in a config map. I’m not sure if those changes are released into any available version of the GoodStart tools, or even where one can get the GoodStart tools today.


    1. Hi Tom,

      I had a bad start with Trailblazer very early in my Small talk ‘career’, and it seems I completely missed the point back then…

      I too have some tools for comparing an image to a set of config maps, releasing an application version into multiple maps and such, but they make assumptions about given prerequisites or a philosophy behind map structures. Some projects, however, follow completely different patterns (some are well-hidden behind years of history and the project having gone through dark ages). And some customers wouldn’t allow me to import any tools into their library, so I have to use what the product offers.

      I must admit I never used GoodStart tools, but have heard good things abut them several times.

      The fact that there are so many add-ons and even a dedicated book on envy tells a story: envy is powerful and worth spending time to learn more about it, but its tool support is lacking. Some of that is on Instantiations’ radar, like a new diff browser/merge tool that I am really looking for, but some areas that are not related to a programmer’s daily work are completely out of focus and neither IBM big instantiations has ever devoted any energy to them.

      Maybe that is one of the reasons why he role of the configuration manager and packager in a project is one that everybody wants to avoid… And projects do water lots of energy in that area, accepting that as a given because what’s to be done is so hard…

Comments are closed.