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.