Este es el segundo post sobre Azure Container instances. En el post anterior vimos lo fácil que era publicar un contenedor y ejecutarlo usando ACI y discutimos algunas de sus limitaciones.

En este post veremos que ACI nos permite ejecutar grupos de contenedores, de forma igualmente sencilla y así tener algunos escenarios más complejos.

AKS Devspaces es una característica que Microsoft está promocionando bastante en sus charlas: casi en cualquier evento donde se hable de AKS se demuestra, ni que sea brevemente, Devspaces.

Pero… qué es y lo más importante: ¿Para qué sirve y como se usa?

He visto este problema con un proyecto generado a partir de la plantilla de SPA de React, pero quizá puede aplicar a otras plantillas de SPA (como Angular).

No suelo escribir en el post artículos sobre teoría de la computación, aunque es un tema apasionante. Que ahora recuerde solo escribí uno acerca del concepto del Orden de un algoritmo. Pero hace algunos días (he tardado más de lo esperado en escribir eso xD) buceando por twitter leí unos comentarios donde se mencionaba el concepto de un problema NP y leyendo el desconocimiento al respecto, me he animado a escribir esto… para que, si alguna vez te topas con ese concepto, sepas de que se habla. Por supuesto voy a hacer varias simplificaciones al respecto, así que si alguien conoce los fundamentos matemáticos que subyacen debajo, espero que me perdone 😉

Cuando hablamos de serverless todo el mundo lo asociamos a las soluciones tipo FaaS como Azure Functions o Amazon Lambda, pero hay otros productos que se engloban dentro de ese paradigma y en Azure uno de los más interesantes es Azure Container Instances. Del mismo modo que con una Azure Function me limito a poner código en “ejecución” y esto se ejecuta en algún sitio, usando ACI lo que hago es “poner un contenedor” que se ejecutará en… bueno, donde sea. Eso es serverless señores.

Con este post quiero iniciar una pequeña serie dedicada a ACI, como ACI se compara con su primo Zumosol (AKS) y como AKS y ACI habilitan interesantes escenarios (altísima escalabilidad y workloads mixtos de contenedores).

Este es un post cortito y motivado porque hace algunos días en el curso de JavaScript avanzado que tengo, junto al maestro José Manuel Alarcón, en CampusMVP un alumno preguntó más o menos eso: como se podía tener un timeout en una promise, de forma que esa fallase automáticamente si se superaba un determinado tiempo.

A ver, era algo que se veía a venir… Microsoft ha anunciado finalmente el abandono de Full Framework, en favor de Net Core. Cualquiera que estuviese al tanto de los intríngulis de pasillo del gigante de Redmond sabía que ambos equipos andaban bastante a la greña.

¡Buenas!

Este post pertenece al “calendario de adviento de C#“, y me gustaría hablaros de un tema que parece sencillo pero que bueno, esconde sus cosillas. En concreto sobre comparaciones en C#.

Una de las características más útiles, aunque más potencialmente peligrosas de C# es la posibilidad de sobrecargar los operadores de conversión (casting) y concretamente el de conversión implícita.

Poder sobrecargar el operador de conversión explícita, aunque lo entiendo como una característica que agrega ortogonalidad al lenguaje, no es algo que me guste. Antes de eso prefiero crear un método AsXXX(). De hecho me parece que un cliente de mi clase encontrará más lógico un método AsXXX() que no “un casting a XXX” que debes saber que se puede hacer para hacerlo.

Imagina que estás probando alguna versión release de netcore (pongamos la 2.2-preview3) y quieres generar imágenes Docker de tu proyecto para esa imagen. Pero a la vez quieres también crear las imágenes usando la última versión estable (pongamos la 2.1).

Asumiendo que el código fuente es compatible, ¿como puedes gestionar eso sin morir en el intento?