go to post Ben Spead · Sep 5, 2017 The following article (and it's ensuing discussion) may also be of interest to everyone:https://community.intersystems.com/post/studio-tip-running-cos-commands-...HTH,Ben
go to post Ben Spead · Sep 2, 2017 A colleague pointed out another option which is fairly complete already:https://github.com/intersystems-ib/cache-git-studioI played with it and would recommend it!
go to post Ben Spead · Sep 2, 2017 Please make sure to mark a response as an accepted answer once you are all set - it makes it helpful for others looking for an answer and prevents the 'unanswered' list from including things which have been resolved.Thanks!
go to post Ben Spead · Aug 31, 2017 w $system.Version.GetNumber() will get you just the version number string
go to post Ben Spead · Aug 30, 2017 Joel - the first paragraph says that eGit is installed with Atelier automatically but Nicole has confirmed that this is not the case. Could you please edit the article and remove that statement?Thanks!Ben
go to post Ben Spead · Aug 30, 2017 Thank you - I will take a close look!How does Port.SourceControl.Extension.VCS relate to %Studio.SourceControl.Base? None of the method names match so I am guessing that it doesn't extend it. Would there be a different handling class extending the Source Control Base class which calls the method in your Git class?
go to post Ben Spead · Aug 29, 2017 Thank you Rubens - that is very helpful! Could you please also post a Gist for Port.SourceControl.Extension.VCS?
go to post Ben Spead · Aug 23, 2017 There is a huge benefit from two perspectives:- If you need to refresh data in your Dev or Test environment, you can just grab the globals DB from Live and drop it in and not worry about overwriting any code in Dev or Test- If you choose to deploy your code via a DB drop, you can drop in a new DB to replace the existing routines DBNOTE - for either of these to work, you may need to map configuration into the routines DB (so you don't bring back Live config into Dev for instance)HTH!Ben
go to post Ben Spead · Aug 8, 2017 Robert - thanks for posting, and it's great seeing that you're still doing awesome work in this space!All the best,Ben
go to post Ben Spead · Aug 8, 2017 FYI ... we will have several sessions covering this topic at the Global Summit - attend if you can, otherwise check out the material afterwards!For internal application development within InterSystems we use a variety of approaches, but the most common is as follows:1) We use an internally developed issue tracking system, but we plan to eventually migrate to JIRA2) We use Perforce for all of our source control 3) We have BASE, TEST and LIVE environments for every application, typically BASE and TEST being cloned from VM snapshots of LIVE. In addition to the Shared BASE VM, for those applications which are undergoing the highest rate of change, developers will create a local copy of the application to do their development work. Some apps have all changes being developed on Shared BASE and the changes are progressed (via our Change Control tool) to TEST and the LIVE. For applications where developers use Private BASEs, they commit there and then push the changes to Shared BASE and then to TEST and LIVE.Feel free to ask questions (here or at Global Summit)!Thanks for asking.
go to post Ben Spead · May 30, 2017 If you are going to be writing any JSON code in 2016.1, then these guidelines may save you a lot of time later:https://community.intersystems.com/post/writing-forward-compatible-json-...
go to post Ben Spead · May 30, 2017 Thanks Lexi! That is covered in the last point of this article as well: https://community.intersystems.com/post/writing-forward-compatible-json-...
go to post Ben Spead · May 22, 2017 Yes of course :) Once you create a library of unittests you can script them to run automatically. If you are using a continuous integration / build server then you can script the tests to run after the build has completed successfully. We have some teams using Jenkins for this.
go to post Ben Spead · May 9, 2017 John,If you haven't already done so, please contact the WRC to let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers).Thanks,Ben
go to post Ben Spead · May 9, 2017 John - if you haven't already done so, please contact the WRC and let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers)
go to post Ben Spead · May 5, 2017 Jennifer - Angular 2 is not supported by Angular Material. By picking Angular 1.x Chris was able to demonstrate the stack selection that we're using for many internal applications as well as what many of our large customers are using (REST+AngularJS 1.x + Angular Material).
go to post Ben Spead · May 4, 2017 Brendan - I think you are missing a ( in: do file.WriteLine(^Global1key))
go to post Ben Spead · Apr 26, 2017 Pravin - nice article, thank you.You might want to add "... using Extended Global Reference" to your Title (to make it easier to find in a search) and include a link to the documentation on that:http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=... Thanks for contributing :)
go to post Ben Spead · Apr 20, 2017 Kyle,The macros are intended to prevent developers from having to refactor code at the same time as they perform an upgrade, as well as make it easier for application providers who have code running on a number of versions.I've learned from experience that it is always best to have the fewest moving parts when possible when doing an upgrade so you can quickly find the cause of any issues that pop up. Therefore, I always try to write forward compatible code and only after all of my systems for a given codebase have been upgraded and are stable do I start to introduce backwards incompatible changes. These macros allow that very nicely. In addition, using the macros means that you have more flexibility to upgrade without having to schedule a concurrent refactoring project (even if it is just a find and replace refactoring project :) ).All that being said, the macros are not intended for long-term use with-in an application. Once the 2016.1 > 2016.2 hurdle has been cleared then my recommendation would be to pull out the macros (find & replace) and stick with Caché's native JSON access going forward. But that can then be a project that takes place post-upgrade, thus simplifying the upgrade and lowering risk.
