Hi Community,

I would like to share with you my experience regarding  to debugging via Atelier.

I'm developing a REST API and would like to attach to a process when I call the API via a REST Client tool, for example Postman. The purpose is to inspect values from HEADER and BODY of the HTTP request during the debugging process.

Come on! How am I doing? I am going to demonstrate that by using a class from SAMPLES namespace.

1 - Open Atelier;

2 - Open your REST Service class;

3 - Go to the method related to the URI that you need to debug;

AtScale pulls data from the IRIS database. 

The AtScale product forms a virtual OLAP cube on the intermediate layer, which external applications can access using standard SQL and MDX (Multidimensional Expressions) languages. The solution includes three main components.

Continuing to  observe the possibilities of Django, and usage with IRIS. The first we have looked how to define models and connect to tables already existing in IRIS, than we extended embedded Django Administration portal, with an ability to see what data we have in that models, with filters, editing and even pagination.

Time to go to real action, now we a going to create some REST API, on Django, based on the same data, we used before from the package posts-and-tags.

To do so, we will use Django REST Framework

Django REST framework is a powerful and flexible toolkit for building Web APIs.

Some reasons you might want to use REST framework:

• The Web browsable API is a huge usability win for your developers.
• Authentication policies including packages for OAuth1a and OAuth2.
• Serialization that supports both ORM and non-ORM data sources.
• Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
• Extensive documentation, and great community support.
• Used and trusted by internationally recognised companies including Mozilla, Red Hat, Heroku, and Eventbrite.

Your application is deployed and everything is running fine. Great, hi-five! Then out of the blue the phone starts to ring off the hook – it’s users complaining that the application is sometimes ‘slow’. But what does that mean? Sometimes? What tools do you have and what statistics should you be looking at to find and resolve this slowness? Is your system infrastructure up to the task of the user load? What infrastructure design questions should you have asked before you went into production? How can you capacity plan for new hardware with confidence and without over-spec'ing? How can you stop the phone ringing? How could you have stopped it ringing in the first place?

In the first part, I've shown how to start a new project on Django, as well as define new models and add already existing models.

This time, I'll introduce an admin panel, available out of the box and how it can be useful.

Important note: do not expect that if you try to repeat actions from this post it will work for you, it does not. During the article, I had to do some fixes in the django-iris project, and even in DB-API driver made by InterSystems to fix some issues there as well, and I think this driver is still in development, and we will get more stable driver in future. Let's decide that this article only explains how it could be if we would have all done.

Hi developers! In this article I’m going to explore the use of Iris Python Native API in a specific problem: large strings to store.

Hi Folks,

Before I begin my writing journey here I wish to introduce myself briefly, so that everyone who reads and follows me will get a clear picture.

To start with I did my Bachelors in Physical Sciences, Mathematics and Computer Science were my core subjects. I have 4+ years of experience in HealthCare Revenue Cycle operations including Medical Coding, Billing, AR Collections, Denial Management and Fincial Reconciliation. Also, 2+ years of experience in Data Operations and Analytics, specifically in Python, PowerBI, SQL and MsExcel.

Following this GitHub we will see how the FIX protocol can be implemented easily using IRIS and Python.

If you don't have much time focus on the Send a Quote before the Order part near the end, as it will, in a matter of minute, tell you how to send a Quote Request followed by an Order Request and show you the result from the server, and that in no more than five clicks.

An interesting pattern around unique indices came up recently (in internal discussion re: isc.rest) and I'd like to highlight it for the community.

As a motivating use case: suppose you have a class representing a tree, where each node also has a name, and we want nodes to be unique by name and parent node. We want each root node to have a unique name too. A natural implementation would be:

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!

Hello,

I became aware of Python in the early 2000s when I started automating tasks. Some of our processes utilized python scripts. I never figured it out very well, and we decided to do away with Python because nobody on our team was familiar with it.

You know several languages and wish to share your knowledge with users in different parts of the world who don't speak English?

Now it's your time to shine! 🤩

With our Developer Community, it is easy to link your original article and its translation in a different language (or even ask for a translation).

So let's talk about creating your own translation:

Python has become the most used programming language in the world (source: https://www.tiobe.com/tiobe-index/) and SQL continues to lead the way as a database language. Wouldn't it be great for Python and SQL to work together to deliver new functionality that SQL alone cannot? After all, Python has more than 380,000 published libraries (source: https://pypi.org/) with very interesting capabilities to extend your SQL queries within Python.

Hi! My name is Sergei Sarkisian and I’m creating Angular frontend for more than 7 years working in InterSystems. As the Angular is very popular framework, our developers, customers and partners often choose it as part of the stack for their applications.

I would like to start series of articles which will cover different aspects of Angular: concepts, how-to, best practices, advanced topics and more. This series will target people who already familiar with Angular and wouldn’t cover basic concepts. As I’m in the process of building articles roadmap, I would like to begin with highlighting some important features in most recent Angular release.