I just saw this new posting by Mike Kadow on the "Caché, Ensemble, DeepSee" Google Group announcing the availability of his new book, "Caché and MUMPS - Part II"
There's also more information about it at his site http://www.cosmumps.org/
If your Ensemble environment is actually a HealthShare one, here's a snippet of information that I wasn't able to find in the documentation.
When a namespace is HealthShare-enabled it gets some mappings added to it in order to fetch stuff from the HSLIB database. The most obvious mapping is a package mapping that gives your namespace all the HS.* classes.
Far less obvious is that your namespace will also be fetching/filing Test.* classes from the HSLIB database. So if you thought that, say, Test.
When developing or maintaining Caché Objects applications, or even ones written in plain COS code, it's sometimes useful to investigate dependencies. Yuzinji is a tool that analyzes the Caché class dictionary plus the COS code within methods and routines, then feeds its results into Structure101g Studio.
By doing this it becomes easy to ask questions such as "Who uses this piece of code?", getting the information in a format that is easy to explore further. For example, I recently analyzed all the packages in the SAMPLES namespace of the 2016.
When my COS code is executing in a Caché process it might want to interact with the host operating system. For the purpose of this post I'm focusing on a Windows host, but much of it applies to other host OS platforms as well.
A common example of host OS interaction is when my process wants to read from or write to a file. What credentials will apply when Windows is checking whether or not to allow me access to the file?
To answer that we need to consider another question. How did our process start?
If you've got more than one developer on a project, do you each work in your own namespace? Or do you all use a common namespace?
Through my work at George James Software I have encountered many different Caché and Ensemble development setups. At risk of over-generalizing, the older and more established users of InterSystems technologies seem more likely to have all their developers working in a common namespace, whereas the newer 'converts' tend to favour giving each developer their own namespace.
There's plenty of goodness in the %-packages InterSystems supplies, and it seems that every new version of Caché brings something new. The browser-based class documentation (a.k.a. Documatic) generally provides a good level of information, but on the basis that "a picture is worth a thousand words" I sometimes want a diagram.
For example, when trying to navigate the %Dictionary package for a project that needed to find out about class definitions, here's one of the UML class diagrams I created.
It was generated from a 2008.
The purpose of this post is to raise the profile of a powerful mechanism that has long been available to us, and to open a discussion about ways in which it can be used or abused.
You can read more detail about the mechanism here. To summarize, your class definition can use the Projection keyword to reference one or more projection classes. A projection class can implement methods that get invoked at key points in the lifecycle of your class.
A projection class must extend %Projection.AbstractProjection
Announcing Deltanji 6.0, the latest version of the well-respected George James Software source control product formerly known as VC/m.
Deltanji comes in four editions, including Solo which is quick to install on Caché or Ensemble (2009.1 or later), easy to get started with, and perpetually free.
Deltanji runs within the environment whose code it is managing, integrating closely with Studio and Portal, and storing code versions in a CACHE.DAT database.
Please visit http://georgejames.com/deltanji to learn more and download the software.