Tecnologías Web 102

Back y SPAs.

En el anterior post, Tecnologías Web 101, comenté como surgieron los principales lenguajes usados en la web (HTML, CSS y JS) además de como empezaron a aparecer algunas herramientas que nos permitían generar las vistas desde la parte del servidor con algunos lenguajes como PHP o Java.

Durante este segundo post contaremos algunas herramientas centradas en crear aplicaciones de una forma más rápida, además de que empiezan a salir los primeros frameworks del frontend.

Frameworks del Back

En 2004 aparece Ruby on Rails, un framework MVC que nos permite crear aplicaciones web (con Ruby) de una forma muy rápida, creado por David Heinemeier (más conocido en las RSS como DHH). David lo crea pensando en dos principios:

• No te repitas (DRY).
• Convención sobre configuración (CoC).

De esta forma, surge una herramienta que nos va a permitir crear aplicaciones de forma muy rápida sin tener que repetir todos los pasos que normalmente hay que seguir a la hora crear y configurar todas las partes de un proyecto. Al lanzar un comando se generará toda la estructura de carpetas, se configurará un sistema de plantillas para generar las páginas HTML que se enviarán al cliente, un ORM que nos hará mucho más fácil la interacción con la BBDD... Además, hace que configurar cualquier parte sea muy sencillo siempre que sigamos las convenciones establecidas.

Y estas razones son por las que las Startups comienzan a usarlo para crear sus MVPs, ya que en poco tiempo pueden tener una parte de la aplicación funcionando para poder validar la idea y si no es el caso poder pivotar antes de seguir perdiendo el tiempo.

Más adelante, en 2005 empezarán a aparecer frameworks similares a este construidos para distintos lenguajes, como Django para Pyhon o Symfony para PHP.

Este fue un año importante para JavaScript, puesto que Jesse James Garret publica un libro en el que menciona el termino AJAX (Asynchronous JavaScript And XML), que lo describe como un conjunto de tecnologías que van a permitir cargar los datos del servidor y actualizar la página con estos datos sin necesidad de recargarla, obteniendo aplicaciones mucho más dinámicas.

El JavaScript contraataca

Al siguiente año, en 2006, hay dos tecnologías que van a ayudar a los desarrolladores en gran medida a hacer las aplicaciones web.

John Resig decide crear la librería jQuery ante la dificultad que le suponía trabajar con JavaScript y que este funcionara en los distintos navegadores. Esta librería ha terminado siendo una de las más utilizadas dentro del ecosistema de JavaScript.

Esto se debe a que todas aquellas tareas repetitivas a la hora de trabajar con el DOM quedaban de una forma mucho más simple, pues tiene métodos que nos proporcionan una forma sencilla de buscar los elementos del DOM que necesitamos modificar, manipular el código CSS, añadir listeners a los eventos, incluso trabajar con AJAX más fácilmente que usando el código JS nativo, y haciendo que fuera compatible entre los distintos navegadores.

Por otro lado, ese mismo año, Hampton Catlin publicó Sass, uno de los preprocesadores más importantes y usados de la historia y que se sigue usando actualmente. Con Sass se consigue que escribir CSS sea como si lo estuviéramos programándolo, ya que nos permite usar variables, funciones, anidar reglas de CSS, usar bucles y condicionales... Todo ello va a hacer que podamos reutilizar lo máximo posible partes de los estilos y dejar el código mucho más legible.

Sass nos permitía usar dos tipos de sintaxis:

• sass: no se utilizan llaves, dos puntos y, puntos y comas. Los bloques empiezan y terminan según la identación del código, al igual que ocurre con Python.
• scss: se utilizan llaves, dos puntos y, puntos y comas.

Pero los navegadores no entienden el código escrito con Sass, por lo tanto antes de importar estos estilos en nuestras aplicaciones, hay que convertirlo a CSS.

Durante los siguientes años se publican los otros dos preprocesadores más utilizados, LESS y Stylus que nos permiten hacer casi lo mismo que Sass, solo que cambiando la sintaxis a utilizar.

En el 2009 hay un gran avance en el ecosistema de JavaScript, y es que Ryan Dahl crea NodeJS, un entorno de programación JS en el lado del servidor. Ahora ya sería posible usar un solo lenguaje para crear una aplicación web entera, tanto el frontend como el backend. Esto hace que muchas empresas tengan en cuenta JavaScript como lenguaje a la hora de desarrollar sus proyectos, puesto que los equipos de desarrollo se pueden centrar en aprender bien un único lenguaje en lugar de tener que aprender varios como ocurría hasta ahora.

El ascenso de las SPAs

Ya por estos años la gente empezaba a consumir información de internet a través de los smartphones y por tanto durante el desarrollo de las web vamos a tener que tener en cuenta el tamaño de estos dispositivos además de otras características como que las web no deberían de ser muy pesadas ya que podrían terminar por gastarles los datos a los usuarios, algo que no gustaría a nadie.

Y en el 2010 se empiezan a poner de moda las Single Page Applications o SPAs al salir dos frameworks de JavaScript para crearlas, Backbone (creada por Jeremy Ashkenas) y AngularJS (de Google). Estos dos frameworks implementan el patrón MVC en el cliente, uno de los patrones más usados a la hora de desarrollar la parte del backend de las aplicaciones.

La principal ventaja de las SPAs que van a influir a la hora de crear algunos de los frameworks y librerías que van a salir más tarde, es que la primera carga es algo más lenta porque se descargan toda la aplicación, pero el resto de interacciones con la app van a ser más rápidas ya que no tiene que descargarse distintas páginas del servidor. Mientras que el principal problema de las SPAs es el SEO, porque estas aplicaciones no se renderizan en el servidor sino que lo hacen en el cliente.

AngularJS introduce algunas novedades que también van a copiar algún que otro framework en el futuro, entre ellas la del Two-Way Data Binding que permite sincronizar los datos del modelo y de la vista. Otra de las novedades son las directivas que permiten modificar la funcionalidad o apariencia de aquellas etiquetas a las que se les añaden, por ejemplo permitiendo iterar una lista de elementos y creando una plantilla por cada uno de ellos.

Y la cosa no queda aquí, este mismo año también se publican dos frameworks para desarrollar aplicaciones web y APIs influenciados por Sinatra de Ruby cuya primera versión se publicó en 2007. Estos dos frameworks son ExpressJS y Flask (para Python) con los que podemos definir los endpoints a los que hacer las peticiones y la respuesta que tenemos que devolver.

Y es aquí donde aparece el famoso Mean Stack para desarrollar aplicaciones web donde las tecnologías que lo forman son MongoDB como BBDD, ExpressJS como framework para el servidor, AngularJS para el frontend y NodeJS como entorno de ejecución de JavaScript para el servidor.

Y con este stack que tantas empresas han adoptado para sus desarrollos, terminamos el post de hoy. No os perdáis el siguiente, Tecnologías Web 103.

Tecnologías Web 101

Los Inicios

Hoy os vengo a presentar el primero de una serie de seis posts en los que iremos viendo como ha ido evolucionando el desarrollo web en función de algunos factores clave como la llegada de los smartphones. En este primero os dejo además alguna reflexión y vamos a ir viendo como empezó todo.

LitElement, React, Flutter, Vue, Ionic, Angular, React Native... seguro que alguno de estos nombres nos suenan, o puede que nos suene algún otro que no he escrito en la lista. Da igual, todos ellos son nombres de Tecnologías Web.

Algunas son de las últimas tecnologías que han salido y otras de aquellas que ya llevan un tiempo y son de las más usadas actualmente. Algunas nos permiten desarrollar aplicaciones web y otras aplicaciones para móviles (híbridas y nativas) pero usando lenguajes que se usan en la web.

Seguro que ahora mismo acaba de publicarse alguna librería nueva, o hay alguien a quien se le ha ocurrido crear un nuevo framework que hace lo mismo que otro que ya existe. Pero bueno, con el tiempo puede darse a conocer y algunos desarrolladores quieren aprenderlo y cambiar aquel que están usando en sus proyectos por este nuevo, solo por estar a la última. Y al poco tiempo le saldrá algún competidor que hace exactamente lo mismo pero cambiando la sintaxis y replicando alguna de las funcionalidades de otro framework/librería y vuelta a empezar.

Ojo, con esto no quiero decir que sea algo malo. Esta muy bien aprender y conocer cuales son las tecnologías web que acaban de salir, conocer las ventajas y desventajas frente a otras, y sobre todo que problemas se han encontrado los creadores para que dijeran "vamos a desarrollar Vuelar Native" y terminaran por crearlo. Lo que quiero decir es lo siguiente, ¿es necesario cambiar el proyecto de tecnologías porque ha salido una nueva y queremos usarla?, es decir, tenemos un proyecto con Angular, ha salido Vue y decidimos volver a desarrollar en Vue todo lo que ya teníamos funcionando. Yo creo que no.

Pieter Levels (@levelsio en Twitter) es un nómada digital que ha construido varias aplicaciones web para las personas que se dedican a viajar por el mundo al mismo tiempo que trabajan. Una de estas aplicaciones es Nomad List, una herramienta que proporciona mucha información importante para estos nómadas, como por ejemplo, el tiempo, el coste de vida, la velocidad de internet...

Mirad los siguientes tweets:

• https://twitter.com/levelsio/status/902136319463350272?s=20

• https://twitter.com/levelsio/status/902129203197485057?s=20

Algunos me podríais decir, es de 2017, seguramente ya haya cambiado jQuery por otra librería. Pues ya os digo yo que no es así.

Bueno, no me quiero ir por las ramas, entonces, ¿cómo han ido evolucionando las tecnologías web desde los inicios hasta la actualidad, donde nos encontramos con tantas librerías y frameworks?

El Despertar de la Web

Todo empezó en 1989, cuanto Tim Berners-Lee, un ingeniero del CERN, crea un documento en el que define una forma de compartir la información que se encontraba repartida entre los distintos ordenadores que usaban en el CERN. Y en el 1990 Tim crea el primer servidor de páginas web.

Lo siguiente que hizo Tim fue proponer un nuevo sistema de hipertexto que les permitiera compartir los documentos, y de esta forma se empieza a desarrollar lo que hoy conocemos como HTML. En  1991 se publica un primer documento que llevaba el nombre de HTML Tags en el que se definían 18 etiquetas que les permitirían estructurar los documentos, permitiendo usar títulos, párrafos, listas, enlaces...

En 1993 se presentan dos propuestas (HTML y HTML+) para convertirlo en un estándar, y en estas propuestas se incluían nuevas etiquetas bastante importantes a la hora de crear los documentos científicos, como permitir crear tablas y añadir imágenes. Pero no se convierte en un estándar hasta 1995, cuando se publica HTML 2.0.

Durante estos años las aplicaciones ya incorporaban formularios grandes que se validaban en el servidor, lo que conllevaba que los usuarios tuvieran que esperar hasta que el servidor respondiera si eran correctos y cumplían con las validaciones, o no.

Ante este problema, en 1995, Brendan Eich (trabajador de Netscape) desarrolló un lenguaje que podía ser ejecutado en el navegador para reducir el tiempo de espera ante la respuesta del servidor. El nombre del lenguaje empezó siendo Mocha, más tarde ese mismo año se cambió a LiveScript, y por último se le llamó JavaScript debido a que el lenguaje de moda de aquella época era Java y querían atraer a los programadores de este lenguaje.

Ahora solo faltaba poder cambiar la apariencia de los sitios web que había por aquella época, y aquí es donde entra CSS que se presenta oficialmente el mismo año que JS. Aunque ya existían anteriormente otros lenguajes de estilos, este permite aplicar en forma de cascada unas propiedades a los elementos de la página que se han definido en distintas hojas de estilos.

Esta primera versión permitía definir estilos para los textos, cajas y listas, permitiendo añadir márgenes, establecer el tamaño y tipos de letras, añadir los bordes, cambiar los colores de las letras y los fondos...

Este año, Rasmus Lerdof empieza a desarrollar PHP, inicialmente para contar el número de visitas que se realizaban a su CV, y que va a ir evolucionando permitiendo generar páginas dinámicas incrustando código PHP dentro del HTML. Este es considerado uno de los primeros lenguajes de programación en el lado del servidor.

La Amenaza Flashtasma

Durante el 1996, Adobe Flash (en aquel momento conocido como Macromedia Flash) entra en juego permitiendo que se puedan ver videos y escuchar música en los navegadores, algo que hasta este momento era imposible de hacer con cualquier otra tecnología. Lo único necesario era tener instalado el plugin en los navegadores.

Pero su destino no iba a ser muy bueno. Debido a la gran cantidad de agujeros de seguridad en el código, los dispositivos de Apple eran incompatibles debido a la gran cantidad de recursos que consumía Flash, y por último la llegada de HTML5 que permitía hacer lo que Flash pero con la ventaja de que lo hacía de forma nativa sin necesidad de instalar plugins en los navegadores, se ha terminado porque Adobe haya decidido de dejar Flash.

A finales de este mismo año, Microsoft lanza ASP, una tecnología del lado del servidor que va a permitir crear páginas web dinámicamente inyectando en el HTML a través de código de scripting con el que se puede llegar incluso a hacer que los datos se obtengan de una BBDD. El principal problema de esta tecnología es, que solo funciona bajo los entornos de Microsoft.

Otra de las tecnologías que aparecen este año es XML, un metalenguaje desarrollado por la W3C y que permite declarar lenguajes de marcado. XML se ha usado para definir los mensajes que se envían cuando varias aplicaciones se tienen que comunicar (SOAP, WSDL...),

Al siguiente año, Sun Microsystems saca la especificación de los Java Servlets, la alternativa a ASP y PHP de los que hemos hablado anteriormente, pero esta vez para el lenguaje Java. Estos servlets son clases de Java que se van a ejecutar cuando el servidor recibe las peticiones, y es dentro de los métodos donde se va a ir generando la página de HTML dinámicamente, mientras que con las otras tecnologías, el código se incrusta en el HTML.

Por 1998 se publica HTML 4.0 que incluía varias mejoras frente a las versiones anteriores. Pero a partir de esta versión, la W3C que se encargaba de la estandarización de este lenguaje lo deja de lado para centrarse en XHTML, lo que lleva a algunas empresas como Apple, Mozilla u Opera a crear la WHATWG (Web Hypertext Application Technology Working Group) que se iba a encargar de seguir trabajando en la especificación de HTML llegando a sacar HTML5 más adelante.

También es este año cuando se publica la especificación de CSS2 en la que se añaden algunas propiedades que permiten indicar como se tienen que posicionar los elementos en la página, también se añadieron los media types que permitían aplicar las propiedades en la pantalla, en el página de impresión... y las sombras.

Ya que ASP era de Microsoft, y todo aquello que pertenecía a Microsoft solo funcionaba en sus plataformas, en el 1999 aparece una nueva tecnología, JSP (Java Server Pages), la cual va a permitir generar dinámicamente las páginas en el servidor incrustando el código de Java dentro de la página HTML. Además, viene a resolver el principal problema de ASP, la portabilidad.

Y hasta aquí llega este primer post, en el que hemos visto como aparecen los principales lenguajes usados en el cliente y algunas herramientas que nos permiten generar las páginas dinámicamente desde el servidor. No os perdáis el siguiente post, Tecnologías Web 102. 

Patrones de Arquitectura

¡Hola a todos! Uno de los cursos más interesantes que imparto es el de "Patrones de Arquitectura", donde se estudia el modelo de solución de diferentes proyectos y problemas habituales en cuanto a su arquitectura. Me he encontrado frecuentemente muchas dudas al respecto durante la impartición, así que he decidido clarificar un poco los conceptos previos con este blog.

Considero que todo buen desarrollador o arquitecto podría hacer buen uso de estas soluciones, y es por ello que en esta entrada intento iluminar algunos puntos de interés. Comenzamos con una definición, como no podría ser de otra manera.

Un patrón es una idea o, dicho de otra manera, es una forma de resolver un problema que no se ata a ningún lenguaje ni software específico. Esta definición nos ha acompañado durante años y últimamente está en boga, debido, como siempre, a las necesidades de nuestra sociedad y empresas respecto a los tipos de productos de software que hacemos.

Modelo MVC

Desde el inicio, los arquitectos de software hemos querido hacer las cosas bien y estudiar la mejor manera que radique en el complicado equilibrio entre mantenibilidad, velocidad y desacoplamiento de nuestros productos.

Así pues, el patrón MVC (Modelo-Vista-Controlador) y el patrón de Arquitectura de capas fueron los primeros creados para tal efecto. La división del código del producto en diferentes capas nos ofrecía un resultado esperanzador, ya que nos permitía que los desarrolladores se enfrentaran en resolver el código en menos líneas, ofreciendo una reusabilidad de las diferentes capas entre sí.

Modelo de microservicios

En los tiempos de las arquitecturas monolíticas estos patrones pegaron fuerte… hasta que llegaron a nuestra vida los terminales móviles. Y es que la llegada de los móviles a nuestras vidas cambió nuestra sociedad desde el inicio, provocando que los usuarios ganaran una dependencia de esos pequeños aparatitos para todo. Desde compras online hasta juegos, pasando por las mismas instituciones del estado que ofrecían sus formularios… todo, hoy en día, se puede hacer con un terminal móvil.

Esta necesidad de velocidad y de tener las aplicaciones funcionando 24/7 se resolvió olvidando las viejas arquitecturas monolíticas tan usadas y pasando al patrón de Microservicios, que nos ofrecía dividir la aplicación en diferentes aplicaciones más pequeñas según disponibilidad. 

Y, a esto, teníamos que unir el uso de eventos en nuestro desarrollo, provocados tanto por nuestros clientes como por otras aplicaciones que resolvían el problema de aplicaciones de “tiempo-real” estilo chats, pujas u otras aplicaciones que necesitaban tener su información completamente actualizada. A este patrón se le denominó Orientado a eventos.

Modelo DDD siguiendo el patrón Hexagonal

Mediante estos últimos patrones se resolvían muchos de los problemas de nuestra sociedad actual pero otro surgía: nuestros usuarios eran cada vez más numerosos y el número de peticiones aumentaba en la misma proporción.

Así pues, se estimó proteger, de alguna manera, nuestros sistemas de información de un número de peticiones tan elevado. 

Se estudió la segregación de nuestras peticiones entre las de lectura y escritura, dividiendo y usando dos sistemas de información que se actualizarán entre sí mediante el patrón Orientado a eventos. Este nuevo patrón se llamó CQRS (Command Query Responsability Segregation) y resolvió con éxito el problema del numeroso número de peticiones a nuestros sistemas de información. 

Pronto, este patrón se conectó al patrón Hexagonal que resolvía que diferentes tipos de clientes accedieran a un mismo núcleo de nuestra aplicación que, al mismo tiempo, se adaptaba también a diferentes sistemas de información.

Todos los patrones de los que he hablado anteriormente resuelven distintos problemas y necesidades, pero hay uno que puede servir de pegamento o unión entre ellos y que maneja la arquitectura de nuestra aplicación de una manera notable y eficiente. Se trata del patrón DDD (Domain Driven Development), que estudia una nueva arquitectura de capas basada en el lenguaje ubicuo que nos dicta a que todo lo que escribamos sea semántico y, por tanto, entendible. DDD nos obliga a reestructurar toda nuestra aplicación y desarrollo, dividiendo en nuevas capas con una estructura donde el dominio es lo más importante y, esto es, el diseño de nuestra aplicación.

Hoy en día los patrones de arquitectura evolucionan con nuestra sociedad, obligando a los arquitectos a redefinirlos para solucionar los problemas enfocados a nuestras aplicaciones. Las necesidades marcan las pautas y el futuro nos dirá qué nuevos patrones traerá consigo. Y es que, en desarrollo, hay una verdad empírica: siempre hay una mejor manera de hacer las cosas.

Espero que os haya resultado interesante el artículo, como siempre aquí os dejo algunos links de interés que pueden ayudar a completar el conocimiento expuesto.

https://medium.com/all-you-need-is-clean-code/patrones-de-dise%C3%B1o-b7a99b8525e
https://www.genbeta.com/desarrollo/patrones-de-diseno-que-son-y-por-que-debes-usarlos
https://platzi.com/blog/patrones-de-diseno/


¡Muchas gracias por vuestra atención y nos leemos de nuevo próximamente!

Formación y educación durante y después COVID-19

Soy de los que creen que esta crisis va a cambiar nuestra manera de vivir, y que a corto y medio plazo, va a cambiar muchas costumbres y muchos hábitos.

Pero ¡ojo!, los cambios no tienen por qué ser malos, son simplemente cambios, y necesitan un periodo de adaptación y transición para que maduren y puedan ser perfectamente viables, ¡es más! Me atrevería a decir que incluso pueden mejorar la situación de la que partían.

Mi Experiencia

Es abrumador el número de cursos y formaciones a distintos niveles (empresas, universidad, profesional) que se han parado o directamente suspendido, evidentemente, es completamente entendible en estas circunstancias y en un mundo en el que la formación presencial era el formato más habitual. ¿Había formación online? Sí, sí que la había, pero en un porcentaje significativamente menor con respecto a la formación presencial.

Todavía recuerdo la primera vez, hace 4 años, cuando impartí mi primera formación online. Era un curso sobre programación web segura. Era un curso donde los alumnos eran de diferentes provincias y se decidió hacer en este formato debido a los costes y dificultades de juntar a todos los alumnos en una sola clase.

No os voy a engañar, en ese momento no era muy optimista respecto a dar la formación online, siempre había impartido en presencial y sentí cierto rechazo a salir de mi circulo de confort. ¿Qué paso? me atrevería a decir que el curso salió más que bien, o así al menos los alumnos lo reflejaron en las evaluaciones. ¿Mis sensaciones? me sentí bastante más cómodo de lo que me imaginaba en una primera instancia, no en el primer momento, pero durante la semana fui viendo las bondades del formato online respecto al presencial, como pueden ser, el ahorro de costes (tanto para la empresa como para el trabajador), el tiempo ganado en desplazamientos o la tranquilidad de que puedes dar el curso en tu home office.

¿Es mejor la formación online o la presencial? Me hacen mucho esa pregunta los alumnos la verdad 😊. Para mi ninguna es perfecta, cada una tiene sus pros y sus contras.

¿Mi opinión? Me considero una persona muy empática y cercana, me gusta estar al lado del alumno y eso puede hacer que mi balanza se gire levemente hacia la presencialidad, pero he comprobado que también se puede ser cercano desde la distancia, eso va dentro del formador y no tiene que ver con los medios que utilices.

Formación a Empresas

Ahora mismo Pronoide, con quien colaboro estrechamente en la formación a empresas, está dedicada totalmente a trabajar con la formación online, la manera presencial no es posible en estos momentos.  Muchas empresas están dando una oportunidad a la formación en remoto, aunque este cambio no se hará de la noche a la mañana, sí que nos gusta pensar en un futuro con optimismo. Hay empresas que empiezan mandando uno o dos participantes a las ediciones públicas de calendario para ver cómo funciona el formato remoto. Hay empresas que están contratando ediciones de cursos para formaciones internas de sus equipos online.

Como ya he dicho para las empresas y sus empleados estos formatos suponen, mayor ahorro de costes, al eliminar la barrera geográfica, las formaciones remotas se pueden planificar mejor (por ejemplo, en franjas más cortas) al no tener que reservar o bloquear aulas físicas, y se evitan los horarios incomodos para tener más holgura y esperar que todo el mundo llegue al centro de formación.

Formación Reglada

El panorama actual afecta también severamente a los institutos y las universidades donde también trabajo como profesor, por lo que veo de primera mano lo que está ocurriendo.

Al suspenderse las clases presenciales, automáticamente se han pasado todas las clases a modelo online, por lo que impartimos todas en remoto. En el caso del instituto no me afecta, ya que es 100% online, pero en el caso de la universidad sí que ha habido un pequeño periodo de adaptación. ¿Se ha perdido la calidad? Desde mi punto de vista no, se ha perdido el contacto físico con el alumno, pero la calidad es similar, las tecnologías permiten esta flexibilidad sin que lo notemos demasiado.

Es cierto es que no va a haber este año exámenes presenciales, por lo que la manera de evaluar al alumnado será diferente. Desde mi ámbito se está fomentando mucho la evaluación continua, y evaluar a los alumnos con sus actividades, su asistencia a clase y su participación. No creo que esta política sea mala, de hecho, nunca he creído demasiado en los exámenes. En mi clase y al finalizar un curso, sé con bastante seguridad qué alumno sabe y cuál no, sin mucha necesidad de hacer exámenes.

Con esto quiero decir que, esta situación tan excepcional en la que nos encontramos, puede que nos enseñe otras maneras de evaluación de los alumnos, no solo la del examen de toda la vida, y que pueden ser perfectamente viables y válidas.

¿Cambiará la formación tal y como la como la conocemos?

Estoy convencido que la educación online va a tener gran protagonismo en este periodo como ya estamos empezando a ver, y también creo que la tendencia a hacer los cursos en remoto cada vez será mayor.

Didácticas para formación virtual

En mi entrada anterior sobre Claves para la formación virtual, os comentaba cuales eran los factores y tecnologías para tener éxito en una formación virtual.
En este caso, me gustaría compartir con vosotros algo más delicado, la metodología. Se trata de una experiencia labrada durante más de diez años en formación.

Para poder completar con éxito una formación virtual, hay una serie de factores y técnicas de aplicación a tener en cuenta que os muestro a continuación.

Comunicación:

Posiblemente sea lo menos cuidado y atractivo de un curso online para el formador. El objetivo de un formador es impartir con garantía la formación y, para ello, es necesario disponer de un feedback continuo de la evolución del curso.

Lo primero que tenemos que garantizar es la comunicación entre alumnos y profesor. 

Una buena dinámica para comenzar es la presentación de cada uno de los alumnos del curso. Este apartado es muy importante, ya que puede determinar el destino del curso. Las preguntas que hay que responder deberían ser:

-       Nombre: Para dirigirte al alumno con propiedad, aunque en la práctica no es fácil reconocer cuando habla uno u otro. Es bueno que apuntemos en una hoja de papel estos datos para luego poder reconocerlos más tarde.

-       Puesto de trabajo: Su rol en el trabajo indicará también cuál es su objetivo en el curso.

-       Conocimientos previos de la materia del curso: El objetivo es saber cuál es su nivel al comenzar el curso. Si es alto o bajo, si es un curso homogéneo para principiantes o para gente avanzada, si hay variedad de perfiles, etc.

-       Expectativas del curso: Cuáles son a nivel individual los objetivos y planteamientos que tiene el alumno para el curso.

Debemos pensar que estamos en el aula con los alumnos, pero que no podemos verlos y la algunas veces ni siquiera oírlos. Es común que alguno de ellos no posea micrófono, o que no sea de calidad, o que no funcione. En estos casos debemos tener opción de utilizar los mensajes de chat, lo que nos obliga a tener el chat siempre a mano y vigilarlo en caso de que algún alumno pregunte por ese canal. 

En el caso de que el chat no sea fácil de monitorizar, es recomendable hacer partícipes a todos los alumnos indicando que, si ven algo en el chat, lo comuniquen por micrófono para contestar lo antes posible. Este truco suelo usarlo mucho ya que los chats no suelen ser fáciles de visualizar mientras estás realizando un laboratorio o explicando un diagrama.

Durante el curso, sobre todo el primer día, se deben realizar preguntas y buscar comentarios para tener la impresión de los alumnos sobre la marcha inicial del curso. En ocasiones, los alumnos pueden tardar en contestar casi un minuto, pero es cierto que solo pasa al principio del curso. La mayoría de las veces suele ser porque no tienen el micrófono activado, no se esperan la pregunta o no les gusta hablar, pero al final siempre contesta alguien y, de hecho, los que contestan suelen estar activos e implicados durante toda la formación. 

Procuro que la gente se involucre y comente, lo que da al profesor una garantía de que todo está yendo bien.

Laboratorios:

Durante los cursos, especialmente los que tienen una carga lectiva importante, hay que alternar teoría y práctica. En el apartado de prácticas hay que tener cuidado ya que las prácticas guiadas implican que hay que hacer contínuas pausas y preguntas para ver que los alumnos no se pierden y van bien las actividades propuestas.

La forma de solucionar problemas suele ser más compleja que en un aula presencial, y estos problemas no deben bloquear un curso. En los cursos en los que uso máquina virtual suelo hacer una copia de la máquina por día (snapshot) para que la gente que se haya perdido en la práctica pueda continuar el día siguiente sin bloquear a los demás y no tener que abandonar el curso por no poder seguirlo. En ocasiones, aprovecho el inicio o el fin del curso para resolver esos problemas individualmente.

Dinamismo:

En una jornada de formación virtual da tiempo a muchas cosas, pero lo cierto es que no es igual a un aula en formación presencial. No podemos estar un día entero impartiendo teoría y no veremos las caras de los alumnos para ver si les está gustando o no. Para ello se alterna teoría, pizarra para explicaciones y prácticas sencillas con pocos pasos y muy claros, sobre todo al principio de la formación para que se aprecie que el curso es dinámico. Cada hora del curso, a lo sumo, hay que conseguir un feedback de los alumnos para comprobar que siguen ahí y que les es interesante lo que están aprendiendo.

También es bueno orientarse a los temas que dominan o conocen los alumnos para acercar el curso a sus casos particulares. Muchas veces los alumnos cuentan anécdotas y casos de uso interesantes que enriquecen el curso. Sorprende cuando a veces los participantes (aun procediendo de la misma empresa), tienen vivencias totalmente diferentes con las tecnologías/herramientas y el como a veces se crean conversaciones pueden aportar distintos puntos de vista o experiencias reales que añaden una enseñanza de gran valor al grupo de alumnos.  

Cercanía:

Cuando hablo de cercanía me refiero a la habilidad del formador de tener empatía con los alumnos. Comprender su ánimo, contar algún chiste (relacionado con la materia a ser posible) para relajar el ambiente con el objetivo de conseguir alguna retroalimentación que sea franca y valiosa.

Esta parte es un arma de doble filo. La táctica de cercanía se utiliza para que los alumnos tengan la confianza de interrumpir para preguntar en cualquier momento. Es rozar un poco en lo personal y eso puede hacer que algunas personas se incomoden o no entiendan, que a veces la línea recta no es la distancia más corta entre dos puntos. 

Sin embargo, si funciona bien, la cercanía hace más ameno y fructífero el curso. En los casos donde he aplicado la cercanía correctamente, con complicidad y compañerismos, los cursos han sido más agiles y eficaces, y los alumnos más puntuales e involucrados.

Durante la presentación de los alumnos puede verse cuando es posible ser mas cercano o cuando no. ¿Cuándo aplicarlo? No hay una respuesta que valga siempre para esta pregunta. Los alumnos tienen que demostrar cercanía en la presentación del curso, pero, aún así, en el caso de que haya alguno que no vaya a encajar, aunque sea solo uno, es mejor no aplicarlo y optar por mantener las formas y distancias reglamentarias.

Inicio y fin de sesión:

El inicio y fin de las sesiones debe ser consistente y homogéneo, que los alumnos entiendan que es el inicio y que es el final. Al inicio, excepto en la primera sesión, es bueno hacer un repaso explicando lo que se hizo el día anterior. Eso da tiempo a que alumnos rezagados lleguen y que no se pierdan nuevo contenido (y no tengamos que volver a empezar para no perderlos durante el arranque del día).

Al finalizar la sesión, debería haber siempre cinco o diez minutos de comentarios y preguntas. Siempre empleo la frase “Dudas, preguntas, opiniones y críticas”. Es bueno, sobre todo en las primeras sesiones, que los alumnos indiquen el grado de satisfacción del curso, si hay que modificar algo: como el ritmo de exposición, o hacer las sesiones más prácticas, o subir o bajar el nivel del curso, etc. De esta forma, la calidad percibida de formación es mucho mayor.

Conclusión:

Con esta entrada pretendo que se comprenda la complejidad de una formación virtual y que, si tenemos en cuenta todo esto, podremos realizar con altas probabilidades de éxito. Hay que tener en cuenta muchos factores como hemos visto pero, para poder hacer las cosas bien, primero hay que saber qué es lo que no estamos haciendo o qué estamos haciendo mal.

En todos mis cursos, el último día, a última hora, siempre pregunto a mis alumnos que cambiarían del curso para mejorarlo la próxima vez porque, aunque seamos profesores, también tenemos mucho que aprender.

Claves para la formación virtual

Si me hubieran dicho hace unos años que ocurriría algo como el Covid-19, no me lo hubiera creído. Sin embargo, aquí estamos. En una situación de confinamiento sin precedentes y, tal vez, una oportunidad sin precedentes. De las grandes crisis se puede salir reforzado y, en este estado de confinamiento, la formación puede salir reforzada con la formación virtual.

Mi trabajo como formador me hace viajar por toda España y, a veces, fuera de ella. Aún así, vivo totalmente descentralizado: mi oficina está apenas a tres metros de mi dormitorio, mis reuniones se realizan online, y la comunicación con los clientes son vía telefónica o a través de videoconferencia.

Llevo ya unos cuantos años realizando formación virtual y por eso creo que es bueno contar mis impresiones y conocimientos sobre el tema y compartirlo con la comunidad. Pero lo que realmente interesa es cómo afrontar el día a día a la hora de realizar las formaciones.

En mi artículo Didácticas para la formación virtual explico los factores didácticos a tener en cuenta. En este caso nos centraremos en los factores técnicos.

Al grano

No es una tarea sencilla, ya que no es comparable tener a los alumnos delante o estar a cientos de kilómetros de distancia.

Debemos tener en cuenta diversas cuestiones que voy a resumir:

Consideraciones técnicas y de infraestructura

Debemos tener en cuenta que, para poder dar una formación online, una parte muy importante es planear con antelación las herramientas que vamos a necesitar y los temas que debemos cubrir para poder dar el curso con garantías de éxito. Las más importantes a tener en cuenta son las siguientes:

Ancho de banda del formador: Una de las primeras preguntas que hay que hacerse es: ¿Tengo capacidad para transmitir video y audio? ¿Cuánto tardaría en enviar información (ficheros grandes) a mis alumnos?

Es muy recomendable que el profesor posea un ancho de banda más que suficiente para transmitir y compartir información con los alumnos sin afectar a la conexión. Si tenemos otros equipos o programas en ejecución que usen el mismo ancho de banda, no está de más apagarlos durante las sesiones.

Los alumnos deben tener un ancho de banda suficiente para que puedan transmitir y recibir. En general los alumnos suelen tapar la webcam, deshabilitarla, o simplemente no tienen.

Requisitos del curso: Uno de los puntos críticos. Esta parte suele ser bastante compleja, ya que los alumnos en sus casas deben cumplir con los requisitos mínimos del curso. Los alumnos puede que tengan equipos de empresa en casa, pero no hay garantías de que tengan permisos de instalación o manipulación avanzada (Activación de Intel VT/AMD V para la virtualización). Incluso algunos no tienen equipo de empresa y usan el de sus casas, pudiendo ser insuficientes para recibir la formación o realizar las prácticas.

Estoy muy a favor del uso de virtualización para los cursos cuando son cursos técnicos, como por ejemplo VirtualBox de Oracle. La justificación de usar máquinas virtuales en mis cursos es tener controlado el entorno del alumno y que sea homogéneo para todos los participantes. De esta forma, los problemas son los mismos o son reproducibles por el profesor.

Herramientas del formador:

Siempre es necesario que el profesor tenga una serie de herramientas a su disposición. Estas herramientas dan un salto de excelencia a los cursos, lo que permite que sean de mayor calidad. En la siguiente lista indico las herramientas que deberíamos tener para facilitar y hacer más amena la formación:

•  Webcam: Muy recomendable, casi obligatoria. Debe ser suficientemente buena para que nos vean en todo momento. Los alumnos no suelen compartir la imagen, pero el hecho de que los alumnos vean a una persona explicarse y apoyarse visualmente ayuda mucho a amenizar y personalizar el curso.

• Carpeta compartida: Es recomendable que haya un punto común de compartición entre profesor y alumnos para pasar información, ejercicios resueltos, documentación, etc. Debe ser dinámica para que sea sencillo compartir algo en cualquier momento sin perder tiempo. En mi empresa tenemos una cabina Synology y suelo compartir una carpeta con los alumnos para que puedan obtener la información en tiempo real.

• Pizarra: Ya sea física o virtual. Aunque no lo parezca, una buena webcam y una pizarra manual puede ser mejor que usar una pizarra virtual sin medios. Se pueden usar tabletas gráficas WaCom o similares y usar un pencil para pintar. En mi caso, trabajo con Mac y uso el iPad como pizarra. Si lo tenéis, podéis usar QuickTime Player para mostrar la pantalla del iPad en el escritorio y usar un Apple Pencil para pintar. Al terminar el dibujo se hace una captura y se comparte. Así de sencillo. Para la pizarra física, los alumnos pueden hacer una captura de pantalla o una fotografía, aunque esta última no lo aconsejo. El uso de una pizarra da dinamismo al curso, permite realizar resúmenes diarios que facilitan la comprensión y rompen la monotonía de un curso virtual.

• Herramienta de videoconferencias: Este tema lo hablaré detenidamente en otra entrada de blog y lo enlazaré a este. Pero lo importante es saber que herramientas hay, cuál se puede utilizar (a veces las subvenciones en formación nos obligan a usar herramientas concretas), calidad de la herramienta, componentes específicos de formación, como formularios, chats, pizarras virtuales, etc. Existen muchas herramientas y más adelante resumiré las que más nos interesan. Una de las que más me gustan en cuanto a comportamiento es Zoom, sin embargo, tras sus últimas polemicas por su seguridad, ya no es tan atractiva.

Otras consideraciones:

• Capacidad de alumnos y ancho de banda consumido por las herramientas: Muchas herramientas poseen de forma gratuita un número reducido de alumnos y otras exigen a mayor cantidad de alumnos mayor ancho de banda. Incluso hay herramientas point-to-point que permiten hacer videoconferencias usando redes locales como jitsy. Estas últimas son muy útiles cuando se imparten cursos mixtos (presencial y online) cuando todos los alumnos están ubicados en la misma red local.

• Calidad de las video llamadas: Hay herramientas cuya calidad es espectacular y otras que hacen que la imagen no sea lo suficientemente buena. Imaginad estar compartiendo un escritorio donde no se ve Como comentaba en la entrada anterior, en casos especiales, una herramienta con streaming local funcionará mejor si están todos en la misma empresa, sin embargo, con una herramienta clásica de streaming remoto, usarán todos los participantes el mismo recurso de internet de la empresa, pudiendo colapsar el servicio.

• Herramientas de formación: Existen tres tipos de herramientas de videoconferencias: orientada a llamadas simples, como por ejemplo Skype, orientada a reuniones profesionales, como Google Meet y orientadas a formación, como Cisco WebEx. Estas últimas poseen herramientas dedicadas específicamente para la impartición de cursos de formación, pero, a veces, esas herramientas son tan complejas de utilizar, que aportan ruido a un curso y hacen que los alumnos se pierdan en los detalles.

• Compatibilidad: Hay que evaluar que la herramienta sea compatible tanto con el equipo del profesor como el de los alumnos. Las herramientas puramente web suelen ser claros ganadores, sin embargo, muchas de ellas usan plugins java o flash, siendo este último ya obsoleto y su ejecución es bastante compleja e, incluso, incompatible con ciertos navegadores y sistemas operativos presentes y futuros.

• Homologación: Debemos pensar si la herramienta está homologada para su uso. Muy importante para cursos subvencionados, ya que son muy estrictos para estos temas. Las restricciones en cuanto a la plataforma online son muy grandes. Un ejemplo sería Classonlive, donde posee compatibilidad con los requisitos de la Fundae.

En resumen:

Con esta primera entrada intento que nos demos cuenta de cuales son los factores determinantes para que una formación online sea exitosa, ya que muchas veces damos por supuesto algunos de estos puntos que luego no son ciertos.  

De brete en brete

Aún recuerdo la primera crisis que sufrimos en Pronoide allá por 2005, después de los dos primeros años exitosos de la empresa, de repente nos quedamos sin clientes y sin proyectos... Éramos una joven empresa de desarrollo, a la que incluso el mantenimiento del software creado por nosotros mismos, se le encargaba a otra empresa mucho más grande. Tras 6 meses de agonía, el equipo estaba desmoralizado, yo estaba arruinado, mantener el proyecto me costó deber dinero a mi familia, a mis amigos, a mi pareja... La rutina de sacar dinero de todas las tarjetas de crédito personales, para ingresar en el banco de la empresa y pagar las nóminas.

Quince años más tarde miro aquella crisis casi con cariño. En aquel momento realizamos casi cualquier tarea relacionada con el mundo de la informática que se nos ponía al alcance: tratamos de crear nuevas aplicaciones (que nunca se vendían lo suficientemente rápido), traté de perito judicial informático (litigar no es para ingenuos), o de convertirme experto en protección de datos (la legislación imposible de cumplir), inténtanos montar redes inalámbricas en África (con vacuna de la malaria incluida) … Y de repente, sin planearlo, a partir de un curso de creación de plantillas personalizadas para MS Visio que impartí por casualidad (¿quién necesitaba un curso de eso?), nos metimos en el negocio de la formación técnica informática. Al principio, solo yo, luego Luis Ramón, y finalmente toda la empresa se transformó en una empresa de formación especializada en informática para profesionales. Cambiamos el desarrollo de programas, por enseñar a programar, en el año 2005 dimos 4 cursos y menos de 100 horas de formación antes de cerrar el año. El año pasado, 2019, impartimos 350 cursos y casi llegamos a las 10.000 horas de formación. No somos una empresa grande, no tenemos comerciales, pero nos gusta lo que hacemos. Somos 10 empleados (la gran mayoría profesores) y unos 30 colaboradores

En estos 14 años, hemos pasado otras crisis o momentos difíciles, alguna vez por temas coyunturales (como la crisis económica del 2008), otras un poco por nuestras decisiones (por cubrir más áreas técnicas de conocimiento en 2013). Eso sí, después de cada momento duro, hemos crecido como empresa: en 2009 ampliamos la plantilla de formadores, en 2014 salimos del mundo Java (nuestra área de mayor conocimiento) y entramos en temas Big Data, DevOps y Desarrollo Front. Hemos tenido algún año en el que hemos cerrado en números rojosEn algún momento hemos cerrado el año en números rojos, que siempre he preferido llamarlos inversión a pérdidas. Alguna vez, he tenido que pedir préstamos bancarios personales para cubrir a mi empresa. Hemos tenido suerte, podríamos haber tenido que cerrar forzosamente, pero siempre hemos tenido una tendencia clara a crecer tras los momentos difíciles.



¿Cómo nos planteamos en Pronoide estas semanas, meses o quién sabe si trimestres? Con total normalidad, sin prisas. No vamos a despedir a nadie, no vamos a cambiar la duración de la jornada laboral, no vamos a pedir a nadie tomar vacaciones, y vamos a seguir asignando a nuestros colaboradores cursos sin priorizar a la plantilla interna…  Estamos decididos a aprovechar la crisis, como un momento único, de parada de casi todos los cursos (seguimos impartiendo algunos cursos en remoto), para acelerar nuestra transformación digital (esa que avanzaba a cuenta gotas), para formar al equipo en temas nuevos (que nunca había tiempo suficiente para preparar), para evitar esos cursos que sólo puede dar uno (terminar con los monopolios de conocimiento interno) y para crear una metodología más ágil de gestión de nuestros cursos (que nos permita escalar más rápidamente cuando se normalice la situación).

¿Por qué? Porque llevamos mucho tiempo formando a nuestros profesores de plantilla como para no darles total cobertura y protección, porque hemos trabajado mucho en crear nuestra red de colaboradores para ahora desmoronarla a la primera dificultad, porque podemos seguir impartiendo formación en modo virtual o remoto, porque tenemos la posibilidad de encajar este golpe aunque sea con números rojos (inversión), porque muchas empresas van a necesitar nuestra ayuda, en el proceso de aceleración digital que sobreviene, para aprender a pasar al mundo Cloud, para administrar sus entornos, para crear aplicaciones, para gestionar sus equipos de desarrollo. Porque las empresas y profesionales que formemos se recuperarán y ayudarán a otros a recuperarse…El sector de las tecnologías de la información no puede acobardarse ni ser cauteloso, no tenemos motivos reales.
Sé que, en muchos otros sectores, y en muchas empresas, las perspectivas no son tan halagüeñas como las que planteo… razón de más por la que en Pronoide tenemos que ser muy responsables y comprometernos al máximo con nuestra gente, nuestros colaboradores, nuestras familias, nuestras empresas clientes y en definitiva con ésta, nuestra sociedad, que tendremos que poner en marcha de nuevo, en cuanto se pueda, con un montón de lecciones aprendidas en unas pocas semanas.