Blog Bitix
Estrategias de despliegue para microservicios con Nomad
abril 18, 2019 09:30
El ciclo de vida de una aplicación no consiste solo en desarrollarla, incluye también su puesta en producción o despliegue en un entorno de pruebas, pero también una vez la aplicación está desplegada en algún momento será necesario actualizarla con una nueva versión.
Las aplicaciones monolíticas tienen otros problemas pero en el aspecto de despliegue es sencillo ya que solo hay una aplicación, basta con desplegar la nueva versión. En una aplicación con arquitectura de microservicios es un reto mayor debido a que hay múltiples aplicaciones.
En cualquiera de ellas puede darse el caso de que para ganar en escalabilidad o para aumentar la disponibilidad o tolerancia a fallos es posible que haya varias instancias, las cuales han de ser actualizadas con el requisito si es necesario de que el servicio no deje de prestar su servicio, es decir que el despliegue no suponga una caída del servicio.
Hay varias estrategias para desplegar una nueva versión de una aplicación:
- Rolling update: actualizar todas las instancias de forma progresiva. Una vez se termina de actualizar una se espera un tiempo y se actualiza la siguiente hasta que todas estén actualizadas.
- Blue/Green: manteniendo en funcionamiento las instancias con la versión antigua se crea el mismo número de instancias con la nueva versión y se redirige tráfico hacia ellas. Una vez se ha comprobado que la nueva versión funciona correctamente se promociona la nueva versión y se eliminan las instancias de con la versión antigua. Esta estrategia permite volver a la versión anterior rápidamente si se detecta algún problema.
- Canary: se siguen manteniendo las instancias con la versión antigua, a diferencia de la estrategia blue/green se crea un número menor de instancias con la versión nueva que el número de instancias con la versión antigua. Una vez comprobado que la nueva versión es correcta se promociona la nueva versión y se actualizan todas las instancias restantes mediante rolling update a la nueva versión. También permite volver a la versión antigua si se detecta algún problema.
Docker Swarm permite la estrategia de despliegue rolling update sin embargo las estrategias blue/green y canary son interesante para tratar de que un error en una versión nueva no afecte al funcionamiento de la aplicación y obligue hacer un rollback que posiblemente tarde más tiempo durante el cual el servicio funcionará con el defecto descubierto. Nomad permite despliegues con las estrategias blue/gree y canary.
Para actualizar un servicio en Nomad basta con modificar la definición del job y enviarlo a Nomad, y este se encarga de orquestar la actualización en las instancias según la estrategia de despliegue configurada. En este caso se actualiza la versión de nginx de la versión nginx:stable-alpine a nginx:alpine usando una estrategia rolling update para las cinco instancias del servicio.
La estrategia de despliegue en Nomad se define en la sección de configuración update. El parámetro min_healthy_time es el tiempo que se espera cuando se hace un rolling update para considerar una instancia como sana y continuar la actualización con la siguiente, max_parallel indica el número de instancias que se migran al mismo tiempo. El parámetro canary indica el número de instancias que se crean en las estrategias blue/green y canary, en la primera el número de instancias coincidirá con el parámetro canary que indica el número de instancias de un servicio. Nomad con los parámetros health_check, min_healthy_time, healthy_deadline, progress_deadline, stagger y auto_revert se puede poner unos límites para considerar válido un despliegue y en caso de no serlo realizar un rollback de forma autmática.
|
|
|
|
En el caso de los despliegues blue/green y canary una vez comprobado que la versión de los nuevos servicios funcionan correctamente se promocionan y actualizan el resto de instancias en el caso de canary o se detienen las instancias antiguas en el caso de blue/green.
|
|
Desde la línea de comandos se puede observar el estado del servicio y el proceso de actualización, el primero es el estado previo a realizar el despliegue, el segundo durante el proceso de actualización con rolling update y el tercero una vez finalizado el proceso de despliegue y marcado como exitoso en el que todas las instancias han pasado de la versión 0 a la 1.
|
|
|
|
El proceso de despliegue también se puede monitorizar desde la interfaz web que ofrece Nomad.
Progreso del despliegue rolling update en Nomad
En este ejemplo los servicios están en contenedores docker, también se observa que la versión de los contenedores en ejecución pasan de la versión stable-alpine a alpine.
|
|
|
|
Nomad y Consul se inician con los siguientes comandos en modo desarrollo comentados en el artículo Introducción a Nomad para gestionar aplicaciones y microservicios.
|
|
Blog Bitix
Introducción a Nomad para gestionar aplicaciones y microservicios
abril 17, 2019 09:00
En las arquitecturas de aplicaciones basadas en microservicios cada microservicio o simplemente servicio es una aplicación distinta e independiente, son varias aplicaciones que hay que gestionar y desplegar de forma individual o de forma coordinada.
Dado su número hay que automatizar todas las tareas para tratar de conseguir la menor intervención manual, ningún proceso manual si es posible. Para que no sean inmanejables han de tratarse como ganado de forma masiva en vez de como animales de compañía que requieran atención individual para continuar generando valor en un proyecto con el tiempo disponible en vez de dedicarlo a tareas que no lo aportan.
Dado que cada microservicio puede emplear una tecnología diferente es necesario algo que permita tratarlos a todos por igual, esta tecnología son los contenedores que hacen un papel similar al que hacen en el transporte de mercancías en barcos.
Hay varias tecnologías para orquestar o gestionar los microservicios y crear clusters de máquinas en las que desplegarlos, una de ellas es Docker Swarm sencilla e integrada con Docker pero no con tantas funcionalidades como otra de las populares que es Kubernetes y para usarlo en una máquina local minikube, ofrece mas funcionalidad pero añade una complejidad significativa que para algunos casos de uso no compensa además requiere mas tiempo para dominarla. Una solución intermedia conservando la sencillez pero con mas funcionalidad es Nomad de HashiCorp. Otra de sus características destacadas es que el cluster de Nomad puede estar formado en diferentes centros de datos y proveedores de la nube al mismo tiempo, por ejemplo en AWS, GCP entre otros o centros de datos híbridos en la nube y propios. En la sección Nomad vs. Other Software de su documentación se compara con otras opciones.
Nomad es distribuido, con alta disponibilidad y escalable a cientos de nodos en múltiples centros de datos y regiones. No es una solución completa por si sola pero se integra con otras. No ofrece descubrimiento de servicios pero se integra muy bien con Consul. No es un balanceador de carga pero se integra con Nginx, Fabio, Traefik y HAproxy automatizando su configuración desde Consul. No integra un gestor de secretos pero se integra con Vault. No soporta escalado y no integra de por sí varias de estas funcionalidades como Kubernetes pero es más simple.
Nomad a diferencia Docker no solo puede gestionar contenedores docker sino también tareas del sistema y otras como máquinas virtuales qemu o contenedores con rkt, a diferencia de Kubernetes es mucho mas sencilla pero conservando funcionalidad suficiente para muchos casos de uso. Nomad requiere de otra de las herramientas de HashiCorp que es Consul para el registro y descubrimiento y para la configuración del cluster, también se integra con otras de sus herramientas como Vault para guardar cifrados datos sensibles como contraseñas y certificados. Con Connect es capaz de proporcionar conexión TLS con autenticación mutua de forma transparente para los servicios.
Los jobs son la unidad de trabajo que contienen la definición de los servicios, se definen en un archivo de configuración donde los elementos son el nombre, los grupos de tareas, las tareas y en cada tarea el driver que usa dependiendo del cual se proporciona la configuración apropiada. El driver determina como es gestionada el tipo de tarea puede ser un conteendor de docker, un proceso del sistema, una máquina virtual de qemu o un contenedor rkt, a diferencia de Docker Swarm que solo puede gestionar contenedores docker. Se pueden configurar variables de entorno, memoria asignada a cada tarea, propiedades de red y CPU.
Nomad y Nomad cada uno son un binario ejecutable sin ninguna otra dependencia. Basta con descargarlos e incluirlos en el path del sistema. En este ejemplo hay definido un job compuesto por una tarea de un contenedor docker de nginx configurado en un puerto aleatorio y con 1 GB de memoria para cada una de las dos instancias del servicio. Dado que lo usa es necesario instalar Docker.
|
|
Nomad y Nomad se ejecutan con los siguientes comandos en modo desarrollo.
|
|
Iniciados se pueden enviar jobs y ver su estado, dirección y puerto asignado así como los logs generados.
|
|
También poseen una interfaz web integrada en la que consultar la misma información, la de Nomad está en el puerto 8500 y la de Nomad en el 4646 donde ver el estado de los jobs y el progreso de los despliegues.
Interfaces web de Consul y Nomad
Nomad permite varias estrategias para actualizar los jobs a una nueva versión de un servicio, basta modificar la configuración del job, volverlo a enviar a Nomad y este se encarga de actualizar las instancias siguiendo la estrategia rolling, blue/green o canary definida en el job, pero eso lo muestro mas detalladamente en otro artículo.
La documentación de Nomad, Nomad y otros productos de HashiCorp dedicados a la infraestructura en la nube esta muy bien explicada y detallada, este artículo solo es un resumen de las partes básicas para conocer como empezar a usarlo. En el siguiente vídeo se hace una pequeña explicación y demostración.
Picando Código
Gleam – Nuevo lenguaje de programación funcional estáticamente tipado en BEAM
abril 17, 2019 12:30
El pasado lunes 15 de abril se publicó la primera versión de Gleam (0.1): Gleam es un lenguaje de programación funcional estáticamente tipado diseñado para escribir sistemas concurrentes mantenibles y escalables. Compila a Erlang y tiene interoperabilidad directa con otros lenguajes de BEAM (la máquina virtual de Erlang) como Erlang, Elixir y LFE.
Obviamente es un lenguaje bastante nuevo, así que no está listo para usar en producción. Está interesante y ya se puede probar, programar alguna cosa divertida y aprender a usarlo. El código fuente está disponible en GitHub bajo licencia Apache 2.0, y chat del proyecto se encuentra en IRC en #gleam-lang de Freenode. Aplaudo el uso de IRC para proyectos de Software Libre en vez de Slack 
¡El compilador está escrito en Rust! Y si bien no conozco Rust, parece que saca algo de inspiración de ese lenguaje en la sintaxis y le veo también algunas cosas de Elixir.
Principios de Gleam
Ser seguro
Un sistema de tipados expresivo inspirado por la familia de lenguajes ML nos ayuda a encontrar y prevenir bugs en tiempo de compilación, mucho antes que el código llegue a los usuarios.
Para los problemas que no pueden ser resueltos con el sistema de tipos (como que le caiga un rayo al servidor) el runtime Erlang/OTP provee mecanismos bien testeados para manejar fallas.
Ser amigable
Perseguir bugs puede ser estresante así que la realimentación del compilador debe ayudar y ser lo más clara posible. Queremos pasar más tiempo trabajando en nuestra aplicación y menos tiempo buscando errores tipográficos o descifrando mensajes de error crípticos.
Como comunidad queremos ser amigables también. Personas de todos los orígenes, géneros y niveles de experiencia son bienvenidas y deben recibir respeto por igual.
Ser performante
El runtime Erlang/OTP es conocido por su velocidad y habilidad para escalar, permitiendo que organizaciones como WhatsApp y Ericsson manejen cantidades masivas de tráfico de manera segura con baja latencia. Gleam debería aprovechar por completo el runtime y ser tan rápido como otros lenguajes de la BEAM como Erlang y Elixir.
Ser un buen ciudadano
Gleam facilita el uso de código escrito en otros lenguajes BEAM como Erlang, Elixir y LFE, así que hay un ecosistema rico de herramientas y librerías para que los usuarios de Gleam aprovechen.
A cambio los usuarios de lenguajes BEAM deberían poder aprovechar Gleam, ya sea usando librerías escritas en Gleam de manera transparente, o agregando módulos Gleam a sus proyectos existentes con mínimo trabajo.
Instalación
Para instalarlo, debemos seguir esta guía, Necesitamos tener Rust, Erlang y rebar3 instalados de antemano, clonar el código con git, y compilar el compilador. El soporte para editores de texto todavía está un poco en pañales, pero ya hay modos para Emacs, Vim y Visual Studio Code.
Empezando a programar
Al ser un lenguaje tan nuevo, todavía no es un proceso tan directo crear un proyecto. De todas formas sólo hay que seguir estos pasos. El compilador puede trabajar con proyectos generados con rebar3, una herramienta de builds de Erlang.
Los tipos básicos de Gleam son String, Bool (True || && False), Int (enteros) y Float (decimales). Los valores pueden nombrarse con let para ser reusados después, pero los valores contenidos son inmutables:
let x = 1
let y = x
let x = 2
x // => 2
y // => 1
Tiene Tuplas, colecciones ordenadas de tamaño fijo con elementos que pueden ser de distintos tipos:
{"Texto", 2, True}
Y acá me empiezo a acordar de Elixir, podemos extraer los valores de la tupla así:
> valores = {"Texto", 2, True}
{"Texto", 2, True}
> {a, b, c} = valores
{"Texto", 2, True}
> a
"Texto"
> b
2
)> c
True
Otra estructura de datos son las Listas: Colecciones ordenadas de elementos del mismo tipo:
[7, 8, 9]
// Y para agregar nuevos valores, como en Elixir, se usa:
> ["N" | ["a", "n", "d", "o"]]
["N", "a", "n", "d", "o"]
Por último están los Mapas, colecciones de nombre y valores que pueden ser de cualquier tipo:
{
nombre = "Nicanor",
edad = 20,
}
Y se puede acceder al valor con la sintaxis `mapa.nombre_del_campo`:
let persona = { nombre = "Nicanor", edad = 20 }
let nombre = persona.nombre
nombre // => "Nicanor"
Para actualizar o agregar valores a un mapa se usa la sintaxis: { mapa | nombre_del_campo = valor }:
let persona1 = { nombre = "Marcela", edad = 22 }
let persona2 = { persona1 | edad = 23, idioma: "español" }
persona1 // { nombre = "Marcela", edad = 22 }
persona2 // { nombre = "Marcela", edad = 23, idioma: "español" }
Los tipos del mapa dependen de los nombres y tipos de los campos. El compilador lleva un registro de los campos y valores de cada mapa y presenta un error en tiempo de compilación en caso de querer usar un campo que no exista o tenga el tipo incorrecto.
Las funciones con nombre se declaran con pub fn:
pub fn sumar(x, y) {
x + y
}
pub fn multiplicar(x, y) {
x * y
}
Y como son valores de primera clase se pueden asignar a variables, pasar a funciones y todo lo demás que se puede hacer con cualquier otro tipo de datos:
pub fn dos_veces(f, x) {
f(f(x))
} // Wooooo!
También tiene funciones anónimas con una sintaxis similar:
pub fn ejecutar() {
let sumar = fn(x, y) { x + y }
sumar(1, 2)
}
No puedo evitar las comparaciones con Elixir, pero es a lo que me hace acuerdo… Hay una sintaxis corta para crear funciones anónimas que toman un argumento y lo pasan a otra función. Y esto se usa generalmente con pipes para crear una serie de transformaciones de datos:
pub fn sumar(x, y) {
x + y
}
pub fn ejecutar() {
// esto equivale a sumar(sumar(sumar(1,2), 4), 6)
1
|> sumar(_, 2)
|> sumar(_, 4)
|> sumar(_, 6)
}
Vistas las funciones otra cosa interesante es pasarles mapas como parámetros. El lenguaje apunta a ser muy permisivo con esto, y muestra un ejemplo de cómo funciona:
fn numero_siguiente(mapa) {
mapa.numero + 1
}
El tipo de la función es fn({ a | numero = Int}) -> Int. La a en este caso puede ser “cualquier otro campo”, así que la función se puede llamar con cualquier mapa siempre y cuando tenga el campo numero con un valor del tipo Int.
let articulo = { nombre: "tenedor", numero: 17 }
let nintendo = { nombre: "gameboy", numero: 4 }
let fernando = { nombre: "Fernando", edad: 33 }
numero_siguiente(articulo) // => 18
numero_siguiente(nintendo) // => 5
numero_siguiente(fernando) // => Compile time error! No numero field
La expresión case se usa como estructura de control por medio de la técnica “pattern matching” (ya escribí algo sobre Pattern Matching en el blog antes). Cómo se usa:
case numero {
| 0 -> "Cero"
| 1 -> "Uno"
| 2 -> "Dos"
| n -> "Otro número" // machea todo lo que no sea lo anterior
}
Como alternativa al if else de otros lenguajes, hace pattern matching con los valores Bool:
case alguna_condicion {
| True -> "Es verdadera"
| False -> "Es falsa"
}
La expresión case retorna un valor por lo que podemos asignarle el resultado a una variable. El pattern matching me resulta una cosa mágica y feliz, pero debe ser porque no estoy acostumbrado a usarlo.
El lenguaje también cuenta con Enums, y el tipo Bool está definido como uno:
enum Bool =
| True
| False
Una variante que muestra como ejemplo para extraer valores es:
enum User =
| LoggedIn(String)
| Guest
let diego = LoggedIn("Diego")
let leticia = LoggedIn("Leticia")
let visitor = Guest
Los enums también pueden ser “patternmacheados” para asignarle nombres a distintas variantes y podemos usarlos en un let.
Por último, al ser un lenguaje de la BEAM, podemos usar funciones de otros lenguajes directamente ¡Santa interoperabilidad Batman! Al ser lenguajes distintos, el compilador no puede determinar el tipo de las funciones, así que es la responsabilidad del programador en esos casos de hacer las cosas bien o veremos hermosas explosiones en nuestra aplicación. Pero llamar funciones de otros lenguajes es bastante sencillo:
// Llamando a la función uniform del módulo rand de Erlang:
pub external fn random_float() -> Float = "rand" "uniform"
// Llamando a IO.inspect de Elixir:
pub external fn inspect(a) -> a = "Elixir.IO" "inspect"
Como si fuera poco, también podemos importar tipos externos.
Conclusión
Si bien está en una etapa muy temprana de desarrollo, Gleam me resultó un lenguaje súper interesante que iré siguiendo con atención. Al ser tan nuevo, todavía hay mucho por implementar, así que resulta un buen aprendizaje y bastante interesante ir viendo cómo se desarrollan nuevas funcionalidades.
Elixir, Crystal y ahora Gleam son los lenguajes que me interesaría usar más aparte de Ruby, y en algún momento me voy a poner a leer también sobre Rust.
Si quieren aprender más de Gleam, pueden visitar su sitio web.
Variable not found
Enlaces interesantes 358
abril 15, 2019 06:55
Como entretenimiento para la Semana Santa, ahí van los enlaces recopilados durante los últimos siete días. Como siempre, espero que os resulten interesantes :)Por si te lo perdiste...
- Indicios de que tu interfaz de usuario fue creado por un programador
José María Aguilar - ¿Dónde está la directiva @helper de Razor en ASP.NET Core?
José María Aguilar
.NET / .NET Core
- Best 20 dot Net Core Libraries Every Developer should know
Shehryar Khan - C# 8: indexes and ranges
Olivier Giss - string vs. String is not a style debate
Jared Parsons - Why You Should Prefer a Single Line for C# Properties
Thomas Claudius Huber - Using, using, using with C# 8
Christian Nagel - Tuesday Quickie: When closure bites (or how not to configure Newtonsoft.Json)
Joel Hammon - Using strongly-typed entity IDs to avoid primitive obsession Part 1 & Part 2
Andrew Lock
ASP.NET / ASP.NET Core
- Troubleshooting Common ASP.NET MVC Problems
Jennifer Marsh - Add Authentication to Angular 7 App using ASP.NET Core 3
Talking Dotnet - Using ASP.NET Core Identity users in integration tests
Gunnar Peipman - Using Vue CLI Inside an ASP.NET Core Project
Shawn Wildermuth - .NET Core 3.0, VS2019 and C# 8.0 for ASP .NET Core developers
Shahed Chowdhuri - Getting Started with TypeScript for JSInterop in Blazor
Chris Sainty - Implement Middlewares using Endpoint Routing in ASP.NET Core 3.0
Jürgen Gutsch - File uploads in ASP.NET Core integration tests
Gunnar Peipman - Introducing Syncfusion's ASP.NET Core Blazor / Razor Components
Ajith R. - Debugging ASP.NET Core with Visual Studio and Docker Desktop
Nick Randolph - Accepting payments with Stripe and ASP.NET Core
Kristoffer Strube - Integration Tests in ASP.NET Core SignalR
Luis Ruiz
Azure / Cloud
How Skype modernized its backend infrastructure using Azure Cosmos DB: Part 1 & Part 2 & Part 3
Parul Matah- Getting Started with Azure Front Door
Michael Crump - Microsoft Graph: Webhooks
Fernando Escolar - Introducing the App Service Migration Assistant for ASP.NET applications
Calvin Keaton - Determine available runtimes on Azure App Service
Jerrie Pelser - Instalar una clave SSH en Azure DevOps
Gisela Torres - Terraform: Dando forma a nuestra infraestructura
Jorge Turrado - Trabajando con Azure DevOps, presentación
Daniel Córdoba Cárdenas
Conceptos / Patrones / Buenas prácticas
- Principios de diseño #8: procedural polymorphism
Iván Reinoso - C# Design Patterns - Strategy
Marinko Spasojevic - What Web Developers Need to Know About Content Security Policy
Shao Voon Wong - From dependency injection to dependency rejection
Mark Seemann
Data
- Designing Highly Scalable Database Architectures
Samir Behara - Updated: Implementing Missing Features in Entity Framework Core – Part 5: Getting the SQL for a Query
Ricardo Peres - Entity Framework Core 3.0 and SQL Server Performance Optimization, Part 1: Parameters Sniffing
Bassam Alugili - Domain modelling and persistence with EF Core
Scott Logic - Code review #1 - dapper and varchar parameters
Michał Białecki
Machine learning / IA / Bots
- Introduction to Convolutional Neural Networks (CNN) with TensorFlow
Marco Peixeiro - Machine Learning with JavaScript and TensorFlow.js Series
Nikola Živković - How to build your first Neural Network to predict house prices with Keras
Joseph Lee Wei - Machine Learning with ML.NET in UWP: Recommendation
Diederik Krols - Random Forests for Complete Beginners
Victor Zhou - Preguntas naturales: un conjunto de datos con 300.000 entradas para entrenar inteligencias artificiales
Alvy
Web / HTML / CSS / Javascript
Native image lazy-loading for the web!
Addy Osmani- Creating a custom HttpInterceptor to handle 'withCredentials' in Angular 6+
Rick Strahl - Digging Into The Display Property: The Two Values Of Display
Rachel Andrew - Type of Undeclared Variable in JavaScript: What is it?
Dhananjay Kumar - An Overview of Popular CSS-in-JS Libraries for React
Christian Nwamba - Using a Mixin to Take the Math out of Responsive Font Sizes
Martijn Cuppens - Understanding Subresource Integrity
Drew McLellan - Using the ng-BootStrap TypeAhead Control with Dynamic Data
Rick Strahl - Vanilla.js — Getting Started
Jeremy Likness - Squeezing Angular Directives
Aleix Suau - Under-Engineered Toggles
Adrian Roselli - Edge Goes Chromium: What Does it Mean for Front-End Developers?
Ollie Williams - Using the Web Speech API for Multilingual Translations
Steven Estrella - Get a CSS Custom Property value with JavaScript
Andy Bell - Inline SVG... Cached
Chris Coyier
Visual Studio / Complementos / Herramientas
- View Clipboard Ring History in Visual Studio 2019
Abhijit Jana 
Intelligent document tabs grouping in Visual Studio 2019
Sergey Vlasov- 5 Top, No-Cost .NET Core Extensions for Visual Studio 2019
David Ramel - Visual Studio Tips: Test Explorer
Jeremy Hutchinson - New features for extension authors in Visual Studio 2019 version 16.1
Mads Kristensen - Azure Kubernetes Service: tu clúster manejado en la nube & Acceder a tus aplicaciones en Kubernetes a través de Ingress & Usar Port Forwarding para acceder a tus aplicaciones en Kubernetes & Helm: el gestor de paquetes para Kubernetes
Gisela Torres - Configure Visual Studio across your organization with .vsconfig
Heath Stewart - Fixing Intellisense and Go To Definition in Visual Studio 2019
Matthew Jones - Compartir código en Visual Studio: proyectos compartidos o librerías
José Manuel Alarcón - Performance Timing in Chrome DevTools
Christian Nwamba - Advanced Visual Studio search in Watch, Autos and Local windows
Mark Downie - The Git Stash Functionality in Visual Studio 2019Thomas Claudius Huber
- Cómo resolver el problema MSB4018 CreateAppHost en Visual Studio 2019
Jorge Serrano
Xamarin
- Working with Barcodes in Xamarin.Forms
Gerald Versluis - Share Files as Email Attachments with Xamarin.Essentails
James Montemagno - Adding fingerprint authentication in Xamarin Forms
Enmanuel Toribio - Using Font Icons in Xamarin.Forms: Goodbye Images, Hello Fonts!
James Montemagno - Novedades en Xamarin.Forms 3.6 & Un vistazo a Aurora Controls
Javier Suárez
Otros
Stack Overflow Developer Survey 2019
Stack Overflow- What to expect in the new Microsoft Edge Insider Channels
Jatinder Mann & John Hazen - Windows 10 ha cambiado la forma en la que expulsamos los dispositivos USB, y quizás te interese cambiarla de nuevo
Gabriela González - Odio los framework
Javi Santana
Bitácora de Javier Gutiérrez Chamorro (Guti)
Necromancer’s DOS Navigator
abril 13, 2019 08:01
DOS Navigator comienza en 1991, un gestor de archivos para DOS que proporciona una cantidad de funciones que representan un salgo enorme en la tecnología de la época. Su evolución continua hasta 1998 cuando presentan la versión 1.50, aunque desde la 1.35 de 1995 decidieron dedicar sus esfuerzos al cliente de correo para Windows The […]
La entrada Necromancer’s DOS Navigator aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).
Blog Bitix
Aumentar el tamaño del identificativo de la cookie de sesión de Tomcat o Spring Session
abril 12, 2019 05:00
El protocolo HTTP es un protocolo sin estado que quiere decir que entre las peticiones no se comparte estado ni se recuerda ningún dato. Por otro lado las cookies es pequeño conjunto de datos que son almacenados en el cliente y son enviados en cada petición que se hace a un sitio web, cada sitio web mantiene su propia colección de cookies, dos sitios distintos no comparten sus cookies. Para mantener estado entre dos peticiones se hace uso de las cookies.
En Java los servidores web envían al cliente una cookie con simplemente un identificativo de la sesión, el estado se suele mantener en el servidor en memoria, en almacenamiento de disco o persistido en una base de datos como Redis. El identificativo de la sesión por defecto usando un contenedor de servlets como Tomcat tiene una longitud de 16 bytes que codificados en hexadecimal da lugar a 32 caracteres o 128 bits. Para aumentar la seguridad por si alguien intenta adivinar el identificativo de cualquier usuario que tenga sesión iniciada por fuerza bruta de casualidad es posible aumentar el número de caracteres para identificar la cookie de sesión. La clase de la API que lo permite en Tomcat es Manager.
Según Insufficient Session-ID Length un identificativo con solo 64 bits (32 de entropía) un atacante haciendo 1000 intentos por segundo y 10000 sesiones válidas tarda solo 7,15 minutos en obtener una sesión válida (32 bit = 4294967296 / 10.000 = 429496, a 1000 intentos por segundo da 429 segundos o 7,15 minutos). Con 128 bits el tiempo crece a 292 años haciendo 10000 intentos por segundo y teniendo 100000 sesiones válidas, pero podría reducirse si el número de intentos por segundo aumentase o sesiones aumentase.
Los datos se guardan en el servidor y la cookie con el identicativo de sesión no ocupa mucho aún pasando de 32 caracteres hexadecimales a una cifra mayor como 128, el número de caracteres no es significativo para el rendimiento pero se dificulta en varios órdenes de magnitud la dificultad de adivinar una cookie.
Unsando Spring Boot y Tomcat basta con usar la clase Manager para cambiar el valor por defecto de longitud de la sesión.
|
|
Persistiendo la sesión en Redis con Spring Sesion por defecto el identificativo de la sesión es generado a partir de un UUID, el identificativo de la sesión tiene el mismo valor por defecto de 128 bits pero para cambiar la longitud hay que proporcionar una clase que cambia el comportamiento.
|
|
|
|
Longitud del identificativo de sesión de 64 bytes o 128 caracteres hexadecimales
|
|
Un libro dedicado a la seguridad muy bueno que he leído es Iron-Clad Java Applications, tiene montón de detalles dedicados a la seguridad de las aplicaciones web sean seguras, incluido como este dedicado a la longitud de los identificativos de la sesión.
Una clave asimétrica considerada segura puedes ser de 2048 bits pero se puede generar una de hasta 8192 bits con el mismo esfuerzo lo que aumenta la seguridad de forma exponencial ante un ataque de fuerza bruta que con el aumento de la capacidad de cómputo y en el futuro puede ser viable. El tiempo de cómputo requerido por usar una clave de mayor tamaño no creo que sea significativo para la mayoría de los casos pero igualmente la seguridad aumenta.
El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew run.
Picando Código
Spring – nueva película animada hecha con Blender
abril 10, 2019 02:59
Spring es el 12° proyecto de la iniciativa Open Movies de Blender:
Spring es la historia de una niña pastora y su perro, que enfrentan espíritus antiguos para continuar el ciclo de la vida. Este poético y visualmente maravilloso cortometraje fue escrito y dirigido por Andy Goralczyk, inspirado por su niñez en las montañas de Alemania.
Blender es software de gráficos 3D libre usado para crear animaciones, efectos especiales, arte, modelos imprimibles 3D, aplicaciones y videojuegos. Mediante la Fundación Blender, se han producido varios proyectos de alta calidad con el objetivo de demostrar, validar y mejorar las capacidades del software.
Varios de ellos ya son bastante conocidos:
Elephants Dream, Big Buck Bunny, Sintel, Tears of Steel, Caminandes Gran Dilamma, Cosmos Laundromat, Glass Half, Caminandes Llamigos, Agent 327 Operation Barbershop, Daily Dweebs y Hero.
El equipo de producción de Spring usó la versión de desarrollo de Blender 2.80 durante toda la producción, incluso antes que el software estuviera oficialmente en Beta. Como con todas las películas anteriores de Blender, el proceso de producción entero y todos los archivos fuente están siendo compartido en la plataforma Blender Cloud. Si acceden al enlace, pueden ver una línea de tiempo de varias semanas de desarrollo y materiales que se van compartiendo como artwork, storyboards y demás materiales de producción. También se incluyen tutoriales, videos del proceso y mucho material más.
La imagen del corto es espectacular y el resultado final es excelente. Les recomiendo mirarlo. Y visiten este enlace si quieren ver más películas del estilo libres, gratuitas y totalmente legales de mirar como y dónde quieran.
Formato: película animada 3D, 7:44 minutos. sonido 5.1. Sin diálogos. Apta para audiencias de 6 años para arriba (PG).
Todo lo que se ve fue hecho con Blender, GIMP y Krita.
Arragonán
Diseño incremental de software a partir de las interacciones (parte 1)
abril 10, 2019 12:00
Este post viene a cuento de que me quedé sin hacer la charla de la Bilbostack 2019 por andar pachucho durante varias semanas, teniendo que cancelar el compromiso al no haberme recuperado a los pocos días del evento. Me quedó el contenido a medio preparar y tenía la espinita clavada de compartir mis ideas sobre el tema.
¿Qué narices es eso del diseño incremental?
Ahora que “agile” (nótese el entrecomillado ;)) es mainstream, parece que se va asumiendo en muchos sitios que hacer software de forma iterativa ayuda a hacer mejor software. Cada cierto tiempo hay entregas que permiten validar si se va por un camino correcto o no, comprobar malos entendidos, ver problemas que han surgido, adaptabilidad a cambios…
Lo que bajo mi percepción no es tan mainstream es la parte de incremental, cuesta más hacer vertical slicing. En mi opinión esto suele ocurrir por falta de habilidades o conocimiento de prácticas relacionadas con Extreme Programming, como son test first o el propio diseño incremental.
Aunque siempre hay que hacer un esfuerzo inicial para poder sentar algunas bases respecto a la visión del producto, qué problemas o necesidades se quiere resolver, la arquitectura de alto nivel, etc.; muchas veces se peca de querer bajarlo demasiado en detalle desde el inicio, pretendiendo tener una foto de cómo va a ser la solución y adivinar el futuro.
No olvidemos que, cuando desarrollamos un software, hoy sabemos menos que mañana. En cada iteración que pasa, más aprendemos sobre el negocio, conocemos mejor las herramientas y la tecnología, intentamos mejorar como equipo, etc.
Así que una cosa que debemos tener clara es que, si queremos que nuestro software dure, tenemos que enfocarnos en diseñar software que acepte cambios. Aceptar la incertidumbre frente a tratar de adivinar problemas futuros.
¿Y lo de diseñar a partir de las interacciones?
Pues básicamente enfocar el diseño de software desde cómo se va a utilizar, ya sean personas que interactúan a través de una UI u otros sistemas que lo hacen usando algún tipo de API.
Seguramente resulta familiar el término API first, que es una aproximación similar. Empezar definiendo cómo se expone el software partir de un contrato e ir haciendo Outside-In hacia la implementación y modelado más interno.
En el caso del diseño a partir de las interacciones nos abstraemos de los detalles de un API. Anteponemos la definición de la interacción a la del API ya que esta no es nada más que un detalle técnico de cómo se expone la interacción al mundo.
Y cuidado: No podemos caer en la trampa de definir pobremente esas interacciones, sin descubrir el negocio que hay debajo y acabar pensando que sólo son CRUDs. Nunca es un CRUD: reglas de negocio, efectos colaterales, integraciones con terceros…
Descubrimiento de producto
Antes de identificar las interacciones, un trabajo importante es lo que se suele llamar descubrimiento de producto. Algunas cosas que necesitamos saber: objetivos de negocio del producto, quiénes son los usuarios y sus motivaciones, dependencias técnicas u organizativas, posibles restricciones, identificar a los stakeholders…
Es un tiempo dedicado a analizar y entender los problemas para poder enfocar mejor la solución, ya que no hay nada peor que descubrir que hemos contruido algo que nadie quiere.
Hay multitud de actividades que se pueden usar dependiendo del contexto (producto, equipo, negocio…): business model canvas, value proposition canvas, entrevistas, user personas, mapa de stakeholders, mapa de empatía, benchmarking de producto, customer journey map… o usar un paquete de este tipo de actividades como design sprint, agile inception deck o lean inception.
Estas actividades, muy estilo design thinking, se han quedado relegadas habitualmente a la gente de UX, negocio o gestión de producto, ya que a los técnicos típicamente no nos ha preocupado demasiado o no se nos ha incluido.
Participar en estas actividades nos ayuda a entender infinitamente mejor las necesidades durante la evolución del desarrollo del producto, además de facilitarnos el planteamiento inicial de la arquitectura de software a alto nivel. Y es que hacer diseño incremental no quiere decir que no hagamos un trabajo previo.
Formalización del backlog
Para poder organizarnos y priorizar debidamente necesitamos tener disponible algún tipo de backlog de producto, de modo que lo oportuno es hacer un volcado de product backlog items (sin preocuparnos demasiado del tamaño) como complemento a las diferentes actividades de descubrimiento que se hayan podido realizar.
A mi personalmente me gusta el terminar visibilizándolo en un formato estilo user story map. Aunque siempre he omitido la parte de journey, simplemente me gusta verlo organizado en dos dimensiones: funcionalidad/tema y prioridad agrupada en swimlanes.
Me parece muy interesante organizar las swimlanes como must, could y nice to have, al menos como organización incial o de cara a implementar un MVP. Otras veces, teniendo razonablemente claro el alcance final, las he utilizado directamente para definir releases o entregas parciales tentativas.
Refinamiento de historias de usuario
Ya con la prioridad, sabemos por donde hay que ponernos a aterrizar esos product backlog items y formalizarlo en una o varias historias de usuario. Recordemos que una historia de usuario no es sólo completar una plantilla, debería ser siempre un artefacto que sirve como recordatorio de (o excusa para) una conversación sobre ella y que además debería tener unos criterios de aceptación específicos.
Además de en las dailies o conversaciones más informales entre los miembros del equipo, habitualmente estas conversaciones deberían ocurrir más intensamente en algún tipo de sesión de planning, de la que deberíamos extraer los criterios de aceptación de las historias de usuario en las que vayamos a trabajar próximamente. Esas sesiones pueden contener ejercicios de estimación como planning poker o de refinamiento como example mapping.
Personalmente me gusta bastante el example mapping porque ayuda a estructurar las conversaciones, desgranando las historias de usuario en forma de reglas, dudas y ejemplos que ilustran las reglas.
Specification by Example
Las reglas forman parte de los criterios de aceptación de una historia, mientras que los ejemplos nos marcan la especificación y nos sirven como primer paso para hacer Specification by Example (prefiero ese nombre que Behaviour-Driven Development) con el que dirigir el diseño incremental de las iteraciones.
Como herramienta para hacer Specification by Example suelo utilizar cucumber, de modo que las especificaciones terminan en el típico formato gherkin Given/When/Then.
Evidentemente se pueden utilizar otras herramientas para esto, pero ¿por qué cucumber?:
- Al separar las especificaciones como texto plano, permite colaborar fácilmente con perfiles no técnicos para elaborarlo o validarlo.
- Ayuda forzarse a utilizar lenguaje ubicuo que deberíamos haber ido desarrollando (quizá incluso mantengamos un glosario de términos).
- Queda como fuente de verdad y sirve como documentación viva. Si una funcionalidad cambia, quedará reflejado el cambio.
- Facilita hacer ATDD separando claramente el ciclo de especificación del de desarrollo.
- Permite implementar tests automáticos a distintos niveles. Pudiendo hacer tests sólo de la lógica de negocio, desde la UI, a través de un API…
A partir de las historias de usuario y de las especificaciones con ejemplos tendremos identificados los casos de uso o interacciones, el alcance bien definido y habremos trabajado el lenguaje ubicuo.
Este tipo de prácticas hacen más eficiente el proceso de desarrollo, aumentando la calidad del producto y evitando retrabajo a causa de malosentendidos.
Próximamente
Espero escribir al menos un post más, tratando la parte más técnica a través de un ejemplo práctico sobre:
- Implementar tests automáticos desde especificaciones gherkin con cucumber.
- Artefactos tácticos de Domain Driven Desing.
- TDD Outside-In, empezando desde las interacciones o use cases.
- Arquitectura hexagonal/clean, escapando de frameworks.
Otros recursos
En forma de cursos, posts y videos relacionados que tengo repartidos por ahí:
- Buenas prácticas de BDD con Gherkin (Cucumber, Behat…).
- Una de BDD, Specification by Example y Cucumber.
- Estimar es timar: Example Mapping.
- BDD: ¿Qué aporta Gherkin? 🥒 (Cucumber, Behat & Co.).
- Desarrollando un MVP: PHP y Clean Architecture.
- Testing en Invoice_Me. Cucumber, RSpec, Capybara, Selenium….
Picando Código
Kingdom Rush: Rift in Time ¡Juego de tablero de Kingdom Rush en Kickstarter!
abril 09, 2019 07:46
La famosa saga de juegos Tower Defense, Kingdom Rush, llega al mundo de los juegos de tablero. Mediante una campaña en Kickstarter, Kingdom Rush: Rift in Time alcanzó la meta inicial de USD 20.000 en apenas media hora.
Los encargados de trasladar Kingdom Rush de los píxeles a cartón, plástico y madera son el equipo del estudio Lucky Duck Games, que ya tiene experiencia con varios títulos. El producto se describe como un juego de puzzle, completamente cooperativo, dirigido por una campaña y de proporciones épicas. Si ya han disfrutado Kingdom Rush, van a ver que se trata de una adaptación fiel a juego de mesa. En la página de Kickstarter pueden encontrar varias instrucciones y videos que explican cómo se juega. Pero la idea sigue siendo defender nuestra base de hordas de enemigos con torres, ¡pero cooperativo!
De 1 a 4 jugadores, para mayores de 12 años y con partidas de entre 60 y 90 minutos. Se incluyen varios tableros con caminos como para generar el escenario, fichas de corazones y diamantes, cartas para las hordas y torres, las formas a lo Tetris para atacar desde las torres, marcadores para torres, soldados y ¡héroes! En principio serán 4 héroes y dos jefes (figuras de plástico 
).
Va a estar traducido a Inglés y Francés, y podemos elegir una de esas dos versiones si lo compramos durante la campaña. Pero también va a incluir un manual digital para Español, Italiano y Polaco. Aseguran que la mayor parte del contenido del juego es independiente del lenguaje. Así que con aprenderse las reglas, seguramente no va a ser necesario volver al manual.
Como varias campañas en Kickstarter, hay distintas metas que se van a ir alcanzando a medida que más gente invierta en el proyecto. Las metas son más héroes, hordas, torres y con suerte escenarios. Al momento de escribir esto, ya se superaron los USD 110.000 de recaudación, por lo que se desbloquearon al menos 7 de estas metas. El paquete básico, denominado Knight Pledge, cuesta USD 59 e incluye todo lo necesario para jugar + todas las metas que se desbloqueen. Pero también podemos comprar el King Pledge por USD 79, una edición de lujo y limitada que nunca va a estar disponible para comprar en otro lado. Incluye mejoras al paquete básico y un póster. Por ahora también hay un agregado disponible por USD 19 que incluye un héroe, un jefe, y una campaña nueva.
Me alegra muchísimo ver a Kingdom Rush en formato juego de tablero y ¡no puedo esperar a probarlo!
Variable not found
Antipatrones de asincronía en C#
abril 09, 2019 11:09
Hace unas semanas leía el post C# Async Antipatterns de Mark Heath, y encontré en él problemas en la implementación de código asíncrono que, coincidiendo con el autor, creo que son bastante frecuentes.Como la asincronía ha llegado para quedarse y aún hay desarrolladores que no lo tienen claro del todo, he pensado que sería interesante traducir y republicar aquí el post, por supuesto, con permiso expreso de su autor (thank you, Mark! ;))
¡Vamos allá!
Antipatrones de asincronía en C#
Las palabras claveasync y await han hecho un gran trabajo simplificando la forma de escribir código asíncrono en C#, pero, desafortunadamente, no pueden protegernos de hacer las cosas mal. En este artículo me gustaría recoger algunos de los errores de codificación o antipatrones más comunes relativos a asincronía que suelo encontrar en revisiones de código.1. Olvidar el await
Cuando llamamos a un método que retorna un objeto Task o Task<T>, no deberíamos ignorar su valor de retorno. Esto decir, la mayor parte de las veces deberemos utilizar await para esperar su resultado, aunque hay algunas ocasiones en las que podríamos necesitar almacenar el objeto Task para esperar a su finalización más adelante.Observad que en el siguiente ejemplo invocamos a
Task.Delay(), pero dado que no esperamos su finalización, el mensaje "Después" es mostrado inmediatamente porque la llamada Task.Delay(1000) simplemente retorna un objeto Task que finalizará un segundo más tarde, pero, dado que nadie está esperando a que esta tarea sea completada, la ejecución continúa sin detenerse:Console.WriteLine("Antes");
Task.Delay(1000);
Console.WriteLine("Después");
Task y está marcado como asíncrono con la palabra clave async, el compilador nos dará un error bastante descriptivo:Because this call is not awaited, execution of the current method continues before the call is completed.
Consider applying the 'await' operator to the result of the call.
async, el compilador de C# no protestará y nos permitirá hacerlo sin problema. Por tanto, debemos estar atentos para que este error no pase desapercibido.2. Ignorar tareas asíncronas
A veces nos interesa ignorar deliberadamente el resultado de una llamada asíncrona porque no queremos esperar a que ésta se complete. Por ejemplo, podría tratarse de un tarea de largo tiempo de ejecución que queremos que se realice en segundo plano, mientras en primer plano continuamos con otra cosa.A menudo veo código como el siguiente:
// Hacer algo en segundo plano - no queremos esperar a que finalice
var ignoredTask = DoSomethingAsync();
DoSomethingAsync() no serían capturadas en ningún momento. En este caso, lo mejor que puede pasar es que no nos enteremos de que la operación en segundo plano falló; lo peor, es que incluso podría tumbar el proceso completo y provocar la finalización de la aplicación.Por tanto, debemos utilizar esta técnica con mucha precaución, y siempre asegurar que el método invocado gestiona apropiadamente las excepciones. A menudo veo su uso en aplicaciones en la nube, y en muchas ocasiones tiendo a refactorizarlo enviando un mensaje a una cola cuyo handler realiza la tarea en segundo plano de forma totalmente independiente.
3. Utilizar métodos async void
A menudo os encontraréis escribiendo un método síncrono (es decir, un método que no retorna una instancia de Task o Task<T>) en cuyo interior os interesará llamar a un método asíncrono (que retorne un Task). Sin embargo, sabemos que no podemos utilizar la palabra clave await sin marcar el método como async, por lo que tendremos que buscar otras fórmulas. Básicamente hay dos formas de conseguirlo, y las dos son arriesgadas.La primera es cuando estamos en un método
void. En este caso, el compilador de C# nos permitirá añadir async a la firma del método, por lo que podremos utilizar await sin problema:public async void MyMethod()
{
await DoSomethingAsync();
}
MyMethod() no tienen forma de esperar a que este método finalice su ejecución, pues no tienen acceso al objeto Task que retorna la llamada a DoSomethingAsync(). Por lo tanto, básicamente estaremos ignorando la tarea asíncrona de nuevo.Sin embargo, hay algunos casos de uso válidos para los métodos
async void. El mejor ejemplo lo encontraríamos en los manejadores de eventos de aplicaciones Windows Forms o WPF. Los event handlers retornan siempre void, por lo que no podemos hacer que retornen el objeto Task con la tarea asíncrona.Por tanto, no hay ningún problema en utilizar un código como el siguiente:
public async void OnButton1Clicked(object sender, EventArgs args)
{
await LoadDataAsync();
// update UI
}
async void. Si podéis hacer que vuestros métodos retornen Task, deberíais hacerlo.4. Bloquear tareas con .Result o .Wait()
Otra forma bastante habitual de consumir métodos asíncronos desde métodos síncronos es utilizando la propiedad .Result o llamando a Wait() sobre el objeto Task que representa a la tarea asíncrona.La propiedad
Result espera a que la tarea finalice y retorna su resultado, lo cual a priori puede parecer bastante útil. Podemos utilizarlo como se muestra a continuación:public void SomeMethod()
{
var customer = GetCustomerByIdAsync(123).Result;
}
Result o Wait() hace que el hilo de ejecución quede bloqueado y no pueda ser destinado a otros menesteres mientras espera la finalización de la tarea asíncrona. Pero lo que es peor, la mezcla de código asíncrono con llamadas a .Result (o Wait()) abre la puerta a problemas de interbloqueos realmente terribles.Por lo general, siempre que necesitéis llamar a un código asíncrono desde un método debéis aseguraros de que éste también sea asíncrono. Sin duda, esto puede suponer un cierto esfuerzo adicional y deriva en muchos cambios en cascada para introducir asincronía en toda la cadena de llamadas, sobre todo en una base de código extensa, pero esto es preferible al riesgo de introducir deadlocks.
Puede haber casos en los que no es posible hacer el método asíncrono. Por ejemplo, si queremos invocar un código asíncrono desde el constructor de una clase, esto no será posible, aunque normalmente podremos rediseñar la clase para no necesitarlo.
Por ejemplo, en lugar de esto:
class CustomerHelper
{
private readonly Customer customer;
public CustomerHelper(Guid customerId, ICustomerRepository repo)
{
customer = repo.GetAsync(customerId).Result; // avoid!
}
}
class CustomerHelper
{
public static async Task<CustomerHelper> CreateAsync(Guid customerId, ICustomerRepository repo)
{
var customer = await repo.GetAsync(customerId);
return new CustomerHelper(customer)
}
private readonly Customer customer;
private CustomerHelper(Customer customer)
{
this.customer = customer;
}
}
IDisposable o implementar el atributo ActionFilterAttribute de ASP.NET MVC. En estos casos hay que ser muy creativos para idear una solución, o simplemente asumir que necesitaremos realizar llamadas bloqueantes y prepararnos para introducir muchas llamadas a ConfigureAwait(false) para protegernos de los bloqueos (hablaremos de esto más adelante).Las buenas noticias son que, en el desarrollo actual, es cada vez más raro encontrar escenarios en los que sea necesario bloquear una tarea. Por ejemplo, desde C# 7.1 podemos declarar métodos
async Main para aplicaciones de consola y ASP.NET Core está diseñado con la asincronía en mente desde sus orígenes, mucho más de lo que lo estaba ASP.NET MVC.5. Mezclar ForEach() con métodos asíncronos
La clase List<T> tiene un "útil" método llamado ForEach(), que permite ejecutar un Action<T> sobre cada elemento de la lista. Si habéis visto algunas de mis ponencias sobre LINQ ya conoceréis mis opiniones en contra de este método, pues fomenta una gran variedad de malas prácticas (podéis leer este artículo para conocer algunas de las razones para evitar el uso de ForEach()).Pero aparte de esto, una aplicación especialmente peligrosa de
ForEach() que he visto es utilizarlo para invocar métodos asíncronos. Por ejemplo, imaginemos que queremos enviar un email a todos los clientes de la siguiente manera:customers.ForEach(c => SendEmailAsync(c));
foreach:foreach(var c in customers)
{
SendEmailAsync(c); // The return task is ignored
}
Task por cada cliente, pero no hemos esperado a que ninguna de estas tareas finalice.A veces he visto desarrolladores que intentan solucionarlo introduciendo
async y await en la lambda:customers.ForEach(async c => await SendEmailAsync(c));
ForEach() acepta un Action<T> que retorna void, por lo que básicamente hemos creado un método async void que, por supuesto, es uno de los antipatrones que hemos comentado anteriormente, pues el consumidor no tiene forma de esperar su finalización.Y entonces, ¿cómo solucionamos esto? Bien, personalmente preferiría sustituir ese código por un bucle
foreach explícito:foreach(var c in customers)
{
await SendEmailAsync(c);
}
ForEachAsync(), lo que permitiría escribir código como el siguiente:await customers.ForEachAsync(async c => await SendEmailAsync(c));
List<T>.Foreach() (o Parallel.Foreach, que de hecho tiene el mismo problema) con métodos asíncronos.6. Exceso de paralelización
En algunas ocasiones, podemos identificar una serie de tareas que se realizan de forma secuencial y forman parte de un cuello de botella en el rendimiento de nuestras aplicaciones. Por ejemplo, imaginad un código que procesa pedidos secuencialmente como el mostrado a continuación:foreach(var o in orders)
{
await ProcessOrderAsync(o);
}
var tasks = orders.Select(o => ProcessOrderAsync(o)).ToList();
await Task.WhenAll(tasks);
ProcessOrderAsync() para cada pedido, y almacenar en una lista cada uno de los objetos Task retornados. Tras ello, esperamos a que todas estas tareas finalicen.En efecto, este código funciona, pero, ¿qué ocurriría si existieran 10.000 pedidos? Habríamos inundado el thread pool con miles de tareas, quizás evitando que otras tareas del sistema puedan ser realizadas. Además, si
ProcessOrderAsync() hiciera a su vez llamadas a otros servicios externos como bases de datos o microservicios, estaríamos saturándolos con un gran volumen de llamadas.¿Y cuál sería el enfoque correcto en este caso? Bueno, al menos deberíamos considerar limitar el número de tareas concurrentes que pueden llamar a
ProcessOrderAsync() al mismo tiempo. En este artículo describí distintas fórmulas para conseguir esto.Cuando veo este código en una aplicación en la nube, a veces es una señal de que tenemos que introducir algún sistema de mensajería para que la carga pueda ser dividida en bloques y gestionada por lotes desde más de un servidor.
7. Efectos laterales del código no thread safe
Si alguna vez habéis echado un vistazo a la programación funcional (lo que recomiendo que hagáis incluso si no tenéis intención de cambiar de lenguaje), os habréis topado con el concepto de funciones puras. Conceptualmente, las funciones puras son aquellas que no son sensibles a efectos laterales; toman unos datos de entrada y retornan otros de salida, pero no realizan ninguna mutación de estado en su interior. Las funciones puras ofrecen muchos beneficios, incluyendo su inherente seguridad en entornos multiproceso.A menudo encuentro métodos como el siguiente, donde enviamos una lista o un diccionario a un método que los modifica de alguna forma:
public Task ProcessUserAsync(Guid id, List<User> users)
{
var user = userRepository.GetAsync(id);
// do other stuff with the user
users.Add(user);
}
public Task<User> ProcessUserAsync(Guid id)
{
var user = userRepository.GetAsync(id);
// do other stuff with the user
return user;
}
8. Ausencia de ConfigureAwait(false)
ConfigureAwait() no es un concepto especialmente fácil de comprender para nuevos desarrolladores, pero su correcta utilización puede ser crítica si estáis trabajando sobre una base de código síncrono que utiliza Result o Wait() para esperar la finalización de tareas asíncronas.Sin entrar en mucho detalle, el significado principal de
ConfigureAwait(true) es informar de que quiero que el código continúe ejecutándose en el mismo contexto de sincronización cuando mi tarea haya finalizado.Por ejemplo, en una aplicación WPF, el contexto de sincronización es el UI thread, y dado que sólo es posible actualizar componentes de la interfaz de usuario desde este hilo, casi siempre tendré que utilizar
ConfigureAwait(true) en mi código de UI, como se muestra a continuación:private async void OnButtonClicked()
{
var data = await File.ReadAllBytesAsync().ConfigureAwait(true);
this.textBoxFileSize.Text =
$"The file is ${data.Length} bytes long"; // needs to be on the UI thread
}
ConfigureAwait(true) se emplea por defecto en todas partes, por lo que podríamos eliminarlo en el ejemplo anterior y todo seguiría funcionando.Entonces, ¿para que querríamos utilizar
ConfigureAwait(false)? Pues por ejemplo por motivos de rendimiento. No siempre necesitamos continuar la ejecución en el mismo contexto de sincronización, y en estos casos será mejor si no forzamos a que todo el trabajo se haga en un hilo concreto. Por tanto, ConfigureAwait(false) debería utilizarse siempre que no nos importe dónde debe continuarse la ejecución, que es de hecho en muchas ocasiones, especialmente en código de bajo nivel que realice operaciones con archivos o llamadas a través de la red.Sin embargo, cuando combinamos código que utiliza contextos de sincronización,
ConfigureAwait(false) y llamadas a Result o Wait(), aparece el peligro de deadlocks. En estos casos, la fórmula recomendable para evitarlo es acordarse de utilizar ConfigureAwait(false) en todos los lugares donde explícitamente no sea necesario permanecer en el mismo contexto de sincronización.Por ejemplo, si vamos a crear una biblioteca propósito general para ser distribuida a través de NuGet, sería muy recomendable introducir
ConfigureAwait(false) en todas las llamadas asíncronas, porque no podemos estar seguros del contexto en el que serán utilizadas.Hay algunas buenas noticias en el horizonte. En ASP.NET Core ya no existe el contexto de sincronización, lo que implica que no necesitaremos utilizar
ConfigureAwait(false) con este framework, aunque sigue siendo recomendable cuando creemos paquetes NuGet.Pero si estáis trabajando en proyectos que corren riesgo de deadlocks, deberéis estar muy atentos y añadir las llamadas a
ConfigureAwait(false) en todas partes.9. Ignorar la versión asíncrona
En todos los métodos de .NET Framework que tardan cierto tiempo o que efectúan E/S en disco o red, casi siempre existe una versión asíncrona que puede ser utilizada en su lugar. Desafortunadamente las versiones síncronas de estos métodos se mantienen por motivos de retrocompatibilidad, pero rara vez encontraremos buenas razones para utilizarlas.Por ejemplo, es siempre mejor utilizar
Task.Delay() que Thread.Sleep(), dbContext.SaveChangesAsync() que dbContext.SaveChanges(), o fileStream.ReadAsync() que fileStream.Read(), pues de esta forma se liberarán hilos del thread pool para poder realizar otras tareas, permitiendo que tus aplicaciones procesen un mayor volumen de solicitudes.10. Usar try/catch sin await
Existe una optimización muy práctica que probablemente hayáis utilizado alguna vez. Supongamos que tenemos un método asíncrono muy simple, que sólo hace una llamada asíncrona en la última línea del mismo:public async Task SendUserLoggedInMessage(Guid userId)
{
var userLoggedInMessage = new UserLoggedInMessage() { UserId = userId };
await messageSender.SendAsync("mytopic", userLoggedInMessage);
}
async y await. Podríamos haber hecho simplemente lo siguiente, retornando la tarea directamente:public Task SendUserLoggedInMessage(Guid userId)
{
var userLoggedInMessage = new UserLoggedInMessage() { UserId = userId };
return messageSender.SendAsync("mytopic", userLoggedInMessage);
}
await la compilación genera una máquina de estados.Pero imaginemos que actualizamos el método de la siguiente manera:
public Task SendUserLoggedInMessage(Guid userId)
{
var userLoggedInMessage = new UserLoggedInMessage() { UserId = userId };
try
{
return messageSender.SendAsync("mytopic", userLoggedInMessage);
}
catch (Exception ex)
{
logger.Error(ex, "Failed to send message");
throw;
}
}
catch no está cumpliendo el cometido que podríamos esperar: no capturará las excepciones que pudieran lanzarse durante la ejecución de la tarea retornada por SendAsync(). Esto se debe a que, en realidad, sólo estamos capturando las excepciones lanzadas mientras se crea la tarea, que es muy distinto.Si quisiéramos capturar las excepciones lanzadas en cualquier momento durante esa tarea, necesitaríamos de nuevo la palabra clave
await:public async Task SendUserLoggedInMessage(Guid userId)
{
var userLoggedInMessage = new UserLoggedInMessage() { UserId = userId };
try
{
await messageSender.SendAsync("mytopic", userLoggedInMessage);
}
catch (Exception ex)
{
logger.Error(ex, "Failed to send message");
throw;
}
}
catch sí podrá capturar las excepciones lanzadas durante la ejecución de la tarea SendAsync().Conclusión
Hay muchas formas en la que uno puede provocar problemas implementando código asíncrono, por lo que vale la pena dedicar de tiempo a profundizar en la comprensión sobre threading. En este artículo simplemente he citado alguno de los problemas que encuentro con mayor frecuencia, pero estoy seguro de que podrían ser añadidos muchos más. No dudéis en dejar en los comentarios qué consejos adicionales añadiríais a esta lista.Si os gustaría aprender más sobre threading en C#, algunos recursos que os puedo recomendar son la reciente charla de Bill Wagner en NDC, el curso Getting Started with Asynchronous Programming in .NET de Filip Ekberg y, por supuesto, cualquier cosa escrita por el experto en asincronía Stephen Cleary.
Links:
- Artículo original: https://markheath.net/post/async-antipatterns
- Imagen de portada: Marco Verch
Fixed Buffer
Terraform: Dando forma a nuestra infraestructura
abril 09, 2019 08:00
Acabamos de terminar la serie sobre CI/CD, y en ella hemos hablado de lo importante que es mantener unas estrategias de trabajo que nos permitan la detección de errores rápidamente. Como colofón final, vimos como aprovisionar y desplegar en Azure Web Apps desde el Azure Pipelines (o desde otros sitios) y así despreocuparnos de esa parte utilizando las plantillas ARM.
Utilizar ARM es muy potente, pero quizás es algo tedioso de utilizar… ahí es donde entra terraform. ¿Y que es terraform podrás preguntarte? Pues es una herramienta multiplataforma hecha en Go que nos permite una gran abstracción sobre ARM, pero no solo funciona con ARM, admite una lista de proveedores bastante larga y que puedes consultar aquí.
Además de permitirnos trabajar de forma declarativa, sin tener que bajar al fango, aporta una gran ventaja respecto a usar ARM, y es que terraform mantiene el estado. Es decir, la herramienta es capaz de almacenar el estado de las cosas que ya están desplegadas, evitando volver a desplegarlas si no hay cambios. Pero hablar es fácil, y que yo te cuente que algo es mejor o peor no sirve de mucho, así que vamos a probarlo para ver lo sencillo que es.
Instalando terraform
Vamos a ir a su web y descargarnos el binario para nuestro sistema operativo. En la web nos indican que tenemos que añadir la ruta donde hayamos puesto el binario al PATH. (En mi caso, “C:/Terraform”):
Una vez que lo hayamos hecho, desde una terminal vamos a comprobar que todo esta bien ejecutando:
terraform version
Si todo está bien, debería devolvernos la versión actual. Si es así, ya tenemos terraform instalado. ¿A qué no ha sido tan difícil?
Aunque trabaja con ficheros *.tf que son texto plano, yo recomiendo utilizar Visual Studio Core con la extensión “Terraform“. Si tienes dudas sobre como instalar cualquiera de las dos, te dejo un enlace de CampusMVP donde explico cómo preparar un entorno de trabajo para .Net Core, al que solo hay que añadir la nueva extensión. Esto solo es una sugerencia, si prefieres utilizar cualquier otro entorno, o simplemente el block de notas y la terminal, todo funcionará igual de bien.
Creando nuestro código terraform
Para esta entrada, vamos a hacer un aprovisionamiento sencillo de una Azure Web App Windows, junto a su plan y su grupo de recursos desde terraform (para la siguiente vamos a hacer un escenario algo más complejo añadiendo un Sql Server a nuestra web). Para ello, vamos a crear un fichero al que llamaremos “main.tf” (el nombre no es importante). De hecho, terraform buscará todos los ficheros “*.tf” desde el nivel en el que se encuentre y unificará todos los archivos, por lo que es una buena idea separar los archivos por finalidades. En esta entrada vamos a utilizar un solo fichero para el código, pero una estructura más clara podría ser:
- webapp.tf para el código de la web.
- resourcegroup.tf para el código de grupo de recursos.
- variables.tf para las variables que vamos a necesitar.
Definiendo el proveedor
Lo primero que vamos a hacer, es definir el proveedor junto a las 4 variables que necesita (para utilizar las variables, se hace con el formato “${var.NOMBRE_VARIABLE}” ):
provider "azurerm" {
version = ">= 1.6.0"
subscription_id = "${var.ID_Suscripcion}"
client_id = "${var.ID_Aplicacion}"
client_secret = "${var.Password_Aplicacion}"
tenant_id = "${var.ID_Tenant}"
}
variable "ID_Suscripcion" {
description = "ID de la suscripción de Azure"
}
variable "ID_Aplicacion" {
description = "ID del la aplicación"
}
variable "Password_Aplicacion" {
description = "Secreto de la aplicación"
}
variable "ID_Tenant" {
description = "ID del directorio activo de Azure"
}
¿Y de dónde sacamos estos datos? Pues dos de ellas simplemente debemos consultarlas, para ello escribimos en la PowerShell:
az account list
Esto nos devolverá el ID de la suscripción y el directorio activo:
Para los dos campos de aplicación, lo que vamos a hacer es registrar una aplicación en nuestro directorio activo. Esto se puede hacer desde el portal de Azure, o desde la propia terminal ejecutando:
az ad sp create-for-rbac -n "NombreAplicacion"
Eso nos va a devolver los datos que nos faltan:
Si tienes problemas porque no se reconoce el comando “az”, sigue este enlace para instalar Azure CLI.
Definiendo el Grupo de Recursos
Una vez que lo tenemos, vamos a añadir un grupo de recursos para nuestra Web App:
resource "azurerm_resource_group" "webapp" {
name = "${var.resource_group_name}"
location = "${var.location}"
}
variable "location" {
description = "Region donde queremos que se cree"
}
variable "resource_group_name" {
description = "Nombre del grupo de recursos"
}
Definiendo el Service Plan
Ahora vamos a añadir el service plan:
resource "azurerm_app_service_plan" "webserviceplan" {
name = "${var.service_plan_name}"
location = "${azurerm_resource_group.webapp.location}"
resource_group_name = "${azurerm_resource_group.webapp.name}"
kind = "${var.plan_settings["kind"]}"
sku {
tier = "${var.plan_settings["tier"]}"
size = "${var.plan_settings["size"]}"
capacity = "${var.plan_settings["capacity"]}"
}
}
variable "plan_settings" {
type = "map"
description = "Definimos el tipo de plan que vamos a utilizar"
default = {
kind = "Windows" # Linux or Windows
size = "S1"
capacity = 1
tier = "Standard"
}
}
variable "service_plan_name" {
description = "Nombre del service plan"
}
Una de las ventajas que podemos ver, es que terraform nos permite utilizar datos de los propios recursos desplegados utilizando el formato “${TIPO_DE_RECURSO.NOMBRE_RECURSO.DATO}”. Por ejemplo, en:
location = "${azurerm_resource_group.webapp.location}"
Le estamos indicando que la localización del service plan, queremos que sea la misma que la del recurso “azurerm_resource_group” con el nombre “webapp”. Trabajando de esta manera, terraform es capaz de calcular el grafo de dependencias para que todo se pueda aprovisionar sin problemas.
Definiendo la Web App
Por último, solo nos queda añadir el Web App:
resource "azurerm_app_service" "webapp" {
name = "${var.name}"
location = "${azurerm_resource_group.webapp.location}"
resource_group_name = "${azurerm_resource_group.webapp.name}"
app_service_plan_id = "${azurerm_app_service_plan.webserviceplan.id}"
}
variable "name" {
description = "Nombre de la Web App"
}
Hay muchos parámetros, que podríamos poner en el propio código, pero entonces no sería reutilizable… Terarform nos permite indicarle todos estos parámetros cuando vayamos a hacer el despliegue en el propio comando, pero como puedes intuir, es muy tedioso. Así que vamos a utilizar otra de las opciones que nos da terraform, que es cargar tener un segundo fichero de variables con sus valores.
Si usas git, hay que añadirlo en el .gitignore o nuestras claves se irán al repositorio.
Para poder tener este fichero, creamos un segundo fichero con el formato “*.auto.tfvars”, por ejemplo, “variables.auto.tfvars”, donde iremos rellenando los valores de esta forma:
ID_Suscripcion = "----"
ID_Aplicacion = "----"
Password_Aplicacion = "----"
ID_Tenant = "----"
name = "postterraformbasic"
service_plan_name = "planpostterraformbasic"
resource_group_name = "postterraform"
location = "westeurope"
A la vista está que este código es más fácil de seguir y mantener que si fuese ARM directamente, aunque hay algunas cosas que no están soportadas aun, y puede hacer falta incluir algo de ARM en algunos casos…
Desplegando con terraform
Una vez que tenemos todo el código, y las variables listas, vamos a desplegar, para ello vamos a inicializar la herramienta con:
terraform init
Una vez hecho esto, vamos a comprobar si existe algún error con:
terraform validate
En caso de que no exista ningún error, lo siguiente es calcular los cambios (aunque este paso se puede omitir):
terraform plan
La salida de este comando nos va a mostrar algo como esto:
Como salida, nos da las acciones que va a ejecutar en detalle, pero solo son a nivel informativo, para ejecutar el despliegue, utilizamos:
terraform apply
Esto nos devuelve algo parecido al comando plan, donde nos dice que es lo que va a hacer, pero ahora, nos pide que confirmemos escribiendo “yes” si queremos que despliegue:
Tras escribir “yes”, se inicia el proceso. Una vez termine, la salida será algo asi:
Como terraform almacena el estado, si volvemos a intentar desplegar lo mismo, volviendo a ejecutar:
terraform apply
Obtenemos el resultado esperado, y nos dice que no hay ningún cambio pendiente:
Si por el contrario hubiésemos cambiado algo en el código, el resultado hubiese sido un cambio en nuestra infraestructura. Para terminar con las opciones que tenemos, existe una manera de eliminar los recursos desplegados:
terraform destroy
Volverá a pedirnos confirmación, y basta con que volvamos a escribir “yes”:
Conclusión
Aunque ha sido un ejemplo simple, se puede ver que terraform es una herramienta muy potente que nos quita mucho trabajo a la hora de desplegar infraestructura desde código al ser declarativo, persistir el estado y encima calcular las dependencias automáticamente. Existe una lista detallada de las opciones disponibles en la documentación oficial, a la cual recomiendo echarle un ojo.
En la próxima entrada vamos a ver un ejemplo más en profundidad creando una web en Linux conectada a un Sql Server, de modo que tengamos una infraestructura funcional, y además desplegaremos la web desde Azure Pipelines para poder comparar el proceso en el caso de ARM y en el caso de Terraform.
Si quieres ver el código completo, dejo un gist. También os dejo el enlace a un repo muy interesante de un workshop sobre terraform de un compañero.
**La entrada Terraform: Dando forma a nuestra infraestructura se publicó primero en Fixed Buffer.**
Variable not found
Enlaces interesantes 357
abril 08, 2019 06:25
Ahí van los enlaces recopilados durante la semana pasada, con mucho protagonismo del flamante Visual Studio 2019. Espero que os resulten interesantes. :-)Por si te lo perdiste...
- Ilities
José María Aguilar - El nuevo tipo de retorno ActionResult<T> en ASP.NET Core 2.1
José María Aguilar
.NET / .NET Core
- Modernize Your C# Code
Florian Rappl - Getting .NET Core 3 Preview to Work in Visual Studio 2019
Jeremy Clark - How to Beat Array Iteration Performance with Parallelism in C# .NET
Michael Shpilt - Making It Up as You Go Along with ExpandoObjects
Peter Vogel - Kirill’s Whitespace Guidelines for C#
Kirill Osenkov - Task.IsCompletedSuccessfully
Jeremy Clark - List vs IEnumerable vs IQueryable vs ICollection vs IDictionary
Mahsa Hassankashi - New C# 8 Features in Visual Studio 2019
Damir Arh - ConcurrentDictionary + closure = 💔
Gérald Barré
ASP.NET / ASP.NET Core
Choosing the right ASP.NET Core technology- Christian Nagel
- Creating Custom Constraints For Razor Pages Routes
Mike Brind - Conditionally include partial view in ASP.NET Core
Gunnar Peipman - Blazor: Building Components Manually via RenderTreeBuilder
Chris Sainty - Custom appsettings.json for ASP.NET Core integration tests & Using custom startup class with ASP.NET Core integration tests
Gunnar Peipman - Middleware in ASP .NET Core
Shahed Chowdhuri - Strongly Typed Feature Flags With ASP.NET Core 2.2
Ken Dale
Azure / Cloud
- Avoiding Azure Functions Cold Starts
Mark Heath - Reliably processing Azure Service Bus topics with Azure Functions
Alex Brown - 11 Awesome Resources for Building Your Applications in CI Using Azure DevOps Pipelines
John Papa - Learning Azure Functions: Mastering Blob Triggers and Queue Storage Triggers
Akhil Mittal - Resizing Images using Azure Functions
Anuraj Parameswaran - Using Azure Cognitive Service Computer Vision AI to read text from an image
Sibeesh Venu - The Curious Case of the JSON BOM
Jimmy Bogard - Web application firewall at Azure Front Door service
Teresa Yao
Conceptos / Patrones / Buenas prácticas
- C# Design Patterns - Command Design Pattern
Marinko Spasojevic
Data
- Replacing existing entity framework code with Dapper
Karthik Chintala - Using Data Protection in Entity Framework Core with Value Converters
Jiří Činčura
Machine learning / IA / Bots
- TensorFlow is dead, long live TensorFlow! – Hacker Noon
Cassie Kozyrkov - Drawing with Voice – Speech Recognition with TensorFlow.js
Nikola Živković - Custom AI Models with Azure Machine Learning Studio and ML.NET
Matt Hyon & Bernard Apolinario - Announcing ML.NET 1.0 RC - Machine Learning for .NET
César De la Torre
Web / HTML / CSS / Javascript
- Tipos Suma en TypeScript
Juan María Hernández - Simplifying Angular CLI for beginners
Dhananjay Kumar - Responsible JavaScript: Part IJeremy Wagner
- An Angular Roadmap - The Past, Present, and Future of Angular
Ryan Peden - Fixed Headers, On-Page Links, and Overlapping Content, Oh My!
Chris Coyier - Form Validation in Under an Hour with Vuelidate
Sarah Drasner - Managing Z-Index In A Component-Based Web Application
Pavel Pomerantsev - Undefined: The Third Boolean Value
Kushagra Gour
Visual Studio / Complementos / Herramientas
Visual Studio 2019: Code faster. Work smarter. Create the future.
John Montgomery
- Visual Studio 2019 for Mac is now available
Unni Ravindranathan
- Visual Studio 2019 .NET productivity
Kendra Havens
- Little great things about Visual Studio 2019
Mads Kristensen
- Introducing Time Travel Debugging for Visual Studio Enterprise 2019
Mark Downie
- Web and Azure Tool Updates in Visual Studio 2019
Angelos Petropoulos
- Using Git in Visual Studio has never been easier than in Visual Studio 2019
Thomas Claudius Huber
- Live Share now included with Visual Studio 2019
Jon Chu
- ¿Qué hay de nuevo en Visual Studio 2019?
Jorge Turrado
- Instalar Kubernetes Dashboard en tu clúster & Cómo usar kubectl proxy para acceder a tus aplicaciones & Acceder a tus aplicaciones en Kubernetes a través de NodePort
Gisela Torres
- Why NuGet Package Signing Is Not (Yet) for Me
Phil Haack
- Introducing OzCode V4: Never use F10 or F11 again
Omer Raviv
- Visual Studio Tips: Using Data Tips & Trace points & Keyboard Shortcuts for Debugging & Window Management
Jeremy Hutchinson
Otros
- Terminales y millones de colores: una historia complicada
Eduard Tomás - Esto es lo que pasa cuando intentas medir la productividad de un programador por las líneas de código que escribe al día
Txema Rodríguez - Microsoft Graph
Fernando Escolar - Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks
Samuel D. Crow
Blog Bitix
Trazabilidad en microservicios con Spring Cloud Sleuth
abril 07, 2019 10:45
En una aplicación distribuida con varios microservicios es imprescindible tener la configuración de forma centralizada que cada microservicio obtiene al iniciarse y disponer de registro y descubrimiento para que los servicios al iniciarse, terminarse, actualizarse o por un fallo se registren o desregistren y obtengan la ubicación de las dependencias que necesitan.
Otra de las funcionalidades esenciales en una aplicación distribuida es la trazabilidad de una petición, desde que entra por el API gateway pasando por las diferentes peticiones que hacen los microservicios por la red o envío de mensajes. Es necesaria la funcionalidad que relacione las trazas de todos los servicios para depuración o consulta en un futuro para dar visibilidad a las acciones que se realizan en el sistema.
¿Como se consigue relacionar las trazas de los microservicios que son independientes? La técnica que se emplea es asignar a cada petición entrante un identificativo, más bien un identificativo para la transacción de forma global y un identificativo para la transacción en cada microservicio que varía en cada comunicación de red.
Cuando un microservicio se comunica con otro envía en su petición el identificativo de la transacción global y el de su transacción. Si un microservicio no recibe estos identificativos los genera. En el protocolo HTTP estos identificativos se envían y reciben a través de las cabeceras. Los identificativos permiten correlacionar todas las trazas que emiten los diferentes procesos de los microservicios de una misma petición en la aplicación, haciendo una búsqueda global por el identificativo global se obtiene el conjunto de trazas que han emitido los microservicios por las que ha transitado una petición.
Para obtener mejor visibilidad de los tiempos y latencias se puede utilizar Zipkin, Prometheus junto con Hystrix o Resilience4j también dan visibilidad de los tiempos entre otras cosas.
En Java el proyecto Spring Cloud Sleuth proporciona la funcionalidad de trazabilidad. En el esquema se observa como Sleuth envía las cabeceras de un servicio cliente a un servicio servidor.
|
|
Sleuth se encarga de propagar las cabeceras del servicio cliente al servicio servidor automáticamente instrumentando los clientes HTTP de RestTemplate, AsyncRestTemplate, WebClient, Apache HttpClient y Netty HttpClient. Para enviar, recibir, obtener y establecer los identificativos de correlación con Sleuth junto con el cliente HTTP de Java hay que hacer la instrumentación manualmente con las clases Tracing y Tracer si no está entre los soportados como en el caso del cliente HTTP que se añadió en Java 11 en el propio JDK con el soporte para HTTP/2.
En la parte servidora Sleuth proporciona un filtro que se encarga de obtener y crear el span de la petición que contiene los identificativos de correlación que con Spring y las dependencias adecuadas se configura automáticamente. Para inyectar y extraer las cabeceras de Sleuth con el cliente HTTP de Java o como en el ejemplo con el de Jersey basta con proporcionar una lambda que realice el añadido o extracción de las cabeceras con la API del cliente.
Este es el código para instrumentalizar el cliente HTTP de Jersey que utiliza el servicio cliente que invoca al gateway y el código para crear el span en el cliente con los identificativos de correlación y recogerlos en el servicio servidor.
|
|
|
|
He utilizado el ejemplo de la serie de artículos sobre Spring Cloud añadiendo el soporte para Spring Cloud Sleuth. La aplicación se compone de un microservicio de configuración (con Spring Cloud Config), otro de registro y descubrimiento (con Eureka), un servicio de API gateway (con Zuul), el servicio de aplicación y un cliente del servicio que envía las peticiones al gateway y este las redirige al servicio de aplicación.
El cliente inicia un span que es enviado al servidor y el servidor obtiene las cabeceras enviadas. El cliente y el servidor son dos procesos distintos del sistema pero se observa que el identificativo global de la transacción traceId se mantiene en ambos y el identificativo de spanId cambia entre el cliente y el servidor.
|
|
Para iniciar los diferentes microservicios de la aplicación hay que utilizar los siguientes comandos.
|
|
En los proyectos hay que incluir la dependencia para Sleuth en la herramienta de construcción.
|
|
El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradle-run.sh.
Blog Bitix
El concepto de wildcard capture en Java
abril 05, 2019 03:45
Con la introducción de los generics en el lenguaje Java en la versión de Java 5 se añadió validación de tipos a por ejemplo las colecciones, y entre ellos los elementos wildcard definidos con un ?. Una lista definida como List<?> se considera una lista de elementos de un tipo desconocido, todas las colecciones pre-java5 se consideran a partir de Java 5 de forma efectiva como List<?> o List<? extends Object> a partir de Java 5.
El siguiente código produce un error de compilación con el mensaje capture of ya que el compilador no puede validar que el tipo que se inserta en la lista, Object, como primer elemento si es compatible en tiempo de ejecución con el tipo de elementos que tiene la lista:
|
|
|
|
El método bar() define como parámetro una lista raw y es capaz de extraer un Object ya que todo objeto hereda de él e insetar un Object ya que es una lista raw, el compilador realiza el type erasure y la considera como List<Object> pero el compilador advierte del posible error en tiempo de ejecución con el mensaje Note: WildcardError.java uses unchecked or unsafe operations, en este caso la advertencia es innecesaria ya que se inserta un elemento extraído de la propia lista, se puede suprimir anotando el método con @SuppressWarnings(“unchecked”).
Para establecer una relación entre dos tipos se deben usar type parameters, en este caso para el tipo que se extrae de la lista y el tipo insertado en la lista. Para que el código anterior compile hay que escribir un método que capture el tipo del wildcard, estos métodos por convención se nombran añadiendo al final la palabra Helper. En este caso otra alternativa es definir el método como en bar() aunque un List<?> y un List<T> no son lo mismo el primero admite más tipos de listas parametrizadas.
|
|
Este concepto de wildcard capture genera bastantes dudas y en internet hay múltiples artículos tratando de explicarlo.
- Why use a wildcard capture helper method? es la mejor explicación que he encontrado de wildcard capture.
- Wildcard Capture and Helper Methods
- Capturing wildcards in Java generics
- Java Generics Wildcard Capture - A Useful Thing to Know
- Java Generics: Wildcard capture misunderstanding
- Going wild with generics, Part 1
- Why use a wild card capture helper method?
- When to use generic methods and when to use wild-card?
Picando Código
Descarga gratis el número de abril de la revista Linux Journal
abril 03, 2019 07:08
La revista Linux Journal cumple 25 años. Para celebrarlo, pusieron para descargar gratis en su sitio web. Simplemente hay que visitar esta página, ingresar una dirección de correo electrónico, y recibir un enlace de descarga. Les recomiendo inscribirse al newsletter de la revista, semanalmente envían artículos de interés a los usuarios de GNU/Linux y el software libre en general.
Este número en particular viene bastante cargado, entre otras cosas dos entrevistas a Linus Torvalds por el primer editor de la revista, Robert Young (quien luego fundara Red Hat). La primera una entrevista actual donde Linus habla de varias cosas. Interesante saber que cuando necesita portabilidad, usa una Dell XPS 13, el mismo modelo que uso en el trabajo. La segunda entrevista es la republicación de una entrevista publicada originalmente en el primer número de Linux Journal en 1994, con los mismos protagonistas.
Además hay artículos sobre el futuro de Linux, Software Libre y los niños, Kubernetes, cómo armar tu propio radio receptor, y más.
Pueden pedir el enlace de descarga en: https://www.linuxjournal.com/free_issue
Picando Código
Se viene ScaLATAM: la primera conferencia focalizada en Scala y Programacion Funcional de Latinoamérica
abril 03, 2019 02:00
En mayo se organiza en Montevideo ScaLATAM: la primera conferencia focalizada en Scala y Programacion Funcional de Latinoamérica. Entre los oradores está Gabriel Claramunt, referente de la comunidad Scala y el culpable de que me empezara a interesar la programación funcional allá cuando éramos jóvenes y me apasionaba la programación. ¡Por más que no usen Scala les recomiendo asistir! Qué buenas conferencias está habiendo en Uruguay…
Más información:
El objetivo es reunir a developers, empresas y entusiastas en un ambiente pensado para el intercambio de conocimientos y aprendizaje. La conferencia consiste en dos días de charlas dadas por speakers reconocidos local e internacionalmente con experiencia y conocimiento de las nuevas tendencias. Elegimos Uruguay como sede ya que es uno de los principales exportadores de software y donde las empresas mas importantes de la región deciden instalarse. Si estás dando tus primeros pasos en Scala o si ya tenés experiencia, querés potenciar tus conocimientos y contactarte con empresas/personas que comparten tus intereses, esta conferencia es para vos!
Llamado a charlas
Está abierto el llamado a charlas para que envíes tu propuesta. Temas priorizados (pero no excluyentes, si tenés una idea, ¡enviala!): FP Foundations, FP Experience reports (Industrial adoption, Open source , Growing the Community), Scala Libraries and applications (Distributed systems, ML, Big Data), Development Workflow, Scala Tooling. Se puede en este enlace.
Entradas
Hay entradas generales a USD 30 y para estudiantes a USD 15 y se pueden comprar acá.
Dónde y cuándo
Jueves 2 y Viernes 3 de Mayo
Universidad ORT Uruguay, Cuareim 1451, Montevideo, Uruguay
Variable not found
¿Se pueden asociar varias interfaces a la misma instancia en el contenedor de servicios de ASP.NET Core?
abril 02, 2019 06:57
Hace unas semanas, el amigo J. Roldán escribía un comentario en el post Inyección de dependencias en ASP.NET Core con una pregunta interesante sobre la forma de registrar determinados componentes en el inyector de dependencias. Básicamente la duda que planteaba era cómo asociar distintas interfaces a una única instancia, algo que, aunque no es complicado de conseguir, tampoco tiene una solución precisamente intuitiva.El problema
En el escenario concreto que planteaba nuestro querido lector era que quería proporcionar, a los componentes que necesitaban acceder a datos en su aplicación, un acceso limitado al contexto de datos de Entity Framework.Para ello, por un lado definía una interfaz parecida a la siguiente, que proporcionaba acceso a los repositorios:
public interface IUserRepositories
{
DbSet<User> Users { get; }
...
}
public interface IUnitOfWork
{
int SaveChanges();
}
IUserRepositories, mientras que si necesitaba persistir datos, recibiría adicionalmente un objeto IUnitOfWork, por ejemplo:public class UserServices
{
...
public UserServices(IMapper mapper, IUserRepositories userRepos, IUnitOfWork uow)
{
_mapper = mapper;
_userRepos = userRepos;
_uow = uow;
}
public async Task Update(int id, UserDto user)
{
var user = await _userRepos.Users.FirstOrDefaultAsync(u=>u.Id == id);
if(user == null)
throw new Exception();
_mapper.Map(userDto, user);
await _uof.SaveChangesAsync();
}
}
Si, como es lo habitual, registraba ambos componentes como scoped, las instancias del contexto de datos que recibía eran distintas, por lo que los cambios realizados en una no eran visibles para la otra, aparte de la sobrecarga que supone crear dos contextos en cada petición:
// En ConfigureServices():
services.AddScoped<IRepositories, EfContext>();
services.AddScoped<IUnitOfWork, EfContext>();
// En UserServices:
public class UserServices
{
...
public UserServices(IUserRepositories userRepos, IUnitOfWork uow, IMapper mapper)
{
if(userRepos != uow) // userRepos contiene una instancia del contexto
throw new Exception("Ooops!"); // uow contiene otra instancia distinta del contexto
_mapper = mapper;
_userRepos = userRepos;
_uow = uow;
}
...
}
La solución
Obviamente, lo que hay que cambiar es la forma de registrar las interfaces, de forma que ambas estén asociadas a la misma instancia del contexto de datos, única en el ámbito de una petición.Para ello, podemos hacer lo que se muestra en el siguiente código:
services.AddScoped<IUserRepositories, EfContext>();
services.AddTransient<IUnitOfWork>(provider => (IUnitOfWork)provider.GetService<IUserRepositories>());
IUserRepositories a una instancia per request del contexto de datos EfContext. Hasta ahí, lo normal.La diferencia viene ahora: la interfaz
IUnitOfWork la registramos utilizando la sobrecarga que permite especificar la factoría que será utilizada para obtener la instancia, y desde ella retornamos el objeto que ya esté asociado a IUserRepositories.Sencillo, ¿verdad?
Publicado en: www.variablenotfound.com.
Variable not found
Enlaces interesantes 356
abril 01, 2019 11:18
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)Por si te lo perdiste...
- Adivina, adivinanza: ¿por qué no compila este código?
José María Aguilar - Inicializar a null propiedades sin tipo
José María Aguilar
.NET / .NET Core
- Accepting Partial Resources with Newtonsoft.Json
Florian Rappl & Manuel Römer - AutoMapper's Design Philosophy
Jimmy Bogard - Using .NET PInvoke for Linux system functions
Tom Deseyn - Hosting DI Container with .NET Core 3.0
Christian Nagel - C# Multithreaded Resource Access – Locks, Monitors and Mutex
John Demetriou - Migrating Delegate.BeginInvoke Calls for .NET Core
Mike Rousos - .NET Core Workers as Windows Services
Glenn Condron
ASP.NET / ASP.NET Core
- Securing ASP.NET Core in Docker
Muhammad Rehan Saeed - gRPC Bi-directional streaming with Razor Pages and a Hosted Service gRPC client
Damien Bowden - Keep Configure Methods Clean Using Extension Methods
K. Scott Allen - Accessing Configuration Settings from Multiple Sources
Jeeva Subburaj - Slack Slash Commands
David Pine - Getting Started with .NET Core and Docker and the Microsoft Container Registry
Scott Hanselman - Re-reading ASP.Net Core request bodies with EnableBuffering()
Jeremy Meng - Use Your ASP.NET Core App as an Executable
K. Scott Allen - Using FluentValidation for Forms Validation in Razor Components
Chris Sainty - Logging in ASP .NET Core
Shahed Chowdhuri - Blazor: Implementing Client Side Search As You Type Using bind-value-oninput
Scott Sauber - Managing Page Layouts in Blazor
Peter Vogel
Azure / Cloud
- AWS SDK for .NET now targets .NET Standard 2.0
Steven Kang - Returning HTTP Status Codes from Azure Functions
Jason Roberts - Azure Functions con docker
Fernando Escolar - Azure Blob Storage lifecycle management generally available
Yuan Zheng - High-Throughput with Azure Blob Storage
Claus Joergensen - Top 13 Cosmos DB Features Coming Soon as of March 2019
Chris Pietschmann - Azure AI Enhanced with Cognitive Services Updates
David Ramel - Generar las imágenes de Docker desde Azure Container Registry
Gisela Torres - End-To-End Testing in Azure Pipelines using Nightwatch.js
Florian Rappl
Conceptos / Patrones / Buenas prácticas
- C# Design Patterns - Decorator Design Pattern
Marinko Spasojevic - WTF is Big O Notation?
Rob Conery - La importancia de las convenciones de codificación: PascalCase, camelCase, snake_case y kebab-case
Jorge Serrano - Storing UTC is not a silver bullet
Jon Skeet - Cómo ser mejor programador (aparte de programando)
Manuel A. Lores
Data
Machine learning / IA / Bots
How to optimize and run ML.NET models on scalable ASP.NET Core WebAPIs or web apps
César De la Torre- Image Classification With TensorFlow.js
Nikola Živković - Three Popular Clustering Methods and When to Use Each
ODSC
Web / HTML / CSS / Javascript
- visibilityEvents.js: detectar cuando un elemento se muestra o se oculta en una página
José Manuel Alarcón - Understanding Event Emitters
Charles Peters - Tips for Debugging Your Angular Applications
Christian Nwamba - Vuex—The Deep Dive
Nosa Obaseki - Push Notifications in ASP.NET Core Angular Applications
Tomasz Peczek - Breaking CSS Custom Properties out of :root Might Be a Good Idea
Kevin Powell - Tracking changes in Chrome DevTool Sources
Christian Nwamba - Creating a Vuex Plugin
Shawn Wildermuth - An Illustrated (and Musical) Guide to Map, Reduce, and Filter Array Methods
Una Kravets - Responsible JavaScript: Part I
Jeremy Wagner - How To Align Things In CSS — Smashing Magazine
Rachel Andrew - The shortest way to conditional insert properties into an object literal
Andrea Simone Costa - Announcing TypeScript 3.4
Daniel Rosenwasser - You probably don't need input type=“number”
Brad Frost - Creating a Reusable Pagination Component in Vue
Mateusz Rybczonek
Visual Studio / Complementos / Herramientas
- Herramientas de desarrollo: Azure Pipelines (CD)
Jorge Turrado - TRUCO: mostrar en línea la definición de un método en Visual Studio y Visual Studio Code
José Manuel Alarcón 
Visual Studio Tips: View Uncaptured Exception & Evaluate a Function Without Side Effects & Source Map in the Scroll Bar & Solution Explorer Search
Jeremy Hutchinson- Visitor pattern navigation support with ReSharper
Anders Malmgren - How to Test Live Services with Fiddler AutoResponder
Miroslav Shtilianov - Visual Studio Tips - Breakpoints
Jeremy Hutchinson - Recommended VS Code Extensions for Angular Developers
John Papa - Ejecutar contenedores de Docker en Kubernetes
Gisela Torres - F7 is the greatest PowerShell hotkey that no one uses any more. We must fix this.
Scott Hanselman
Otros
- Java 12 lanzado: versión descafeinada sin soporte a largo plazo
José Manuel Alarcón - Calling Conventions
Michal Franc - What does the N in nmake stand for?
Raymond Chen
Koalite
Tipos Suma en TypeScript
abril 01, 2019 05:06
A veces da la sensación de que TypeScript se usa “sólo” como una forma de tener Javascript con intellisense y errores de compilación. La verdad es que, sólo por eso, ya puede merecer la pena, pero si nos quedamos ahí nos estamos perdiendo parte de las ventajas que nos puede aportar a la hora de diseñar soluciones.
Quizá el sistema de tipos de TypeScript no sea el mejor del mundo y presente sus problemas a la hora de mantener invariantes o no tenga toda la solidez que a uno le pudiera gustar, pero eso no es óbice para que ofrezca alternativas de diseño interesantes, sobre todo comparado con las que solemos ver en lenguajes como C# o Java.
En este post vamos a ver cómo podemos aprovechar varias características del sistema de tipos, concretamente los tipos literales y los tipos unión, para conseguir un diseño más seguro.
Tipos literales
Se le llama tipo literal en TypeScript a aquel tipo que contiene un único valor de tipo string, number, boolean o enum. Por ejemplo:
type Two = 2; type Duck = 'Duck'; const x: Two = 2; // OK const y: Two = 3; // Error const a: Duck = 'Duck'; // OK const b: Duck = 'Fox'; // Error
A primera vista no parece algo muy útil porque todas las variables que definamos del tipo tendrán el mismo valor, pero cuando los combinamos con otros tipos la cosa mejora.
Las reglas de inferencia de tipos para los tipos literales son un poco confusas (y han cambiado alguna vez a lo largo de la vida de TypeScript), por lo que hay que andarse con un poco de ojo:
let x = 2; // el tipo inferido para x es "Number" const x = 2; // el tipo inferido para x es 2
Por supuesto, un valor de un tipo literal es asignable a valores del tipo “general”, pero no a la inversa:
const x: Two = 2; const y: Number = x; // OK const z: Two = y; // Error
Tipos unión
En TypeScript podemos definir un tipo formado por la unión de otros tipos, es decir, a una variable del tipo unión podemos asignarle cualquier valor de cualquiera de los tipos que forman la unión:
type StringOrNumber = String | Number; let a: StringOrNumber = 2; // OK let b: StringOrNumber = 'Mar'; // OK let c: StringOrNumber = null; // Error
Como no, nuestros tipos literales pueden formar parte de uniones:
type DuckOrTwo = 'Duck' | 2; let a: DuckOrTwo = 2; // OK let b: DuckOrTwo = 'Duck'; // OK let c: DuckOrTwo = 142.12; // Error
Esto facilita interoperar con apis Javascript donde es frecuente que algún parámetro pueda tomar un conjunto de valores primitivos. Un caso típico sería el método addEventListener para registrar manejadores de eventos, al cual se le pasa el nombre del evento para el que se quiere registrar el manejador.
Tipos suma
Juntando los tipos literales y los tipos unión podemos construir el equivalente a tipos suma. Estos tipos pueden almacenar información de distintos tipos, y existe una forma de detectar cuál de los posibles tipos almacenan.
Dicho así suena un poco enrevesado, pero es fácil entenderlo con un poco de código. Imagina que necesitas representar un valor opcional. Para ello hace falta indicar de alguna forma la ausencia de valor, algo que muchas veces se hace utilizando null o undefined, pero esa alternativa no siempre es aconsejable. Podemos mejorarlo haciendo algo así:
type Optional<T> = { empty: true } | { empty: false, value: T };
function f(x: Optional<number>) {
if (x.empty === true) {
// Tipo inferido { empty: true }
console.log(x.value); // error de compilación
}
else {
// Tipo inferido { empty: false, value: number }
console.log(x.value * 2);
}
}
Es un poco feo tener que escribir el x.empty === true, pero sin eso el sistema de tipos de TypeScript no es capaz de acotar el tipo correcto en cada rama del if.
Todo esto podemos aplicarlo a cosas algo más interesantes que Optional. Veamos otro ejemplo en el que tenemos usuarios con una dirección de correo asociado y queremos que no se les pueda enviar emails hasta que la dirección de correo haya sido verificada.
Modelar esto en C# con una cierta seguridad de tipos es relativamente incómodo y nos obliga a utilizar varias clases y alguna relación de herencia por el camino. En TypeScript es bastante sencillo:
type VerifiedEmail = { verified: true, address: string };
type UnverifiedEmail = { verified: false, address: string };
type Email = VerifiedEmail | UnverifiedEmail;
type User = { name: string, email: Email };
function sendEmail({ address }: VerifiedEmail) {
// TODO: Enviar email
}
function verifyEmail({ address }: UnverifiedEmail) {
// TODO: Verificar el email
}
let u: User = getUserFromSomewhere();
sendEmail(u.email); // Error. Email podría no estar verificado
if (u.email.verified === true)
sendEmail(u.email);
else
verifyEmail(u.email);
De esta forma es fácil crear tipos más restrictivos que nos permitan limitar las operaciones disponibles en cada caso y nos obliguen a tener en cuenta todos los escenarios posibles.
En realidad, como decíamos antes, lo único que estamos haciendo es implementar tipos suma de una forma un tanto rebuscada, usando un valor dentro del tipo como discriminador en lugar de usar constructores como haríamos, por ejemplo, en Haskell donde nuestro tipo Email se definiría así:
data Email = VerifiedEmail address | UnverifiedEmail address
En lugar de utilizar un flag para distinguir entre los dos estados de Email se utilizan distintos constructores, VerifiedEmail y UnverifiedEmail para diferenciar un tipo de correo de otro.
Conclusión
TypeScript no es la panacea y tiene un montón de cosas discutibles (soy el primero que se suele quejar de ello), pero también ofrece posibilidades interesantes.
Desgraciadamente, en el mundo del frontend es muy frecuente “no diseñar” y limitarse a aplicar los patrones indicados por el framework o librería de turno (react, vue, redux, angular…). Eso hace que TypeScript se vea sólo como una forma de tipar estáticamente las llamadas a estas herramientas y no se intente aprovechar realmente la capacidad de diseño que permite su sistema de tipos.
Como vimos al hablar de las clases como code smell, es importante utilizar cada lenguaje sacando partido a sus características en lugar de limitarse a traducir de un lenguaje a otro. Si tu uso de TypeScript se reduce a emplear las mismas técnicas que en Javascript (pero con intellisense) o los mismos diseños que en C# (pero ejecutándose en un browser), te estás perdiendo gran parte de sus ventajas.
Posts relacionados:
- Extender tipos existentes en TypeScript
- TypeScript: varianza y solidez
- Mantenimiento de invariantes en TypeScript
Blog Bitix
Ejemplo de máquina de estados con Spring Statemachine
marzo 31, 2019 09:00
Hace ya unos años escribí un ejemplo y un artículo con una implementación propia de una máquina de estado en Java, para algún caso muy básico puede ser suficiente pero para algo serio no es la opción a elegir. Pasado un tiempo de ese ejemplo y artículo descubrí uno de los muchos proyectos de Spring útiles para una aplicación, para las necesidades más habítuales tiene un proyecto que lo proporciona y para las menos habituales es también posible que la proporcione como en el caso del proyecto Spring Statemachine que precisamente tiene el mismo objetivo de implementar una máquina de estados cubriendo muchos casos de uso.
El uso de una máquina de estados permite modelar un proceso con cierta complejidad. Puede ser el ciclo de vida de una compra, un envío, un proceso documental, financiero, … cualquiera en el que intervengan estados, transiciones entre esos estados y realización de acciones necesarias para proporcionar la funcionalidad deseada.
Una máquina de estados se compone de un conjunto de estados finito, de transiciones en esos estados, de eventos que disparan las transiciones y cambios de estado, de acciones asociadas a los estados, a las transiciones o a la entrada o salida de un estado, guards que permiten decidir que transición se escoge entre varias en los choices, forks en las que el flujo sigue por varios caminos en paralelo, temporizadores que pasado un tiempo disparan una transición, seguridad para proteger la ejecución de eventos, transiciones y acciones con Spring Security, persistencia tanto para la configuración como para el estado en bases de datos relacionales o NoSQL como Redis y MongoDB. Una lista bastante completa de características que cubrirá las necesidades de la mayoría de aplicaciones.
Aparte de proporcionar una librería para crear máquinas de estados en Java otra ventaja es que el fujo de un proceso queda recogido y documentado en la implementación de la máquina de estados. De que estados, transiciones y eventos se compone en un punto más centralizado lo que en otro caso podría estar repartido por el código de la aplicación utilizando una solución propia codificada expresamente para el caso.
En el ejemplo he definido el siguente grafo de estados y transiciones que contiene estado inicial, choice, fork, join, jerarquía de estados con en el estado Tasks y un estado final. Una selección completa del conjunto de tipos de estados. En este caso las flechas van únicamente en una dirección pero perfectamente el flujo podría tener transiciones que volviesen a estados anteriores creando ciclos.
Grafo de la máquina de estados
El uso de Spring Statemachine es relativamente sencillo. En el ejemplo se define en un enumerado la lista de estados, también la lista de eventos o transiciones. Una de las formas de definir el grafo dela máquina de estados es mediante código Java y utilizando Spring definiendo un bean. La clase StateMachineBuilder facilita la construcción de la definición de la máquina de estados, por una parte está la configuración general o de infraestructura con el método configureConfiguration(). Con el método configureStates() se define los estados de la máquina y su tipo (inicial, final, normal, choice, fork, join,) así como las acciones que se deseen ejecutar al entrar, en el estado y al salir del estado con los métodos stateEntry(), stateDo() y stateExit(). Con el método withStates()() se pueden definir submáquinas o una jerarquía de estados como en el caso del estado Tasks. Finalmente hay que definir cuales son las posibles transiciones de los estados y que eventos las disparan. Normalmente las transiciones se definen con el método withExternal() pero en los casos de los estados de tipo choice, fork y join se define con los métodos withChoice(), withFork() y withJoin().
|
|
Las acciones asociadas a los estados del ejemplo simplemente emiten trazas pero tienen disponible el parámetro context para obtener datos e implementar su lógica, como es un componente de Spring podría incluso hacer uso de inyección de dependencias para utilizar otros servicios que necesitase.
|
|
|
|
En el caso de un choice se utilizan los métodos first(), then() y last() que una cláusula guard en los dos primeros determinan a que estado se transiciona. Una clásula guard es una instancia de la clase Guard que contiene un método que devuelve un boolean según su lógica. Si es verdadero se seleciona el estado asociado, para la lógical se puede utilizar la información de contexto StateContext entre otra información como la que se haya asociado en los diferentes estados con el método getExtendedState() y la proporcionada en la ejecución del evento con getMessageHeaders().
|
|
En este ejemplo se utiliza Spring Boot, aparte de las configuraciones anteriores se realizan dos cosas adicionales. Una de ellas es utilizar un ThreadPoolTaskScheduler en modo demonio de modo que la máquina virtual y el programa pueda finalizar correctamente. La otra es que con una implementación de la clase StateMachineListenerAdapter se pueden recibir que acciones realiza la máquina de estados, en este caso para emitir trazas.
|
|
Una vez definida la máquina de estados su uso comienza con el método start(), a continuación ya se pueden enviar eventos par provocar cambios de estado y ejecución de acciones. Se puede proporcionar información de contexto para la máquina accesible desde cualquier estado en el mapa obtenido con ExtendedState.getVariables() y al provocar eventos con la clase GenericMessage. En cualquier momento el método getState() devuelve en que estado se encuentra la máquina. Según la rama que haya elegido la clase RandomGuard en la bifurcación y el estado en el que esté la máquina se envía la transición CHOICE1_FORK o CHOICE2_FORK. El fork provoca que la máquina de estados ejecute en paralelo dos caminos, enviados los eventos correctos se llega a los estados finales de las dos ramas del subestado y se pasa automáticamente al estado JOIN que a su vez pasa automáticamente a STATE2, finalmente se pasa al estado END y termina la máquina de estados.
|
|
Otro caso de uso posible es en vez de iniciar la máquina de estados desde el inicio es iniciarla en un determinado estado para continuar con el flujo de una entidad que anteriormente se quedó en ese estado. En el caso del ejemplo la máquina de estados se continua desde el estado TASK11 y TASK22 utilizando el método resetStateMachine(), se vuelve a iniciar la máquina y se envían los eventos adecuados a partir de esos estados.
|
|
Por defecto el contenedor de dependencias de Spring utiliza el @Scope singleton para los beans de modo que solo existe una única instancia, como las máquinas tiene estado no pueden compartirse, hay que crear una nueva en caso de querer utilizar dos simultáneamente como sería el caso de una aplicación web o un proceso que escucha mensajes de una cola, utilizando el scope prototype se crea una instancia cada vez que se necesite. La creación de más máquina de estado se indica en la documentación que es algo costoso para no tener que crearlas, tener varias instancias y limitado a cierto número se puede utilizar un pool de máquinas de estado.
En un cambio de estado se produce la siguiente secuencia de eventos y acciones.
- Se notifica del inicio de la transición.
- Se ejecuta la acción asociada a la transición.
- Se notifica de la transición, de la salida del estado anterior y de la entrada en el nuevo.
- Se ejecuta la acción de entrada al estado y del estado.
- Se notifica del cambio de estado.
- Se notifica de la finalización de la transición.
|
|
Estas son las dependencias necesarias a añadir n la herramienta de construcción y la salida en la terminal de las trazas ejecutando la máquina de estados desde el estado inicial e inicializada desde un estado en concreto.
|
|
|
|
|
|
El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradle run.
proyectos Ágiles
Master en Agile – MMA 2019
marzo 31, 2019 02:09
En octubre de 2019 se iniciará el Barcelona una nueva edición del Postgrado en Métodos Ágiles (PMA) y otra del Máster en Transformación Agile (MTA) en La Salle (Universitat Ramon Llull), el primero a nivel mundial sobre Agile.
Tras 6 exitosas ediciones, este año cuenta con diversas novedades, entre las que se incluyen, dentro del PMA, el Certified Scrum Master (CSM) de la Scrum Alliance y el Team Kanban Practitioner (TKP) de la Lean Kanban University.
Otras novedades, dentro del MTA, son los contenidos sobre Visual Management Framework (VMF- Agile para cualquier área) y escalado con Kanban.
Esta es una oportunidad única para aprender de profesionales de primer nivel, con varios años de experiencia específica en Agile, aplicando principios y métodos ágiles en contextos diversos, especializándose en aspectos concretos, investigando sobre nuevas técnicas y ponentes en conferencias nacionales e incluso internacionales.
PMA – Postgrado en métodos Ágiles
| Asignaturas | Temas | Profesores |
| Fundamentos & Inception |
Principios y métodos más conocidos (Scrum, Lean, Kanban y XP). Facilitadores e impedimentos. Inception y conceptualización ágil de proyecto. |
Silvia Sistaré Agustín Yagüe |
| Scrum y Kanban | Estimación y planificación ágil, framework de Scrum, retrospectivas, Kanban, métricas ágiles, herramientas ágiles físicas, radiadores de información. | Tiago Garcez Teodora Bozheva |
| Personas y equipos | Gestión de personas, gestión de conflictos, motivación e incentivos, facilitación compartida, contratación ágil, facilitación gráfica. | Steven Wallace |
| Agile Product Management |
Design Thinking. Lean Startup & Agile Product Management |
|
| Ingeniería Ágil, TDD, BDD, Legacy code |
User eXperience y prototipado en Agile. ALM ágil, eXtreme Programing, Software Craftsmanship, testing ágil. Desarrollo guiado por pruebas (de aceptación y unitarias). Cómo trabajar con código heredado y reducir la deuda técnica. |
Marc Pifarré |
| Trabajo Final de Postgrado | Durante el Postgrado se elaborará un caso práctico de introducción de los contenidos en una empresa, organizándose en equipos multidisciplinares de alumnos utilizando Scrum. |
MMA – Master en Métodos Ágiles
Este máster está especializado en Business Agility, agilidad organizacional y transformación. Incluye todas las asignaturas del Postgrado (PMA) y, adicionalmente, las siguientes:
| Asignaturas | Temas | Profesores |
| Enterprise Learning & personal efficiency |
Comunidades de Práctica, Open Spaces, Talent development, gamification. Productividad y aprendizaje personal. |
Steven Wallace Manuel Lopez Jordi Molla |
| Lean Thinking & Agile Management |
Lean y escalado con Kanban Visual Management Framework (VMF- Agile para cualquier área) Agile-Lean Management |
|
| Coaching y Cultura |
Coaching de equipos, liderazgo. Tipos de cultura empresarial, gestión del cambio organizativo. |
|
| Continuous Transformation |
Enterprise continuous improvement. Agile Rollout. Contratos ágiles. Enterprise software development & DevOps |
|
| Scaling Agile |
Escalado (LESS, Spotify, Nexus, SAFe), desescalado y auto-organización empresarial (reinventing organizations, sociocracy, …). Impact Mapping, Product Portfolio Management, Roadmapping, Budgeting for Agile |
|
| Trabajo Final de Máster | Durante el Máster se elaborará un caso práctico de introducción y aplicación de Agile en una empresa, incluyendo la parte de transformación organizativa y de cultura |
Algunos comentarios de los alumnos en ediciones anteriores: “Cuando se acaba la clase, estamos ya esperando a que llegue la semana que viene para ver un nuevo tema con el siguiente profesor”. “Muy práctico”. “La calidad y diversidad de puntos de vista entre los profesores le aporta mucho valor”. Más detalles en: Mejora de la situación laboral los alumnos del PMA trans un año.
El Máster tendrá una duración de un año académico y se realizará viernes tarde y sábado por la mañana.
–> Ver también cuál ha sido la Mejora de la situación laboral de los alumnos tras un año y los Principales aspectos valorados por los alumnos.
Mascando Bits
Cómo subir un paquete a PyPI
marzo 28, 2019 07:05
Recientemente un compañero mío quería distribuir una pequeña librería en Python que había escrito. En lugar de forzar a los desarrolladores a clonar su repositorio, quería que pudieran instalarse la librería con un sólo comando “pip install“. Planteamiento muy interesante que se formaliza con el concepto de gestor de paquetes.
Un gestor permite un uso más inteligente, ágil y seguro de las dependencias y ayuda tanto al que distribuye el paquete como al que lo usa, resolviendo problemas como el versionado, la cadena de dependencias dentro del paquete, la instalación…
Quisiera a fin de fomentar el uso del gestor de paquetes de Python llamado pip, que usa como repositorio oficial PyPI (Python Package Index), generar una guía lo más completa posible. 
Me gustaría remarcar que con ello no quiero ni pretendo incentivar que cualquiera se dedique a subir de cualquier forma lo primero que se lo ocurra. Aludo a la responsabilidad de cada uno, para no convertir PyPI en un vertedero de paquetes de dudosa calidad.
¿Qué es PyPI?
Desde la web oficial:
PyPI — Índice de Paquetes Python
El Índice de Paquetes Python es un repositorio de software para el lenguaje de programación de Python.
¿Has programado algo genial? ¿Quieres que otros puedan instalarlo con easy_install o pip? Pon tu código en PyPI. Es una gran lista de paquetes de Python donde debes enviar tu paquete para que pueda instalarse fácilmente con uno sólo comando.
La buena noticia es que enviar un paquete a PyPI en la teoría es muy simple: registrarte y cargar tu código, todo de manera gratuita. La mala noticia es que en la práctica es un poco más complicado que eso 
. La otra buena noticia es que he escrito esta guía 
y que, si estás atascado, siempre puedes consultar la documentación oficial 
.
He escrito esta guía con los siguientes supuestos:
- El módulo / biblioteca / paquete que está enviando se llama mypackage.
- mypackage está alojado en GitHub.
Crear tu cuenta
Crea una cuenta en PyPI Live y también en PyPI Test. Debes crear una cuenta para poder cargar tu código. Te recomiendo usar el mismo correo electrónico y contraseña para ambas cuentas, sólo para hacerte la vida más fácil cuando llegue el momento de subir tu código. Ambas plataformas son idénticas, siendo la de test una réplica de la oficial para que pruebes a subir tus paquetes.
Crear un archivo de configuración .pypirc
Este archivo contiene su información para la autenticación con PyPI, tanto la versión en vivo como la versión de prueba.
[distutils] index-servers = pypi pypitest [pypi] repository=https://upload.pypi.org/legacy/ username=your_username password=your_password [pypitest] repository=https://test.pypi.org/legacy/ username=your_username password=your_password
Esto es sólo para hacer tu vida más fácil, para que cuando llegue el momento de subir el código de de tu paquete no tengas que recordar/escribir tu nombre de usuario y contraseña. Asegúrate de poner este archivo en tu carpeta de inicio de tu sistema GNU/Linux; tu ruta debe ser:
~/.pypirc
Debido a que este archivo contiene tu nombre de usuario y contraseña, es posible que desees cambiar sus permisos para que sólo tú puedas leerlos y escribirlos. Desde la terminal, ejecuta:
chmod 600 ~/.pypirc
Si por el contrario te encuentras en un sistema Windows genera el archivo .pypirc en la carpeta de tu usuario en C:\Users\usuario con el siguiente comando:
type nul > your_file.txt
Notas sobre usernames / passwords
En Python 3, si tu contraseña incluye un % sin procesar, debes generar una secuencia de escape duplicándolo. El analizador de configuración de .pypirc interpola las cadenas de texto. Por ejemplo, si tu contraseña es hello%world:
[pypi] repository=https://pypi.python.org/pypi username=myusername password=hello%%world
Nunca me he encontrado con este problema, pero si te ocurre, esto podría ayudar.
Este comportamiento de escape ha sido parcheado y ya no es necesario hacerlo, pero si ves un error con un código de respuesta de:
403: Invalid or non-existent authentication information
Intenta eliminar la secuencia de escape de los signos de porcentaje en tu contraseña.
Si tu contraseña incluye espacios, asegúrese de no entrecomillarla. Por ejemplo, si tu contraseña es me encanta Mascando Bits:
[pypi] repository=https://pypi.python.org/pypi username=myusername password=me encanta MascandoBits
Preparar el paquete
Cada paquete en PyPI necesita tener un archivo llamado setup.py en la raíz del directorio. Si estás utilizando un archivo README en formato markdown, también necesitará un archivo MANIFEST.in. Además, es recomendable elegir una licencia para tu paquete reflejada en un archivo LICENSE que describa lo que se puede hacer con tu código. Entonces, si por ejemplo he estado trabajando en una biblioteca llamada mypackage, la estructura de mi directorio se vería tal que así:
root-dir/ # nombre de directorio de trabajo aleatorio
setup.py
MANIFEST.in
LICENSE.txt
README.md
mypackage/
__init__.py
foo.py
bar.py
baz.py
A continuación un desglose de lo que va en cada archivo:
setup.py
Son los metadatos de la librería necesarios para generar el paquete.
from setuptools import setup
setup(
name='mypackage',
packages=['mypackage'], # Mismo nombre que en la estructura de carpetas de arriba
version='0.1',
license='LGPL v3', # La licencia que tenga tu paqeute
description='A random test lib',
author='RDCH106',
author_email='contact@rdch106.hol.es',
url='https://github.com/RDCH106/mypackage', # Usa la URL del repositorio de GitHub
download_url='https://github.com/RDCH106/parallel_foreach_submodule/archive/v0.1.tar.gz', # Te lo explico a continuación
keywords='test example develop', # Palabras que definan tu paquete
classifiers=['Programming Language :: Python', # Clasificadores de compatibilidad con versiones de Python para tu paqeute
'Programming Language :: Python :: 2.7',
'Programming Language :: Python :: 3.3',
'Programming Language :: Python :: 3.4',
'Programming Language :: Python :: 3.5',
'Programming Language :: Python :: 3.6',
'Programming Language :: Python :: 3.7'],
)
El parámetro download_url es un enlace a un archivo alojado con el código de tu repositorio. Github alojará esto para ti, pero solo si creas una etiqueta git tag. En tu repositorio, escribe en la línea de comandos:
git tag v0.1 -m "Agrega una etiqueta para que podamos poner esto en PyPI"
Luego, escribe el siguiente comando para mostrar la lista de etiquetas:
git tag
Deberías ver v0.1 en la lista.
Por último escribe el siguiente comando para actualizar tu código en Github con la información de etiqueta más reciente:
git push --tags origin master
Github creará archivos comprimidos para descargar en https://github.com/{username}/{package_name}/archive/v{tag}.tar.gz.
MANIFEST.in
Incluye archivos que se empaquetarán en al distribución del paquete.
include LICENSE.txt README.md
LICENSE.txt será el archivo que contiene la licencia y README.md será el fichero que contenga la información básica (instalación, uso…) que quieras distribuir con tu paquete.
Subir tu paquete a PyPI Test
Ejecuta:
python setup.py sdist upload -r pypitest
No debería recibir ningún error si seguiste los pasos hasta este punto, y ahora también deberías poder ver tu paquete en el repositorio PyPI de prueba. Si hay algo que no te gusta este es el momento de hacer los cambios que quieras. Eso sí, para subir el paquete de nuevo tendrás que editar el número de versión para que sea distinto al de la anterior vez.
PyPI te permite borrar las versiones del paquete y subir todos las versiones que quieras, pero no editar una versión de tu paquete subida. Esto es para mantener la estabilidad de las dependencias. Es posible retirar una versión, creando la consecuente ruptura de dependencias, pero no se deja modificar para una versión de un paquete por no desvirtuar el sentido mismo del versionado.
Es posible que en algunas guía o documentación hayas visto que también se hace previo al upload un comando register:
python setup.py register -r pypitest
Ya no es necesario y no está soportado:
https://packaging.python.org/guides/migrating-to-pypi-org/#registering-package-names-metadata
Subir tu paquete a PyPI Live
Ejecuta:
python setup.py sdist upload -r pypi
Y ya, !lo has hecho! 
Has publicado tu primer paquete en PyPI y podrá ser instalado con el gestor de paquetes pip o cualquier otro como conda.
Fixed Buffer
Herramientas de desarrollo: Azure Pipelines (CD) y ARM
marzo 26, 2019 09:00
Todo lo que empieza tiene un final, y hoy es el final de la serie sobre “Integración Continua y Despliegue Continuo” (CI/CD). Hoy vamos a hablar sobre cómo hacer una integración y despliegue completos sobe Azure Web Apps de un proyecto ASP NET Core con Azure Pipelines.
Para poder hacerlo, lo primero que necesitamos es aprovisionar los recursos en Azure, y hay varias maneras de hacerlo. Hablo de ellas en Variable Not Found:
En este caso, vamos a utilizar el sistema de aprovisionamiento desde AzureRM para crear el plan, la webapp y una segunda ranura que será donde hagamos el deploy de nuestro proyecto para cambiarlo después a producción. Utilizando este sistema vamos a conseguir que nuestro proyecto esté siempre online incluso mientras se hace la publicación, ya que vamos a publicar sobre una segunda ranura y solo después de que nuestro proyecto este publicado y online, haremos el cambio entre ranuras (internamente hace un cambio de DNS, por lo que el cambio es instantáneo). Una vez dicho esto, ¡vamos a meternos en faena!
Creando la integración continua
Dentro de esta serie, publique como hacer la integración de nuestro proyectos en Azure Pieplines, así que nos vamos a saltar esa parte. El fichero .yml podría ser algo como esto:
# Configuramos el pool con la imagen
pool:
vmImage: 'ubuntu-16.04'
# Variables de trabajo
variables:
buildConfiguration : 'Release'
project : '**/*.csproj'
# Pasos
steps:
# Restore Nuget
- task: DotNetCoreCLI@2
displayName: Restore
inputs:
command: restore
projects: '$(project)'
# Compilamos el proyecto
- task: DotNetCoreCLI@2
displayName: Build
inputs:
projects: '$(project)'
arguments: '--configuration $(buildConfiguration)'
# Aquí van las pruebas unitarias
# ------
# Publicamos la solución indicándole que queremos zipearla
- task: DotNetCoreCLI@2
displayName: Publish
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(buildConfiguration) --output $(build.artifactstagingdirectory)'
zipAfterPublish: True
# Subimos los artefactos
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
Creando el despliegue continuo en Azure Pipelines
Con esto, ya tenemos nuestra integración funcionando y subiendo los artefactos, ahora solo falta el despliegue. La manera más sencilla quizás sea desde la propia ventana de resultados de la integración, pulsando sobre el botón Release:
Eso nos va a lanzar a una nueva página donde vamos a crear el pipeline. Por defecto nos va a dar muchas opciones, pero vamos a hacerlo desde 0, así que elegimos “empty job”:
Esto va a crear un job vacío, en el cual vamos a añadir todos los pasos que necesitamos. En nuestro caso son 3:
- Aprovisionar los recursos.
- Desplegar nuestro proyecto a una ranura de staging
- Cambiar las ranuras de staging y producción.
Para eso, vamos a pulsar sobre el Stage 1, para añadir tareas al job:
Esto nos lleva a las tareas que tiene el job, y ahí vamos a pulsar en “+” para añadir las nuestras:
Aquí vamos a tener que añadir 3 tareas, una por cada una de las 3 acciones que queremos hacer. La primera, será una tarea de aprovisionamiento, así que vamos a la pestaña “Deploy” y seleccionamos “Azure Resurce Group Deployment”:
El siguiente que vamos a introducir, es “Azure App Service Deploy”:
Y por último, vamos a añadir “Azure App Service Manage”:
Una vez añadidos los 3 recursos, nos quedará algo como esto:
Ahora vamos a configurarlos, para ello, vamos al primero y al pulsar sobre él, nos aparecen sus opciones:
Simplemente, tenemos que seleccionar nuestra suscripción y grupo de recursos donde queremos que se añadan, así como la zona para el despliegue. Después le indicamos que el template va a estar en una url y le pasamos las direcciones “raw” de los ficheros. Por ejemplo, en GitHub existe un botón para ir al fichero raw y luego basta con copiar la url:
Como se puede intuir, estos ficheros los genera el proyecto de “Grupo de Recursos de Azure” que hemos creado en Visual Studio, y los parámetros que hayamos puesto al validar nuestro script de aprovisionamiento:
Con esto, ya tenemos listo el aprovisionamiento de recursos. Ahora, vamos a configurar el despliegue de nuestro proyecto. Azure Pipelines nos da un asistente como este:
Aquí tenemos que tener especial cuidado, ya que vamos a “ciegas”. Me explico, como los recursos aún no están creados en Azure, vamos a tener que introducir los datos a mano porque los desplegables van a estar vacíos. Para eso, vamos a escribir los datos que hemos puesto al validar nuestro script de despliegue. También hay que tener cuidado con cuál es el nombre real que aplica nuestro despliegue, por ejemplo, la plantilla que hemos seleccionado para el aprovisionamiento añade “Portal” al nombre que hallamos elegido:
"webAppPortalName": "[concat(parameters('baseResourceName'), 'Portal')]"
Lo mismo pasa con la ranura (Slot) al que vamos a desplegar, realmente no existe mientras estamos configurando el despliegue, así que la escribimos a mano.
Este “problema” se puede solucionar si utilizamos las variables del pipeline, de manera que siempre sean los mismos valores. Si hacemos el aprovisionamiento de recursos antes de configurar esta parte también se evitaría porque si los recursos ya están creados, aparecerán todos correctamente en los desplegables.
Una vez que lo hemos terminado de configurar, lo último que nos falta es cambiar la ranura de “Staging” por la de “Produccion”, de manera que se haga un despliegue completo, y nuestro proyecto este accesible en producción. Para eso, configuramos el último apartado:
Igual que en el caso anterior, vamos a “ciegas” porque los recursos aun no existen. Sabiendo esto, escribimos manualmente el nombre del servicio que estamos operando, el grupo de recursos al que pertenece, y la ranura que queremos poner en producción. Puede que no queramos poner en producción la ranura y solo cambiarla por otra, esto lo podríamos conseguir si desmarcamos la casilla “Swap whit Production”, lo cual nos hace aparecer un segundo campo para rellenar con la ranura por la que queremos cambiar.
Una vez que hemos configurado las 3 tareas, pulsamos sobre el botón “Save” para guardar nuestro job:
Ya tenemos nuestro despliegue listo. Ahora cada vez que hagamos un cambio en el repositorio, automáticamente se publicará. Antes de hacer cambios, podemos comprobar que nuestro pipeline funciona pulsando sobre el botón “Create a release”:
Esto lanzará un ciclo de despliegue como podemos ver en la pestaña “Releases”:
Una vez termine, si vamos a https://{nombre de nuestro servicio}.azurewebsites.net debería estar disponible nuestro proyecto. Si añadimos algún cambio y lo subimos a github, de que acabe la integración y el despliegue deberíamos poder ver en la url el cambio que hemos hecho. Por ejemplo:
Como es habitual en este tipo de entradas, el código esta disponible en GitHub para poder consultarlo.
Aviso a navegantes
No es oro todo lo que reluce, poner webs en producción de manera automática puede ser peligroso ya que puede haber errores de interfaz gráfica (o cualquier otro tipo) que no se hayan testeado mediante pruebas automáticas. Una mejor practica puede ser hacer despliegue sobre una ranura de “develop” donde poder comprobar la funcionalidad completa de la web, y una vez que estamos seguros de que todo esta bien, hacer el swap desde la ranura que hemos testeado de manera que los posibles errores estén comprobados ya.
Si por el contrario, lo único que estamos publicando es una API RESTful que hemos desarrollado con buenas prácticas y que no tiene estado (no hay datos que son necesarios mantener en memoria entre peticiones), no debería ser un problema hacer despliegue continuo automáticamente, ya que las peticiones de aquello que consuma nuestro servicio se lanzaran contra la versión establecida, y solo cuando cambiemos los clientes a la nueva versión se aplicará el cambio.
Conclusión sobre CI/CD
Aunque quizás el despliegue continuo a producción es algo idílico y difícil de alcanzar por la cantidad de posibles problemas y errores que podemos introducir, este solo es el paso final de una serie de buenas prácticas y metodologías de trabajo. Quedarse en cualquiera de los puntos anteriores al despliegue en producción sigue siendo algo muy válido, ya que estamos haciendo que no exista una dependencia tan fuerte entre código y programador, lo cual siempre facilita el trabajo y la mantenibilidad de los proyectos. Esto añadido a una buena política de pruebas unitarias,
evita los problemas asociados a realizar proyectos en equipos de trabajo, donde cada persona no tiene por qué conocer el alcance del trabajo del resto. Con la variedad de proveedores que ofrecen estos servicios, no buscar uno que se adapte a nuestras necesidades e implementarlo puede ser una decisión que a la larga salga cara.
**La entrada Herramientas de desarrollo: Azure Pipelines (CD) y ARM se publicó primero en Fixed Buffer.**
Variable not found
Publicando nuestra web sobre Azure Web Apps
marzo 26, 2019 09:00
Blogger invitado
Jorge Turrado
Apasionado de la programación, siempre buscando la manera de mejorar el día a día con el desarrollo de tecnologías .NET. Apasionado de este momento tan cambiante y fabuloso para ser desarrollador C#.Para hacer esto tenemos varios caminos posibles, unos más automatizables que otros, y cuál elegiremos dependerá de nuestras necesidades:
- A través de la interfaz web de Azure
- Desde Visual Studio
- Usando Azure Resource Manager (ARM).
Crear la Web App a través de la interfaz web de Azure
En primer lugar está la opción más obvia, que es ir al portal de Azure y crearla desde allí, para eso, nos tenemos que identificar en Azure, y dentro del “dashboard”, pulsamos sobre “Crear un recurso”:
Dentro del menú, vamos a Web App:
Esto nos llevará a un nuevo menú, donde vamos a dar un nombre a nuestra aplicación, elegiremos si es Windows o Linux, así como el plan de precios:
Al seleccionar sobre el plan de precios, nos va a abrir un nuevo menú donde seleccionaremos algún plan ya creado, o uno nuevo, en caso de no existir ninguno, se creará uno por defecto:
Al pulsar sobre “Crear nuevo”, nos lanza un último menú, donde elegir la región donde queremos que este el plan, así como el tipo de equipo donde queremos que funcione nuestra Web App:
Una vez que tengamos todo seleccionado, al pulsar crear, se ejecutará la implementación de los recursos:
Una vez que termine, se puede consultar desde el panel “Todos los recursos”:
Crear la Web App desde Visual Studio
Una segunda opción es utilizar la propia interfaz de publicación de Visual Studio para aprovisionar los recursos. Para ello, dentro de nuestro proyecto, vamos a publicar desde el menú contextual:
Y desde ahí, en la ventana, seleccionamos “App Service” y “Crear nuevo”:
Al pulsar sobre “Publicar”, se inicia el asistente donde nos vuelve a pedir los datos de nuestro App Service:
En él, podemos elegir el nombre, el grupo de recursos y el plan de hospedaje para nuestra web. Una vez que lo hayamos elegido, basta con pulsar sobre el botón “Crear” para lanzar el aprovisionamiento.
Una vez haya terminado, se lanzará la publicación, consiguiendo que nuestra web esté online. Si volvemos a comprobar en el portal, podremos ver que el Web App esta creado correctamente:
Crear la Web App usando ARM (Azure Resource Manager)
Una tercera opción, que además es la que usan las otras 2 por detrás, es utilizar el Azure Resource Manager (ARM). Con ARM, podemos crear mediante código plantillas de implementación de recursos, que además pueden ser versionadas junto al resto del proyecto. Mediante estas plantillas, podemos conseguir configuraciones complejas tal cual lo haríamos en la interfaz web, uniendo por ejemplo nuestra Web App con un Storage y una base de datos, consiguiendo así que las siguientes implementaciones no impliquen un montón de trabajo de creación y configuración.Otro escenario en el que puede ser muy interesante utilizar estas implementaciones es en equipos de trabajo donde queremos que los recursos sean los mismos para todo el equipo, sin tener que preocuparnos de generar “n” espacios de trabajo iguales y asignarlos, ya que, muy cómodamente, cada persona puede generar su entorno de trabajo igual a los demás.
Para poder utilizar ARM desde Visual Studio, es necesario añadirle la carga de trabajo “Desarrollo de Azure”:
Una vez que lo tenemos, basta con que añadamos un nuevo proyecto a nuestra solución de tipo “Grupo de recursos de Azure”, dentro del menú “Cloud”:
Al crearlo, nos lanzará un pequeño asistente que nos permitirá seleccionar templates predefinidas que nos puedan resultar interesantes. Estas templates se pueden modificar, añadiendo o quitando lo que nos interese, pero son una buena base desde la que partir. En nuestro caso, la plantilla es suficiente para hacer un aprovisionamiento básico para una Web App sobre Windows sin ningún añadido, ni bases de datos ni storages.
Para eso, seleccionamos las plantillas de Azure QuickStart, buscamos “101-webapp-basic-windows” y pulsamos sobre “Aceptar”:
Esto nos ha creado un proyecto listo en nuestra solución con los ficheros necesarios para hacer la implementación de recursos en Azure:
Para lanzar el aprovisionamiento, basta con hacer clic derecho sobre el proyecto, y sobre el menú contextual, seleccionamos “Implementar -> Nuevo…”:
Esto nos lanza un último menú, donde tenemos que seleccionar el grupo de recursos donde queremos hacer el aprovisionamiento y sus parámetros. Dentro de estos parámetros, están cosas como el nombre de nuestra Web App y el tipo de máquina donde tiene que correr:
Una vez hecho esto, pulsamos sobre “Implementar” y después de esperar a que termine, ya tendremos nuestros recursos aprovisionados.
Publicando sobre Azure App Service
Una vez que el recurso está creado mediante cualquiera de los tres métodos, ya sólo falta poner nuestra web en ese recurso. Para ello, desde el menú de publicación de Visual Studio, seleccionamos “App Service”, y esta vez, marcamos “Seleccionar existente”:
Al pulsar “Publicar”, se nos despliegan todos los recursos disponibles en nuestra cuenta de Azure:
Al elegir nuestra Web App y pulsar en “Aceptar”, se creará el perfil de publicación y nuestra web será desplegada sobre el recurso que hemos seleccionado. De aquí en adelante, basta con que volvamos a publicar sobre ese perfil cada vez que necesitemos modificar nuestra web.
Es importante añadir que, con lo que hemos hecho, sólo hemos creado una web en producción, y que, si volvemos a publicar y cometemos errores, nuestra web puede quedar inaccesible o accesible con errores. Además, el tiempo que dure la publicación nuestra web estará inaccesible, por no hablar de que no es obligatorio pasar las pruebas unitarias para publicar, basta con que compile…
Si nuestra web esta en producción y queremos evitar estos posibles fallos, la mejor idea puede ser utilizar webs con diferentes Slots (Ranuras) donde la publicación se haga automáticamente después de pasar por un sistema de CI. Precisamente de esto hablo en mi entrada:
Con esto me despido, ha sido un placer volver a publicar en Variable Not Found, donde espero volver (después de un tiempo, eso sí), con alguna nueva e interesante idea.
José M. Aguilar > Como siempre, es un placer tenerte por aquí, Jorge. Ya sabes que las puertas están abiertas para cuando te apetezca de nuevo. Mientras tanto, continuaremos siguiéndote de cerca en Fixed Buffer ;)Publicado en Variable not found.
Picando Código
Firefox Send (Beta) disponible en Android
marzo 23, 2019 04:07
Firefox Send, nuevo servicio gratuito para compartir archivos online de forma segura, ya tiene su aplicación beta para Android. La aplicación no está listada en Google Play, pero la pueden encontrar en el siguiente enlace:
https://play.google.com/store/apps/details?id=org.mozilla.firefoxsend
La interfaz es básicamente la misma que el sitio web. Al ser una versión Beta, todavía puede tener algún que otro detalle. Pero por ahora anda todo muy bien.
En lo personal vengo usando Firefox Send con éxito, es súper práctico para compartir archivos online.
Podemos usar la aplicación web desde cualquier dispositivo entrando en Firefox Send.
Meta-Info
¿Que es?
Planeta Código es un agregador de weblogs sobre programación y desarrollo en castellano. Si eres lector te permite seguirlos de modo cómodo en esta misma página o mediante el fichero de subscripción.
subscripciónPuedes utilizar las siguientes imagenes para enlazar PlanetaCodigo:
Si tienes un weblog de programación y quieres ser añadido aquí, envíame un email solicitándolo.
Idea: Juanjo Navarro
Diseño: Albin
Fuentes
- .NET o no .NET, esa es la cuestión
- Arragonán
- Bitácora de Javier Gutiérrez Chamorro (Guti)
- Blog Bitix
- Blog de Diego Gómez Deck
- Blog de Federico Varela
- Blog de Julio César Pérez Arques
- Bloggingg
- Buayacorp
- Coding Potions
- DGG
- Es intuitivo...
- Fixed Buffer
- Infectogroovalistic
- Ingenieria de Software / Software Engineering / Project Management / Business Process Management
- Israel Perales
- Juanjo Navarro
- Koalite
- La luna ilumina por igual a culpables e inocentes
- Made In Flex
- Mal Código
- Mascando Bits
- Metodologías ágiles. De lo racional a la inspiración.
- Mig Salazar
- Navegapolis
- PHP Senior
- PHPBSD.net » webmaster
- Pedro Hernández
- Pensamientos ágiles
- Picando Código
- Poesía Binaria
- Preparando SCJP
- Pwned's blog - Desarrollo de Tecnologia
- Rubí Sobre Rieles
- Spejman's Blog
- Thefull
- USANDO C# (C SHARP)
- Una sinfonía en C#
- Variable not found
- Yet Another Programming Weblog
- carlosrovira.com
- design-nation.blog/es
- proyectos Ágiles
- psé
- vnsjava
- xailer.info