Actualidad
25/10/2021
El pasado viernes 22 de octubre volvimos celebrar de nuevo un evento presencial con todos los empleados de ITERIAM.
Con cambio de fecha provocado por la pandemia, la Reunión General de Otoño junto a compañeros de diferentes localizaciones en el Club Las Encinas de Boadilla después de prácticamente 2 años de la última ocasión.
Un momento ideal para compartir de nuevo un rato juntos después de un tiempo complicado.
Actualidad
20/08/2021
Actualmente todos los clientes valoran de forma muy positiva disponer de servicios sin necesidad de desplazarse a oficinas físicas.
Hace unos años esto era complicado, la legislación no lo permitía y la tecnología no estaba lo suficientemente madura, pero hoy en día procesos como el alta de clientes o la contratación de productos son servicios que se ofrecen de forma digital por algunas compañías.
ITERIAM plantea en muchos de los proyectos de transformación digital a nuestros clientes cambiar procesos de contratación tradicionales a lo que es un onboarding digital para lo que hemos desarrollado una plataforma base específica.
Como pieza fundamental de esa plataforma, firmamos un acuerdo de colaboración con Mobbeel para utilizar sus soluciones para ofrecer una experiencia 100% digital en todos los procesos antes mencionados:
Con estas soluciones de Mobbeel que se suman a otros acuerdos firmados anteriormente, ponemos a disposición de nuestros clientes una solución de onboarding con unos tiempos de lanzamiento muy rápidos, posibilidades de integración ilimitadas, una experiencia de usuario óptima y adaptable en cuanto a legalidad y confirmación de la identidad digital en cada caso práctico.
Si quieres más información sobre esta solución, no dudes en escribirnos a [email protected].
Actualidad
24/05/2021
Cuando nos enfrentamos a cualquier proyecto podemos hacerlo de muchas formas, pero el resultado siempre queremos que sea satisfactorio.
Muchas generaciones recordamos la famosa frase de John Hannibal Smith de la serie “El equipo A” que titula este artículo. Podría haber usado otras series míticas como MacGyver como hilo conductor, pero necesitaba algo más potente. Me tentó también Michael Knight que encajaba bien como ejemplo de tecnología, pero improvisaba mucho.
Por eso el equipo A para lo que os quiero contar me pareció perfecto. ¿Os imagináis a Hannibal sin pensar una forma imaginativa para resolver las aventuras de cada episodio? ¿Sin definir un plan con sus compañeros de equipo? ¿Sin apoyarse en su experiencia previa como miembro de los cuerpos de élite del ejército?
Cuando abordamos un proyecto de usabilidad y experiencia de usuario cometemos errores básicos y simples, producto casi siempre de una insuficiente planificación y de repetir lo que vemos en otros proyectos. Planear bien las cosas tiene un montón de ventajas como evitar el retrabajo, acortar los tiempos de ejecución, asegurar la calidad del resultado, etc.
Os facilito en este artículo algunos ejemplos de buenas prácticas y recomendaciones, para que veáis que con poco que le deis al coco… ¡los planes siempre salen bien!
Mobile First ha dejado de ser una tendencia y actualmente es un patrón obligatorio para diseñar un proyecto web.
Haz como MA Barracus y tatúatelo. El modo en que los usuarios actuales asumen ver los contenidos está basado en experiencias móviles. Estas experiencias se basan en pantallas sencillas con scroll vertical.
La mayoría de los proyectos ya son responsive, pero no podemos confundir ese término con Mobile First.
Hay un gran error de usabilidad que se sigue cometiendo y es el contenido en las pantallas. Se sigue haciendo contenido para pantalla de escritorio y se desarrollan responsive. El resultado será un sitio web que se verá bien en otros dispositivos, pero tendrá un exceso de contenido en una única pantalla y elementos poco accesibles para operar con una mano.
Por ello hay que recalcar que Mobile First denota también que las pantallas han de ser sencillas, concisas y fáciles de usar desde cualquier dispositivo.
¿Qué pensaríais si la furgoneta del equipo A se pareciese a ésta?
Es importante hacer un buen estudio del Header ya que es el primer elemento que tocar y se repite en todo el sitio web que estéis diseñando.
Hay varios errores que se repiten y son tan fáciles de corregir con el objetivo de simplificar tus propuestas y centrarte en lo esencial. Estos son algunos de los consejos para crear un Header que funcione:
Sigo utilizando ejemplos gráficos para avanzar en mis recomendaciones. ¿Te imaginas al Equipo A con un R5 en vez de la furgoneta molona que usaban?
¿Como viajar con todo el equipo a las diferentes misiones? ¿Como disparar esas metralletas?
El espacio, ya sea en un sitio web, en una misión del equipo A o en tu vida, es muy importante. El espacio libre es eso que una persona usa, sin ser consciente, para sentirse a gusto en dicho espacio.
Para que una web sea cómoda y se use a gusto ha de tener mucho espacio libre y estas son algunas de las pautas a seguir:
Se ha podido demostrar que el “Loco Murdock” no era un personaje ficticio si no que sus trastornos estaban causados por consumir sitios web como el que veis en la siguiente imagen:
Cuando hablamos de obtener una buena experiencia en el uso de una plataforma el tema de las promociones y publicidad pueden tirar por tierra todo lo que hayas trabajado en el Header, en el contenido o en la navegación.
El uso muy moderado de estos recursos de publicidad – bien propia o ajena – resta a tu diseño, pero si te dejan llegar a tu destino debes pensar en si te interesa el impacto que provocan. El uso desmesurado de dichos recursos no es que resten, te anulan. Hacen inservible tu sitio web.
Otros dos factores para destacar que salen de esa publicidad son los logins o suscripciones y las políticas de cookies. El login siempre ha de estar accesible pero no debes atosigar al usuario para que se registre: deja que te conozca y sugiérelo sutilmente. Haz lo mismo con la newsletter.
En cuanto a las políticas de cookies, todos nos hemos subido a ese tren, pero que esa legislación no nos impida ver tu página. No llenes toda la página con ese mensaje porque puedes conseguir que ya no la quieran ver. Un mensaje discreto es lo que mejor funciona.
Un error muy simple se da cuando alguien decide presumir de sus redes en su página web. Los hay que te las ponen en el Nav y que merecen ser castigados. Otros en el Footer, tienen mi clemencia. Y otros, almas cándidas, por todas partes. Pues compañeros, mal plan.
El sentido de esos botones es que conozcas esas redes, pero vamos a poner a funcionar nuestra materia gris: ¿dónde está expuesto el grueso de nuestro negocio? ¿en las redes sociales? ¿en el sitio web? Debería estar en el sitio web mientras que las redes sociales son canales que usas para que la gente llegue a dicho sitio web.
Os voy a poner un ejemplo. Entráis a una tienda a comprar y delante de cada producto hay otras tres puertas: una puerta que te lleva a la empresa que hace la publicidad de la tienda, otra que te remite a un cartel de la carretera y la otra de nuevo te lleva al escaparate. ¿No tiene sentido verdad? Lo suyo es que ese escaparate, esa publicidad y ese cartel sean los que te llevan a la tienda a consumir tus productos.
Pues en muchos sitios web se ha instaurado esa tendencia y es un gran error. Si al entrar lo primero que ves son las redes sociales estás invitando al usuario a que lo primero que haga es salir de tu página e irse a una red social, donde sí, estás tú, pero también otros cuantos millones de empresas como tú.
Cabe destacar que no podemos confundir el botón de redes sociales del Nav o Footer con los botones en blogs que sirven para compartir dicho post dentro de una red social. Estos si tienen un gran sentido ayudando al SEO de dicha empresa.
El mal uso de los botones que te llevan a redes sociales es algo muy instaurado y es un mal hábito para la usabilidad de cualquier proyecto. Si te hago salir justo cuando entras… ¡no creo que los planes salgan bien!
Actualidad
09/04/2021
Hoy en día todo es digital y los dispositivos móviles son una herramienta siempre presente.
Por eso, ¿por qué no utilizar la tecnología en nuestro beneficio y comenzar a digitalizar un proceso tan simple y rutinario como firmar un documento?
Esta necesidad se planteaba en muchos de los proyectos de transformación digital que planteamos a nuestros clientes y por ello hemos firmado un acuerdo de colaboración con Signaturit, empresa líder dedicada a las soluciones de firma digital.
Con esta alianza queremos complementar los servicios que damos a nuestros clientes ofreciendo la mejor solución en el ámbito de la firma electrónica. Además de la digitalización de la firma, también resultan otras soluciones como el email certificado.
Gracias a esta colaboración estratégica podemos seguir personalizando nuestros servicios y creando desarrollos a medida que impulsen la digitalización de los procesos y la transformación de las empresas.
Estas soluciones relacionadas con la digitalización de firmas, al igual que nuestras aplicaciones móviles, se adaptan a cada cliente y sus necesidades.
Actualidad
10/02/2021
Después de la introducción realizada en la primera parte del artículo, ¡vamos a a ponernos a «picar»!
Partimos de un problema real al que trataremos de dar solución con nuestra Skill:
«Carmen es una joven emprendedora que dirige una pequeña tienda de decoración y coleccionismo en Toledo (España). El Baúl del Abuelo vende desde artículos originales para dotar a tu casa de una personalidad única a artículos para coleccionistas tales como vajillas o documentos antiguos. En un afán por ofrecer un mejor servicio a sus clientes, Carmen ha pensado en desarrollar una Skill de Alexa con la que sus clientes puedan comprobar el horario de apertura de su establecimiento”.
Una vez planteado el problema, explicaremos detenidamente los pasos que Carmen tendría que llevar a cabo para desarrollar su propia Skill con esta funcionalidad.
En este primer paso deberemos crear nuestra nueva Skill en la consola de desarrollo de Amazon y configurar el modelo de interacción para la interfaz de voz.
Para esto en primer lugar lo que tenemos que hacer es iniciar sesión en Amazon Developer (si aún no tienes cuenta puedes crearte una gratuita que te dará acceso a multitud de herramientas para desarrollar tus propias aplicaciones) y hacer uso de Alexa Developer Console, una interfaz gráfica de desarrollo que forma parte de la consola de desarrollo de Amazon.
Una vez dentro de la Alexa Developer Console, podemos ver la lista de Skills desarrolladas (en caso de no haber desarrollado ninguna la lista estará vacía). Para crear una nueva Skill hacemos clic en “Create Skill”:
Pon nombre a tu Skill, selecciona el idioma deseado y elige uno de los cuatro tipos de modelo interacción disponibles:
En este caso usaremos el de modelo de interacción personalizado (Custom Skill Model).
El siguiente paso es configurar el modelo de interacción de nuestra Skill. Para ello, la Alexa Developer Console nos muestra cinco secciones:
Utilizaremos cada una de estas pestañas de la barra de navegación para desplazarnos de un área a otra.
Empezaremos en la sección “Build” para diseñar un custom skill model para la Skill. La página de resumen del área de desarrollo se divide en tres secciones o columnas claramente diferenciadas. La Skill se crea utilizando la lista de comprobación del skill builder en la columna de la derecha y consta de cuatro pasos de configuración:
Inicia uno de los pasos de la configuración haciendo clic en el botón correspondiente de la lista de comprobación de Skill Builder. De manera alternativa, puedes seleccionar áreas de configuración determinadas mediante la barra del menú situada en la columna de la izquierda.
En la columna central de la página encontrarás material informativo sobre Alexa Skill Development, así como un vídeo sobre el área seleccionada de la consola de Alexa Developer.
1. Seleccionamos el Invocation Name
Primero definiremos el nombre de invocación de la Skill de Alexa. El nombre de invocación es la expresión que utilizarán los usuarios para activar/comunicarse con tu Skill. El nombre de invocación puede ser el mismo que el nombre de la Skill, pero puede diferir si es necesario.
A la hora de definir el nombre de invocación debemos tener en cuenta los siguientes aspectos:
Para la Skill que estamos desarrollando, usaremos el siguiente Invocation Name: el Baul del Abuelo. Guardamos el nombre de la invocación haciendo clic en “Save Model” y hacemos click en “Customs” para volver a la vista general.
2. Definición de propósitos o intents
Con los intents definimos lo que un usuario de tu Skill puede decir, cuál es el propósito de su manifestación y cómo reacciona tu Skill ante ella. Cada Skill personalizada contiene cinco propósitos (intents) preestablecidos que deben implementarse más tarde, a los que, además, podemos añadir más según sea necesario. A continuación, explicamos cómo crear un custom intent:
● Pon un nombre a la nueva acción y haz clic en “Create custom intent”:
Seguidamente debemos definir las posibles formas con las que los usuarios pueden pedirle a la Skill que ejecute la acción vinculada a la intent. Introduce la frase en el campo de texto y haz clic en el signo más (+).
De esta manera, la Amazon Developer Console aumentará a través de su IA los patrones de reconocimiento de habla que has definido. Sin embargo, esto solo es así si el sistema dispone de una base de datos suficientemente amplia, por lo que debes introducir al menos 8 ejemplos de expresiones con cada intent que elijas.
A continuación, pulsamos “Save Model” para crear el modelo y entrenarlo por aprendizaje automático.
3. Creación del modelo
Para crear el modelo debemos hacer click en “Build Model” y esperar a que la consola de desarrollo nos notifique que el modelo de interacción se ha creado con éxito.
Si después de crear el modelo queremos volver a hacer cambios en el nombre de invocación o los intents, solo tendríamos que reiniciar el proceso de compilación pulsando de nuevo “Build Model”.
4. Seleccionando el endpoint del servicio web
El paso 4 de la lista de comprobación de Skill Builder incluye la selección del endpoint del servicio web. Aquí hay dos opciones:
Para simplificar el tutorial, dejaremos de lado la opción de alojar la lógica en nuestro propio servidor web, y explicaremos cómo hacerlo haciendo uso de las funciones Lambda de AWS.
Para ello activaremos la casilla de verificación de AWS Lambda ARN. ARN significa “Amazon Resource Name” (nombre del recurso de Amazon). Es un nombre único para un recurso AWS, como una función Lambda, por ejemplo.
Antes de poder enlazar con ARN a una función Lambda que contiene la lógica del programa de tu Skill, primero debes crearla en la consola AWS. En el siguiente punto del tutorial veremos cómo hacerlo.
Basándonos en el modelo de interacción definido en el paso anterior, procedemos a crear una función Lambda AWS, que se ejecuta en la plataforma de Cloud Computing de Amazon y la cual incluirá la lógica de negocio de tu Skill.
Accede a tu cuenta AWS (Si no estás registrado, regístrate primero para obtener una cuenta de AWS gratuita) y selecciona “AWS Management Console” en “Mi cuenta”.
La consola de administración de AWS permite acceder y administrar los servicios web y recursos de computación de Amazon. Primero, asegúrate de que tu consola está configurada en la región donde quieres ofrecer tu Skill. (“EU (Ireland)” si deseas que tu funcionalidad esté disponible para los usuarios europeos). Para encontrar el producto AWS deseado, utiliza la función de búsqueda “Find services” y busca y selecciona el servicio lambda.
Una vez en la página principal del servicio, podemos ver un resumen de todas las funciones Lambda creadas. (Si todavía no has creado ninguna la lista estará vacía). Hacemos click en “Create function” para iniciar el proceso de configuración de una nueva función Lambda.
Las funciones AWS Lambda pueden crearse desde cero, utilizando un proyecto o partiendo de una aplicación proporcionada por AWS o por socios colaboradores en el repositorio AWS de aplicaciones serverless. Puesto que tenemos que recurrir a varias librerías de Alexa para la lógica del programa de nuestra Skill, es mejor partir de una plantilla que obtenemos de al seleccionar la opción “Examinar el repositorio de aplicaciones sin servidor”. Para el tutorial elegimos la plantilla “alexa-skill-kit-nodejs-factskill”.
Imagen 8: Seleccionamos la opción correspondiente para generar una función lambda usando la plantilla indicada.
Indicamos el nombre para nuestra aplicación y hacemos clic en “Deploy” para desplegar la aplicación serverless generada automáticamente en Cloud Formation.
En la nueva página a la que nos redirige, debajo de la sección de recursos, hacemos click al enlace para acceder a la función lambda vinculada a la aplicación automáticamente generada:
La máscara de configuración para la función se abre en una nueva pestaña, ya con valores establecidos por defecto (Permisos, roles, recursos, etc.)
Importante: En la ventana del código de la función lambda (que nos viene desarrollada por defecto al haber utilizado la plantilla), contiene la lógica de negocio específica para la acción que estamos desarrollando. Para personalizarla con el ejemplo que estamos siguiendo, eliminamos el código presente y lo sustituimos por el de nuestra aplicación pegando en su lugar el siguiente fragmento de código: https://jsfiddle.net/8tkz6dc5/
Conocer en detalle los conceptos de programación de Skills y el porqué de cada línea de código requeriría de un tutorial mucho más tiempo y lo dejamos para en otro tutorial, ya que no es el objetivo de este que estamos abordando. En caso de que queráis generar el código scaffolding para alguna Skill de Alexa de vuestro interés podéis hacer uso del Alexa Skills Code Generator para generar el nuevo código de nuestra Skill
Para que los usuarios puedan dirigirse a nuestra Skill utilizando un altavoz inteligente, se requiere un enlace en los dos sentidos:
1. Definir el modelo de interacción de la Skill como disparador de la función Lambda
Para ello accedemos a la configuración de nuestra función Lambda en la consola de gestión AWS y selecciona la opción “Alexa Skills Kit” como desencadenador (Es probable que aparezca seleccionada si has seguido las indicaciones del tutorial y has utilizado la plantilla alexa-skill-kit-nodejs-factskill para el desarrollo de la función). Una vez seleccionado, el kit de funcionalidades de Alexa aparece ahora como un disparador en la representación gráfica de la función Lambda, pero requiere una configuración adicional.
Para ello necesitamos el ID de la Skill del modelo de interacción disponible en la sección de Endpoints de la Alexa Developer Console:
Copia la cadena de caracteres que aparece en “Your Skill ID” en el portapapeles y, a continuación, introdúcelo como el ID de cualificación de tu función Lambda:
Confirma la configuración haciendo clic en “Add” (Agregar) y guarda los cambios (“Save”).
2. Registrar la función Lambda como endpoint de la Skill
Para enlazar la función Lambda creada y desplegada, copiamos el ARN de la función (en la parte superior del panel de administración de nuestra función lambda):
y lo pegamos en la configuración de endpoints de nuestra Skill Alexa, concretamente en el campo “Default Region”. Debes definir, al menos, un endpoint predeterminado para tu Skill. También puedes especificar endpoints alternativos para Norteamérica, Europa e India, así como para Oriente Próximo y Lejano. Guarda los ajustes con un clic en “Save Endpoints”
De esta manera, si un usuario interactúa con la Skill de Alexa que hemos desarrollado, se envía una petición POST al endpoint del servicio web predeterminado, en este caso, a la función Lambda vía ARN.
Dentro de la Alexa Developer Console tenemos la sección “Test”, que ofrece un entorno de pruebas completo para Skills, incluyendo un simulador de Alexa con salida de voz. De forma predeterminada, el entorno de pruebas está desactivado para las Skills de Alexa recién creadas. Actívalo cambiando el menú desplegable de “Off” (desactivado) a “Development” (desarrollo).
Para probar la Skill, llama a tu nueva Skill Alexa usando la invocación y prueba un comando de voz/texto que corresponda un intent contemplado previamente.
La Skill que estamos desarrollando como ejemplo puede iniciarse con la invocación “Alexa, abre el Baúl del Abuelo”. Alexa responde con el welcomeOutput definido en la lógica del programa:
“Bienvenido a el Baul del Abuelo, ¿en qué le puedo ayudar?”Si hacemos una pregunta que corresponda a la intención definida en el modelo de interacción, siguiendo nuestro ejemplo, obtendremos la siguiente respuesta:
"¿A qué hora abre la tienda? -> El horario de apertura de la tienda es de 10 de la mañana a 8 de la tarde”Como puede observarse, el acceso a la lógica del programa ha funcionado y Alexa entiende nuestra pregunta y nos da la información que necesitamos. La entrada y salida que ha procesado el servicio de habla de Amazon en la consulta se muestra en la ventana Skill I/O en formato JSON:
Alternativamente, es recomendable probar la Skills en los dispositivos conectados a tu cuenta antes de publicarlas y lanzarlas al market.
Una vez probada la Skill, puedes ponerla a disposición de otros usuarios si la encuentras satisfactoria y útil. Para ello debes ir a la sección “Distribution” y proporcionar toda la información necesaria para su publicación. Rellena todos los campos obligatorios bajo “Skill Preview” (vista previa de habilidades), “Privacy & Compliance” (Privacidad y cumplimiento) y “Availability” (disponibilidad).
En “Privacidad y cumplimiento”, especificaremos si los usuarios pueden utilizar funciones de pago dentro de tu Skill, si recopilas datos personales de los usuarios, si tu Skill está dirigida a usuarios menores de 13 años o si incluye publicidad.
En “Disponibilidad”, define las restricciones para la disponibilidad de tu Skill. ¿Debería estar disponible para todos los usuarios o solo para determinadas organizaciones? ¿Deben realizar las pruebas beta determinadas personas?, y ¿En qué países y regiones te gustaría publicarla?
En último lugar, guarda tus datos haciendo clic en “Save and continue” (guardar y continuar).
Después de haber guardado tus datos de publicación”, serás redirigido automáticamente al área “Certification” (certificación). La consola Alexa Developer comprueba tus datos y te pide, si es necesario, que revises la información incorrecta o que proporciones los datos que faltan.
Si la información introducida es correcta, puedes continuar con una prueba de funcionamiento haciendo clic en “Run” (ejecutar). Dependiendo del alcance de tu proyecto, el texto de la función puede tardar unos minutos en completarse. Si el informe de prueba muestra errores, tienes la opción de volver al área determinada, corregir el error y realizar una nueva prueba de funcionamiento.
Una vez completado con éxito la prueba funcional, estará lista para que Amazon valide y revise la Skill. Haz clic en “Submit for Review” (enviar para revisión) para certificar tu Skill. Una vez completada la revisión, recibirás un correo electrónico en la cuenta asociada a tu cuenta de desarrollador de Amazon. Existen básicamente dos escenarios posibles:
En la vista general de Skills de la Alexa Developer Console puedes ver el estado de todas tus Skills:
Actualidad
09/02/2021
Cuando hablamos de un altavoz inteligente o asistente de voz, estamos haciendo referencia a un altavoz conectado a Internet a un servicio de voz basado en nube que recibe comandos a través de una interfaz de voz y, por lo tanto, permite hacer uso de servicios en línea basados en audio y permiten controlar dispositivos conectados a través de Wifi o Bluetooth.
El servicio de voz de Amazon (Alexa) ofrece ya de serie varias funciones básicas tales como la reproducción de música, escuchar noticias, recibir informes de tráfico, predicciones meteorológicas, etc. Además, pueden instalarse otras funciones extra, las llamadas Skills o funcionalidades de Alexa, disponibles en la Alexa Skills Store, la cual actúa como un marketplace de aplicaciones o funcionalidades extras para los usuarios.
Las Skills de Alexa son programas que pueden instalarse en todo dispositivo inteligente que haga uso del servicio de voz de Alexa y que sirven para ampliar la gama de funciones básicas que este servicio ofrece. Más a bajo nivel, la arquitectura de una Skill de Alexa sigue un modelo cliente-servidor, donde cualquier dispositivo que soporte el servicio lingüístico de Alexa, (ya sea un altavoz inteligente Amazon Echo o un horno debidamente equipado), actúa como el cliente o frontend de la Skill, y donde el backend se ejecuta en su propio servidor o en AWS Lambda, un servicio de procesamiento de datos desarrollado por Amazon basado en arquitectura serverless ofrecido por AWS (Amazon Web Services).
Puedes desarrollar tus propias Skills de Alexa haciendo uso del Alexa Skills Kit y el AWS Lambda.
Las Skills de Alexa se desarrollan utilizando el Alexa Skills Kit (ASK), disponible gratuitamente una vez hayas creado tu cuenta de desarrolladores de Amazon.
El Alexa Skills Kit (ASK) es una colección de APIs, herramientas, documentación y ejemplos de código que te permite crear tus Skills de Alexa.
Por otro lado, si no deseas encargarte de alojar tú mismo la lógica del programa de tu Skill de Alexa en tu propio servidor, necesitarás una cuenta AWS que te proporcione acceso al servicio en la nube de AWS Lambda.
Después de estos conceptos pasa a segunda parte del artículo para realizar los 6 pasos que nos permitirán tener disponible nuestra Skill:
Actualidad
10/12/2020
La mayoría de los programadores que han utilizado la práctica de desarrollo de software TDD (Rojo/Verde/Refactorización) en su ciclo de trabajo, deben estar ya acostumbrados a introducir pequeños cambios en el código en cada una de sus fases, y principalmente deben conocer los cambios asociados a las refactorizaciones que realizamos durante la última fase de TDD.
La refactorización, tal como fue definida por Martin Fowler en su libro Refactoring: Improving the Design of Existing Code (1999), “es el proceso de cambiar un sistema de software, de forma tal que no se altere el comportamiento externo del mismo pero que se mejore su estructura interna. Con el objetivo de hacerlo más sencillo de entender y barato de mantener, permitiendo que el diseño del programa mejore luego de haber sido escrito”.
Al igual que con la fase de Refactorización, durante la fase Verde también se realizan alteraciones en el código, mediante las cuales intentamos hacer que el software supere la prueba que se encuentra fallando, empleando el menor cambio posible. A estas operaciones Robert C. Martin (tío Bob) las denominó transformaciones.
Podemos pensar en estas transformaciones como la contraparte de las refactorizaciones, debido a que consisten en pequeñas variaciones en el código que permiten modificar el comportamiento externo del software pero que conservan significativamente su estructura interna. Dicho en otras palabras, las transformaciones generalizan el comportamiento del sistema sin cambiar su estructura.
Pensando en estas transformaciones, el tío Bob definió la “Premisa de Prioridad de Transformación” (sus siglas TPP del inglés Transformation Priority Premise) la cual afirma que las transformaciones poseen un orden inherente fundamental, y que al ser aplicadas en correcto orden se conduce a mejores algoritmos y se evitan interrupciones del ciclo de TDD.
Él describe esta premisa en algunas de sus charlas mediante un ejemplo de desarrollo de un algoritmo de ordenamiento, y hace notar que al violar dicho orden se conduce a un algoritmo de ordenamiento de burbuja, mientras que empleando un orden preestablecido se alcanza un algoritmo de ordenamiento rápido, el cual es mucho más eficiente que el anterior.
Basándose en sus experiencias y evaluando publicaciones de otras personas, el tío Bob llegó a la siguiente lista ordenada de transformaciones:
| 01 | {}–>null | De no tener código alguno a código que retorna Null |
| 02 | null->constant | De código que retorna Null a devolver un valor literal simple |
| 03 | constant->constant+ | De un valor literal simple a un valor literal complejo |
| 04 | constant->scalar | De un valor literal a una variable |
| 05 | statement->statements | Agregar más sentencias |
| 06 | unconditional->if | Dividir el flujo de ejecución mediante condicionales |
| 07 | scalar->array | De una variable a una colección |
| 08 | array->container | De una colección a un contenedor |
| 09 | statement->tail-recursion | De una sentencia a recursión de cola |
| 10 | if->while | De un condicional a un bucle while |
| 11 | statement->non-tail-recursion | De una sentencia a una iteración |
| 12 | expression->function | De una expresión a una función |
| 13 | variable->assignment | Reemplazar el valor de una variable |
| 14 | case/else | Añadir una bifurcación a un condicional existente |
Este listado sugiere un grado de complejidad incremental en nuestras transformaciones a medida que avanzamos en él, de forma que es más sencillo cambiar una constante a una variable que el añadir una sentencia condicional. Debido a esto, se sustenta la idea de dar prioridad en su uso a las transformaciones más simples por encima de aquellas más complejas.
Como una guía para nuestro uso durante el ciclo de TDD se puede representar dicho listado con el siguiente diagrama:
Para propiciar el uso de las transformaciones más simples, cuando diseñamos una prueba, primero debemos pensar en desarrollar aquellos casos de uso que nos permitan emplear transformaciones más simples en vez de las transformaciones más complejas. Debido a que a mayor complejidad de la prueba, mayor será el riesgo que tomemos para lograr hacer que nuestra prueba pase.
Encontrarnos en una situación donde no sabemos cómo hacer que una prueba pase, es un problema que muchos hemos observado mientras realizamos TDD. Algunas veces, la causa de este tipo de impasses recae en nuestro proceso de toma de decisiones durante el ciclo de desarrollo de TDD.
La transformación más simple suele ser la mejor opción que incurrirá en el menor riesgo para crear una situación de bloqueo. Debido a que mientras mayor sea el cambio en el código, más tiempo nos tomará antes de que nuestra prueba vuelva a pasar, por lo que se produce un riesgo mayor de romper el ciclo de TDD.
Por todo lo antes expuesto, el tío Bob plantea como premisa que si se eligen las pruebas e implementaciones que empleen transformaciones que están más arriba en la lista, se podrán evitar las situaciones de impasse o interrupciones prolongadas en el ciclo rojo / verde / refactorización.
Podemos practicar y dominar estos conceptos aplicando esta premisa de la prioridad de las transformaciones en un problema conocido como lo es la kata de los números primos.
El objetivo de esta kata es determinar el listado de factores primos un número. Un número primo sólo puede ser dividido exactamente por sí mismo y por 1.
A continuación, realizaremos la kata de los factores primos:
1. Añadimos un Test Fallido para 1 (Caso más simple)
Nos detenemos al fallar la compilación de la prueba
1.1 Transformando para Compilar
La forma más fácil de tener éxito (compilar ahora) es crear un método con valor de retorno nulo. Esta es la primera transformación o transformación nula ({} -> null).
1.1 Transformando para Pasar el Test
Esta prueba falla porque el método primeFactorsOf devuelve null, y no una lista vacía. Para que esta prueba sea exitosa, transformaremos el valor nulo en una lista vacía.
Nuestra segunda transformación es null -> constant.
¿Acaso null no es una constante? Null también es una constante, pero Null es una constante muy especial. Es una constante sin tipo definido y sin valor. Por lo tanto, es diferente de una constante que tiene un tipo y un valor.
La transformación realizada con null -> constant hace que el código sea más general. Null es un caso muy especial, inmutable, pero una lista vacía tiene el potencial de ser general. Ser general significa que puede manejar una variedad más amplia de casos.
2. Añadimos un Test Fallido para 2
Como segunda prueba, agregamos:
assertThat(primeFactorsOf(2), is(Arrays.asList(2)));
Con lo que esta nueva prueba fallará.
2.1 Transformación – Constante a Variable
Para que esta prueba sea exitosa, generalizamos la constante new ArrayList()
Para hacer esto, transformamos la constante en una variable llamada factors. La tercera transformación es constant -> variable.
Lo que hemos hecho es una refactorización (extracción de una variable), con la cual no hemos cambiado el comportamiento en un sentido estricto. Debido a que reemplazar una constante por una variable con su valor original no altera el comportamiento del sistema. Sin embargo, nos abre la posibilidad de poder cambiar ese comportamiento. En otras palabras, cambiar una constante por una variable no es una transformación independiente, pero es una parte necesaria del proceso de transformación.
2.2 Transformación – Flujo Dividido
Una transformación que modifica una constante en una variable permite que realicemos una cuarta transformación llamada división de flujo. En la transformación de flujo dividido, una sentencia if es empleada para dividir el flujo de control del programa. Esta transformación fue habilitada por la transformación anterior. La sentencia if hizo de nuestro código algo más específico. Por lo que nos toca ahora generalizarlo.
2.2 Refactorización – Generalizando
La condición if(number == 2) fue un caso muy específico (coincidiendo con la intención de la prueba). Debemos refactorizar para manejar casos más generales.
if(number > 1) es más general debido a que está abierto a posibilidades.
3. Añadimos un Test Fallido para 3
Al incluir la tercera prueba assertThat(primeFactorsOf(3), isListOf(3)); dicha prueba fallará.
3.1 Transformación – Constante a Variable
Para lograr hacer pasar la prueba con la transformación más simple, aplicamos la transformación constant -> variable en la cual modificaremos el 2 que añadimos a la lista de factores por la variable de entrada number.
4. Añadimos un Test Fallido para 4
Para la cuarta prueba incluimos la siguiente sentencia:
assertThat(primeFactorsOf(4), is(Arrays.asList(2,2)));
4.1 Transformación – Flujo Dividido
De forma que logremos pasar esta prueba, debemos volver a hacer una división en el flujo, dependiendo si la entrada number es divisible por 2.
4.2 Transformación – Flujo Dividido Nuevamente
Aún con este cambio, otra de nuestras pruebas continúa fallando. Esto se debe a que el caso de los factores primos de 4 es exitoso, pero el caso de los factores primos de 2 debe incluir a un solo valor y no dos. Por lo que tendremos que dividir el flujo nuevamente para evitarlo.
Y con esto podremos pasar todas las pruebas.
4.3 Refactorización
En el caso de number > 1, la división es realizada dos veces. No debemos preocuparnos de ello en este momento debido a que pronto desaparecerá. No generamos ningún inconveniente si movemos la parte del segundo condicional number > 1 fuera de la primera cláusula condicional.
4.4 Refactorización
Al igual que con el código productivo, el código que compone nuestras pruebas también debe ser mantenido. Por lo que podemos refactorizar para mejorar su legibilidad al eliminar duplicación en el código.
5. Añadimos más pruebas
En los casos de 5, 6 y 7, estas pruebas funcionan correctamente si son incluidas debido a que su comportamiento se encuentra incluido en nuestro algoritmo.
6. Añadimos prueba fallida para el 8
assertThat(primeFactorsOf(8), isListOf(2, 2, 2));
La cual falla.
6.1 Transformación – If a While
Podemos aplicar la transformación If -> while de forma que pasemos la nueva prueba.
El bucle while es simplemente una forma generalizada del condicional if, por lo que if es una forma especial de la estructura while.
6.2 Refactorización
Se mejora la legibilidad del código al refactorizar el bucle while a un bucle for como se muestra a continuación.
7. Añadimos un Test Fallido para 9
Añadimos la prueba assertThat(primeFactorsOf(9), isListOf(3, 3));
7.1 Hacemos pasar con Duplicación
Añadimos la condición de división por 3 como se muestra a continuación para hacer que nuestra prueba pase.
7.2 Transformación para remover la duplicidad – Bucle más general
Hemos introducido una duplicidad en nuestro código. Podemos incurrir en estas mientras estemos trabajando en un ciclo de TDD, pero las mismas no deben registrarse en el repositorio de origen como código repetido. Esta redundancia no es una transformación, debido a que nada ha sido generalizado. Simplemente es un experimento que nos permite imaginar como debe ser la solución general.
Nuestra tarea ahora es aplicar un ciclo más generalizado para eliminar la duplicación. El código duplicado siempre es inusual y específico.
7.3 Refactorización
Mejoramos nuevamente la legibilidad al refactorizar el bucle while por un bucle for y eliminamos el condicional restante, para obtener el resultado final compuesto por dos bucles for fáciles de entender.
Las siguientes transformaciones fueron observadas en este ejercicio de ejemplo:
Pudimos ver mediante la kata de ejemplo una ilustración del proceso descrito por el tío Bob, y ver que al aplicar las transformaciones que propone TPP conseguimos garantizar:
La Premisa de la Prioridad de Transformación (TPP) es una de las herramientas con las que contamos para garantizar el cumplimiento de las reglas del desarrollo guiado por tests. Este listado de transformaciones no implica reglas inalterables, sino una guía para evitar los bloqueos en el ciclo de TDD, especialmente al hacer el cambio de rojo a verde.
Si te interesa conocer más sobre TPP puedes buscar el siguiente material:
Actualidad
26/10/2020
Hace unas semanas mi compañero Gustavo Caro hacía un repaso de cómo han ido evolucionando las arquitecturas de aplicaciones y en este artículo voy a intentar resolver algunas dudas que surgen cuando nos enfrentamos a arquitecturas orientadas a eventos.
Las arquitecturas orientadas a eventos han crecido en popularidad en los últimos años, y aunque no son un concepto nuevo ya que existen referencias a la programación dirigida por eventos que se remontan a los 70s, sí que están ganando importancia debido a las últimas tendencias en ingeniería del software.
Empecemos por el principio, una arquitectura orientada a eventos (EDA del inglés Event-Driven Architecture) es un patrón distribuido de arquitectura donde diferentes actores se comunican mediante eventos en base a roles: productores y consumidores.
Utilizando este tipo de arquitecturas, las empresas implementan sistemas flexibles que se pueden adaptar a toma decisiones y cambios en tiempo real. Los eventos se capturan a medida que ocurren y permite que productores y consumidores de eventos compartan información sobre el estado y la respuesta en tiempo real.
Los componentes en este tipo de arquitectura están altamente desacoplados lo que facilita escalar horizontalmente. También hay que remarcar el hecho de que añadir nuevos consumidores es sencillo, ya que las integraciones no son punto a punto. En la parte negativa está el hecho de que, debido a la propia naturaleza desacoplada de la arquitectura, hay que ser cuidadoso con los componentes que formen parte y las dependencias entre ellos.
Existen múltiples conceptos alrededor de este tipo de arquitecturas que a simple vista pueden parecer similares, pero te das cuenta de que no lo son cuando indagas un poco más: eventos de dominio, Event Sourcing, CQRS…
En este artículo voy a intentar aclarar las diferencias entre esos conceptos. ¡Empecemos!
En DDD (del inglés Domain-Driven Design), los eventos de dominio se usan para describir hechos de negocio que ocurren dentro del dominio. Estos eventos son relevantes dentro del bounded context pero también para otros bounded context, permitiendo integración entre diferentes dominios.
Una importante característica de estos eventos es que deben contener un alto valor semántico expresado en el lenguaje que hablen los expertos de dominio.
Si quieres profundizar en DDD te recomiendo el siguiente artículo.
Event Sourcing hace referencia a sistemas donde el estado de la aplicación completa es almacenado como una secuencia de eventos. Aquí, el termino evento se refiere al “cambio de estado”, no es solamente una “notificación”.
Las aplicaciones persisten los eventos en un Event Store, que es una base de datos de eventos. En lugar de almacenar el estado actual de la aplicación directamente campos de una tabla en la base de datos, los eventos son almacenados cronológicamente y pueden ser usados para reconstruir el estado actual en memoria si fuera necesario.
Como ya nos decía Martin Fowler en un post original del año 2005: “Event Sourcing ensures that all changes to application state are stored as a sequence of events”
Command Query Responsability Segregation (CQRS) es un patrón por el cual se tienen estructuras de datos separadas para leer y escribir información. CQRS no tiene que ver estrictamente con eventos, ya que se puede implementar sin hacer uso de ellos, pero es bastante común que se combine CQRS con Event Sourcing.
CQRS Diagram by Martin Fowler
La justificación de usar CQRS es que, en dominios complejos, un modelo único de lectura y escritura puede resultar muy complicado y se puede simplificar separando los modelos. Este hecho puede resultar determinante si los patrones de accesos difieren de manera considerable, como por ejemplo muchas lecturas y muy pocas escrituras.
Como hemos revisado en este artículo , las arquitecturas orientadas a eventos ofrecen numerosas ventajas, pero en contrapartida los patrones a seguir son algo más complejos que en otras arquitecturas y por tanto hay que pensar bien cuándo conviene hacer uso.
Una herramienta que nos puede ser de gran ayuda en este tipo de arquitecturas es un catálogo de eventos. A medida que la aplicación crece y el número de componentes es mayor, el flujo entre los componentes se hace más difícil de seguir, así como sus interacciones. En este punto es donde un catálogo de eventos cobra importancia.
En relación al tipo de eventos (domino / event sourcing), es importante tener una idea clara del propósito y semántica que cada uno lleva, y aunque no son exclusivos y en algún punto pueden tener la misma información, es una buena practica mantenerlos separados.
En general este tipo de arquitectura puede resultar muy útil y aunque quizás sea complicado implementarlo en un sistema completo, sí que su uso en partes específicas del sistema puede ofrecernos la flexibilidad y desacoplamiento que podemos necesitar.
Actualidad
04/08/2020
La evolución de las aplicaciones siempre ha estado estrechamente relacionada con la evolución tecnológica y las necesidades de los usuarios y las empresas.
Del mismo modo que las organizaciones empresariales evolucionan en la forma de hacer las cosas, las aplicaciones informáticas deben seguir el mismo camino para lograr su único objetivo, satisfacer dichas necesidades y servir al usuario de la forma más eficiente. Es como un ciclo que se retroalimenta constantemente:
Esta evolución ha obligado a un cambio en los sistemas, adaptando las infraestructuras que ofrecen la disponibilidad de dichos servicios y aplicaciones, de tal forma que los usuarios que los consumen lo puedan hacer de una forma más eficiente, segura y además en remoto, es decir, disponible en internet.
Un ejemplo sencillo para mostrar que adaptarse en esta evolución es obligatorio, sería una aplicación de mensajería que tiene un éxito inesperado. Es cierto que el aumento de demanda no es sino el principio del éxito, pero también puede ser el principio del fracaso si la infraestructura que soporta dicha aplicación de mensajería no está preparada para soportar tanta demanda. En este caso, la aplicación está condenada al fracaso.
La característica principal de estas aplicaciones es que hacen uso de una base de código única para sus servicios y funcionalidades. Es decir, la aplicación es «responsable» de todas las tareas necesarias para realizar una determinada función.
Este tipo de aplicaciones se destacan por combinar la interfaz del usuario y la capa de acceso a los datos en el mismo programa y alojarlos en la misma máquina (o nodo).
Una de las características para tener en cuenta es el llamado escalado vertical. Si el servidor que aloja la aplicación recibe un aumento en las peticiones de usuario, es posible que los recursos existentes en la máquina sean insuficientes. La única posibilidad es aumentar los recursos en dicha máquina (RAM, espacio en disco, etc.) dentro de sus límites.
Goza de una arquitectura sencilla, puesto que toda la aplicación se aloja en el mismo nodo, donde las comunicaciones entre las distintas partes de la aplicación siempre son de forma local.
Debido a su arquitectura, las interferencias entre los componentes de la aplicación son más delicadas, y un fallo en una de sus partes puede poner en evidencia toda la aplicación.
Otra desventaja, la tenemos en la complejidad de las actualizaciones, que pueden afectar a la disponibilidad de todo el sistema durante un período de tiempo durante su despliegue.
Por el simple hecho de tener una infraestructura estática y fija por años, el mantenimiento es más costoso y es más difícil evolucionar de forma eficiente a las nuevas necesidades del mercado.
En definitiva, aunque son fáciles de desarrollar, una aplicación que aglutina toda su funcionalidad no es la mejor opción si queremos aspiraciones crecimiento complejas, más usuarios, más desarrolladores, etc.
Su principal cometido es tener la aplicación disgregada en múltiples nodos, dando la posibilidad de que en cada nodo exista un componente de la aplicación o un mismo componente replicado en varios nodos.
Esta arquitectura es bastante más compleja y difícil de gestionar y administrar que una aplicación monolítica. De hecho, se deben utilizar numerosas herramientas que antes no eran en absoluto necesarias. Pero esta idea de tener la aplicación distribuida en varios nodos fue un punto de inflexión, que dio lugar a conceptos muy importantes y ha favorecido de forma incuestionable la existencia de aplicaciones mucho más robustas, escalables, eficientes y seguras.
Uno de los grandes conceptos que introduce este tipo de aplicaciones es el escalado horizontal. Es decir, cuando por cuestiones de demanda los recursos actuales ya no son suficientes, en vez de aumentar los recursos de un nodo (escalado vertical), lo que se hace es incrementar el número de nodos dedicados al procesamiento de ese componente demandado. Esto es una gran ventaja ya que el límite de recursos ya no será el soportado por un nodo, sino el soportado por tantos nodos como tengamos en nuestra arquitectura.
Otro gran concepto que surge, aunque todavía no de forma automática y madura, es la llamada elasticidad. Es decir, al igual que se aumentan el número de nodos dedicados para soportar un aumento de demanda, se pueden reducir si la demanda disminuye y dejarlos disponibles para otros procesos. Este concepto contribuye a un reparto de recursos más eficiente.
La seguridad y la robustez mejoran notablemente, ya que es más probable que los problemas de seguridad de un nodo sean cercados en ese nodo, no poniendo en riesgo toda la aplicación si alguno de ellos se pone en evidencia.
Otra gran ventaja con respecto a las aplicaciones monolíticas es que las actualizaciones no conllevan desplegar toda la aplicación ya que, en este caso el despliegue será a nivel de nodo. El mantenimiento es mucho más fácil y la durabilidad de la aplicación será mayor por la facilidad de adaptación a los cambios.
Todas estas características hacen que las aplicaciones distribuidas sean ideales cuando adecuar los recursos que se deben utilizar en función de la demanda sea clave.
Esta arquitectura fue la que insistió en la utilización de aplicaciones distribuidas y orientadas a servicios.
La idea fue hacer que esos servicios fueran independientes, y las interacciones entre ellos se hicieran bajo ciertos protocolos estandarizados de comunicación, como WSDL y SOAP.
Esta independencia hacía posible que servicios desarrollados por diferentes tecnologías, pudiesen comunicarse entre sí, sin ningún problema.
Debido a que los servicios son más independientes, cambios en ciertos componentes de la aplicación no alteraban al resto, simplemente debían seguir cumpliendo los criterios de comunicación establecidos.
La arquitectura SOA está más enfocada a la arquitectura de la aplicación. Cloud Native se enfoca más en la arquitectura del sistema que alberga, distribuye y ofrece las aplicaciones.
Este punto de vista, lo que ofrece es básicamente el uso de recursos en la nube bajo demanda automatizada. Es decir, va a existir una elasticidad gestionada de forma automática por el sistema en la infraestructura dedicada a cada una de las aplicaciones que distribuyen. Consiguiendo que el uso de los recursos sea lo más eficiente posible.
Estas infraestructuras dinámicas dedicadas hacen posible que las aplicaciones sean resilientes antes situaciones adversas, por ejemplo, por demanda extrema, errores hardware, etc.
No existe una definición formal pero básicamente es una evolución de SOA y está orientada al trabajo con servicios muy pequeños e independientes.
El objetivo es aislar los distintos componentes de una aplicación con el fin de que cada uno sea una aplicación por sí misma.
Otra de las diferencias con SOA es la comunicación entre los servicios; Ya no sería con servicios web WSDL o SOAP, sino vía HTTP con API-REST.
Muchos beneficios suelen asociarse a los Microservicios, pero tres de los más importantes son: una entrega más rápida, escalabilidad mejorada y una mayor autonomía.
Los microservicios son el facilitador de una mayor agilidad en términos de adaptación a los cambios del mercado. Su filosofía es compatible y está directamente relacionada con procesos ágiles de desarrollo: entrega continua. Es decir, el mantenimiento de la aplicación conlleva modificaciones en los microservicios, pudiendo llevar a cabo muchas subidas a producción en un corto período de tiempo de forma independiente (continuous delivery, deployment, improvement).
Esto aumenta la agilidad del software porque cada microservicio se convierte en una unidad independiente de desarrollo, implementación, operaciones, versiones, y escalamiento.
En realidad, aquí el término escalabilidad es algo ambiguo. Podría referirse, por ejemplo, a la escalabilidad del tiempo de ejecución del sistema, a su adaptabilidad (a un costo razonable), o a los cambios en el número de usuarios que acceden a él. O también podría referirse a poder aumentar el número de microservicios sin interferencias con los otros o a la capacidad del proceso de desarrollo para acomodar a muchos desarrolladores trabajando en paralelo.
Lo que está claro es que, con los microservicios la unidad a escalar es el servicio. Por tanto, cada uno de ellos son una unidad autónoma que pueden ser desarrollados, desplegados y operados por un equipo diferente. Por eso, suelen implementarse sobre contenedores: un microservicio en un nodo.
En estos casos, es de máxima importancia sincronizar una responsabilidad compartida entre el desarrollador y el sistema que lo alberga. Esta es la base de la filosofía DevOps.
La antigua filosofía introducida hace décadas por el principio «Divide y vencerás» ha sido puesta en práctica en innumerables ocasiones: en los algoritmos informáticos, en el envío de pequeños paquetes de datos en el protocolo IP, en la agrupación de las tareas en 7 capas en la arquitectura de red OSI, etc.
Es curioso como la misma filosofía se sigue adoptando en las infraestructuras tecnológicas actuales. Divide and win my friend 🙂
Nota. Los diagramas de las arquitecturas monolítica y de microservicios pertenecen al blog de Chris Richardson. Te animo a que lo visites para leer sus interesantes artículos.
Actualidad
08/07/2020
PowerShell es la línea de comandos ubicua de Microsoft. Con los años, este lenguaje lanzado en 2006 se ha convertido en mi principal herramienta para moverme por el “Universo Microsoft”.
Todo lo puede, para todo sirve y siempre está a mano, como el destornillador del Doctor Who. Y aunque es cierto que en los últimos tiempos Microsoft ha abierto el abanico a otras líneas de comandos, como Azure CLI (AZ) para Azure o Bash para Azure y WSL, PowerShell aún sigue teniendo una posición muy sólida en el ecosistema, e incluso mejor desde el lanzamiento en 2016 de la versión multiplataforma (Mac OS, Linux): PowerShell Core.
Pero vayamos al grano. Puede que tu día a día sea una sucesión de scripts, probablemente rápidos, pero ¿qué pasa cuando son largos? ¿Qué haces si tienes que esperar a completar una o varias tareas que pueden llevar 10, 20 o 60 minutos?
Para estos casos, he depurado estrategias de notificación para ignorar el script hasta que algo relevante suceda. Esto es particularmente útil cuando tienes varios scripts pendientes, u otros proyectos, o una video llamada en curso. 😉
Las comparto en este artículo, sin un orden en particular, para que puedes aprovecharlas en tu día a día, por utilidad, o por mera diversión: 3 estrategias de notificación y 1 sorpresa.
En PowerShell puedes implementar avisos sonoros como los de las videoconsolas de 8 bits de los años 80. Así identificas de oído si tu script ha llegado a alguna etapa importante.
Es como un Write-Host sónico. Además, la implementación es super sencilla:
[console]::beep(500,300)El ejemplo muestra cómo reproducir un sonido de 500 hertzios y 300 milisegundos. Más hertzios, más agudo. Más milisegundos, más duración.
Fun Fact: ¿Sabías que 440 hertzios es la frecuencia que se emplea como sonido de referencia para afinar de instrumentos como el piano o el violín? ¡Puedes afinar tu guitarra o violín usando cualquier PC con Windows!
Por supuesto puedes jugar con las duraciones y frecuencias (aunque no del todo con el ritmo) para formar diferentes «códigos» o incluso melodías famosas. Por ejemplo:
Star Wars – Imperial March, de John Williams
[console]::beep(440,500)
[console]::beep(440,500)
[console]::beep(440,500)
[console]::beep(349,350)
[console]::beep(523,150)
[console]::beep(440,500)
[console]::beep(349,350)
[console]::beep(523,150)
[console]::beep(440,1000)
[console]::beep(659,500)
[console]::beep(659,500)
[console]::beep(659,500)
[console]::beep(698,350)
[console]::beep(523,150)
[console]::beep(415,500)
[console]::beep(349,350)
[console]::beep(523,150)
[console]::beep(440,1000)Visto en: Music from the Command Line:Performed by Powershell
Los Vengadores – Assemble, de Alan Silvestri
[console]::beep(440,1800) [console]::beep(440,200) [console]::beep(440,600) [console]::beep(660,100) [console]::beep(580,1200) [console]::beep(520,800) [console]::beep(490,800) [console]::beep(440,1200)[Nota: Melodía sacada de oído por mí]
Los veteranos del software como yo, recordareis la película «Juegos de Guerra» protagonizada por Matthew Broderick. En ella una IA llamada WOPR trataba de iniciar una guerra termonuclear por culpa de una red mal segmentada y un hacker. Hay muchas lecciones sobre ciberseguridad e IA en esa película.
Una de las cosas que recuerdo es la voz de la WOPR. Pero desde hace décadas, con el API de voz de Windows (si lo tienes configurado) puedes tener algo parecido en tus scripts usando estos comandos:
$text = "Extraño juego, la única manera de ganar es no jugar."
$object = New-Object -ComObject SAPI.SpVoice
$object.Speak($text) | Out-Null[Referencia friki obligada: https://www.youtube.com/watch?v=FboBAFiLDbI]
Por supuesto puedes jugar con bastantes parámetros como la velocidad, otras voces e idiomas. Pero eso añade complejidad al script.
En resumen, puedes emitir información compleja y descriptiva de lo que va sucediendo durante la ejecución de tus scripts sin tener que prestarle atención. O leer archivos de texto de forma automática. O gastar bromas.
Este API tiene muchas posibilidades y PowerShell lo pone fácil. ¿Podrá integrarse con Alexa o Siri?
En Windows 10 hay dos formas típicas de notificar algo al usuario: mediante un cuadro de diálogo y mediante el centro de notificaciones.
Para lanzar un molesto, pero efectivo cuadro de diálogo, no tenemos más que poner:
Add-Type -AssemblyName PresentationFramework #Ensamblado para la sesión.
[System.Windows.MessageBox]::Show('CPE1704TKS ?')Esto nos permite explorar nuevas opciones de control de nuestros scripts, como por ejemplo recibir una notificación sobre si continuar una acción, o no, en lugar de solamente notificar algo.
Para ello tenemos una amplia gama de opciones de MessageBox como:
$msgBoxInput = [System.Windows.MessageBox]::Show('¿Una partidita de ajedrez?','WOPR','YesNoCancel','Error')
Write-host "Profesor Falken dijo:"$msgBoxInputPero también podemos emplear elementos de consola más avanzados como el Out-GridView con la opción -PassThru:
$myList = @("Tic, tac, toe","Chess","Global thermonuclear war")
$selection = $myList | Out-GridView -Title "Select a game" -PassThru
Write-host "Lets play:"$selectionPor último, en Windows tenemos algo más moderno y algo menos intrusivo como el centro de notificaciones, que funciona como el de un móvil y que no interrumpirá nuestro flujo de trabajo o reunión en curso. Aunque parece una buena opción, la generación de notificaciones es bastante más compleja y requiere de procesos adicionales para no acabar llenando de basura la barra de tareas.
Add-Type -AssemblyName System.Windows.Forms #Ensamblado para la sesión.
$global:balloon = New-Object System.Windows.Forms.NotifyIcon
$path = (Get-Process -id $pid).Path
$balloon.Icon = [System.Drawing.Icon]::ExtractAssociatedIcon($path)
$balloon.BalloonTipIcon = [System.Windows.Forms.ToolTipIcon]::Info
$balloon.BalloonTipTitle = "General Kenobi says..."
$balloon.BalloonTipText = 'Hello there!'
$balloon.Visible = $true
$balloon.ShowBalloonTip(5000)Resumiendo, Windows y PowerShell nos ofrecen muchas opciones para gestionar notificaciones nativas, con relativa facilidad.
Como hemos podido comprobar, los scripts largos no tienen por qué ser aburridos, ni consumir tu atención y tu valioso tiempo. Basta con echarle algo de imaginación y emplear la vasta lista de posibilidades que ofrece PowerShell para facilitar nuestro trabajo.
Por mucho hype que haya con C#, JavaScript o Go, a menudo PowerShell puede ser la solución más rápida, compatible y con mejor TCO, para resolver problemas o automatizar procesos.
Y hasta aquí este artículo. Me despido con un meme en PowerShell: Never gonna give you up, de Rick Ashley.
Que por supuesto puedes incluir en tus scripts. Pero ojo con el volumen del audio al ejecutar esto:
iex (New-Object Net.WebClient).DownloadString("http://bit.ly/e0Mw9w")