Cuando trabajamos con componentes web, normalmente usamos el shadow DOM en los custom elements que creamos debido a que es la manera en que podemos sacarle todo el potencial a este estándar. Pero seguro que más de una ocasión nos hemos preguntado, ¿Qué elementos de HTML NO pueden aceptar Shadow DOM? Bueno, existen dos formas de saberlo.
La especificación del DOM Standard
Herramientas de desarrollador de Google Chrome
La especificación del DOM Standard
La manera más eficiente de saber exactamente que elementos NO soportan shadow DOM es guiarnos por lo que dice la especificación.
La otra opción es usar las herramientas del desarrollador de Google Chrome para ver el shadow DOM de los elementos en una aplicación.
Esta configuración se encuentra en los settings del panel de herramientas para el desarrollador, para ello, debemos dar clic en los tres puntitos verticales y después en settings o solamente presionar F1.
Luego en Preferences -> Elements activamos el checkbox que dice Show user agent shadow DOM.
Ahora podemos revisar sitios web que tengan elementos que soporten shadow DOM, algunos ejemplos son el input, select, audio, video, estos elementos ya contienen shadow DOM y por lo tanto NO podemos adjuntarles uno. En la siguiente imagen se muestra el elemento input :
También existen otros elementos que NO soportan Shadow DOM, ejemplo, img, a, button, br, b, etc.
Tanto los elementos que ya tiene Shadow DOM como los que no lo soportan provocaran el siguiente error al invocar sobre ellos el método attachShadow({ mode: 'open' }). Tal como dice la especificación
Uncaught DOMException: Failed to execute ‘attachShadow’ on ‘Element’: This element does not support attachShadow
Consola de Google Chrome
NotSupportedError: Operation is not supported
Consola de Firefox
Object doesn’t support property or method ‘attachShadow’
Una startup es una institución de seres humanos diseñada para crear un nuevo producto o servicio bajo condiciones de extrema incertidumbre.
Lean Startup toma su nombre de la revolución Lean manufacturing que Taiichi Ohno y Shigeo Shingo desarrollaron en Toyota. Se basaron en Lean Thinking para alterar los sistemas de la cadena de producción y suministros. Entre sus principios está la utilización del conocimiento y creatividad de los individuos, la reducción de los lotes, el método justo a tiempo para los sistemas de gestión de producción y control de inventarios, y una aceleración en las iteraciones. Enfocados en la creación de valor para los clientes y eliminar el desperdicio de esfuerzo.
Lean Startup adapta estas ideas en el contexto de emprendimiento. Para Lean Startup, emprendimiento es un tipo de administración, así es, un emprendedor es un tipo de administrador. La única deferencia es que muchas veces los administradores trabajan en una ambiente más controlado con un producto o servicio existente.
Pero ¿Qué sucede cuando en una empresa se requiere agregar una característica nueva o innovar en un producto existente? Muy probablemente la incertidumbre va a crecer. Y ¿Qué pasaría si una empresa quiere lanzar un nuevo producto o servicio?, en este último caso, podemos decir con seguridad que la incertidumbre es extrema. Esto es lo que realmente sucede en las empresas, porque vivimos en un mundo con cambios sumamente constantes y los administradores necesitan adaptarse a estos cambios.
Debido a esta incertidumbre extrema, una startup no se puede gestionar con los métodos tradicionales, el fracaso en una startup es necesario para el aprendizaje, cometer errores tempranamente para validar tus ideas iniciales y entonces adaptarse mejorando el producto a la necesidad real del cliente.
Con la anterior definición podemos listar los 5 principios de Lean startup:
Emprendedores hay en todas partes
Si ponemos atención la definición de arriba sobre lo que es un emprendedor, podremos comprender que un emprendedor está en todas partes, desde la compañía más grande e internacional, hasta la más pequeña, en cualquier sector, en cualquier industria y en condiciones de extrema incertidumbre.
Emprendimiento es Administración
Así es, una startup es una institución, y requiere un nuevo tipo de administración enfocado en el contexto de condiciones de extrema incertidumbre. Esto quiere decir que una startup no solo se trata del producto, sino de una institución humana completa.
Aprendizaje validado
Una de las claves para el éxito de una startup es el aprender como crear un negocio sustentable, y este aprendizaje se valida usando experimentos frecuentemente de tal forma que se pueda probar cada elemento de la visión de la startup.
Construir-Medir-Aprender
Es el proceso fundamental de una startup, convertir ideas en productos, medir como los clientes reaccionan y aprender si se debe cambiar la estrategia o seguir adelante con la ruta actual. Este proceso está siempre en mejora continua para acelerar la retroalimentación del cliente.
Innovación contable
Como decíamos, necesitamos métodos diferentes, ¿Cómo podemos medir el progreso de la startup?, ¿Cómo definir metas? y ¿Cómo priorizar nuestro trabajo? La contabilidad de una startup no solo son números financieros, lo más importante es medir el valor que le proporcionamos a nuestros clientes y como obtener crecimiento basándonos en ese valor.
Ciclo de retroalimentación Construir-Medir-Aprender y motor de crecimiento
Lean startup es administración de empresas que proporcionan productos o servicios en ambientes de extrema incertidumbre. Aunque existe mucho material sobre administración de negocios, muchas veces no se toma en cuenta la incertidumbre en el que estos negocios se encuentran.
Lean Startup recomienda medir la productividad de manera diferente, este nuevo enfoque existe porque muy a menudo se construye algo que nadie quiere, entonces no importa si se construye a tiempo o dentro del presupuesto si al final nadie va a querer el producto o servicio.
El objetivo de una startup es descubrir lo más pronto posible lo que el cliente realmente quiere y va a pagar por ello, de esta manera se construye solo lo necesario de mucho valor y se evita el desperdicio de tiempo, dinero y esfuerzo. Es una nueva forma de ver el desarrollo de nuevos productos e innovaciones donde se utiliza mucho las iteraciones ágiles con un gran enfoque en el comportamiento del cliente y la combinación de una gran visión de lo que se quiere lograr.
Eric Ríes utiliza la metáfora del automóvil de combustión interna para describir lo que es Lean startup. Dentro de un automóvil existen dos importantes ciclos de retroalimentación:
El motor en sí, llamado Motor de Crecimiento.
Conductor y volante, llamado Construir-Medir-Aprender.
Motor de crecimiento. Se encuentra dentro del motor, cada explosión de los pistones provoca la suficiente fuerza para hacer girar las ruedas y al mismo tiempo impulsa la ignición para la siguiente explosión de los pistones y así generar el continuo movimiento de las llantas de un coche. Esto se traduce a todas las operaciones, marketing y mejoras del producto que se realizan dentro de una institución, esto permite que el motor continúe su función e impulse al crecimiento. En una startup, la mayor parte del tiempo se invierte en poner al 100% este motor, mejorándolo constantemente basándose en los resultados del segundo ciclo de retroalimentación.
No sé mucho de autos, y mucho menos de motores, pero imaginemos que se utilizan distintos motores según el terreno por el cual un coche se desplaza, con esto se explica la relación con el segundo ciclo de retroalimentación, si vamos a nuestro destino a través de una autopista y un camino plano, es claro que necesitamos un motor con mucha velocidad y que aguante la aceleración más rápida durante mucho tiempo, pero si al contrario vamos en un camino de tierra con terreno irregular, con subidas y bajadas bruscas, es necesario un motor con mayor aguante a los cambios continuos entre pausas y aceleraciones, y que por lo tanto además de rapidez para avanzar también necesitamos resistencia a estos terrenos irregulares para llegar a nuestra meta. Necesitamos afinar o cambiar el motor en función del terreno por donde nos desplazamos.
Es importante mencionar, que como el motor de un coche, si no se le da el adecuado mantenimiento y afinaciones necesarias podemos provocar que nuestro coche deje de avanzar, es decir, detenemos el crecimiento de nuestra startup.
Construir-Medir-Aprender. Cuándo se usa un automóvil para llegar a un lugar específico, puedes ir a ese destino incluso si no sabes llegar, revisas un mapa, en el camino puedes preguntarle a personas por indicaciones, cambiar de dirección más de una vez, descubrir un atajo, tomar una ruta que haga que te desvíes pero que inmediatamente lo reconozcas y puedas corregir la dirección hacia tu meta, en fin muchas cosas pueden pasar.
Otra analogía es que si planeas correr un maratón, empieza con unos kilómetros diarios, investiga mejores formas de obtener condición física rápidamente y cada día aumentas un kilómetro o más, vas aumentando tu kilometraje conforme vas mejorando tu condición hasta obtener los kilómetros deseados para tu maratón, es obvio que necesitas hacer esto cuanto antes para fallar lo más pronto posible y aprender antes del día del maratón. No sería inteligente esperar a unos días antes del maratón o peor aún, simplemente correr el maratón completo y fracasar en el intento, tu cuerpo y tu mente no estarán preparados para aguantar el maratón.
En contraste, para lanzar un cohete al espacio se necesita mucha planeación y cálculos, cada cambio de ruta debe estar calculado con anticipación, el minúsculo error hará que un cohete no llegue a su destino o provocar una catástrofe. Hacer las cosas cómo lanzar un cohete, todo a mucho detalle y que el más mínimo error resulte en el fracaso del negocio no es para nada deseable. Por desgracia muchos planes y estrategias de negocios son tratados igual que el lanzamiento de un cohete, lo ideal es ver el plan de negocios tal como manejar un coche.
Por esta razón Lean Startup está diseñado para enseñar cómo gestionar una startup de la misma forma que manejar un carro, en lugar de hacer planes complejos basados en un montón de suposiciones, puedes hacer constantes cambios con un volante llamado Construir-Medir-Aprender.
Con este manejo de volante, podemos saber si de verdad necesitamos cambiar de ruta y cuando hacerlo, a esto se le llama pivotar, o seguir con la ruta actual, esto último llamado perseverar. Una vez que se ha aprendido y construido lo suficiente para que el motor de crecimiento esté en óptimas condiciones, se puede escalar y crecer con la máxima aceleración gracias a los métodos que Lean Startup ofrece.
Ahora bien, existen tres componentes claves que permiten alcanzar los objetivos dentro de Lean startup. Imaginemos que vamos manejando al trabajo, estamos decididos en llegar y no nos damos por vencidos debido a un desvío o porque tomamos una ruta equivocada. De la misma manera Lean Startup tiene una brújula de hacia dónde se quiere llegar, a crear un negocio que cambie la vida de muchas personas y que sea próspero para todos, esto es llamado Visión.
Para lograr esa visión, Lean startup emplea una estrategia, la cual incluye el modelo de negocio, el roadmap del producto, un punto de vista de la competencia y los socios, e ideas sobre quiénes serán los clientes.
Gracias a la visión y estrategia se llega al punto final, el producto. El producto cambia constantemente en un proceso de optimización llamado Afinación del Motor. Con menos frecuencia la estrategia sufre cambios, a estos cambios se le llama pivote, la visión muy rara vez cambia porque se está totalmente enfocado en conseguir los principios establecidos en la visión.
Visión, producto, estrategia
Una startup es un portafolio de actividades. Muchas cosas suceden simultáneamente; el motor está corriendo, consiguiendo nuevos clientes y atendiendo a los existentes; se afina el motor, tratando de mejorar el producto, marketing y operaciones; se está dirigiendo con el volante Construir-Medir-Aprender, dónde se decide si es necesario un cambio en la estrategia y cuándo hacerlo (pivotar).
Aunque hablamos de dos importantes ciclos de retroalimentación, Motor de crecimiento y Construir-Medir-Aprender. Este último tiene una gran importancia e influye poderosamente al primero gracias al aprendizaje validado que se obtiene. A medida que vamos aprendiendo con el ciclo de Construir-Medir-Aprender, podremos hacer cambios en el motor, podemos definir con mejor seguridad que tipo de motor necesitamos y que mejoras debemos hacer a este motor para acelerar el crecimiento, y por supuesto, que dirección tomar.
El motor de crecimiento realmente es tu producto o servicio, y depende de las decisiones tomadas en tu estrategia, la cual a su vez está subordinada por el ciclo Construir-Medir-Aprender, y la última parte, la visión de tu startup, es la base de todos estos componentes. Podríamos decir que la pirámide de los tres componentes claves para una startup se encuentra en el centro del ciclo Construir-Medir-Aprender, los resultados de este ciclo influyen en cambios en el producto y en la estrategia, pero como mencionamos antes, muy rara vez influirá en la visión, pero no se descarta que su influencia en la visión pueda suceder.
Un diagrama representando esta relación sería el siguiente:
Veamos con más detalle este grandioso ciclo de aprendizaje validado, recuerda que decimos que es un aprendizaje validado porque nos permite saber lo que el cliente realmente quiere y está dispuesto a pagar por ello.
En la imagen de arriba vemos que tenemos flechas en ambas direcciones, esto es así porque el orden en que se ejecutan las tres etapas es inverso a su planeación, describamos un poco estas etapas, empezaremos con la planeación, que es lo primero que haríamos antes de ejecutar nuestro plan. Una startup transforma ideas en productos, estas ideas u oportunidades de negocio nos permite definir nuestra visión en dos partes, esto sería nuestro primer aprendizaje base:
Hipótesis de valor, que nos permite probar que nuestro producto es de valor para nuestros clientes potenciales.
Hipótesis de crecimiento que nos revela de que manera nuevos clientes pueden fácilmente descubrir los beneficios del producto y expandir nuestro alcance.
Luego teniendo la definición de nuestras hipótesis, ahora podemos utilizar innovación contable para saber que es lo que específicamente necesitamos medir para que en la ejecución podamos determinar si estamos obteniendo aprendizaje validado.
Posteriormente basado en las dos etapas anteriores sabremos definir lo que se va a construir, es decir, que experimento correr y obtener los datos necesarios para saber si vamos por buen camino (perseverar) o necesitamos pivotar.
Ya que tenemos el plan de nuestra iteración, es el momento de la ejecución, es decir, Construir, Medir y Aprender.
Los productos que se construyen en una startup son nada más que experimentos, experimentos realizados lo más pronto y lo más ágil posible, y lo ideal es realizar avances pequeños (lotes chicos) para aprender rápidamente cómo construir un negocio sustentable.
Muchas iteraciones de este ciclo serán experimentos fallidos y también habrá experimentos exitosos, pero esto es bueno, una Startup necesita de los aciertos y de los errores lo más temprano posible para conseguir sus objetivos.
Estos aciertos y errores son medidos antes de obtener nuestro aprendizaje, pero esta medición es muy diferente a las métricas tradicionales, es por eso que se le llama innovación contable.
Ahora que terminamos de construir nuestro experimento, lo pusimos a prueba con clientes potenciales y obtuvimos las métricas necesarias en nuestra iteración, es hora de Aprender. Ya que tenemos nuestro aprendizaje validado, sabremos si pivotar o perseverar y de nuevo planeamos la siguiente iteración para poder ejecutar de nuevo este ciclo.
NOTA: Solo soy aprendiz de Lean Startup, es un tema del que estoy aprendiendo muchísimo y del cual plasmo ese aprendizaje a través de esta publicación, una publicación que espero les sea de gran utilidad.
“Event loop”, tal vez lo has escuchado. Esto es porque javascript tiene modelo de ejecución de código donde utiliza un ciclo de eventos (event loop), que una vez entendiendo su funcionamiento, se puede crear código mucho más eficiente, y resolver problemas rápidamente, que a simple vista no son tan obvios. Es la base de la concurrencia y el asincronismo.
Para comenzar:
Javascript se ejecuta en un solo hilo de ejecución, como se ejecuta un solo hilo, su ejecución es secuencial, no es como JAVA donde se pueden lanzar otros hilos.
Existen ambientes huéspedes donde se ejecuta javascript que tienen su propia API, ejemplo:
Navegador web
Node.js
Este funcionamiento secuencial es el mismo, no cambia por estar relacionado con un ambiente huésped.
La concurrencia se logra a través de invocaciones asíncronas a la API del ambiente huésped, esto evita que el funcionamiento se bloquee y provoque lentitud de las aplicaciones.
Elementos para la concurrencia
Veamos con más detalle los elementos que hacen funcionar Javascript en los ambientes huéspedes.
Call Stack – Pila de ejecuciones
Callback Queue – Cola de retrollamadas, tambien llamado Task Queue
Event Loop – Ciclo de eventos
Host Environment – Funcionalidad del ambiente huésped
Event loop, ciclo de eventos javascript
Calls Stack, heap y motor de javascript
Del lado izquierdo tenemos al motor de javascript, este motor se encarga de ejecutar nuestro código. A veces es llamado máquina virtual, porque se encarga de interpretar nuestro código a lenguaje máquina y ejecutarlo. Solo puede ejecutar una línea de código a la vez. Tiene un Heap para guardar objetos y demás datos en memoria que el código pueda generar.
Pero también tenemos una Pila de llamadas (Call Stack). Los elementos de la pila son objetos y datos de memoria, pero tienen una estructura especifica. Tienen un orden y el último elemento en entrar es el primero en salir, se le llama LIFO (Last-in, First-out).
Cada elemento de la pila es un trozo de código Javascript y guarda las referencias del contexto y variables utilizadas. La pila ejecuta el trozo de código en turno hasta quedar vacía.
Callbacks Queue
Abajo tenemos Callbacks Queue, es una estructura de datos y guarda pedazos de código que el motor de javascript puede ejecutar. Es una cola, y como la cola de las tortillas el primero en formarse, es el primero en salir (FIFO, First-in, First-out).
Un callback, es una función que se pasa por parámetro a otra, de tal manera que esta última ejecuta el callback en un punto determinado, cuando las condiciones y/o los datos cumplen una cierta regla de invocación.
Event loop
Event Loop, este elemento nos permite mover la siguiente callback del Callbacks Queue al Call Stack. Como es un ciclo, en cada iteración toma un solo callback.
Ambiente huésped
Del lado derecho tenemos El ambiente huésped, el ambiente huésped es el lugar donde corremos Javascript, los más comunes son el Navegador web y Node.js. Las tareas que ejecuta el ambiente huésped son independientes de los demás componentes. En el navegador web tiene sus propias API como fetch, setTimeout, alert. Node.js también cuenta con su propia API como net, path, crypto.
¿Cómo es posible?, ¿Y la concurrencia? ¿Puedo hacer muchas cosas a la vez en un sitio web?
Todo el trabajo de poner un temporizador, renderizar contenido como texto, imágenes, animaciones, o ver videos, están a cargo del ambiente huesped. Lo que pasa es que las APIs del navegador web generan callbacks cuando su tarea ya está completada y los agrega al Callbacks Queue para que el event loop las tome y las mueva al Callstack.
Javascript se comunica con el ambiente huésped a través de su API, mas adelante vamos a utilizar un ejemplo basado en el diagrama de arriba, donde se utiliza window.setTimeout, la cual es una función del navegador web.
Concurrencia
Inicio es la función principal, con la que se inicia el proceso de ejecución en el call stack. Dentro de inicio tenemos cuatro setTimeout de dos segundos. La función setTimeout es propia del ambiente huésped, y a los cuatro setTimeouts le pasamos un callback, estos son, cb1, cb2, cb3 y cb4.
Los temporizadores setTimeout se ejecutan en la parte de la funcionalidad del ambiente huésped dejando tiempo de ejecución para el call stack. He aquí la concurrencia, mientras el ambiente huésped ejecuta un temporizador, el call stack puede continuar ejecutando código.
Después de los primeros dos segundos, el ambiente huésped, a través del primer setTimeout pasa cb1al callback queue, pero durante estos dos segundos se pueden realizar otras operaciones en el ambiente huésped, en el caso del navegador, un ejemplo seria que el usuario puede seguir escribiendo dentro de un textarea. De nuevo, he aquí la concurrencia.
Tras el primer setTimeout, el segundo setTimeout pasa cb2al callback queue y así sucesivamente hasta el cb4. Mientras los callbacks se pasan al callback queue. El event loop nunca deja de funcionar, por lo que en alguna iteración el event Loop pasa cb1al call stack y se empieza a ejecutar el código de cb1y esto mismo sucede con cb2, cb3 y cb4.
Event loop en acción
Aquí abajo esta el ejemplo del que hablamos, el temporizador genera los callbacks en el orden que aparecen los setTimeouts más dos segundos. El Event Loop toma un callback en cada iteración, por lo que cada cb de setTimeout se invocan uno después del otro, y no exactamente después de dos segundos, pues entre que se posicionan los callbacks en la cola y se mueven al callstack de ejecución transcurre más tiempo. Esto sin contar el tiempo que trascurre entre cada invocación de setTimeout.
Si en los cuatro callbacks se indica el mismo tiempo en milisegundos. Presiona el botón RERUN, Te darás cuenta de que los tiempos no son iguales y que pueden pasar más de dos segundos.
Conclusión
Las APIs huéspedes reciben callbacks que deben insertar en la callback queue cuando el trabajo que se les encomienda esta hecho, por ejemplo un callback de una petición ajax se pasa a la callback queue solo cuando la petición ya obtuvo la respuesta. En el ejemplo que describimos arriba con setTimeout, cuando pasan dos segundos, se inserta el callback al callback queue.
Mientras el ambiente huésped realiza sus tareas, en este caso, los demás temporizadores, el call stack de ejecución de javascript puede ejecutar el código que el event loop le puede pasar desde el callback queue.
El Event loop es un ciclo infinito que mientras existan callbacks en el callback queue, pasara cada callback, uno por uno, al call stack.
El call stack no puede ejecutar más de un código a la vez, va ejecutando desde el último elemento hasta el primero, en nuestro caso hasta la terminación de la función inicio que dio origen a todo el proceso. Es una estructura de datos tipo Pila.
Gracias a que los callbacks se ejecutan hasta que un trabajo específico esté terminado, proporciona una manera asíncrona de ejecutar tareas. Las tareas pueden realizarse en el ambiente huésped sin afectar la ejecución del call stack. En la pila solo se ejecuta código que recibe el resultado de las tareas realizadas por el ambiente huésped.
Redux es un contenedor predecible del estado de aplicaciones JavaScript.
Te ayuda a escribir aplicaciones que se comportan de manera consistente, corren en distintos ambientes (cliente, servidor y nativo), y son fáciles de probar. Además de eso, provee una gran experiencia de desarrollo, gracias a edición en vivo combinado con un depurador sobre una línea de tiempo.
redux.org
Te permite controlar el flujo de datos de una aplicación Javascript, este flujo de los datos funciona en una sola dirección. Por esta única dirección es mucho más fácil controlar las mutaciones y operaciones asíncronas.
Redux es parecido a flux, de hecho está basado en flux
En el estado de una aplicación, principalmente en aplicaciones SPA, esto es muy importante, porque las aplicaciones web modernas tienen gran complejidad de operaciones asíncronas. Además de controlar el estado entre los componentes.
¿Qué problemas puedo mitigar con Redux?
En el ejemplo de aplicaciones web, estas necesitan controlar peticiones a servidores, obtener datos y controlar el estado en el cliente. Aun cuando estos datos no han sido guardados en el servidor.
Estas aplicaciones modernas requieren de un control complejo y por eso nuevos patrones de arquitectura como Redux y flux nacen para hacer el desarrollo más productivo.
Las mutaciones de objetos son difíciles de manejar y más a escalas medianas y grandes. Se comienza a perder el control de los datos, este flujo de datos generan comportamiento no deseados. Mala información desplegada al usuario y código que es muy difícil de mantener.
Sin contar cosas más elevadas como tu salud y causa de estrés por el esfuerzo en arreglar estas inconsistencias, te hace perder tiempo para mantener la aplicación funcionando correctamente. Por si fuera poco afectas a tus usuarios porque ellos obtienen información incorrecta y pierden su tiempo al utilizar esa información.
¿Qué decir de las operaciones asíncronas? Bueno, prácticamente pasa lo mismo o aún peor. Porque en una operación asíncrona no sabes cuando obtendrás el resultado y además normalmente vienen acompañadas con el deseo de hacer modificaciones al estado de la aplicación.
Un ejemplo común es el control de los datos de tu aplicación con cualquier frawework front-end de componentes visuales.
¿De qué está hecho Redux? Tres elementos
Store. El store es un objeto donde guardas toda la información del estado, es como el modelo de una aplicación, con la excepción que no lo puedes modificar directamente, es necesario disparar una acción para modificar el estado.
Actions. Son el medio por el cual indicas que quieres realizar una modificación en el estado, es un mensaje o notificación liviana. Solo enviando la información necesaria para realizar el cambio.
Reducers. Son las funciones que realizan el cambio en el estado o store, lo que hacen internamente es crear un nuevo estado con la información actualizada, de tal manera que los cambios se reflejan inmediatamente en la aplicación. Los reducers son funciones puras, es decir, sin efectos colaterales, no mutan el estado, sino que crean uno con información nueva.
¿Qué principios debo seguir? Tres principios
Un único Store para representar el estado de toda la aplicación. Tener una sola fuente de datos para toda tu aplicación permite tener centralizada la información, evita problemas de comunicación entre componentes para desplegar los datos, fácil de depurar y menos tiempo agregando funcionalidad o detectando errores.
Estado de solo lectura. Esto permite tener el control de cambios y evitar un relajo entre los diferentes componentes de tu aplicación, ni los componentes, ni peticiones ajax pueden modificar directamente el Estado (state) de tu aplicación, esto quiere decir que si quieres actualizar tu estado, debes hacerlo a través de actions, de esta manera redux se encarga de realizar las actualizaciones de manera estricta y en el orden que le corresponden.
Los cambios solo se hacen con funciones puras. Al realizar los cambios con funciones puras, lo que realmente se hace es crear un nuevo objeto con la información actualizada, estas funciones puras son los reducers y no mutan el estado, al no mutar el estado, se evitan problemas de control, datos incorrectos, mal comportamiento y errores, también permite que la depuración sea más fácil. Puedes dividir los reducer en varios archivos diferentes y las pruebas unitarias son fáciles de implementar. Los reducers son funciones puras que toman el estado anterior y una acción, y devuelven un nuevo estado.
Otras arquitecturas como MVC (Modelo, Vista, Controlador), los cambios pueden existir en ambas direcciones, es decir, la vista puede cambiar el estado, el modelo lo podría modificar y también el controlador. Todos estos cambios necesitan estar sincronizados en varias partes de una aplicación para evitar inconsistencias, lamentablemente este problema de inconsistencia se vuelve muy difícil y tedioso de resolver.
Lo anterior no sucede con Redux.
¿Cómo funciona? Mi primer estado predecible con Redux
Primero veamos el flujo de una sola dirección de redux:
Redux: flujo de control una sola dirección
Ahora un ejemplo concreto para saber de que estamos hablando, el control de un contador:
Si quieres probar este ejemplo en tu máquina recuerda insertar o importar la librería Redux. En este ejemplo podemos ver el funcionamiento de Redux, cada vez que se da clic sobre los botones de incrementar y decrementar, el contador se incrementa y decrementa.
Si ahora nos vamos al código JS, podremos ver que solo tenemos una función llamada counter, esta función es un reducer y es una función pura, sin efectos colaterales.
Luego vemos que como parámetros recibe un state y un action, cuando creamos nuestro Store con Redux, estas funciones reducer son utilizadas para modificar el State.
Normalmente, el state, reducer y action son definidos en puntos diferentes, y pueden ser organizados en varios archivos y carpetas dependiendo de la necesidad de la aplicación, toda esta organización tiene la finalidad de tener un código limpio y separar funcionalidades. En este caso sencillo no es necesario, en un solo archivo tenemos todo.
State
Nuestro state es solo un valor numérico, el cual se va a incrementar o decrementar con los botones que están en la página, normalmente el state es un objeto literal o un array literal, pero en nuestro caso solo necesitamos un número. Su definición podría estar en otro archivo, sin embargo, para este ejemplo no es necesario, lo agregamos como valor por defecto del parámetro state.
functioncounter(state=0,action){...
Actions
Si seguimos revisando nuestro código, veremos unos cuantas condiciones que revisa el valor del parámetro action y dependiendo de la acción, se ejecuta alguna operación, en nuestro caso son las operaciones INCREMENTAR o DECREMENTAR.
Los actions no son más que objetos literales como los siguientes:
Los reducer revisan esos actions, en nuestro ejemplo:
if (action.type ==='INCREMENTAR') {returnstate+1;}if (action.type ==='DECREMENTAR') {returnstate-1;}
Con todo esto ya tenemos nuestro State y su estado inicial en caso de no estar definido, también nuestra primer reducer, counter, y nuestros primeros actions INCREMENTAR y DECREMENTAR.
Store
Es el momento de crear nuestro Store, utilizando la librería redux esto es muy fácil:
const store = Redux.createStore(counter);
Con la anterior línea, Redux crea un Store para controlar el estado de nuestra aplicación. Internamente, un Store es un Patrón observador que utiliza un Singleton para el State y expone los siguientes métodos principales:
store.getState()
store.subscribe(listener)
store.dispatch(action)
store.getState() te permite obtener el estado actual de tu aplicación.
store.subscribe(listener) ejecuta la función listener (u observador), cada vez que el store es actualizado.
store.dispatch(action) pide actualizar el estado, esta modificación no es directa, siempre se realiza a través de un action y se ejecuta con un reducer.
Reaccionar a cambios del state
Luego creamos una función render, para que se ejecute cada vez que el State de tu aplicación cambie.
Aquí te preguntarás, ¿Cómo es posible que esa línea imprima 0 en la pantalla?, pues internamente el store invoca un dispatch con un action vacío store.dispatch({}), esto invoca nuestra función reducer y al no encontrar ninguna acción, entonces regresa el estado inicial 0.
Luego nos subscribimos a store para escuchar u observar el State cada vez que se actualice y poder ejecutar la función render().
store.subscribe(render);
Esta línea permite que cuando demos clic en los botones de incrementar y decrementar, se imprima el nuevo valor en la página volviendo a renderizar su contenido.
Ejecutar dispatch a través de eventos del DOM
Y por último agregamos dos listeners correspondientes a los botones de incrementar y decrementar, cada botón realiza una invocación dispatch para modificar el estado.
Al fin tenemos el flujo de datos de nuestro sencillo ejemplo usando Redux, en general los componentes que forman a una aplicación que utiliza Redux son los siguientes:
Redux: flujo de control completo
Conclusiones
Podemos notar el flujo en una sola dirección desde la vista con los actions dispatch(action), luego los reducers counter(prevState, action) para modificar el store y este último manda la información a través de subscribe(render) y getState().
Redux como ya se mencionó en párrafos anteriores, nos proporciona:
El conocimiento en todo momento del estado de nuestra aplicación y en cualquier parte de la aplicación con mucha facilidad.
Fácil organización, con actions, reducer y store, haciendo cambios en una sola dirección, además puedes separar tus actions, reducer y el store en varios archivos.
Fácil de mantener, debido a su organización y su único store, mantener su funcionamiento y agregar nuevas funcionalidades es muy sencillo.
Tiene muy buena documentación, su comunidad es grande y tiene su propia herramienta para debuguear
Todos los puntos anteriores hacen que sea fácil de hacer pruebas unitarias.
Y lo más importante, te ahorra tiempo, dinero y esfuerzo xD.
El mundo es un entorno cambiante, los mercados, las industrias, las personas, los usuarios, por consiguiente también los problemas, es aquí donde entra en escena Scrum. Por esta razón, es necesario una perspectiva que nos permita conocer y aprender del problema. Conocer y aprender nos da la capacidad de inspeccionar para poder realizar adaptaciones a la solución de tal manera que disminuya la incertidumbre.
Scrum es un framework ágil que sirve para construir productos que generan un alto valor e impacto para el negocio del cliente y al mismo tiempo se construye la solución con el mínimo esfuerzo.
El beneficio de scrum es darnos la habilidad de adaptarse al cambio sin perder la estabilidad de la solución, gracias al desarrollo sustentable implementado. ¿Qué queremos decir con sustentable? Significa que la solución conserva su estabilidad aun cuando iterativamente lo incrementamos. La calidad del producto influye considerablemente en la sustentabilidad de la solución.
El primer paso es alinear ciertos principios y valores. De tal manera que en conjunto sean la masa rocosa en la que se pueda edificar un castillo y no la masa de arena en la que solo nos permita construir una casa y a la primera llovizna se derrumbe.
Cuando hablamos de principios y valores estamos hablando de las relaciones interpersonales. Esto es importante porque las personas son los individuos que en conjunto forma un equipo para crear los productos, aplicaciones y sistemas computacionales que otros individuos van a utilizar. Estas mismas personas son las que forman empresas y organizaciones.
Individuos e interacciones sobre procesos y herramientas.
Es por eso que los valores en los que se basa Scrum giran alrededor de principios que promueven productivas interacciones entre individuos:
Coraje
Enfoque
Compromiso
Respeto
Apertura (franqueza, actitud abierta y receptiva)
Los valores de Scrum están basados en varios principios básicos del ser humano, no son principios difíciles, es sentido común, busca en tu interior y verás que esos principios siempre están latentes en menor o mayor medida, cada persona es diferente, pero estos principios siempre están ahí:
Honestidad
Justicia
Integridad
Amor
El uso exitoso de Scrum depende de que las personas lleguen a ser más virtuosas en la convivencia con estos cinco valores. Las personas se comprometen de manera personal a alcanzar las metas del equipo scrum. Los miembros del equipo Scrum tiene el coraje para hacer bien las cosas y para trabajar en los problemas difíciles. Todos se enfocan en el trabajo del sprint y en las metas del equipo Scrum. El equipo Scrum y sus interesados acuerdan estar abiertos a todo el trabajo y a los desafíos que se les presenta al realizar su trabajo. Los miembros del equipo Scrum se respetan entre sí para ser personas capaces e independientes.
Respeto
Los miembros del equipo Scrum se respetan entre sí para ser personas capaces e independientes. Pero ¿Qué quiere decir respetarse?, para mí el respeto es preocuparse por la otra persona, esta preocupación es resultado de apreciar a los integrantes de tu equipo y este aprecio viene del amor, sí, suena cursi, pero es verdad, piénsalo.
Dado que respetas a los demás integrantes del equipo, estás totalmente dispuesto a ayudar a mejorar, opinar de manera constructiva y a respetar las opiniones de los demás. Este respeto recíproco se convierte en una gran confianza para que cada individuo se convierta en una persona capaz e independiente, cada individuo realizará su mayor esfuerzo debido a su integridad y respeto a los demás, lo que provoca un ciclo infinito de buenas intenciones.
Coraje
Porque tienes aprecio a tu equipo y a las metas propuestas, porque tu integridad es fuerte y sabes quien eres para el equipo, tienes el coraje de alzar la mano cuando algo esté bloqueando o disminuyendo la productividad. Tienes el coraje de opinar y hablar de mejoras dentro del equipo y también dentro de la organización misma si es necesario.
Enfoque
Cada miembro del equipo está consciente que para ser ágil y ayudar al equipo a realizar su trabajo es necesario enfocarse en el objetivo definido en cada sprint. Así evitamos desviarnos de lo que se quiere lograr en nuestras actividades diarias. Esto nos permite NO malgastar nuestro tiempo en cosas que no son importantes para el objetivo actual y acelerar el desarrollo de la solución.
Compromiso
Porque cada integrante del equipo tiene una integridad latente y comparten una gran honestidad y respeto. Entonces los miembros se comprometen de manera personal a alcanzar el objetivo del equipo Scrum porque saben perfectamente que ese compromiso es beneficioso para todos, porque les permitirá eliminar la frustración individual y del equipo.
No es estricto cumplir con cada detalle en específico de las tareas en un sprint, mientras no afecten al logro del objetivo se puede negociar el alcance. Pero cada integrante realiza con gusto su mayor esfuerzo, trabajando con transparencia y respeto mutuo. Si no se cumple totalmente lo esperado, existen eventos durante y después de un sprint que nos ayudan a mejorar nuestro alcance sin afectar el objetivo del sprint.
Apertura (franqueza, actitud abierta y receptiva)
Porque aprecias a tu equipo, eres honesto y te guías por la justicia. Estás abierto a opiniones, abierto al trabajo que se necesita hacer, al respeto mutuo y la honestidad o transparencia. A inspeccionarte a ti mismo y adaptarte para que el equipo Scrum sobrepase todo el trabajo y desafíos del proyecto.
Teoría de control de proceso empírico de Scrum
Ahora bien, dado que el entorno en que se trabaja es cambiante, scrum también se basa en la teoría de control de procesos empírico. Según la guía de Scrum:
El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
El empirismo de Scrum se construye con tres pilares:
Transparencia
Inspección
Adaptación
Anotación importante, los cimientos o la masa rocosa de estos tres pilares son los cinco valores de Scrum.
Pilares de scrum, transparencia, inspección y adaptación
Haciendo una analogía rápida con un espejo. Si nos paramos enfrente del espejo, pero este tiene manchas que no nos permiten vernos claramente, quiere decir que no es transparente. Lo cual provoca que si quiero peinarme, no podre inspeccionar mi cabello, dado que no logro observar bien mi cabello no podre adaptarlo para que quede bien arreglado y peor aún, no sabré el resultado final de mi peinado.
Ahora, si el espejo está completamente limpio y transparente, este espejo seria Scrum (bien implementado claro), podre inspeccionar el estado de mi cabello y podré adaptarlo peinándome a una velocidad superior que si el espejo tuviera manchas, podre peinarme correctamente y podre contemplar el resultado final ("Mi .¨Vbñ´Vcabello bien peinado... jajaja xD).
Transparencia
Todos los aspectos importantes del proceso deben ser visibles para aquellos que son responsables del resultado.
De esta manera cada integrante de un equipo scrum tiene los datos y las herramientas necesarias para conocer todos los aspectos de lo que se va a construir y/o se está construyendo.
Inspección
La inspección no se puede dar si no hay transparencia, la inspección es visualizar e identificar los puntos de mejoras u errores de tal manera que se conoce y aprende profundamente sobre el problema a resolver. Este pilar provoca el aprendizaje.
Adaptación
Debido a la transparencia del proceso y al aprendizaje con la inspección, se puede mejorar y tomar las acciones necesarias para aumentar el valor e impacto de la solución al mismo tiempo que se reducen riesgos y también se mitigan desviaciones de los objetivos deseados. En conclusión se adapta.
Roles de un Scrum Team
El framework scrum define tres roles:
Product Owner responsable de maximizar el valor del producto/servicio que se va a construir. Administra el product backlog.
Desarrolla y comunica explícitamente el objetivo del producto
Crea y comunica claramente los elementos del product backlog
Ordenar los elementos del product backlog
Asegurarse de que el producto backlog sea transparente, visible y que se entienda.
Scrum Master, ayuda a todo el equipo a entender el framework scrum con la teoría, reglas, valores y prácticas. Es un verdadero líder que sirve a los developers, product owner y a toda la organización.
Developers, son las personas que van a construir el producto y/o servicio. Sus responsabilidades principales son:
Crear un plan para el sprint, esto es el sprint backlog
Inculcar calidad al adherirse a una definición de terminado (DoD)
Adaptar su plan cada día hacia el objetivo del sprint
Responsabilizarse mutuamente como profesionales
Estos tres roles en conjunto forman el scrum team. Dentro del scrum team no existen las jerarquías ni tampoco se dividen en sub equipos. También el scrum team son multifuncionales, esto quiere decir que en conjunto tiene todas las habilidades necesarias para crear valor en cada sprint. Pueden compartir las habilidades y adquirirlas según se vaya necesitando.
El tamaño del scrum team debe ser lo suficientemente pequeño para facilitar la agilidad, pero lo suficientemente grande para generar el suficiente valor en cada sprint, normalmente 10 personas o menos. Si es necesario un equipo más grande, entonces se debe considerar crear varios scrum teams enfocados en el mismo producto. En consecuencia deben compartir el mismo objetivo del producto, product backlog y product owner.
Eventos de scrum
Cada uno de los pilares anteriores se viven en los Eventos de Scrum, nos ayudan a la inspección y adaptación de los artefactos, es decir, provocan el aprendizaje y la mejora continua, pero para eso cada evento y artefacto debe tener total transparencia. Así también cada uno de los valores de scrum se viven en todo el proceso, como se manifestó antes, son los cimientos de los pilares y de scrum.
Saltarse cualquier evento de scrum hace que se pierda una oportunidad para inspeccionar y adaptarse. Además, cumplir con los eventos genera regularidad y minimiza la necesidad de reuniones no definidas en scrum. Como recomendación los eventos deben celebrarse al mismo tiempo y en el mismo lugar para reducir complejidad.
Sprint
Esta palabra significa carrera corta, si, una carrera pequeña que nos permita trabajar en la solución y al mismo tiempo inspeccionar y adaptarnos rápidamente, esto siempre con la transparencia necesaria en todo el equipo. Dentro del sprint suceden los 4 eventos restantes necesarios para lograr el objetivo del producto
Durante un sprint:
No se realizan cambios que pongan en riesgo el objetivo del sprint
La calidad no disminuye
El Product Backlog se refina según sea necesario
El alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más.
La longitud de un sprint puede ser de un mes o menos, un sprint sigue el principio lean sobre lotes pequeños. Si el sprint es mayor a un mes, se empieza a hacer grande y la complejidad también, lo que provoca un aumento del riesgo. Adicionalmente, al ser un sprint grande el objetivo del sprint puede cambiar y el aprendizaje es mucho más lento porque la retroalimentación no sucede a tiempo.
Un sprint puede cancelarse si el objetivo del sprint se vuelve obsoleto. Solo el Product Owner tiene la autoridad para cancelar el sprint.
Sprint Planning
Aquí se define que se va a hacer en el sprint (objetivo) y como se va a realizar. En la planificación participan todo el equipo scrum de tal manera que se pone en práctica principalmente el foco con el objetivo del sprint y la transparencia del conocimiento de como se va a trabajar.
El sprint planning aborda los siguientes temas:
¿Por qué es valioso este sprint? Resulta en el objetivo del sprint. El product owner propone como el producto puede incrementar su valor y utilidad en el sprint actual.
¿Qué se puede hacer en este sprint? El Product Owner y Developers seleccionan elementos del Producto Backlog para incluirlos en el sprint actual. Pronosticar cuando se puede completar en un sprint es muy difícil, pero cuanto más sepan los Developers sobre su desempeño pasado, su capacidad actual y su Definición de Terminado, más confiados serán en sus pronósticos.
¿Cómo se realizará el trabajo elegido? Los Developers planifican el trabajo necesario para crear un Incremento que cumpla con la Definición de Terminado (DoD). A menudo se hace descomponiendo los elementos seleccionados en piezas más pequeñas que se puedan terminar en un día o menos. La forma de hacerlo queda a criterio de los Developers. Nadie más les dice como convertir los elementos del Product Backlog en Incrementos de valor
El límite de tiempo para el sprint planning es de 8 horas para un sprint de un mes.
El objetivo del sprint, más los elementos seleccionados del product backlog para el sprint actual, más el plan para entregarlos se denominan juntos como Sprint Backlog.
Daily Scrum
Reunión diaria donde se puede ver (transparencia) el avance diario, de tal manera que se pueda inspeccionar y adaptar el progreso actual para lograr el objetivo del sprint. Si el Product Owner y el Scrum Master trabajan continuamente en elementos del Sprint Backlog, entonces ellos participan como Developers.
Los Developers pueden seleccionar la estructura y técnicas que deseen, siempre que su Daily Scrum se centre en el progreso hacia el objetivo del Sprint y produzca un plan viable para el siguiente día de trabajo. Esto genera enfoque y autogestión.
El Daily Scrum es un ciclo de retroalimentación diario que mejora la comunicación, identifica impedimentos, promueve la toma rápida de decisiones y elimina la necesidad de otras reuniones.
El límite de tiempo para el Daily Scrum es de 15 minutos.
Sprint Review
Aquí se revisa el producto o avance, es decir, el artefacto llamado Incremento. De nuevo, esta reunión fomenta la transparencia, inspección y adaptación para el próximo sprint. No es sola una demostración de los avances hasta el momento. Es una oportunidad para detectar adaptaciones.
Para ponerlos más claro, el Sprint Review es un ciclo de retroalimentación al final de cada sprint donde se fomenta la transparencia revisando el Incremento. El Scrum Team en conjunto con los stakeholders inspeccionan los resultados para tomar decisiones de adaptación para lograr el Objetivo del producto, pueden ajustar el Product Backlog si encuentran nuevas oportunidades o cambios importantes.
El límite de tiempo para el Sprint Review es de 4 horas para un sprint de un mes.
Sprint retrospective
Este evento es el que más relación palpable tiene con los pilares scrum en relación con el equipo humano, es donde se toman acciones concretas y se planifica lo que requiere hacer para mejorar la efectividad del equipo y la calidad del trabajo en el próximo sprint.
También es un ciclo de retroalimentación al final del sprint para inspeccionar y adaptar las personas mismas, las interacciones, los procesos y la Definición de Terminado.
El límite de tiempo para el Sprint Retrospective es de 3 horas para un sprint de un mes.
Artefactos de Scrum
Product Backlog (Lista de producto), lista de elementos o requerimientos que hasta el momento se conoce que el producto necesita.
Sprint Backlog (Lista de sprint), son los elementos seleccionados del product backlog para construirse en el sprint actual.
Increment (Incremento), es el producto terminado (hasta el momento) o avance terminado en un determinado sprint.
Más adelante veremos a detalle los roles, los eventos y los artefactos, espero que esta publicación les dé un panorama general de lo que es el Scrum.
ES_MX 
EN