Hello everyone,

I was first introduced to TDD almost 9 year ago, and I immediately fell in love with it.
Nowadays it's become very popular but, unfortunately, I see that many companies don't use it. Moreover, many developers don't even know what it is exactly or how to use it, mainly beginners.

InterSystems IRIS 2019.1 has been out for a while and I would like to cover some enhancements for handling JSON which might have gone unnoticed. Dealing with JSON as a serialization format is an important part of building modern applications, especially when you interact with REST endpoints.

There are often questions surrounding the ideal Apache HTTPD Web Server configuration for HealthShare. The contents of this article will outline the initial recommended web server configuration for any HealthShare product.

As a starting point, Apache HTTPD version 2.4.x (64-bit) is recommended. Earlier versions such as 2.2.x are available, however version 2.2 is not recommended for performance and scalability of HealthShare.

Hi Community!

I have very good news for the developers, who are using GitHub to host projects with InterSystems ObjectScript. GitHub introduced the support of InterSystems ObjectScript this week!

How does it work?

Now all the .cls files in your repository are considered as InterSystems ObjectScript and highlighted according to the language rules of ObjectScript. For example WebTerminal, Samples-Data.

As you might have heard, we just introduced the InterSystems API Manager (IAM); a new feature of the InterSystems IRIS Data Platform™, enabling you to monitor, control and govern traffic to and from web-based APIs within your IT infrastructure. In case you missed it, here is the link to the announcement.

In this article, I will show you how to set up IAM and highlight some of the many capabilities IAM allows you to leverage.

A good writer is supposed to draw you in with the title and bury the answer somewhere in the article. I suppose this makes me a bad writer – don’t think less of me, my whole feeling of self-worth comes from the opinions of internet strangers!

There's an easy new way to add certificate authority (CA) certificates to your SSL/TLS configurations on InterSystems IRIS 2019.1 (and 2018.1.2) on Windows and Mac. You can ask IRIS to use the operating system's certificate store by entering:

%OSCertificateStore

in the field for "File containing Trusted Certificate Authority X.509 certificate(s)". Here's an image of how to do this in the portal:

Other Sync-Tools just work from Caché/IRIS to Caché/IRIS.
Synchronizing your data to some external DB requires some other solution.

The solution is available in Caché/IRIS since quite some time and works excellent.
^OBJ.DSTIME does the magic.
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=D2IMP_ch_current#D2IMP_C23869

Hi Developers!

Often when we develop some library, tool, package, whatever on InterSystems ObjectScript we have a question, how we deploy this package on the target machine?

Also, we often expect that some other libraries already installed, so our package depends on them, and often on some particular version of it.

When you code on javascript, python, etc the role of packages deployment with dependency management takes package manager.

So, I'm pleased to announce that InterSystems ObjectScript Package Manager available!

This example is extracted from a long-running installation.
The purpose is to have simple monitoring of several servers at a rather primitive level.
Just slightly more intelligent than a raw PING. But still easy to integrate.
It avoids the overkill of information you are often confronted with while you are just
interested in the number of active processes or similar basic figures.
The example shows a basic skeleton that might be easily filled by your real needs.

It consists of 3 sections:

Hi, everyone!

I want to share a personal project that started with a simple request at work:

Is it's possible to know how many Caché licenses we are using?

Reading other articles here in the community, I found this excellent article by David Loveluck

In this article, I would like to talk about the spec-first approach to REST API development.

While traditional code-first REST API development goes like this:

• Writing code
• REST-enabling it
• Documenting it (as a REST API)

Spec-first follows the same steps but reverse. We start with a spec, also doubling as documentation, generate a boilerplate REST app from that and finally write some business logic.

This is advantageous because:

• You always have relevant and useful documentation for external or frontend developers who want to use your REST API
• Specification created in OAS (Swagger) can be imported into a variety of tools allowing editing, client generation, API Management, Unit Testing and automation or simplification of many other tasks
• Improved API architecture. In code-first approach, API is developed method by method so a developer can easily lose track of the overall API architecture, however with the spec-first developer is forced to interact with an API from the position if API consumer which usually helps with designing cleaner API architecture
• Faster development - as all boilerplate code is automatically generated you won't have to write it, all that's left is developing business logic.
• Faster feedback loops - consumers can get a view of the API immediately and they can easier offer suggestions simply by modifying the spec

Let's develop our API in a spec-first approach!

Are you all ready for something you wish you knew ages ago (or, in my case, a DECADE ago)? Open up a portal in your favorite instance and go to:

System Administration->Configuration->Additional Settings->Startup

Scroll down to "Terminal Prompt" and click 'Edit'. This allows you to edit what you see on your terminal prompt. You can change that to my current setting: 8,3,2

What does this do? It adds your instance name for your prompt. So now your prompt can look like:

DEVELOPMENT:USER>