Github lanza Sponsors, una plataforma para ayudar a que los desarrolladores reciban donaciones por sus proyectos open source

23/05/2019
Artículo original

Github lanza Sponsors, una plataforma para ayudar a que los desarrolladores reciban donaciones por sus proyectos open source

GitHub, propiedad de Microsoft y uno de los sitios webs más conocidos por la comunidad de desarrolladores para alojar y administrar su código, inaugura una nueva plataforma mediante la que los desarrolladores podrán dar mejor visibilidad a sus vías de financiación, así como recibir donaciones directamente a través de GitHub.

Esta nueva propuesta recibe el nombre de Sponsors, y permitirá a toda persona u organización con cuenta de GitHub hacer donaciones mensuales a aquellos desarrolladores cuyos proyectos sean de código abierto, mediante un sencillo botón que encontrarán en sus perfiles.

Sin comisiones durante un año e igualación de las donaciones de hasta 5.000 dólares

Github

Según leemos en TechCrunch, GitHub pretende "expandir las oportunidades de participar en el código abierto". El funcionamiento de Sponsors es bastante sencillo, y se centra en mostrar de forma visual y sencilla las vías de financiación de los proyectos de código abierto a aquellos usuarios que quieran colaborar con los desarrolladores. Entre ellas, encontramos la mayor novedad, la financiación a través de GitHub.

Cualquier usuario con una cuenta de GitHub podrá financiar el perfil de un desarrollador de forma mensual

Dentro de este apartado de Sponsors, podremos ver del mismo modo enlaces externos hacia páginas en las que el desarrollador acepta donaciones, como pueda serlo Patreon, una de las más conocidas en nuestro país.

Por el momento, la herramienta estará en fase beta, ya que GitHub quiere comprobar la evolución del programa y analizar su uso. Como adelantábamos, tan solo podrán financiarse los proyectos de código abierto, y durante el primer año, no se cobrará ningún tipo de tarifa por el procesamiento de los pagos. Microsoft ha anunciado también que igualará en hasta 5.000 dólares las donaciones recibidas por los desarrolladores.

Sponsorships Checkbox

En la propia página de GitHub nos cuentan que añadir esta función es bastante sencillo, ya que tan solo hay que activar la visualización del botón de sponsor desde los propios ajustes del repositorio de GitHub.

Los desarrolladores podrán ofrecer recompensas a aquellas personas que contribuyan con su proyecto (aunque no queda claro aún cómo), un sistema muy similar al de las recompensas que se obtienen en otras plataformas como Patreon o Twitch.

Esta plataforma de Sponsor estará disponible en todos los países donde opere GitHub, y es una buena estrategia para frenar la migración a GitLab por parte de aquellos desarrolladores que no vieron con buenos ojos la compra del sitio por parte de Microsoft.

Vía | Techcrunch

GitHub crea Sponsors, su propia plataforma para la financiación pública proyectos open source

23/05/2019
Artículo original

GitHub crea Sponsors, su propia plataforma para la financiación pública proyectos open source

GitHub, propiedad de Microsoft y uno de los sitios webs más conocidos por la comunidad de desarrolladores para alojar y administrar su código, inaugura una nueva plataforma mediante la que los desarrolladores podrán dar mejor visibilidad a sus vías de financiación, así como recibir donaciones directamente a través de GitHub.

Esta nueva propuesta recibe el nombre de Sponsors, y permitirá a toda persona u organización con cuenta de GitHub hacer donaciones mensuales a aquellos desarrolladores cuyos proyectos sean de código abierto, mediante un sencillo botón que encontrarán en sus perfiles.

Sin comisiones durante un año e igualación de las donaciones de hasta 5.000 dólares

Github

Según leemos en TechCrunch, GitHub pretende "expandir las oportunidades de participar en el código abierto". El funcionamiento de Sponsors es bastante sencillo, y se centra en mostrar de forma visual y sencilla las vías de financiación de los proyectos de código abierto a aquellos usuarios que quieran colaborar con los desarrolladores. Entre ellas, encontramos la mayor novedad, la financiación a través de GitHub.

Cualquier usuario con una cuenta de GitHub podrá financiar el perfil de un desarrollador de forma mensual

Dentro de este apartado de Sponsors, podremos ver del mismo modo enlaces externos hacia páginas en las que el desarrollador acepta donaciones, como pueda serlo Patreon, una de las más conocidas en nuestro país.

Por el momento, la herramienta estará en fase beta, ya que GitHub quiere comprobar la evolución del programa y analizar su uso. Como adelantábamos, tan solo podrán financiarse los proyectos de código abierto, y durante el primer año, no se cobrará ningún tipo de tarifa por el procesamiento de los pagos. Microsoft ha anunciado también que igualará en hasta 5.000 dólares las donaciones recibidas por los desarrolladores.

Sponsorships Checkbox

En la propia página de GitHub nos cuentan que añadir esta función es bastante sencillo, ya que tan solo hay que activar la visualización del botón de sponsor desde los propios ajustes del repositorio de GitHub.

Los desarrolladores podrán ofrecer recompensas a aquellas personas que contribuyan con su proyecto (aunque no queda claro aún cómo), un sistema muy similar al de las recompensas que se obtienen en otras plataformas como Patreon o Twitch.

Esta plataforma de Sponsor estará disponible en todos los países donde opere GitHub, y es una buena estrategia para frenar la migración a GitLab por parte de aquellos desarrolladores que no vieron con buenos ojos la compra del sitio por parte de Microsoft.

Vía | Techcrunch

React useReducer

19/05/2019
Artículo original

Cuando queremos manejar estado mas complejo que una sola variable, o que depende muchas condiciones antes de entregar el valor final. Es mejor usar useReducer, este hook es sumamente similar a Redux y como tal es un observer de estado al que podemos subscribir nuestro componente.

Redux no es igual a Hooks o al revés useReducer no es Redux, hay importantes consideraciones de diseño al momento de querer reemplazar redux con hooks, eso lo veremos después cuando presentemos algo mas complejo que un simple contador, de momento vamos a expandir nuestro contador.

El nuevo contador

El nuevo contador nos permitirá incrementar o reducir su valor a voluntad. Solo tiene dos botones a continuación presento el código

import React, { useReducer } from 'react';
import R_merge from 'ramda/src/merge';
import ReactDOM from 'react-dom';

type Action =
  | { type: 'increment' }
  | { type: 'decrement' };

interface State {
  count: number
}

const reducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'increment':
      return R_merge(state, { count: state.count + 1 });
    case 'decrement':

leer más

Chaos Engineering: ¿resistirían tus servidores en la nube el ataque de un ejército de monos locos?

19/05/2019
Artículo original

Chaos Engineering: ¿resistirían tus servidores en la nube el ataque de un ejército de monos locos?

Ningún sistema o plataforma en producción es infalible a caídas. Tampoco podemos asegurar que el lanzamiento de ningún producto se venga abajo a las pocas horas. Quizás en algunos casos se podría haber evitado con un mayor esfuerzo de desarrolladores de software y los administradores de sistemas en las configuración de las aplicaciones, pero nada es así de obvio cuando dispones de una vasta infraestructura distribuida y en diferentes servicios en la nube.

Los usuarios de internet parecen acostumbrados a que sea “normal” que alguna de sus apps o plataformas en la nube se caiga cada cierto tiempo. Pasen horas sin poder acceder al servicio o no puedan ver el último capítulo de su serie. Lo hemos visto con Facebook, Whatsapp o, incluso con algo mucho más frustrante, como HBO España en el estreno de Juego de Tronos. ¿Pero cómo evitar esas caídas masivas? ¿Y, por supuesto, evitar las pérdidas de monetarias que se producen cuando esto sucede?

De aquí surge Chaos Engineering poniendo sobre la mesa la idea de cómo afrontaría cualquier infraestructura distribuida el hecho de que un ejército de monos entrara a sabotear cada una de las configuraciones de red, apagando máquinas en AWS o tirando de forma aleatoria algunos de los microservicios conectados. ¿Qué ocurría? ¿Seguimos respondiendo con normalidad? ¿O por el contrario responderemos con terribles errores 500, 503 o nada de nada?

Chaos Engineering no es algo nuevo, ni el hype del momento

Tenemos que remontarnos a finales de 2010 cuando Netflix publicó su magnífico post sobre las lecciones aprendidas migrando a Amazon Web Service. Por un lado dejaba claro, como una empresa de sus dimensiones necesitaba la nube para poder seguir creciendo y, por otro lado, dejaba claro la preocupación de cómo iba asegurar que todo funcionará bien teniendo ya decenas de servicios distribuidos y ahora totalmente deslocalizados de sus data centers.

Chaos Monkey

De este modo, lo primero que hicieron fue crear un conjunto de herramientas llamadas como el cariñoso apelativo de Chaos Monkey. En un principio, para matar aleatoriamente instancias de AWS y ver cómo afectaba sobre su infraestructura.

De este modo, Netflix se aseguraba tener un control predictivo de cuál sería la experiencia del usuario cuando alguno de sus elementos más importantes se viniera abajo. Así, si el sistema de recomendaciones se caía, ellos podrían redirigir ese tráfico a algo más estático como el listado de de series más populares. O si el sistema de streaming de la plataforma fallaba podría empezar a ajustar la calidad de la reproducción hasta estabilizar la plataforma, de modo que el usuario pudiera seguir usandolo sin cortes. En ningún caso, si la base de datos de recomendaciones falla debería afectar a otro servicio aislado como el servicio de streaming. Si esto sucediera tendríamos un problema, probablemente una dependencia mal configurada totalmente innecesaria.

“Chaos Engineering es la metodología de trabajo para experimentar sobre un Sistema distribuido, con la finalidad de generar confianza en la capacidad del Sistema para soportar condiciones turbulentas en producción.” Manifiesto Chaos Engineering

Causar fallos intencionadamente para descubrir errores en nuestra plataforma en producción

Los primeros en convencerse en usar Chaos Engineering serán aquellos que han tenido que luchar con fallos en producción un viernes por la noche o un día festivo. No están dispuestos a que eso vuelva a ocurrir.

La metodología que promueve Chaos Engineering es simple en concepto, pero complicada de ejecutar. Si los test unitarios son la parte más “micro” centrada en que nuestro código haga lo que dice que hace, entonces Chaos Engineering se puede considerar perfectamente como la parte “macro” para asegurar el correcto funcionamiento en conjunto de toda nuestra infraestructur (en producción).

Es muy complicado a día de hoy introducir la importancia de Chaos Engineering en la cultura de muchos equipos de desarrollo. Posiblemente culpa de los responsables técnicos como el director de tecnología (CTO o CIO) incapaces de comprender lo que cuesta realmente esos fallos de producción cuando ocurren y lo que cuesta a la empresa.

Obviamente, introducir una cultura entre el equipo de desarrolladores de software en la que busquemos proactivamente los fallos de nuestro sistema no es algo habitual, más bien nos tiramos de los pelos a posteriori cuando algo falla inexplicablemente.

Aunque cueste, necesitamos encontrar esos fallos antes de que pasen en nuestra arquitectura: esas latencias innecesarias, esos fallos aleatorios que no sabemos descubrir o que nos impediría servir adecuadamente todas las peticiones que nos lleguen cuando nuestra plataforma tenga un pico de usuarios activos.

Probablemente, los primeros en convencerse serán aquellos que han tenido que luchar con fallos en producción un viernes por la noche o un día festivo. No están dispuestos a que eso vuelva a ocurrir.

Chaos Monkey 2

Chaos Engineering en la práctica

Tal como describe el manifiesto de Chaos Engineering, para abordar la incertidumbre de los distribuidos a gran escala debemos seguir una serie de pasos para realizar los experimentos necesarios:

  • Tenemos que ser capaces de medir nuestro sistema en condiciones normales. Si no estamos monitorizando nuestra plataforma, ya no sólo no podremos averiguar qué falla cuando ejecutemos el experimento, sino que a día de hoy somos incapaces de ver que algo está dando errores. Importante siempre monitorizar tus aplicaciones y la salud de tus componentes.

  • Realizar hipótesis sobre estado al que llevaremos al sistema en producción con los fallos. ¿Cómo debería comportarse? ¿Qué esperamos de él?

  • Definiendo los puntos de fallo de nuestro sistema tenemos que acordar ciertos eventos que provocarán errores lo más parecidos al mundo real: servidores que dejan de funcionar, discos que se quedan sin espacio o pasan a modo lectura, conexiones de red inestables, latencias altas de respuestas,..

  • Trazar un plan revisando los resultados del experimento. Si se ha cumplido nuestra hipótesis o si nos hemos dado cuenta que hay debilidades reales que hacen caer al sistema. Tenemos que solucionarlas antes de que se produzcan de forma real.

Herramientas para utilizar Chaos Monkey en tus aplicaciones

Durante estos años tanto Netflix como AWS han ido desarrollando algunas herramientas para poder simular esos eventos en entornos complejos. Netflix los bautizó como su SimianArmy donde encontramos distintos agentes encargados de elementos fundamentales dentro de nuestra configuración:

  • Introducir delays artificiales a la capa RESTful client-servidor para simular la degradación del servicio y medir si los tiempos de respuestas finales se ven afectados y de qué modo.

  • Encontrar instancias que no se adhieren a los best-practices definidas y ser apagadas. Por ejemplo, esas máquinas puede que estén mal configuradas y no estén siendo autoescaladas adecuadamente.

  • Detectar recursos que no se estén usando en AWS y ser eliminados o descubrir vulnerabilidades o configuración erróneas de seguridad.

Podéis consultar el proyecto open source en Github de SimianArmy y su migración dentro de la infraestructura de CI de Spinnaker. También hay algunos proyectos como Gremlin que intenta acercar los conceptos de Chaos Engineering a más empresas de forma intuitiva a través de su plataforma.

Y si os interesa más el tema aquí os recomiendo este listado sobre recursos en Github: Awesome Chaos Engineering. Así como el libro que escribió el equipo de Netflix sobre el tema.

Como mencionamos más arriba, es necesario que estos experimentos sean adoptados como algo cultural del equipo de desarrollo. Para llevar a cabo los pasos descritos necesitamos flexibilidad para poder simular estos eventos en nuestro entorno de producción o si tenemos un entorno de staging para un experimento inicial más aislado.

Aunque tenemos que recordar que nuestro objetivo es encontrar fallos lo más reales posibles. Y, aunque suena mal, debemos hacer esas pruebas en producción.

Foto | howling red on Unsplash

Mi aplicación ASP.NET se reinicia doctor, ¿es grave?: Aplicaciones, Grupos de aplicaciones y Dominios de Aplicación en IIS y ASP.NET

18/05/2019
Artículo original

Los tres términos del título de este post suelen causar bastante confusión entre los desarrolladores ASP.NET que además deben administrar un servidor web con Internet Information Server bajo Windows. Mi objetivo hoy va a ser tratar de aclararlos y ver qué implicaciones tienen en el día a día de una aplicación Web creada con ASP.NET: cómo funcionan, cuándo se reciclan o se inician, cómo se afectan unos a otros...

En primer lugar considera la siguiente estructura de una aplicación web albergada en IIS:

Estructura básica de una aplicación ASP.NET en IIS

Como vemos existe una aplicación principal que hemos llamado en este caso AplicacionBase, y dentro de ésta, aparte de sus archivos propios, podemos tener varias carpetas con más archivos de la aplicación, así como otras sub-aplicaciones, en este ejemplo concreto tenemos 2: AplicacionA y AplicacionB.

¿Para qué sirven estas sub-aplicaciones? ¿Por qué querríamos crearlas? Pues por muchos motivos, pero sobre todo porque seguramente son aplicaciones diferentes a la principal que se ocupan de cosas diferentes. Por ejemplo:

  • La aplicación principal puede que sea nuestra web, que usa por debajo algún tipo de gestor de contenidos.
  • La aplicación "A" es el producto que vendemos, una aplicación de tipo SaaS que es lo que usan los usuarios tras haberse autenticado y que no está en su propio subdominio.
  • La aplicación "B" podría ser un sistema de facturación Open Source que utilizamos para cobrar a los clientes y que no hemos construido nosotros.

Como, en nuestro ejemplo, cada aplicación es completamente distinta y aislada de las demás, pero queremos tenerlas todas juntas bajo el mismo dominio, hemos decidido montarlas así.

Además, cada una de ellas puede que necesite una versión de .NET diferente y tenga unos requisitos de recursos hardware diferentes (memoria, uso de CPU...). Esto es algo que nos permite gestionar fácilmente IIS.

Nota: crear una sub-aplicación en un sitio de IIS es muy sencillo: basta con pulsar con el botón derecho sobre el sitio raíz y elegir Añadir aplicación:

Añadir aplicación

Aplicación, sitio, sub-aplicación...

Como no, siendo de Microsoft, la primera dificultad ya viene por la propia terminología de IIS. A las aplicaciones "raíz" se les denomina "Sitios" y no aplicaciones. IIS viene con un sitio por defecto y luego puede crear más sitios según vayas necesitando. Pero, salvo que vayas a albergar tan solo páginas estáticas sin ningún tipo de código de lado servidor, estos sitios son en realidad aplicaciones.

Anteriormente a los sitios se les llamaba "servidores virtuales", que hasta me parecía más adecuado que el lacónico término actual.

Es decir, IIS tiene sitios y sub-aplicaciones, pero todos ellos son en realidad aplicaciones. Cuando se habla del término "Aplicación" nos referimos siempre al sentido que le da Internet Information Server.

Grupos de aplicaciones

Cada aplicación de IIS se ejecuta bajo lo que se denomina un Grupo de Aplicaciones o Application Pools (AppPools). Al crear una aplicación (o sub-aplicación, es lo mismo), IIS nos obliga a elegir un grupo de aplicaciones, que puede ser uno ya existente o uno nuevo creado para la nueva aplicación.

Un grupo de aplicaciones es una manera de agrupar y aislar procesos dentro de IIS. Es decir, todas las aplicaciones que comparten un mismo grupo de aplicaciones comparten los mismos recursos de memoria, CPU, etc. y además se gestionan de manera conjunta, reiniciándose a la vez si es necesario. Cada grupo de aplicaciones está aislado de los demás. Esto permite que tengamos muchas aplicaciones distintas y no relacionadas dentro de IIS y que si una se cuelga o debe reiniciarse por algún motivo (reinicio programado, acapara demasiada memoria o CPU...), no afecte al resto de ellas que estñan en otros AppDomains.

Esto es genial, desde luego, para los que se dedican al hosting puesto que asignando un AppPool diferente para cada cliente evita que lo que hagan pueda afectar a los demás. Aparte de que puedes controlar el máximo de recursos que pueden utilizar, sin que ninguno acapare demasiado. Pero para un uso normal de cualquier empresa, sin ser para hosting, también está my bien pues permite tener recursos dedicados a cada aplicación, versiones diferentes de ASP.NET en cada una y, si alguna de ellas o varias no son aplicaciones propias, tenerlas aisladas de las demás.

Podemos ver y gestionar los grupos de aplicaciones desde el apartado correspondiente del gestor de IIS:

Gestión de grupos de aplicaciones

Cada uno de estos grupos aislados nos permite configurar multitud de cuestiones sobre su funcionamiento, siendo lo básico la versión de .NET a utilizar (que puede ser ninguna en caso de usar otro lenguaje de servidor, como PHP, Node.js, ASP Clásico...), si .NET debe interceptar todas las peticiones (modo integrado) o solo las que le correspondan or extensión de archivo (clásico). Pero también muchas otras cuestiones, como

Animación que muestra todas las opciones disponibles en las propiedades avanzadas de un AppPool

Entre todas estas propiedades las más importantes se refieren al reciclado del AppPool. Por defecto los grupos de aplicaciones se reciclan periódicamente cada 1740 minutos. Es decir, por defecto, cada 29 horas, si no indicamos lo contrario, IIS le "pega" un reinicio al grupo de aplicaciones, reiniciando todas las aplicaciones que tenga dentro.

Obviamente esto se puede (y se debe) cambiar y elegir otro tipo de criterios, como por ejemplo que se alcance un uso exorbitado de memoria o que durante más de un tiempo determinado se intente acaparar demasiado uso de procesador, por ejemplo. No voy a entrar en detalles hoy porque no es el objeto, pero es algo muy interesante y útil para tratar de mantener a raya el servidor.

Esto lo gestiona IIS.

Dominios de Aplicación

Al igual que IIS aísla los subprocesos de sus aplicaciones dentro de grupos de aplicaciones, ASP.NET aísla sus subprocesos en lo que se denominan Dominios de Aplicación o AppDomains.

Esto es un concepto de .NET y no tanto de ASP.NET, pero por supuesto ASP.NET les saca partido también. Para entendernos, los dominios de aplicación reemplazan a los subprocesos del sistema operativo y son gestionados por .NET. Al igual que un subproceso real del sistema operativo, un AppDomain aísla sus recursos de los demás AppDomains de modo que no puedan interferir entre ellos y, por ejemplo, el fallo de uno eche abajo a los demás.

Los dominios de aplicación son útiles porque son menos costosos de crear y gestionar que los subprocesos del sistema operativo, cada uno de ellos puede ejecutarse con un nivel de seguridad de .NET diferente, pero todos bajo un mismo proceso del sistema y todos están controlados por el runtime de .NET.

Aunque no es lo más normal, podemos gestionar desde nuestro código los dominios de aplicación como nos plazca.

Generalmente una aplicación creada con ASP.NET genera automáticamente un dominio de aplicación cuando arranca y todos los datos de la aplicación (variables de sesión y aplicación, caché y clases estáticas) están contenidos dentro de éste.

Si en un servidor con IIS abrimos el gestor de procesos (CTRL+MAYs+ESC) podremos ver que cada grupo de aplicaciones tiene un proceso abierto en el sistema operativo (el ejecutable responsable es w3wp.exe):

El gestor de tareas de Windows con los procesos de IIS

Cada uno de ellos se ejecuta bajo un determinado contexto de seguridad (como si fueran usuarios ficticios del sistema) y, si debajo tienen aplicaciones ASP.NET, contienen uno o varios dominios de aplicación de .NET.

Una cosa muy importante a tener en cuenta es que en IIS las sub-aplicaciones de una aplicación, aunque tienen dominios de aplicación diferentes, comparten un dominio de aplicación común que es el de la aplicación "raíz" o base. Así, en el ejemplo del principio, existe un AppDomain para las aplicaciones "A" y "B", y un AppDomain para la aplicación base, pero los de "A" y "B" se dependen del de la aplicación base. Ahora veremos las implicaciones de esto...

Reciclajes, reinicios y su relación con todo lo anterior

Vale, recapitulemos los 3 puntos clave hasta ahora:

  • Los grupos de aplicaciones son la manera que tiene IIS de aislar unos procesos de otros para proteger las aplicaciones que ejecuta. Cada uno de estos grupos de aplicaciones se ejecuta en un proceso del sistema operativo.
  • Cada grupo de aplicaciones puede gestionar una o varias aplicaciones de IIS.
  • En .NET, el mecanismo de aislamiento de procesos se denomina Dominios de Aplicación. Cada aplicación de IIS tiene su propio dominio de aplicación, pero puede tener otros dependientes (los de las sub-aplicaciones).

Bien. En una situación como la que describe la primera figura de este texto, supongamos que las tres aplicaciones tienen sendos grupos de aplicaciones en IIS, con el mismo nombre. Así, la aplicación base se ejecuta en un AppPool llamado AppPoolBase, la "A" en uno llamado AppPoolA y la "B" en AppPoolB (podrían todos compartir el mismo, por supuesto, pero lo dejaré así para dar una explicación más general). Cada uno de estos ejecuta una aplicación ASP.NET por lo que tendrá a su vez un dominio de aplicación propio en .NET.

En el caso de IIS, los grupos de aplicaciones se pueden reciclar, tanto automáticamente en función de las reglas que les hayamos establecido, o a mano en el momento en el que lo deseemos:

Opción del menu contextual de un AppPool para reciclarlo a mano

El reciclaje implica que se crea un nuevo proceso de IIS para atender a las nuevas peticiones que lleguen para esa aplicación, y el proceso anterior se elimina en cuanto se hayan procesado todas las peticiones en curso o pendientes que tuviese. O sea, se levanta un nuevo proceso "fresco" para la aplicación Web, con lo que si el anterior tuviese algún problema (estuviese "colgado", ocupase mucha memoria...) dejaría de dar problemas.

Cuando reciclamos un AppPool de IIS, eliminamos también el dominio de aplicación de la aplicación ASP.NET subyacente. Pero podemos hacerlo de manera independiente sin afectarlos los unos a los otros. En nuestro ejemplo podríamos reciclar el AppDomainB, reiniciando la aplicación "B", pero ni la aplicación "A" ni la aplicación base se enterarían de nada. Tan solo la aplicación "B" se iniciaría de nuevo obteniendo un nuevo dominio de aplicación en el proceso.

Al mismo tiempo, se puede reiniciar un dominio de aplicación de ASP.NET sin tener que reciclar el AppDomain bajo el que está gestionado por IIS. Son cosas independientes. Así, por ejemplo, si todas las aplicaciones de nuestro ejemplo del comienzo compartiesen el mismo grupo de aplicaciones de IIS, podríamos reiniciar el dominio de aplicación de la aplicación "B" sin que se enteraran ninguna de las otras dos (ahora mismo veremos un caso especial que echa por tierra esto).

¿Cómo se reinicia un dominio de aplicación? Pues cuando:

  • Cambias el archivo web.config o el global.asax.
  • Modificas el contenido de la carpeta Bin de la raíz del proyecto, que contiene las DLLs de la aplicación.
  • ¡Si borras cualquier subcarpeta de la aplicación!. Esto no lo sabe mucha gente, pero es una causa común de que se reinicie el AppDomain y por lo tanto que se reseteen las sesiones y otros datos. A más de uno lo puede volver loco.

Hay algunos casos más, pero ya son mucho más raros.

Entonces:

  1. Podemos reciclar un AppPool sin afectar a los demás, creando un AppDomain nuevo para las aplicaciones ASP.NET que contenga.
  2. Podemos reiniciar el AppDomain de una aplicación sin que se enteren las demás, incluyendo las que están en el mismo AppPool de IIS.

Como vemos, es muy flexible.

Sin embargo...

El AppDomain raíz

Este es un caso particular que echa por tierra la segunda afirmación final del apartado anterior. Y es que, como dije antes, el AppDomain de la aplicación raiz o "base" es el que genera los AppDomain de las aplicaciones "hija" o sub-aplicaciones.

En nuestro ejemplo del principio, tanto el AppDomain de la aplicación "A" como el la "B", aún siendo independientes, dependen del AppDomain de la aplicación "Base".

¿Y esto que significa? Pues que aunque podríamos resetar la aplicación "A" sin afectar a la "B" y viceversa, en el momento en el que reseteemos el AppDomain de la aplicación base, también se resetearán los de las aplicaciones "A" y"B", aunque no tengan nada que ver y aunque estén en AppPools de IIS diferentes.

Esto es importante porque si, por ejemplo, cambiamos un parámetro en el web.config de la aplicación base (el "sitio" de IIS), se reiniciará su dominio de aplicación .NET, y automáticamente estaremos reiniciando los dominios de aplicación de las aplicaciones "A" y "B", aunque este parámetro no tenga influencia alguna sobre ellas y aunque las tengamos en dominios de aplicación de IIS diferentes. De hecho, el reinicio de los AppDomain no implica el reinicio de los AppPool en los que están las aplicaciones. No tiene nada que ver en ese sentido (en el sentido contrario sí, pues reiniciando el AppPool se reinicia el AppDomain).

Suena a trabalenguas, pero en el fondo es muy sencillo.

Como moraleja de la historia me gustaría que te llevaras que una aplicación Web de ASP.NET en IIS se puede reiniciar por que se recicle su AppPoool (que implica el reinicio de los AppDomains), o simplemente porque se resetee su AppDomain, y estas acciones se producen por motivos muy diversos y no relacionados.

Por eso, si tu aplicación web presenta problemas y se te reinicia sin saber muy bien por qué, debes primero averiguar qué es lo que se está produciendo (el reciclaje o el reseteo) y entonces buscar las causas subyacentes con las pistas que te he dado en este texto.

¡Espero que te resulte útil!

CSS Scan, una herramienta para inspeccionar y copiar el CSS de cualquier elemento con solo pasar el cursor

15/05/2019
Artículo original

CSS Scan, una herramienta para inspeccionar y copiar el CSS de cualquier elemento con solo pasar el cursor

Todos o casi todos conocemos las herramientas de los distintos navegadores que nos permiten inspeccionar elementos de cualquier página web. En el caso de Google Chrome, por ejemplo, basta con hacer clic derecho y clicar Inspeccionar en el menú. Es una forma fácil y sencilla de ver lo que hay detrás.

Sin embargo, estas utilidades son para muchos algo arcaicas. No han evolucionado al mismo tiempo que sí lo han hecho otras opciones del navegador destinadas a la mayoría de los usuarios, y no tanto a los más próximos al desarrollo. Por tanto, el margen de mejora que tienen es evidente.

Y el ejemplo de ello son alternativas, en este caso a la hora de visualizar los estilos de una página web, como es CSS Scan.

"No vuelvas a abrir nunca DevTools para comprobar los estilos"

Quizás lo primero que hay que decir es que CSS Scan es de pago. Cuesta 24,99 dólares normalmente, aunque ocasionalmente puede encontrarse a un precio promocional de 14,99 dólares. Pero, a la vista de sus opciones y facilidad de uso, su compra está justificada si nos soluciona la vida en cuanto a inspección de estilo.

Sus creadores, de hecho, confían tanto en su herramienta que son claros en su web: "No vuelvas a abrir nunca DevTools para comprobar los estilos".

Uno de los objetivos de CSS Scan es hacerte perder menos tiempo a la hora de inspeccionar estilos

CSS Scan emplea la misma tecnología utilizada por Google y Github con, según explican los responsables, "mejoras para limpiar rápidamente cualquier basura CSS". Esta pensado para ir a lo importante y evitarte perder el tiempo tratando de entender por qué una hoja de estilo no está ofreciendo el resultado esperado. Usas el cursor, lo llevas al elemento problemático, y obtendrás la respuesta sobre el código que lo está definiendo.

CSS Scan, además, deja claro que además de inspeccionar, permite copiar el código CSS. Solo hay que pasar el cursor y hacer un clic. Así queda copiado en el portapapeles y puedes ser copiado en cualquier otro lado para el propósito que uno quiera. La herramienta está disponible en extensión para Google Chome y complemento para Firefox. El pago de 24,99 dólares ofrece la utilidad de por vida.

6 maneras de reducir la sobrecarga de información

10/05/2019
Artículo original

Imagen CC0 de Jonny Lindner

No se debe confundir la sobrecarga cognitiva con la sobrecarga de trabajo. La sobrecarga de trabajo es simplemente tener muchas tareas por hacer y carecer del tiempo suficiente para completarlas y, la sobrecarga cognitiva se refiere a tener demasiada información para procesar a la vez.

Si bien la tecnología debería facilitar nuestras vidas, el exceso de información puede tener un impacto negativo en nuestra salud mental, pues acaba por abrumarnos.

En mayo de 2018 Forbes publicó un artículo sobre la cantidad de datos que se crean cada día. En dicho artículo afirman que al ritmo actual se crean 2,5 trillones de bytes cada día (para los despistados, recordar que trillón significa que hay que añadir 18 ceros) y, además, dicho ritmo se está acelerando debido al auge del IoT (internet de las cosas). Por otro lado, es importante destacar que el 90% de los datos del mundo se han generado en solo dos años (2016 y 2017). Si te interesa este tema, puedes leer el artículo de Forbes (en inglés) donde encontrarás un montón de estadísticas que ilustran las formas en que se crean estas ingentes cantidades de datos cada día.

Vamos ya con las formas de reducir el estrés cognitivo:

1- Cierra/ apaga todas las aplicaciones

Sí todas, todas. Cuando necesitas concentrarte en una tarea ¿para qué tienes abiertas aplicaciones que no usas? Lo único que harán es distraerte, incluso las aplicaciones que usamos para mejorar nuestra productividad, como Trello, pues te notificarán los cambios que se hayan producido en los proyectos en los que participes. O GMail/Outlook que te notificará que tienes un nuevo correo.

Lamentablemente, este exceso de información no te resulta útil, al contrario, lo único que consigue es descentrarte, y ralentizar tu tarea si encima decides interrumpirla.

Por lo tanto, cuando quieras centrarte en una tarea cierra todas las aplicaciones que supongan una distracción potencial y por supuesto silencia el teléfono. (Si puedes, ni lo tengas sobre la mesa).

2- Desconecta las notificaciones emergentes

Este punto está muy relacionado con el anterior, sobre todo si no puedes prescindir de ciertas aplicaciones. ¿No te atreves a cerrar el correo durante toda la mañana? Bueno, no hace falta ser tan radical, pero al menos desactiva las ventanas emergentes que te avisan de un nuevo correo y ten disciplina, revisa tu correo solo cada hora, por ejemplo.

Evalúa qué notificaciones te ayudan realmente a hacer tu trabajo y desconecta el resto.

3- Aléjate de las redes sociales

Resulta muy tentador consultar las redes sociales o tu blog favorito mientras trabajas, especialmente cuando estás esperando a que la máquina termine una tarea. Sin embargo, consultar las RRSS o leer un blog, tan solo añade más información a tu cerebro, por lo que ahora en lugar de estar pensando en cuál es el siguiente paso en tu proyecto, en tu cabeza también te está rondando la última frikada que has visto en Twitter, o la última ocurrencia de las lumbreras que nos gobiernan.

Deja las redes sociales para la hora de comer o para después del trabajo. De esta forma, además separarás mejor tu vida personal de tu vida profesional.

4- No hagas varias cosas a la vez

No, no es posible hacer bien varias cosas a la vez, ni siquiera, aunque seas una gran programadora.

Dividir tu atención en cuatro o cinco tareas paralelas es una manera de asegurarse de que esas tareas te lleven más tiempo que si las hicieras de una en una. Lo que es peor aún, resulta muy fácil abandonar algunas tareas por completo a medida que pasas de otras (generalmente tu capacidad de atención se va reduciendo), lo que se traduce en un trabajo incompleto.

Olvídate de ser multitarea.

5- Documenta tu trabajo

Documente tus listas de tareas, procesos operativos y los procedimientos diarios que debe seguir (no reinventes la rueda de cada vez) para que no dependas de la memoria y puedas, no solo hacer tus tareas más rápidamente, sino, mejor aún, más relajadamente.

Cada vez que descubras cómo funciona algo o algo sobre lo que puedas mejorar, actualiza la información electrónica relacionada. De esta forma, no necesitas bucear en antiguos emails, blocs de notas, o preguntar a compañeros detalles que faltan en lo que estás haciendo y deberías saber.

Redacta procedimientos, haz check-lists y por supuesto, úsalos.

6- Toma notas mientras trabajas

Aunque te pueda parecer el mismo punto que el anterior, no es así, de hecho, lo complementa. La documentación a la que hacemos referencia en el punto anterior, te ayuda a tener más productividad. Por otro lado, ahora lo que te aconsejamos es que cuando resuelvas un problema complejo anotes cómo lo has hecho.

De esta forma no necesitarás memorizar los pasos que has seguido y podrás consultaros siempre que te haga falta. Te resultará especialmente útil cuando pasado el tiempo te vuelvas a enfrentar al mismo problema y tengas la obligación de resolverlo en “cero coma”, pues teóricamente sabes hacerlo.

Documentar procesos complejos, aunque no sean comunes, reducirá tu estrés cognitivo.

Aun hay algunos trucos más que te pueden ayudar a reducir tu sobrecarga cognitiva, como por ejemplo reducir al mínimo el número de reuniones a las que asistes: el 80% de lo que se comenta en las reuniones no es información relevante para para el 80% de los asistentes.

Y a ti, ¿se te ocurre algún otro? Compártelo en la zona de comentarios.

Cómo adaptarse a la RGPD con ASP.NET Core

07/05/2019
Artículo original

imagen ornamental - RGPD

Con la llegada de la RGPD (o GDPR, General Data Protection Regulation) y sus efectos sobre todas las empresas respecto a la privacidad, nos vimos obligados a introducir modificaciones en nuestras aplicaciones web con objeto de soportar los nuevos requisitos de seguridad y privacidad impuestos por las autoridades europeas.

La entrada en vigor, el 25 de mayo de 2018, prácticamente coincidió con el lanzamiento de ASP.NET Core 2.1, que se subió al hype y aprovechó para introducir algunas novedades que, de alguna forma, nos ayudaban a implementar algunos de los requisitos exigidos por esta nueva normativa:

  • Facilitar la inclusión del típico banner de aceptación de uso de cookies durante la navegación por el sitio web y trackear su consentimiento.
  • Facilitar la inclusión de una página de información sobre la privacidad del sitio.
  • Evitar el envío de cookies no imprescindibles al usuario si las condiciones no han sido aceptadas.
  • Permitir la distinción de cookies fundamentales para el uso del sistema de otras que son prescindibles.
  • En caso de usar Identity Framework, permitir la descarga y eliminación de datos del usuario.

Algunas de estas funcionalidades, que exploraremos en mayor detalle a lo largo de este artículo, se implementan en forma de componentes incluidos en el framework ASP.NET Core, mientras que otras son simples adiciones a la plantilla de proyectos MVC y Razor Pages.

Nota: este artículo asume que tienes al menos conocimientos básicos de trabajo con ASP.NET Core MVC.

Configuración de funcionalidades

Desde ASP.NET Core 2.1, los nuevos proyectos MVC y Razor Pages incluyen en la clase Startup código específico para añadir a las aplicaciones funcionalidades relativas a la aceptación de cookies, tanto en la configuración de servicios como en la definición del pipeline:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<CookiePolicyOptions>(options =>
        {
            options.CheckConsentNeeded = context => true;
            options.MinimumSameSitePolicy = SameSiteMode.None;
        });
        ...
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        ...
        app.UseCookiePolicy();
        ...
    }
}

El objeto CookiePolicyOptions permite personalizar algunos aspectos de estas funcionalidades, como la configuración de la cookie que será utilizada para recordar la aceptación del usuario o la lambda CheckConsentNeeded, donde podemos introducir lógica que decida si debemos exigir el consentimiento del usuario en la petición actual.

Por ejemplo, con el siguiente código indicaríamos al framework que las cookies de consentimiento serán sólo obligatorias cuando el usuario navegue por rutas comenzando por "/home":

options.CheckConsentNeeded = context =>
{
    // Introducir lógica personalizada aquí...
    return context.Request.Path.StartsWithSegments("/home");
};

Inclusión del banner de aceptación de cookies

De nuevo encontramos cambios en la plantilla de proyectos MVC y Razor de ASP.NET Core, en este caso para mostrar el banner de aceptación de cookies y procesar la aceptación por parte del usuario.

Para ello, se incluye de serie la vista parcial /Shared/_CookieConsentPartial.cshtml, que se añade a todas las vistas desde el Layout de la aplicación. En esta vista parcial se maqueta el banner de aviso de uso de cookies, y se introduce un pequeño script para que el browser añada una cookie para indicar que el usuario aceptó las condiciones de uso:

Banner de aceptación de cookies

El código fuente de la misma es el siguiente:

@using Microsoft.AspNetCore.Http.Features

@{
    var consentFeature = Context.Features.Get<ITrackingConsentFeature>();
    var showBanner = !consentFeature?.CanTrack ?? false;
    var cookieString = consentFeature?.CreateConsentCookie();
}

@if (showBanner)
{
    <div id="cookieConsent" class="alert alert-info alert-dismissible fade show">
        Use this space to summarize your privacy and cookie use policy.
        <a asp-area="" asp-controller="Home" asp-action="Privacy">Learn More</a>.
        <button type="button" class="accept-policy close"
                data-dismiss="alert" aria-label="Close" data-cookie-string="@cookieString">
            <span aria-hidden="true">Accept</span>
        </button>
    </div>
    <script>
        (function () {
            var button = document.querySelector("#cookieConsent button[data-cookie-string]");
            button.addEventListener("click", function (event) {
                document.cookie = button.dataset.cookieString;
            }, false);
        })();
    </script>
}

Lo único "raro" de este código es que desde el lado servidor se usa el contexto de la vista para obtener la instancia de la clase que utiliza ASP.NET Core para el seguimiento de la aceptación de las condiciones, ITrackingConsentFeature.

Como puedes observar, se utiliza luego la propiedad CanTrack para determinar si el banner debe ser mostrado o no. Esta propiedad estará establecida a true si el consentimiento no es requerido (es decir, si la lambda CheckConsentNeeded de la configuración retorna falso) o si existiera la cookie que indica que el usuario aceptó las condiciones de uso.

Por otra parte, se utiliza el método CreateConsentCookie() para obtener el contenido de la cookie que el browser añadirá a la sesión de navegación cuando el usuario dé su consentimiento pulsando el botón incluido en el banner.

Usando la configuración por defecto, un ejemplo de cookie que podría generarse sería el siguiente:

.AspNet.Consent=yes; expires=Sun, 05 Apr 2020 11:39:01 GMT; path=/; secure; samesite=lax

Las propiedades de la cookie, como su nombre o duración, se pueden personalizar desde el bloque de código que hemos visto anteriormente en la configuración de servicios.

Inclusión de página de información sobre la privacidad

Las plantillas de proyecto de sitios web basados en ASP.NET Core también incluyen de serie una página o vista específica para mostrar información sobre el tratamiento de la privacidad en el sitio web, accesible desde el menú principal.

Obviamente no incluye ningún tipo de contenido útil más allá de un texto tipo "comodín", por lo que, salvo actuar como recordatorio de que debemos construirla, tampoco sirve para mucho más. Es localizarla y escribir lo que corresponda.

Gestión de cookies no esenciales

Las funcionalidades que hemos descrito hasta el momento están enfocadas a mostrar información sobre la privacidad del sitio y a registrar el codiciado consentimiento explícito del usuario a la utilización de cookies en nuestro sitio web.

Sin embargo, ¿cómo afecta esto de forma interna?

Pues bien, aquí es donde encontramos otras de las novedades interesantes incluidas en ASP.NET Core: el framework no permitirá el envío al cliente de cookies no esenciales mientras no tengamos el consentimiento explícito del usuario*. Siempre, claro está, en las peticiones sobre las que hayamos indicado que es obligatorio dicho consentimiento.

Es decir, si el usuario no ha aceptado la política de privacidad y uso de cookies, un código como el siguiente no enviará la cookie al lado cliente:

public IActionResult Index()
{
    var visitsCookieValue = Request.Cookies["visits"]?.ToString() ?? "0";
    int.TryParse(visitsCookieValue, out int visits);
    visits++;
    Response.Cookies.Append("visits", visits.ToString());
    ...
    return View();
}

Esto es así porque, por defecto, las cookies que añadamos a la respuesta son consideradas como no esenciales para el funcionamiento de nuestra aplicación. El caso anterior sería un buen ejemplo de este tipo de cookies: simplemente la usamos para contar las visitas a la vista, algo que probablemente no sea del todo imprescindible para el correcto funcionamiento del sistema.

Sin embargo, si hacemos lo siguiente, estaremos indicando expresamente que la cookie es imprescindible y debe ser enviada aunque el usuario no lo haya aceptado:

public IActionResult Login(string id, string secret)
{
    var token = _tokenServices.GetToken(appId, secret);
    var cookieOptions = new CookieOptions()
    {
        IsEssential = true
    };
    Response.Cookies.Append("auth-token", token, cookieOptions);
    ...
}

Observa que, a diferencia del caso anterior, en esta ocasión la cookie sí sería esencial para el buen funcionamiento de una aplicación que utilice el token, por ejemplo, para autenticación de usuarios.

Hay que tener cuidado con esto, porque hay características de ASP.NET Core, como el mantenimiento de estado de sesión (Session) o el almacén temporal de datos (TempData), que utilizan cookies que por defecto no están configuradas como fundamentales.

Para modificar esto, podríamos realizar los siguientes cambios en la configuración de sus respectivos servicios:

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookieTempDataProviderOptions>(options => {
        options.Cookie.IsEssential = true;
    });

    services.AddSession(options =>
    {
        options.Cookie.IsEssential = true;
    });
    ...
}

Hay que tener cuidado con esto porque a lo mejor no te está funcionando la sesión y es debido ¡a la configuración relacionada con la RGPD!

Descarga de información y eliminación de datos del usuario

Cuando creamos un proyecto utilizando las plantillas con autenticación local basadas en ASP.NET Core Identity, veremos también que en las páginas de gestión de la cuenta de usuario aparecerán opciones para descargar en formato JSON todos los datos almacenados del usuario, así como para eliminarlos por completo, facilitándonos el cumplimiento de los derechos de acceso:

Página de datos personales

Recapitulando...

Para asegurar el cumplimiento de la RGPD en nuestras aplicaciones, debemos desarrollar teniendo en cuenta bastantes aspectos relativos a la seguridad y privacidad de los usuarios.

En este post hemos visto que ASP.NET Core incluye de serie ayudas interesantes para facilitarnos la adopción de algunas de las medidas impuestas por esta normativa europea. Aunque aún quedará mucho trabajo por hacer, al menos tendremos las bases sobre las que construir aplicaciones más seguras y respetuosas con la privacidad de nuestros usuarios.

Microsoft liberará su compilador Q# y los simuladores cuánticos del Quantum Development Kit en GitHub

06/05/2019
Artículo original

Microsoft liberará su compilador Q# y los simuladores cuánticos del Quantum Development Kit en GitHub

El compilador Q# y los simuladores cuánticos proporcionados en el Quantum Development Kit de Microsoft serán pronto open source, según acaba de anunciar la compañía en Microsoft Build 2019. Los de Redmond quieren, con este movimiento, hacer más fáciles y transparentes para los desarrolladores tanto la computación cuántica como el desarrollo de algoritmos.

La liberación de los elementos del Quantum Development Kit se llevará a cabo en GitHub y, según han señalado, pretenden que proporcione tanto a los miembros de Microsoft Quantum Network y a startups más oportunidades para aprovechar Q# y mejorar sus soluciones cuánticas.

Próximamente el compilador Q# y los simuladores cuánticos del Quantum Development Kit serán liberados

Este nuevo movimiento de Redmond en pro del código abierto también servirá a instituciones académicas que requieren de OSS ya que les proporcionará la capacidad, dicen desde la tecnológica, de aprovechar Q# para su desarrollo cuántico. Estos anuncios se transformarán en hechos en los próximos meses, sin una fecha definida.

Más GitHub en Microsoft

Microsoft y GitHub

Microsoft Build 2019 ha dado para más y otro de los anuncios destacados vuelve a involucrar a GitHub. De acuerdo con lo anunciado por la compañía, los usuarios de GitHub van a poder acceder ahora a las aplicaciones de Microsoft, incluyendo Azure Portal y Azure DevOps, usando su cuenta de usuario de GitHub. No necesitarán más.

A falta de ampliar la información con más detalles, lo que sabemos es que esta actualización del sistema de acceso permitirá a los desarrolladores pasar del repositorio a la implementación solamente usando su cuenta de GitHub. Y según Microsoft, este es solo un primer paso pasa mejorar los servicios de Microsoft para los usuarios de la plataforma.

Pasando del repositorio a la implementación solo con la cuenta de GitHub

En principio, esta nueva forma de acceso tratará de hacer coincidir la cuenta de GitHub de un usuario con otra existente en Microsoft con acceso a Azure. Si no se logra hallar una, se creará una identidad para el usuario que está registrado en su cuenta de GitHub. Desde Microsoft prometen que esto proporcionará "una experiencia de inicio de sesión perfecta".

Por último, en esta Build 2019 se ha anunciado también que GitHub Enterprises ahora soportará sincronizaciones de equipo con Azure Active Directory. Este nueva característica permitirá a clientes empresariales de GitHub sincronizar grupos de usuarios de GitHub con AAD y aumentar la seguridad, señalan desde Redmond, al reforzar una identidad segura en el lugar de trabajo.

Guido van Rossum culpa en parte a las redes sociales por su decisión de abandonar la supervisión de Python

06/05/2019
Artículo original

Guido van Rossum culpa en parte a las redes sociales por su decisión de abandonar la supervisión de Python

Hace casi un año que Guido van Rosuum, creador y ex "Dictador Benevolente de por Vida" de Python, decidiera abandonar la supervisión del desarrollo de Python alegando que estaba cansado del odio y ya no quería volver a pelear nunca más con personas que detestaba sus decisiones.

Más recientemente, van Rossum hablo con la gente del podcast de TFiR sobre los órigenes del lenguaje de programación y las razones por las cuáles decidió dejar las riendas del proyecto que el mismo creó, y las indirectas que algunos desarrolladores le lanzaban en redes sociales fueron un factor importante para que tomara ese decisión.

Guido siente que las redes sociales se nos están saliendo de las manos, pero para él, personalmente, las redes sociales definitivamente le causaron estrés adicional:

No disfruté para nada cuando los desarrolladores centrales andaban enviándome indirectas en Twitter cuestionando mi autoridad y la sabiduría de mis decisiones, en lugar de decírmelo en mi cara y tener un debate honesto sobre las cosas

El programador había supervisado el desarrollo de Python por casi 30 años, y en todo ese tiempo, como explica el mismo, había sido el que tomaba las decisiones finales, el árbitro. A estas alturas de su vida quiere pasar menos tiempo sintiéndose estresado por lo que es la comunidad y sin tener que sentirse afectado por todo lo que pasaba alrededor de Python.

Todavía no han decidido del todo cómo será gobernado Python

Python

A finales de 2018 la comunidad de desarrolladores que quedaron encargados de Python empezó a plantearse un nuevo modelo de gobernabilidad para Python, uno "diseñado para ser aburrido, y que al menos inicialmente, tendría un comité de cinco personas con la autoridad para hacer lo que antes era solo responsabilidad de Guido.

En su entrevista durante el podcast van Rossum enfatizó que el todavía es uno de los desarrolladores centrales de Python y explicó que aún no han decidido exactamente el tipo de modelo de gobernabilidad que usarán. Dice que tienen unas cinco o seis propuestas sobre la mesa, y pronto habrán dos votaciones para decidir por uno de ellos y luego para elegir a las personas que formarán el liderazgo.

Básicamente: van a votar para elegir una "constitución" y luego, usando las reglas establecidas en esa constitución pasarán a votar por los líderes. Python es uno de los lenguajes de programación más populares, importantes y versátiles de la actualidad, y la dirección del proyecto es sin duda relevante incluso más allá de la comunidad de desarrollo.

Página Siguiente