#Caché

In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:

• Git 101
• Git flow (development process)
• GitLab installation
• GitLab Workflow
• Continuous Delivery
• GitLab installation and configuration
• GitLab CI/CD
• Why containers?
• GitLab CI/CD using containers

In the first article, we covered Git basics, why a high-level understanding of Git concepts is important for modern software development, and how Git can be used to develop software.

In the second article, we covered GitLab Workflow - a complete software life cycle process and Continuous Delivery.

In the third article, we covered GitLab installation and configuration and connecting your environments to GitLab

In the fourth article, we wrote a CD configuration.

In this article, let's talk about containers and how (and why) they can be used.

At the end of our last lesson, we ended with our page displaying a nice (but garish) Angular Material Toolbar, and our Widget data displaying in a list of Material cards. Our page feels a bit static, and we already know that the large number of Widgets that we will be dealing with will not be especially usable on a static list. What can we do to help?

How would you like to be able to access the Web Terminal directly from your VSCode?

This 'feature' have been around for a long time, but I don't see any articles on it so I thought I would make everyone aware.

As many of you, our partners, are more widely using modern UI frameworks to create client front-end, you may have encountered a question, "So how do I secure my data when I just finished developing all new fancy browser based client experience?"

The answer is easy. Use a standard, proven OAuth2 and OpenID!

"OK, but how can I do it? I have never done it before."

No problem, just have a look here, if your client is Angular (not AngularJS) based, there is a demo project available for you to review and get inspired!

I bet that not everyone familiar with InterSystems Caché knows about Studio extensions for working with the source code. You can actually use the Studio to create your own type of source code, compile it into interpretable (INT) and object code, and sometimes even add code completion support. That is, theoretically, you can make the Studio support any programming language that will be executed by the DBMS just as well as Caché ObjectScript. In this article, I will give you a simple example of writing programs in Caché Studio using a language that resembles JavaScript. If you are interested, please read along.

Introduction and Motivation

A unit of ObjectScript code (a ClassMethod, say) may produce a variety of unexpected side effects by interacting with parts of the system outside of its own scope and not properly cleaning up. As a non-exhaustive list, these include:

XDATA is used for a whole host of ISC libraries to store things like Zen pages, BPL logic and DTL transformations.

XDATA is the equivalent of XML config files of the JAVA world and JSON config files of the JavaScript / NPM world.

Whilst Atelier looks to shift source code to the disk, XDATA will remain a key component to source control our projects config / meta data.

I was searching for the most simple way to connect from visual studio code to my local instance via terminal without having to change any window.

I know this can also be achieved via telnet but seems a bit overhead if you're in your local machine.

For me the simplest sollution is to open a terminal window in VS Code, navigate to the /bin folder of your instance installation and run .\csession.exe INSTANCENAME

For simplicity you can just include your /bin folder in your path so you don't even need to navigate there

It was my answer to the question appeared in GoogleGroups. And when I answered there I figured out that it might worth to post an article and to add some light on how Unicode is stored in Caché.

The attached file contains two $system.Event examples that processes work asynchronously using persistent queues:

• Events_Simple.prj.xml
• Events_PubSub.prj.xml - updated this example has been published on https://github.com/intersystems-ib/cache-iat-pubsub

Events_Simple

This is a very basic example that creates some worker processes and then enqueue messages to them using $system.Event.

Have you ever thought why the code that you write in Caché Object Script is exported to an XML file?

Hi,

this is a public announcement for the first release of Intersystems Cache Object-Relational Mapper in Python 3. Project's main repository is located at Github (healiseu/IntersystemsCacheORM).

About the project

CacheORM module is an enhanced OOP porting of Intersystems Cache-Python binding. There are three classes implemented:

• CacheClient This is the super class of CachePython module. It wraps two functions from intersys.pythonbind module pythonbind3.connection() and pythonbind3.database().

• CacheQuery A subclass of CacheClient that wraps methods and adds extra functionality in intersys.pythonbind.databaseand intersys.pythonbind.query classes

• CacheClass A subclass of CacheClient, that wraps methods and adds extra functionality in intersys.pythonbind.databaseand intersys.pythonbind.object classes

The intersys.pythonbind package is a Python C extension that provides Python application with transparent connectivity to the objects stored in the Caché database.