Planeta código

Si están en Madrid este fin de semana, no se pierdan Madrid Games Week, la feria del videojuego referente a nivel nacional. Se realiza a partir de hoy 18 de octubre hasta el 21 de octubre en el pabellón 12 de IFEMA.

Nintendo va a tener una gran presencia, con 850 metros cuadrados de espacio dedicado a Nintendo Switch y más de 90 puestos de juego. Van a haber más de 30 juegos a disposición de los asistentes, incluyendo Super Smash Bros. Ultimate y Pokémon Let’s Go Pikachu y Pokémon Let’s Go Eevee.

El “¡Todos están aquí!” es la expresión perfecta para hablar de Super Smash Bros. Ultimate, el crossover de personajes que no solo enfrenta en divertidos y frenéticos combates a Mario, Link, Pikachu, y otros personajes de toda la historia de Nintendo, sino que engloba a grandes estrellas invitadas y todos los personajes que han estado alguna vez en la saga Smash, como los míticos Sonic y Pac-Man. El juego más completo de la saga, con más de 70 personajes y más de 100 escenarios, llegará a las tiendas el 7 de diciembre, pero todos los asistentes a Madrid Games Week podrán probarlo meses antes de su lanzamiento.

Estarán también todos los Pokémon de la primera generación por primera vez en Nintendo Switch, y por primera vez en España, gracias a Pokémon: Let’s Go, Pikachu! y Pokémon: Let’s Go, Eevee!. Madrid Games Week será la primera oportunidad que tendrán los fans de todo el país para probar esta nueva aventura que combina elementos de la saga clásica con elementos de Pokémon GO, el fenómeno de masas que a día de hoy sigue superando récords de actividad gracias a su entregada comunidad. Pokémon: Let’s Go, Pikachu! y Pokémon: Let’s Go, Eevee! se pondrán a la venta el próximo 16 de noviembre, y los asistentes a la feria podrán probar varias de sus novedades, como el modo cooperativo para explorar, capturar y combatir en compañía, y el control con el nuevo accesorio Poké Ball Plus.

En la Zona Mario los asistentes se podrán montar fiestas sobre la marcha con sus acompañantes y disfrutar con los minijuegos de Super Mario Party, o demostrarán quién es el rey de la pista con Mario Tennis Aces y quién domina mejor el volante y los caparazones con Mario Kart 8 Deluxe.

Las aventuras de mayor calibre están en la Zona RPG, como The Legend of Zelda: Breath of the Wild, el considerado por la crítica (y el autor de este blog) como el mejor juego del año 2017 y uno de los mejores de la historia.

En la Zona de Acción y deportes no sólo están títulos exclusivos de Nintendo Switch como Splatoon 2. El apoyo third party está patente en EA SPORTS FIFA 19, Dragon Ball FighterZ y el gran fenómeno de Fortnite en un formato que permite jugar en cualquier lugar. Ubisoft tendrá un gran peso en esta zona con Starlink: Battle for Atlas, el título de acción y exploración espacial que el mismísimo Shigeru Miyamoto presentó en el pasado E3.

Nintendo Switch, la consola de los indies

Nintendo Switch es la consola en la que todos los desarrolladores independientes quieren estar. Así, la Zona Nindies crece con un gran número de experiencias diferentes, con títulos
ya considerados por muchos como inolvidables como Celeste, Hollow Knight, Dead Cells, y apuestas con la originalidad por bandera como Toki, Flipping Death, The Gardens Between.

Todos los asistentes al stand de Nintendo en Madrid Games Week tendrán la posibilidad de llevarse una de las dos Nintendo Switch que se sortearán cada día (de viernes a
domingo) entre todos aquellos que hayan conseguido un número de sellos por jugar en cada una de las diferentes zonas. A través de Twitter también se sortearán tres Nintendo Switch
entre todos aquellos que tuiteen una foto desde cualquier lugar del stand utilizando el hashtag #NintendoEnMGW.

Quien busque la diversión en la emoción de la competición, también tendrá su lugar en el stand de Nintendo en Madrid Games Week. Los asistentes podrán inscribirse en los torneos de Mario Tennis Aces y Mario Kart 8 Deluxe, y para quienes disfruten de ver una competición de alto nivel tanto como de jugar, se celebrará un Torneo Invitacional de Super Smash Bros. Ultimate, en el que los mejores jugadores del país se enfrentarán en frenéticos combates.

La guinda al pastel de la competición la pone la clasificación nacional del Splatoon 2 European Championship 2019, en el que los mejores equipos de inklings y octolings se llenarán las caras de tinta para demostrar quién merece representar a España en el campeonato europeo que se celebrará en primavera de 2019.

Están los juegos más esperados meses antes de su lanzamiento, están los juegos third party en las mejores versiones para jugar en cualquier lugar, están los Nindies, están los mejores
juegos para la diversión en familia, están las aventuras más sorprendentes, están las competiciones de alto nivel, están los regalos y sorteos… Todos están aquí, ¡solo faltas tú!

Más información:
http://www.nintendo.es
https://www.nintendo.es/nintendoswitch
https://twitter.com/nintendoes
https://www.facebook.com/NintendoES
https://www.facebook.com/NintendoSwitchES
http://www.youtube.com/NintendoES
https://instagram.com/nintendoes/
https://www.instagram.com/NintendoSwitchES

Sobre Nintendo
Pionera en la creación de entretenimiento interactivo, Nintendo Co., Ltd., con sede en Kioto (Japón), fabrica y distribuye hardware y software para su consola de sobremesa Nintendo Switch, y para las familias de consolas portátiles. Desde 1983, cuando lanzó la Nintendo Entertainment System (NES), Nintendo ha vendido más de 4.600 millones de videojuegos y más de 725 millones de unidades de hardware en todo el mundo, incluyendo las actuales consolas Nintendo Switch, New Nintendo 3DS y New Nintendo 3DS XL, Nintendo 3DS, Nintendo 3DS XL y Nintendo 2DS, así como Game Boy, Game Boy Advance, Super NES, Nintendo 64, Nintendo GameCube, Wii, Nintendo DS, Nintendo DSi, Nintendo DSi XL y Wii U. También ha creado personajes tan conocidos como Mario, Donkey Kong, Metroid, Zelda y Pokémon. Como empresa subsidiaria, Nintendo Ibérica, S.A., con sede en Madrid, actúa como sede central de operaciones de Nintendo en España y Portugal.

Hoy se celebran 10 años de la Ley de Acceso a la Información Pública en Uruguay. Una ley que ha ayudado mucho a los datos abiertos y la transparencia, en algunos casos. Gracias a esta ley podemos hacer un pedido de información directamente desde la web con ¿Qué Sabés?.

Para celebrar el aniversario, Fabrizio Scrollini lista 10 cosas que deberíamos ir pensando sobre cómo solucionar en los próximos 10:

1) Aún tenemos organismos que o bien no publican información, o no responden pedidos de acceso. Trasciende partidos, y hay hasta quien quiso (caso de la Intendencia de Maldonado) declarar la ley inconstitucional. Esto no debería ser aceptable.

2) En el país líder en América Latina en gobierno electrónico, hay organismos que no responden pedidos vía correo electrónico. No solo es irónico. Está desfasado de la realidad del siglo XX (ya ni XXI)

3) Necesitamos más recursos para el organismo regulador y posiblemente un nuevo diseño institucional. Eso debería ayudar con el cumplimiento de la ley y la capacitación del servicio civil.

4) En estos 10 años han existido interpretaciones disparatadas (y otras respetables) del Poder judicial sobre como aplicar excepciones. Necesitamos generar doctrina legal adecuada y consistente.

5) La actividades de formación ciudadana son importantes. Deberían escalarse lo cual asume recursos. Solo un 25 % de la ciudadanía (aproximadamente) conoce este derecho y es clave que más lo conozcan.

6) Los programas de Datos Abiertos deben ser fotalecidos para favorecer más publicación y uso de la ley en formas no tradicionales. Ahí vamos por buen camino y podemos hacer mucho más.

7) Nos debemos una conversación seria sobre transparencia en el sector de seguridad y defensa. Está claro que no todo puede ser público pero hay mucha información útil para la ciudadanía y para evaluar que no está aún disponible.

8) Hay un problema en todas las tiendas políticas. La transparencia no gusta. Hay declaraciones disparatas. Precisamos fortalecer una sociedad civil que cobre ese tipo de declaraciones y eso debe incluir financiamiento público.

9) No existe no tener registros ni archivos adecuados sobre los pedidos que se responden. No solo pasa en Uruguay, pero no se puede medir lo que no se cuenta. Si nos vamos a quejar que hay muchos pedidos y toma trabajo, al menos midamos.

10) Seguimos precisando de medios de prensa que molesten al poder y hagan uso de estas herramientas. Cada vez hay más. También la administración ha adaptado sus prácticas. Esconder información no es jugar limpio.

Bonustrack 11). Creer que nuestra democracia ha mejorado solo por esta ley sería un error. Hay gente que resiste la transparencia en todas las tiendas partidarias e institucionales. Son la gente que puede ayudar a que nuestra democracia deje de ser seria.

Hace unos años redacté Sieve en C, una macro-comparativa del rendimiento de diferentes compiladores de C/C++ para Windows ejecutando una implementación de la Criba de Eratóstenes o Sieve. Unos días atrás publiqué Visual C++ 2008 vs Visual C++ 2017, y volvió a picarme el gusanillo sobre lo que ha evolucionado la calidad del código generado […]

La entrada Watcom C++ y Sieve para DOS aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

Teniendo una buen número de microservicios con múltiples instancias ofreciendo cada uno una API y en una ubicación diferente para simplificar la visión de los que actúen clientes de los microservicios se puede utilizar un proxy. Con un proxy es posible centralizar todas las peticiones, que sea éste el encargado de conocer la ubicación de todas las instancias de los microservicios y de hacer la llamada allí donde se encuentre cada una de ellas.

Entre las varias funcionalidades que proporcionar el proyecto Spring Cloud Netflix es esta de proxy mediante Zuul. Para hacer de proxy Zuul necesita tener una correspondencia entre URLs y servicios que realmente proporcionan la funcionalidad, una forma que tiene Zuul de conocer la ubicación de las instancias es utilizando el servicio de registro y descubrimiento Eureka. Además, Zuul como cliente de los microservicios posee la funcionalidad de Hystrix que implementa el patrón circuit breaker para tolerancia a fallos, Ribbon para hacer balanceo de carga entre varias instancias de los microservicios a nivel de servidor además de reintentos cuando una instancia falla.

En el ejemplo que he utilizado para esta serie de artículos sobre Spring Cloud hay un servicio que por defecto se inicia en el puerto 8080 y ofrece un endpoint / que devuelve un mensaje. Para crear un microservicio proxy con Zuul hay que crear una aplicación Spring Boot anotar la clase principal con la anotación @EnableZuulProxy y proporcionar la configuración para la correspondencia de rutas y microservicios, además de las propiedades para hacer reintentos en caso de que un microservicio falle y de timeouts en caso de que se comporte no como se espera en cuanto tiempos de respuesta.

Se puede establecer un tiempo máximo para establecer la conexión, de tiempo de petición, el número de reintentos en la misma instancia si falla o en otro número de instancias, el número máximo de conexiones y el número máximo de conexiones al mismo host. Todas ellas definibles en cada servicio de forma individual bajo las propiedades hystrix.command.service y service.ribbon donde service es el identificativo del servicio. Las rutas se indican bajo la propiedad zuul.routes con la relación identificativo del servicio y path.

Dado que Zuul es un proxy para múltiples instancias de microservicios a cada microservicio hay que darle una ruta, cuando Zuul realiza la llamada a una instancia del microservicio se encarga de omitirla. En el ejemplo, la ruta en Zuul /service/** está asociada al microservicio service pero el servicio service ofrece su endpoint en /, Zuul se encarga de omitir la parte de la ruta para el proxy y hace la llamada a la ruta / como espera el microservicio.

Lógicamente los clientes deben contactar con el proxy en vez de con el microservicio directamente. Arrancado el servicio de descubrimiento y registro Eureka, el servidor de configuración de Spring Cloud, dos instancias del servicio y el proxy con Zuul haciendo las llamadas al proxy se observa que se obtiene el resultado del microservicio. Como en el ejemplo hay varias instancias del servicio Zuul realiza balanceo de carga entre ellas con Ribbon utilizando la política round-robin y el mensaje es diferente en cada una de las respuestas según la instancia invocada. Con Zuul además se consigue balanceo de carga a nivel de servidor que Ribbon solo ofrece a nivel de cliente.

Las URLs del servicio en el microservicio y en el proxy son.

El cliente de ejemplo realiza peticiones al proxy, en la salida se muestra el resultado del balanceo de carga cuando hay varias instancias, cuando se añade una nueva instancia entra a formar parte del balanceo de carga. Otro beneficio de Zuul es que ofrece la funcionalidad de reintentos de modo que si una instancia de un servicio falla la petición se reintenta en otra. En el artículo Balanceo de carga y resilencia en un microservicio con Spring Cloud Netflix y Ribbon usando solo Ribbon se observaba que cuando una instancia falla se le siguen haciendo peticiones hasta que la lista de instancias del servicio en Eureka se actualiza quitando la fallida, con Hystrix se obtiene la respuesta fallback pero no se evita completamente el error. Zuul puede ocultar el error provocado por una instancia que falla reintentado la petición en la misma nuevamente, en otra u otras instancias según se configure. El comportamiento con Zuul cuando una instancia falla se puede comparar con el comportamiento incluido en el artículo anterior usando en el cliente los microservicios directamente.

Zuul además es capaz de proporciona otras muchas funcionalidades como:

• Autenticación
• Seguridad
• Recolección de métricas y monitorización
• Pruebas de carga
• Pruebas de verificación o canary testing
• Enrutado dinámico
• Migración de servicio
• Abandono de carga o load shedding
• Manejo de respuesta estática
• Gestión de tráfico active/active

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew-run.sh.

Un servicio que recibe numerosas peticiones o es crítico para el funcionamiento de una aplicación es necesario escalarlo o crear múltiples instancias de él para atender toda la carga que se demanda o para que en caso de que una instancia falle haya otras disponibles que funcionen correctamente para atender las peticiones.

En este entorno de múltiples instancias se hace necesario un servicio de registro y descubrimiento que usando Spring, Spring Boot y Spring Cloud Netflix una implementación es Eureka. Una vez descubiertas las instancias que hay del servicio es necesario hacer balanceo de carga para conseguir escalabilidad y tolerancia a fallos, en el mismo proyecto de Spring Cloud Netflix para realizar balanceo de carga en el cliente se ofrece Ribbon.

Hay varias formas de usar Ribbon una de ellas es con lo que denominan feign client, con Spring RestTemplate o directamente con LoadBalancerClient que es la que muestro en este artículo. Este cliente con Ribbon obtiene del servicio de registro y descubrimiento la lista inicial de instancias de un servicios registrado con sus ubicaciones siendo el host en el que se encuentran y el puerto en el que ofrecen su servicio. Con esta lista y el estado de los servicios se realiza el balanceo de carga. Sin embargo, dada la naturaleza de los microservicios se pueden añadir con posterioridad más instancias de un servicio o algunas pueden empezar fallar, Ribbon se encarga de mantener actualizada la lista de instancias de un servicio.

Combinado con Hystrix un ejemplo de cliente que hace peticiones a un servicio es el siguiente. Para demostrar su funcionamiento el cliente realiza varias llamadas a un servicio cada unos pocos milisegundos balanceando la carga entre las instancias que existan. Si con posterioridad se añade una nueva instancia del servicio Ribbon al cabo de un tiempo de que haya sido iniciada lo añadirá a la lista y empieza a seleccionarla para enviarle peticiones. Si una instancia falla hasta que Eureka no marca la instancia como fuera de servicio y el cliente no actualiza su lista de instancias en el ejemplo de cliente seguirá enviando peticiones a la instancia fuera de servicio y con Hystrix utilizando el método de fallback como respuesta.

Ante el fallo de una instancia para evitar que temporalmente el cliente empiece a fallar cuando le redirige una petición este puede reintentar las peticiones en otra instancia, esta funcionalidad se proporciona con Spring Retry o utilizando Zuul como proxy.

El cliente usa la clase LoadBalancerClient que en cada invocación del método choose() devuelve una instancia diferente de servicio realizando balanceo de carga utilizando el método round-robin. La clase ServiceInstance proporciona la URL de la instancia del servicio.

La clase del servicio y los comandos para iniciar el servicio de registro y descubrimiento, el servicio de configuración, las instancias del servicio en diferentes puertos y el cliente.

Esta es la salida y funcionamiento del cliente realizando balanceado la carga entre las mútiples instancias y que ocurre cuando se añade una nueva o una empieza a fallar y se elimina de la lista.

Ribbon posee numerosas propiedades de configuración a nivel global para todos los clientes de servicios o de forma específica para cada servicio ya sea con la anotación @RibbonClient o mediante la configuración en archivos externos de Spring Boot. Algunas propiedades de configuración interesantes son las de timeout que permiten que un cliente no agote sus recursos esperando a que a los servicios que llama si tardan en responder y a su vez el cliente actuando de servidor recibe muchas llamadas de sus clientes. En un comando de Hystrix también se puede especificar un timeout de modo que si se realizan reintentos el tiempo total para Hystrix deberá ser superior que el tiempo total de todos los posibles reintentos teniendo en cuenta el timeout del cliente con Ribbon. Unsando el cliente HTTP Jersey como en este caso también pueden establecerse timeouts para una petición.

El balanceo de carga que con Ribbon se realiza en el cliente es más sencillo que realizar el balanceo de carga en el servidor ya que no requiere una pieza más en la infraestructura pero requiere que el cliente tenga algo de lógica para hacer el balanceo de carga.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradle-run.sh.

La organización mundial que promueve la diversidad de género en la comunidad de R, R-Ladies, tiene una instancia en Uruguay: R-Ladies MVD. El martes 23 de octubre organizan su cuarto encuentro: Taller de manipulación y transformación de datos con tidyverse en R por Lucía Coudet.

La cita es en Scanntech (Duvimioso Terra 1975) a las 19:00. Pueden confirmar asistencia en este enlace.

Pueden unirse y estar al tanto de su actividad en Meetup o seguir la organización en Twitter.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• ¿Recomendarías a tu hijo que se dedicase al mundo del desarrollo de software?
  José M. Aguilar
• Cómo incluir scripts en la página desde vistas parciales ASP.NET Core MVC con DynamicSections
  José María Aguilar

.NET / .NET Core

• .NET Core 2.0 Sees End of Life, 2.1.5 Update Released
  David Ramel
• Update on .NET Core 3.0 and .NET Framework 4.8
  Scott Hunter
• I didn't understand why people struggled with (.NET's) async
  Dan
• C# Intermediate: Structures in C# & Enumerations in C#
  Marinko Spasojevic
• The danger of TaskCompletionSource<T> class
  Sergey Teplyakov
• Using Async with ManualResetEventSlim
  Calvin H.
• BenchmarkMockNet: Benchmarking .NET Mocking Libraries
  Steve Desmond
• Middle Ground between Server and Workstation GC
  Maoni Stephens
• Unit Testing With .NET Core
  Jeremy Morgan
• .NET Tip: Testing Private Fields
  Peter Vogel
• A Recap about Creating Maps for AutoMapper in .NET Core
  Silvia Campo
• FixedTimeEquals in .NET Core
  Kevin Jones
• LINQ Stinks - code smells in your LINQ
  Mark Heath
• A History of .NET Runtimes
  Matt Warren

ASP.NET / ASP.NET Core

• Exploring .NET Core's SourceLink - Stepping into the Source Code of NuGet packages you don't own
  Scott Hanselman
• Creating PDF files in ASP.NET Core
  Damien Bowden
• Integrating JavaScript and C# in the Browser: Beyond the Basics with Blazor
  Peter Vogel
• Headless CMS and Decoupled CMS in .NET Core
  Scott Hanselman
• Server-Side Blazor to Ship in .NET Core 3.0
  David Ramel
• Simple Paging In ASP.NET Core Razor Pages
  Mike Brind
• ASP.NET Core and Blazor on Mac: Dockerizing Applications
  Vincent Maverick Durano
• Creating a PDF in ASP.NET Core using MigraDoc PDFSharp
  Damien Bowden
• Using DbUp in AspNetCore application
  Janak Shrestha
• Action Filters in .NET Core Web API
  Marinko Spasojevic
• Adding decorated classes to the ASP.NET Core DI container using Scrutor
  Andrew Lock
• Building Blazor apps with SignalR Core
  Anuraj Parameswaran
• Announcing ASP.NET SignalR 2.4.0 Preview 1
  Andrew Stanton-Nurse
• Convert null-valued results to 404 in ASP.NET Core MVC
  Filip Woj

Azure / Cloud

• Announcing Orleans 2.1
  Reuben Bond
• Use Hybrid Connections to Incrementally Migrate Applications to the Cloud
  Andrew Hall

Data

• Learning Entity Framework (Day 3): ASP.NET Web API 2 with Entity Framework 6 Code First Migrations
  Akhil Mittal
• Adaptive Query Processing in SQL Server 2017
  Robert Sheldon
• Faster MS SQL database existence checking with Entity Framework Core and Entity Framework
  Jiří Činčura

HTML / CSS / Javascript

• WebAssembly on Cloudflare Workers
  The Cloudflare Blog
• How Do You Put a Border on Three Sides of an Element?
  Chris Coyier
• Creating Flexible Layouts with Flexbox
  Tiffany Brown
• Apply a Filter to a Background Image
  Chris Coyier
• Creating Layouts with CSS Grid
  SitePoint
• CSS Only Floated Labels with :placeholder-shown pseudo class
  Nick Salloum
• Use Cases For Flexbox
  Rachel Andrew
• Moving Backgrounds With Mouse Position
  Chris Coyier
• CSS Debugging and Optimization: Code-quality Tools & Minification with CSSO & * Minification with CSSO
  Tiffany Brown
• One Invalid Pseudo Selector Equals an Entire Ignored Selector
  Chris Coyier
• JavaScript tiene dos valores para el número cero, y no son iguales aunque lo parezcan
  José Manuel Alarcón

Visual Studio / Complementos / Herramientas

• Visual Studio 2017 version 15.9 Preview 3
  Angel Zhou
• Unit testing memory leaks using dotMemory Unit
  Maarten Balliauw

Xamarin

• [Material] Analizando interfaces de usuario avanzadas con Xamarin.Forms
  Javier Suárez Ruiz

Otros

• MS-DOS v1.25 and v2.0 Source Code
  Microsoft
• ¿Expertos o eternos principiantes?
  Juan Palacio

Publicado en Variable not found.
Publicado en: www.variablenotfound.com.

Un mes ya… y hoy vengo a hablaros de la “Inyección de Dependencias” (DI). La inyección de dependencias consiste de manera resumida en evitar el acoplamiento entre clases utilizando interfaces. Gracias esto, conseguimos que cada clase tenga una función única, facilitando así el mantenimiento y el soporte de nuestro código.

Esto que puede parecer un poco lioso a simple vista, y puede parecer mucho trabajo, se puede conseguir fácilmente cambiando levemente nuestro patrón de diseño. Vamos a imaginar que tenemos una clase que lee unos datos desde una base de datos con Entity Framework (“Database First” o “Code First“), y los envía por email:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
using PostInyeccion.Models;

namespace PostInyeccion
{
    class Program
    {
        static void Main(string[] args)
        {
            GeneradorInformes generador = new GeneradorInformes();
            generador.GenerarInforme();
        }
    }

    internal class GeneradorInformes
    {
        internal void GenerarInforme()
        {
            //Obtenemos los datos desde el contexto
            using (PostDbContext contexto = new PostDbContext())
            {
                var profesores = contexto.Profesores.Include(x => x.Cursos)
                                                    .ThenInclude(x => x.Alumnos).ToList();
                
                //Trabajo de maquetacion
                //.......                           

                //Enviamos el correo
                var emailSender = new EmailSender();
                var envioOK = emailSender.Enviar(profesores);
                if(!envioOK)
                {
                    //Registramos el fallo en un log
                }
            }
        }
    }

    public class EmailSender
    {
        public bool Enviar(List<Profesores> profesores)
        {
            //Enviar correo
            return true;
        }
    }
}

En primer lugar, vamos a analizar los posibles problemas de esta clase:

1. Baja mantenibilidad por el acoplamiento en entre clases: Es la propia clase la que instancia las que va necesitando, provocando que cualquier cambio en las clases “auxiliares” pueda cambiar el comportamiento.
2. Dificultad para realizar pruebas unitarias: En el caso en el que queramos realizar pruebas unitarias, es requisito que todos los servicios estén activos. Desde el punto de vista de las pruebas, esto es nefasto, podemos no tener acceso al servidor de correo, o a la base de datos… Con este patrón, es muy difícil testear nuestra clase.

Inyección de Dependencias

Vamos a ver que pasa si refactorizamos la clase para inyectar las dependencias, de manera que no tengamos dependencias:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
using PostInyeccion.Models;

namespace PostInyeccion
{
    class Program
    {
        static void Main(string[] args)
        {
            //Generamos la clase que hara el trabajo
            GeneradorInformes generador = new GeneradorInformes();

            //Obtenemos los datos desde el contexto
            using (PostDbContext contexto = new PostDbContext())
            {
                var profesores = contexto.Profesores.Include(x => x.Cursos)
                                                    .ThenInclude(x => x.Alumnos).ToList();

                //Instanciamos la clase de envio de emails
                var emailSender = new EmailSender();
                generador.GenerarInforme(profesores, emailSender);
            }
        }
    }

    public class GeneradorInformes
    {
        public  void GenerarInforme(List profesores, IEmailSender emailSender)
        {
            //Trabajo de maquetacion
            //.......
            
            //Enviamos el correo
            var envioOK = emailSender.Enviar(profesores); 
            if(!envioOK) 
            { 
                //Registramos el fallo en un log 
            }
        }
    }
}

interface IEmailSender
{
    bool Enviar(List profesores);
}

public class EmailSender : IEmailSender
{
    public bool Enviar(List profesores)
    {
        //Enviar correo
    }
}

Hemos conseguido una mayor mantenibilidad al abstraer totalmente a la clase “GeneradorInforme” de las labores propias de envío de correo y de obtención de datos. Y ahora es cuando me dices, “Pero no hace falta utilizar inyección de dependencias para conseguir lo que has conseguido…”. Efectivamente, para simplemente desacoplar las clases, no sería necesario. Podríamos haberle pasado al método una instancia de EmailSender en vez de su interfaz pero… Si queremos hacer pruebas unitarias, eso no es suficiente. Seguiríamos con el problema de que si el servidor de correo esta caído, nuestra prueba fallaría. Ahí radica la potencia de trabajar inyectando dependencias. En nuestro proyecto de pruebas unitarias, simplemente tendríamos que añadir una nueva clase que implemente “IEmailSender” y que no se conecte a ningún servidor, o que simule la conexión.

En el caso del ejemplo, hemos inyectado las dependencias mediante un parámetro, pero esta solo es una de las maneras. Podemos inyectar dependencias de varias maneras:

1. Inyección de dependencias en parámetros de constructor.
2. Inyección de propiedades.
3. Inyección de dependencias en parámetros de métodos.

Vamos a ver más detalladamente cada uno.

Inyección de dependencias en parámetros de constructor

var emailSender = new EmailSender();
GeneradorInformes generador = new GeneradorInformes(emailSender);
//--------------------------------------------------------------
public class GeneradorInformes
{
    //Dependencia para el envio de correos
    IEmailSender _emailSender;

    //Pasamos la dependencia en el construcor
    public GeneradorInformes(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    public void GenerarInforme(List<Profesores> profesores)
    {
        //Trabajo de maquetacion
        //.......

        _emailSender.Enviar(profesores);
    }
}

 Inyección de propiedades

//Instanciamos la clase de envio de emails
var emailSender = new EmailSender();
GeneradorInformes generador = new GeneradorInformes();
generador.EmailSender = emailSender;
generador.GenerarInforme(profesores);
//-----------------------------------------------------
public class GeneradorInformes
{
    //Propiedad con la dependencia
    public IEmailSender EmailSender { get; set; }
    public GeneradorInformes()
    {
    }

    public void GenerarInforme(List<Profesores> profesores)
    {
        //Trabajo de maquetacion
        //.......

        EmailSender.Enviar(profesores);
    }
}

En este caso, hay que tener en cuenta que la dependencia no estará disponible durante el constructor, por si la necesitásemos.

Inyección de dependencias en parámetros de métodos

Es el caso que hemos visto en el primer ejemplo.

Contenedor IOC

La utilización de contenedores IOC (Inversion Of Control) nos abstraen de la necesidad de generar las clases cada vez. Simplemente es configurar un contenedor el cual nos sirva las dependencias que necesitamos en cada momento. Esto facilita mucho la labor de trabajo al no tener que gestionar nosotros mismos las clases. Existen bastantes sistemas IOC para .NET, pero en este caso, vamos a utilizar “Microsoft.Extensions.DependencyInjection”.

Para eso, tenemos que añadir el paquete desde NuGet:

O vía consola:

PM->Install-Package Microsoft.Extensions.DependencyInjection -Version 2.1.1

Ahora vamos a registrar los servicios (Asumo que tenemos un DbContext creado en base a los post de Entity Framework  Core), pero para ello, primero tenemos que crear el interfaz IGeneradorInformes y hacer que Generador de informes la implemente:

public interface IGeneradorInformes
{
    void GenerarInforme();
}

//.........

public class GeneradorInformes : IGeneradorInformes
//......

Una vez que lo tengamos, empezamos a registrar los servicios:

//Generamos la coleccion de servicios
IServiceCollection serviceCollection = new ServiceCollection();
//Registramos el DbContext
serviceCollection.AddDbContext<PostDbContext>(options=>
                options.UseMySql("Server=localhost;Database=postefcore;Uid=root;Pwd=root;"));
//Registramos el EmailSender
serviceCollection.AddSingleton<IEmailSender, EmailSender>();
//Registramos el generador de informes
serviceCollection.AddSingleton<IGeneradorInformes, GeneradorInformes>();

//Construimos el contendor IoC
var services = serviceCollection.BuildServiceProvider();

Después, simplemente necesitamos llamar a su metodo “GetService<T>()” para obtener una instancia de la clase concreta con todas sus dependencias inyectadas:

IGeneradorInformes generador = services.GetService<IGeneradorInformes>();
generador.GenerarInforme();

Este sistema funciona muy bien en MVC 5 y MVC Core, ya que esta construido totalmente sobre el sistema de inyección de dependencias, pero es cierto que en aplicaciones que no sean MVC, hay que trabajarselo un poco. Digo esto porque necesitamos mantener activa una referencia a “services” para poder pedirle las clases. Esto lo podemos resolver bastante fácilmente con un tipo estático que almacene nuestra referencia:

using Microsoft.Extensions.DependencyInjection;
using System;

namespace PostInyeccion
{
    public static class Injector
    {
        static IServiceProvider _proveedor;

        public static void GenerarProveedor(IServiceCollection serviceCollection)
        {
            _proveedor = serviceCollection.BuildServiceProvider();
        }

        public static T GetService<T>()
        {
            return _proveedor.GetService<T>();
        }
    }
}

Veamos como usarlo en nuestro código:

static void Main(string[] args)
{
    //Generamos la coleccion de servicios
    IServiceCollection serviceCollection = new ServiceCollection();
    //Registramos el DbContext
    serviceCollection.AddDbContext(options =>
        options.UseMySql("Server=localhost;Database=postefcore;Uid=root;Pwd=root;"));
    //Registramos el EmailSender
    serviceCollection.AddSingleton<IEmailSender, EmailSender>();
    //Registramos el generador de informes
    serviceCollection.AddSingleton<IGeneradorInformes, GeneradorInformes>();

    Injector.GenerarProveedor(serviceCollection);
    //Obtengo clase desde el IOC
    IGeneradorInformes generador = Injector.GetService<IGeneradorInformes>();
    generador.GenerarInforme();
}

Con esto, registraremos todas las dependencias al inicio de nuestro programa, y llamaremos a Injector.GetService<T>() cuando necesitemos utilizar una dependencia.

A simple vista, parece que es mucho trabajo y poca recompensa, pero en las siguientes entradas veremos las ventajas que aporta trabajar así cundo hablemos de las pruebas unitarias y del “Moking”.

Puedes descargar el código de ejemplo desde este enlace.

**La entrada Inyección de Dependencias en .Net Framework se publicó primero en Fixed Buffer.**

Relación de los fundamentos de la auto-organización con los principios de la motivación intrínseca (autonomía, maestría y propósito).

Para ver el texto más pequeño o imprimir las imágenes en mayor resolución, con el botón derecho del ratón hacer clic en la imagen  y escoger la opción “Abrir imagen en una pestaña nueva”. 

Para que la auto-organización sea un éxito, la persona (o el equipo) debe tener unos objetivos, marco y reglas claros, así como las habilidades e información necesarias para poder realizar ese trabajo de manera efectiva.

 

También es importante considerar ciertos aspectos que refuerzan o degradan el éxito de la auto-organización:

• Las personas siguen las ideas, se motivan por la visión, más que por la persona (el individuo) que ejerce el liderazgo. El liderazgo tiene que proporcionar una visión compartida, que produzca alineamiento de los diferentes individuos.
• Estos objetivos o visión deberían estar asociados a la satisfacción del que va a recibir el producto/servicio (cliente, usuario, …), lo cual constituye el resultado final a conseguir (este es el punto por el que hay que empezar las conversaciones). Es por ello que el contacto directo entre quienes están realizando el trabajo con el mercado o “cliente” ayuda a:
  • Entender qué necesitan y hacer sentir de manera “real” el impacto del trabajo, si realmente se están cubriendo las demandas de los que se tienen que beneficiar de él.  Idealmente también permite alinear el “propósito” del trabajo con la motivación más intrínseca de la persona (fomentando la responsabilidad sobre los resultados dado que “los han hecho suyos”).
  • Proporcionar la transparencia de contexto del cliente necesaria para que puedan tomar buenas decisiones.
  • Fomentar la innovación en las personas o equipos de trabajo, al entender mejor las necesidades (que no la “solución”), el tipo de negocio o servicio a proporcionar.

Crear un entorno donde se empiece dar todo esto permite crear un efecto de peer emulation, donde se da ejemplo de nuevos comportamientos y  profesionalidad (en personas y en equipos). Para ello será importante seleccionar en el inicio las personas, equipos y áreas adecuadas, ya que quizás no todo el mundo (management o personas en la “trinchera”) estén desde el principio receptivas a estos nuevos paradigmas de gestión basados en autonomía y responsabilidad.

Evidentemente, el inicio de este cambio requiere:

• Una aceptación de que las personas o equipos con mayor autonomía pueden cometer errores, pero como mínimo tienen que sacar aprendizaje de ellos para reducirlos en el futuro.
• Una inversión. Los objetivos y las restricciones pueden estar claramente definidos pero, sin un esfuerzo explícito de medio-largo plazo en el desarrollo de las personas, la organización siempre estará rindiendo por debajo de sus posibilidades y fallando de manera repetitiva.

 

“Es mejor querer más responsabilidad en la organización que tener miedo de dar más responsabilidad a la organización”

— Adaptado de una cita de Bill Cosby

 

Artículos relacionados

• Motivación de personas y liderazgo
• Agile management es diferente   
• El buen gestor de un equipo ágil

 

 

"La mayoría de las organizaciones que triunfan, triunfan por el compromiso de su gente". Así lo afirma Fred Kofman en este fragmento de su conferencia "Tu trabajo no es tu trabajo", en el que expone que el que el valor que aportan las personas motivadas y comprometidas no se puede exigir ni comprar. 

Fred Kofman es asesor de liderazgo en Google, director del Centro de Liderazgo Consciente en el Instituto Tecnológico de Monterrey y presidente del Conscious Business Center International. Es doctor en economía por la Universidad Berkeley de California y trabajó de profesor durante años en la Escuela de Management Sloan del Instituto Tecnológico de Massachusetts.

 

 

 

Los microservicios son independientes unos de otros y se comunican mediante operaciones de red. Dado que las operaciones se realizan a través de un medio no confiable como la red, dada su naturaleza efímera y a que pueden fallar en los microservicios es importante que los clientes estén preparados ante posibles fallos.

Un patrón o técnica que se suele emplear es el de Circuit Breaker, en Java y con Spring se ofrece en el proyecto Spring Cloud Netflix mediante Hystrix y Javanica. Este patrón soluciona dos problemas cuando un microservicio del que se depende falla y hace al microservicio que lo usa tolerante a fallos.

• Uno es que cuando un microservicio empieza a fallar es necesario dejar de hacerle peticiones para permitirle recuperarse si está saturado que provoca esos fallos. Cuando ocurre un fallo es posible realizar una acción en sustitución de la llamada al microservicio y devolver un valor alternativo como medida paliativa y hacer que el microsevicio afectado tenga la posibilidad de seguir ofreciendo su servicio aunque sea de forma degradada.
• Otro problema es que el microservicio aunque no falle tarde demasiado en responder, se puede establecer un timeout que si se supera se deja de esperar e igualmente se realiza la acción de sustitución lo que evita que los microservicios que usan uno que tarda demasiado en responder agoten sus recursos y empiecen a fallar o tardar demasiado también.

En ambos casos se evita que la cadena de microservicios empiece a fallar y con ello sistema completo.

El patrón circuit breaker se denomina así ya que implementa una lógica similar a un circuito eléctrico. El circuito en su estado normal está cerrado y se realizan las llamadas al microservicio servidor. Si el microservicio servidor empieza a fallar se llama a la acción alternativa con su valor, si se supera un umbral de errores el circuito pasa a estado abierto y se dejan de hacer llamadas al microservicio servidor. Cada cierto tiempo definido se realiza una llamada al servicio servidor para comprobar su estado de forma que si responde correctamente el circuito pasa a estado cerrado nuevamente y las siguientes llamadas se realizan al microservicio servidor dejándose de utilizar la acción alternativa.

Para utilizar Hystrix como implementación del patrón circuit breaker en una aplicación Java con Spring Boot el método que realiza la llamada al microservicio servidor ha de encapsularse en un método anotado con la anotación @HystrixCommand, como parámetro se indica un método con la acción alternativa o fallback que obtiene un valor en los fallos. También se puede indicar el tiemout de espera antes de considerar que la llamada ha fallado con la propiedad execution.isolation.thread.timeoutInMilliseconds. Igualmente se pueden indicar los valores para abrir el circuito con circuitBreaker.requestVolumeThreshold y circuitBreaker.errorThresholdPercentage. Esos son los básicos para utilizar este patrón de tolerancia a fallos. Tiene algunos valores adicionales más que se pueden configurar para adaptar el patrón a los valores óptimos de la aplicación.

En el ejemplo el cliente en un bucle realiza las llamadas al servicio con un método get() anotado con @HystrixCommand. En este método se encapsula la petición HTTP que puede fallar, utilizando la librería Jersey y obtenida la ubicación de una instancia del servicio a su vez del servicio de registro y descubrimiento Eureka.

El circuito se abre cuando el número de llamadas supera un umbral y un porcentaje de fallos, se han de cumplir las dos condiciones. Si el número de llamadas que se realizan no superan el umbral aunque todas fallen el circuito permanece cerrado. Ambos valores son personalizables con las propiedades circuitBreaker.requestVolumeThreshold y circuitBreaker.errorThresholdPercentage. El circuito permanece abierto al menos durante el tiempo indicado por metrics.rollingStats.timeInMilliseconds.

En la aplicación ejemplo hay un microservicio servidor y un microservicio cliente, iniciada una instancia de microservicio servidor y una instancia del microservicio cliente que implementa el patrón circuit breaker inicialmente las peticiones se realizarán correctamente si no ocurre un timeout. Si se finaliza el proceso del microservicio servidor las peticiones del cliente al servidor empezarán a fallar y este obtiene el valor alternativo del método fallback, si se supera el umbral de llamadas y de fallos el circuito pasa a estado abierto. Mientras el circuito permanezca abierto el cliente sondea con una petición cada cierto tiempo el estado del servidor, si el servicio servidor se inicia unos instantes después de que esté disponible el cliente con la petición de sondeo comprobará que el servidor funciona, se cerrará el circuito y el cliente empezará a obtener los valores devueltos por el microservicio servidor.

Para monitorizar en tiempo real el estado del sistema y de los circuitos se ofrece un dashboard en el que visualizan el número de peticiones que se están realizando, las fallidas, el estado de los circuitos, las que fallan por timeout o las que fallan con error. Para tener acceso a esta página hay que incluir la dependencia org.springframework.cloud:spring-cloud-starter-netflix-hystrix-dashboard. La página dashboard está disponible en la dirección http://localhost:8085/hystrix.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradle-run.sh.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradle-run.sh.

Pues como uno que os habla, seguro que muchos de vosotros habéis comparado miles de veces si un objeto es nulo utilizando un patrón de código C# como el siguiente:

var invoice = _invoiceRepository.GetById(18);
if(invoice == null) 
{
    // Hacer algo
}

¿Qué podría salir mal, verdad?

Pues aunque pueda parecer raro, hay casos en los que la comparación anterior no funcionaría bien... o mejor dicho, no funcionaría como esperamos.

Hace unos días leía un post de Khalid Abuhakmeh en el que hacía referencia a una charla de Channel 9 en la que Mads Torgersen recomendaba no utilizar la doble igualdad para comparar con null (minuto 33:00, aprox.)

En su lugar, la recomendación del lead designer del lenguaje C# en Microsoft es utilizar la expresión is null, como en el siguiente ejemplo:

var invoice = _invoiceRepository.GetById(18);
if(invoice is null) 
{
    // Hacer algo
}

Ahí queda eso :)

El motivo: la sobrecarga de operadores

¿Y cuál es la causa de esta recomendación? Pues básicamente, que no siempre podemos estar seguros del resultado de esta operación. Como recordaréis, muchos de los operadores de C# pueden ser sobrecargados, y la comparación de igualdad == no es una excepción.

Si por algún motivo se sobrescribiera dicho operador y su lógica introducida así lo decidiera, podríamos encontrarnos con un resultado poco previsible y, sobre todo, muy difícil de depurar.

Es decir, imaginemos que un descerebrado desarrollador introduce un código como el siguiente en la clase Invoice:

public class Invoice
{
    public int Id { get; set; }
    [...]

    public static bool operator == (Invoice a, Invoice b)
    {
        if(a is null || b is null)
        {
            return true;
        }
        return a.Id == b.Id;
    }
}

Como veis, estamos indicando que el operador de igualdad retornará cierto si alguno de los operandos son nulos, por lo que el siguiente resultado será algo diferente a lo que podríamos esperar:

var invoice = new Invoice {  Id = 1 };
Console.WriteLine(invoice == null);      // --> True
Console.WriteLine(invoice is null);      // --> False

En cambio, dado que el operador is no es sobrecargable, el resultado será siempre el esperado.

En fin, la verdad es que son escenarios muy raros de encontrar, pero está bien saber que esta posibilidad existe. Por mi parte no creo que me pueda acostumbrar fácilmente a utilizar is en lugar de == y tampoco tengo claro que me valga la pena el esfuerzo, pero, sin duda, sería lo más correcto.

Publicado en Variable not found.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste:

• 10 razones por las que tu blog te ayuda a encontrar empleo
  José María Aguilar
• Redirecciones HTTP 303, 307 y 308: ¿las conoces?
  José María Aguilar

.NET / .NET Core

• Scripts to remove old .NET Core SDKs
  Scott Hanselman
• Async pitfalls: deferred work and resource ownership
  Ian Griffiths
• Asynchronous functors
  Mark Seemann
• "ImageResizer" is now "dotnet srcset"
  Steve Desmond
• Getting the date of build of a .NET assembly at runtime
  Gérald Barré
• How to generate a zip containing the user personal data to be GDPR compliant in .Net Core 2.1.
  Silvia Campo
• A command-line REPL for RESTful HTTP Services
  Scott Hanselman
• [.NET Internals 09] Just-In-Time (JIT) compilation
  Dawid Sibiński
• C# Intermediate - Static Members in C# & Anonymous and Nullable Types in C#
  Marinko Spasojevic
• Performance in .NET – Part 1
  Ricardo Peres
• How Microsoft rewrote its C# compiler in C# and made it open source
  Mads Torgersen

ASP.NET / ASP.NET Core

• Disable Automatic Model State Validation in ASP.NET Core 2.1
  Talking Dotnet
• Defining Web API Services and Clients with NSwag
  Peter Vogel
• Data Driven Layout in Server-side Blazor
  Jeremy Hutchinson
• Capturing Image From Web Cam In ASP.NET Core MVC
  Saineshwar Bageri
• Asynchronous initialization in ASP.NET Core, revisited
  Thomas Levesque
• TagHelperComponent Show Case - Adding Language Direction
  Hisham Bin Ateya
• What is self-contained deployment mode, works locally but not after deploying
  Benjamin Perkins
• Check the versions of ASP.NET Core available to your Azure App Service
  Jon Hilton
• Customising Routing Conventions In Razor Pages
  Mike Brind
• Customizing ASP.​NET Core Part 01: Logging
  Jürgen Gutsch
• An early look at Reporting API in ASP.NET Core
  Tomasz Pęczek
• ASP.NET Core 2.2.0-preview2 now available
  Sourabh Shirhatti

Azure / Cloud

• Introducing Azure Functions 2.0
  Eduardo Laureano
• Announcing the New App Service Diagnostics Experience
  Jennifer Lee
• Azure Cosmos DB Developer Experience updates
  Deborah Chen
• Microsoft’s Content Delivery Network is now generally available
  Maxwell Gattuso
• Calling a Microsoft Chatbot from a web page
  David Giard
• Azure SignalR Service now generally available
  John Montgomery
• Cosmos DB Emulators can also run in the Cloud
  Julien Oudot

Data

• Haciendo fácil el acceso a datos con Entity Framework Core Parte I y Parte 2
  Jorge Turrado
• Learning Entity Framework: Data Access Approaches of Entity Framework in .NET & Code First Approach and Migrations in Microsoft .NET Entity Framework
  Akhil Mittal

HTML / CSS / Javascript

• Control the Internet With Chrome Extensions!
  Lindsay Grizzard
• Don't use empty or low content for your design system grid examples
  Chris Coyier
• Lazy Loading Images – The Complete Guide
  ImageKit Team
• Putting things on top of other things
  Isabel Brison
• Announcing TypeScript 3.1
  Typescript Team
• Nested Links | CSS-Tricks
  Chris Coyier
• Goodbye JavaScript, Hello WebAssembly
  Ed Charbeneau
• Hands-on With ARIA: Accessibility for eCommerce
  Kyle Speaker

Visual Studio / Complementos / Herramientas

• Will Visual Studio 2019 be an Evergreen Release of Visual Studio?
  Sasha Krsmanovic
• How to filter Fiddler capture traffic using host name and process name
  Bac Hoang
• How to upgrade extensions to support Visual Studio 2019
  Mads Kristensen
• Firefox and Fiddler – Easier than Ever
  Eric Law

Xamarin

• Primer vistazo a Xamarin.Forms gui.cs Backend
  Javier Suárez (Woow!!)
  
• [Xamarin.Forms] Nueva extensión de marcado para OnPlatform y OnIdiom
  Javier Suárez
  

Otros

• Conviértete en un desarrollador con trabajo en menos de un año (no sin esfuerzo)
  Manuel A. Lores

Publicado en Variable not found.

El conocimiento profesional de nuestros padres, y no digamos de nuestros abuelos, era relativamente estable y servía para toda una vida profesional. Sin embargo la velocidad actual nos puede dejar profesionalmente oxidados en menos de una década.

Hoy podemos ser expertos y dentro de un año incompetentes, o como define Fred Kofman,⁽¹⁾ ciegos: profesionales incompetentes que ignoran que lo son —si no lo ignoran, Kofman los llama cretinos—

Es sugerente el ciclo que Kofman describe en el capítulo "Aprendiendo a aprender" del tomo I de Metamanagement, porque ilustra que a la velocidad actual, en las profesiones de conocimiento podemos pasar de expertos a ciegos sin darnos cuenta. 

Con el permiso de Fred Kofman y mi agradecimiento por ello comparto el siguiente fragmento de "Aprendiendo a aprender": 

"Consideremos la siguiente grilla. En ella se describen los progresos del principiante en un recorrido opuesto al sentido de las agujas del reloj, desde el cuadrante superior izquierdo (ciego) hasta el cuadrante superior derecho (experto)

 

 

 

Para no tener que hacer cambios en el código que implica recompilar la aplicación y generar de nuevos los artefactos al cambiar algunos valores de la aplicación se utilizan los archivos de configuración. Los archivos de configuración son archivos de texto plano que pueden seguir algún formato como properties, xml o yaml, externos a la aplicación pero que lee sus propiedades al iniciarse. Algunas propiedades de configuración de ejemplo pueden ser la cadena de conexión a una base de datos, el usuario y contraseña.

Dado que algunos valores de configuración son sensibles como en el ejemplo anterior la cadena de conexión, usuario y contraseña es recomendable por mayor seguridad almacenar estos valores cifrados y que la aplicación los descifre con la clave correspondiente al necesitar su valor original.

Spring Cloud Config permite guardar los archivos de configuración con algunos valores cifrados. Hay varias posibilidades de configuración para guardar los datos cifrados: mediante clave simétrica, clave privada-pública, guardarlos en el servicio externo Vault de [Hasicorp][hasicorp], mantenerlos cifrados solo en el almacenamiento persistente o transmitirlos cifrados y que sea el cliente el que los descifre.

Utilizando la forma más simple para mantener los datos cifrados con una clave simétrica en el servicio de configuración hay que mantener en una propiedad de configuración la clave simétrica para cifrar y descifrar los datos, encrypt.key. En este ejemplo la clave simétrica y las propiedades cifradas están en archivos de configuración diferentes pero incluidos en el mismo servidor de configuración. Esto no parece que aporte mucha seguridad ya que si se tiene acceso al archivo de configuración de un servicio con una propiedad cifrada probablemente se tenga acceso al archivo con la clave cifrada y la medida de seguridad no es útil. Sin embargo, esto permite al estar separados los archivos de configuración añadir el archivo con la propiedad cifrada a un repositorio público sin peligro siempre y cuando la clave de cifrado se mantenga en secreto. Los archivos de configuración de los servicios en el servidor de configuración se podrían añadir a un repositorio de Git.

Definida la clave simétrica e iniciado el servidor de configuración este ofrece dos endpoints para cifrar y descifrar datos. Utilizando el de cifrado se obtiene el valor cifrado del dato sensible que se quiere proteger. Con el endpoint de descifrado se puede descifrar. Se observa que utilizando varias veces el endpoint de cifrado se devuelve en cada una un valor distinto, sin embargo, descifrando cada uno de estos valores con el endpoint de descifrado siempre se obtiene el valor original. Esto es debido seguramente a que en la operación de cifrado se utiliza la técnica del salt para que a los valores cifrados se les pueda aplicar un ataque de diccionario, el salt es incluido en el valor devuelto para que la operación de descifrado devuelva el valor original.

El valor cifrado obtenido por este endpoint se puede guardar en los archivos de configuración entrecomillándolo y precediéndolo con la cadena {cipher}.

En este caso el servicio al iniciarse obtiene su configuración del servicio de configuración, los datos se transmiten en forma plana sin cifrar y el cifrado utilizando en el servidor de configuración es transparente para el cliente. Accediendo al endpoint del servidor de configuración que devuelve la configuración de un servicio con una propiedad cifrada se observa que al obtener el valor se devuelve en texto plano al cliente, esta petición es la misma que hace el servicio para obtener su configuración, de modo que aunque la información está cifrada en el servidor de configuración se transmite al servicio sin cifrar en texto plano. En este ejemplo se utiliza el protocolo inseguro HTTP, lo recomendable es utilizar el protocolo HTTPS para cifrar el tráfico entre el servidor de configuración y el cliente de modo que los valores sensibles queden protegidos también en la transmisión.

Iniciado el servicio de descubrimiento, el de configuración y un servicio que tiene un dato cifrado de configuración el valor que obtiene está ya descifrado. En este caso el servicio client obtiene el valor de la propiedad config.password descifrado con el valor secret.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradle-run.sh && ./curl-1.sh.

Java 11 es la primera versión de soporte extendido publicada o LTS bajo el nuevo ciclo de publicaciones que adoptó Java en la versión 9. Añade varias novedades importantes en cuanto a seguridad y elimina otras que en versiones anteriores ya fueron marcadas como desaconsejadas.

En la plataforma Java era habitual que entre versión y versión mayor pasasen varios años normalmente 3 o más. Este ciclo de publicaciones no se adapta a las necesidades de todas las empresas, organizaciones y usuarios. Algunas empresas y usuarios desean ciclos de publicaciones más cortos quizá con no tantas novedades en cada uno de ellos pero sí de forma más constante incorporando mejoras. Otras organizaciones necesitan confiar en una versión que tenga un ciclo de soporte largo para sus aplicaciones.

Para adaptarse a ambos requerimientos Java a partir de Java 9 adoptó un nuevo ciclo de publicaciones siendo cada seis meses para los que desean mejoras de forma regular y cada tres años para los que necesitan soporte extendido. Java 9 incorporó la esperada modularización que cambia la forma de desarrollo de las aplicaciones con numerosas mejoras. Java 10 añadío la inferencia de tipos para variables locales con la palabra reservada var. Ahora Java 11 siendo una versión de soporte extendido o LTS, el soporte de Java 11 está planificado que dure hasta 2023 y hasta 2026 de forma extendida lo que son 8 años de soporte.

En esta nueva versión de Java 11 publicada el 25 de septiembre de 2018 las novedades no son tan relevantes como lo fuero Java 8 con las lambadas y Java 9 con los módulos pero continúa con las mejoras incrementales y proporciona una versión LTS en la que empresas grandes confiarán como base para sus desarrollos.

La lista más relevante de novedades de Java 11 es la siguiente:

• 181: Nest-Based Access Control
• 309: Dynamic Class-File Constants
• 315: Improve Aarch64 Intrinsics
• 318: Epsilon: A No-Op Garbage Collector
• 320: Remove the Java EE and CORBA Modules
• 321: HTTP Client (Standard)
• 323: Local-Variable Syntax for Lambda Parameters
• 324: Key Agreement with Curve25519 and Curve448
• 327: Unicode 10
• 328: Flight Recorder
• 329: ChaCha20 and Poly1305 Cryptographic Algorithms
• 330: Launch Single-File Source-Code Programs
• 331: Low-Overhead Heap Profiling
• 332: Transport Layer Security (TLS) 1.3
• 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
• 335: Deprecate the Nashorn JavaScript Engine
• 336: Deprecate the Pack200 Tools and API

Eliminación de módulos Java EE y CORBA

Se eliminan del JDK paquetes ya desaconsejados hace varias versiones anteriores y que no eran muy usados en cualquier caso. Estos paquetes son los de CORBA una forma de llamada a procedimientos remotos que se utilizó como alternativa a RMI pero que nunca tuvo un uso extendido prefiriéndose SOAP o más recientemente interfaces REST.

La lista de paquetes eliminados son los siguientes.

• java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services Metadata)
• java.xml.bind (JAXB)
• java.activation (JAF)
• java.xml.ws.annotation (Common Annotations)
• java.corba (CORBA)
• java.transaction (JTA)
• java.se.ee (Aggregator module for the six modules above)
• jdk.xml.ws (Tools for JAX-WS)
• jdk.xml.bind (Tools for JAXB)

Sintaxis de variables locales para parámetros en lambdas

Ahora los parámetros de una lambda pueden declararse con var con inferencia de tipos. Esto proporciona uniformidad en el lenguaje al declarar los parámetros permite usar anotaciones en los parámetros de la función lambda como @NotNull.

Esta funcionalidad tiene algunas restricciones. No se puede mezclar el uso y no uso de var y no se puede mezclar el uso de var y tipos en lambdas explícitas. Son consideradas ilegales por el compilador y producirá un error en tiempo de compilación.

Cliente HTTP

En Java 9 se incorporó de forma experimental un cliente HTTP con soporte para HTTP/2 en el propio JDK. En Java 11 alcanza la categoría de estable. Este cliente HTTP es una forma sencilla de hacer llamadas a servicios web ya sean REST o GraphQL. Las clases del nuevo cliente se encuentran en el paquete java.net.http. Al estar este cliente HTTP incorporado en el JDK no será necesario depender de librerías de terceros.

Ejecución desde archivo de código fuente único

Para ejecutar un programa Java es necesario compilarlo a bytecode y posteriormente ejecutarlos. Se necesitan dos pasos. Para facilitar la ejecución de los programas que se componen de un único archivo de código fuente se añade la posibilidad de lanzar un programa desde el archivo de código fuente. Esto es útil par programas pequeños o para los casos de estar aprendiendo el lenguaje.

Esta funcionalidad es compatible con los shebang de los sistemas Unix.

Unicode 10

Tratar texto es una parte importante casi de cualquier aplicación, este soporte de Unicode 10 añade 16018 nuevos caracteres soportados, 128 nuevos emojis y 19 símbolos nuevos para el estándar en televisiones 4K.

TLS 1.3

Algunas de las versiones anteriores de TLS ya no se consideran seguras añadir soporte para la versión más reciente TLS 1.3 permite a las aplicaciones Java ser más compatibles y más seguras. El protocolo TLS 1.3 proporciona dos beneficios principalmente, es más seguro y más rápido que sus versiones anteriores.

Otras mejoras

Se añaden implementaciones específicas para la arquitectura Aarch64 para un mejor rendimiento en la plataforma ARM en algunas funciones. Se añade de forma experimental un nuevo recolector de basura ZGC con pausas para recolectar basura menores capaz de manejar cantidades de memoria pequeñas de megabytes y grandes de terabytes. Al mismo tiempo se añade un recolector de basura Epsilon que no reclama la memoria. Se añade soporte para los algoritmos criptográficos ChaCha20 y Poly1305 junto con otras funcionalidades criptográficas RSASSA-PSS, AES Encryption with HMAC-SHA2 for Kerberos 5, …

Se añaden varios métodos a la clase String muy utilizados con los que no será necesario recurrie a librerías de terceros. Estos métodos son repeat, isBlank, strip, stripLeading, stripTrailing, lines. En otras clases de la API también se han añadido nuevos métodos.

Java que tradicionalmente marcaba como deprecarted características pero que las seguía manteniendo por compatibilidad hacia atrás parece que ha empezado a eliminar varias de esas características desaconsejadas de forma más agresiva. No solo se añaden nuevas características, también se eliminan algunas y se desaconseja el uso de otras entre ellas el visor de applets, eliminación de Unsafe.defineClass, Thread.destroy() y Thread.stop(Throwable), eliminación de las funcionalidades de despliegue de Java Plugin y Java Web Start que se marcaron como desaconsejadas en Java 9 y para eliminación en Java 10 finalmente en Java 11 se han eliminado sin reemplazo.

Oracle ya no ofrece el entorno de ejecución JRE ni versiones de 32 bits para Windows. JavaFX ya no está incluído en el JDK pero seguirá siendo utilizable como librería independiente.

Las anteriores son las funcionalidades que he considerado más destacables para todos los usuarios., También hay otras funcionalidades añadidas, soporte eliminado para funciones específicas o de funcionamiento interno.

Editando un archivo relativamente largo de código, me empecé a frustrar porque el desplazamiento y renderizado de código andaba lento. Lo primero que tenía que hacer era encontrar el culpable de la lentitud. Por suerte Emacs tiene incorporado un profiler. Para activarlo tenemos que usar M-x profiler-start y seleccionar si queremos hacer profiling de cpu, memoria o ambos. Mi problema parecía de cpu porque se trancaba en momentos que intentaba desplazarme rápido por varias líneas de código. Con M-x profiler-report, podemos ver un buffer nuevo que nos muestra los resultados. Y un test bastante corto mostró cuál era el problema:

No olviden ejecutar M-x profiler-stop si están probando algo, porque no deja de gastar algunos recursos extra tenerlo corriendo.

El nombre linum me resultaba familiar por haber leído al respecto antes, particularmente relacionado a la lentitud de Emacs. Se trata de una biblioteca que provee el número de línea, y viene incluida con Emacs desde su versión 22. Como Emacs no proveía ver el número de línea de forma nativa, las bibliotecas de número de línea en general son bastante lentas.  Pero en la versión estable actual, Emacs 26, finalmente se implementó el número de línea nativo. Así que era el paso que me faltaba para actualizar a Emacs 26. De los cambios de la versión 26:

Ahora Emacs soporta mostrar el número de líneas en el buffer. Esto es similar a lo que provee `linum-mode`, pero mucho más rápido y sin usurpar el margen para los números de línea. Personaliza la variable local de buffer ‘display-line-number’ para activar este display opcional. Alternativamente, se puede usar el modo menor ‘display-line-numbers-mode’ o el global ‘global-display-line-numbers-type’ con el mismo valor que ‘display-line-numbers’.

Los números de línea no se muestran en las ventanas de minibuffers y tooltips, porque no son útiles ahí (…)
‘linum-mode’ y todos los paquetes similares se vuelven obsoletos de ahora en adelante. Se alenta a los usuarios y desarrolladores a cambiar a esta nueva característica en su lugar.

Lamentablemente en Debian y Ubuntu todavía no han actualizado a la versión 26.1 de Emacs. En ArchLinux sí, como era de esperarse. Pero por suerte a los que usamos .deb, siempre nos salva un ppa. En este caso el PPA de Kevin Kelley: https://launchpad.net/~kelleyk/+archive/ubuntu/emacs

Dicho repositorio contiene paquetes basados en las versiones estables de Emacs: 25 y 26. Así que lo agregué a mi apt y procedí a instalar emacs26. Lo bueno es que emacs25 y emacs26 pueden convivir en el sistema. Así que en este momento tengo ambos por las dudas que encuentre alguna cosa que no funcione perfecto en Emacs 26 y pueda usar 25 como respaldo. Por ahora viene todo bien.

Con respecto a la lentitud, ni bien actualicé a la versión más nueva abrí el mismo archivo de código que había destacado el problema en un principio, y la diferencia fue gigante. El desplazamiento entre líneas es mucho más rápido y fluido. Probé con archivos más grandes de miles de líneas, y es el día y la noche.

¿Y Spacemacs?

Desde hace poco más de un año vengo usando Spacemacs (una “distribución” de Emacs). Por suerte Spacemacs soporta la nueva implementación de número de línea desde hace un tiempo. Incluso noté al iniciar Spacemacs con Emasc 26, que se desinstalaba el paquete relacionado a linum, y al iniciar Emacs 25 se vuelve a instalar, por lo que Spacemacs sabe qué usar dependiendo de la versión de Emacs.

Así que por el momento, sigo usando Emacs 26

El evento

Como parte de evento que se realiza en todo el mundo durante estos meses, he tenido la suerte de organizar y participar como ponente en la NetConf en Madrid.

Gracias a la generosidad de la gente de la Universidad Politécnica de Madrid el evento ha tenido una locación inmejorable.

Ha sido una versión de tres charla en la que he tenido la suerte de compartir cartel con dos grandes del mundo de .NET de España como Javier Valero y Robert Bermejo.

Sobre Azure DevOps

Cuando preparé la charla no existía Azure DevOps por lo tanto mi charla fuer sobre Visual Studio Team Services, en concreto sobre cómo montar un entorno de despliegue continuo de una aplicación ASP Net Core en Docker sobre Azure.

Dejo un link a las diapositivas que utilicé durante la charla.

Gracias a los ponentes, a la UPM y a Tokiota por el apoyo.

Nos leemos.

Después de haberme centrado en el rendimiento de FileOptimizer, con análisis, limpiezas y optimizaciones regulares había llegado el momento de centrarse en su estabilidad y su seguridad. Al igual que en cuanto a la eficiencia podemos guiarnos por nuestro “saber hacer”, apoyarse en herramientas es algo de gran ayuda. Además de las advertencias del compilador, […]

La entrada Análisis estático de FileOptimizer aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

El proyecto Tor organiza una serie de eventos en Ciudad de México a partir de la semana que viene. Sumamente interesantes, para aprender qué tienen planeado, cómo tener un repetidor de Tor, y cómo unirse a la comunidad. A continuación la información de los eventos, desde el blog oficial de Tor:

A finales de septiembre, personas que colaboran con Tor en todo el mundo se reunirán en la Ciudad de México por uno de nuestros encuentros bianuales. Hablaremos sobre el futuro de Tor como organización y decidiremos en qué protocolos y características enfocaremos nuestros esfuerzos. Es una oportunidad para que los equipos distribuidos en Tor pasen tiempo juntos y definan en qué trabajar en los próximos meses y años.

Como parte de este encuentro, también tendremos dos días de hackatón abierto para que todos pueden sumarse. Los días de puertas abiertas durante el encuentro en Ciudad de México serán el martes 2 de Octubre y el miércoles 3 de Octubre en el Sheraton María Isabel. Para obtener más información, consultá la wiki de la reunión.

¿Qué son los días abiertos?

Estos días son oportunidades para desarrolladores y personas sin experiencia técnica para venir y pasar el rato con algunos miembros del equipo de Tor. Aquí se puede obtener más información acerca de Tor, hackear algo con nosotros o simplemente conocer a gente interesante que también esté interesada en el software libre y de código abierto, la privacidad en línea y la libertad de expresión.

Estos días están abiertos a todos, independientemente de su nivel de habilidad técnica. Si estás interesado en contribuir con Tor (ya sea como voluntario o por un puesto pagado), este es también un buen momento para aprender más sobre lo que estamos haciendo y unirte a nuestra comunidad.

Este año, tendremos varias sesiones diseñadas para los recién llegados. Estas incluyen Introducción a Tor para principiantes (en inglés y en español) y “State of Onion” una charla sobre dónde estamos y hacia dónde vamos. Estaremos desarrollando el cronograma hasta los mismos días del evento, pero puedes ver todo lo que tenemos planeado hasta ahora.

¡Ven a contribuir con Tor!

Los días de puertas abiertas durante la encuentro de Tor, al igual que todos los eventos de Tor, se ejecutan según las pautas y el código de conducta de nuestros participantes.  ¡Traé tus ideas y preguntas, vamos a juntarnos y hackear! La mayoría de las sesiones se realizarán en inglés, pero habrá algunas en español. Recuerda que habrá oradores de múltiples idiomas asistiendo.

¿Que más sucede?

Relay Meetup

2 de octubre, 6:30 p.m. Sheraton María Isabel. En inglés.

La red Tor está compuesta por miles de voluntarios que dan su tiempo y ancho de banda para hacer del mundo un lugar mejor ejecutando nodos o relays. Los días de puertas abiertas de esta reunión incluyen una reunión de operadores de relays organizada por Colin Childs, aka Phoul en el IRC.

Vení y conocé a otros operadores de relays y escuchá las últimas noticias sobre Tor: tendremos camisetas y calcomanías para equipar sus dispositivos. Si no maneja un nodo o relay pero le gustaría saber más, habrá muchas personas en la reunión dispuestas a ayudarlo.

Coloquio “Mecanismos de Privacidad y Anonimato en Redes”

4-5 de octubre, de 10 a.m. a 6 p.m. Auditorio Sotero Prieto, Facultad de Ingeniería, en la Universidad Nacional Autónoma de México (UNAM). Este evento se llevará a cabo en español e inglés.

Después de la reunión, se llevará a cabo un coloquio centrado en la privacidad y la seguridad en la UNAM. El evento está siendo coordinado por gwolf. Haga clic aquí para obtener información del mapa y programa.

Tor Meetup Feminista

Tormenta: diálogos feministas para las libertades y autocuidados digitales
4 de octubre, de 4 a 8 p.m. Facultad de Ingeniería, UNAM. Sala de videoconferencia, en el sótano del Centro de Ingeniería Avanzada. En Español.

Invitación a un encuentro de activistas feministas de México a las mujeres y personas no binarias de la comunidad de Tor, para conversar y compartir experiencias sobre el uso de internet, y el desarrollo de herramientas técnicas para el anonimato. El objetivo de este encuentro es reconocer el trabajo y las apuestas que están detrás de algunas de las herramientas de protección digital que utilizamos todos los días. Será un encuentro informal de entrada libre, abierta y gratuita.

La Leyenda de Zelda es de esas sagas que sigue publicando nuevos títulos y reinventándose. El año pasado Breath Of The Wild sorprendió al mundo rompiendo récords de ventas y revolucionando el género open world. Link’s Awakening fue el primer Zelda que jugué. Con sólo 8 bits, y a través de la pantalla verde del Game Boy que me prestaba mi vecino, el juego lograba transportarme a Koholint Island y vivir las aventuras como Link intentando despertar al Wind Fish. Por la intriga y el sentimiento de aventura y misterio que me despertaba (y el factor nostalgia) sigue siendo uno de mis juegos favoritos. Con Breath Of The Wild volví a vivir la experiencia, esta vez en un mundo mucho más amplio y poblado.

El siguiente video muestra cómo podría verse una versión “Link’s Awakeningesca” de Breath Of The Wild. Como si fuera poco los gráficos y la música, usan el modelo de Game Boy Color Atomic Purple que compré hace tantos años y donde volví a jugar varias veces esta aventura con Link’s Awakening DX:

Después de mirarlo no sé si ponerme a jugar a Breath Of The Wild o Link’s Awakening…

Hace unos días, un alumno del curso online de ASP.NET Core en CampusMVP (por cierto, desde hace unas semanas actualizado a la versión 2.1) me planteaba una cuestión que quizás podría interesar a alguien más, por lo que vamos a comentarla por aquí.

Básicamente, la duda era la siguiente:

¿Hay alguna forma sencilla de añadir el atributo [Authorize], pero sólo a los controladores que se encuentren en una carpeta determinada del proyecto, sin tener que aplicarlo uno a uno?

La respuesta rápida es: sí. Bueno, con matices ;) Incluso hay varias opciones, así que vamos a ver algunas de ellas, y de paso repasamos conceptos de ASP.NET Core MVC :)

Opción 1: Usar clases base

La primera forma que se me ocurre, y quizás la más sencilla, es hacer los controladores presentes en la carpeta hereden de una clase base y aplicar los filtros sobre ella, de forma que todos sus descendientes se vean afectados.

[Authorize(Roles="admin")]
public abstract class AdminController: Controller
{
}

...

// En Controllers/DashboardController.cs
public class DashboardController: AdminController
{
    // Esto ya estará protegido 
    // por el [Authorize] de AdminController
}

Ya, me diréis que recorrer todas las clases que nos interesen y hacer que hereden de AdminController nos llevará el mismo tiempo que aplicarles directamente el atributo [Authorize], y es cierto. Sin embargo, si más adelante tuviéramos que modificar los criterios de admisión para estos controladores (por ejemplo, añadir otros roles o policies), sólo tendríamos que tocar en este punto del código.

Opción 2: Usar atributos personalizados

Otra posibilidad sería crear un authorization filter personalizado e introducirlo como filtro global de la aplicación.

El siguiente código muestra un filtro que, establecido de forma global, observaría todas las peticiones entrantes y comprobaría que el usuario esté logado y ostente el rol "admin", pero sólo en aquellas acciones cuyos controladores hayan sido definidos en el espacio de nombres que comience por "MyApp.Controllers.Admin":

public class AdminAuthorizeAttribute : IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        var actionName = context.ActionDescriptor.DisplayName;
        if(actionName.StartsWith("MyApp.Controllers.Admin."))
        {
            var user = context.HttpContext.User;
            if (!user.Identity.IsAuthenticated || !user.IsInRole("admin")) {
                context.Result = new ForbidResult();
            }
        }
    }
}

Obviamente, no estamos teniendo en cuenta las carpetas físicas en las que se encuentran los controladores, puesto que son simplemente una forma de organizar el código fuente, sino sus namespaces, que es la forma en que se organizan los componentes.

Con esto, ya sólo habría que establecer el filtro como global, algo que conseguimos retocando ligeramente el método ConfigureServices() de la clase Startup:

public void ConfigureServices(IServiceCollection services)
{
    [...]
    services.AddMvc(opt =>
    {
        opt.Filters.Add(new AdminAuthorizeAttribute());
    })
    .SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}

Fijaos que, quizás de una forma extraña, pero acabamos de definir una convención en nuestra aplicación que podríamos definir así: "todos los controladores del espacio de nombres MyApp.Controllers.Admin" deben estar decorados con el atributo [Authorize]".

Hey, ¿y no traía MVC Core algo para facilitar la implementación de convenciones? Pues sí, y ya hablamos de ello hace bastante tiempo...

Opción 3: Usar convenciones personalizadas

Si echáis un vistazo al enlace anterior, seguro que veis rápidamente que en esta feature del framework MVC es donde tenemos la solución más elegante a nuestro problema.

Básicamente, la idea consiste en introducir código que modifique el ApplicationModel, una estructura en memoria creada por ASP.NET Core MVC en el momento del arranque, que describe todas las "piezas" que componen la aplicación: controladores, acciones, filtros, parámetros, rutas, constraints, etc.

El código que modifica el modelo de aplicación es lo que en el framework llamamos una convención. Por ejemplo, podríamos crear una convención que hiciera que las acciones cuyo nombre acabe por "Post" sean sólo accesibles mediante el verbo HTTP post, o añadir un filtro que compruebe el token JWT a todos los controladores que hereden de una clase determinada, o modificar las rutas en función de cualquier criterio... En definitiva, podemos hacer casi cualquier cosa :)

Suena complejo, ¿verdad? Pues nada más lejos de la realidad. En la práctica, estas convenciones son clases que implementan las interfaces IApplicationModelConvention, IControllerModelConvention, IActionModelConvention o IParameterModelConvention, dependiendo del ámbito en el que vayamos a aplicar nuestra convención.

En nuestro caso, dado que queremos aplicar una convención a los controladores, la interfaz que nos interesa es IControllerModelConvention, cuya signatura es la siguiente:

public interface IControllerModelConvention
{
    void Apply(ControllerModel controller);
}

Durante el arranque de la aplicación ASP.NET Core MVC irá invocando sucesivamente este método por cada controlador de nuestra aplicación, enviándonos en el objeto ControllerModel toda la información disponible sobre el mismo. Y, como comentaba antes, lo mejor es que gran parte de esta información puede ser modificada al vuelo.

El siguiente código muestra la convención AdminControllersAreOnlyForAdminsConvention que añade automáticamente el filtro Authorize, configurado apropiadamente, a todos los controladores cuyo espacio de nombres sea el que nos interesa:

public class AdminControllersAreOnlyForAdminsConvention : IControllerModelConvention
{
    public void Apply(ControllerModel controller)
    {
        if (controller.DisplayName.StartsWith("MyApp.Controllers.Admin."))
        {
            var policy = new AuthorizationPolicyBuilder()
                            .RequireRole("admin")
                            .Build();
            controller.Filters.Add(new AuthorizeFilter(policy));
        }
    }
}

Para que sea tenida en cuenta, esta convención se debe añadir al registro de servicios de la clase de inicialización Startup como una opción de configuración del _framework MVC:

services.AddMvc(opt =>
{
    opt.Conventions.Add(new AdminControllersAreOnlyForAdminsConvention());
});

Y de esta forma tan sencilla, de nuevo hemos llegado a nuestro objetivo :)

Publicado en Variable not found.

Venimos con la segunda parte de “Haciendo fácil el acceso a datos con Entity Framework Core“. Esta vez, vamos a hacer el mismo ejemplo, pero con la opción “Code First”. Utilizando esta opción, vamos a generar nuestra base de datos mediante clases que relacionaremos entre ellas, así veremos las dos caras de la moneda.

Modelo

Tengamos el objetivo claro, mediante la opción “Code First” vamos a buscar conseguir un modelo como este:

En el tenemos 2 relaciones 1 a muchos:

1. Un profesor podrá impartir varios cursos.
2. Cada curso puede tener varios alumnos.

Creando la solución en Visual Studio

En primer lugar, vamos a crear el proyecto, solo que esta vez, será un proyecto de consola Net Core:

Paquetes

Como la vez anterior, instalamos los paquetes de Entity Framework Core vía NuGet:

En caso de querer hacerlo vía consola:

PM->Install-Package Microsoft.EntityFrameworkCore -Version 2.1.3
PM->Install-Package Microsoft.EntityFrameworkCore.Tools -Version 2.1.3

Y lo mismo para el proveedor de MySql

O como siempre, por consola:

PM->Install-Package Pomelo.EntityFrameworkCore.MySql -Version 2.1.2

Creando la solución en DotNet CLI

Una de las ventajas de Net Core es que nos permite ejecutar sus acciones desde línea de comandos, con eso, conseguimos toda la funcionalidad en plataformas como Linux. En este caso, utilizaremos la Powershell. Para crear un proyecto, crearemos una carpeta y navegaremos a ella con:

– mkdir PostEntityCore
– cd PostEntityCore

Una vez dentro de la carpeta, crearemos el proyecto y añadiremos los paquetes con:

– dotnet new console
– dotnet add package Microsoft.EntityFrameworkCore -v 2.1.3
– dotnet add package Microsoft.EntityFrameworkCore.Tools -v 2.1.3
– dotnet add package Pomelo.EntityFrameworkCore.MySql -v 2.1.2

Generando el DbContext

En este caso, el modelo lo vamos a generar mediante clases en nuestro proyecto, a fin de organizar el proyecto, añadiremos una carpeta “Data” a la solución, donde añadiremos las siguientes clases:

Vamos a desgranar las clases:

//Alumnos.cs
using System;
using System.ComponentModel.DataAnnotations;

namespace PostCore.Data
{
    public class Alumnos
    {
        [Key]
        public int IdAlumno { get; set; } //Clave primaria
        public string Nombre { get; set; } 
        public DateTime Nacimiento { get; set; }
        public int IdCurso { get; set; } //Campo clave foranea

        //Entity Framewrok Core
        public Cursos Curso { get; set; } //Objeto de navegación virtual EFC
    }
}

//Cursos.cs
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

namespace PostCore.Data
{
    public class Cursos
    {
        //Inicializamos el objeto de navegacion virtual de Entity Framework Core
        public Cursos()
        {
            Alumnos = new HashSet<Alumnos>();
        }

        [Key]
        public int IdCurso { get; set; } //Clave primaria
        public string Nombre { get; set; }
        public string Ciudad { get; set; }
        public int IdProfesor { get; set; } //Campo clave foranea

        //Entity Framewrok Core
        public Profesores Profesor { get; set; } //Objeto de navegación virtual EFC
        public ICollection<Alumnos> Alumnos { get; set; } //Objeto de navegación virtual EFC
    }
}

//Profesores.cs
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

namespace PostCore.Data
{
    public class Profesores
    {
        //Inicializamos el objeto de navegacion virtual de Entity Framework Core
        public Profesores()
        {
            Cursos = new HashSet<Cursos>();
        }
        [Key]
        public int IdProfesor { get; set; } //Clave primaria
        public string Nombre { get; set; }

        //Entity Framewrok Core
        public ICollection<Cursos> Cursos { get; set; } //Objeto de navegación virtual EFC
    }
}

//PostDbContext.cs
using Microsoft.EntityFrameworkCore;

namespace PostCore.Data
{
    //Heredamos de DbContext nuestro contexto
    class PostDbContext : DbContext
    {
        //Constructor sin parametros
        public PostDbContext()       
        {
        }

        //Constructor con parametros para la configuracion
        public PostDbContext(DbContextOptions options)
        : base(options)
        {
        }

        //Sobreescribimos el metodo OnConfiguring para hacer los ajustes que queramos en caso de
        //llamar al constructor sin parametros
        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            //En caso de que el contexto no este configurado, lo configuramos mediante la cadena de conexion
            if (!optionsBuilder.IsConfigured) 
            {
                optionsBuilder.UseMySql("Server=localhost;Database=postefcore;Uid=root;Pwd=root;");
            }
        }

        //Tablas de datos
        public virtual DbSet Alumnos { get; set; }
        public virtual DbSet Cursos { get; set; }
        public virtual DbSet Profesores { get; set; }
    }
}

Entity Framework Core “Code First” en Visual Studio

Una vez tenemos el contexto creado en nuestro proyecto, iremos a la “Consola del Administrador de paquetes”, y ahí dispondremos de estos comandos:

1. add-migration {nombre} -Context {contexto}
2. remove-migration
3. update-database {nombre} -Context {contexto}
4. drop-database -Context {contexto}

Vamos a explicar los comandos:

add-migration: Con este comando, generaremos la migración que lanzaremos a la base de datos. Este comando tiene 2 parámetros:

1. {nombre}: Con este parámetro indicaremos el nombre que queremos indicarle a la migración, ademas, es obligatorio.
2. -Context {contexto}: En caso de tener más de un contexto de datos en nuestro programa, indicaremos cual de los contextos es mediante este parámetro. Si solo tenemos un contexto de datos, no es obligatorio usarlo.

remove-migration: Con este comando, eliminaremos la ultima migración que hemos generado. Se puede utilizar varias veces consecutivamente para ir eliminando migraciones desde la última a la primera.

update-database: Con este comando, enviaremos a la base de datos los cambios de la migración, haciéndola efectiva:

1. {nombre}: Con este parámetro indicaremos el nombre de la migración que queremos aplicar.
2. -Context {contexto}: En caso de tener más de un contexto de datos en nuestro programa, indicaremos cual de los contextos es mediante este parámetro. Si solo tenemos un contexto de datos, no es obligatorio usarlo.

drop-database: Con este comando, eliminaremos la base de datos. Este comando tiene 1 parámetro:

1. -Context {contexto}: En caso de tener más de un contexto de datos en nuestro programa, indicaremos cual de los contextos es mediante este parámetro. Si solo tenemos un contexto de datos, no es obligatorio usarlo.

Una vez que conocemos los comandos, vamos a ponernos en faena… Para empezar, utilizamos el comando:

add-migration init -Context PostDbContext

Esto genera una carpeta “Migrations” donde va a ir guardando cada una de las migraciones. Conviene no borrar el contenido, ya que almacena las “versiones” del contexto de datos, de modo que podemos revertir los cambios en la base de datos. Ademas, el hecho de almacenar estas migraciones, permite al sistema aplicar cambios de manera incremental en las próximas migraciones, y es requisito para poder aplicar cambios a la base de datos sin que se produzcan errores por tablas ya existentes.

Con eso, ejecutamos:

update-database -Context PostDbContext

Entity Framework Core “Code First” en DotNet CLI

Igualmente, podemos hacer toda la labor desde el cli de dotnet con los comandos equivalentes de “dotnet ef”:

1. migrations add {nombre} -c {contexto}
2. migrations remove
3. database update {nombre} -c {contexto}
4. database  drop -c {contexto}

Vamos a explicar los comandos:

migrations add: Con este comando, generaremos la migración que lanzaremos a la base de datos. Este comando tiene 2 parámetros:

1. {nombre}: Con este parámetro indicaremos el nombre que queremos indicarle a la migración, ademas, es obligatorio.
2. -c {contexto}: En caso de tener más de un contexto de datos en nuestro programa, indicaremos cual de los contextos es mediante este parámetro. Si solo tenemos un contexto de datos, no es obligatorio usarlo.

migrations remove: Con este comando, eliminaremos la ultima migración que hemos generado. Se puede utilizar varias veces consecutivamente para ir eliminando migraciones desde la última a la primera.

database update: Con este comando, enviaremos a la base de datos los cambios de la migración, haciéndola efectiva:

1. {nombre}: Con este parámetro indicaremos el nombre de la migración que queremos aplicar.
2. -c {contexto}: En caso de tener más de un contexto de datos en nuestro programa, indicaremos cual de los contextos es mediante este parámetro. Si solo tenemos un contexto de datos, no es obligatorio usarlo.

database drop: Con este comando, eliminaremos la base de datos. Este comando tiene 1 parámetro:

1. -c {contexto}: En caso de tener más de un contexto de datos en nuestro programa, indicaremos cual de los contextos es mediante este parámetro. Si solo tenemos un contexto de datos, no es obligatorio usarlo.

Una vez que conocemos los comandos del CLI, vamos a ello

dotnet ef migrations add init -c PostDbContext

En este caso, debemos tener las mismas cosas en consideración que si lo hiciésemos desde Visual Studio.

Con eso, ejecutamos:

dotnet ef database update -c PostDbContext

Resultado

Una vez hecho esto de cualquiera de las 2 maneras, desde el gestor de nuestra base de datos, veremos que se ha creado la base de datos, y si aplicamos la ingeniería inversa para reconstruir el modelo (desde el MySql Workbench), veremos algo así::

Vemos que hemos conseguido generar el modelo que queríamos, pero tenemos una tabla más, “__efmigrationshistory”, en esta tabla es donde Entity Framework Core registra las versiones del contexto que están aplicadas en la base de datos.

Ejemplo

En mi perfil de GitHub he dejado un ejemplo del proyecto, el cual una vez aplicadas las migraciones sobre la base de datos, podemos ver que funciona correctamente ante la misma lógica de programa de la primera parte:

using (postefcoreContext context = new postefcoreContext())
{
    //Creamos el profesor
    Profesores profesor = new Profesores() {Nombre = "Pedro" };
    context.Add(profesor);
    //Creamos los cursos
    Cursos curso1 = new Cursos() { Nombre = "Matematicas", IdProfesor = profesor.IdProfesor };
    context.Add(curso1);
    Cursos curso2 = new Cursos() { Nombre = "Lenguaje", IdProfesor = profesor.IdProfesor };
    context.Add(curso2);
    //Creamos los alumnos
    Alumnos alumno1 = new Alumnos() { Nombre = "Jorge", IdCurso = curso1.IdCurso };
    context.Add(alumno1);
    Alumnos alumno2 = new Alumnos() { Nombre = "Juan", IdCurso = curso1.IdCurso };
    context.Add(alumno2);
    Alumnos alumno3 = new Alumnos() { Nombre = "Andrea", IdCurso = curso2.IdCurso };
    context.Add(alumno3);
    Alumnos alumno4 = new Alumnos() { Nombre = "Sandra", IdCurso = curso2.IdCurso };
    context.Add(alumno4);
    //Guardamos los cambios
    context.SaveChanges();
}

using (postefcoreContext context = new postefcoreContext())
{
    var profesor = context.Profesores //Indicamos la tabla
                          .Include(x => x.Cursos) //Incluimos los resultados coincidentes de la tabla cursos (inner join)
                          .ThenInclude(x => x.Alumnos) //Incluimos los resultados coincidentes de la tabla alumnos (inner join)
                          .First(); //Seleccionamos el primero
    foreach (var curso in profesor.Cursos)
      foreach (var alumno in curso.Alumnos)
        Console.WriteLine($"El alumno {alumno.Nombre} recibe el curso de {curso.Nombre},impartido por {profesor.Nombre}");
}

Nos devolverá:

El alumno Juan recibe el curso de Matematicas,impartido por Pedro
El alumno Jorge recibe el curso de Matematicas,impartido por Pedro
El alumno Sandra recibe el curso de Lenguaje,impartido por Pedro
El alumno Andrea recibe el curso de Lenguaje,impartido por Pedro

En caso de no tener Visual Studio, lanzaremos el proyecto desde el CLI de dotnet con :

dotnet run –proyect PostCore

Aviso a navegantes

En caso de que no queramos almacenar las migraciones, se pueden borrar del proyecto eliminándolas como archivo, o simplemente con:

PM -> remove-migration
CLI -> dotnet ef migrations remove

Pero cada vez que queramos crear una nueva migración y aplicarla, no existirá la migración previa, de manera que tendremos que hacer un drop a la base de datos mediante

PM-> drop-database -Context PostDbContext
CLI-> dotnet ef database dtop -c PostDbContext

asumiendo con ello la consiguiente perdida de datos. En caso contrario, el update lanzará un error indicando que las tablas ya existen en la base de datos.

En entornos de desarrollo, no es necesario revisar la migración ya que presumiblemente no nos importa la posible perdida de datos, pero si vamos a aplicar migraciones en entornos de producción, conviene que revisemos los ficheros generados en la migración, donde veremos que se definen 2 métodos:

protected override void Up(MigrationBuilder migrationBuilder)
protected override void Down(MigrationBuilder migrationBuilder)

Estos dos métodos serán ejecutados durante las actualizaciones de la base de datos (“Up” al aplicar un migración y “Down” al quitarla) y conviene que estemos seguros de que si por ejemplo queremos cambiar como almacenamos los datos de un nombre, unificando dos columnas, hacemos que se genere una nueva columna, se migren los datos de las previas a la nueva, y entonces se borren la previas, de modo que no tengamos una perdida de datos. En cualquier caso, siempre que la migración tenga posibilidades de que se produzca una perdida de información, Entity Framework Core nos lo notificara con el mensaje:

En este enlace, dejo un ejemplo de la documentación oficial detallando más sobre ese tema.

**La entrada Haciendo fácil el acceso a datos con Entity Framework Core (Parte 2) se publicó primero en Fixed Buffer.**

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste:

• Extendiendo claims de usuarios en ASP.NET Core
  José María Aguilar
• ¿Se pueden desarrollar aplicaciones ASP.NET Core con Visual Basic .NET?
  José María Aguilar

.NET / .NET Core

• Announcing .NET Framework 4.8 Early Access build 3646
  Jamshed Damkewala
• Announcing Cumulative Updates for .NET Framework for Windows 10 October 2018 Update
  Brett Lopez
• Implementing Self-Organizing Maps with .NET Core
  Nikola Živković
• C# Intermediate - Properties in C#
  Marinko Spasojevic
• C# 8 Small Features
  Jonathan Allen
• C# Special Method Names
  Ricardo Peres
• .NET Core Opinion
  K. Scott Allen
• Introduction to ANNdotNET v1.0 deep learning tool on .NET Platform
  Bahrudin Hrnjica
• Avoid Logging in Low-Level Code
  Mark Heath

ASP.NET / ASP.NET Core

• The future of ASP.NET SignalR
  Andrew Stanton-Nurse
• How to register a service with multiple interfaces in ASP.NET Core DI
  Andrew Lock
• Deleting records in ASP.NET Core using AJAX with partial page refresh
  Jerrie Pelser
• How the Next Delegate Works In ASP.NET Core Middleware
  K. Scott Allen
• ASP.NET Core 2.2 introduces API Analyzer for improved WEB API documentation
  Talking Dotnet
• 10 Points to Secure Your ASP.NET Core MVC Applications
  Saineshwar Bageri
• Using MessagePack with ASP.NET Core WebAPI
  Anuraj Parameswaran
• Dependency Injection Lifetimes in Blazor
  Jeremy Hutchinson
• Different js scripts for different ASP.NET core environments
  Jon Hilton
• Running ASP.NET Core content negotiation by hand | StrathWeb. A free flowing web tech monologue.
  Filip Woj
• Deploying an ASP.NET Core application to Windows IIS
  Damien Bowden
• Getting around Chrome POST XSS Protection
  Rick Strahl

Azure / Cloud

• Azure Tips and Tricks Part 157 - Part 1 Create Thumbnail Images with Azure Functions and Azure Storage
  Michael Crump
• Using Azure Storage Explorer - Simple Talk
  Supriya Pande
• Immutable storage for Azure Storage Blobs now generally available
  Michael Hauss
• Azure DevOps Continuous Build/Deploy/Test with ASP.NET Core 2.2 Preview in One Hour
  Scott Hanselman

Data

• Entity Framework Core Tutorial
  Simon Timms

HTML / CSS / Javascript

• El juego de la igualdad en JavaScript
  Alvy
• Fundamentos de JavaScript: por qué deberías saber cómo funciona el motor
  CampusMVP
• Flexbox: How Big Is That Flexible Box?
  Rachel Andrew
• A new CSS-based web attack will crash and restart your iPhone
  Zack Whittaker
• WebAssembly Load Times and Performance – Unity Blog
  Marco Trivellato
• Here is why appendChild moves a DOM node between parents
  Max Wizard
• Building A PWA Using Angular 6
  Ahmed Bouchefra

Visual Studio / Complementos / Herramientas

• ASP.NET Core in Visual Studio for Mac – Help us build the best experience
  Sayed Ibrahim Hashimi
• How to upgrade extensions to support Visual Studio 2019
  Mads Kristensen
• Visual Studio Live Share Can Do That?
  Burke Holland
• Creating A Basic Chrome Extension
  Dan Shultz

Xamarin / Cross-platform

• [Xamarin.Forms] Efecto para personalizar la StatusBar
  Javier Suárez
• Upgrading from Plugins to Xamarin.Essentials
  James Montemagno
• Xamarin.Forms 3.2.0 Released: Going Big with Little Things |
  David Ortinau
• Flutter Release Preview 2: Pixel-Perfect on iOS
  Flutter Team

Otros

• Twenty Years as a Freelance Web Developer: Wisdom Gained and Lessons Learned | CSS-Tricks
  Adam Coti
• Instaladores en Windows y qué diferencia existe entre un instalador .exe y uno .msi
  José Manuel Alarcón
• Why is Alt+F4 the hotkey for closing a window? Why not Alt+F5 or Alt+F3?
  Raymond Chen

Publicado en Variable not found.

En el primer post vimos como interactuar con IPFS de forma sencilla. Ahora vamos a dar un paso más y vamos a alojar una web en IPFS, aprovechando todas las ventajas de escalabilidad y disponibilidad que nos ofrece la red. Para ello usaremos además otro protocolo llamado IPNS, que sería similar a DNS pero en la red IPFS.

Las páginas ideales para IPFS actualmente son las que siguen el JAMstack, es decir, uso extensivo de JavaScript en el cliente, que podrá conectarse a APIs para obtener/actualizar información. Las APIs no tienen por qué ser centralizadas, ya que JavaScript con WebRTC puede buscar peers, posibilitando APIs descentralizadas.

Generando el contenido estático

El primer paso será generar el contenido estático de la web. Para ello existen herramientas muy conocidas como Jekyll, Hugo o Pelican.

No nos vamos a alargar más en esto, ya que cada herramienta tiene sus pasos. El resultado final será una carpeta con ficheros HTML, CSS, fuentes, imágenes y JavaScript.

Subir a IPFS

Teniendo el nodo IPFS en funcionamiento, subimos la carpeta del modo habitual, en mi caso, voy a subir la página que está en http://adrianistan.eu .

ipfs add -r adrianistan.eu/

Y anotamos el último hash.

Comprobamos que la web es accesible, tanto desde la gateway del nodo, como una externa:

Tanto en el nodo local como en uno externo, la web carga perfectamente con el hash

IPFS tiene direccionamiento por contenido

En el post anterior mencionamos que IPFS direcciona por contenido gracias a los hashes. Esto tiene unas consecuencias interesantes. Por ejemplo, si se añade un archivo duplicado a IPFS, este tiene exactamente la misma dirección, ya que comparten hash. Por otro lado, los documentos no se pueden actualizar, porque entonces su hash cambia. Sin embargo en una web queremos cambiar contenido, ahí entra en acción IPNS.

IPNS, gestión de nombres para IPFS

IPNS es un protocolo parecido en intenciones a DNS que redirige un ID única al hash correspondiente en ese momento. Registramos el hash de la web actual en IPNS.

ipfs name publish HASH

Ahora sí, el hash IPNS puede publicarse por la red, ya que siempre apuntará a la última versión de la web.

Para acceder a recursos a través de IPNS tenemos que cambiar de protocolo, en vez de /ipfs/HASH, tenemos que poner /ipns/HASH. Vale tanto para comandos como para las gateways HTTP.

https://cloudflare-ipfs.com/ipns/QmYDVeoadAzk9ZW6zwJK3E3KHrA1LWLveEdqUv4XAcCjKa/

En cualquier momento podemos comprobar a que dirección IPFS apunta el hash IPNS:

ipfs name resolve QmYDVeoadAzk9ZW6zwJK3E3KHrA1LWLveEdqUv4XAcCjKa

Para actualizar el contenido simplemente se vuelve a repetir el paso de ipfs name publish. IPFS automáticamente modificará la redirección de IPNS.

Los contenidos antiguos no desaparecen, pero pueden no ser accesibles ya que ningún nodo tenga copia de ellos.

DNSLink

Aún así, ir dándole a la gente un hash IPNS es demasiado complicado. Afortunadamente, podemos usar el DNS tradicional para indicar una ruta IPNS y así, como veremos, facilitar bastante las cosas.

Para ello añadimos un campo TXT en los DNS de nuestro dominio. El contenido es el siguiente:

dnslink=/ipns/HASH

Con esto podremos usar /ipns/dominio.com en la red IPFS. Pero todavía hace falta un cliente IPFS.

Afortunadamente, podemos redirigir mediante CNAME a una gateway HTTP de confianza y ¡la web funcionará correctamente! Para ello hay que crear un campo TXT en el subdominio _dnslink con el mismo contenido que el anterior.

Todas las gateways de IPFS soportan DNSLink para que la transición a IPFS sea lo más transparente posible.

Así, finalmente la página carga con un dominio normal y corriente en un navegador normal y corriente.

Fijaos en la URL

De hecho, vosotros mismos podéis acceder:

http://adrianistan.yayeyo.ga

IPFS Companion

Si usamos mucho IPFS, puede que nos interese una extensión que maneje el protocolo ipfs:// . Tanto en Firefox como en Chrome existe IPFS Companion, una extensión que nos permite acceder a contenido IPFS de forma sencilla.

Servicio systemd

Por último, quiero dejar el servicio de systemd necesario para tener el nodo IPFS funcionando constantemente en nuestro ordenador. En este caso, IPFS lo instalé vía Snap.

[Unit]
Description=IPFS daemon

[Service]
ExecStart=/snap/bin/ipfs daemon
Restart=on-failure

[Install]
WantedBy=default.target

sudo cp ipfs.service /etc/systemd/user/

sudo systemctl --user start ipfs.service
sudo systemctl --user enable ipfs.service

Y con esto ya tendríamos suficiente como para jugar con IPFS un buen rato.

La entrada Alojando una web en IPFS se publicó primero en Adrianistán.