An integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development.
The official IDE for InterSystems Data Platform products is Atelier.
I'm in the process of trying to convert my team to a Git-based workflow for source code version management (we use Ensemble and HealthShare, but build a lot of customizations on top). We are having a hard time working with Atelier in this regard for a few reasons:
Trying to evaluate it and work out how we could use it.
As a standard application database. Object or relational etc. does not matter.
Issue is ObjectScript.
So:
1) Can we develop, maintain and use an IRIS database and never use ObjectScript i.e. use only Java, Python, C++ interfaces etc. (exactly which one does not matter)? Would that make designing and using the IRIS database more prone to inefficiency and error?
offers the latest features and bug fixes. It now updates your installation of Atelier to build 1.1.291 for Mac, Windows, Red Hat and SUSE. Here’s an account of what’s recently been improved:
We at George James Software are pleased to announce the release of version 2.6 of Serenji, our editor and debugger for Caché, Ensemble and HealthShare.
The main enhancement in 2.6 is the ability to run on a Linux <edit> or OS X </edit> workstation using Wine 1.8. More release details are here.
This article is one of the series which introduces Eclipse to experienced Caché/ Ensemble/ HealthShare users. The goal is to open the perspective of a developer who was using Caché Studio for years and make Her/ Him see deeply into the Eclipse world – far beyond Atelier. In other words it is an Atelier (Eclipse IDE for InterSystems technology) beginner’s guide. This time the topic is: editing XML files using Atelier.
In response to a comment on his posting about source control hooks and Atelier Bill McCormick used the example of Studio's SOAP Wizard and talked about providing more information about how Atelier will support this kind of extension.
My Atelier (1.0.116) has a Tools menu with an Add-Ins option and a "Soap Wizard" (sic) submenu.
Is there any information available to us yet about how we can add our own add-ins of this kind?
We at George James Software recently released a new version of Deltanji, the native source code management tool for Caché, Ensemble and HealthShare.
Version 6.1 includes several enhancements, including easy creation of labels. Bulk transfer of large codesets is also now available from the browser UI.
A perpetually free "install and go" Solo Edition of Deltanji is available. Licenses can be purchased for other editions that provide more advanced code management and deployment features.
Deltanji is compatible with Atelier. It can also manage external files.
I have a question on working with dev and prod environments.
After project is ready and signed, I usually migrate outcome to production using the export tool from the studio.
For changes/adding to existing projects, I exclude the production class (as it has some different values differing the dev from the live) and I add the differences manually afterwards.
My questions on migrating are:
Does anyone has (to share) his/her best practice steps on "migrating dev to prod"?
In Atelier when resolving conflicts with the server the screen shows the Local copy and Server copy and the differences, but depending on where the difference is you cannot tell what what the document is, you need to scroll to the top to see what it is before deciding what to do. It should indicate the class or routine name beside "Conflicting Server documents"
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.
Looking for advice on best practise (or at least reasonable approaches) for handling the Production class when utilising source control. (And perhaps wider advice around deployment.)
I want to grant access to view the Error Trap in System Management Portal to certain admins, without giving them access to anything that would alter Caché behavior, such as users or database sizes. I was looking for a granular Resource that would do this, but haven't been able to find what I'm looking for.
If you're connecting to a local server and doing isolated development with a throwaway account, just store your password in plain text in the settings.json configuration file. But if you're working with a shared server using a "real" user account, it's a good idea to protect that information.
We have a bunch of templates on OEX that provide a handy foundation for building a particular application with IRIS. And the basic principle of each and every template is that we take vanilla IRIS images, load code, and files into the image using Dockerfile, and create a new docker image as a solution. And then we develop running this image and rebuilding it when returning to development.
Some developers ask me why we need to build the docker image to work with the code. Indeed, if at the end of the day I need to develop a ZPM package and not a docker image why don't run the vanilla image and load the code and everything in it?
The problem I have with the building image approach is that often I can wait a lot to build an image and it fails on some Objectscript problem in the source that I cannot fix as the image is not building. and
Very recently Docker showed a very new feature added to their Docker Desktop tool. It was a good way to start using Docker on macOS and Windows, and they also released the same tool for Linux as well. And new feature Extensions add an ability to extend this GUI application with some extra abilities from extensions.
By update
Open Exchange app.png)