Páginas

viernes, 21 de septiembre de 2018

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: 


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'); 

4 var animacion = anime.timeline({ 
5     loop: true, 
6 }); 

8 anima(valorDelay), 

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.


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

lunes, 27 de agosto de 2018

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.

viernes, 17 de agosto de 2018

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.

sábado, 11 de agosto de 2018

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:


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é.

lunes, 30 de julio de 2018

¿Cómo representar Scrum técnico en una imagen?

Habéis oído el refrán "Una imagen vale más que mil palabras". Yo andaba hace tiempo dándole vueltas a tener una imagen que sirviese para explicar lo que es Scrum técnico.

Según Scrum Manager hay dos formas de adopción de Scrum: técnica y pragmática. Cuando se adopta Scrum técnico se siguen unas reglas definidas, mientras que en la pragmática los equipos basándose en la experiencia acumulada pueden ir rompiendo las reglas para ejecutar un Scrum más acorde a sus necesidades específicas.

Ha sido hace unas semanas cuando Maria Robles ( Trabajos de María ), me dijo: "si quieres preparo las imágenes". Y hala, nos pusimos a trabajar. Aunque esto no ha sido un desarrollo de software, la forma de trabajo se ha ajustado a los valores y principios del Manifiesto Ágil.

Empezamos por tener tres charlas a modo de sprints en las que le explicaba a la diseñadora cual es el proceso a seguir para desarrollar software con Scrum. Después de cada charla, ella me enseñaba algunos personajes y dibujos que representaban lo que le explicaba. Cuando ya tenía algunos personajes y dibujos seleccionados, me pidió que escribiera el proceso que le estaba contando. Tras esto realizó el diseño y me mostró la primera versión del póster. Sobre este le pedí cambios y este proceso lo repetimos 3 veces. En todo momento durante el proceso, aclarábamos las dudas que surgían manteniendo comunicación cara a cara o por whatsapp.

Tras esto le pedí su visto bueno a mi amigo Alex(Blog de Alex) me ayudó proponiendo interesantes mejoras.

Tras este proceso en el que empleamos una gran dosis de ilusión obtuvimos el póster de la imagen.