So, the next year will bring us a new way of installing IRIS. Always keep in mind that you have to bring your own web server. No matter how many instances of IRIS you have on your local machine. Or if you work in Docker, always keep in mind a bit more complicated configuration.

And I now want to understand the costs of this decision for end-developers like most of here.

7 20
2 498

Hi folks!

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

Any thoughts? How do you develop with docker?

1 4
1 276

In the discussions at one notable topic has been that some Studio users make regular use of its facilities for exporting multiple code artifacts (e.g. classes and routines) into a single XML file on the workstation, then exporting that file into a different server namespace.

3 4
1 254

Good morning, evening, night,... wink

A small reflection/question for today... it's true that new IRIS for Health (I4H) releases are more and more powerful each time regarding FHIR capabilities. Nowadays it allows us to consume FHIR resources with extrem easiness, we can connect with end-points in external FHIR servers very easily and make I4H act as passthrough or consume their resources... or, even more, we can define, configure and run a FHIR repository in, literally, less than 5 minutes.

7 3
0 274

The use of Source Code Control systems in development is important. And there are a few systems known in the world, like GIT, SVN (Subversion), Perforce, Mercurial. Where the most popular nowadays is the git. Using it is very useful in many cases, but mostly it depends on the code as text, which can be compared between commits, branches, or versions of releases and so on.

1 0
0 274

In a healthcare setting we've an Ensemble namespace through which passes a key HL7 feed (the ADT feed from our PAS). It is split up, transformed and passed on to multiple downstream systems. We consider the feed going to each downstream system an interface. Each interface is developed as separately as possible - typically as a separate branch of our git repo (which we access via VS Code).

0 0
0 177