Angular decidió lanzar el día 11 del mes 11 su última versión major del framework, la número 11 (las casualidades no existen 😁). En esta versión han dado una idea de cuál es su actual foco y probablemente el de varias versiones posteriores, otorgando una gran importancia a la estabilidad y al ecosistema por encima de nuevas funcionalidades, algo por otro lado muy necesario.

Como siempre, antes de entrar en detalle, recordemos qué significa que Angular haya sacado su nueva versión major siguiendo el versionado semántico:

• Versión major: se esperan cambios que puedan romper antiguas versiones y es probable que se requieran ciertos pasos (manuales o automáticos) para actualizar la aplicación.
• Versión minor: se pueden introducir pequeñas novedades, pero siempre con retrocompatibilidad con versiones anteriores.
• Versión patch: básicamente introducen soluciones a bugs conocidos.

Si bien esta versión de Angular no contiene tantos cambios sobre los que haya que hacer migración, como pudimos tener por ejemplo con Angular 9, ng update nos hará el trabajo más llevadero en ese sentido. Este comando nos permitirá realizar la migración de nuestra aplicación sin apenas esfuerzo.

Operación Byelog

Cómo mencioné al inicio del post, el principal foco de la versión 11 ha sido mejorar la estabilidad del ecosistema, un proceso al que en Angular llaman “Operación Byelog”. Este proceso consiste en aumentar los recursos destinados por Angular en sus tres monorepos con el objetivo de cerrar issues y mezclar Pull Requests (PR) que son importantes para la comunidad.

Esto es algo muy interesante porque, a finales de noviembre y principios de diciembre de 2020, tan solo el repositorio principal de Angular ya cuenta con alrededor de 2.500 issues abiertas y 400 PR pendientes de ser revisados 😱:

La Operación Byelog pretende, no sólo ir mejorando estas estadísticas, sino que cada vez que se abra un issueéste pueda ser resuelto en un plazo máximo de dos semanas (un esfuerzo para nada desdeñable con el volumen que manejan). Y como parte de este esfuerzo Angular ha publicado este roadmap en su web para poder estar informados de sus actuales prioridades, y en qué partes del framework están poniendo el foco en cada momento.

Conversión de tipografías externas a recursos en línea

Angular 11 introduce la automatización en el proceso de compilación de tus tipografías, que se convierten por defecto en recursos en línea. Esto consiste en que, durante el proceso de compilación, se descargan las fuentes tipográficas que uses en tu aplicación, y se añaden dentro de una etiqueta style, lo que permite cargarla más rápido después, sin tener que esperar a parsear primero el CSS devuelto y luego comenzar la descarga de los recursos asociados.

El principal beneficiado de este proceso es el SEO ya que mejora notablemente el tiempo del primer pintado. Para aquellos desarrolladores que se han preocupado en todo momento de los web vitals o las estadísticas en lighthouse de su aplicación, esta funcionalidad quizás no les aporte demasiado ya que tendrán solucionado este problema usando otros métodos, pero siempre está bien para futuras situaciones que Angular lo proporcione automáticamente sin necesidad de que hagamos nada.

Mejoras en el entorno de desarrollo

La nueva versión de angular introduce dos nuevas mejoras respecto a nuestra experiencia de desarrollo mientras programamos con el framework:

Mejora en el logging

Ahora, durante el proceso de compilado, Angular nos informará de mejor forma la información del estado de la aplicación, para que sea más fácil de leer:

HMR

Desde mi punto de vista, la introducción del reemplazo de módulos en caliente (o hot module replacement) es, sin duda alguna, la funcionalidad del momento en Angular. Esta nueva mejora permite cargar automáticamente en los componentes los cambios que hagamos al desarrollar, tanto de estilos como de lógica, sin necesidad de recargar la página (en "caliente"), lo que mejora considerablemente tanto la inversión de tiempo como la experiencia de desarrollo mientras programamos.

La puedes activar simplemente lanzando el servidor de desarrollo con la opción --hmr:

ng serve --hmr

TypeScript y TSLint

Como en la mayoría de versiones de Angular, cada vez que se actualiza la major se actualiza también la versión de TypeScript. El motivo es que, al contrario que Angular, TS no sigue el versionado semántico, sino que cada versión del lenguaje puede introducir cambios que necesiten de alguna migración en tu código y, esto para Angular, sólo se puede hacer en una major, como hemos visto al principio.

En el caso de Angular 11 la versión de TypeScript que usa es la 4.0.

En la versión anterior Angular hacía uso de TSLint, como linter por defecto para código TypeScript. Se ha sabido que esta herramienta va a dejar de mantenerse, así que para Angular 11 han decidido migrar a ESLint, tal y como recomendaban los maintainers de TSLint en la issue correspondiente. Por ello, si no has necesitado nunca añadir modificaciones en la configuración por defecto de TSLint, probablemente te espere una migración sencilla. Por el contrario, si tu configuración es muy a medida, no te quedará otra opción que informarte sobre dicha migración (en el issue tienes bastantes datos al respecto):

Una última cosa sobre este apartado: desde Angular 10 han ido mejorando los tipos que usan en el framework. Con el cambio de linter se mejora también la integración entre ellos, permitiendo (siempre y cuando se active esta opción a la hora de ejecutar ng new) una mejor detección de errores de tipado y de posibles fallos. Esta mejora se debe en parte al motor de renderizado Ivy, aparecido en la versión 9, que permite conectar correctamente la lógica y analizarla teniendo en cuenta la template del componente. Pero aún queda camino por recorrer ya que todavía quedan ciertas partes del framework que utilizan ViewEngine, el anterior motor de renderizado.

Webpack 5

La nueva versión de Webpack salió unos pocos días antes que la de Angular y se puede usar de forma experimental en el framework añadiendo simplemente el siguiente código en el archivo package.json:

"resolutions": {

_ "webpack": "5.4.0"_

}

Seguramente el principal motivo por el que no lo han añadido de forma definitiva es porque la nueva versión de Webpack, aunque introduce muchas mejoras, también introduce varios cambios de compatibilidad con la versión anterior. Uno de los más problemáticos es la desaparición de los polyfills automáticos para navegadores antiguos (esencialmente Internet Explorer).

Servicio de lenguaje

El servicio de lenguaje de Angular es el encargado de recomendarnos todas esas buenas prácticas y advertencias de posibles errores mientras escribimos nuestro código. En esta versión Angular ha introducido ciertas mejoras descriptivas, aunque este servicio aún funciona sobre ViewEngine, el antiguo motor pre-Ivy. En principio se espera su desaparición o más bien migración a Ivy en futuras versiones, lo que nos permitirá inferir tipos entre nuestro código y el template:

En resumen

Angular continúa con su proceso de mejora interno, lo que a nosotros como desarrolladores nos viene estupendamente, ya que se espera que le den algo más de "cariño" a los repositorios en las próximas versiones. Y sobre todo una mejor experiencia de desarrollo, algo en lo que parece que ya llevan un tiempo enfocándose y es de agradecer.

Para versiones futuras cabe esperarse aún más mejoras relacionadas con los tipos, y también una reducción considerable en el número de problemas o mejoras pendientes que hay en GitHub.

Y por supuesto, el curso de Angular de CampusMVP ya está actualizado con esta nueva versión.

Todo empezó hace unos días. Enterrado entre las notas de la próxima versión 1.20 de Kubernetes, sus desarrolladores anunciaban que el orquestador de contenedores que todo el mundo utiliza, iba a "declarar Docker como obsoleto en su plataforma, para eliminarlo en una versión posterior". 

Los gritos se escucharon por toda Internet: ¿Qué pasa con este anuncio? ¿Está Docker obsoleto? ¿Deberíamos dejar de usarlo? ¿Qué le pasa a toda la inversión que he hecho en Docker y Kubernetes? ¡Socorro! 😱

Relájate. El impacto de este anuncio es mínimo y seguramente ni siquiera te va a impactar. Te lo explicamos a continuación.

Lo primero: distinguir entre qué es Docker, qué hace y qué tiene por debajo

El primer personaje relevante en empezar a poner las cosas claras fue Kelsey Hightower, el conocido evangelista y profesor de la plataforma cloud de Google con un tuit en el que recordaba una cosa importante:

Docker != Contenedores

Existen las imágenes de contenedores. Docker las puede crear.
Existen registros de imágenes. Docker puede hacer push y pull hacia estos.
Existen los procesos de contenedores. Docker los puede crear pero Linux es el que manda.

Hasta la propia Kubernetes lanzó un post en su blog titulado "Don't Panic: Kubernetes and Docker", para llamar a la calma. En él explican lo que ocurre realmente: de momento marcan como obsoleto el kubelet en el módulo Dockershim, que implementa el soporte para Docker como runtime de contenedores, para posteriormente eliminarlo.

Pero como trataba de explicar el tuit mencionado antes, esto no significa gran cosa. Veamos por qué.

Docker es muchas cosas: una pila tecnológica completa para manejar contenedores e imágenes, con multitud de herramientas y utilidades, sobre todo pensadas para desarrolladores. Pero Kubernetes no necesita la mayor parte de lo que ofrece Docker. Sólo una pequeña fracción: el runtime, es decir, el que es capaz de "levantar" las imágenes y ponerlas en marcha. Lo que hace Dockershim es realmente quitar de Docker todo lo que Kubernetes no necesita y quedarse con el runtime, porque añade dificultades, mantenimiento y posibles problemas de seguridad.

Y si Kubernetes solo necesita un runtime y Docker no le vale de entrada. ¿Cuál sería el runtime que deberíamos utilizar?

Bueno, pues en la actualidad los dos principales runtimes, los que más se utilizan, son containerd y CRI-O, ambos compatibles con la interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes. Docker en sí no soportaba la CRI de Kubernetes, de ahí el problema y la necesidad del shim, pero su runtime ligero de código abierto, runc, es lo que tienen por debajo tanto containerd como CRI-O. Es más, Docker junto a Google y a IBM, crearon el proyecto containerd usando runc en 2016, precisamente con el objetivo de lograr esta transición que llegará el año que viene, como explican en su propio artículo oficialmente.

Entonces, ¿qué es lo que ocurre finalmente y cómo me afecta?

Pues lo que ocurre es que en la versión 1.20 de Docker verás un aviso en el kubelet si usas Docker como runtime. Nada más. Todo seguirá igual.

Pero para Docker 1.23, que saldrá a finales de 2021, Docker no se soportará como runtime directo. En lo único que te afectará es que tendrás que elegir entre containerd y CRI-O como runtime (entre otros) para ejecutar tus contenedores en Kubernetes. Ambos usan por debajo runc, el runtime de Docker, por lo que todo funcionará sin problema y podrás seguir utilizando Docker como hasta ahora para desarrollar y probar fuera de Kubernetes. Las imágenes que crees con Docker seguirán funcionando en tu clúster de Kubernetes, propio o en la nube, de la misma manera que hasta ahora, solo que sin la sobrecarga de tener que quitar "lo que sobra" de Docker.

Hay todo un FAQ sobre esto de todos modos.

Si trabajas con Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) o Amazon Elastic Kubernetes Service (EKS), simplemente tendrás que asegurarte de que, antes de la versión 1.23, tienes elegido como runtime uno de los compatibles.

Quizá si haces cosas muy avanzadas que dependen mucho de Docker puedas tener algún problema y tendrás que trabajarlo, pero entonces no te preocupará este anuncio porque entiendes perfectamente las implicaciones. Para los demás, el impacto es mínimo y de hecho incluso beneficioso.

En resumen: relájate. Docker no se ha vuelto algo inútil de repente ni vas a tener que aprender nada nuevo.

Una de las novedades más interesantes de Blazor 5, aparecido con .NET 5, es la posibilidad de virtualizar listas.

En las aplicaciones web suele ocurrir que tenemos un listado o una rejilla muy grandes, con muchos datos. Dado que la información debe moverse entre el servidor y el cliente (el navegador), si hay muchos datos puede suponer que la pantalla que muestra la información tarde mucho en responder y, por lo tanto, baje la usabilidad y la satisfacción de los usuarios.

La solución a estas situaciones es llevar al lado cliente tan solo la información que hace falta en cada momento, es decir, la que está visible, pero no toda. Esto es más fácil decirlo que hacerlo, ya que lograr algo así y que no se note desde el punto de vista del usuario implica hacer muchos malabarismos y, dependiendo de la técnica elegida, puede resultar muy complejo.

O al menos hasta la aparición de Blazor 5.

Con Blazor 5 o posterior tenemos una manera muy simple y rápida de conseguir virtualizar las listas: el control <Virtualize>. Gracias a este, en lugar de tener que cargar todo el contenido de los listados, conseguiremos que se cargue tan solo lo que se está visualizando en cada momento (y un poquito más, por lograr agilidad) y, además, sin que se note puesto que el listado o rejilla tendrá el mismo tamaño que si estuvieran todos los datos cargados. A medida que el usuario hace "scroll" por la página se irán cargando los nuevos datos en segundo plano cuando sea necesario visualizarlos. Todo esto de manera transparente para el usuario y el programador. Una maravilla, vamos. Ganaremos en rendimiento y los usuarios disfrutarán de una gran experiencia de usuario.

En el siguiente vídeo te cuento cómo hacerlo y verás claramente la diferencia de funcionamiento que tiene por debajo una lista enorme y otra virtualizada.

Te dejo también el código de ejemplo (244Kb) que he utilizado, en el que están la página original (/Pages/ListadoSinVirtualizar.razor) y la virtualizada (/Pages/Listado.razor), para que puedas usarlas una al lado de la otra.

[youtube:sG5rQgP76Tw]

¡Espero que te parezca útil!

Como todos los años en diciembre, Atomico publica un informe sobre el estado de la tecnología en Europa y este año ha sido más extenso que en ocasiones anteriores. En el enlace anterior puedes leer el informe completo. Si te parece muy denso, encontrarás un resumen muy interesante de los puntos clave en esta página (en inglés) y si eso te sigue abrumando quédate con nosotros pues puede que esto te interese, ya que de todos los puntos cubiertos por este informe (inversiones, startups, diversidad, …) nos centraremos en el consideramos que os puede importar más a la mayoría de vosotros, esto es: el mercado laboral.

A continuación veremos qué dice el informe de Atomico sobre cómo ha impactado la covid-19 en el mercado laboral europeo de tecnología.

Antes de seguir conviene destacar que todos los datos usados en el informe de Atomico para conocer las tendencias laborales en Europa han sido aportados por el famoso portal Indeed y que todos los gráficos usados en este artículos han sido descargados directamente desde su informe.

1. El empleo, ¿se ha creado más empleo o se ha destruido?

Para obtener un patrón de contratación en tecnología, es decir, para saber si se está creando o destruyendo empleo en este sector, Indeed compara la cantidad de ofertas de trabajo de tecnología abiertas cada mes con el total de ofertas de trabajo en un país.

España es el país donde más creció el empleo en tecnología en 2020.

Los datos indican que la covid-19 no ha afectado por igual a todas las regiones de Europa, siendo las regiones del sur de Europa las más favorecidas en lo que respecta al trabajo tecnológico. De hecho, tanto en España como en Portugal, el número de ofertas de empleo en tecnología se disparó enormemente en relación con los empleos no tecnológicos a partir de marzo. En otros países, como Suecia, Dinamarca y, en particular, los EE. UU., los puestos de tecnología disminuyeron en relación con el mercado laboral en general.

También son notables las variaciones entre países en lo que se refiere a la evolución de puestos de trabajo durante el verano y la segunda mitad de 2020. Si bien en algunos países el número puestos de tecnología frente al total se mantuvo en niveles elevados, en otros, la proporción relativa de puestos de trabajo en tecnología comenzó a disminuir.

2. Influencia del sector tecnológico

Otra cuestión relevante que se puede extraer de los datos aportados por Indeed es la influencia que tiene el sector tecnológico en un país en concreto. De nuevo, podemos ver que tanto en España como en Portugal el papel de la tecnología como motor del mercado laboral tiene una importancia elevada. Además, dicha importancia se ha visto intensificada por la pandemia:

3. Búsqueda de empleo

En lo que a la búsqueda de empleo se refiere, en el informe podemos ver lo que ocurre en cada país entre noviembre de 2019 y noviembre de este año. Las tendencias que se obtienen a partir de los datos no son uniformes en todos los países, pero hay patrones claros que se replican en una gran cantidad de mercados europeos, que brindan una clara indicación de cómo la demanda de empleos tecnológicos aumentó a partir de marzo de 2020. España sigue dicha tendencia:

Como hemos visto la demanda en puestos tecnológicos parece crecer en países como España o Portugal, sin embargo ¿se consiguen cubrir dichos puestos? Esto es otra historia. 

En España el 44,1% de las vacantes en tecnología son difíciles de cubrir.

Indeed considera que un puesto es difícil de cubrir cuando permanece más de dos meses anunciado. Portugal tiene la mayor proporción de trabajos tecnológicos que se clasifican como difíciles de cubrir, seguido de los Países Bajos y Bélgica. En el otro extremo se sitúan Dinamarca y Reino Unido.

Antes de la covid-19 los puestos difíciles de cubrir podrían permanecer más de 6 meses vacantes y, países como Reino Unido, Francia o Dinamarca tenían una ratio muy elevada de puestos vacantes. Sin embargo, la pandemia dio la vuelta a estos números, cosa que no pasó en Alemania o Portugal.

Resumen

Según el informe de Atomico, en lo que se refiere al mercado laboral en puestos tecnológicos España está de enhorabuena. Otro cantar es si ahondamos en la parte de inversión per cápita por país, donde España se sitúa por debajo de la media europea (está en el puesto número 15), o si hablamos de que Europa alberga las 10 universidades más importantes de ciencia computacional, ninguna de ellas está en España.

El modo oscuro en las aplicaciones es, sin duda, una de las características más demandadas por los usuarios de todo tipo y en especial por parte de los programadores. Yo no lo entiendo porque a mí me destroza la vista 🙈 y en Windows en particular me parece horrendo, pero lo cierto es que todos los grandes nombres del sector lanzan el soporte para modo oscuro con especial protagonismo en sus aplicaciones.

Sea como fuere, siempre es una gran idea adaptarse a los gustos y preferencias de los usuarios, así que proporcionar soporte para este modo de funcionamiento en nuestros sitios o aplicaciones web va a ser siempre positivo.

En este artículo te voy a contar cómo puedes dar soporte automático en tu código Web para el modo claro y oscuro del sistema operativo usando tan solo CSS.

La nueva característica prefers-color-scheme

A estas alturas ya deberías conocer bien el concepto de media-queries y diseño responsivo. Las media queries nos permiten adaptar un diseño web a las particularidades del medio en el que se está desplegando. Por ejemplo, para unos anchos determinados, pero también a si es en pantalla o impreso, entre otras características.

Una de las nuevas características de medios que se han añadido a los navegadores en los últimos meses es la que nos permite definir los estilos a aplicar según el modo de color definido en el sistema operativo. Se trata de prefers-color-scheme.

Se emplea básicamente del mismo modo en el que utilizamos otras características, como width para adaptarnos al ancho disponible, solo que en este caso los valores que puede tomar son los de los esquemas claro (light) y oscuro (dark) del modo de color del sistema.

Vamos a verlo rápidamente con un ejemplo. Esta es una página muy simple que tiene nada más que un encabezado, un par de párrafos y un enlace. No le establezco colores ni estilos de ningún tipo y, por defecto, el navegador le otorga este aspecto anodino:

Este será su aspecto independientemente del modo que tengamos establecido en el sistema. Es decir, aunque tengamos el sistema en modo oscuro, la página se va a ver con el fondo blanco y los textos en negro, no cambia en forma alguna dependiendo del modo.

Bien, gracias a la nueva propiedad para media queries que acabo de comentar, podemos escribir algo como esto:

@media (prefers-color-scheme: light) {
    body {
        background-color: white;
        color: black;
    }
    a {
        color: red;
    }
}

Fíjate que lo que hacemos es indicar que, para cuando el sistema esté en modo claro (light) queremos que utilice los selectores CSS indicados. En este caso dejamos el fondo blanco y el color por defecto de las letras negro, y ponemos los enlaces en color rojo. En mi equipo que, por supuesto está en modo claro 😉, se verá así:

No hay mucho cambio aparte del color del enlace, pero lo más importante es ver cómo el navegador nos indica que está usando los estilos de nuestra media query:

Si te fijas en la zona recuadrada a la derecha de la figura (amplíala para verla mejor) verás que tengo definido el color azul por defecto para los enlaces, pero que se está aplicando el rojo que hemos indicado en la media query. ¡Perfecto!, parece que de momento funciona.

Ahora vamos a añadir el soporte para el modo oscuro:

@media (prefers-color-scheme: dark) {
    body {
        background-color: black;
        color: white;
    }
    a {
        color: yellow;
    }
}

En este caso tan sencillo me limito a poner el color del fondo negro, el color del texto por defecto como blanco y que los enlaces se vean amarillos.

Bien, haciendo esto, el navegador al cargar la página verificará si estamos utilizando el modo oscuro en el sistema y en caso afirmativo usará estos estilos. No solo eso: si lo cambiamos sobre la marcha se adaptará instantáneamente al nuevo estilo sin que tengamos que hacer nada:

Como puedes observar en la animación, en cuanto cambiamos el modo de color de las aplicaciones a oscuro, automáticamente la página cambia los estilos, tomando los indicados en nuestra última media query, y todo el sistema le sigue a continuación. ¡Muy chulo y sencillo!

Esto funciona en todos los navegadores modernos, básicamente Firefox y Chrome así como los basados en Chromium como Opera, Brave o Microsoft Edge. No sé por qué motivo, en Edge bajo Windows 10 no funciona. Quizá sea un bug de la versión actual, pero en otros sistemas sí que funciona.

También funciona perfectamente en móviles. Por ejemplo, esta es la misma página cambiando de color automáticamente al cambiar el modo en mi móvil con Android:

Y en iOS, dado que todos los navegadores son Safari por debajo, también funciona sin problema.

Un último apunte: aunque esto va a funcionar en todos los navegadores modernos, si quieres dar soporte para otros navegadores (como Internet Explorer 😒) las buenas prácticas dictan que crees unos estilos por defecto para la página, fuera de toda media query de modo que si no las reconoce, al menos se vea de una manera decente. Puedes usar los mismos estilos que para el modo claro, por ejemplo.

Esto último en Sass es muy fácil de hacer sin tener que repetir los estilos, pero quizá lo mejor sería que utilizases variable CSS para los colores principales que vas a emplear en cada uno de los modos, reutilizándolos así de manera muy sencilla, y pudiendo además variarlos fácilmente en el futuro.

El archivo que he utilizado como ejemplo (688 bytes) es el más sencillo posible. Ahora solo resta que lo apliques a tu caso particular, empleando los estilos que sean precisos para adaptar tu diseño, que puede llegar a ser muy complejo, pero que en el fondo sólo debería afectar a unos pocos colores.

¡Espero que te resulte útil!

Cuando trabajas con .NET habrás observado que, al compilar una aplicación, aparte del .exe o .dll correspondientes se generan también unos archivos con la extensión .pdb. Estos tienen el mismo nombre que el ensamblado principal, pero no parecen hacer nada.

PDB es el acrónimo de Program Database. Es un formato propietario de Microsoft que almacena información de depuración de las aplicaciones ejecutables en Windows (.exe y .dll). Se crea a partir del código fuente para obtener una relación exhaustiva de los símbolos (variables, objetos, métodos...) del programa y su ubicación en el código y relacionarlos con el código compilado resultante. De esta manera, si necesitamos depurar la aplicación, las interfaces de depuración pueden "casar" las instrucciones de bajo nivel que se están ejecutando con las líneas de código concretas con las que se corresponden.

Aunque es un formato propietario de Microsoft, en realidad está documentado de forma abierta en GitHub. Si bien existe una API y SDK específicos para trabajar con estos archivos .pdb en Windows y, además, con .NET Core se introdujo una versión "portable" del formato que sirve para cualquier sistema, en otros sistemas debemos usar herramientas específicas de terceros, como PDBParse u otras más avanzadas como Radare2, que es mucho más potente y no sólo sirve para este tipo de archivos, sino que hace ingeniería inversa casi de cualquier cosa.

Con un PDB puedes depurar el código fuente a partir de volcados de memoria (y/o el ejecutable) con Visual Studio y herramientas como WinDBG.

Archivos PDB en release

Pero, si los archivos .pdb son para depuración, ¿por qué cuando genero una aplicación en modo release, para producción, también se me generan archivos .pdb? ¿Para qué me sirve eso?

El motivo parece obvio, pero no lo es tanto. Y es que, si no tuviésemos este tipo de archivos, no podríamos depurar la aplicación en producción.

¿Cómo? ¿Depurar en producción? Parece un contrasentido. Al fin y al cabo, ya depuramos la aplicación mientras estamos desarrollándola ¿no?

En efecto. Durante las pruebas y el desarrollo ya depuramos la aplicación, por lo que la podemos desplegar a producción con ciertas garantías. Sin embargo, debemos tener en cuenta varias cosas:

• Hay muchas cosas que se nos van a escapar durante el desarrollo, que pueden producir errores una vez la aplicación está en funcionamiento.
• En ciertos tipos de aplicaciones, al estar en producción y tener muchos usuarios simultáneos, se dan situaciones muy difíciles de reproducir en desarrollo o pruebas, especialmente las que tienen que ver con código multisubproceso/asincronía.
• Si la aplicación se distribuye a muchos usuarios finales es muy probable que ciertos entornos personalizados (configuración, sistema operativo, nivel de parche, drivers...) den problemas que no hayamos podido tener en cuenta durante el desarrollo. En ese caso necesitaremos el .pdb para depurar el ejecutable concreto que presente los problemas.
• Cuando compilamos para release se le aplican multitud de optimizaciones al código final que no están al compilar en debug (no tanto por el switch/debug como el /optimize que se aplica en este caso). Generalmente esto no tiene impacto alguno sobre el funcionamiento de la aplicación más allá de mejorar su rendimiento, pero en ciertas ocasiones sí que pueden introducir cambios sutiles que afecten al resultado final e introduzcan nuevos bugs.
• Si hacemos profiling y optimización del ejecutable final, necesitaremos el .pdb para localizar las líneas que se pueden optimizar.

Regenerar archivos .pdb

Vale. Me has convencido. Son útiles. Pero, dado que tengo el código fuente de cada versión gracias al control de código fuente con Git, si me hace falta puedo volver a compilarlo y generar el PDB si lo necesito ¿no?

Pues sí, pero no... La lógica es aplastante, y será cierto en la mayoría de los casos. Pero hay un problema: nadie te garantiza que el mismo código exacto, unos meses después, genere el mismo archivo .pdb que se generó cuando compilaste la primera vez.

El motivo es que si cambia la versión del compilador o incluso de Visual Studio, el ejecutable generado puede ser diferente, y por lo tanto el PDB también. No sólo eso, incluso el mismo compilador no siempre genera el mismo código ejecutable todas las veces, según asegura Eric Lippert, exmiembro del equipo de diseño del lenguaje C# en Microsoft.

Tampoco debemos olvidar que los archivos .pdb que se generan para debug y para release no son iguales.

¿Debería incluir los .pdb cuando distribuya mi aplicación a los usuarios?

No es necesario que lo hagas. Ocupan bastante y en la mayoría de los casos no los vas a usar para nada. Por eso, los puedes quitar del paquete final que distribuyas (instalación, ZIP...) y obviar dárselos a los usuarios finales.

Si luego los necesitas siempre puedes facilitárselos y depurar in situ. Por eso es interesante que los archives en algún lado para tenerlos a mano, solo, por si acaso.

Desactivar la generación de archivos PDB en release

De acuerdo otra vez. Siempre me convences... Pero, de todos modos, seamos realistas, yo no voy a depurar mi aplicación en producción nunca. ¿No sería mejor directamente no generarlos?

La recomendación sería que no: no desactives su generación. Genéralos siempre y archívalos por versiones, aunque no los distribuyas.

No obstante, si tienes la seguridad de que no los quieres, desactivar su generación es muy sencillo en Visual Studio:

1. Cambias a la configuración "Release".
2. En las propiedades del proyecto vas a la pestaña Debug.
3. En la parte de abajo pulsas el botón Avanzadas, para abrir el diálogo de propiedades avanzadas.
4. En la lista desplegable para Información de depuración escoges la opción None.

Esto desactivará la generación de símbolos de depuración, por lo que prueba conseguida. Pero te recomiendo que no lo hagas.

Fíjate en que hay varias opciones y por defecto, en .NET Core / .NET 5 la elegida es Portable. Lo que significan estas opciones es:

• None: no se generan símbolos de depuración.
• db-only: podrás depurar el código a partir de volcados de memoria, pero sin poder usar el ejecutable.
• Full: igual que el anterior pero además podrás adjuntar el ejecutable al depurador ya que incluirá dentro de éste cierta metainformación de depuración. Te permite hacer cosas como "Editar y continuar" en Visual Studio, que están muy bien.
• Portable: un formato nuevo de PDB que surgió con .NET Core y que genera un archivo de depuración compatible con todos los sistemas operativos, lo que pega bien con la naturaleza multiplataforma de .NET Core. Es el equivalente "moderno" a la opción Full y es lo que está marcado en el caso de aplicaciones .NET Core/.NET 5+.
• Embedded: embebe la información de depuración directamente en el ensamblado final, por lo que no se genera ningún archivo .pdb. Ahora bien, siempre estarás distribuyendo esta información y el .exe o .dll ocuparán mucho más.

Espero que este repaso a los PDB haya arrojado luz sobre qué son, cuál es su utilidad y cómo debes gestionarlos.

Esta semana empezamos con un experimento que esperamos que salga bien, os sea útil y seamos capaces de seguir haciéndolo. Se trata de un noticiario semanal en vídeo en el que os contaremos en 2 o 3 minutos las principales noticias que se hayan producido en el sector, haciendo especial hincapié en cuestiones relacionadas con la programación.

A continuación dejamos el vídeo de este primer número. Debajo encontrarás un resumen de texto y los enlaces de todo lo mencionado.

No te olvides de suscribirte a nuestro boletín mensual, y también al canal de YouTube para enterarte de los nuevos vídeos. Y si te gusta ayúdanos a difundirlo dándole un "like" en YouTube. ¡Gracias!

[youtube:Etlf-djNb34]

Ruby 3.0

5 años después de Ruby 2, acaba de aparecer hace unos días la versión 3 de este lenguaje de programación con tantos adeptos. Esta nueva versión hace hincapié en mejorar la concurrencia, el tipado de datos y, sobre todo, el rendimiento. El compilador Just In Time ahora puede conseguir hasta el triple de rendimiento al ejecutar cierto código.

• Ruby 3.0.0 liberado
• Página oficial del lenguaje de programación Ruby
• Ruby on Rails, el framework Ruby más utilizado

JupyterLab lanza su versión 3.0

Este conocido entorno permite crear archivos interactivos usando infinidad de lenguajes de programación. Se utiliza para aprender, trabajar, ejecutar código... y es muy utilizado especialmente en todo lo que tiene que ver con ciencia de datos y machine learning.

Esta nueva versión tiene una interfaz mejorada, más idiomas en la UI, una extensión para hacer tablas de contenidos y, sobre todo, un depurador integrado con el entorno, listo para ser utilizado.

• ¡Jupyter 3.0 liberado! - Blog oficial
• Página oficial de Jupyter
• Todos los lenguajes soportados por Jupyter

Bootstrap lanza la v1.3 de sus iconos

Ahora tienes 60 iconitos nuevos, además de todos los existentes, para añadir a las interfaces de tus aplicaciones Web (o no):

• Iconos de Bootstrap v.1.3.0 - Blog oficial

Filtración del código fuente de Nissan

Alguien en Nissan ha metido la parta hasta el fondo. Dejaron un repo con todo el código fuente de la empresa en BitBucket con las credenciales admin/admin predeterminadas. Alguien se dio cuenta, y se lo han bajado todo 🤦‍♂️

Entre los datos almacenados en el repositorio se encontraban el código fuente de las aplicaciones móviles de Nissan, partes de la herramienta de diagnóstico Nissan ASIST, servicios varios, pero también otros activos como herramientas de venta, captación y retención de clientes, datos de investigación de mercado, y el portal de logística de vehículos.

• Código fuente de Nissan filtrado a través de un servidor mal configurado - Una Al día de Hispasec

Quien más y quien menos en este mundo del software, alguna vez ha tenido que escribir una biblioteca de clases (mal llamada librería) o una API REST. O, al menos, ha tenido que modificarla. Y como profesionales que somos, siempre documentamos y explicamos el funcionamiento para que los consumidores puedan usarla fácilmente ¿verdad? 😜

Aunque me gustaría que la respuesta fuese que siempre se documenta bien, basta con que piense en mis propios proyectos pasados para saber que no es así. ¿Y qué nos aporta esa documentación? Pues si estamos hablando de una biblioteca o un paquete NuGet (que es una biblioteca, al fin y al cabo), la diferencia salta a simple vista:

La diferencia es abismal, ¿no? En el primer ejemplo, que está sin documentar, somos como un mamut con pistolas pegando tiros a ver qué sale. En cambio, en el segundo caso, tenemos una información que escribió el propio desarrollador del método, donde nos explica qué hace, qué hacen sus parámetros y qué valores de retorno o excepciones pueden existir (si las hubiese).

Para conseguir esta maravilla, simplemente es necesario que en el propio código de la clase introduzcamos unas anotaciones especiales llamadas sumarios, donde vamos a añadir esos mensajes que queremos que se vean desde fuera, por ejemplo:

/// <summary>
/// This is the awesome class that contains the awesome method
/// </summary>
public class MyAwesomeAPI
{
    /// <summary>
    /// This method is awesome and solves your problems
    /// </summary>
    /// <param name="parameter1">This is the first parameter for the awesome method</param>
    /// <param name="parameter2">This is the second parameter for the awesome method</param>
    public void MyAwesomeMethod(int parameter1, int parameter2)
    {
    }
}

Esto es sencillo al estar perfectamente integrado, incluirse en el código y formar parte del propio binario, pero... ¿podemos seguir este planteamiento en una API REST hecha en C#?

OpenAPI al rescate

Pues evidentemente, si estas leyendo esto es porque hay una solución y esa solución se llama OpenAPI. Pero, ¿qué es OpenAPI? Si nos vamos a la definición de su propia web (traducida por mí):

La Especificación OpenAPI (OAS) define una descripción de interfaz estándar y de lenguaje de programación para las API de REST, que permite tanto a los humanos como a las computadoras descubrir y comprender las capacidades de un servicio sin necesidad de acceder al código fuente, a documentación adicional o a la inspección del tráfico de la red. Cuando se define adecuadamente a través de OpenAPI, un consumidor puede comprender e interactuar con el servicio remoto con una cantidad mínima de lógica de implementación. De manera similar a lo que las descripciones de interfaz han hecho para la programación de nivel inferior, la especificación OpenAPI elimina las conjeturas al llamar a un servicio. -- OpenAPI Specification

Y esto, traducido a palabras mortales, quiere decir que la propia API REST va a exponer de manera adicional uno o más endpoints que se pueden consultar para descubrir qué hay en esa API. Lo mínimo que va a ofrecer, es un fichero json en el que se define el funcionamiento de la API REST (endpoints disponibles, verbos, autenticaciones...). El formato de este json está estandarizado y eso permite a aplicaciones y personas entender qué expone una API REST sin tener que hacer "mágica chamánica".

Un ejemplo del json que genera el archiconocido WeatherForecast (la API REST de ejemplo de ASP.NET):

{
  "openapi": "3.0.1",
  "info": {
    "title": "PostSwagger",
    "version": "v1"
  },
  "paths": {
    "/WeatherForecast": {
      "get": {
        "tags": [
          "WeatherForecast"
        ],
        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "text/plain": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/WeatherForecast"
                  }
                }
              },
              "application/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/WeatherForecast"
                  }
                }
              },
              "text/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/WeatherForecast"
                  }
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "WeatherForecast": {
        "type": "object",
        "properties": {
          "date": {
            "type": "string",
            "format": "date-time"
          },
          "temperatureC": {
            "type": "integer",
            "format": "int32"
          },
          "temperatureF": {
            "type": "integer",
            "format": "int32",
            "readOnly": true
          },
          "summary": {
            "type": "string",
            "nullable": true
          }
        },
        "additionalProperties": false
      }
    }
  }
}

Aunque sin conocer el formato cuesta un poco saber qué está exponiendo la API REST que nos ofrece el json, más o menos se deja entrever que hay un endpoint en /WeatherForecast, cuyo único retorno definido es un HTTP 200 con un array de tipo WeatherForecast. Este array contiene 4 propiedades llamadas date, temperatureC, temperatureF y summary.

Aunque con devolver este json sería suficiente, a las personas nos suelen gustar más las tablas, los botones, las etiquetas... O sea, todo lo visual y que nos dé menos trabajo... Así que, lo bueno de que el formato sea estándar, es que existen herramientas que nos ofrecen una interfaz gráfica sobre este json, de modo que interactuar se vuelve mucho más sencillo.

Incluso podemos probar desde el navegador los diferentes endpoint que ofrece:

Swagger en .Net 5

¿Y cómo podemos tener esta maravilla en nuestras APIs REST?

Si el proyecto que estamos creando es ASP .NET Core en .Net 5, basta con que marquemos el selector Habilitar soporte para OpenAPI:

Al hacerlo, se crea automáticamente un proyecto con todo lo necesario para que tanto el fichero swagger.json, como el endpoint de la interfaz gráfica (/swagger/index.html) estén disponibles.

¡Estupendo!

Swagger en .Net Core

¿Y qué podemos hacer si el proyecto no es .Net 5?

Pues, las versiones anteriores no tienen soporte durante la creación del proyecto, pero añadirlo es algo muy sencillo.

Lo primero que vamos a necesitar, es añadir a nuestro proyecto el paquete NuGet Swashbuckle.AspNetCore.

Después, en el método ConfigureServices de la clase StartUp el código, tenemos que añadir esto:

services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "NombreDeMiApi", Version = "v1" });
});

Y por último, vamos a registrar el middleware que se va a encargar de servir la interfaz de usuario y el fichero json añadiendo en el método Configure:

app.UseSwagger();
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
                 "NombreDeMiApi v1"));

Por tener una visión completa:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddSwaggerGen(c =>
    {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "NombreDeMiApi", Version = "v1" });
    });
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    app.UseSwagger();
    app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
                     "NombreDeMiApi v1"));
    app.UseHttpsRedirection();
    app.UseRouting();
    app.UseAuthorization();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

¡Listo! Con esto conseguimos lo mismo que .Net 5 nos proporciona de serie.

Conclusión

Con solo hacer esto, ya hemos conseguido una configuración básica de nuestra documentación OpenAPI, así como una interfaz de usuario para poder probar. Gracias a ello, automáticamente se detectarán todos los controladores y sus acciones, y se añadirán de manera transparente el fichero json y, por tanto, a la interfaz gráfica que lo utiliza.

Este es el comportamiento por defecto y la documentación básica. Entre nuestro deberes como developers, está el complementar esta documentación para que sea completa, añadiendo cosas como códigos HTTP esperados, autenticaciones si las hay, no mostrar todos los endpoints que no sean necesarios, etc..

Pese a todo, es una herramienta la mar de interesante y que personalmente pienso (y no solo yo por lo que se ve en el cambio de .Net 5) que debería formar parte, por defecto, de todas nuestras APIs REST. Va a permitir que terceros se integren con nosotros, pero incluso para nosotros mismos durante las pruebas nos va a simplificar mucho el trabajo al no tener que estar usando Postman, curl, o cualquier otra herramienta similar.

Por otro lado, y esto es también algo muy interesante, OpenAPI está soportado por Azure API Management (y seguro que por otros proveedores cloud), por lo que si nuestra API REST genera el fichero json, podemos utilizarlo para etapas posteriores del ciclo de vida de nuestro servicio.

El trabajo desde casa varía de una persona a otra. Si tienes la costumbre de trabajar en un entorno de oficina, el trabajo en remoto puede resultar muy desalentador.

No obstante, los desarrolladores que trabajan a distancia son cada vez más numerosos debido a la flexibilidad del horario de trabajo y a la posibilidad de contratar a personas con talento que viven fuera de la región.

Con la aparición de la crisis de la COVID-19, el teletrabajo se ha convertido en prácticamente una obligación para muchos programadores. Pero, aunque parece una gran cosa, también tiene sus inconvenientes. Algunos importantes.

Este artículo expone algunas ventajas y desventajas de teletrabajar. Están agrupadas en dos categorías: una general para todo tipo de trabajadores, y otra más específica para desarrolladores de software.

Ventajas e inconvenientes del teletrabajo para todo tipo de profesionales

Desventajas:

• Ausencia de vida social en el lugar de trabajo: aunque puedes interactuar con compañeros y clientes a través de la tecnología, sin embargo, no es lo mismo que las reuniones cara a cara.
• Autodisciplina: necesitas mucha vocación para trabajar desde casa y no distraerte, ya que es fácil perder la motivación.
• Dependencia de la tecnología: dependes totalmente de la tecnología, ya que tienes que depender de los correos electrónicos, las llamadas en conferencia y los mensajes para mantenerte en contacto.
• La empresa podría considerar que no estás haciendo nada: si los directivos no están capacitados para gestionar eficazmente a los empleados en remoto, la productividad puede ser baja. O parecerlo.

Beneficios:

• Flexibilidad de horarios de trabajo: puedes planificar tu propio horario para que también se adapte a tu vida familiar.
• Más productividad: el trabajo a distancia puede mejorar la productividad si se utilizan las mejores prácticas y las herramientas adecuadas.
• Aprender nuevas habilidades: puedes aprender cosas nuevas mediante cursos online y también enseñarte a ti mismo nuevas habilidades de forma autodidacta.
• Ahorrar costes: trabajar desde casa es más rentable, ya que ahorras dinero en los gastos de transporte.
• Más concentración: puedes trabajar sin ninguna interrupción típica de las oficinas, como la de socializar de más en la hora del café.
• No tienes que vivir en la misma ciudad: el trabajo a distancia no requiere tener una presencia física, así que puedes trabajar desde cualquier lugar.

Ventajas e inconvenientes del teletrabajo desde el punto de vista de un programador

Desventajas:

• Si el equipo vive en diferentes zonas horarias, lo más eficiente es dividir el trabajo de manera que se requiera una comunicación mínima entre las zonas; esto puede aumentar la carga de documentación y llevar a estructuras de división del trabajo que no sean las más óptimas.
• Las relaciones de trabajo por Slack / Microsoft Teams / Google Chat no son tan efectivas como las que se celebran en la misma sala de reuniones. Al margen de los problemas de socialización que mencionamos arriba, para los desarrolladores también puede suponer una merma en la resolución de problemas espontáneos de "conversación de pasillo" e "ideas felices" de ese estilo que surgen en conversaciones técnicas informales sobre el trabajo.
• Como desarrollador de software trabajando a distancia puedes caer en la tentación de disimular o ocultar más fácilmente los problemas del software, "escurriendo el bulto" o, al menos, difuminando la responsabilidad de los mismos, especialmente en temas de integraciones o funcionalidades comunes que exigen un desarrollo más colaborativo.
• Los desplazamientos mensuales o trimestrales pueden parecer divertidos, pero cuando te acostumbras a trabajar desde casa y tener un alto nivel de productividad, los viajes a la sede de la empresa para estar con todo el equipo se pueden convertir en algo tedioso y para muchos desarrolladores se convierte en una pérdida de tiempo que no les permite avanzar en los proyectos de desarrollo.
• Si eres jefe de desarrollo o de proyecto que trabaja en remoto, lo normal es delegar algunos de los aspectos del liderazgo a alguien que trabaja presencialmente, que efectivamente no hace el trabajo en remoto pero que, sin embargo, es corresponsable, en teoría, de los resultados.

Ventajas:

• Si el trabajo puede dividirse bien a través de las distintas franjas horarias (por ejemplo, los módulos del software de un subequipo se revisan durante la noche por un subequipo en remoto, y viceversa), el equipo puede avanzar hacia una productividad de 16 ó incluso 24 horas al día, en vez de 8.
• Puedes optar a trabajar para aquellas empresas de software que te interesan aunque no tengan una sede en tu ciudad o zona geográfica, ya que la mayoría de las mejores empresas de software tienen sede en las grandes ciudades o ámbitos geográficos muy concretos.
• Lo que la empresa de software se ahorra en espacio físico y los costes asociados, lo puede invertir en mejores salarios, mejores herramientas o en equipos a medida para cada programador, lo que aumenta la satisfacción general de los trabajadores de la empresa y la productividad de la misma.
• Al margen de la flexibilidad horaria mencionada antes, el trabajo como programador tiene picos de trabajo asociados a el cumplimiento de los plazos para la entrega de un proyecto, recuperación de horas perdidas por un bug inesperado o nuevas especificaciones de producto, etc... Es mucho más fácil sumar estas horas trabajando desde casa, y también recuperar horas libres para compensar el trabajo extra en momentos de menor actividad.
• Atajar el sedentarismo típico de los desarrolladores. Desde casa es más fácil organizarse para salir a hacer ejercicio y también para comer mejor.
• Estar a solas con el ordenador y evitar las distracciones mientras se programa. Lo mencionamos arriba, pero en el caso de un desarrollador evitar distracciones e interrupciones es mucho más crítico. Se dice que un programador al que se le interrumpe tarda unos 15 minutos de media en volver a enganchar con el punto mental en el que estaba antes de la distracción.
• Vestirse como a uno le da la gana. Por lo general a los programadores les gusta ir en camiseta y con ropa cómoda, que en muchos ambientes laborales se considera demasiado informal. En otros sectores, a los teletrabajadores les gusta vestir más formal aunque nadie les vaya a ver en persona, pero normalmente no es el caso de los desarrolladores de software.

Conclusión

A medida que el mundo se transforma, el trabajo en remoto tiene importantes ventajas y desventajas dependiendo de la persona. Lo que funciona para ti o tu empresa no necesariamente tiene que funcionar para los demás. Pero, con los crecientes avances en el mundo de la tecnología, está claro que el teletrabajo juega ya un papel crucial en el devenir de las empresas.

Los trabajadores que mejor se adapten al teletrabajo ganarán empleabilidad, y las empresas que se sepan ser rentables trabajando en remoto serán las que sobrevivan en un futuro próximo.

Esta semana en nuestro noticiario, tenemos novedades sobre Oracle, el fin de la vida de .NET Core 2.1, el dominio mundial de WordPress, las nuevas gafas de realidad aumentada de Lenovo y varias noticias de menor calado. Además, una fe de erratas al principio, y una noticia de campusMVP en exclusiva.

No te olvides de suscribirte a nuestro canal de YouTube, al RSS del blog o a nuestro canal de Telegram para recibir todos los sábados el noticiario. Y si te gusta el vídeo, dale a "Me gusta" 😊

[youtube:I_WUgrkgZI4]

Oracle presenta la versión 21 de su base de datos

En 2020, debido a la COVID-19, Oracle no lanzó la versión 20c de su base de datos, así que este año lanza la versión 21c, que en realidad es una doble versión porque junta lo de las dos en una. Tiene un montón de novedades entre las que destacan las bases de datos en memoria (que antes sólo estaban disponibles en la versión cloud), un nuevo tipo de datos JSON muy optimizado, soporte de más algoritmos para Machine Learning, o la posibilidad de ejecutar otros lenguajes como JavaScript o Python dentro de la base de datos.

• Presentación de Oracle 21c

Fin del ciclo de vida de .NET Core 2.1

Junto al aviso mensual de parches y actualizaciones de .NET, Microsoft nos ha recordado a todos esta semana que .NET Core 2.1 llega al final del ciclo de vida este verano y que la actualización de este mes es la última que tendrá el SDK. Así que si tienes alguna app con esta versión, cambia ya a .NET 3.1 o a .NET 5 y no dejes que te pille el toro.

WordPress ya está detrás de casi la mitad de los sitios web del mundo

Esta semana hemos conocido un dato demoledor sobre WordPress: y es que este archiconocido gestor de contenidos está ya detrás de casi la mitad de los sitios web del mundo. 😯 En concreto del 39,6%. Eso significa que hace funcionar a 2 de cada 5 sitios web mundiales y no para de crecer.

Las mismas estadísticas revelan también que un 38,3% de los sitios web, una cantidad muy parecida, no usan un gestor de contenidos conocido. O sea, que o bien utilizan desarrollos propios o páginas estáticas. Es otro dato muy interesante.

Si descartamos estos sitios y nos quedamos solo con los que usan un gestor de contenidos, WordPress tiene el 64% de cuota de mercado, que son 2 de cada 3. El siguiente CMS, a muchísima distancia, es Shopify, con el 3,2% de cuota. Impresionante.

Tienes todas las cifras en un enlace del artículo que acompaña a este vídeo. Mira debajo 😊

• Wordpress gestiona el 39,6% de los sitios web del mundo

Lenovo presenta sus smart glasses empresariales A3

Fuera ya de la programación, esta semana ha estado marcada por el evento de consumo CES, que en esta ocasión ha sido, por supuesto, 100% virtual, y en el que las marcas presentan siempre sus grandes novedades en hardware. Hay cantidad de novedades en chips y otras cosas (ver justo a continuación) pero lo que más nos ha llamado la atención ha sido las nuevas gafas empresariales de realidad aumentada de Lenovo, la A3.

Te permiten definir hasta 5 pantallas virtuales, emitir y recibir vídeo Full-HD para expertos remotos, interactuar con modelos en 3D, y muchas cosas más. Estarán listas para mediados de año y no hay precios todavía.

• Detalles sobre las gafas Lenovo A3
• Mini-site del producto

Novedades del CES en procesadores y GPUs

• Anuncios de Chips en el CES 2021: los portátiles toman el protagonismo
• Intel añade detección de ransomware por hardware en sus chips vPro de generación 11
• NVidia desenvuelve sus GPUs GeForce de serie RTX 30 para portátiles
• AMD presenta sus procesadores para portátiles Ryzen 5000

Otros temas comentados brevemente

• Beta de TypeScript 4.2
• El lenguaje Go podría añadir genéricos este año
• Grafana añade una capa gratuita

Hace unos meses la Comisión Europea publicó el primer resumen cuantitativo sobre la adopción de tecnologías de inteligencia artificial (IA) entre las empresas europeas. Para ello realizó una encuesta en 30 países (UE-27 junto con Noruega, Islandia y Reino Unido) a más de 9 500 empresas; en la muestra están representadas empresas de todos los tamaños, desde micropymes (entre 5 y 9 empleados) hasta grandes empresas (más de 250 empleados).

En este enlace encontrarás el informe completo (en inglés) y también un resumen del mismo (en inglés y en francés), así como una Excel con los datos agregados. Pero te vamos a contar lo interesante en este artículo si sigues leyendo 😉

Definiciones usadas en el informe

En este informe se define inteligencia artificial como "una tecnología que intenta automatizar una o más funciones o procesos cognitivos (humanos). Proporciona predicciones, recomendaciones o decisiones para lograr objetivos específicos. Lo hace aprendiendo continuamente sobre su entorno o los resultados de sus acciones".

Por otro lado, clasifica en 10 grupos las tecnologías de IA incluidas en la encuesta. Estos son:

1. Procesamiento del lenguaje natural
2. vVsión por computador,
3. Detección de anomalías
4. Análisis de los sentimientos
5. Machine learning
6. Optimización de procesos o equipos
7. Motores de recomendación y personalización
8. Automatización de procesos
9. Máquinas autónomas
10. Actividades creativas y de experimentación

El informe sigue en líneas generales la estructura de la encuesta y se divide en cinco capítulos clave, que se centran en los siguientes temas: adopción de la tecnología de IA, recursos, barreras internas para la adopción de la tecnología, barreras externas y por último analizan en profundidad los obstáculos para adoptar IA por tecnología y por país.

En este post nos centraremos en aquellos aspectos que creemos que más afectan a los programadores.

Adopción de la tecnología de IA en la Unión Europea (UE)

El primer indicador es hasta qué punto las empresas conocen la inteligencia artificial, como requisito indispensable previo para la adopción, como es lógico.

Un 78% de las empresas europeas dicen saber lo que es la inteligencia artificial, el 15% no lo tiene claro y un residual 7% afirman no saber lo que es.

En cuanto al nivel de adopción de IA, cuatro de cada diez (42%) empresas han adoptado al menos una tecnología de IA, sin embargo, el 40% de las empresas participantes no utilizan IA, ni tienen planes de hacerlo en el futuro.

En cuanto a la adopción de IA por tamaño de empresa los resultados no sorprenden a nadie. Más de la mitad (55%) de las grandes empresas (+ 250 empleados) utilizan actualmente al menos una tecnología de inteligencia artificial, en comparación con poco menos de cuatro de cada diez (38%) de las microempresas (de 5 a 9 empleados).

Si nos fijamos en la adopción de IA según el sector económico, dejando a un lado las empresas TIC donde la adopción alcanza el 63%, las pioneras son las relacionadas con la educación (49%) seguidas por las empresas de las ciencias de la salud (47%). Las mayores perspectivas de crecimiento se prevén en el sector de finanzas y seguros (27%) y gestión de residuos (27%). En la siguiente figura se muestran los niveles de adopción de AI por sector:

A diferencia de lo que ocurría cuando se analizaba el tamaño o el sector, sí existe una gran disparidad en cuanto al nivel de adopción de AI cuando comparamos los países de la UE, llegando en algunos casos a ser el doble. Curiosamente los primeros puestos no están ocupados por los países que cabría esperar (Reino Unido, Francia, Alemania, …) sino por Chequia (61%), Bulgaria (54%) y Lituania (54%). España se encuentra en el puesto número 11 (de 30) con un 40%.

Resumen: si actualmente quieres trabajar en una tecnología de IA, lo mejor es buscar una gran empresa, a ser posible del sector TIC y si está en Chequia más posibilidades de acertar tienes 😜 Pero hay cancha en toda la UE y se espera un gran crecimiento en los próximos años.

Recursos para la adopción de IA

La principal estrategia para la incorporación de estas tecnologías es optar por algún tipo de externalización, ya sea a través de la compra de software más generalista (ready-to-use) (59%) o la contratación de terceros que las desarrollen a medida (38%). Solo un 20% de momento abordan el proceso con profesionales de la casa.

En lo que al tamaño de las empresas se refiere, en las grandes empresas de la UE (28%) existe una cierta preferencia por el desarrollo interno de tecnologías de IA en comparación con el 16% de las microempresas que escogieron este enfoque para adquirir tecnología de IA.

También se observan algunas diferencias notables por sector. Los sectores más técnicos son los más propensos a desarrollar la IA internamente (36% sector TI y 28% para otros sectores técnicos o científicos), lo que no es no es de extrañar dado el perfil necesario para ello. Mientras que, por ejemplo, en el sector de la salud o agrícola el porcentaje es del 12% y en lo que se refiere a servicios sociales cae al 8%. (No debemos olvidar el alto nivel de adopción de la IA en este último sector, un 47%).

Resumen: las grandes empresas y los sectores más técnicos son los más propensos a contratar programadores para desarrollar proyectos de IA internamente.

Barreras internas para la adopción de IA

En lo que a barreras internas se refiere, tanto las empresas que ya han adoptado la tecnología (Adopters) como las que piensan hacerlo en un futuro (plan to use) consideran que lo más difícil es encontrar personal formado (falta de habilidades entre el personal existente 45%, dificultades para contratar nuevo personal con las habilidades adecuadas 57%) y en segundo lugar el costo de implementación (costo de adopción 52%, costo de adaptación de procesos operativos 49%, falta de financiamiento externo / público 36%).

Las diferencias entre las empresas de distintos tamaños no son reseñables. De hecho, de nuevo, la falta de personal capacitado vuelve a ser el factor más relevante.

Con respecto a los obstáculos internos para la adopción de IA, no existe un patrón claro para cada sector industrial. Lo único que se puede afirmar es que las barreras son más bajas en el sector TIC a excepción de la relativa a encontrar personal formado, que incluso en dicho sector es un gran obstáculo.

Resumen: todas las empresas se quejan de la falta de conocimiento en tecnologías IA de sus empleados y de la dificultad de encontrar personal capacitado.

¿Qué necesitas para ser considerado personal cualificado?

Se busca especialmente personal con suficientes habilidades de programación, al igual que personal con habilidades de gestión de big data y aprendizaje automático (machine learning) o habilidades de modelado.

Los datos muestran (véase siguiente figura) que las empresas que indicaban carecer de personal capacitado en IA lo que necesitaban era personal con habilidades de programación (52%), personal formado en big data y machine learning (43%) y personal con conocimientos en modelado (39%).

En cuanto al tamaño de la empresa, para la mayoría de las necesidades de habilidades, son las empresas más grandes (más de 250 empleados) las que encuentran las habilidades enumeradas como deficientes, con la excepción de las habilidades en robótica. Cuando se trata de diferencias sectoriales, las necesidades de habilidades de programación son más pronunciadas en el sector financiero y de seguros (59%) y el sector manufacturero (54%).

Y así están las cosas en España:

Conclusión

En lo que respecta a cada tecnología, la adopción en la UE sigue siendo relativamente baja, con tasas inferiores al 13%. Pero si vemos los datos agregados, la adopción alcanza el 42% y un 18% tiene intención de usar IA en menos de dos años.

Por lo tanto, podemos decir, que los datos indican que existe una intención saludable de adoptar tecnologías de IA en los próximos dos años. Pero si bien los obstáculos externos pueden ser más susceptibles de intervención, las empresas generalmente encuentran que los obstáculos internos son el principal desafío.

Una barrera importante a la que se enfrentan todas las empresas, es la falta de habilidades en IA (entre el personal existente y en la contratación de personal nuevo con las habilidades adecuadas). Además, los costos involucrados en la implementación de tecnologías de IA suponen un desafío adicional.

¿A qué esperas para aprender Machine Learning y Ciencia de Datos con nosotros y el mejor máster del mercado?

Una de las grandes novedades que se presentaron con .NET 5 y C# 9, fueron los registros.

Antes de eso podíamos trabajar con dos tipos de estructuras para almacenar información: class y struct.

Nota: existen más tipos de estructuras en C#: delegados, interfaces, etc... pero su objetivo no es almacenar información, que es lo que nos importa a efectos de este artículo y es en lo que nos vamos a centrar.

Con C# 9 o posterior disponemos de un tercer elemento para almacenar información: record, también conocido como registro.

¿Y cuál es la diferencia con los dos anteriores que seguramente ya conoces?

Con las clases y las estructuras tenemos el problema de que pueden ser alterados. Los objetos de tipo clase son tipos por referencia, mientras que las estructuras son tipos por valor, que lo más que se podían acercar a un objeto inmutable era declarándolas como readonly.

Los objetos de tipo record, son objetos por referencia que vienen a solucionar el problema existente a la hora de generar objetos inmutables, esto es, objetos que no pueden variar. Por otro lado están "a caballo" entre clases y estructuras, puesto que tienen características de los dos.

Las similitudes con ambos elementos, los vemos inmediatamente al realizar una comparación entre dos registros.

1. Podremos emplear el operador de igualdad ==, puesto que al ser tipos por referencia nos va a indicar si se tratan de objetos con la misma referencia o no.
2. Al igual que con las estructuras, el método Equals nos va a decir si son iguales o no, en función de los valores que tiene.

Pero veamos de forma más clara su funcionamiento mediante un ejemplo simple.

En primer lugar vamos a crear un nuevo tipo Persona, pero en lugar de emplear un clase (con class), emplearemos record:

public record Persona {
    public string Nombre { get; set; }
    public string Apellidos { get; set; }

    public Persona (string nombre, string apellidos) {
        Nombre = nombre;
        Apellidos = apellidos;
    }
}

Una vez tenemos nuestro registro, vamos crear varios objetos de este tipo:

• Dos de ellos serán copias uno del otro.
• Un tercer objeto nuevo, pero con los mismos valores.
• Un último objeto con diferentes valores.

A continuación vamos a realizar comparaciones entre ellos para verificar:

1. Objetos copiados directamente, al igual que las clases, mantienen la misma referencia.
2. Objetos con los mismos valores, se reportan como iguales.

var persona1 = new Persona ("Rubén", "Rubio");
var persona2 = persona1;
var persona3 = new Persona ("Rubén", "Rubio");
var persona4 = new Persona ("Rubén", "R.");

Console.WriteLine ($"Referencia: persona1 = persona2 {ReferenceEquals(persona1,persona2)}");
Console.WriteLine ($"Valor: persona1 = persona2 {persona1.Equals(persona2)}");
Console.WriteLine ($"Referencia: persona1 = persona3 {ReferenceEquals(persona1,persona3)}");
Console.WriteLine ($"Valor: persona1 = persona3 {persona1.Equals(persona3)}");
Console.WriteLine ($"Referencia: persona1 = persona4 {ReferenceEquals(persona1,persona4)}");
Console.WriteLine ($"Valor: persona1 = persona4 {persona1.Equals(persona4)}");

Y el resultado de ejecutar el código.

Declaración mediante registros posicionales

Al principio decíamos que vienen a solucionar la definición de tipos inmutables, pero... con lo que hemos visto hasta ahora es posible modificar su contenido, por lo que no son inmutables 🤔

La declaración mediante registros posicionales nos va a permitir, por un lado simplificar el cuerpo del registro y, por otro, crear un registro realmente inmutable, siendo el propio compilador el que genere por nosotros toda la fontanería de constructor, deconstructores y propiedades.

Veamos cómo reescribiríamos el registro Persona para hacerlo inmutable:

public record Persona (string Nombre, string Apellidos);

El ejemplo anterior sería equivalente a este otro código:

public record Persona {
    public string Nombre { get; init; }
    public string Apellidos { get; init; }

    public Persona (string nombre, string apellidos) {
        Nombre = nombre;
        Apellidos = apellidos;
    }

    public void Deconstruct (out string nombre, out string apellidos) {
        nombre = Nombre;
        apellidos = Apellidos;
    }
}

Si lo observamos detenidamente, las propiedades no tienen un set, sino que son accesibles únicamente en la inicialización, puesto que son propiedades inicializadoras. De esta forma, ya no podremos alterar el registro siendo realmente inmutable.

Además, es considerable la reducción de código, puesto que hemos reducido toda la declaración a una única línea de código.

Pero, ¿y si necesitásemos constructores adicionales?

Para añadir más constructores a nuestro registro, bastará con añadirlos entre llaves a continuación de la declaración y siempre llamando al constructor base mediante el empleo de this.

public record Persona (string Nombre, string Apellidos) {
    public Persona (string Nombre) : this (Nombre, "") { }
};

Instanciación mediante expresiones con with

Por último veremos cómo podemos instanciar registros con ayuda de expresiones con with, que no es más que una forma de generar un registro a partir de otro, previamente existente, al que indicaremos que alguna de sus propiedades debe tener un valor diferente.

En primer lugar, declararemos un registro a partir del cual copiar:

var persona1 = new Persona ("Rubén", "Rubio");

A continuación, realizaremos la copia mediante igualdad, pero añadiremos la partícula with seguida de la declaración, entre llaves, de los valores que deben ser modificados:

var persona2 = persona1 with { Nombre = "Fernando" };

De esta forma tendremos una copia de persona1 en persona2 pero variando la propiedad Nombre.

var persona1 = new Persona ("Rubén", "Rubio");
var persona2 = persona1 with { Nombre = "Fernando" };
Console.WriteLine ($"Persona 1: {persona1}");
Console.WriteLine ($"Persona 2: {persona2}");

[youtube:UQOeoVqKuvg]

La próxima semana se retiran las certificaciones tradicionales de Microsoft

Las míticas MCSA, MCSD y MCSE para formación de desarrolladores en lenguajes y plataformas concretas, desaparecen definitivamente. Las iban a quitar el verano pasado, pero debido a la COVID-19, lo retrasaron hasta este mes. Ahora Microsoft lo único que quiere es que te preparares para "roles" aunque, eso sí, solo para Azure en lo que respecta a desarrollo. Si quieres certificarte en algo que no sea Azure, mala suerte. Si quieres tener una certificación en la plataforma .NET o en desarrollo Web con tecnologías Microsoft, te queda esta semana para presentarte a los exámenes...

Se presentan los planes de Entity Framework Core 6

Esta semana Microsoft ha presentado su plan para Entity Framework Core de cara a la próxima versión, la 6, que está planificada para noviembre.

Según han dicho, se van a centrar en las características más solicitadas, como por ejemplo el soporte para campos JSON, la posibilidad de crear tablas temporales al hacer migraciones, pero también en mejorar el rendimiento más todavía, o igualarse en capacidades a EF 6 clásico.

Hay un montón de cosas más en la lista:

• The Plan for Entity Framework Core 6.0

Proyecto Win32 Metadata

Esto es superinteresante. A excepción de, básicamente, C o C++ los lenguajes de programación sobre Windows que quieran acceder a funciones de bajo nivel de la API del sistema tiene que hacerlo a través de envoltorios o enlaces con dicha API. Esto incluye lenguajes como C# de la propia Microsoft, que deben utilizar Interop (P/Invoke) y declarar exactamente las funciones que van a utilizar. Esto suele ser complicado de mantener porque si hay cambios en las APIs a medida que cambian las versiones de Windows, no tienes una forma sencillo de conocerlas.

Con este proyecto, el equipo de la API de Windows mantiene todas las referencias actualizadas y permite al compilador generar automáticamente las llamadas de bajo nivel de manera automática, como se ve en el vídeo de las noticias. Es muy interesante porque simplifica mucho el desarrollo de este tipo de funcionalidad.

Han sacado paquetes para .NET y para Rust, y otros desarrolladores pueden utilizar el proyecto para otros lenguajes que lo necesiten:

• Making Win32 APIs More Accessible to More Languages
• Win32Metada en GitHub

Lanzamiento de Wine 6.0: para ejecutar apps Windows en Linux o macOs

Wine es el archiconocido proyecto Open Source que permite ejecutar aplicaciones de Windows en Linux o Mac. No se trata de un emulador, sino de una capa de abstracción de las APIs de Windows en UNIX. Es decir, es un componente que se sitúa en medio de los ejecutables de Windows y traduce las llamadas a bajo nivel de Windows a llamadas a bajo nivel de UNIX, permitiendo así que se ejecuten muchas aplicaciones sin problema.

Ahora acaban de lanzar su versión 6 que es una de las mayores actualizaciones de los últimos años, incorporando multitud de nuevos módulos en formato PE (Portable Executable), como ntdll, Kernel32, gdi32, y user32, además de un gran soporte para Direct3D, DirectShow y DirectMedia con lo que van a funcionar muchos más juegos también. También tiene algunas cuestiones que rompen la compatibilidad hacia atrás.

• Anuncio oficial de Wine 6.0
• Want to run Windows apps on Linux? Wine just got this huge update

Vulnerabilidad crítica en sistemas SAP

Esta semana se ha liberado una vulnerabilidad en el Solution Manager de SAP catalogada con el nivel máximo de 10 en el sistema de valoración de vulnerabilidades. Permite comprometer todos los sistemas que estén conectados al SolMan. Aunque ya se sabía desde el año pasado, es ahora cuando hay una prueba de concepto en funcionamiento, y si en vuestra empresa usáis SAP y no habéis parcheado el sistema... tenéis un problema:

• New SAP Exploit Published Online: How to Stay Secure?

Otros enlaces mencionados

• La versión 88 de Google Chrome que ha salido esta semana retira definitivamente el soporte para Flash.
• Brave en su versión para escritorio, añade soporte para el sistema de archivos distribuido IPFS.
• El mítico sitio de descargas Tucows cierra

El aprendizaje automático o machine learning puede emplearse para abordar distintos tipos de problemas. Estos pueden agruparse en categorías, según la clase de técnica con la que se acometa su resolución.

El objetivo de este artículo es ofrecerte una visión general sobre los paradigmas de aprendizaje automático y los tipos de problemas para los que se usan habitualmente.

Paradigmas de aprendizaje automático

Por regla general (existen excepciones), los algoritmos de aprendizaje automático construyen un modelo que representa el conocimiento que han podido extraer de los datos que se le facilitan como entrada. Dependiendo de la información adicional que se suministre al algoritmo, a fin de guiar el proceso de aprendizaje, podemos diferenciar entre distintos paradigmas. A continuación te describo brevemente los más conocidos:

• Aprendizaje supervisado. Consiste en ir indicando al algoritmo, a medida que aprende, si la salida que ha generado para un cierto caso (la predicción) es correcta o no. La acción más corriente es que el algoritmo efectúe ajustes en el modelo que está generando cada vez que se le indica que se ha equivocado, con el objetivo de mejorar sus predicciones.
• Aprendizaje no supervisado. La única información que se entrega al algoritmo son las muestras de datos, sin más detalles. A partir de dichas muestras es posible analizar la distribución de los valores, la similitud o distancia entre las muestras, el grado de concurrencia de unas variables con otras, etc. Las aplicaciones son múltiples como comprobaremos después.
• Aprendizaje semisupervisado. Es un caso a medio camino de los dos anteriores. Del conjunto de datos con que se cuenta, se conoce la salida correcta solo para algunas muestras. El algoritmo las usa para construir un modelo inicial que, posteriormente, facilita una previsión del valor de salida para el resto de muestras. De esta forma, el modelo se amplía y ajusta aprovechando la información disponible.
• Aprendizaje por refuerzo. Al algoritmo al que se facilitan los datos no se le suministran las salidas reales para que pueda ajustar su modelo, como ocurre en el caso supervisado, pero se le otorga un premio más o menos grande en función de lo buena que es la secuencia de acciones llevada a cabo hasta el momento. De esta forma, el comportamiento se refuerza hacia el objetivo perseguido.

Cada uno de estos paradigmas permite resolver tipos específicos de problemas y puede ser implementado usando distintas herramientas: los modelos que representan el conocimiento. Dependiendo del modelo elegido: un árbol, una red neuronal, un conjunto de reglas, etc., se usará un algoritmo concreto para generarlo y ajustarlo.

Tipos de problemas en machine learning

El aprendizaje automático se emplea para resolver un gran abanico de problemas de la vida real. Dichos problemas, o tareas como también se las conoce, pueden ser categorizados en unos pocos tipos. Aunque no es una regla estricta, cada tipo de problema suele afrontarse mediante un paradigma concreto de aprendizaje. Por ello, a continuación se esbozan los tipos de tareas más corrientes atendiendo al paradigma con el que normalmente se aborda.

Tareas de aprendizaje supervisado

Existen dos tipos de problemas fundamentales que se resuelven mediante aprendizaje supervisado, descritos a continuación. Las salidas reales, conocidas de antemano para los datos, son las que permitirán al algoritmo ir mejorando los parámetros de su modelo. Una vez completado el aprendizaje o entrenamiento del modelo, este será capaz de procesar nuevas muestras y generar la salida adecuada sin ningún tipo de ayuda.

• Clasificación. Cada una de las muestras de datos tiene asociada una o más salidas nominales, a las que se denomina etiquetas de clase, etiquetas o sencillamente clase. Para clasificar de forma automática se crea un modelo predictivo, al que entregando las variables de entrada genere como salida las etiquetas de clase correspondientes. Un clasificador puede usarse para procesar solicitudes de préstamo en solventes o de riesgo, diferenciar los mensajes de correo entrantes como spam o importante, saber si en una fotografía aparece o no la cara de una persona, etc.
• Regresión. Como en el caso anterior, cada muestra también tiene asociado un valor de salida, pero en este caso es de tipo real (continuo, no discreto, es decir, con posibles resultados dentro de un continuo), por lo que las técnicas empleadas para generar el modelo son habitualmente distintas a las usadas para clasificación. No obstante, el procedimiento de ajuste o entrenamiento del modelo es similar: se usan las salidas reales conocidas para corregir sus parámetros y mejorar la predicción. Con un modelo de regresión es posible determinar la estatura de una persona en función de su sexo, edad y nacionalidad, o predecir la distancia que podrá recorrer un transporte tomando como variables de entrada el peso de la carga, volumen de combustible disponible y temperatura ambiente.

Tareas de aprendizaje no supervisado

Los tipos de problemas afrontados con este paradigma de aprendizaje se caracterizan, como se ha indicado más arriba, porque las muestras de datos solo cuentan con las variables de entrada. No hay una salida a predecir que pueda guiar a los algoritmos. Por ello, los modelos generados, en caso de existir, no son predictivos sino descriptivos. Las tareas más comunes son las siguientes:

• Agrupamiento. Analizando la similitud/disimilitud de las muestras de datos, por ejemplo, calculando la distancia a que se encuentran unas de otras en el espacio generado por los valores de sus variables, se crean varios grupos disjuntos. Esta técnica, también conocida como clustering, facilita la exploración visual de los datos, pudiendo emplearse también como un método de clasificación básico cuando no se dispone de las etiquetas de clases necesarias para generar un clasificador.
• Asociación. La búsqueda de asociaciones entre ciertos valores de las variables que componen las muestras se efectúa buscando la concurrencia entre ellos, es decir, contando las veces que aparecen simultáneamente. Este tipo de problema puede generar como resultado un conjunto de reglas de asociación, siendo una técnica muy empleada en todo tipo de comercios, tanto electrónico como físico, para disponer sus productos o recomendarlos.
• Reducción de variables. Mediante el análisis de la distribución de los valores de las variables en el conjunto de muestras, es posible determinar cuáles de ellas aportan más información, cuáles están correlacionadas con otras y por tanto son redundantes o si es posible encontrar una distribución estadística subyacente que genera esos datos, lo cual permitiría simplificar su representación original. En este tipo de tarea existen multitud de técnicas posibles, desde la selección y extracción de variables hasta lo que se denomina manifold learning, consistente en encontrar la citada distribución subyacente.

Nota: de los citados aquí, los algoritmos de agrupamiento y de asociación generarían un modelo descriptivo. En el primer caso aportaría información sobre la forma en que se agrupan las muestras de datos, la distancia que hay entre muestras de un mismo grupo y lo diferentes que son respecto a muestras de otros grupos. En el segundo, las reglas y métricas asociadas a ellas conforman un modelo que permite conocer casuísticas específicas del problema analizado.

Otros tipos de tareas de aprendizaje

Una gran mayoría de los problemas abordables mediante aprendizaje automático pertenecen a las categorías enumeradas en los dos apartados previos. No obstante, existen otros tipos de tareas que precisan de enfoques diferentes. Un ejemplo serían los problemas de optimización en general, de los cuales quizá el exponente más conocido es el del viajante del comercio. Esta tarea consiste en buscar el itinerario más corto para visitar n ciudades. En el momento en que n es muy grande el problema se vuelve inabordable a la búsqueda exhaustiva: evaluar todas las posibles alternativas para determinar la mejor.

Existen muchos otros casos dentro de esta categoría y la dificultad suele ser siempre la misma: no se conoce el caso óptimo, por lo que no puede saberse si una potencial solución es más o menos buena, y el número de posibles soluciones, o de pasos para llegar hasta ellas, es enorme. Existen dos categorías de técnicas que suelen aplicarse para afrontar estos problemas:

• Algoritmos bioinspirados. Forman parte de este grupo los algoritmos genéticos, estrategias evolutivas, optimización basada en sistemas de partículas, etc. Todos ellos parten de un mismo concepto: reproducir mecanismos existentes en la naturaleza como puede ser la selección evolutiva en los seres vivos, el comportamiento de bandadas de pájaros, de colonias de hormigas, etc. Gracias a ellos es posible encontrar una solución aceptable al problema de optimización en un lapso de tiempo razonable.
• Aprendizaje por refuerzo. Este paradigma, descrito al inicio del apartado, puede aplicarse también a problemas de optimización, si bien en los últimos tiempos ha ganado notoriedad por su éxito a la hora de aprender a jugar y ganar determinados juegos, desde el Super Mario Bros a ajedrez o Go.

Como puedes comprobar, existen multitud de problemas que pueden ser resueltos mediante el aprendizaje automático.

El primer paso suele ser determinar la categoría del problema que se afronta para, a continuación, seleccionar el paradigma de aprendizaje más adecuado. Estos dos factores nos permitirán, en un paso posterior, elegir la herramienta de trabajo más adecuada.

Una nueva investigación sugiere que la lectura de código informático no depende de las regiones del cerebro que participan en el procesamiento del lenguaje.

En cierto modo, aprender a programar un ordenador es similar a aprender un nuevo idioma. Requiere aprender nuevos símbolos y términos, que deben organizarse correctamente para indicar al ordenador qué debe hacer. El código de un ordenador también debe ser lo suficientemente claro como para que otros programadores puedan leerlo y entenderlo.

A pesar de esas similitudes, los neurocientíficos del MIT han descubierto que leer código no activa las regiones del cerebro que están involucradas en el procesamiento del lenguaje. En su lugar, activa una red distribuida llamada red de demanda múltiple, que también se emplea para tareas cognitivas complejas, como resolver problemas matemáticos o crucigramas.

Sin embargo, aunque la lectura de código activa la red de demanda múltiple, parece depender en realidad de diferentes partes de la red que los problemas matemáticos o lógicos, lo que sugiere que programar tampoco replica con precisión las demandas cognitivas de las matemáticas.

"Comprender el código informático parece ser algo propio. No es lo mismo que el lenguaje, y no es lo mismo que las matemáticas y la lógica", dice Anna Ivanova, del MIT, autora principal del estudio.

Lenguaje y cognición

Un enfoque principal de la investigación es la relación entre el lenguaje y otras funciones cognitivas. En particular, han estudiado la cuestión de si otras funciones dependen de la red de lenguaje del cerebro, que incluye el área de Broca y otras regiones del hemisferio izquierdo del cerebro. En un trabajo anterior, su laboratorio demostró que la música y las matemáticas no parecen activar esta red lingüística.

"Aquí, estábamos interesados ​​en explorar la relación entre el lenguaje y la programación, en parte porque la programación es algo tan nuevo que sabemos que no puede haber ningún mecanismo 'precableado' que nos haga buenos programadores", dice Ivanova.

Hay dos escuelas de pensamiento con respecto a cómo el cerebro aprende a programar, dice:

• Uno sostiene que, para ser bueno en programación, debes ser bueno en matemáticas.
• El otro sugiere que, debido a los paralelismos entre codificación y lenguaje, las habilidades lingüísticas podrían ser más relevantes.

Para arrojar luz sobre este tema, los investigadores se propusieron estudiar si los patrones de actividad cerebral al leer el código de la computadora se superpondrían con la actividad cerebral relacionada con el lenguaje.

Los dos lenguajes de programación en los que se centraron los investigadores en este estudio son conocidos por su legibilidad: Python y ScratchJr, un lenguaje de programación visual diseñado para niños de 5 años en adelante. Los sujetos del estudio eran todos adultos jóvenes que dominaban el lenguaje en el que estaban siendo evaluados. Mientras los programadores se encontraban en un escáner de resonancia magnética funcional (fMRI), los investigadores les mostraron fragmentos de código y les pidieron que pronosticaran qué acción produciría el código.

Los investigadores vieron poca o ninguna respuesta al código en las regiones del lenguaje del cerebro. En cambio, encontraron que la tarea de codificación activaba principalmente la llamada red de demanda múltiple. Esta red, cuya actividad se extiende a lo largo de los lóbulos frontal y parietal del cerebro, generalmente se activa para tareas que requieren tener en mente muchos datos a la vez, y es responsable de nuestra capacidad para realizar una amplia variedad de tareas mentales. "Hace prácticamente cualquier cosa que sea cognitivamente desafiante, que te hace pensar mucho", dice Ivanova.

Estudios anteriores demostraron que los problemas matemáticos y lógicos parecen depender principalmente de las múltiples regiones de demanda en el hemisferio izquierdo, mientras que las tareas que involucran la navegación espacial activan el hemisferio derecho más que el izquierdo. El equipo del MIT descubrió que leer código parece activar tanto el lado izquierdo como el derecho de la red de demanda múltiple, y ScratchJr activó el lado derecho un poco más que el izquierdo.

Este hallazgo va en contra de la hipótesis de que las matemáticas y la programación se basan en los mismos mecanismos cerebrales.

Efectos de la experiencia

Los investigadores dicen que, si bien no identificaron ninguna región que pareciera estar dedicada exclusivamente a la programación, tal actividad cerebral especializada podría desarrollarse en personas que tienen mucha más experiencia en programación.

"Es posible que, si se toma a personas que son programadores profesionales, que han pasado 30 o 40 años codificando en un lenguaje en particular, pueda comenzar a ver alguna especialización o cristalización de partes del sistema de demanda múltiple", dice Evelina Fedorenko, la autora sénior del estudio. "En las personas que están familiarizadas con la programación y pueden realizar estas tareas de manera eficiente, pero que han tenido una experiencia relativamente limitada, parece que todavía no ve ninguna especialización".

En un artículo complementario que aparece en el mismo número de eLife, un equipo de investigadores de la Universidad Johns Hopkins también informó de que la resolución de problemas de código activa la red de demanda múltiple en lugar de las regiones del lenguaje.

Los hallazgos sugieren que no hay una respuesta definitiva a si la codificación debe enseñarse como una habilidad basada en matemáticas o una habilidad basada en el lenguaje. En parte, eso se debe a que aprender a programar puede basarse tanto en el lenguaje como en múltiples sistemas de demanda, incluso si, una vez aprendido, la programación no depende de las regiones del lenguaje, dicen los investigadores.

"Ha habido reivindicaciones de ambos bandos: tiene que estar junto con las matemáticas, tiene que estar junto con el lenguaje”, dice Ivanova. "Pero parece que los educadores en ciencias de la computación tendrán que desarrollar sus propios enfoques para enseñar código de manera más efectiva".

Artículo original: To the brain, reading computer code is not the same as reading language

Hace unos días, nuestro tutor José Manuel Alarcón mantuvo una interesante conversación con Francisco Charte y David Charte, nuestros dos expertos en Inteligencia Artificial autores del Máster Online de Machine Learning de campusMVP. A lo largo de la charla hemos intentado entender qué son estas disciplinas, cómo se diferencian de la programación convencional, la importancia que tienen los datos, aplicaciones reales... y muchas cosas más.

Cuando hay un avance tecnológico de este calibre suelen crearse mucho humo y mitos alrededor, y un vídeo como éste puede ser una buena puerta de entrada para demitificarle este campo a muchos desarrolladores que quizá piensen que no está a su alcance o que simplemente no se habían planteado la gran oportunidad de futuro que hay en él.

Más abajo tienes la charla completa, pero te dejamos también aquí el índice por si prefieres ir a algún momento concreto:

• 00:35 Inicio de la charla
• 00:59 Presentación de Francisco y David
• 03:16¿Qué son AI, ML, Ciencia de Datos, Big Data...?
• 06:02 Diferencias entre programación convencional y programación Machine Learning
• 08:28 ¿La IA quitará el trabajo a los programadores?
• 11:10¿Cómo es la programación para Machine Learning?
• 17:08 La importancia de los datos en Machine Learning
• 19:44 Aplicaciones reales de Machine Learning en empresas
• 24:20¿Necesito saber muchas matemáticas para aprender Machine Learning?
• 26:15 Qué cubre el nuevo Máster de Machine Learning de campusMVP
• 28:59 Ejemplos concretos que se desarrollan en el máster
• 33:07 Despedida

[youtube:x3VF_zuxLyQ]

Si no quieres perderte este tipo de vídeos (pronto vendrán más) así como los vídeos prácticos que publicamos en el canal, no te olvides de suscribirte😉

[youtube:96sSb0Pg5d4]

100 años de la palabra "Robot"

El 25 de enero de 1921, el dramaturgo checo Karel Čapek y su hermano Josef acuñaron el término en su obra Robots Universales Rossum (R.U.R) basándose en el término checo "robota", que significa esclavo.

En la obra los robots están hechos de carne sintética, o sea, que no son máquinas, sino orgánicos, y además pueden pensar por si mismos. Al principio, trabajan de buen grado para los humanos, pero por supuesto acaban revelándose.

Angular lanza sus guías de depuración

Una de las prioridades en el roadmap del equipo de Angular es el mejorar la experiencia de depuración con el framework. Así que acaban de lanzar una nueva sección en su documentación con unas guías de depuración muy interesantes con los errores más comunes que se producen con el framework.

Las guías incluyen sendos vídeos (en inglés, eso sí), además de detalles por escrito.

Además han estandarizado los códigos de error para que sea más fácil determinar qué ha pasado cuando rompe algo.

• Anuncio en el blog de Angular con todos los detalles
• Documentación de errores

Open Web Docs

Esta semana se ha presentado la iniciativa Open Web Docs. Como sabes, la principal fuente de documentación sobre tecnologías Web de Front-End es la MDN o Mozilla Developer Network, que todos los fabricantes de navegadores acordaron utilizar como documentación en 2017. Pero Mozilla tuvo que despedir a más de 250 trabajadores el año pasado, entre los que estaban muchos dedicados a mantener la MDN.

Como la cosa peligra bastante, se han juntado Google, Microsoft, Apple, Mozilla... y algunas otras empresas y colectivos como la W3c, Samsung o la empresa gallega Igalia (grandes contribuidores al Open Source de los navegadores). Lo que han hecho es crear una fundación para poder donar legalmente dinero a la MDN y otros proyectos, y garantizar así su supervivencia y calidad.

O sea, Open Web Docs no sustituye a la MDN sino que intenta garantizar su supervivencia. Lo explican muy bien en su vídeo de los triangulitos y los circulitos (ver más abajo).

Ya han donado bastante dinero los fundadores, así como muchos particulares. Te animamos desde aquí a donar si le sacas partido a la MDN habitualmente, como cualquier desarrollador Web hoy en día.

• Open Web Docs
• ¿Qué es el Open Collective? (video de los triángulos y los circulitos)

La biblioteca ECharts se convierte en proyecto Apache de primer nivel

ECharts es una potente biblioteca de JavaScript gratuita y open source que permite crear visualizaciones de datos con gráficas 2D y 3D muy espectaculares. También permite hacer análisis multidimensional de datos.

Acaba de liberar su versión 5 y ahora se ha convertido en un proyecto Apache de primer nivel, lo que quiere decir que han cumplido con todas los principios y el proceso de meritocracia de la fundación Apache, lo que garantiza su calidad y continuidad en el tiempo.

Lo utilizan GitLab, Intel, Amazon y muchas otras empresas.

• Anuncio oficial
• Página oficial de ECharts
• Código fuente de ECharts en GitHub

Deno 1.7 con mejoras de compilación

Esto es en realidad de la semana pasada, pero quedó fuera por descuido. Deno, la alternativa segura a Node.js, creada por el "padre" de Node.js y basado en TypeScript, ha lanzado su versión 1.7 con varias mejoras, sobre todo en lo que respecta a la compilación. Ahora permite hacer compilación para múltiples sistemas y arquitecturas desde el mismo ordenador. Por ejemplo, desde Linux podemos compilar para Linux 32 y 64, para Windows y macOS x64. Además los binarios son ahora entre un 40 y un 60% más pequeños y con los permisos más controlados.

• Todas las novedades de Deno 1.7

Flash deja sin tren durante un día a una provincia china

¿Te acuerdas de que la semana pasada comenté que Flash desaparecía de Chrome? Bueno, en realidad no solo era eso, sino que directamente dejaba de funcionar, como ya lleva anunciando Adobe durante más de 3 años. Pues esta semana, coincidiendo con la fecha límite, todos los trenes de la provincia de Dalian, al sur de China, dejaron de funcionar porque todo su sistema de control sigue estando hecho en Flash. Para solucionarlo tuvieron que instalar una versión pirateada antigua del visor 🤦‍♂️

Y no son los únicos: en Sudáfrica han lanzado un navegador propio para poder usar Flash y que no se les caigan muchos sistemas gubernamentales.

• Adobe Flash Shutdown Halts Chinese Railroad for Over 16 Hours Before Pirated Copy Restores Ops
• South African government releases its own browser just to re-enable Flash support

Al igual que ocurre con Blazor Server, cuando utilizamos Blazor WebAssembly hosteado en una aplicación ASP.NET Core, podemos usar prerrenderización, de forma que el resultado de la ejecución del componente Blazor llegue al cliente insertado directamente en la página contenedora, de forma que:

• El usuario tendrá una sensación de carga mucho más rápida, porque podrá visualizar la página completa, eliminando el clásico mensaje "Loading..." que aparece en el navegador mientras se descargan los recursos estáticos. Una vez con el contenido en el navegador, dichos recursos serán descargados y la aplicación comenzará a funcionar normalmente.
• De nuevo, facilitaremos que los motores de búsqueda puedan indexar los contenidos de nuestras páginas, al obtener por completo su contenido.

El funcionamiento es muy parecido al prerrenderizado enBlazor Server, aunque en este caso hay una diferencia importante en el hecho de que la página contenedora es un simple HTML, lo cual, a priori, limita las posibilidades de prerrenderización de los componentes en el lado servidor.

Por ello, si queremos usar prerrenderización de la aplicación Blazor WebAssembly, tendremos que seguir un procedimiento que, aunque sencillo, es algo farragoso.

En primer lugar, debemos hacer que la página index.html deje de ser la página de arranque del proyecto WebAssembly. Esto tiene sentido, pues necesitamos que la página contenedora sea procesada en el servidor para poder incluir en ella el resultado de la ejecución de los componentes Blazor.

Dicho archivo podemos eliminarlo y, en su lugar, añadir a la carpeta /Pages del proyecto ASP.NET Core un archivo _Host.cshtml que será la nueva página contenedora. El contenido de este archivo puede ser el mismo que usamos en cualquier proyecto Blazor Server, aunque será necesario hacerle algunos retoques:

• La directiva @namespace del encabezado habrá que hacerla coincidir con el espacio de nombres exacto de la página.

  @namespace MyProject.Server.Pages

• Será necesario añadir un using para referenciar en la página el espacio de nombres donde se define el componente raíz de Blazor; normalmente, será simplemente el nombre completo del proyecto Client de la solución

  @using MyProject.Client

• En la sección <head> de la página, debemos referenciar los recursos de estilo:

  <link href="css/app.css" rel="stylesheet" /><link href="MyProject.Client.styles.css" rel="stylesheet" />

• A continuación modificamos el modo de renderización del tag helper<component>, como sigue, para activar la prerrenderización:

  <component type="typeof(App)" render-mode="WebAssemblyPrerendered" />

• Por último, ya en el pie de la página, debemos reemplazar el cliente JS blazor.server.js por blazor.webassembly.js.

Todavía en el proyecto Server, en el archivo Startup.cs debemos modificar el fallback para que las peticiones no sean gestionadas por index.html, sino por la página que hemos creado:

app.UseEndpoints(endpoints =>
{
    endpoints.MapRazorPages();
    endpoints.MapControllers();
    endpoints.MapFallbackToPage("_Host.cshtml");
});

Y ya para finalizar, debemos acudir al archivo Program.cs del proyecto Blazor WebAssembly y eliminar la línea que define el componente raíz de la aplicación, pues el tag helper que hemos colocado en la página contenedora ya se está encargando de ello:

// Eliminar la siguiente línea:
builder.RootComponents.Add<App>("#app");

 ¡Listo! De esta manera conseguiremos que la página inicial se renderice en el servidor y conseguirmos los beneficios de velocidad de carga inicial y SEO mencionados al principio.

[youtube:M-D1SZdqDy8]

npm 7 ya disponible

Aunque lleva meses en beta, esta semana se ha liberado por fin la versión definitiva de la versión 7 del gestor de paquetes de Node.js. Tiene una novedad que destaca sobre las demás: la posibilidad de crear "workspaces" que básicamente te permiten gestionar varios paquetes o proyectos de npm con un sola configuración en la raíz. Era algo que ya tenían Yarn o Pnpm y que viene muy bien para algunos flujos de trabajo. También es capaz de instalar dependencias de tipo "peer" (para plugins), y trae un nuevo formato de archivos de bloqueo.

• Anuncio de npm 7 CLI disponible
• Anuncio de nuevas características de npm 7 - En el blog antiguo, antes de cambiar al de GitHub tras la compra.
• La característica de workspaces explicada
• ¿Qué son las dependencias peer en npm?

WebRTC se ha convertido por fin en estándar

Aunque pudieras pensar lo contrario, WebRTC no era todavía un estándar definitivo. Crear un estándar es un proceso muy largo y lento, y aunque hace años que esta especificación se utiliza de manera más o menos estable, ha sido esta semana cuando lo han cerrado y reconocido como tal el W3C y el IETF. Es un hito importante y más con la relevancia que han tomado las comunicaciones de audio y vídeo en tiempo real durante el último año.

• Nota de prensa oficial del W3C sobre WebRTC
• La documentación oficial del estándar WebRTC

Google Cloud SQL Insights

Google Cloud SQL es el servicio de bases de datos gestionado por Google, que permite utilizar MySQL, SQL Server o PostgreSQL en la nube, despreocupándote de su gestión, escalabilidad, etc...

Esta semana Google ha presentado esta nueva funcionalidad para el servicios, los Insights, que facilita el entender y solucionar problemas de rendimiento de tus bases de dato en la nube de Google. Te proporciona estadísticas, gráficas y trazas para poder analizar fácilmente muchos problemas de rendimiento.

• Google Cloud SQL
• Presentación de Insights

Sincronización automática entre MondgoDB y Realm

Realm es una conocida base de datos embebida que se utiliza en multitud de aplicaciones móviles con lenguajes como Swift, Java, C# o incluso JavaScript. Es una gran alternativa a SQLite porque es más sencilla de programar, está orientada a objetos y se creó desde el principio para móviles. También es Open Source y gratuita.

Ahora MongoDB acaba de anunciar Realm Sync, un servicio que permite sincronizar automáticamente datos entre MongoDB Atlas, su servicio cloud, y Realm. Esto está muy bien porque te permite sincronizar automáticamente los datos locales de tus usuarios en una aplicación móvil con una base de datos en la nube, sin complicarte la vida, y poder acceder a ellos desde otros clientes (Web, escritorio...).

• Sitio web de MongoDB
• Sitio web de la base de datos móvil Realm
• MongoDB Atlas - Tiene una capa gratuita generosa
• Documentación de Realm Sync con MongoDB
• Vídeo práctico de uso de Realm Sync

Azure Quantum disponible públicamente

Esta semana Microsoft ha abierto para todo el que le interese el acceso a su producto Azure Quantum. Se trata de una plataforma cloud que te permite hacer uso de ordenadores cuánticos básicos para experimentar con esta tecnología futurista. Aunque Microsoft no ha logrado todavía sus propios QBits estables, sí que tiene un kit de desarrollo para computación cuántica y un lenguaje de programación, Q#, y a través de Azure Quantum te da acceso a computadores cuánticos de empresas como Honeywell, IonQ, 1Qubit y otras.

Ya la habían abierto el pasado mayo a unos pocos elegidos, pero ahora está para todo el mundo.

Si te interesa aprender y experimentar con tecnología futurista, puedes usarlo gratis durante 1 hora, y luego pasa a costar 10$ a la hora, aunque toda la documentación y las herramientas son gratuitas.

• Anuncio de disponibilidad pública de Azure Quantum
• Azure Quantum
• Introducción a Azure Quantum (vídeo)
• Machine Learning Cuántico y Azure Quantum (vídeo)

No es la primera vez, ni mucho menos, que hablamos de Inteligencia Artificial (IA) y aprendizaje automático. Ya conocemos los conceptos y algunas de las soluciones más curiosas que podemos crear con ellos, sin embargo, aún no hemos explorado las posibilidades que nos pueden ofrecer de cara a una pequeña o mediana empresa.

En este artículo te hablaré de algunos ejemplos que no son difíciles de implementar en un negocio y pueden aportar cierta ventaja frente a los que no cuenten con estas tecnologías.

Conocer a la clientela

Las grandes empresas que cuentan con equipos de marketing son capaces de estudiar ampliamente el mercado e identificar distintos segmentos de clientes. En el caso de una pequeña empresa, no siempre se dispone de empleados que se puedan centrar en estas tareas, que en ocasiones son útiles para saber la aceptación que tienen los productos en diferentes tipos de población.

Las herramientas de agrupamiento inteligentes pueden ser una ayuda que resuelva las tareas de segmentación del mercado, ya que pueden analizar los datos de compras y clientes y, en base a ellos, reconocer diferentes grupos de datos que se relacionan entre sí por sus características. Una vez que se obtiene el agrupamiento de los datos, se puede explorar qué aspectos tienen en común y en qué se diferencian unos grupos de otros.

Si tenemos, por ejemplo, una librería, esto nos puede ayudar a decidir cómo organizar las estanterías por temas: tal vez parezca lógico ubicar los libros de ciencia ficción y los de fantasía cerca, pero el agrupamiento puede que revele otras relaciones nada obvias que sean también útiles para que un determinado tipo de cliente siempre tenga a la vista todo lo que le pueda interesar, aumentando así las ventas.

Predecir las necesidades de los clientes

En un negocio de cara al público es crucial poder adaptarse a cada cliente y ofrecerle los productos que más le puedan interesar. Este trato puede diferenciar a una pequeña tienda de una gran superficie y hacer que los clientes la prefieran. Con el auge de las compras online en la actualidad, un sistema de recomendaciones basado en aprendizaje automático nos puede ayudar a replicar esa ventaja de comprar en pequeñas tiendas, dando la posibilidad de consultar productos recomendados directamente desde una búsqueda o una página de producto.

Un sistema de recomendaciones es capaz de contemplar las relaciones entre los diferentes productos de nuestra tienda, las posibles similitudes entre los diferentes clientes, o incluso ambas cosas simultáneamente.

Por ejemplo, supongamos que queremos mejorar el sistema de compra online de una librería. Si ya disponemos de los elementos básicos como los listados de libros, la búsqueda y el sistema de pedidos, podemos incorporar un mecanismo de recomendación de libros basados en las consultas de los clientes y sus compras previas, teniendo en cuenta varios posibles atributos de estos. El sistema podría tener varios usos:

• En la página de un producto, incluir un módulo de "libros relacionados" basados en las características del libro consultado, sin importar que el catálogo sea muy grande.
• En la página del carrito de la compra, añadir una sección con otros artículos que suelen comprarse junto a los que ya se han seleccionado.
• Cuando el cliente complete un pedido, anticipar una posible compra futura (por ejemplo, de un libro lanzado recientemente del mismo género) y proporcionar al cliente un código de descuento por e-mail para propiciar la compra.

Todo esto de manera automatizada y con una efectividad elevada en las recomendaciones.

Anticipar fallos en maquinaria

Si nuestra empresa es una fábrica pequeña o mediana, no será extraño que contemos con algún tipo de máquinas para agilizar los procesos y manipular los productos de forma rápida y eficiente o bien de formas que un humano no sería capaz, como prensar enormes cantidades de aceituna o uva, doblar y cortar con precisión piezas de metal, tejer y coser prendas, etc.

Un proceso fundamental en este tipo de industrias es el mantenimiento periódico de la maquinaria, para prevenir posibles fallos habituales en las máquinas. Aún así, pueden ocurrir algunos imprevistos, y sería conveniente contar con un sistema de predicción que se anticipase a ellos. Este problema atrae mucha investigación tanto del mundo académico como desde la industria, en muchas ocasiones colaborando para encontrar soluciones que tengan una buena base teórica y que se puedan poner en producción.

Algunas de las metodologías que se aplican a estas situaciones son las técnicas de predicción de series temporales y las de optimización. Estas nos permitirán analizar todos los datos previos provenientes de sensores y otros componentes de las máquinas, y construir un modelo que aproveche esa información para monitorizar los valores y detectar anomalías o tendencias que puedan preceder a un fallo.

Prevenir ataques online

Un riesgo al que se expone todo negocio con una presencia online es el de las amenazas de ciberseguridad. Se pueden sufrir tanto ataques automatizados, mediante bots que escanean las redes en busca de vulnerabilidades que se puedan explotar, como ataques dirigidos, donde una o más personas son responsables de atacar a un sitio concreto. Algunos de los ataques se pueden evitar sorteando las posibles vulnerabilidades, otros pueden tener mecanismos de reconocimiento específicos, pero para muchos no tendremos un medio fácil de detección.

Existe una gran variedad de técnicas inteligentes que son capaces de analizar los registros de accesos de los servidores, incluso en tiempo real, e identificar posibles comportamientos anómalos que tengan los clientes. Esto nos puede ayudar a lanzar una alarma cuando se reconozcan accesos que son diferentes a los habituales, y que una persona pueda tomar una decisión al respecto para solucionar la situación en caso de ataque. Incluso, en algunos casos decidir hacer bloqueos de manera automática.

Conclusiones

Acabamos de conocer cuatro maneras de sacar partido a las nuevas tecnologías de aprendizaje automático que pueden dar a un negocio una ventaja frente a los que no las implementen. Desde luego, son solo unos pocos de todos los posibles usos que podríamos darle a este tipo de herramientas, cada vez más utilizadas y que facilitan el funcionamiento interno de las empresas y sus relaciones con los clientes.

Espero que te hayan parecido interesantes y que te inspiren otras aplicaciones posibles que puedan ser útiles para tus proyectos.

Te dejo un par de enlaces con algunas ideas adicionales que quizá encuentres interesantes:

• Forbes: 14 maneras inteligentes de aprovechar el machine learning para pequeñas empresas (en inglés)
• Microsoft: IA y machine learning para pequeñas empresas (en inglés)