lunes, 5 de octubre de 2020

Diseño de un api ReST (y II)

Continuamos la serie sobre apis ReST. En el anterior post vimos el papel que tiene el protocolo HTTP y el significado de los métodos, así como ejemplos de las urls más sencillas. Con estos rudimentos podemos construir nuestra api, en un ejemplo en el que el recurso serán los clientes en una aplicación de gestión.


El recurso

Los recursos cliente de nuestro ejemplo tendrán las siguientes propiedades (a modo de muestra)

  • id: numérico, es un identificador único para cada cliente
  • nombre, cadena de texto
  • direccion, cadena de texto
  • telefono, cadena de texto

El api

Antes de definir un api debemos conocer lo que se esperan las aplicaciones clientes de nuestro servicio y cuales son los requisitos de la aplicación que lo publica. Vamos a suponer que en nuestro caso es necesario un mantenimiento básico de los datos de los clientes, con las siguientes funcionalidades:

  • Generación de listados de clientes
  • Búsqueda de un cliente
  • Alta de un nuevo cliente
  • Modificación de un cliente
  • Baja de un cliente

-Nada que ver aquí, es solo un CRUD


GET /clientes

Devuelve el contenido del directorio ‘clientes’. Aquí hay una idea importante: lo que debe devolver una petición GET será lo contenido en la última carpeta de la ruta si no se adjunta un identificador. ¿Y si hay muchos clientes? Pues mientras no filtremos los resultados deberán devolverse todos. Más adelante hablaremos de cómo debe expresarse el filtrado de resultados en un api ReST





Vemos que al solicitar clientes con GET nos envían un documento JSON con la representación del estado actual de los clientes en el servidor.


-¿Asi que eso es lo que significa representational state transfer?


GET /clientes/{id}

Devuelve el recurso contenido en el directorio ‘clientes’ cuyo identificador es ‘id’. ¿Y si no existe un recurso con ese identificador? Otro punto importante aquí: todas las respuestas que de el servidor deben incluir el código de respuesta HTTP adecuado. En este caso debería ser 404 NOT FOUND en lugar de un 200 OK.

Podría pensarse que para solicitar un único cliente debiera ser ‘GET /cliente/{id}’ pero esto no es así. El protocolo HTTP habla de recursos que están en directorios y los clientes están en ‘clientes’. Es una regla: los directorios guardan muchos recursos, los directorios están en plural. Es más: la petición ‘GET /clientes/{id}’ ha de interpretarse como ‘entra en el directorio clientes y localiza el recurso cuyo id es el indicado’.



POST /clientes

Insertará un recurso nuevo en el directorio ‘clientes’. De nuevo nos encontramos con asuntos destacables. El nuevo recurso deberá adjuntarse como contenido en el cuerpo de la petición HTTP, en el formato que el servidor espere o soporte. Como respuesta a una petición post es buena idea entregar el recurso tal y como ha quedado en el servidor, su id o un enlace a él.




PUT /clientes/{id}

Localiza el recurso cuyo id se indica en la ruta y lo sustituye por el que se haya proporcionado con la petición. Si el recurso no existiera es elección del servidor el devolver un 404 o crear un nuevo recurso.


En la petición el identificador del cliente a sustituir está en la ruta. En este ejemplo tambien lo vemos en el documento json del cuerpo. Esto es habitual, ya que las aplicaciones cliente suelen generar el json a partir de objetos en memoria y no se molestan en eliminar propiedades no solicitadas. El servidor utilizará solo el id de la ruta y deberá ignorar completamente cualquier otro. 


PATCH /clientes/{id}

PATCH fue añadido a HTTP en 2010. Es similar a PUT salvo que mientras PUT sustituye un recurso por otro PATCH modifica el existente. Esto implica que en una petición PATCH puede adjuntarse una representación parcial del recurso que incluya únicamente los valores que han de cambiar.


En la petición el identificador del recurso forma parte de la ruta (el recurso identificado con '25' del directorio 'clientes') y en el cuerpo de la petición solo se indica las propiedades que cambian. En la respuesta (y esto es opcional) se incluye el recurso entero tal y cómo ha quedado. 


DELETE /clientes/{id}

Esta petición solicita la eliminación del recurso identificado por ‘id’, que está en el directorio ‘clientes’.  Si el recurso se ha podido eliminar la respuesta será un 200 OK si queremos indicar algo al cliente (en el body de la respuesta) o 204 NO CONTENT si la simple respuesta 2XX basta. Si el recurso no existiera debería devolverse un 404 NOT FOUND.
Una petición DELETE que no incluya el identificador del recurso debería afectar a todos los recursos del directorio, es decir: ‘DELETE /clientes’ debería tener como resultado la eliminación de todos los clientes.  




Con esto ya tenemos la base del diseño de un api ReST, pero aun faltan algunos temas importantes. Continuaremos hablando de ello en el siguiente post.


Esperando la respuesta a una petición GET

lunes, 21 de septiembre de 2020

Diseño de un api ReST

En la actualidad existen muchas tecnologías para publicar servicios y componer una arquitectura cliente-servidor. ReST es probablemente la más extendida y es difícil encontrar un sitio en el que no se esté usando. En este post veremos las bases de ReST y explicaremos como diseñar un api que sea aceptablemente ortodoxa.


Cables azules para las peticiones GET. Cables blancos para las POST


El protocolo HTTP

La idea que hay detrás del protocolo HTTP es sencilla y particular: en un servidor existen una serie de recursos guardados en directorios reales o imaginarios. Después los clientes envían peticiones en las que se incluye una ruta a uno o varios de esos recursos junto con un verbo que indica que acción debe realizarse una vez estos hayan sido localizados.

Otras características de HTTP que lo hacen muy conveniente como protocolo de comunicación entre cliente-servidor son:
  • Mensajes sencillos: Los mensajes HTTP son textos planos con apenas estructura. Una cabecera con información sobre la petición y un cuerpo opcional. Es tan sencillo que la separación entre cabecera y cuerpo son dos saltos de línea y retorno de carro seguidos.
  • Independiente del formato de la información intercambiada. Puede ser xml, json, una imagen, html o cualquier cosa que se nos pase por la cabeza.
  • Sin estado: La conversación más larga que puede mantenerse con HTTP es petición-respuesta, precisamente porque HTTP está pensado para aplicaciones distribuidas que trabajan con los recursos alojados en un servidor. El servidor no almacenará estado alguno ni dedicará recursos en ello (por ejemplo creando sesiones). Si es necesario mantener un estado esta tarea recaerá sobre las aplicaciones cliente.

Esta última característica tiene una gran importancia a la hora de diseñar un api ReST y todas las funcionalidades que ofrezca el servidor deberán tenerla en cuenta.


ReST

De Representational State Transfer, es una arquitectura de software para aplicaciones cliente-servidor ideada por Roy T. Fielding cuya principal característica es que utiliza el protocolo HTTP hasta la última consecuencia. Toda la información que maneje el servidor será representada como recursos y cualquier funcionalidad ofrecida por este deberá poder accederse a través de una petición HTTP que respete los principios del protocolo al pie de la letra. 

Roy T. Fielding diciendo lo que es ReST y lo que no.

Los recursos

Lo primero que definiremos cuándo diseñamos un api ReST son los recursos. Estos serán la información que maneje nuestro servicio. Ejemplos típicos (y tópicos) de recursos podrían ser clientes, facturas, productos, empleados... Cada uno de estos recursos deberá identificarse con un valor único y poseerá distintas propiedades. Por ejemplo: los clientes tendrán id, nombre, DNI, fecha de nacimiento y los productos id, referencia, fabricante, peso, etc.

Decidir cuáles son los recursos resulta más sencillo cuando ya disponemos de una base de datos o la lógica de la aplicación. Es la norma que exista una relación entre las tablas que tengamos y los recursos del servicio. Esto también ocurrirá con respecto a las entidades que utilice nuestra lógica de negocio. Además descubriremos que las relaciones entre esas tablas o entidades se ve reflejada en las relaciones existentes entre los recursos. Pero no nos confundamos: ¡un api ReST es una abstracción que a simple vista nada tiene que ver con un diagrama de clases o de entidad-relación!


La representación de los recursos

Una vez identificados los recursos debemos decidir cómo los representaremos en las peticiones y respuestas. HTTP permite cualquier formato, pero normalmente podremos escoger entre XML y JSON debido a que los frameworks suelen tener en cuenta únicamente esos dos formatos. Si escogemos otra manera de representar a los recursos nos tocará hacer las debidas conversiones con nuestro propio código.

La inmensa mayoría de servicios ReST trabajan con JSON puesto que contienen la misma información que un XML pero son más sucintos, a costa de no incluir ninguna descripción de la información que contienen. Veámoslo con un ejemplo:

Lucha de acrónimos

En el XML vemos que hay claramente una lista de clientes. En JSON básicamente sustituimos cada etiqueta xml por un único carácter. Cierto que no queda claro que se trate de clientes y bien pudieran ser ‘empleados’ o ‘personas’ pero no debemos olvidar que en un servicio ReST tenemos una aplicación cliente que es capaz de saber que está solicitando un listado de clientes, no de empleados. El XML en este caso es un despilfarro de ancho de banda.

Las rutas

El siguiente paso una vez que conozcamos cuáles son nuestros recursos será definir las rutas para localizarlos. Debemos ‘colocarlos’ en esos directorios de los que nos habla el protocolo HTTP y es el momento de hacer un inciso relacionado con ellos.
En HTTP localizamos los recursos utilizando URLs. Con una URL identificamos un recurso, su localización y el modo en el que accederemos a él.



En la ruta encontramos los directorios en los que se localiza el recurso identificado por el valor final. Cuando se trata de recursos físicos esos directorios existen realmente. Es lo que sucede, por ejemplo, con un servidor web. En Apache (el servidor web más utilizado) disponemos del directorio ‘www’ dentro del cual organizamos nuestros ficheros .html, .css, imágenes y demás cacharrería. Cuando los recursos son abstractos, representaciones de filas en una tabla u objetos en la memoria del servidor, los situaremos en directorios ficticios para ‘seguirle el juego’ al protocolo HTTP.


Recursos físicos en un servidor Apache de color azul


Una técnica que nos ayuda a definir las rutas es imaginarnos los recursos realmente como ficheros y realizarnos la siguiente pregunta: Si tuviera una serie de ficheros, a razón de uno por ‘Empleado’ ¿en qué directorio los guardaría? ¿Y si fueran facturas, productos o cualquier otra cosa? La respuesta es clara: en los directorios ‘empleados’, ‘facturas’ y ‘productos’.

Los métodos

En HTTP una petición es una ruta a los recursos más una acción, el método. De todos los métodos definidos en HTTP los cinco que sirven para actuar sobre los recursos son

  • GET: se solicitan recursos existentes en el servidor
  • POST: añade un nuevo recurso en la ruta indicada
  • PUT: Sustituye el recurso indicado por la url por el que se envía. Si no existe lo añadirá.
  • PATCH: Modifica el recurso utilizando los datos adjuntos a la petición.
  • DELETE: Elimina los recursos indicados en la url.

En realidad los métodos no hacen nada…todo depende de la implementación del servicio en el lado del servidor. Vamos a suponer que nadie programará que al recibir un GET se elimine un recurso y que cuando se reciba un DELETE se entregen. Suena absurdo, pero es perfectamente posible hacerlo así.

Con esto ya tenemos la base de que es un servicio ReST. En el siguiente post comenzaremos con el diseño de un api sencilla.


Jordan Peterson después de haber leído este artículo





miércoles, 29 de julio de 2020

Spark: la oportunidad


¡Vivimos una explosión de datos! Cada vez más se requieren más personas que sepan analizar y modelar estos datos para obtener la información. El dato es útil. El dato de alta calidad, bien entendido y auditable, no tiene precio. En este artículo vamos a dar una pincelada sobre este entorno de trabajo, un diamante en bruto, llamado Spark.


Obtenemos datos de todos los medios, como Twitter feeds, Facebook, mensajes, SMS, y una gran variedad de medios.  La necesidad de poder procesar esos datos tan rápidamente como sea posible se convierte en más importante que nunca. 

Hace unos pocos años, la programación mediante MapReduce ha sido útil para estos fines, pero la cantidad de tiempo que se tarda en ejecutar los trabajos no es la más aceptable en la mayoría de las situaciones. La curva de aprendizaje para escribir un trabajo MapReduce también es difícil, ya que requiere conocimientos específicos de programación y el know-how. Además en MapReduce los trabajos sólo funcionan para un conjunto específico de casos de uso. Necesitamos algo que funcione para un gran conjunto de casos de uso.

Apache Spark fue diseñado como una plataforma de computación rápida, de uso general y fácil de usar, de ahí viene su nombre: chispa.

Extiende el modelo MapReduce y lo lleva a otro nivel. La velocidad proviene de los cálculos en memoria. 

Las aplicaciones que se ejecutan en un proceso y con una respuesta mucho más rápida. Spark es incluso más rápido que MapReduce para aplicaciones muy complejas usando los discos. Puede ejecutar la aplicación por lotes, o algoritmos iterativos que se basan unos sobre otros. 


Se pueden ejecutar consultas interactivas y procesar datos de flujos continuos con una aplicación. 
Soporta un número de bibliotecas que pueden utilizarse fácilmente, para expandirse más allá de las capacidades básicas de Spark, son:






La gran facilidad de uso de Spark nos permite aprender rápidamente usando los APIs simples para Scala, Python, R y JavaSpark se ejecuta en clústeres Hadoop con YARN  o Apache Mesos, o incluso de manera autónoma con su propio planificador


¿Por qué y para qué querríamos usar Spark?


Spark proporciona procesamiento distribuido paralelo, tolerancia a fallos en hardware de productos básicos, escalabilidad, etc...Añade el concepto de computación agresiva en caché de memoria distribuida, con baja latencia, APIs de alto nivel y pila de herramientas de alto nivel. 

Hay dos grupos que podemos considerar aquí que querrían usar SparkCientíficos de Datos e Ingenieros (Analistas de Datos).

 ¿Pero no son similares?

En cierto sentido, sí, tienen superposición de conjuntos de habilidades, pero para nuestro propósito, vamos a definir al científico de datos como aquellos que necesitan analizar y modelar los datos para obtener información. Tendrían técnicas para transformar los datos en algo que pueden utilizar para el análisis de datos. 
  • Su análisis ad-hoc.
  • Ejecutar consultas interactivas que les proporcionen resultados inmediatamente. 
Los Científicos de datos también tienen experiencia en el uso de SQL, estadísticas, aprendizaje automático y algo de programación, por lo general usando lenguajes como Python o R.

Una vez que los científicos de datos han obtenido la información sobre los datos; más tarde, alguien determina que hay una necesidad de desarrollar una aplicación de procesamiento de datos de producción, una aplicación web, o algún sistema, la persona llamada a trabajar en ello estarían los ingenieros (analistas de Datos).

Los ingenieros (analistas de datos) utilizarían la API de programación de Spark para desarrollar un sistema de casos de uso. Spark paraleliza estas aplicaciones a través de los clústeres mientras se ocultan las complejidades de la programación de los sistemas distribuidos y tolerancia a fallos.  Pueden usar Spark para monitorear, inspeccionar y ajustar las aplicaciones. 

Spark Core, componentes...


El núcleo de Spark (Core) está en el centro de todo. Es un sistema de propósito general que proporciona programación, distribución y supervisión de las aplicaciones a través de un grupo de componentes.

Los componentes en la parte superior del Spark Core que están diseñados para trabajar internamente, dejando que los usuarios los combinen, como lo harían con cualquier biblioteca en un software de proyecto. El beneficio de esta pila es que todos los componentes de la capa superior heredarán las mejoras realizadas en las capas inferiores. 

El Spark Core está diseñado para escalar de uno a miles de nodos. Proporciona la abstracción fundamental de Spark: Resilient Distributed DataSet (RDD):
  • Resilient (Flexible): si se pierden los datos en la memoria, se pueden volver a crear
  • Distribuido: procesado en todo el clúster 
  • DataSet (conjunto de datos): los datos iniciales pueden provenir de una fuente, como un archivo, o pueden ser creados mediante programación

Los RDD son anteriores a Spark SQL y al API de los DataFrame / Dataset.

Spark SQL está diseñado para trabajar con Spark a través de SQL y HiveQL e Impala. Spark SQL permite a los desarrolladores mezclar las consultas de SQL con el lenguaje de programación de Spark elegido: Python, Scala, R o Java. 

Funciona con datos estructurados


DataFrames y Datasets que son la abstracción de los datos estructurados. Posee además un entorno de optimización de las consultas: el Catalyst Optimizer

Spark Streaming proporciona acceso al proceso de flujos de datos en tiempo real. Su API coincide con el de Spark Core, lo que facilita a los desarrolladores moverse entre aplicaciones que procesan los datos almacenados en la memoria y/o llegar a ejecutarlos en tiempo real, proporcionando el mismo grado de tolerancia a fallos, rendimiento y escalabilidad que ofrece el Spark Core.

MLlib, la biblioteca de aprendizaje automático de máquina (Machine Learning), proporciona múltiples tipos de algoritmos que están diseñados para escalar a través del clúster.

GraphX es una biblioteca de procesamiento de gráficos (Graph Processing) con API para manipular gráficos y realizar gráficos computacionales en paralelo.

Los DataFrames y los DataSets son la representación principal de los datos en Spark.
  • Los DataFrames representan datos estructurados en forma de tabla. Son similares a las tablas en un RDBMS. Consisten en una colección de objetos Row (fila) sin escribir. Las filas se organizan en columnas descritas por un esquema. 
  • Los DataSets representan datos como una colección de objetos de un tipo específico. Están fuertemente tipados
  • Realmente un DataFrame es un alias de un Dataset [Row]: conjuntos de datos que contienen objetos Row (filas)
Cómo veis, el entorno de Spark no es difícil ni complicado, simplemente requiere perseverancia para familiarizarse con él y una vez conseguido estaréis en disposición de entrar en un mundo apasionante, desafiante y novedoso tecnológico. Espero que pongáis más de una chispa en vuestro camino.




¡Hasta el próximo post queridos lectores!





jueves, 23 de julio de 2020

Tecnologías Web 106

Visto en Tecnologías Web 105 como algunas tecnologías solucionaban el problema con el SEO de las SPAs, ahora vamos a comentar cuales son las que han aparecido estos últimos 2 años y las nuevas versiones que llegan de aquellas que ya existían y de las que hemos hablado en los anteriores posts.



Nuevas generaciones


En el año 2018, sale la versión 3 de Polymer, en la que como novedad, han cambiado una de sus especificaciones, HTML Imports deja de usarse a cambio de ES Modules después de que varias compañías entre las que se encuentra Mozilla se negara a implementar la primera especificación en su navegador.


El equipo encargado de desarrollar Polymer ha presentado LitElement, una clase de JavaScript con la que vamos a poder crear nuevos componentes que podremos usar en cualquier aplicación sin importar si se ha creado con React, Angular o cualquier otro framework. Esto es posible porque todo lo que usa LitElement son funcionalidades nativas de JavaScript. Y según parece este será el futuro de Polymer.



Este mismo año el creador de NodeJS, Ryan Dahl, publica su nuevo proyecto, Deno, que es el NodeJS que quería haber creado desde un principio. Deno es un entorno de ejecución de JavaScript y TypeScript. Aquí la primera diferencia respecto a Node, esta nueva herramienta soporta el código TypeScript de forma nativa, por tanto no vamos a tener que configurar nada para poder ejecutar el código TS, sino que Deno se encargará de todo. Otra diferencia respecto a Node y que llama mucho la atención es que no tiene un gestor de paquetes como NPM, sino que cuando vayamos a necesitar usar una dependencia en nuestro proyecto, solo tendremos que importarla desde la URL donde se encuentre publicada. ¿Superará Deno a Node? Supongo que lo iremos viendo con el tiempo, actualmente ya se está hablando de esta tecnología así que es cuestión de tiempo que lo veamos que pasa con ellas.

En 2019, sale una nueva versión de React, que trae como novedad los React Hooks, una serie de funciones para los componentes funcionales que nos permiten reutilizar lógica entre distintos componentes, además de que nos proporcionan funcionalidades que antes no se podían usar en este tipo de componentes (como añadir un estado o usar los métodos del ciclo de vida). Por supuesto también podemos crear nuestros propios Hooks, y ya existe algún repositorio en el que podemos encontrar una gran cantidad de ellos que ha ido creando la comunidad.

El futuro


Para terminar con esta serie de posts, en 2020, está pendiente de salir la versión 3 de Vue que va a traer su versión de los React Hooks, la Composition API, para permitir la reutilización de funcionalidad entre los componentes de una forma más sencilla a como se tenía que hacer hasta ahora, que es con los mixins. En cuanto a las otras novedades que trae, el paquete de Vue pesará menos y será más rápido, además de que tendrá un mejor soporte con TypeScript.


Durante este mismo año, también saldrá la nueva versión de Webpack (que al tiempo que escribo esto se encuentra en fase beta) que eliminará algunas de las funcionalidades que se habían deprecado, y traerá algunas nuevas como la caché persistente o mejoras como por ejemplo en el hashing. Una de las funcionalidades más llamativas es el module federation, un plugin que va a facilitar la creación de lo que se conoce como micro frontends, permitiendo compartir entre los distintos builds aquellas dependencias que tienen en común, entre otras cosas.




Y con esto hemos dado un repaso a la evolución de las tecnologías web desde los inicios hasta estos últimos años donde parece que no han salido tantas librerías y frameworks, pero es muy probable que estén ahí y necesiten ser encontradas.

Mientras tanto en otra parte del planeta:


Tecnologías Web 105

La web moderna.

En este penúltimo post veremos como empiezan a aparecer librerías y frameworks enfocados al frontend para el desarrollo de las SPAs, y como empiezan a salir algunas soluciones para enfrentarnos al principal problema que plantean este tipo de aplicaciones, el SEO. Pero si todavía no has leído el anterior post, deberías de leerlo primero, Tecnologías Web 104.


HTML nuevo, JS nuevo


Después de varios años sin novedades nuevas de HTML, en 2014 sacan HTML5 que trae consigo un conjunto de etiquetas nuevas (nav, header, footer, main...) que añaden un significado al contenido de estas y nos ayudan a reducir el uso de las etiquetas div, y otras como la etiquetas audio y video que permiten reproducir contenidos multimedia de forma nativa (algo que hasta ahora solo podíamos hacer con Flash).

Otra de las novedades más importantes de HTML5 son todas las APIs que traen y que nos van a permitir acceder a la cámara del dispositivo, a la ubicación, almacenar datos de forma local...

Este año, Evan You, un extrabajador de Google, publica Vue, un framework progresivo, lo que quiere decir que vamos a poder usarlo como si fuera una librería al estilo de React, o para cosas más complejas al igual que haríamos con Angular. Si ya tenemos un proyecto con cualquier tecnología y queremos pasarlo a Vue, podremos hacerlo de poco a poco ya que no es necesario tener una configuración compleja como ocurre con React o Angular que la necesitan para transpilar el JSX o el TS.

A mi parecer, Evan ha ido picoteando un poco de cada librería y framework existentes hasta este momento quedándose con lo mejor de cada uno para añadirlo a Vue. Y es por lo que ha recibido el apoyo de la comunidad y por lo que actualmente se ha posicionado como uno de los frameworks o librerías más usadas para el frontend.

No olvidemos que también han sacado un documental sobre Vue, al igual que hicieron en su momento con Ember.

Y llegamos al año 2015, el año en que sale una nueva versión del estándar de JavaScript, EcmaScript 6.

ES6 es una de las versiones más importantes de JavaScript hasta la fecha, debido a todas las novedades que trae consigo. Entre las novedades nos encontramos algunas como las arrow functions, las promesas, las dos nuevas formas de declarar variables o la sintaxis para declarar clases más parecida a como se hace en otros lenguajes.

Por otro lado, Dan Abramov inspirado por el patrón Flux que recomienda usar Facebook para gestionar el estado en las aplicaciones de React, publica Redux, una librería muy sencilla que aunque parece que se asocia solo a React, también se puede usar con cualquier otra librería o framework sin ningún problema.

Con Redux vamos a tener todo el estado en un único sitio, que solo se va a poder modificar a través de unas funciones llamadas reducers a las que se le mandan acciones que indican el cambio que hay que realizar sobre el estado.


Yendo a lo nativo


Siguiendo con el ecosistema de React, este año se presenta React Native, una librería construida sobre React, y que permite construir aplicaciones móviles nativas para Android e iOS usando unos componentes predefinidos que trae la librería. Usan un elemento al que se refieren como Bridge que se encarga de realizar la comunicación entre la parte de JavaScript y la parte nativa. React Native va mandando mensajes que describen la acción que hay que ejecutar, y la parte nativa la ejecuta

Este mismo año, Facebook se encuentra con el problema de que tienen que desarrollar su aplicación móvil de forma nativa y la API para traer los datos que necesitan en el feed no les sirve porque es una interfaz muy compleja en la que hay que mostrar muchos datos. Entonces surge la idea de GraphQL,  un lenguaje de consultas con el que consiguen traer los datos que necesitan con una sola petición, en lugar de tener que realizar varias peticiones como se venía haciendo.

Y esta es otra de las herramientas sobre las que podemos encontrar un documental.

Por último, este año, aparece Polymer, una librería de JavaScript para crear aplicaciones web mediante el uso de componentes. Al principio había unos pocos componentes básicos que proveían de una funcionalidad genérica que sirve para la mayor parte de las aplicaciones, pero han ido añadiendo nuevos componentes según han ido saliendo las nuevas versiones. Es una librería que siempre ha ido de la mano de las especificaciones que definen los Web Components.

Durante el 2016 el equipo de Google presenta Angular 2 en una conferencia, causando un gran revuelo entre la comunidad ya que habían rediseñado el framework por completo. En esta versión han decidido apostar por TypeScript como lenguaje de programación, han cambiado la sintaxis de las directivas, y lo que en la antigua versión eran los controladores, ahora son los componentes.

Desde entonces han ido sacando distintas versiones de Angular, aproximadamente una cada 6 meses, pero ninguna con grandes cambios como de AngularJS a Angular 2 (de momento).

Sobre el ecosistema de Vue aparecen dos herramientas nuevas.

De SPA a universal


Una de ellas es Nuxt, un framework construido sobre Vue que nos permite crear aplicaciones de una forma muy rápida ya que no nos tenemos que preocupar por configurar casi nada. Cuando digo casi nada, me refiero a que ni siquiera tendremos que configurar el router, ya que el va a ir generando las rutas a partir de los archivos y carpetas que añadamos dentro de la carpeta pages, tampoco Vuex, ni .

Pero no solo esto, lo mejor de Nuxt (a mi parecer) es que podemos hacer que nuestra aplicación sea una SPA, realice el primer renderizado en el servidor (mejorando el SEO) o genere archivos HTML estáticos a partir de las rutas que tenga nuestra aplicación, y todo ello de una forma muy sencilla.

Además también hay que decir que tiene una lista increíble de módulos que añaden cierta funcionalidad a nuestra aplicación y por tanto nos simplifican el trabajo evitando que tengamos que configurar otras cosas que no trae por defecto, como por ejemplo alguna librería de componentes.

Y por otro lado, surge Vuex que es el gestor de estado para las aplicaciones de Vue. Esta librería se basa en Redux y por tanto en el patrón Flux, pero está diseñada para usarla solo con Vue al contrario de lo que ocurre con Redux. En este caso, los elementos con los que nos encontramos son las acciones que se despachan desde la vista y en las que vamos a realizar las operaciones asíncronas, después tenemos las mutaciones que se encargan de realizar el cambio en el estado, y los getters que nos devuelven parte del estado para usarlo en las vistas.

En 2017 surge un nuevo competidor para aquellas tecnologías como React Native o Ionic que nos permiten crear aplicaciones nativas e híbridas usando los lenguajes propios de la web, es decir, HTML, CSS y JS. Flutter nos va a permitir crear aplicaciones nativas para Android e iOS mejorando considerablemente el rendimiento ya que estas aplicaciones construidas con Dart se van a compilar usando librerías de C a código máquina.

Las otras tecnologías a nombrar este año son Next y Angular Universal. Donde Next es la alternativa a Nuxt para la librería de React, mientras que Angular Universal solo permite realizar el primer renderizado de las aplicaciones de Angular en el servidor.

Terminamos este post aquí, dejando para el siguiente aquellas tecnologías que han salido durante los últimos dos años y las nuevas versiones de algunas de las que ya hemos hablado en esta serie de posts. No os perdáis Tecnologías Web 106.







viernes, 26 de junio de 2020

Tecnologías Web 104

Multiplataformas

Pues ya ha llegado el nuevo post de Tecnologías Web, espero que os estén gustando y hayáis visto como han ido evolucionando y apareciendo tecnologías para facilitar el desarrollo de la web. ¿Cómo, que no habéis leido los anteriores? Pues podéis empezar por el principio leyendo Tecnologías Web 101, o si sois de los que empezáis la casa por el tejado empezad por el anterior, Tecnologías Web 103.

Durante este cuarto post, contaremos como con la llegada de los smartphones empiezan a surgir aquellos frameworks que permiten desarrollar para múltiples plataformas y dispositivos, además de comentar cual es la librería JavaScript más usada hoy en día para el desarrollo frontend.




Aplicaciones híbridas


Desde la llegada del iPhone en 2007, como hemos comentado en anteriores posts, los dispositivos móviles pasan a ser un medio a través del que consumir información de internet, usar aplicaciones... Y este año, varias de las tecnologías que aparecen van enfocadas a estos dispositivos.

Para empezar, se empieza a hablar del Reponsive Web Design, una técnica por la que vamos a hacer que las aplicaciones web se puedan adaptar a los distintos dispositivos independientemente de su tamaño, es decir, podremos hacer que nuestra aplicación se vea bien en un móvil, una tablet, un portátil... Esto lo vamos a conseguir usando las media queries de CSS para aplicar unas propiedades u otras dependiendo de los distintos tamaños de pantallas, y aplicando otras tecnologías como Flexbox.


También surgen Ionic y PhoneGap (más tarde se le cambió el nombre a Apache Cordova) que nos permiten desarrollar aplicaciones móviles (híbridas) usando los tres principales lenguajes de la web (HTML, CSS y JS).

PhoneGap nos proporciona acceso al hardware de los dispositivos como a la cámara, el acelerómetro, la ubicación, y coge todo nuestro código y lo embebe dentro de un WebView.

Por su parte, Ionic se construye sobre PhoneGap y AngularJS, permitiendo construir las aplicaciones de la misma forma que con PhoneGap, pero cambiando la forma de desarrollar, por aquella que se sigue con AngularJS.

Por otro lado, de la misma forma que podemos desarrollar aplicaciones móviles usando los lenguajes de la web, aparece Electron, de la mano de Github, que nos proporciona un entorno para crear aplicaciones de escritorio multiplataforma. Al igual que las dos herramientas comentadas antes, lo que Electron va a hacer, es encapsular una aplicación web dentro de un contenedor, haciendo que esta tenga un aspecto nativo. Abrir una aplicación hecha con Electron, sería como abrir la aplicación en un navegador Chrome, ya que esta herramienta usa como motor, Chromium.

Todas estas tecnologías suponen una gran ventaja frente a las nativas, ya que no es necesario tener distintos equipos para desarrollar estas aplicaciones, uno que se encargue de desarrollar para los dispositivos de Apple, otro para los dispositivos de Android... sino que con un solo equipo que conozca alguna de las herramientas que acabamos de comentar podría hacer una única aplicación que funcione en todos estos dispositivos (pero cuidado que no todo son ventajas). Entre las desventajas tenemos el rendimiento de las aplicaciones, pues el de las nativas superan al de las híbridas.

En cuanto al tema de estilos en la web, este año se crea PostCSS, una herramienta de JavaScript que se encarga de modificar nuestro código CSS aplicando plugins sobre él. Usando estos plugins podremos empezar a usar funcionalidades como las que ya nos proporcionaban los preprocesadores (funciones, mixins...), podremos aplicar los prefijos automáticamente a aquellas propiedades que los necesiten, se puede eliminar el código que no se usa para dejar los archivos con un menor tamaño...

Hay muchos plugins para PostCSS y los han separado en distintas secciones en función de las modificaciones que van a realizar sobre nuestro código.

Una nueva forma de pensar


Por último, este año, Facebook publica la librería de React. Una librería encargada de la parte de las interfaces de usuario (desarrollando componentes) y con la que podemos crear SPAs. Esta librería surge básicamente porque en Facebook necesitaban una herramienta que ofreciera un mejor rendimiento que las que había en esta época. Para ellos el Two Way Binding que se venía usando en algunas librerías que hemos comentado anteriormente no era lo suficientemente óptimo, por lo que se ha apostado por un flujo de datos unidireccional.

Esta librería introduce conceptos nuevos como el Virtual DOM, una representación del DOM en memoria sobre el que se van a aplicar los cambios para ver a que componentes afectan y renderizar solo aquellos componentes afectados, en lugar de tener que volver a renderizar toda la aplicación cada vez que cambia algo.


Otra de las novedades es la sintaxis que hay que usar para crear los componentes. Esta sintaxis también fue creada por Facebook y es JSX, en la que vamos a definir la estructura de los componentes usando código HTML dentro del JavaScript, algo que parece no gustar a los desarrolladores la primera vez que lo ven, pero que acaban cogiéndole cariño en cuanto le dan una oportunidad.

A día de hoy, esta librería es la más usada en el desarrollo web, habiendo superado a Angular que era la que tenía el primer puesto no hace tanto. Además, si ya teníamos el MEAN Stack, con React aparece el MERN Stack donde se sustituye Angular como framework para las vistas por React.

Y hasta aquí este post. No olvidéis pasaros por el siguiente, Tecnologías Web 105, en el que veremos las herramientas presentadas en los últimos seis años y alguna que está por salir.


jueves, 18 de junio de 2020

Inteligencia Articial con Azure Cognitive Services

Estamos viviendo una época de continuos cambios y transformaciones en el mundo de las tecnologías de la información.

En los tiempos que nos ha tocado vivir, tenemos que dedicar una especial atención al ámbito de la inteligencia artificial, I.A, ya que estamos en los albores de una gran revolución tecnológica que cambiará el mundo.

Hoy vamos a hablar sobre los servicios que el gigante Microsoft nos ofrece en su nube de servicios, la sección denominada como Azure Cognitive Services.


¿Qué base necesito para poder adentrarme en el mundillo de la I.A?

Azure Cognitive Services, trata de hacer accesible la inteligencia artificial, de forma que esté al alcance de todos los desarrolladores, sin que se requiera un gran bagaje en el ámbito del aprendizaje automático.

Muchas veces nos ocurre que cuando queremos adentrarnos en el mundo de la I.A, nos echa atrás la gran cantidad de buenas bases de conocimiento que debemos de tener, en áreas como matemáticas, física, cálculo, etc.

Mediante el uso de estos servicios de Azure, bastará con hacer una llamada API para incorporar capacidades en nuestras aplicaciones como:
  • Ver
  • Escuchar
  • Hablar
  • Buscar
  • Comprender

En definitiva, se trata de acelerar la toma de decisiones en nuestros sistemas con potentes características que el servicio nos ofrece.

Dependiendo de las características con las que queramos dotar a nuestras aplicaciones, el servicio de Azure Cognitive Services ha agrupado las diferentes API's que se encuentran disponibles en diferentes temáticas. Para dar de alta cualquier API que nos interese, lo podemos hacer directamente desde el propio portal de Microsoft Azure

Podemos contratar cualquier servicio de una API cognitiva específica como cualquier otro servicio de Azure.

¿Cuáles son las API's que Azure Cognitive Services nos proporciona?

Vamos a citar las diferentes temáticas de las que disponemos así como citar algunas de las características de las mismas, para que nos hagamos una idea de lo potente que puede llegar a ser incorporar en nuestras aplicaciones estas funcionalidades.

  • API de visión


    • Creación de clasificadores personalizados de imágenes.
    • Algoritmos faciales avanzados, lo que permite la detección y el reconocimiento de atributos faciales.
    • Acceso a algoritmos avanzados para procesar imágenes y devolver información de un vídeo.
    • Extracción de información de un vídeo.
  • API de Voz
    • Agrega a las aplicaciones características habilitadas por voz.
    • Proporciona algoritmos para la identificación y verificación del hablante
    • Detección en tiempo real del idioma del hablante, y traducción simultánea al idioma que deseemos 
      (Traducción en streaming)

  • API de Idioma
    • Servicio LUIS (Language Understanding), que permite que la aplicación entienda lo que una persona quiere decir en sus propias palabras.
    • Herramienta QnA Maker, que nos va a permitir generar un servicio de preguntas y respuestas a partir de contenido semiestructurado.
    • Base de datos de conocimiento inteligente.
    • Procesamiento de lenguaje natural en texto sin formato para el análisis de opiniones, la extracción de frases clave y la detección de idiomas.
  • API de Búsqueda
    • Servicios de búsqueda de temática basada en el buscador Bing.
    • Bing News Search, devuelve una lista de artículos de noticias cuya relevancia se ha determinado para la consulta del usuario.
    • Bing Video Search devuelve una lista de vídeos cuya relevancia se ha determinado para la consulta del usuario.
    • Bing Spell Check permite realizar correcciones de gramática y ortografía en contexto.
  • API de Decisión
    • Nos permite supervisar y detectar anomalías en datos de series temporales. 
    • Supervisión de posibles contenidos ofensivos, indeseables y peligrosos.
    • Posibilidad de elegir la mejor experiencia para mostrar a los usuarios y aprender de su comportamiento en tiempo real.



Podemos encontrar documentación detallada de cada API en la documentación oficial de Microsoft

¿Qué podríamos realizar con aplicaciones que utilizaran dichos servicios?

El abanico de posibilidades que se nos abre de una forma relativamente fácil y accesible es inmensa:
  • Realización de un bot que gestione en tiempo real pedidos de comida de un restaurante, que se encargue de anotar el pedido, la dirección y la cantidad de productos.
  • Servicios de gestión de reservas en todo tipo de servicios, como vuelos, hoteles, etc.
  • En el ámbito de la robótica, robots que sean capaces de recolectar frutos, analizando el punto óptimo de maduración de la fruta, en base al análisis de imágenes en tiempo real.
  • Sistemas de seguridad en aeropuertos y aduanas, de forma que sean capaces de identificar a personas mediante el uso de técnicas de reconocimiento facial.
  • También relacionado con el ámbito de la seguridad, el análisis de carreteras/vehículos, tanto para la detección de un robo, como para predicciones de colapso de las vías y llevar a cabo toma de decisiones de forma temprana.
Sin duda, vivimos momentos apasionantes, momentos de cambio, donde el poder de la imaginación será algo  fundamental que nos hará reinventarnos y cambiar la forma en la que nos desenvolvemos en nuestro entorno.

Desaparecerán profesiones y se crearán otras nuevas, sustituiremos las labores repetitivas y aburridas por tareas que de verdad nos aporten crecimiento personal y productividad.

Si te atreves a imaginar una idea... ¡Puedes Hacerla Realidad!







miércoles, 10 de junio de 2020

Tecnologías web 103

Más frameworks, ahora para CSS también

Llegamos al ecuador de nuestra serie de posts sobre las tecnologías web, ya hemos visto en el primer post Tecnologías Web 101 los inicios de la web, y en el segundo, Tecnologías Web 102, vimos como empiezan a aparecer los primeros frameworks tanto del backend como del frontend.

Pues como no hay dos sin tres, aquí está el tercer post donde veremos como aparecen los primeros frameworks del CSS, la llegada de los componentes web, hasta llegar a la estandarización de un formato que ya se venía usando.


Diseños flexibles


El año 2011 fue el año del CSS. En este año salió CSS3 que traía novedades en el sistema de layout de las páginas. Aparecen Flexbox y Grid Layout que nos permiten crear plantillas flexibles y definir filas y columnas de una forma sencilla reduciendo el uso de la propiedad float que tanta guerra ha dado, y favoreciendo el diseño responsive de las aplicaciones.

A parte de CSS3, también empiezan a salir los frameworks de estilos como Bootstrap (de Twitter) y Foundation (de Zurb) que nos proporcionan una cantidad muy grande de estilos asociados a unas clases predefinidas y que nos hará muy fácil cambiar la apariencia de nuestras aplicaciones. También definen un sistema de columnas que van a facilitar hacer que las aplicaciones se adapten a los distintos tipos de dispositivos.

Uno para todos y todos para uno


Este mismo año Alex Russell introduce los Web Components en la comunidad, una idea influenciada por las directivas de AngularJS que va a permitir la creación de nuevas etiquetas HTML con una estructura y funcionalidad definida y que se pueden reutilizar entre distintas aplicaciones de una forma sencilla.


Por otro lado Google presenta un nuevo lenguaje para la web como alternativa a JavaScript que se viene usando desde los inicios, este lenguaje es Dart, y está pensado para solucionar algunos de los problemas que nos podemos encontrar con JS. Pero no tuvo una fuerte acogida por parte de los desarrolladores que preferían seguir usando JavaScript, y por ello se desecharon los planes que tenía Google para integrar de forma nativa en su navegador una máquina virtual para ejecutar el código y los cambiaron por crear una herramienta para compilar Dart a JavaScript.

Además surgen otros dos framework.

EmberJS para el frontend, permitiéndonos hacer SPAs, donde dos de sus principales características son las que se siguen con Ruby on Rails, COC y DRY. También incorpora un cli que va a hacer que la productividad aumente proporcionando una forma sencilla y rápida para generar servicios, instalar plugins... Y con el podíamos usar las últimas novedades de JavaScript haciendo uso de Babel para transpilar el código. De este framework se ha llegado incluso a grabar un documental.

En cuanto al otro framework, es Laravel, un framework de PHP. En la actualidad es uno de los frameworks de PHP más usados, junto a Symfony mencionado anteriormente. Viene a proporcionarnos un método sencillo y rápido de construir aplicaciones web, en el que la curva de aprendizaje es muy cómoda.



Durante el siguiente año, Microsoft presenta un nuevo lenguaje de programación basado construido sobre JavaScript, el cual nos va a permitir usar características comunes en otros lenguajes y que JavaScript no permite, como el tipado estático o las interfaces. Este nuevo lenguaje es TypeScript, y vamos a poder usarlo tanto para el cliente como para el servidor, aunque en realidad el código final que se va a ejecutar en estos entornos será JavaScript. Por tanto, necesitamos transpilar el código de TS para obtener el código equivalente en JS.


La ventaja de usar TypeScript frente a JavaScript es que a la hora de transpilar el código se nos van a mostrar errores, sobre todo errores de tipado, de tal forma que nuestro código final será más robusto.



Este mismo año, surge un framework web fullstack llamado Meteor que permite crear aplicaciones web, móviles y de escritorio, de una forma muy rápida. Por defecto, como BBDD usa MongoDB, el servidor está montado con Node y para el frontend al principio usaba Blaze como motor de plantillas, pero según han ido apareciendo nuevas librerías han ido añadiendo más opciones como React o Vue. Pero una de las novedades más importantes que trae este framework es la actualización de los datos en tiempo real, es decir, que si abres la misma página desde distintos dispositivos y se añade algún dato nuevo, este aparecerá en todos los dispositivos automáticamente sin necesidad de refrescar la página.

Tras la aparición de frameworks como AngularJS o Backbone que nos permiten crear SPAs y el uso de los dispositivos móviles para entrar en las aplicaciones web, nos encontramos con que tenemos la aplicación dividida en varios archivos que se tienen que descargar, y cuantos más archivos que descargar haya, más peticiones hay que hacer, con lo que ello conlleva.

Aquí es donde entra Webpack, un module bundler que nos permite gestionar todos los recursos que se van a usar en la aplicación. Webpack va a ir aplicando unos loaders a nuestro código que lo va a ir transformando y uniendo hasta generar los archivos finales (un bundle.js). Por ejemplo, si estamos usando Sass, tendremos que transformar el código a CSS y para ello tendremos que aplicar el loader que se encarga de ello. También se encarga de minimizar el código, haciendo que los archivos que genera ocupen el menor espacio posible.



Para el año 2013 se estandariza el formato JSON que Douglas Crockford había especificado anteriormente. Este formato va a empezar a usarse junto a AJAX por sus ventajas, haciendo que los datos que se van a transferir pesen menos, por lo tanto tarden menos en comunicarse el servidor y el cliente, haciendo que la experiencia del usuario mejore. Los desarrolladores terminarán sustituyendo al XML por JSON en las peticiones AJAX.


Aquí terminamos por hoy. En el siguiente post, Tecnologías Web 104,  veremos como la llegada del iPhone hace que se empiece a pensar en el desarrollo responsive, y el desarrollo multiplataforma.