Summer is coming to an end, and we’re sure you had plenty of highlights! ✨

Maybe you learned something valuable, got yourself a reward on Global Masters, or even joined READY 2025 🎉

Here’s a quick checklist — but you can, of course, share anything else about your summer in the comments. Photos are more than welcome 📸

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.

A Minute Of Laughter on the Developer Community with #InterSystemsMemes.

Which one did you like the most? Let us know in the comments!

1. Meme author: @Kurro Lopez

Hello community,

First of all thanks for reading this post:

Because of you are more experienced, pragmatic, and have a lot of knowledge and good know-how; please consider to read and answer some question, if you would like:

Why did you choose to become a software engineer / developer?

How and when did you start to generate a "flow state of mind" during your career?

Hi everybody!

Many developers prefer a dark version of applications. Not surprisingly, @Guillaume Rongier posted an idea of making a dark version for the Developer Community.

So we look forward to hearing from you.

Please send us your feedback by using this Poll on the Ideas Portal, and by voting and commenting on the relevant idea.

Thank you in advance for your votes and have a good day!

Hi Interoperability experts!

Recently noticed an interesting conceptual discussion in our Interoperability Discord channel to which I want to give more exposure.

All we know that typical InterSystems Interoperability production consists of the following chain:

Inbound adapter->Business Service->Business Process->Business Operation->Outbound adapter.

And Business Process (BO) here is always considered as a passive "listener" either on port/folder/rest API for an incoming data.

Work Queue Manager (WQM) is a feature of InterSystems IRIS that enables you to improve performance by distributing work to multiple concurrent processes programmatically. The idea is that you split the work into chunks, and WQM distributes the chunks across worker processes and can provide the info that the work is done.

However, recently, I got an interesting question: there's a large logical transaction composed of ~1,000,000 individual objects and SQL inserts and updates. Some updates are CPU-intensive, so the original idea was to use WQM to split an update into chunks to speed things up.

But, here's a catch: if one of the individual 1,000,000 changes fails (there's a variety of application-level checks so that it can fail, and that's not even that abnormal a behavior), the entire transaction must be rolled back. That creates a problem: each chunk must report success before committing their individual transactions, and someone must get all these reports and decide if we are committing or not.

Unfortunately, it looks like WQM does not have a bidirectional communication between workers and manager, so I suggested an approach using events:

1. Start jobs.
2. Wait for all jobs to report success using $System.Event.WaitMsg().
3. Send Commit or Rollback using the $System.Event.Signal().

Let's imagine you have to implement a method with a definition

/// Set value to %session.Data
ClassMethod setValue(params...) As %Status
{
}

How it should work

do ..setValue("key1", "val")

is equal to

set %session.Data("key1") = "val"

and

do ..setValue("key1", "key2", "key3", "key4", "val")

is equal to

Hi Developers!

Thank you for using ZPM Package Manager and contributing more and more useful packages to the public registry!

But as you already aware ZPM packages are always deployed with source code.

Do you think we need to add the option to deploy without source code - e.g. if you want to deploy a commercial package?

Will you develop commercial modules if there will be an option and deploy it with ZPM?

How do you deploy commercial applications today?

Images for other languages are often build using multistage build process.

What about InterSystems IRIS?

Consider this Dockerfile:

FROM irishealth-community:2020.4.0.524.0 AS builder

# Load code into USER and compile
# Adjust settings, etc.

FROM irishealth-community:2020.4.0.524.0

# replace in standard kit with what we modified in first stage

COPY --from=builder /usr/irissys/iris.cpf /usr/irissys/.
COPY --from=builder /usr/irissys/mgr/IRIS.DAT /usr/irissys/mgr/.
COPY --from=builder /usr/irissys/mgr/user/IRIS.DAT /usr/irissys/mgr/user/.

The advantage of this approach is the image size.
The disadvantage is that on a final stage developer must know/remember all the modified places in the builder image.

But otherwise is this approach OK for InterSystems IRIS?
Have anyone tried to build IRIS images this way?

Hi All,

I am preparing for InterSystems IRIS Core Solutions Developer Specialist Certification. I have completed the desired syllabus. Does anyone have any questions dumps. I have already completed the practice paper on Intersystems website.

What does everyone think about submitting an issue in a repository and then submitting a pull request to fix that issue. Is it an unnecessary step or does it give extra context and logging for the issue? I ask this because when I find a bug in an Open Exchange app, I always submit the Issue and then often submit a Pull Request to fix the issue.

I think that if the repository owner doesn't like your suggested fix, it is helpful to have the issue around so that they can deny the pull request and potentially implement their own change for the issue.

For standalone installations I always recommended to use custom namespaces and not the USER namespace.

However, what about Docker?

In many Dockerfiles I see the creation of additional namespace, but why, if only one namespace is required?

What do you think?

Currently, the SQL privileges (SELECT, INSERT, UPDATE, DELETE) are managed at the tables level, which can be very tedious when you have to administer many roles in an organization, and need to keep them sync with a constantly evolving data models.
By managing privileges at the schemas level, will allow to give SELECT and other DML privileges to *all* or *several schemas* to a role|user, fixing the need to manually synchronize the new tables|views to the roles.