Article
· Feb 19, 2016 4m read

Why Atelier? And what about Studio?

I have been meaning to make a post about this topic for a few weeks and the other day an issue came in through the WRC about it so it seems this is a conversation we should be having. I want to begin by taking a few moments to explain "Why Atelier" then we can talk about what this means in the general sense for Studio and Atelier and Caché developers. We have wrestled with what to do with Studio for years. When I moved to Product Management in 2008 this was already a "thing". At the time we could not reach a consensus. Some felt Studio was fine as is. Others wanted to investigate a path forward via the browser. Others felt embracing open source and using a tool like Eclipse was the right path. We all agreed on some basic level to the following must have features:

 

Context sensitive help - ie Intellisense for code completion

Debugging

Integrated Source Control

Refactoring

Platform Independence for the client for at least the major client OS - Windows, Mac, Linux

Code Quality and Code Beautification tooling

 

 

In 2014 we reached a tipping point. Issues with Studio, its perceived quirks and dated interface, were being presented to us by customers as a barrier in hiring and retaining staff, in RAD, and various other problems. Surveying the land at the time certain facts became evident. There is a general consensus that Visual Studio is the "best" IDE. In the next tier are the main Java based IDEs like Intelli-J, NetBeans and Eclipse. The next grouping were the web based ones. In general they had buzz but were sorely deficient in features that matched the requirements above. The end result was a commitment to building a plugin for Eclipse that would be our path to an open source, broadly accepted platform for developing across our entire application stack with one tool. We have been plugging away at this since the middle of 2014 and with 2016.2 we will have the first general release that supports what I call "Phase 1" of Atelier's development cycle. 

 

What is Phase 1? Supporting the general tasks of a "typical" Caché developer. I sit down, sync to source control, open a project, start adding a new class or routine written in COS, compile and test that code and repeat. When finished I can check the code directly back in to my source control repository whether that system is Git, Subversion, Perforce or whatever other tool I am using.

 

Phase 2 will encompass the next workflow we want to cover, that of an Ensemble developer. For that case we need to add wizards to support all the standard Ensemble class extensions for adapters, productions, business operations, services etc. We also need to embed or create editors for working with the various structures currently supported in the EMP - BPL, DTL, HL7 Schemas, Business Rules, etc. This is not an insignificant amount of work and we have already begun these tasks now as we get closer to seeing 2016.2 released.

 

What does this mean for Studio? Well for certain nothing will change in the near future. Until Atelier provides all the functionality in Studio our hands are tied. In 2016.2 you will have options that allow for the installation of both tools. This state will continue to at least the completion of the second phase of Atelier development. After that you will find that a default installation will only install Atelier. Studio is something a user will have to take some action to install. From a strategic point of view Atelier is the future IDE for our core data platforms. We know that there is a large investment in tooling made by customers for Studio, and also familiarity with the environment. We have no intention of taking it away from you if you wish to continue working with Studio. But from our perspective it is a product that is moving in to maintenance. We will not be adding new features to Studio. We will continue to correct major faults if they come up but minor annoyances may not be addressed if the resources required for correcting them are seen as outweighing the benefit of a product that is not under active development. We will certify that Studio continues to run on new releases of Windows for the foreseeable future.

 

I hope you all give Atelier a try in the upcoming months and that you come to see the power and flexibility of the environment. And please remember this is only the beginning. The first battle was to get on to the platform. Winning the war will be when we leverage all the tooling available in the Eclipse eco-system to help make things like Unit Testing, Managing data in addition to schemas, and Code Quality part of a Caché programmer's day to day experience.

Discussion (2)2
Log in or sign up to continue

Also note that Caché developers will be able to choose to use Atelier even if the Caché server is not yet on v2016.2 or a later version. Steps:

  • Use a local installation of v2016.2 integrated with their chosen source control system to edit classes and routines.
  • Use Atelier’s export feature to export the file(s) to our standard XML format, and import those files on the Caché server.

Each developer can choose between familiarity with Studio and easy integration with the server (with perhaps no integration with source control), or familiarity with Eclipse and easy integration with source control (with an extra step or two to integrate with the Caché server).

If you're planning to develop on a later version than you deploy onto, beware the occasional gotcha. For example http://docs.intersystems.com/ens20151/csp/docbook/DocBook.UI.Page.cls?KEY=EGRN_compatibility#EGRN_compatibility_hl7schemas identifies an issue with trying to import a 2014.1+ schema into a pre-2014.1 environment. I have seen at least one Ensemble site mangle their production by exporting a schema from 2014.1 or later and then importing it into an earlier version.