Con estos webinars online puedes aprender a programar gratis durante junio

04/06/2020
Artículo original

Con estos webinars online puedes aprender a programar gratis durante junio

Aquellos usuarios que quieran aprovechar el comienzo del verano para iniciarse en el desarrollo de software están de enhorabuena: Le Wagon, una startup con centros de enseñanza de programación presente en 38 ciudades de 20 países, acaba de anunciar el lanzamiento de varios webinars gratuitos para abordar conceptos básicos de programación.

A causa de la crisis del coronavirus, esta oferta informativa se impartirá 100% online (aunque, eso sí, en inglés), pero "los profesores darán todo el apoyo necesario y responderán a todas las dudas de los alumnos a través de esta vía".

Dichos cursos están pensados en los que desean formarse en habilidades tecnológicas para afrontar el futuro del mercado de trabajo: así, podrán tener un primer contacto con lenguajes como JavaScript o Python, o con áreas como el diseño web (HTML, CSS), bases de datos (SQL), la creación de prototipos de apps móviles o el diseño de experiencia de usuario.

Los webinars, a los que puedes apuntarte en esta web, tendrán una duración de dos horas y se irán realizando a lo largo de este mes, empezando el próximo martes 9. Son los siguientes:

  • Code your first website with HTML & CSS

  • Prototype your app in 1 hour with Figma

  • Get started in UI Design with Figma

  • Learn how to automate tasks with APIs

  • Get started with Javascript

  • Learn how to query databases with SQL

  • Data Analytics with Python

  • Web Scraping with Python

Iniciarse en la programación como alternativa la crisis

Según Le Wagon, la crisis económica en ciernes está empujando a muchos profesionales a buscar pastos más verdes en el sector tecnológico, una reinvención profesional que requiere formación extra, en palabras de Gus De Vita, fundador de Le Wagon España:

"Hemos notado un gran aumento de solicitudes debido a la incertidumbre generada por el Covid-19. Muchos afectados por los despidos y los ERTE se toman este periodo como una oportunidad para reinventarse".

"El mercado tecnológico es uno de los que menos impacto han sufrido durante la crisis del coronavirus, por lo que es un sector donde existe una gran oportunidad a nivel laboral".

A la hora de ofrecer sus cursos de pago (como el curso intensivo de 9 semanas de Desarrollador Web que ofrece en Madrid en Barcelona) Le Wagon apuesta por un modelo de negocio poco habitual: cobrar únicamente cuando el alumno consiga trabajo.

De hecho, la compañía asegura haber formado ya a "más de 7.000 alumnos a nivel mundial que han conseguido trabajo en empresas líderes del mercado tales como Google, Amazon, Uber, Facebook, Apple, Microsoft...".

Las cinco mejores tipografías open source para tu editor de código y tu terminal

31/05/2020
Artículo original

Las cinco mejores tipografías open source para tu editor de código y tu terminal

Cuando nos pasamos muchas horas frente a una pantalla, nos gusta poder disponer de una tipografía fácil y agradable de leer. Por comodidad o desconocimiento, muchas veces nos conformamos con las tipografías monoespaciadas que nuestro sistema operativo incluye por defecto... pero pueden no ser la mejor opción.

Si además, la mayor parte de ese tiempo lo pasamos escribiendo código (o peor, revisándolo), es habitual que busquemos una tipografía de referencia, para no vernos obligados a 'hacer' la vista a una nueva cada vez que cambiamos de aplicación.

De modo que hemos preparado una breve selección de las 5 tipografías monoespaciadas 'open source' que te recomendamos para usar en la terminal o a la hora de picar código:

Fira Code

Fira Code Ejemplos de ligaduras de programación, bajo el nombre de la tipografía.

Fira Code es una tipografía desarrollada por Mozilla (a partir de Fira Mono) y que podemos encontrar, por ejemplo, en los proyectos de JetBrains (los creadores de IntelliJ y Kotlin).

Posiblemente uno de de los tipos de letra más populares entre los programadores gracias a su amplia gama de ligaduras, y a detalles como la puntuación dependiente del contexto.

Puntuacion

Las ligaduras de programación son un recurso que permite, por ejemplo, mostrar el operador '->' como un único carácter (una flecha), ahorrándoles unos pequeñas milésimas de segundo a nuestras ojos y cerebros mientras leemos el código.

Esta tipografía, que destaca también por su amplio soporte para símbolos ASCII y matemáticos, está igualmente disponible en repositorios Linux y, como la anterior, con un nombre que varía según la distribución: font-firacode, fira-code-fonts, ort-fira-code...

Cascadia Code

Cascadia

Hace un año, durante su penúltimo evento Build, Microsoft anunció el lanzamiento de una tipografía 'open source' específicamente diseñada para ser usada en editores de código y terminales de línea de comandos: Cascadia Code.

De hecho, la idea era que llegara a muchos ordenadores de la mano de Windows Terminal, software al que acompañaba y homenajeaba (el nombre en clave del mismo antes de ser presentado fue, precisamente, Cascadia).

Por supuesto, Cascadia incluye las famosas ligaduras:

"Las ligaduras de programación son más útiles cuando se escribe código, ya que crean nuevos glifos combinando caracteres. Esto ayuda a que el código sea más legible y fácil de usar para algunas personas".

Iosevka

Iosevka

Más que una tipografía, Iosevka es una familia de las mismas: 15 variantes, cada una de ellas de ellas desdobladas en la modalidad sans serif y slab serif, y con sus correspondientes formatos normal, negrita, cursiva y negrita-cursiva. Una amplia gama de opciones la de estas tipografías open source.

Dos de las variantes, Iosevka Term y Iosevka Fixed están especialmente optimizadas para su uso en emuladores de terminal, según explica su página web oficial. En el caso de esta última variante, "las ligaduras se desactivan para garantizar una mejor compatibilidad en ciertos entornos".

Otras tres variantes (Iosevka Aile, Iosevka Etoile y Iosevka Sparkle) no son monoespaciadas sino 'cuasi-proporcionales' y están optimizadas para escritura y documentación técnica.

La misma web ofrece más datos sobre la tipografía: 6391 glifos incluidos (cada uno de exactamente 1/2 em de ancho), 159 idiomas soportados, 15 clases de ligaduras, etc.

Hack / Hæck

Hack

Hack es una familia de tipografías 'open source', disponible en sus cuatro variaciones (normal, negrita, cursiva y negrita-cursiva) diseñada con el objetivo de optimizar su legibilidad en pantalla, incluso a tamaños de texto pequeños.

Otro de los objetivos planteados por sus creadores fue el de ofrecer compatibilidad en un gran número de idiomas, por lo que incluye 1500 glifos de alfabetos basados en el latino, el griego y el cirílico.

Ofrece un instalador específico para Windows que simplifica su incorporación a nuestra lista de fuentes. Los usuarios de Linux pueden encontrarla en sus correspondientes administradores de paquetes bajo diversos nombres (ttf-hack, hackfont, fonts-hack-ttf, hack-fonts...).

Haeck Modalidad 'Hæck', dotada de ligaduras.

Su código está disponible en Github, y su licencia 'open source' es muy permisiva y permite desde la modificación al uso comercial. Gracias a ello existe una versión de Hack llamada "Hæck", que se caracteriza por incluir ligaduras.

Inconsolata

Inconsolata

Inconsolata es una tipografía 'open source' que no sólo es muy legible en pantalla, sino que -al contrario que otras de esta clase- sigue siendo igual de legible cuando pasa a estar impresa en papel.

Incluye ligaduras de programación para algunos de los operadores más habituales, y -según explica su autor- copia de tipografías japonesas el uso de 'microserifas' para aumentar la nitidez del resultado final.

Cuenta con una variante experimental (desarrollada poR el mismo creador que la original) que incorpora comillas rectas y a la que se conoce como InconsolataGo.

Mi página Web Forms con UpdatePanel se carga el hash (#) de la dirección

29/05/2020
Artículo original

Imagen ornamentalBueno, esto es tecnología viejuna pero que está en uso en miles (o millones) de Web de todo el mundo, incluyendo este blog en el momento de escribir esto en 2020. La maravillosa tecnología ASP.NET Web Forms fue un invento de Scott Guthrie (sí, ese Scott del polo rojo que manda tanto en Microsoft y parece un tipo tan majo) que permitía crear aplicaciones Web orientadas a datos aunque no tengas mucha idea de la Web. Y de hecho aún lo permite, viene incluida de serie en Windows junto con la plataforma .NET, y sigue siendo muy interesante para ciertos tipos de aplicaciones.

Precisamente lo mejor que tiene, es también lo peor: es tan fácil crear algunas aplicaciones sin entender bien qué está ocurriendo que luego "pasan cosas". Esta tecnología se basa en la inclusión de un formulario envolviendo toda la página, que además tiene que ser único, y que ante cualquier acción se envía al servidor y vuelve a la misma página (postback), transfiriendo entre llamadas unos datos llamados ViewState que, como su propio nombre indica, contienen el estado de la página. Este ViewState si no lo controlas puede llegar a pesar muchísimo y a ralentizar las páginas, pero se puede y se debe controlar si conoces bien la tecnología. Más adelante le añadieron soporte para llamadas AJAX de modo que ni siquiera la página tenía que recargarse, para lo cual introdujeron el ScriptManager y el UpdatePanel, dos piezas clave de esta tecnología.

Bien, el caso es que hay un efecto secundario del uso de estas tecnologías que puede volverte loco, aunque no se da con frecuencia. Si utilizas algún tipo de hash en tu URL (esas direcciones que terminan en un # con algo a continuación y que sirven para navegación interna en la página) de modo que permitas saltar directamente a alguna parte de la página, tanto los Web Forms "puros" como los UpdatePanel para AJAX se lo cargan.

El típico ejemplo es una página con varios "tabs" para mostrar información diferente según el que pulses. Puedes cambiar  de uno a otro pulsando en las cabeceras y mantienes cuál es el que está abierto simplemente anotando el identificador con un hash: mipagina.aspx#tab1 y similares.

Bien, el problema es que al actualizar la página con un UpdatePanel, ese #tab1 desaparece, y no puedes mantener la interfaz en donde estaba: te va a cambiar el hash y te dejará tan solo un #, moviéndote la página para arriba del todo, por lo que si tus tabs estaban hacia abajo, pierdes el estado del scroll también. Un horror.

¿Cómo lo solucionamos?

El problema lo produce una función de la infraestructura del Update Panel que se llama _setState y cuyo código es el que se ve en esta figura:

El código del método _setState

Este código por algún motivo toquetea el contenido de la URL actual y en concreto su hash. Sinceramente no tengo ni idea de lo que hace ni he logrado encontrar por ahí información, ya que es código no documentado e interno de cómo funcionan el ScriptManager y el UpdatePanel, pero por lo que se ve es alguna manera de guardar un histórico de interacciones con el panel o algo así. En la práctica, sinceramente, no parece que haga nada útil.

Si para nuestra página es importante que se conserve el hash que hemos puesto tenemos dos opciones:

  1. Redefinir ese método metiendo una comprobación al principio de modo que si hay un hash en nuestra dirección, directamente que no haga nada.
  2. Ir "a saco" y directamente redefinir el método para cargártelo y que no haga nada.

Yo, las veces que me ha pasado (una de ellas muy reciente) lo que he hecho ha sido ir por la segunda opción, que e la vía fácil. Y no he notado problema alguno para poder utilizar las páginas cambiadas con total normalidad. Pienso que el script hace efecto e ocasiones muy poco frecuentes y que no pasa nada por eliminarlo. Pero tienes que probarlo en tu caso concreto.

El código para eliminarlo es muy sencillo. Simplemente tienes que poner esta línea en un script posterior al del ScriptManager:

Sys._Application.prototype._setState = function(){};

Vamos, que directamente le asignas una función vacía, que no hace nada de nada. Así, a lo bestia.

Esto puede ir simplemente en un script justo antes de cerrar el body de la página o bien en el evento DOMContentLoaded de la página o la función $() de jQuery si estás usando esta biblioteca. Lo dejo a tu elección.

Tu página no volverá a perder el hash.

¡Espero que te resulte útil!

65.000 desarrolladores responden: lenguajes de programación más queridos y odiados, y qué paga mejor en 2020

29/05/2020
Artículo original

65.000 desarrolladores responden: lenguajes de programación más queridos y odiados, y qué paga mejor en 2020

Stack Overflow ha publicado su encuesta a los desarrolladores 2020. Con el cuestionario han entrevistado a casi 65.000 programadores para que les dijeran cosas cómo sus tecnologías favoritas, los intereses tienen, y los sueldos que perciben.

Uno de los datos más interesantes es cómo el adorado Python ha caído dos puestos de popularidad a manos de Rust y del TypeScript de Microsoft como el lenguaje de programación más amado por los desarrolladores, aunque por un margen muy pequeño.

Más amado no quiere decir más usado

Lenguajes De Programacion Mas Amados Lenguajes de programación más amados - Stack Overflow 2020 Developer Survey

Aunque solo 5.1% de los desarrolladores entrevistados dice haber usado Rust, resultó ser el más amado por el 86.1% de los que respondieron. Y es que lleva un tiempo siendo el lenguaje más amado por muchos programadores aunque es un gran desconocido aún.

En esa misma categoría, TypeScript, el superconjunto de JavaScript desarrollado y mantenido por Microsoft, le ha quitado el segundo puesto a Phython, aunque por una diferencia de menos del 1%. A estos tres les siguen Kotlin, Go, Julia, Dart, C#, Swift y JavaScript.

Este último, aunque está en el puesto 10 entre los más queridos, sigue siendo la tecnología más usada: el 67.7% de los programadores profesionales utiliza JavaScript, seguido de HTML/CSS, SQL, Python y Java.

Lenguajes Mas Usados Tecnologías más usadas por los desarrolladores - Stack Overflow 2020 Developer Survey

Curiosamente, JavaScript es también uno de los lenguajes más odiados, el 41.7% de los desarrolladores que lo usan o lo han usado no quieren seguir con él. Sin embargo, el primer puesto aquí se lo lleva VBA, repudiado por el 80.4% de todos los entrevistados. A este le siguen Objective-C, Perl, Assembly, C, PHP, Ruby, C++, Java, R, Haskell, y Scala.

Mientras que entre los lenguajes que los desarrolladores más interés tienen en aprender o empezar a usar en su trabajo el ganador indiscutible es Python. Un 30% de los programadores quiere usarlo, seguido de un 18.5% quiere trabajar con JavaScript, un 17.9% con Go, un 17% con TypeScript, y un 14.6% con Rust.

Python y R pagan mejor

Python

Stack Overflow también ofrece muchos datos sobre el estado laboral de los programadores, dejando claro que un buen salario es el factor más importante a la hora de buscar trabajo, seguido de la oportunidad de trabajar con nuevas tecnologías.

No todos los trabajos pagan igual, y tanto en el promedio global como en el de Estados Unidos, los directores de ingeniería son los mejor pagados, promediando unos 92 mil dólares anuales. A esto le sigue SRE (Site Reliability Engineering) con unos 80 mil al año.

El 75% de los desarrolladores trabaja menos de 45 horas a la semana

DevOps paga en promedio 68 mil, los ingenieros de datos están cerca con 65 mil, y los científicos de datos y especialistas en machine learning rondan los 58 mil. Los desarrolladores de aplicaciones de escritorio o empresariales rondan los 56 mil, los administradores de sistemas los 54 mil.

Anotacion 2020 05 29 150511 Tecnologías mejor pagadas - Stack Overflow 2020 Developer Survey

Los desarrolladores móviles y los investigadores académicos están al final de la tabla rondando los 43 y 41 mil dólares anuales. Además de esto está el componente de años de experiencia y lenguajes dominados. Ahí notaron que quienes trabajan con Python y R manejan salarios mayores.

Sin embargo, son Perl, Scala, Go, Rust y Ruby las cinco tecnologías mejor pagadas. Con sueldos que sobrepasan los 70 mil dólares anuales para todas.

Esta encuesta fue hecha en febrero de 2020, antes de que el COVID-19 se declarara pandemia, así que en Stack Overflow quieren apuntar que los salarios y varios otros datos laborales, pueden pintar una imagen diferente en este momento.

Así es 'Arqueras de Nand', el juego de mesa español que ayuda a aprender lenguaje SQL

24/05/2020
Artículo original

Así es 'Arqueras de Nand', el juego de mesa español que ayuda a aprender lenguaje SQL

El valle de Nand ha sido invadido por salvajes hordas de orcos, y la clave para derrotarlos radica en que sus destacamentos de arqueras sepan aprovechar en su favor los riscos y coordinarse con los guerreros. Y para eso, deberán usar operadores lógicos en SQL.

Sí, has leído bien: 'Arqueras de Nand' es un juego de mesa de ambientación fantástica cuyo fin es enseñarnos cómo funcionan las bases de datos reales. Sus creadores son españoles y han lanzado una campaña en Kickstarter que ya ha logrado más del doble de los 3.000 € que se habían marcado como objetivo.

Y todavía les queda una semana por delante para hacer subir su marcador de patrocinadores, situado ahora mismo en 248: a partir de 15 € podrás recibir como recompensa el juego base en inglés y español.

"El objetivo de financiación es muy bajito porque es un proyecto que está financiado por la Unión Europea, de modo que no necesitamos recaudar todo el dinero que haría falta realmente para producirlo. Recurrimos a Kickstarter, más que nada, para conseguir llegar a más gente, porque no somos una empresa de producción de juegos de mesa".

De hecho, ni siquiera son una empresa. Quien habla con nosotros es Pablo Garaizar, creador del juego y profesor de la Universidad de Deusto con formación en psicología y en ingeniería informática que investiga en el Deusto LearningLab aspectos relacionados con la tecnología y la educación.

Nos cuenta que el LearningLab lleva tiempo desarrollando plataformas y apps educativas para niños, además de talleres por los que ya han pasado miles de ellos. Pero añade que, gracias a sus hijos, se empezó a meter en el mundillo de los juegos de mesa y eso le llevó a sugerir a su jefa que ampliasen su gama de recursos educativos.

De la Luna a los mundos fantásticos (o del binario al SQL)

'Arqueras of Nand' no es la primera iniciativa surgida a raíz de esa idea: el año pasado, antes de internarse en el mundo de la programación SQL, Garaizar ya impulsó con éxito otra campaña en Kickstarter para lanzar al mercado 'Moon', otro juego de mesa enfocado en esa ocasión a enseñar a operar con números binarios.

Moon simulaba mediante cartas el funcionamiento de un ordenador de 4 bits (concretamente el del software del primer módulo lunar). Tenían miedo de no tener éxito, por lo abstracto del planteamiento y porque "su componente educativo es siempre una pequeña losa en el mundillo lúdico".

Pero el resultado fue "alucinante": lograron muchas más ventas de las esperadas, y además se creó una amplia comunidad en torno al juego.

"La idea es seguir insistiendo en que hay muchas cosas en informática que se pueden contar de otra forma. En Arqueras queríamos hacer hincapié en enseñar las operaciones lógicas de una manera muy visual, que cada vez que ejecutemos una [equivalente a una acción en el juego] se vea reflejado en un mapa lo que hemos hecho".

"Nos dimos cuenta de que el tablero que estábamos conformando podría ser como una tabla de una base de datos y que las operaciones que iban a realizar las arqueras iban a ser seleccionar unas partes del tablero y dejar fuera otras para hacer sus ataques. Y eso se parece mucho a un uso normal de la base de datos SQL".

Archers El tablero del juego y una de las cartas de acciones, junto a su 'traducción' al lenguaje SQL.

La web del proyecto nos avisa de que la única carta que no funciona exactamente igual que su operador SQL homónimo es "Count": en el juego nos permite disparar flechas a los territorios que contengan determinado número de estandartes, mientras que en una base de datos real, serviría para contar filas.

Para todos los públicos (y copyleft)

Garaizar nos cuenta que 'Arqueras...' son dos juegos diferentes: uno educativo ("por su nivel de dificultad estaría recomendado para niños a partir de 8-9 años"), pero también otro que funciona para todos los públicos si no se hace hincapié en el aspecto educativo.

"Lo hemos probado en ferias de juegos y la gente lo valora por su historia y por cómo se engarza ésta con la mecánica del juego. Por eso, y por las ilustraciones [realizadas por Pedro Soto, ilustrador profesional de juegos de mesa, y responsable del apartado gráfico de juegos como el de 'Águila Roja' o el de '1911 Amundsen vs Scott'].

Un aspecto destacable de 'Arqueras de Nand' es que se trata de un juego copyleft. Su creador, que se proclama convencido de la causa del software libre, nos cuenta que

"Llevamos tiempo elaborando materiales que liberamos como copyleft porque somos una universidad y no tenemos un fin comercial, lo que más nos interesa es que nuestros proyectos lleguen a mucha gente".

Así, nos pone como ejemplo el propio Garaizar, un colegio sólo tendría que comprar un copia del juego y luego hacer fotocopias para permitir tener una copia en cada clase.

Además, "todo el juego se basa en ilustraciones independientes del idioma, y lo único que hay que traducir es el manual de instrucciones", el cual estará disponible "en un montón de idiomas: castellano, catalán, euskera, inglés, francés, italiano, alemán, polaco, ruso...".

ClickOnce: los ajustes de seguridad no permiten que esta aplicación se instale

24/05/2020
Artículo original

Muchas aplicaciones para Windows, tanto creadas con Windows Forms, WPF o incluso de consola, se distribuyen a los usuarios usando una tecnología vetusta pero muy útil llamada ClickOnce. Esta tecnología apareció en junto con la versión 2.0 de .NET Framework allá por 2005 y es extremadamente útil porque te permite empaquetar tus aplicaciones de modo que se puedan descargar e instalar desde una ubicación remota, en Internet, en la red local o en cualquier ubicación fija, y que al mismo tiempo se instalen las dependencias que necesites e incluso se determine si existe una versión nueva y se actualice sola automáticamente. Ya he hablado con anterioridad de algunos problemillas que te pueden dar a la hora de definir el paquete, pero en esta ocasión hablaré de un problema que te puede dar si eres un usuario.

Si vas a instalar una aplicación que implemente Clickonce es posible que, al intentarlo, te aparezca un diálogo como este:

que dice que no se puede instalar debido a los ajustes de seguridad de tu equipo. En este caso es una app que tengo descargada en mi unidad G:\ de Google Drive, que se considera como cualquier unidad local, o sea, que no es una app recién descargada de Internet o desde una unidad de red, por lo que debería instalarse sin problema. Lo peor es que no me da opción alguna para poder instalarla y se limita a decir que mi administrador ha bloqueado esta aplicación porque es un riesgo potencial de seguridad. Pero... mi administrador soy yo mismo. Este equipo es mío y no está en una red corporativa y mi cuenta es de administrador. WTF?

Bueno, resulta que el fabricante de mi portátil decidió por su cuenta y riesgo limitar un montón de cosas por defecto en el sistema. Por eso, entre otras cosas, odio usar los ordenadores tal y como vienen de fábrica: nunca sabes lo que te vas a encontrar, y prefiero instalar de cero una licencia mía del sistema según llega por la puerta el nuevo equipo.

Por suerte casi todo tiene solución en estos casos, así que si te pasa algo así puedes hacer lo que te explico a continuación.

Para determinar si una aplicación ClickOnce se debe instalar o no, el sistema toma la decisión en función de la ubicación de la misma, de si está firmada digitalmente o no, y de unos ajustes asociados con lo anterior que se encuentran en el registro del sistema.

Existen 5 ubicaciones para las que se puede activar o desactivar la instalación:

  • MyComputer: una app que está en una ubicación de tu ordenador local y que no has descargado de Internet.
  • LocalIntranet: apps que están ubicadas en una carpeta compartida de la red local.
  • TrustedSites: apps que se han descargado desde alguno de los sitios de la lista de confianza que hayas establecido en Internet Explorer (sí, esta tecnología tienes sus añitos). Dado que IE sigue estando instalado de serie en Windows todavía puedes establecerlas con facilidad desde Herramientas·opciones de Internet, o desde el panel de control del sistema buscando el mismo ajuste, y luego aquí:

  • UntrustedSites: parecido a lo anterior pero para lo contrario, o sea, sitios en los que explícitamente no confías y que están restringidos. Es la opción situada a la derecha en la figura anterior (Restricted sites).
  • Internet: pues eso, aplicaciones que te instalas directamente desde una ubicación en Internet, sin estar en sitios de confianza o en sitios restringidos explícitamente (por ejemplo, Google Chrome y algunas otras aplicaciones de Google, que usan ClickOnce).

Bien, en el registro del sistema se guardan los ajustes relativos a estas ubicaciones, en concreto en la rama \HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\.NETFramework\Security\TrustManager\PromptingLevel. Si abres el editor del registro (regedit.exe) y buscas esa rama verás los ajustes que tienes actualmente:

Como se puede ver, en este caso los tengo todos deshabilitados, por lo que no me deja instalar nada.

Si quieres permitir que se instalen aplicaciones desde alguna de estas ubicaciones, lo único que tienes que hacer es doble-clic sobre la que te interese y cambiar la palabra Disabled por Enabled. Ni siquiera es necesario reiniciar el equipo, pues se comprueba en cada intento.

Si ahora ejecutas la aplicación, verás que ya te da la opción de instalarla, aunque te avisa de que te asegures de que es una aplicación obtenida de una fuente fiable, claro:

Pero ya puedes proceder, que es lo que querías.

Para evitarte que tengas que editar directamente el registro te dejo aquí un archivo .reg (ZIP, 460 bytes) que establece como habilitadas las ubicaciones de tu equipo local, carpetas de red y sitios en los que confías (no Internet, que por defecto es un poco peligrosa). Descomprime el ZIP, haz doble click en el archivo, y listo.

¡Espero que te resulte útil!

Microsoft y OpenAI crean una inteligencia artificial que autocompleta código Python a partir de instrucciones en lenguaje natural

21/05/2020
Artículo original

Microsoft y OpenAI crean una inteligencia artificial que autocompleta código Python a partir de instrucciones en lenguaje natural

Microsoft ha creado una de las cinco más potentes del mundo (basada en Azure y dotada de 285.000 procesadores) y la ha cedido para uso exclusivo de OpenAI, la organización de investigación de inteligencia artificial 'fuerte' que Elon Musk ayudó a fundar hace unos años.

La compañía lo ha anunciado en el marco de la conferencia Build 2020, reconvertida en evento online para desarrolladores. Y, a la hora de explicar qué tipo de avances pueden lograrse gracias a la IA y a su supercomputadora, nos ha presentado lo que podría ser el inicio de una revolución a la hora de escribir código de software.

Kevin Scott (director de tecnología de Microsoft) y Sam Altman (CEO de OpenAI) nos muestran en un vídeo un ejemplo de creación automática de código: en el mismo, el programador inicia la escritura de un método en código Python, añade un comentario explicando en lenguaje natural no lo que hace el código ya escrito, sino lo que debe hacer el código que falta… y la inteligencia artificial lo genera.

Codigo Dentro de los rectángulos rojos, el código "autocompletado" por la IA a partir de unas pocas líneas escritas por el programador.

Y si algo falla, el programador sólo debe rehacer el comentario para 'explicarse' mejor. Pero no sólo es capaz de elaborar código a partir de lo escrito por el desarrollador humano, sino también de evitar generar código superfluo: en el vídeo vemos cómo hace uso de otros fragmentos de código previos, co-creados por hombre y máquina.

"Todo esto prueba que este modelo es capaz de generar sugerencias de código útiles y ajustadas al contexto, que lograrán que cualquier desarrollador sea más productivo (…) y le permitirán pasar menos tiempo en repetitivos y largos procesos de codificación y centrarse más en los aspectos creativos de la programación de software".

GPT-2: de fabricante de 'fake news' a programador virtual

Pero, ¿de dónde ha salido esta tecnología?

Hace más de un año, OpenAI sembró la polémica en el sector tecnológico anunciando que había desarrollado una inteligencia artificial tan peligrosa que no pensaban publicar la versión completa de la misma para evitar que se le diera un mal uso (terminaron rectificando).

Esta IA, bautizada como GPT-2, no tenía la capacidad de operar misiles termonucleares ni nada por el estilo, sino la de generar automáticamente, a partir de unas pocas palabras, largos textos de 'apariencia humana' capaces de alimentar noticias falsas.

GPT-2 es, técnicamente, un 'modelo de lenguaje': una inteligencia artificial capaz, por ejemplo, de "saber" cuál ha de ser la siguiente palabra de un texto en función de todas las palabras anteriores.

Logra eso gracias a recurrir a técnicas de procesamiento del lenguaje natural capaces de comprender no sólo la semántica de las palabras sino las relaciones que se establecen entre las mismas dentro de un texto.

Dicha capacidad de comprensión le permite realizar diferentes tareas (no sólo escribir, también resumir o traducir) y manejar diferentes idiomas, según con qué datos alimentemos al modelo a la hora de entrenarlo. Se le puede alimentar con artículos periodísticos en inglés o español... o con código escrito en Python o Java. Por ejemplo.

Según cuenta Altman en el vídeo, usaron la supercomputadora para entrenar el modelo alimentándolo con código open source "alojado en miles de repositorios Github". Básicamente han enseñado a una IA a programar haciendo que lea el código de miles de programas hasta que ha sido capaz de 'entender' como funciona.

.NET MAUI: Construir aplicaciones multiplataforma de escritorio con Xamarin.Forms

20/05/2020
Artículo original

Imagen ornamental de portadaEn el transcurso del evento BUILD esta madrugada, Microsoft ha anunciado MAUI, que es el futuro framework de desarrollo de interfaces multiplataforma que formará parte de .NET unificado.

Aunque la información oficial es la que está en el primer enlace, vamos a tratar de resumir y contestar a las preguntas más importantes sobre este anuncio y esta tecnología.

¿Qué es .NET MAUI?

Es el acrónimo (un poco pillado por los pelos) de .NET Multi-platform App UI. Se trata de una evolución de Xamarin.Forms que permitirá crear aplicaciones más allá de Android e iOS y otras plataformas que soporta actualmente esta tecnología. Con MAUI será posible utilizar Xamarin.Forms para crear también aplicaciones de escritorio para Windows (x32, x64 y ARM) y macOS, sacando partido de los conocimientos que ya tienes sobre esta tecnología y dándole más amplitud de miras.

Es importante señalar que en la actualidad ya es posible construir aplicaciones de escritorio con Xamarin.Forms, pero no están oficialmente soportadas. Las aplicaciones construidas con MAUI sí que estarán soportadas oficialmente por Microsoft y formarán parte integral de .NET 6 cuando esté disponible. Linux seguirá siendo posible, pero como ahora: apoyados por la comunidad, sin soporte oficial, lo cual le resta un poco de fuerza a la propuesta.

Este gráfico, sacado del anuncio oficial, define muy bien qué es MAUI:

Resumen de MAUI - Está explicado en el texto

Además simplifican el actual desarrollo existente en Xamarin, unificando el tooling, simplificando la estructura de proyectos, facilitando la reutilización, etc. (todos los detalles en el primer enlace).

Seguirá soportando el patrón MVVM (Model-View-ViewModel) y también la nueva estrella que parece que se está haciendo un hueco en Xamarin, el patrón MVU (Model-View-Update). Por supuesto, como ahora, podrás sacar partido a las APIs nativas cuando sea necesario, pero en lugar de tener que estar creando un nuevo proyecto por cada sistema operativo, ahora irán todos bajo un único proyecto, simplificando la gestión del desarrollo.

¿Cuándo estará disponible?

El proyecto es Open Source, por lo que si te interesa puedes ir a su repositorio en GitHub e ir viendo el código o experimentando. Pero de momento está en pañales.

Según el roadmap y el anuncio , las primeras versiones preliminares se empezarán a ver a finales de este año, probablemente con .NET 5 en noviembre. A lo largo de 2021 se irán sacando más previews y la versión definitiva se espera que esté disponible junto con .NET 6 en noviembre de 2021, dentro de año y medio.

¿Qué pasa con Xamarin?

Pues no pasa nada de momento. Seguirá siendo la plataforma oficial para crear aplicaciones móviles y podrás crear aplicaciones de escritorio también usando los proyectos de la comunidad. Sacarán nuevas versiones cada 6 semanas como hasta ahora.

Una vez que salga .NET MAUI, a finales de 2021, darán soporte oficial a Xamarin durante 1 año, pero será aconsejable que migres las aplicaciones al nuevo framework.

Por suerte, la migración será fácil y probablemente automática, así que no hay que agobiarse en exceso.

¿Debo aprender Xamarin ahora?

Pues si quieres crear aplicaciones móviles nativas multiplataforma para Android e iOS usando C# y XAML, la respuesta es un rotundo sí. Sigue siendo una plataforma muy interesante que te permitirá sacar partido a lo que ya sabes de .NET para crear aplicaciones móviles de manera rápida y que además son nativas, no funcionando en una vista Web.

Una vez que salga MAUI no debería resultarte difícil adaptarte y migrar las aplicaciones al nuevo framework, obteniendo de paso más opciones para explotarlas, dando a tus clientes el extra de tener aplicaciones de escritorio con muy poco esfuerzo adicional.

En resumen

Aunque el nombre pueda confundir a algunos y lo hayan anunciado con tanta antelación, MAUI es una gran noticia para todos los desarrolladores de Xamarin. Podrán seguir invirtiendo en sus conocimientos desarrollando aplicaciones móviles como hasta ahora y, cuando esté disponible .NET 6, tendrán a Xamarin integrado dentro de .NET en lugar de ser un producto aparte, con el añadido de poder crear más tipos de aplicaciones que ahora, y seguramente pudiendo ampliar en el futuro el alcance a otros nuevos tipos de aplicaciones que puedan surgir. Una combinación ganadora.

Visual Studio Live Share permitirá hablar por texto y voz sin usar aplicaciones de terceros

19/05/2020
Artículo original

Visual Studio Live Share permitirá hablar por texto y voz sin usar aplicaciones de terceros

Microsoft Build 2020, el evento anual para desarrolladores de Microsoft ha dado comienzo hoy de una forma atípica, pues debido al COVID-19 se celebra, como muchos otros, de forma online. Entre los muchos anuncios que la compañía de Redmond ha hecho para el ámbito del desarrollo, donde hoy Azure y el aprendizaje automático se llevan mucho protagonismo, destacan los cambios que llegan a Visual Studio Live Share.

El mismo contexto que ha obligado a celebrar el Microsoft Build online es el mismo que he llevado a Microsoft a hacer que Visual Studio Live Share ahora también soporte chat de texto y voz dentro del entorno de desarrollo. Todo ello, sin depender de compartir pantalla y aplicaciones de terceros

Así, además de funcionar como "Google Docs de desarrollo", pues permite editar y depurar código de forma colaborativa en tiempo, también ofrecerá una mayor agilidad cuando más lejos se encuentran los compañeros de trabajo.

La crisis ha acelerado el progreso del trabajo en remoto

Vistual Studio Live

Durante los primeros días de confinamiento, vimos cómo herramientas y funciones como las que acaba de presentar Microsoft se hacían cada vez más necesarias, pese a que Microsoft Teams o Slack estaban a buen nivel.

Necesitábamos el "Google Docs de" diferentes plataformas, y en ese sentido, aparecieron propuestas como Screen, que daba un cursor para cada usuario que participara en una videollamada, además de voz. Además, permitía señalar elementos sin entorpecer a los compañeros.

Cómo manejar trazas en .Net Core con Serilog

19/05/2020
Artículo original

Imagen ornamental con el título del post y el logo de Serilog

En el mundo del desarrollo de software estamos muy acostumbrados a depurar código mientras desarrollamos un producto o una nueva característica. Para ello, los entornos de desarrollo (IDE por sus siglas en inglés) van siempre acompañados de herramientas de depuración que nos permiten recolectar información sobre la ejecución, el valor de las variables, interrumpir el programa en puntos concretos y mover el puntero de ejecución hacia atrás y hacia adelante.

Esto es indispensable durante la fase de desarrollo y mantenimiento, pero ¿qué podemos hacer si el software está ya en producción y se produce un fallo catastrófico? En producción no tenemos un IDE con su depurador asociado para poder ver qué está pasando... Por ello es de vital importancia instrumentar el código de manera que tengamos métricas y trazas que aporten esa información que nos falta cuando algo no va bien en producción.

¿Por qué utilizar un logger?

Existen diferentes métodos y destinos para poder registrar toda esa información de manera que sea posible consultarla a posteriori: desde herramientas básicas integradas en la plataforma .NET, hasta utilidades específicas de proveedores cloud, como Azure, para instrumentar aplicaciones y obtener información en tiempo real sobre cómo se están ejecutando.

Parafraseando a Arquímedes*: dadme un IDE y desarrollaré lo necesario. Es posible añadir todas esas funciones y características que nos resultarían ideales pero hay que plantearse si merece la pena.

* Como dato histórico, la frase que se atribuye a Arquímedes es "Dadme un punto de apoyo y moveré el mundo".

Por ejemplo, podríamos crear con facilidad nosotros mismos una clase estática que guarde la información en un fichero:

public static class FileLogger
{
    private const string FilePath = "log.txt";
    public static void Log(string messsage)
    {
        using var fileStream = new FileStream(FilePath, FileMode.Append);
        using var writter = new StreamWriter(fileStream);
        writter.WriteLine(messsage);
    }
}
//...

FileLogger.Log("Mensaje 1");
FileLogger.Log("Mensaje 2");
FileLogger.Log("Mensaje 3");

Como se puede comprobar, es una implementación muy sencilla que simplemente registra cada mensaje en un fichero llamado log.txt, junto al ejecutable. De hecho, si colocamos ese código en una aplicación de consola y tras ejecutarla abrimos el fichero nos encontrarémos algo como esto:

La imagen muestra el fichero generado con 3 líneas con los valores Mensaje 1, Mensaje 2 y Mensaje 3, uno en cada línea

Hay que reconocer que aunque funcional, el ejemplo anterior es poco práctico y nada recomendable. Sí que es cierto que puede haber algún caso muy particular en el que esto sea suficiente. Pero por lo general vamos a necesitar más información (como la hora, los datos internos de una excepción...), un sistema más robusto de guardar la información y de lidiar con la concurrencia o, simplemente, que los ficheros se vayan purgando periódicamente para evitar acumular un montón de gigabytes con información antigua.

Existen varias herramientas disponibles para poder resolver la situación y que están ya preparadas con mucha funcionalidad extra que nos va a facilitar la vida. Por citar algunas podríamos hablar de NLog, Apache log4net o el que vamos a revisar en más profundidad en el artículo de hoy: Serilog.

Todos ellos trabajan de manera "similar": nos ofrecen un mecanismo para configurar un logger y después vamos a trabajar con él para registrar las trazas según lo configurado. Es por esto que aunque aquí vayamos a hablar de Serilog, utilizar cualquier otro logger no debería ser muy complicado una vez se conoce alguno.

Y ahora que ya hemos hecho las presentaciones, vamos con lo que realmente nos interesa. ¿Cómo se pone en marcha Serilog en .Net Core? Depende un poco del tipo de aplicación que estemos creando, así que empecemos con una aplicación de consola y después veremos cómo aprovechar la inyección de dependencias.

Creando un logger con Serilog

Para poder utilizar Serilog, lo primero que vamos a necesitar es añadir a nuestro proyecto el paquete Serilog. Este es el paquete básico que contiene toda la infraestructura necesaria para utilizar Serilog y sobre este paquete se van a ir añadiendo diferentes salidas como pueden ser ficheros, consola, una base de datos, etc... Estos diferentes destinos se conocen como Sinks y la lista de paquetes ya listos para utilizar diferentes Sinks es muy larga.

Puedes comprobar la lista completa de Sinks, así como sus enlaces en la wiki del proyecto.

En este caso, el ejemplo más básico sería utilizar el Sink de consola, para que todas las trazas que registremos se muestren por consola. Para esto, vamos a añadir también una referencia al paquete Serilog.Sinks.Console.

Teniendo ya en el proyecto los paquetes de Serilog y del Sink de consola, vamos a poder crear un logger con un código tan simple como este:

var logger = new LoggerConfiguration()
                   .WriteTo.Console()
                   .CreateLogger();

Una vez creado el logger, basta con mantener la instancia en memoría para registrar mensajes en consola desde cualquier punto donde tengamos acceso a ésta. Para conseguir registrar el mensaje, sólo hay que llamar a cualquiera de los métodos a nuestra disposición, a saber:

  • Verbose(string)
  • Debug(string)
  • Information(string)
  • Warning(string)
  • Error(string)
  • Fatal(string)

Con ellos vamos a poder registrar trazas con diferentes niveles de importancia e información a lo largo del código de la aplicación. Posteriormente podremos filtrarlos de manera global o simplemente indicándole el nivel mínimo que nos interese, al registrar el Sink. Por ejemplo, si ejecutamos el siguiente código:

var logger = new LoggerConfiguration()
                .MinimumLevel.Debug()
                .WriteTo.Console(LogEventLevel.Information)
                .CreateLogger();

logger.Verbose("Mensaje Verbose");
logger.Debug("Mensaje Debug");
logger.Information("Mensaje Information");
logger.Warning("Mensaje Warning");
logger.Error("Mensaje Error");
logger.Fatal("Mensaje Fatal");

Podemos comprobar que todos loe mensajes con un nivel inferior a Information se filtran directamente y no llegan a la salida del Sink:

La imagen muestra el resultado de la ejecución donde se ve que los mensajes Verbose y Debug no están

Añadiendo diferentes Sink a nuestro logger

Ahora que tenemos estos conceptos básicos claros, vamos a replicar la misma funcionalidad que tenía nuestro logger hecho a mano del principio, añadiendo el Sink de salida a archivos. Para eso añadimos el paquete "Serilog.Sinks.File" y configuramos el Sink de la misma manera que antes:

var logger = new LoggerConfiguration()
                .MinimumLevel.Debug()
                .WriteTo.Console(LogEventLevel.Information)
                .WriteTo.File("log.txt", LogEventLevel.Fatal) //Con esta línea configuramos la salida a fichero
                .CreateLogger();

Con este pequeño cambio, ya hemos añadido una nueva salida al logger, de manera que vamos a mostrar toda la información superior a Information en la consola y, además, guardaremos todas las trazas de nivel igual o superior a Fatal (que en la práctica es solo Fatal) en el fichero log.txt.

De todos modos, respecto a nuestro logger hecho a mano no tenemos una gran ventaja. Simplemente hemos conseguido un par de filtros y una salida adicional por consola. Nada que no se pueda hacer escribiendo un poco más de código en nuestra pequeña clase.

La verdadera potencia se hace patente cuando necesitamos esa funcionalidad extra como poder rotar ficheros. Imaginemos que queremos que las trazas se agrupen por día y que además se retengan durante un máximo de 10 días. Para conseguir eso ya tendríamos que empezar a añadir bastante código extra a nuestra clase. Pero utilizando el Sink de Serilog lograrlo se reduce a algo como esto:

var logger = new LoggerConfiguration()
                .MinimumLevel.Debug()
                .WriteTo.Console(LogEventLevel.Information)
                .WriteTo.File("log.txt", LogEventLevel.Fatal, rollingInterval: RollingInterval.Day, retainedFileCountLimit:10)
                .CreateLogger();

¿Sencillo verdad? Pues aún hay (mucho) más. Utilizando diferentes Sink las posibilidades aumentan para poder cubrir la gran mayoría de los casos. Sin ir más lejos, un escenario habitual es escribir registros en una base de datos, y eso es algo tan simple como esto:

//Cadena de conexión de la base de datos
var connectionString = "Server=(localdb)\\MSSQLLocalDB;Database=Logger;Integrated Security=true";
//Configuración del Sink de MSSqlServer
var sqlLoggerOptions = new SinkOptions
{
    AutoCreateSqlTable = true,
    SchemaName = "Logger",
    TableName = "Logs",
    BatchPostingLimit = 1
};

var logger = new LoggerConfiguration()
                .MinimumLevel.Debug()
                .WriteTo.Console(LogEventLevel.Information)
                .WriteTo.File("log.txt", LogEventLevel.Fatal,rollingInterval: RollingInterval.Day,retainedFileCountLimit:10)
                .WriteTo.MSSqlServer(connectionString, sqlLoggerOptions) //Aquí se añade el Sink
                .CreateLogger();

Como es de suponer, para poder utilizar el Sink de MSSqlServer hay que añadir el paquete "Serilog.Sinks.MSSqlServer"

Enriqueciendo las trazas con información adicional

En este punto ya está claro que, salvo que nuestro logger sea algo extremadamente simple, utilizar un logger especializado es siempre la mejor opción.

Otra de las opciones muy interesantes que ofrece Serilog es la posibilidad de añadir información útil a las trazas de manera automática. A este concepto se le conoce como enriquecer las trazas.

Esto se consigue gracias a la gran capacidad de extensión que ofrece Serilog. Aunque podemos crear nuestros propios enriquecedores para Serilog, ya existen algunos disponibles como paquete NuGet.

Por ejemplo, añadiendo el identificador del proceso:

var logger = new LoggerConfiguration()
                .Enrich.WithProcessId() //Aquí se añade el enriquecedor
                .WriteTo.Console(LogEventLevel.Information)
                .WriteTo.File("log.txt", LogEventLevel.Fatal,rollingInterval: RollingInterval.Day,retainedFileCountLimit:10)
                .WriteTo.MSSqlServer(connectionString, sqlLoggerOptions)
                .CreateLogger();

Vamos a obtener una salida parecida a esta:

La imagen muestra los mensajes enriquecidos registrados en la base de datos donde se ve el identificador del proceso

Para poder utilizar el método WithProcessId hay que añadir el paquete Serilog.Enrichers.Process

Configurando Serilog desde un fichero de configuración

Si bien es cierto que se pueden configurar todos los aspectos de Serilog mediante código, esto no deja de ser una solución muy rígida, que impide poder cambiar la configuración a menos que recompilemos el proyecto. No son pocas las veces donde necesitamos que una aplicación registre absolutamente toda la información disponible para arreglar algún error, pero nadie quiere tener ficheros de varios gigas en producción.

Para poder manejar esta situación los loggers suelen ofrecer la posibilidad de configurarse mediante un archivo, que es fácilmente editable. Serilog no es menos, y permite que configuremos todas sus opciones mediante un fichero app.config/web.config para .NET "tradicional", o un fichero appsettings.json en .NET Core.

Ya que la finalidad en este artículo no es entrar en profundidad en Serilog, sino darte una visión general sobre sus posibilidades, vamos a plantear solamente la opción de appsettings.json, ya que previsiblemente es la que mayor recorrido tiene. Serilog puede tomar su configuración desde cualquier origen de Microsoft.Extensions.Configuration siempre que añadamos el paquete Serilog.Settings.Configuration, por lo que podemos crear un archivo de configuración y pasárselo a Serilog para inicializarlo con las opciones contenidas en éste:

var configuration = new ConfigurationBuilder()
                .AddJsonFile("appsettings.json")
                .Build();

var logger = new LoggerConfiguration()
                .ReadFrom.Configuration(configuration)
                .CreateLogger();

Pero no solo llega con cambiar el código. También es necesario escribir la configuración en el fichero. Para ello creamos un objeto en el JSON y le indicamos todas las configuraciones que habíamos puesto antes en el código:

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File", "Serilog.Sinks.MSSqlServer" ],
    "WriteTo": [
      {
        "Name": "Console",
        "restrictedToMinimumLevel": "Information"
      },
      {
        "Name": "File",
        "Args": {
          "path": "log.txt",
          "rollingInterval": 3,
          "retainedFileCountLimit": 10
        },
        "restrictedToMinimumLevel": "Fatal"
      },
      {
        "Name": "MSSqlServer",
        "Args": {
          "connectionString": "Server=(localdb)\\MSSQLLocalDB;Database=Logger;Integrated Security=true",
          "sinkOptionsSection": {
            "tableName": "Logs",
            "schemaName": "Logger",
            "autoCreateSqlTable": true,
            "batchPostingLimit": 1
          }
        }
      }
    ],
    "Enrich": [ "WithThreadId" ]
  }
}

Si analizamos en detalle el contenido de este archivo podemos comprobar que se parece mucho a lo que teníamos por código, pero de manera declarativa. ¡Genial!

Registrando Serilog en el inyector de dependencias

Lo que hemos planteado hasta ahora está muy bien, pero para los que estamos habituados a trabajar con inyección de dependencias y la interfaz ILogger de .Net Core, esto se queda un poco corto. Eso de crear instancias de objetos por aquí y por allá va totalmente en contra del principio de inyección de dependencias. Es por eso que, Serilog está preparado también para registrarse en el contenedor de inyección de dependencias.

¿A estas alturas ya no hay dudas de cómo añadir ese soporte verdad? En efecto... Utilizando un paquete NuGet.

Esta vez vamos a necesitar incorporar Serilog.AspNetCore, y con esto podremos ir a Program.cs y añadir las únicas 9 líneas que necesitamos para que Serilog trabaje debajo del capó de ILogger:

public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        })
        //Borramos todos los registros de los loggers que vienen prerregistrados
        .ConfigureLogging(logging =>
        {
            logging.ClearProviders();
            logging.SetMinimumLevel(LogLevel.Debug);
        })
        //Añadimos Serilog obteniendo la configuración desde Microsoft.Extensions.Configuration
        .UseSerilog((HostBuilderContext context, LoggerConfiguration loggerConfiguration) =>
        {
            loggerConfiguration.ReadFrom.Configuration(context.Configuration);
        });

Et voilà!, ya tenemos listo nuestro Serilog trabajando por debajo de ILogger. Allá donde utilicemos ILogger realmente por debajo estaremos llamando a Serilog y con todas las configuraciones que le hayamos indicado.

Conclusión

Después de todo lo planteado, crear nuestros propios loggers debería ser algo que ni se nos pase por la cabeza. Al alcance de unos pocos clics tenemos la potencia de loggers tan completos como Serilog.

En esta entrada hemos planteado algunas de las principales opciones de Serilog, aunque no son ni mucho menos las únicas. Te recomiendo encarecidamente que, si no tienes costumbre de trabajar con herramientas como Serilog, Nlog u otros loggers, le eches un vistazo a la documentación de Serilog, ya que un mundo de posibilidades te está esperando.

Y tú, ¿conocías Serilog? ¿crees que puede ayudarte en el día a día de tus proyectos? Puedes dejarnos tus experiencias e impresiones en los comentarios.

Página Siguiente