Por qué adoptar prácticas DevOps

Hoy en día independientemente del tipo de negocio en que una empresa esté  involucrada, la dependencia del software es enorme. La forma de construir y entregar  software dicta en gran medida el éxito o fracaso del negocio en cuestión.

Para la puesta en marcha de un nuevo software, es necesario por una parte construirlo o como normalmente se llama a esta actividad desarrollarlo. Una vez desarrollado es necesario desplegarlo, es decir instalarlo en los servidores desde los cuales dará servicio y por lo tanto se podrá hacer uso de su funcionalidad. En este escenario no debemos olvidar hablar de la necesidad de mantenimiento del software. Los negocios, las leyes, las normas, las modas, en definitiva el mundo cambia y el software construido ha de ser modificado para adecuarse a las necesidades de cada momento.

Las actividades de desarrollo y despliegue las llevan a cabo distintas personas que tienen conocimientos distintos y complementarios. Hay especialistas en desarrollo y especialistas en despliegue o instalación de software. Los primeros se denominan DEVelopers en inglés y los segundos OPerators. Los developers o profesionales de desarrollo diseñan y construyen software y su objetivo es estar siempre cambiando el software para mejorarlo y crear nuevas funcionalidades, en definitiva estar siempre “cambiando”. Los operators o  profesionales de operaciones por su parte, tienen la misión de mantener el software permanentemente dando servicio, impidiendo que se produzcan fallos y caídas inesperadas, en definitiva mantener la “estabilidad”.

Aunque developers y operators tienen el mismo objetivo final, resulta que sus objetivos individuales suelen entrar en conflicto. Si queremos algo estable (operators), los cambios no son bienvenidos (developers).

DevOps es una forma de dar nombre a un conjunto de buenas prácticas que tienen en cuenta esta dicotomía de intereses e intentan que el trabajo de profesionales de desarrollo y operaciones fluya adecuadamente dando respuesta a las necesidades de software de las organizaciones hoy en día.

Los departamentos de Tecnologías de la Información (TI) de las organizaciones son responsables de responder con rapidez a los cambios del software, cambios muy necesarios en un mundo cómo el actual muy competitivo y proporcionar servicios seguros, estables y de confianza a los clientes.

Según “DevOps Handbook” de Gene Kim y Jez Humble en TI se produce una espiral de destrucción debido a que: primero los profesionales de operaciones están intentando mantener estables sistemas cuya infraestructura es compleja,  frágil y en muchos casos está mal documentada, segundo alguien en la organización (marketing, comercial, …) promete grandes funcionalidades que harán las delicias de los clientes y que van a estar disponibles para ya, tercero todo esto encamina a que las cosas cada vez sean más difíciles, cada profesional de desarrollo y operaciones esté cada vez más ocupado, el trabajo se desestructure, se vuelva todo más complicado y cómo consecuencia la comunicación se vuelve más lenta y la cantidad de trabajo pendiente se vuelve cada vez más grande. Y todo esto empeora y empeora con el paso del tiempo.

Para romper esta espiral, es necesario disponer de medios que permitan dotar de robustez a los sistemas complejos y buscar flujo de trabajo en el ambiente de desarrollo. Esto hará que los profesionales de TI estén entregados a un trabajo en el que el sobreesfuerzo y la heroicidad no tengan que ser una constante, es decir un entorno normalmente “amable” de trabajo.

Existen evidencias de que usar prácticas recomendadas por DevOps mejora la construcción y puesta en marcha del software. Una de ellas es el informe “State of DevOps Report” que llevan publicando Jez Humble y Gene Kim desde 2013 anualmente (https://puppet.com/resources/whitepaper/state-of-devops-report ). En las conclusiones del informe de 2018 dice:

Cada año, el State of DevOps report nos enseña algo nuevo. Este año nuestros datos han mostrado que mientras hay muchos caminos individuales de realizar una transformación DevOps, hay formas más rápidas de llegar al éxito. Las organizaciones pueden elegir entre ser sistemáticas en cuanto a cómo evolucionan o pueden adoptar una aproximación más particularizada. Por supuesto, es posible que una aproximación particular funcione, pero lo que vemos entre las organizaciones que han alcanzado los niveles más altos de evolución en DevOps, es que no llegaron ahí por casualidad.

Estamos encantados de ser capaces de proporcionar algo concreto y útil a los equipos que están trabajando duro para mejorar la forma en que trabajan……

Tener en cuenta las prácticas DevOps es crítico para que las organizaciones lidien con la confrontación de intereses entre profesionales de desarrollo y operaciones. Mientras esto no se consiga, los logros de TI serán muy dolorosos y como consecuencia esto hará que las organizaciones que no adopten prácticas DevOps sean cada vez menos competitivas.

Truco AnimeJS: como cambiar propiedades al vuelo

Esta semana una compañera y yo hemos tenido que lidiar con una animación. El caso es que la animación tiene bastantes componentes y mi compañera pensó en usar AnimeJS para facilitar nuestro trabajo. AnimeJS es una librería que es bastante sencilla de entender y de forma rápida se consiguen hacer animaciones complejas, que de otro modo llevarían muchas horas en la elaboración de las hojas de estilo, de funciones javascript u otras técnicas que se puedan emplear. 

Para ilustrar lo que quiero exponer veamos la siguiente animación en acción: 

 Animación realizada con AnimeJS

Una de las características de esta página es que el usuario pueda cambiar la velocidad a la que suceden las animaciones de los distintos elementos. Es decir, que puede acelerar o frenar el ritmo al que salen, entran, crecen, etc. los textos y figuras que aparecen en la pantalla.

Vamos con el código. Aquí vemos el código Javascript de la página:

1 var valorDelay = 30; 
2 var progress = document.querySelector('.progress'); 
3 
4 var animacion = anime.timeline({ 
5     loop: true, 
6 }); 
7 
8 anima(valorDelay), 
9 
10 progress.addEventListener('input', function() 
11         { valorDelay= 30 - progress.value;
12           animacion.pause(); 
13           animacion=undefined; 
14           animacion = anime.timeline({loop: true,}); 
15           anima(valorDelay);}); 
16 
17 function anima(valorDelay){ 
18 
19 animacion 
20   .add({ 
21      targets: '.cabecera', 
22      translateY: [-500, 0], 
23      opacity:[0,1], 
24      delay: function(target,index) {return valorDelay * index; }, 
25   }) 
26   .add({ 
27      targets: '.cuadro', 
28      scale: [0, 1], 
29      delay: function(target,index) {return valorDelay * ((index + 1) * 50);}, 
30   }) 
31   .add({ 
32      targets: '.barra', 
33      width: [0, 1750], 
34      delay: function(target,index) {return valorDelay * ((index + 1) * 50);}, 
35   }) 
36   .add({ 
37      targets: '.texto', 
38      opacity:[0,1], 
39      translateX: [0, 80], 
40      delay: function(target,index) {return valorDelay * ((index + 1) * 50);}, 
41 
42   }) ;
43 }

La animación tiene un “timeLine” que maneja los elementos de la página en 4 "ordenes" de animación, que se corresponden con los .add, que hay en las líneas 20, 26, 31 y 36. 

La página está preparada para aumentar o disminuir el tiempo de retardo entre animaciones con un botón que recorre una barra creada con la etiqueta “” de html. Con el objetivo de cambiar el valor de la propiedad “delay”, se ha empleado la técnica de incluir la instanciación de la animación en una función que recibe como parámetro el valor de retardo a aplicar. 

Cuando desde la página se solicita aumentar o disminuir la velocidad de la animación, se captura con el método “addEventListener”. Cuando se maneja el botón del elemento “” se dispara este método y se asigna a “delay” un valor en función de la posición en que esté el botón. El valor de “” puede ir de 0 a 30 de 10 en 10. Cuando está a cero la animación debe ir despacio, cuando está a 30 más rápido. Es decir, el valor de “” es inversamente proporcional al del retraso requerido.Por este motivo se calcula el  valor de “delay” de forma inversa respecto a   “”, es decir cuánto más grande es “” más pequeño es “delay”.

En este ejemplo se usa un algoritmo de animación aprovechando las funcionalidades de AnimeJS con la particularidad de que dinámicamente se requiere que cambie el valor de una propiedad de la animación, en este caso el tiempo de retardo entre una animación y otra. 

El problema

Cuando se requiere cambiar el valor de “delay” se llama a la función “anima(valorDelay)” con el valor de retardo como parámetro. Sin embargo, hay que tener en cuenta que cada vez que se invoca la función “anima(valorDelay),” se está creando una nueva instancia de la animación. Esto provoca que habiendo varias animaciones activas, la animación empiece a hacer cosas raras si esperamos un poco. Este asunto es lo que me ha animado a escribir este post, por un lado exponer el problema y por otro ofrecer una posible solución.

La solución

Lo que consigue que la animación no haga cosas raras son las sentencias 12, 13 y 14. Estas sentencias cierran la animación que está en marcha, desconectan esta instancia del navegador y abren otra instancia de animación. Así la animación comienza y funciona perfectamente.

Descarga de la página html, la hoja de estilo y el fichero Javascript 

Esperamos Maria ( https://www.domestika.org/en/mariadelamareria ) y yo que os sea de utilidad nuestra experiencia. Si necesitáis algo, dejadnos un comentario.

Ingredientes de SCRUM

1 - Producto

Es el software que se construye durante el proyecto.

2 – Propietario de producto

Persona que se ocupa del producto. ¿Qué funcionalidades debe tener? ¿Cómo será más competitivo? ¿Qué mejoras se le pueden aplicar? Etc.

3 –Scrum master

Persona que se ocupa del proceso es decir, de que se utilice el método Scrum adecuadamente y que el trabajo de los equipos fluya evitando impedimentos.

4- Historias de usuario

Es la descripción de lo que el producto debe hacer.  Es decir, recopilan el conjunto de funcionalidades y otras características que se espera tenga el software que se va a construir.

5 – Puntos historia

Es una medida cuantitativa que asigna el equipo a cada historia. Los puntos historia miden la dificultad que se intuye que tendrá la historia para ser construida, comparada con el resto de las historias de la pila. Es decir no es una medida absoluta, es una medida de comparación.  Existe una técnica llamada “Planning poker” para medir puntos historia.

6 – Pila de producto

El propietario de producto es el responsable de la pila de producto. La pila de producto es una lista que contiene todas las historias que describen el producto. El propietario de producto prioriza las historias, al principio coloca las que se prevea que aportarán más valor para el negocio. Las historias del principio de la pila deben estar suficientemente detalladas para que el equipo de desarrollo tenga la información necesaria para poder construir el software, el resto de ellas pueden estar definidas más vagamente. Esto se debe a que en SCRUM el cambio es bienvenido, es decir, puede ocurrir que una historia que en principio se identificó como tal, después de varias iteraciones (sprints) se considere que ya no es importante y se elimine. También que aparezcan nuevas historias o cambien historias existentes. Por eso, no es útil que las historias de usuario del final de la pila, que todavía no se van a implementar o quizás no se implementen nunca, estén perfectamente detalladas.

7 – Sprint

Periodo de tiempo previamente fijado durante el cual el equipo desarrolla las funcionalidades y características descritas en las historias de usuario. Los sprints se suceden de forma iterativa en el tiempo, hasta que se haya terminado el producto. Los sprints se acaban cuando acaba el tiempo prefijado, si hay trabajo no terminado se reajustará en subsiguientes sprints. Se recomiendan sprints de 1 a 4 semanas y nunca de más de 6. Es importante que las historias de usuario que se acuerde llevar a cabo en un sprint, no se cambien durante el transcurso del sprint,  el objetivo es no alterar el trabajo del equipo.

8 – Reunión de planificación del sprint

El equipo de desarrollo se reúne con el propietario de producto y trabajan sobre la pila de producto. El equipo analiza las historias de usuario, debatiendo con el propietario de producto sobre su naturaleza. Se seleccionan tantas historias del principio de la pila de producto como el equipo considere que va a poder desarrollar durante el sprint, los puntos historia ayudan a saber cuántas historias seleccionar. Las historias seleccionadas pasan a la pila del sprint y se subdividen en tareas, de tal manera que el equipo desmenuza cada historia en las actividades necesarias para implementarla.

Se prepara el tablero SCRUM del sprint (“Por hacer”, “Haciendo”, “Hecho”) y se colocan las tareas de las historias seleccionadas en la columna “Por hacer”.

9 – Reunión SCRUM diario

Esta reunión se celebra cada día de cada sprint, normalmente al comienzo de la jornada de trabajo. Es una reunión breve, no más de 15 minutos. En esta reunión cada miembro del equipo dice como le fue con las tareas del día anterior y que tareas planifica hacer hoy.

  

10 – Reunión de revisión del sprint

Terminado el sprint el equipo hace una demo del software construido al propietario de producto y a los clientes/usuarios. El objetivo es mostrar el software construido y obtener retroalimentación sobre la perspectiva de clientes/usuarios y el propietario del producto. En caso de que se cumplan las expectativas de todos ellos seguir adelante, en caso de que no hacer los cambios necesarios para cumplirlas. 

11 – Reunión de refinamiento de pila de producto

Se reúne el propietario de producto con el equipo de desarrollo, para revisar las historias que se prevé abordar en el próximo sprint. En base al software construido y a posibles cambios producidos en el transcurso del tiempo, se refinan las historias de usuario: re-priorizar, eliminar, modificar y/o  crear nuevas historias. La idea de refinamiento es doble, por un lado se trata de aportar más detalles sobre las historias del próximo sprint y por otro lado reajustar la priorización de las historias para adaptarse al momento (gestión de los cambios).

En Scrum desde el primer sprint el usuario dispone de software construido.  Esto permite que el desarrollo del producto se realice siguiendo unas especificaciones que se basan en la realidad de un software funcionando en vez de hipótesis sobre lo que debería de hacer o no el producto.

12 – Reunión de retrospectiva

Al final de cada  sprint se celebra una reunión de retrospectiva. La retrospectiva vigila el proceso, no el producto. La retrospectiva, lo que persigue es que el equipo: desarrolladores, propietario de producto y clientes/usuarios, pongan de relieve aquellas cosas que creen que pueden hacer mejor para el próximo sprint. Por ejemplo: los SCRUM diarios se han alargado cada día durante más de 2 horas y el equipo ha perdido mucho tiempo. Aquí una mejora es proponerse mantener el scrum diario en los 15 minutos estipulados para los próximos sprints.

Aprender Angular gratis: Donde acudir.

Angular es un framework para el desarrollo de aplicaciones web y apps para móviles. Al igual que otros framewoks el objetivo de Angular es simplificar el desarrollo y mantenimiento de aplicaciones.

Esta plataforma fue desarrollada por Google que la lanzó inicialmente en 2010 con el nombre de AngularJS.  En 2016, lanzó una evolución llamada Angular o Angular 2.  AngularJS y Angular no son compatibles, son frameworks distintos. Sin embargo ambos frameworks  tienen el mismo objetivo, de hecho Angular se diseño aprovechado las ventajas que supuso AngularJS y mejorando sus desventajas.

En conclusión Angular es la evolución de AngularJS y incorpora mejoras de todo tipo: mejor rendimiento, mejores mecanismos para la modularización,  tiene en cuenta las plataformas móviles y hay otras muchas mejoras en la arquitectura suministrada.

Angular no es un framework al uso. Angular ofrece mayor soporte que otros,  resolviendo asuntos sobre los que el desarrollador no tiene que decidir, solamente tiene que usar los elementos que pone Angular a su disposición. Las aplicaciones Angular tienen todas el mismo patrón arquitectónico y son fácilmente abordables para los conocedores del framework.

Los desarrolladores de Angular proporcionan una plataforma donde descargar y aprender a utilizar Angular desde sus fundamentos hasta llegar a un conocimiento completo y profundo del framework.

Para iniciar el aprendizaje de Angular acceder a https://angular.io/guide/quickstart. En esta guía se describen los pasos para crear un entorno de desarrollo local y poder crear una aplicación básica. A través de cuatro simples pasos se instala el Angular y el software necesario para trabajar con él, se crea una aplicación Angular, se arranca el servidor que soporta la aplicación y se edita y modifica un componente para iniciar al navegante en el desarrollo en Angular.

Después se puede profundizar en el aprendizaje en https://angular.io/tutorial. Durante este tutorial se crea una aplicación web, que ilustra los elementos principales que existen en el framework: directivas para mostrar información en pantalla, componentes, plantillas, enlace de datos one-way y two-way, enlace de métodos a eventos del usuario, creación de servicios y uso de enrutamiento para navegar entre vistas y componentes.

En https://angular.io/guide/architecture se puede echar un vistazo a la arquitectura  del framework a grandes rasgos. La arquitectura viene representada con la siguiente imagen:

Esta imagen representa una aplicación Angular que a modo resumen tiene los siguientes componentes:

• Modules: Los módulos son unidades funcionales. Agrupan componentes que hacen algo común, es decir funcionalmente trabajan juntos. Una aplicación Angular al menos tiene siempre un módulo raíz. 
• Component: Cada componente define una clase que tiene datos y lógica de aplicación. Todo ello asociado con una vista (template) que es lo que ve el usuario en la pantalla. Una aplicación Angular tiene al menos un componente.
• Template: Las vistas son páginas HTML con directivas y marcado de enlace de datos para asignar datos de la aplicación a los elementos de la página HTML. 
• Directive: Las directivas proporcionan soporte de lógica de programación y enlace de datos que conectan los datos de tu aplicación y el DOM de la página HTML.
• Property Binding: asigna valores a las propiedades de la página HTML.
• Event Binding: toma control de las acciones de usuario sobre la página HTML.
• Injector: Asocia dinámicamente servicios a componentes, de manera que el uso de servicios en los componentes es más versátil.
• Service: Los servicios proporcionan funcionalidades a los componentes. Estos se crean para lógica y datos que están asociados con más de una vista. Su fundamento es la reutilización.

Esto es todo. Espero facilitar el aprendizaje de Angular con este Post. Se agradecen los cometarios y preguntas.

Contribuir al software libre: Cómo empezar.

A mí siempre me ha gustado desarrollar software. La parte en la que más me gusta participar en el equipo de desarrollo es la elaboración del código fuente, es decir en la programación. Actualmente no me dedico a la programación de forma profesional. Entonces, con el objetivo de poder participar en desarrollos de software pensé en participar en la elaboración de código para algún proyecto de los que actualmente se elaboran por comunidades o grupos sin ánimo de lucro. Actualmente hay muchos productos software que se pueden descargar de forma gratuita y estos productos están desarrollados por estas comunidades. Me planteé formar parte de alguno de los grupos que desarrollan estos productos. Recurrí a internet para ver donde podía colaborar. Buscando encontré este enlace:

http://wikis.fdi.ucm.es/ELP/Trabajo:_C%C3%B3mo_formar_parte_de_proyectos_de_Software_Libre

En este enlace proponen varias plataformas a las que acudir cuando quieres colaborar en el desarrollo software de algún producto. Las plataformas propuestas ahí son:

·         Google Summer of Code y sus organizaciones.

·         Awesome First PR Opportunities

·         Lista de proyectos de Mozilla.

·         GitHub Explore. 

Yo elegí GitHub Explore y buceé a ver qué proyectos estaban en marcha. Lo primero que hice fue registrarme en la plataforma, paso obligatorio para poder colaborar.

Después elegí el proyecto en el que colaborar. Cuando se accede a GitHub Explore, hay una página que en diferentes categorías muestra los proyectos en los que se puede colaborar. También existe una búsqueda avanzada en la que se pueden seleccionar preferencias: lenguajes de programación, número de colaboradores, número de cambios en los últimos meses, etc.

Tras una larga y minuciosa búsqueda, seleccioné el proyecto TheAlgorithms/java ( https://github.com/TheAlgorithms/Java ). Para buscar el proyecto, me centré en algo que fuese sencillo para empezar. Descargué el código y lo cargué en mi IDE preferido Eclipse y empecé a trastear, leyendo código y ejecutando algoritmos. Encontré uno que fallaba referente a la obtención del Máximo Común Divisor. Entonces creé un incidente “issue” para informar del fallo. Alguien recogió la incidencia y arregló el problema. En este proceso recibí un correo de la persona que había arreglado el problema. Aproveché este correo para preguntarle si necesitaba ayuda con algún código y me dijo que sería útil refactorizar  el código de este repositorio de acuerdo con las  normas de codificación de Java.

Elegí un algoritmo y me puse manos a la obra. Estudié el código y comprobé cómo funcionaba. Después ayudada por los plugins “Sonarlint” de Sonarqube  y de Checkstyle para Eclipse, puse el código de acuerdo a las normas de codificación de Java.  Para terminar comprobé a través de pruebas manuales que el código seguía funcionando correctamente.

Para enviar las modificaciones a GitHub, tuve que crear un fork. En este fork almacené el nuevo código. Desde el fork abrí una nueva branch y desde esta branch creé una petición de cambio del fichero mediante un pull request.

Ahora estoy esperando a que alguien acepte mi pull request y que el fichero modificado se cargue en la rama principal (master) del proyecto. Y así estoy, a la espera.

Voy a indagar en otras plataformas, ya os contaré.