jueves, 30 de enero de 2020

Qué es Mocha para javascript en 2 minutos

Mocha es un framework para construir pruebas automatizadas de módulos javascript. Mocha se puede utilizar tanto para módulos que se ejecutan en NodeJS cómo los que se ejecutan en un browser.

Preparando un ejemplo de 2 minutos 

Este ejemplo se ha preparado en un equipo con Windows y NodeJS previamente instalados. 

Para instalar NodeJs en Windows ir a https://nodejs.org/en/ descargar el fichero y seguir los pasos de instalación. 

Pasos a seguir:

1. Crear un directorio PruebaMocha. Desde el directorio creado, para instalar Mocha usar el comando:

npm install mocha

cómo resultado del comando aparece un directorio node_modules que contiene las librerías del framework Mocha.

2. Para construir la prueba crear el fichero miprimermochatest.js con el siguiente contenido: 

    Var assert = require('assert'); 
    describe('Array', function() { 
      describe('#indexOf()', function() { 
        it('should return -1 when the value is not present',
            function(){
          assert.equal([1, 2, 3].indexOf(4), -1);
        });
        it('should return 0 when value 1 is present on position 0', 
            function() {
          assert.equal([1, 2, 3].indexOf(1), 0);
        });
      });
    }); 

3. Para ejecutar la prueba usar desde el directorio PruebaMocha el comando:

node_modules\.bin\mocha miprimermochatest.js 

Se obtiene el resultado: 

    Array
     #indexOf()
     √ should return -1 when the value is not present
     √ should return 0 when value 1 is present on position 0
    2 passing (12ms) 

Conclusión


Este código es un ejemplo muy sencillo para mostrar cómo se automatizan las pruebas. Aquí, el código probado está incluido en el propio módulo de prueba, sin embargo normalmente el código probado está en módulos aparte que constituyen el código del aplicativo que se está probando.

En definitiva se trata de hacer programas que prueban programas. Aprender a hacer programas que tienen pruebas automatizadas, no es baladí. Para que las pruebas sean funcionales y operativas, no solo se deben preparar pruebas bien diseñadas sino que los módulos a probar también tienen que estar diseñados de manera que sean testables. Pero esa, es otra historia.

sábado, 18 de enero de 2020

Qué es SAFE Scaled Agile Framework


SAFe® for Lean Enterprises es una base de conocimiento que incluye principios, prácticas y competencias cuya utilidad está basada en la experiencia. El objetivo de una empresa Lean es llegar a ser un negocio próspero de la era digital y entregar sistemas y soluciones competitivas a sus clientes en el tiempo más breve posible. El Scaled Agile Framework combina el poder de “Agile”, con el conocimiento de “system thinking” y el desarrollo “Lean” de productos para ayudar a los negocios a abordar los retos de desarrollar y entregar soluciones empresariales basadas en tecnología de alta calidad. Es una base de conocimiento de patrones de éxito probados en el mundo real, para conseguir la agilidad de negocio.

Los beneficios de SAFe: “Con un framework ya probado, podemos entregar soluciones mucho más rápido y con menos esfuerzo. SAFe define roles, equipos, actividades y artefactos para aplicar principios Lean y Agile a nivel empresarial y proporciona extraordinarios materiales de aprendizaje y entrenamiento para incrementar tus posibilidades de éxito” .” —Peter Vollmer, Hewlett Packard Enterprise.

Distinguidas empresas tecnológicas deben aprender cómo adaptarse a las cambiantes condiciones tecnológicas y económicas o se extinguirán, no importa su tamaño, su fuerza o lo inteligentes que sean. La agilidad no es una opción, es una necesidad. Incluso los negocios que no se consideran compañías de software – Servicios profesionales, financieros, fabricantes, instituciones sanitarias, agencias del gobierno y más – son actualmente muy dependientes de su habilidad de producir nuevos productos y servicios basados en tecnología innovadores y de alta calidad.

Es la mision de Scaled Agile Inc. ayudar a estas empresas con el crecimiento de su negocio digital mediante el desarrollo y la publicación de la base de conocimiento SAFe, así cómo proporcionar certificaciones, formación, cursos, comunidades y una red global de más de 280 socios que subministran herramientas y servicios.

Partiendo de más de una década de experiencia mejorando los logros del desarrollo de sistemas, SAFe parte de 4 cuerpos de conocimiento: desarrollo agile, systems thinking, desarrollo Lean de productos y DevOps. De esta forma ayuda a las empresas en las siguientes cuestiones:

  •  ¿Cómo alinear el desarrollo tecnológico con los objetivos estratégicos?
  •  ¿Cómo realizar la entrega de valor en el momento preciso?
  •  ¿Cómo mejoramos la calidad de nuestras soluciones y deleitamos a nuestros clientes?
  •  ¿Cómo escalamos las prácticas ágiles desde los equipos a toda la empresa para entregar mejores resultados?
  • ¿Cómo organizamos a la gente para entregar valor de forma eficiente y evitar los retrasos inherentes a las tradicionales estructuras funcionales?
  • ¿Cómo creamos un entorno que incentive la colaboración, la innovación y la mejora continua?
  • ¿ Cómo animamos a la gente a aceptar los riesgos, pensar creativamente y adoptar el aprendizaje continuo?
  • ¿Cómo podemos ayudar a los equipos que aprendan a mejorar de forma autónoma?

Adoptando SAFe y aplicando sus valores, principios y prácticas – la empresa puede abordar estas cuestiones y mejorar el negocio y los beneficios de los individuos. SAFe 5.0 permite la agilidad del negocio y mejora los logros de organizaciones de todos los tamaños. SAFe ha producido mejoras dramáticas en reducción de time-to-market, compromiso de los empleados, mejoras en la calidad, satisfacción del cliente y el logro de mejores resultados económicos. También ayuda a crear culturas que son más productivas, gratificantes y frescas.

Antes de que una empresa pueda obtener estos beneficios, debe transformarse en una empresa Lean. Esta transformación requiere desarrollo de “competencias empresariales” que permitan un nuevo estilo de liderazgo, nuevas formas de pensar y trabajar y una cultura centrada en la entrega de valor y la mejora continua.

La base de conocimiento de SAFe describe roles, responsabilidades, artefactos y actividades para implementar desarrollo Lean-Agile a nivel empresarial. SAFe sincroniza alineamiento, colaboración y entrega en organizaciones con un gran número de equipos agile tanto técnicos como de negocio. SAFe es escalable y configurable, dando soporte tanto a soluciones que implican de 50 hasta 125 profesionales así como entornos más complejos que requieren miles de personas. El website del framework (https://www.scaledagileframework.com/) dispone de la “Big-Picture”, este gráfico es una visión del marco completo y es  la interfaz de usuario con la base de conocimiento. Cada icono de la imagen es clicable y permite una entrada a la guía de SAFe que incluye: el núcleo de las 7 competencias de una empresa Lean, las 4 configuraciones que dan soporte a un amplio rango de entornos de desarrollo y negocio y los principios, valores, mentalidad, roles, artefactos y elementos que constituyen SAFe. 




domingo, 12 de enero de 2020

Qué son las “The Three Ways” de DevOps.


Antecedentes

Uno de los conceptos fundamentales en Lean es el de “Value Stream”.  El “Value Stream” entendido cómo la secuencia de actividades requeridas para diseñar, producir, entregar un bien o dar servicio a un cliente; esto incluye los flujos de información y de materiales necesarios.
En Devops se define el “Value Stream”  de TI como el proceso requerido para convertir una hipótesis de negocio en un servicio proporcionado por la tecnología que entrega valor al cliente.
El tiempo de entrega es el tiempo que transcurre desde que el cliente hace una petición hasta que le es entregado el producto o servicio. El tiempo de proceso es el que transcurre desde que el trabajo se empieza a hacer hasta que se termina. Ver la siguiente figura:



El tiempo de entrega siempre es superior o igual al de proceso. Si se mejora cualquiera de estos tiempos la entrega de valor es más pronta y cuanto antes se entregue el valor más competitiva será la organización.

Particularizando en DevOps

En el caso de DevOps el “ Value Stream” de TI en muchas organizaciones está compuesto por múltiples actividades que llevan a cabo diversos profesionales con habilidades y conocimientos distintos. En “The DevOps HandBook” se muestra la siguiente figura:


 Aquí se representa el flujo de trabajo para poner en marcha un sistema en el entorno productivo, desde su concepción hasta su implantación. Al final de este flujo los clientes pueden utilizarlo y de esta forma recoger el valor que entrega el sistema.  La figura muestra un flujo de trabajo con muchas trasferencias, es decir en un paso el equipo correspondiente  hace un trabajo (por ejemplo:  desarrollar) a continuación se transfiere el trabajo al equipo que tiene que dar el siguiente paso (por ejemplo: Instalar el sistema en el entorno de pre-producción). Cada paso tiene sus propios tiempos de entrega y proceso. Mejorando estos tiempos entregaremos antes las aplicaciones, apps, webs, etc.
Además también hay que tener en cuenta el porcentaje de trabajo completado y asegurado. Este es el porcentaje de trabajo que en cada paso llega utilizable tal cual al siguiente paso, es decir se puede usar sin pedir más información o corregir la información suministrada.  Por ejemplo: para la instalación del sistema en preproducción, el equipo no tiene suficientes instrucciones para la creación de las tablas de la base de datos. Cuanto más elevado sea este porcentaje, habrá menos idas y venidas, no se re-trabajará y de nuevo se entregará el trabajo con más prontitud.

Las “Three ways”

En “The DevOps HandBook” los autores proponen una secuencia de mejora del “Value Stream” de DevOps. En la secuencia recomiendan abordar las mejoras en tres fases, que son las tres formas de mejorar. Estas son:

  •  Primera forma: Mejorar el flujo.
  •  Segunda forma: Hacer buen uso del feedback.
  • Tercera forma: Establecer el aprendizaje y mejora continua.

Recomiendan abordar las mejoras de estas 3 formas y hacerlo una tras otra. Es decir, primero poner el foco en mejorar el flujo, luego agregar al objetivo usar el feedback y para terminar sistematizar la forma en que se aprende de los errores y los éxitos e incorporar ese aprendizaje a la  mejora.

Primera forma: Mejorar el flujo

Aquí se trata de conseguir que el flujo de actividades para llevar los sistemas al entorno productivo sea constante y sin sobresaltos. Para ello existen múltiples recomendaciones:

  • Hacer el trabajo visible
  • Reducir el tamaño de los paquetes de trabajo es decir entregar menos funcionalidades juntas, pero más a menudo.
  • Automatizar los trabajos.
  • Construir con calidad.
  • Integración/entrega/despliegue continuos.
  • Fácil creación de entornos.
  • Prepararse para el cambio.

Segunda forma: Hacer buen uso del feedback

Se trata de establecer mecanismos para que en cada paso seamos capaces de hacer llegar información sobre el resultado de su trabajo a los pasos anteriores.  Cuando los equipos conocen el resultado de su trabajo corriente abajo, son capaces de aprender de sus éxitos y sus errores. Repitiendo lo que se hace bien y cambiando lo que hacen mal para intentar no repetir los errores.

Tercera forma: Establecer el aprendizaje y la mejora continua

Permitir un enfoque dinámico, disciplinado y científico hacía la experimentación y la aceptación de riesgos para aprender de los éxitos y los fracasos. Por ejemplo, estableciendo programas de uso de ataques a los propios sistemas como los recomendados por el Chaos Monkey. Esta es una iniciativa de Nexflix, donde periódicamente lanzan ataques contra sus propios servidores para observar las consecuencias y hacerse más resistentes a posibles problemas.

Bibliografía

The DevOps Handbook
 John Willis; Jez Humble; Gene Kim; Patrick Debois
 Publicado por IT Revolution Press, 2016

lunes, 6 de enero de 2020

Ejemplo de llamada al api fetch síncrona


Objetivo

En este post se explica cómo se puede utilizar fetch para obtener un fichero json que está en la red y mostrarlo mediante un browser. Lo interesante es el ejemplo de cómo hay que codificar las funciones, para que el  orden en que se ejecutan las sentencias javascript sea el adecuado, salvando las asincronías,
El api fetch es asíncrono, esto quiere decir que cuando se ejecuta, se lanza la petición del fichero json y la ejecución continúa sin esperar a que se recupere el fichero. Si esto no se tiene en cuenta, no tendremos garantía de obtener la respuesta adecuada, puesto que lo que queremos es mostrar dicho fichero en la ventana del browser y hasta que no tengamos el fichero no podremos presentarlo.

Punto de partida

Se usa el API REST en https://jsonplaceholder.typicode.com/ , es un  api suministrado de forma gratuita para poder realizar pruebas.
Se ha de iniciar un proyecto node express (https://expressjs.com/en/starter/hello-world.html).  Este framework se usa para construir la aplicación. Mediante la aplicación se arranca un servidor que resuelve peticiones por el puerto 3000.

Ejemplo

Se prepara una aplicación que una vez arrancada con node app.js, se queda esperando peticiones de la siguiente manera:

node app.js
Example app listening on port 3000!

Una vez arrancado el  servidor, en una ventana del browser escribir http://localhost:3000/damepost
Para dar respuesta a esta petición hemos escrito un módulo app.js, que es el que arranca la aplicación y tiene codificada la ruta “/damepost”.  Ver a continuación app.get.

app.js

 const express = require('express')
const app = express()
const port = 3000
const f = require('./functionsRefactored.js')

app.get('/damepost'async (reqres=> res.send(await f.hagoFetch())) 

app.listen(port, () => console.log(`Example app listening on port ${port}!`))

Cuando se realiza la petición http://localhost:3000/damepost, la aplicación llama a la función

 async (req, res) => res.send(await f.hagoFetch())

Esta arrow function llama a hagoFetch(). Esta función está exportada desde el módulo functionsRefactored.js que se muestra a continuación.

functionsRefactored.js

fetch = require('node-fetch');

async function hagoFetch() {
  const response = await fetch('https://jsonplaceholder.typicode.com/posts/1')
    .catch(error =>{console.error(error)})
  const json = await response.json();
  return json
}

exports.hagoFetch=hagoFetch;


En hagoFecth se solicita el fichero json que devuelve todos los posts del usuario cuya identificación es 1. La solicitud se hace con await, es decir de forma síncrona. Hasta que no se dispone de la respuesta la ejecución no continua con la siguiente sentencia.
Una vez que disponemos de la respuesta, podemos extraer el fichero json con el método json(). Este método también lo invocamos de forma síncrona con await.

Resumen

Convertir en síncrona la petición fetch, se ha conseguido mediante dos llamadas con await.

  1.  await fetch(….) no devuelve la constante response hasta que  fetch ha terminado.  
  2.  await response.json() no devuelve la constante json hasta que la función ha terminado.

Para poder hacer await dentro de la función  hagoFetch() se ha tenido que declarar como función async.
A su vez la llamada a la función hagoFetch en app.js se hace con await. Para poder hacer await la arrow function de app.get  para la ruta /damepost está declarada como async.

Espero que esto sea de utilidad para alguien por ahí que se esté pegando con fetch y la asincronía. Si tenéis alguna duda dejad un comentario.