#API

La pandemia que afectó al mundo en 2020 hizo a todo el mundo seguir las noticias y los datos relacionados con la COVID-19. ¿Por qué no aprovechar la oportunidad para crear algo sencillo y fácil de usar, para seguir el número de vacunaciones a nivel mundial?

Hola a todos! Comentamos hoy una entrada de Timothy Leavitt cuyo equipo (Application Services en InterSystems - encargado de desarrollar y mantener muchas de nuestras aplicaciones internas, y proporcionar herramientas y prácticas recomendadas a otras aplicaciones departamentales), durante el último año, se embarcó en un viaje hacia el desarrollo de interfaces de usuario basadas en Angular/REST, para las aplicaciones existentes construidas originalmente con CSP y/o Zen.

¡Hola desarrolladores! Quería compartir hoy un ejemplo muy interesante por parte de Tani Frankel. Se trata de una aplicación sencilla sobre la utilidad SystemPerfomance.

Repasando nuestra documentación sobre la rutina de monitorización ^SystemPerformance (conocida como ^pButtons en versiones anteriores a IRIS), un cliente me dijo «Entiendo todo esto pero ojalá fuese más simple, más sencillo para definir perfiles y gestionarlos, etc.».

Entonces pensé que sería interesante como ejercicio facilitar una pequeña interfaz para hacer esas tareas más sencillas.

El primer paso era envolver en una API basada en clases la rutina actual de ^SystemPerformance.

Hola Comunidad!!

Acabo de subir mi última aplicación "IRIS Api Tester" al Open Exchange.

Es un proyecto docker con InterSystems IRIS + Newman que permite lanzar test sobre tus colecciones de Postman de una manera rápida y fácil.

El proyecto viene listo para funcionar, solo debes clonar el repositorio: https://github.com/daniel-aguilar-garcia/irisapitester

Arrancar el fichero docker-compose:

Existen numerosas herramientas excelentes para probar vuestras APIs REST, especialmente cuando están en funcionamiento. Postman, distintas extensiones de navegador e incluso código personalizado en ObjectScript usando objetos %Net.HttpRequest pueden hacer el trabajo. Sin embargo, a menudo resulta complicado probar únicamente la API REST sin involucrar, sin querer, el esquema de autenticación, la configuración de la aplicación web o incluso la conectividad de red. Son muchos obstáculos solo para probar el código dentro de vuestra clase dispatch.

La buena noticia es que, si nos tomamos el tiempo para comprender cómo funciona internamente la clase %CSP.REST, encontraremos una alternativa que permite probar únicamente el contenido de la clase dispatch. Podemos configurar los objetos de request y response para invocar los métodos directamente.

En este artículo, me gustaría hablar sobre el enfoque spec-first para el desarrollo de una API REST.

Mientras que el desarrollo tradicional code-first de una API REST es así:

• Escribir el código
• Habilitarlo en REST
• Documentarlo (como una API REST)

Spec-first sigue los mismos pasos, pero a la inversa. Comenzamos con una especificación, — que también actúa como documentación — , generamos el código base de la aplicación REST a partir de ella, y finalmente escribimos la lógica de negocio concreta que nos haga falta.

Esto ofrece varias ventajas:

¡Hola a todos!

Hoy instalaremos Jupyter Notebook y vamos a conectarlo con Apache Spark e InterSystems IRIS.

Nota: Los siguientes procedimientos los hice en Ubuntu 18.04 y Python 3.6.5.

Introducción

Si estás buscando un bloc de notas que sea reconocido, difundido ampliamente y muy popular entre los usuarios de Python, en lugar de utilizar Apache Zeppelin, deberías elegir Jupyter notebook. Jupyter notebook es una excelente y muy poderosa herramienta para la "ciencia de datos", que cuenta con una comunidad muy grande, además de muchas funciones y software adicional. Jupyter notebook permite crear y compartir documentos que contienen código en tiempo real, ecuaciones, visualizaciones y texto narrativo. Sus aplicaciones incluyen la limpieza y transformación de los datos, simulaciones numéricas, modelamiento estadístico, visualización de datos, machine learning y muchas funciones más. Y lo más importante, existe una gran comunidad que ayuda a resolver los problemas que surjan.

A continuación veremos cómo mostrar una lista de métricas de ejemplo disponibles a través del servicio /api/monitor.

En el artículo anterior, echamos un vistazo al servicio que expone las métricas de IRIS en formato Prometheus. Veamos cómo configurar y ejecutar IRIS preview release 2019.4 en un contenedor y listar las métricas disponibles.

En este artículo, discutiré el uso de un LLM alternativo para la IA generativa. OpenAI es comúnmente utilizado, pero en este artículo os mostraré cómo usarlo y las ventajas de utilizar Ollama.

En el modelo de uso de IA generativa al que estamos acostumbrados, seguimos el siguiente flujo:

Una sesión simultánea en IRIS: SQL, Objects, REST y GraphQL

Kazimir Malevich, "Deportistas" (1932)

"¡Pues claro que no lo entiende! ¿Cómo puede una persona que siempre ha viajado en un carruaje tirado por caballos entender los sentimientos e impresiones del viajero expres o del piloto de aviones?"

Kazimir Malevich (1916)

Introducción

Ya hemos abordado el tema de por qué la representación de objetos/clases es superior a la de SQL para implementar modelos de áreas temáticas. Y esas conclusiones y hechos son tan ciertos ahora como lo han sido siempre. Entonces, ¿por qué deberíamos dar un paso atrás y hablar sobre las tecnologías que arrastran las abstracciones de vuelta al nivel global, donde habían estado en la era pre-objetos y pre-clases? ¿Por qué debemos fomentar el uso de "código espagueti", que provoca errores que son difíciles de rastrear y se basa en las habilidades de desarrolladores virtuosos?

Hay varios argumentos a favor de la transmisión de datos por medio de APIs basadas en SQL/REST/GraphQL en lugar de representarlos como clases/objetos:

A partir de la versión 2019.2, InterSystems IRIS ofrece su API nativa para Python como un método de alto rendimiento para acceso a datos. La API nativa permite interactuar directamente con la estructura de datos nativa de IRIS.

Globals

Como desarrolladores de InterSystems, seguramente ya estais familiarizados con los globals. Vamos a revisar los aspectos básicos por si os apetece un repaso, pero podéis saltar a la siguiente sección si no lo necesitáis.

¡Hola desarrollador!

En este articulo repasaremos una publicación original de Maks Atygaev sobre la Implementación de una API de MongoDB, basada en InterSystems Caché - MonCaché.

Descargo de responsabilidad: En este artículo se muestra la opinión personal del autor y no tiene ninguna relación con opinión oficial de InterSystems.

Idea

La idea del proyecto es implementar las características básicas de la API en MongoDB (v2.4.9) , con la finalidad de buscar, guardar, actualizar y eliminar documentos de una manera que permita el uso de InterSystems Caché, en lugar de MongoDB, sin cambiar el código del lado del cliente.

GraphQL es un lenguaje estándar para declarar estructuras y métodos de acceso a datos, que sirve como una capa de middleware entre el cliente y el servidor. Si nunca has oído hablar de GraphQL, aquí puedes encontrar algunos recursos útiles: aquí, aquí y aquí.

En este artículo, explicaré cómo puedes usar GraphQL en tus proyectos basados en las tecnologías de InterSystems.

Hace poco, tuve que generar una especificación en Swagger a partir de clases persistentes y en serie, así que ahora publico el código (no está completo, aún queda resolver las especificaciones de la aplicación, pero es un comienzo).

El código está disponible aquí.

Supongamos que tenemos estas clases: