could you please give a little more of a description as to what you are hoping to accomplish? A JS file will be executed on the client, where-as "Caché Code" (by this I assume you mean Object Script?) is executed on the server.
You can edit JS files using Studio, you can create object script class projections to automatically create JS files with JS logic in it, you can send JS from a server process to the web browser, etc - there are may ways for Caché Code to interact with, inform or manipulate JS files. We need more details for what you want to do.
Per your second question, best practice is generally to use System Defaults which are set in your Namespace and store the production settings (rather than storing them in the Production class). This allows you to prevent having to have differences in the Production class between branches.
Steve - #2 is helpful if you want to leverage existing structures for authentication, auditing, transport or other functions that rely on CSP sessions . This can be used as part of a strategy of incrementally moving an application from a CSP-based architecture to Angular.
If your machine is virtualized, just clone the VM (that is what we do for all of our test upgrades). NOTE - make sure to stand it up on an isolated network segment so that it doesn't try to do any inbound file processing or other communication that it should not (especially if you clone LIVE).
Thanks again for sharing the start of your journey with the Community. I am curious if you are planning to provide another Update Article? I would love to hear about how your journey has progressed over the past year and what you have learned along the way which could help others!
Exactly! We are actively using it internally within InterSystems - both in internal application development, and in HealthShare product development. As discussed in the video we have found incredible value in this tool for decreasing technical debt (and making sure new changes don't add to it). We thought customers might find the value in it as well.
You are most welcome. In terms of why TestCoverage was released on OpenExchange, it is something we have been exploring internally last year and wanted to share with the Community in time for Global Summit 2018. In terms of whether or not it will actually make it into product, I can't speak to that but perhaps the author @Timothy Leavitt can comment on that (I believe there were at least exploratory discussions with Product Management on this topic).
The first half of that should be helpful. Code coverage may be helpful too if they are able to move into a CI type BUILD infrastructure (I don't know how well Test Coverage would work in a more dynamic Dev environment as longitudinal history might be harder to maintain ... haven't really thought about that too much before...)
We're using UnitTesting for application validation for internal application development within InterSystems. If you have any specific questions, feel free to create new Questions in the D.C. and tag me, or if you would prefer a general discussion you can ask your Account Manager or Sales Engineer to set up a discussion with me.
There have also been several Global Summit presentations which have touched on the topic - not sure if you've seen these?
Sorry - I forgot that you first need to specify the source control class in the Management Portal. Put "Source Control" in the Search box on the SMP homepage, and then go to that page (e.g. http://localhost:57772/csp/sys/mgr/%25CSP.UI.Portal.SourceControl.zen). Select the Namespace in the left column and then "%Studio.SourceControl.ISC". Save the changes and try the BaselineExport() again. When you are done with the export, change the Source Control back to "None"
As a general tip, if you do enable and enforce source control, then you wouldn't need to be querying your class definitions to find variations between environments - you could see all of that (and so much more!) in your source control system ;)
could you please give a little more of a description as to what you are hoping to accomplish? A JS file will be executed on the client, where-as "Caché Code" (by this I assume you mean Object Script?) is executed on the server.
You can edit JS files using Studio, you can create object script class projections to automatically create JS files with JS logic in it, you can send JS from a server process to the web browser, etc - there are may ways for Caché Code to interact with, inform or manipulate JS files. We need more details for what you want to do.
Per your second question, best practice is generally to use System Defaults which are set in your Namespace and store the production settings (rather than storing them in the Production class). This allows you to prevent having to have differences in the Production class between branches.
Steve - #2 is helpful if you want to leverage existing structures for authentication, auditing, transport or other functions that rely on CSP sessions . This can be used as part of a strategy of incrementally moving an application from a CSP-based architecture to Angular.
If your machine is virtualized, just clone the VM (that is what we do for all of our test upgrades). NOTE - make sure to stand it up on an isolated network segment so that it doesn't try to do any inbound file processing or other communication that it should not (especially if you clone LIVE).
@Peter Cooper
Thanks again for sharing the start of your journey with the Community. I am curious if you are planning to provide another Update Article? I would love to hear about how your journey has progressed over the past year and what you have learned along the way which could help others!
Cheers,
Ben
Exactly! We are actively using it internally within InterSystems - both in internal application development, and in HealthShare product development. As discussed in the video we have found incredible value in this tool for decreasing technical debt (and making sure new changes don't add to it). We thought customers might find the value in it as well.
@Mike Davidovich
You are most welcome. In terms of why TestCoverage was released on OpenExchange, it is something we have been exploring internally last year and wanted to share with the Community in time for Global Summit 2018. In terms of whether or not it will actually make it into product, I can't speak to that but perhaps the author @Timothy Leavitt can comment on that (I believe there were at least exploratory discussions with Product Management on this topic).
The first half of that should be helpful. Code coverage may be helpful too if they are able to move into a CI type BUILD infrastructure (I don't know how well Test Coverage would work in a more dynamic Dev environment as longitudinal history might be harder to maintain ... haven't really thought about that too much before...)
Mike,
We're using UnitTesting for application validation for internal application development within InterSystems. If you have any specific questions, feel free to create new Questions in the D.C. and tag me, or if you would prefer a general discussion you can ask your Account Manager or Sales Engineer to set up a discussion with me.
There have also been several Global Summit presentations which have touched on the topic - not sure if you've seen these?
Best,
Ben Spead
Manager, AppServices, InterSystems
Sorry - I forgot that you first need to specify the source control class in the Management Portal. Put "Source Control" in the Search box on the SMP homepage, and then go to that page (e.g. http://localhost:57772/csp/sys/mgr/%25CSP.UI.Portal.SourceControl.zen). Select the Namespace in the left column and then "%Studio.SourceControl.ISC". Save the changes and try the BaselineExport() again. When you are done with the export, change the Source Control back to "None"
As a general tip, if you do enable and enforce source control, then you wouldn't need to be querying your class definitions to find variations between environments - you could see all of that (and so much more!) in your source control system ;)