GitHub es el mayor servicio web para alojar proyectos tecnológicos (de TI) y sus desarrollos conjuntos. Este servicio web se basa en un sistema de control de versiones distribuido, que permite registrar los cambios realizados en el código fuente durante el desarrollo de un software.
En esta serie de artículos hemos hablado del framework iris-datapipe, de cómo nos ayuda a crear "pipes" de datos para la ingesta y procesamiento, y de cómo instalarlo. Vamos a profundizar en cómo implementar uno de esos "pipes" paso a paso.
En el artículo anterior hablamos de iris-datapipe, un framework diseñado para ayudarte a definir "pipes" de datos con un patrón de ingesta y procesamiento. Hoy veremos cómo puedes instalarlo y configurarlo paso a paso.
Me alegra anunciaros una nueva versión de iris-datapipe, un framework potente que, acompañado de una interfaz gráfica, te permitirá obtener una visión integral de la ingesta y procesamiento de datos en InterSystems IRIS.
La Interfaz de Pasarela de Servidor Web (WSGI, por sus siglas en inglés) es una convención de llamada para que los servidores web puedan reenviar solicitudes a aplicaciones o frameworks web escritos en el lenguaje de programación Python. WSGI es un estándar de Python descrito en detalle en PEP 3333.
🤔 Ok, gran definición, ¿y qué tiene que ver con IRIS?
Bienvenidos estimados miembros de la Comunidad a la presentación y primera entrega de un pequeño proyecto que demostrará las capacidades de InterSystems IRIS para proporcionar funcionalidades plenas de backup para una aplicación web desarrollada en Angular. Este artículo se limitará a presentar el concepto así como las funcionalidades de InterSystems IRIS utilizadas de un modo general, entrando más en detalle en posteriores artículos.
Cada vez es más común ver coloridas insignias o badges en el archivo README.MD, con información útil sobre un proyecto en repositorios como GitHub, GitLab y otros.
En nuestro artículo anterior vimos como podíamos capturar ficheros de tipo DICOM ubicados en una carpeta de nuestro servidor y como los enviábamos a un PACS (en nuestro caso la solución open source ORTHANC) para su almacenamiento y consulta. Pues bien, en este artículo vamos a tratar el movimiento opuesto.
Este es otro artículo para simplificar la vida de los desarrolladores. Hablamos de hacer que GitHub ejecute tus pruebas unitarias (unittest) con cada push que hagas a tu repositorio simplemente añadiendo un fichero. Gratis :). En GitHub Cloud. Suena genial, ¿no?
Es factible, y además muy sencillo. El mérito es para @Dmitry.Maslennikov (y su repo), el gestor de paquetes ZPM y las GitHub Actions. Vamos a ver cómo funciona todo en conjunto.
Si estás desarrollando soluciones en IRIS y quieres utilizar Git, ¡es genial! Sólo tienes que utilizar VSCode con un repositorio git local y enviar los cambios al servidor, así de fácil.
Pero qué sucede si:
Colaboras con otros desarrolladores en un entorno de desarrollo remoto compartido y quieres evitar la edición simultánea del mismo archivo
Utilizas editores basados en el portal de administración para BPL, DTL, tablas dinámicas, cuadros de mando, etc. y quieres incluir esos elementos en el control de código de forma sencilla.
Aún utilizas Studio para realizar algunas cosas y/o ocasionalmente vuelves a usarlo desde VSCode. O tu equipo todavía no ha adoptado completamente VSCode y algunos miembros del equipo todavía quieren utilizar Studio
Trabajas en varios proyectos diferentes al mismo tiempo en el mismo namespace - digamos, en varios paquetes definidos mediante InterSystems Package Manager - y quieres trabajar con todos ellos desde una vista de edición de isfs (en vez de en varios proyectos distintos) con los cambios rastreados automáticamente en el repositorio de git apropiado
Con frecuencia, cuando colaboramos con el repositorio de alguien en GitHub, seguimos el siguiente ciclo:
1. Fork: crear nuestra bifurcación del repositorio
2. Clone: clonar una copia local de nuestro repositorio bifurcado
3. Realizar nuestros cambios y guardarlos con un Commit en nuestra copia local
4. Push: publicar nuestros cambios al repositorio clonado de GitHub
5. Hacer Pull-Request para solicitar incorporar nuestros cambios desde nuestro fork — bifurcación — al repositorio original
6. Y si todo va bien se hará un Merge — fusión o incorporación — con nuestros cambios en el repositorio original
¡Todo esto es genial y funciona bien!
Y si queremos realizar una segunda colaboración justo después de llevar a cabo un Merge , es necesario que primero realicemos un Fetch upstream en nuestro repositorio clonado para que tengamos disponibles los cambios actualizados que incorporamos al repositorio original a través del Pull Request.
Los más frikies de git lo hacen muy fácilmente, pero muchos terminamos simplemente por eliminar nuestro primer fork y crear otro nuevo.
¡Hola a tod@s! Hoy traigo buenas noticias para la Comunidad:
Hace unos días, GitHub se actualizó con la última versión del proyecto linguist, que se utiliza para reconocer los tipos de código fuente en los repositorios. Ayuda a determinar qué lenguaje de programación se ha utilizado en cada archivo del repositorio. La sección de estadísticas del repositorio muestra los resultados del trabajo de este módulo.
Además, se puede buscar en todos los repositorios disponibles de GitHub para cualquier idioma elegido.
https://www.youtube.com/embed/G93HBywyaSY [Este es un enlace integrado, pero no puede ver el contenido integrado directamente en el sitio porque rechazó las cookies que se necesitan para acceder a él. Para ver el contenido integrado, debe aceptar todas las cookies desde la Configuración de cookies]
Por fecha
Open Exchange app
.png)
