El creador de Python se "aburre" de estar jubilado y se incorpora a Microsoft como desarrollador

13/11/2020
Artículo original

El creador de Python se

Guido van Rossum, creador del popular lenguaje de programación Python, se ha unido a la división de desarrolladores de Microsoft… un año después de haberse jubilado. "Decidí que la jubilación era demasiado aburrida".

"¿Qué haré ahora? ¡Demasiadas opciones como para decirlo! Pero lo haré usando Python, eso sin duda. Y no sólo en Windows... hay un montón de código abierto aquí [en Microsoft]".

Una trayectoria que se niega a seguir creciendo

Van Rossum creó Python en 1991 y estuvo guiando su evolución durante nada menos que tres décadas, reclamando para sí con humor el título de "Dictador benevolente vitalicio" de la Python Software Foundation.

Tras lograr situar a Python como uno de los lenguajes informáticos más populares del momento, a mediados de 2018 anunció que se tomaría unas "vacaciones permanentes" y que dejaría el proyecto en manos de su comunidad de desarrolladores.

Pero todo eso lo hacía en su tiempo libre: como profesional llevaba trabajando desde 2013 (tras su salida de Google) para Dropbox, una plataforma cuyas primeras líneas de código se habían escrito en Python.

Entonces, en octubre de 2019, cuando contaba ya con 63 años y medio, decidió que había llegado el momento de su "retiro oficial". Pero el aburrimiento ha logrado sacarle de ella... y el giro de 180º de Microsoft con respecto al software libre parece haber resultado ser clave para que Van Rossum encuentre allí su sitio.

Un portavoz de Microsoft ha declaro a TechCrunch que la compañía no tiene ningún detalle adicional para compartir al margen de confirmar la noticia:

"Estamos emocionados por tenerlo como parte de la División de Desarrolladores. Microsoft se ha comprometido a colaborar y hacer crecer a la comunidad de Python, y la incorporación de Guido es un reflejo de ese compromiso".

I decided that retirement was boring and have joined the Developer Division at Microsoft. To do what? Too many options to say! But it’ll make using Python better for sure (and not just on Windows :-). There’s lots of open source here. Watch this space.

— Guido van Rossum (@gvanrossum) November 12, 2020

Vía | TechCrunch

Imagen | Guido van Rossum

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Fundamentos de testing: preguntas y respuestas

13/11/2020
Artículo original

Imagen ornamental, un circuito electrónico simple con cables y un medidor, de Nicolas Thomas, CC0 en Unsplash 

Nota: este artículo es una traducción de "Software Testing Fundamentals - Questions and Answers" de Amir Ghahrai, con su permiso expreso. Amir es el fundador de DevQA.io un sitio especializado en ayudar a otros desarrolladores a convertirse en testers técnicos.

Las pruebas de software constituyen una actividad más dentro del proceso de desarrollo de software. Se trata de averiguar si el software ofrece la calidad esperada a las partes interesadas.

¿Qué son las pruebas de software o testing de software?

Diferentes personas han dado diferentes definiciones acerca del testing, pero, en general, su objetivo es:

  • Asegurar que el software cumpla con los requisitos y el diseño acordados.
  • Que la aplicación funcione como se esperaba.
  • Que la aplicación no contenga graves errores.
  • Que cumpla con el uso previsto según las expectativas del usuario.

Las pruebas de software se utilizan a menudo junto con los términos verificación y validación.

  • Validación: ¿estamos haciendo el trabajo correcto?
  • Verificación: ¿estamos haciendo bien el trabajo?

La verificación es la comprobación o test de elementos, incluido el software, para constatar su conformidad y coherencia con una especificación asociada.

La validación es el proceso de comprobar que lo que se ha especificado es lo que realmente quería el usuario.

Las pruebas de software son solo un tipo de verificación, que también utiliza técnicas como revisiones, análisis, inspecciones y recorridos.

¿Qué son las pruebas exploratorias y cuándo deben realizarse?

Una prueba exploratoria consiste en hacer simultáneamente un test de diseño y ejecución de una aplicación. Esto significa que el evaluador (tester) usa su conocimiento y experiencia en pruebas para predecir dónde y bajo qué condiciones el sistema podría comportarse inesperadamente. A medida que el evaluador comienza a explorar el sistema, se le ocurren sobre la marcha nuevas ideas de diseño de prueba y se ejecutan en el software que se está probando.

En una sesión de prueba exploratoria, el evaluador ejecuta una cadena de acciones contra el sistema, cada acción depende del resultado de la acción anterior, por lo tanto, el fruto del resultado de las acciones podría influir en lo que hace el evaluador a continuación, es decir, no hay dos sesiones de prueba idénticas.

Esto contrasta con Scripted Testing, donde las pruebas se diseñan de antemano utilizando los requisitos o los documentos de diseño, generalmente antes de que el sistema esté listo y se ejecutan esos mismos pasos exactos contra el sistema más tarde.

Las pruebas exploratorias generalmente se realizan a medida que el producto evoluciona (ágil) o como una verificación final antes de que se lance el software. Es una actividad complementaria a las pruebas de regresión automatizadas.

¿Qué técnicas de testing existen y cuál es su propósito?

Las técnicas de testing se utilizan principalmente con dos propósitos: para ayudarnos a identificar defectos y para reducir el número de casos a verificar.

  • La partición de equivalencia se utiliza principalmente para reducir el número de casos a verificar identificando diferentes conjuntos de datos que no son iguales y ejecutando solo un test de cada conjunto de datos.
  • El análisis de valor límite se utiliza para verificar el comportamiento del sistema en los límites de los datos permitidos.
  • Las pruebas de transición de estado se utilizan para validar estados permitidos y no permitidos y transiciones de un estado a otro mediante varios datos de entrada.
  • La prueba por pares o todos los pares es una técnica de testing muy poderosa y se utiliza principalmente para reducir el número de casos a verificar mientras aumenta la cobertura de combinaciones de funciones.

¿Por qué es necesario hacer test de software?

Las pruebas son necesarias para identificar cualquier defecto presente en el software que pueda causar algún perjuicio a los usuarios. Sin las pruebas adecuadas, podríamos lanzar un software que podría funcionar mal y causar problemas graves.

Algunos ejemplos son:

  • Software en una máquina de soporte vital que puede causar daños graves a un paciente.
  • El software en una planta nuclear que monitorea la actividad nuclear puede causar daños al medio ambiente.
  • La aplicación bancaria o financiera que calcula los tipos de cambio puede causar pérdidas financieras a una empresa.

Imagen ornamental de una oruga (bug) por Yoal Desurmont en Unsplash, CC0

¿Cuál es la diferencia entre bug, defecto (defect), error (error), falla (failure), fallo (fault), y equivocación (mistake)?

Error y equivocación es lo mismo. Bug, defecto y fallo, también es lo mismo.

En general, una persona comete una equivocación (error) que produce un defecto (bug, fallo) en una aplicación que puede causar una falla (avería).

Los defectos ocurren porque los seres humanos son propensos a equivocarse, además, una aplicación puede ser muy compleja, por lo que la integración de diferentes componentes puede provocar comportamientos extraños.

¿Cuántas pruebas son suficientes?

No hay una respuesta definitiva a esta pregunta. Las pruebas no son absolutas y no tienen límites. Sin embargo, podemos usar métricas de riesgo (test basados en riesgos) para identificar los escenarios probables que pueden causar el mayor daño o las partes del software que se utilizan principalmente, para así concentrar nuestro tiempo y esfuerzo en las partes que son más importantes.

Los test deben proporcionar suficiente información sobre el estado o la salud de una aplicación, para que las partes interesadas puedan tomar una decisión informada sobre si lanzar el software o dedicar más tiempo a las pruebas.

¿Qué es el proceso de prueba fundamental?

Para aprovechar al máximo los test, se debe seguir un proceso definido. Pero antes de que comience cualquier test, se debe emplear gran parte del esfuerzo en crear un buen plan de testing. Un buen plan de testing es de gran ayuda para garantizar que las pruebas se alineen con lo que se pretende lograr.

Esto quizás sea más aplicable a un entorno de pruebas bastante formal (como una misión crítica). La mayoría de las organizaciones comerciales tienen procesos de prueba menos rigurosos. Sin embargo, cualquier esfuerzo de prueba puede utilizar estos pasos de alguna forma.

El proceso de prueba fundamental consta de 5 actividades:

  • Planificación
  • Especificación
  • Ejecución
  • Grabación
  • Comprobación de la finalización del test

El proceso de prueba siempre comienza con la planificación de la prueba y termina con la verificación de la finalización de la prueba.

Todas y cada una de las actividades pueden repetirse (o al menos volver a visitarse) ya que pueden ser necesarias varias iteraciones antes de que se cumplan los criterios de finalización definidos durante la actividad de planificación de pruebas.

Siete principios de testing

A continuación se muestran los siete principios de testing:

1. Los test muestran la presencia de errores

Probar una aplicación solo puede revelar que existen uno o más defectos en la aplicación, sin embargo, el test por sí solo no puede probar que la aplicación esté libre de errores. Por lo tanto, es importante diseñar casos de prueba que encuentren tantos defectos como sea posible.

2. Es imposible hacer test exhaustivos

A menos que la aplicación bajo prueba (AUT – application under test) tenga una estructura lógica muy simple y una entrada limitada, no es posible probar todas las combinaciones posibles de datos y escenarios. Por esta razón, el riesgo y las prioridades se utilizan para concentrarse en los aspectos más importantes a probar.

3. Pruebas tempranas

Cuanto antes comencemos con los test, mejor aprovecharemos el tiempo disponible. Tan pronto como estén disponibles los productos iniciales, tales como los requisitos o los documentos de diseño, podemos comenzar a hacer test. Es común que la fase de prueba se reduzca al final del ciclo de vida del desarrollo, es decir, cuando el desarrollo ha finalizado, por lo que al comenzar las pruebas temprano, podemos preparar las pruebas para cada nivel del ciclo de vida del desarrollo.

Otro punto importante sobre las pruebas tempranas es que, cuando los defectos se encuentran al principio del ciclo de vida, son mucho más fáciles y económicos de corregir. ¡Es mucho más económico cambiar un requisito incorrecto que tener que cambiar una funcionalidad en un sistema grande que no funciona según lo solicitado o diseñado!

4. Agrupación de defectos

Durante las pruebas, se puede observar que la mayoría de los defectos detectados están relacionados con una pequeña cantidad de módulos dentro de un sistema. Es decir, un pequeño número de módulos contiene la mayoría de los defectos del sistema. O sea, podemos aplicar el principio de Pareto a las pruebas de software: aproximadamente el 80% de los problemas se encuentran en el 20% de los módulos.

5. La paradoja de los pesticidas

Si sigues ejecutando el mismo conjunto de pruebas una y otra vez, es probable que en esos test no descubran defectos nuevos. Esto es debido a que a medida que el sistema evoluciona, muchos de los defectos detectados anteriormente se habrán solucionado y los antiguos casos de prueba ya no aplican.

Cada vez que se soluciona un defecto o se agrega una nueva funcionalidad, necesitamos hacer pruebas de regresión para asegurarnos de que el nuevo software modificado no haya roto ninguna otra parte del mismo. Sin embargo, esos casos de prueba de regresión también deben modificarse para reflejar los cambios realizados en el software para que sean aplicables y, con suerte, detectar nuevos defectos.

6. Los test dependen del entorno

Las diferentes metodologías, técnicas y tipos de pruebas están relacionadas con el tipo y la naturaleza de la aplicación. Por ejemplo, una aplicación para un dispositivo médico necesita más pruebas que un software de juegos.

Y lo que es más importante aún, un software de dispositivo médico requiere pruebas basadas en riesgos, cumplir con las regulaciones de la industria médica y posiblemente técnicas de diseño de pruebas específicas.

Del mismo modo, un sitio web muy popular debe pasar por rigurosas pruebas de rendimiento, así como pruebas de funcionalidad para asegurarse de que el rendimiento no se vea afectado por la carga en los servidores.

7. Ausencia de errores: ¡falacia!

Solo porque las pruebas no hayan encontrado ningún defecto en el software, no significa que el software esté listo para entrar en producción. ¿Fueron las pruebas que ejecutamos diseñadas realmente para detectar la mayoría de los defectos? ¿O para ver si el software se ajustaba a los requisitos del usuario? Hay muchos otros factores a considerar antes de tomar la decisión de enviar el software.

Imagen ornamental, caja de color blanco, por Daniele Levis Pelusi, CC0 en Unsplash

¿Qué es el test de la caja blanca?

Las pruebas de caja blanca tratan con la lógica interna y la estructura del código. Las pruebas de caja blanca también se denominan pruebas de cristal, estructurales, de caja abierta o de caja transparente. Los test escritos en base a la estrategia de prueba de caja blanca incorporan medidas como la cobertura del código escrito, de las ramas, las rutas, las declaraciones, la lógica interna del código, etc.

Para implementar las pruebas de caja blanca, el evaluador debe lidiar con el código y, por lo tanto, debe poseer conocimientos de codificación y lógica, es decir, el funcionamiento interno del código. La prueba de caja blanca también necesita que el evaluador busque en el código y descubra qué unidad/declaración/parte del código no funciona correctamente.

Test unitarios

El desarrollador lleva a cabo pruebas unitarias para comprobar si el módulo o la unidad de código en particular está funcionando bien. Los test unitarios se producen a un nivel muy básico, ya que se lleva a cabo a medida que se desarrolla la unidad del código o se construye una funcionalidad en particular.

Análisis estático y dinámico

El análisis estático implica revisar el código para descubrir cualquier posible defecto en el mismo. El análisis dinámico supone ejecutar el código y analizar la salida.

Cobertura de instrucciones

En este tipo de prueba, el código se ejecuta de tal manera que cada instrucción en la aplicación se ejecuta al menos una vez. Ayuda a asegurar que todas las declaraciones se ejecuten sin ningún efecto secundario.

Cobertura de ramas

Ninguna aplicación es posible escribirla de un tirón, en algún momento necesitamos abrir una rama de código para realizar una funcionalidad particular. Las pruebas de cobertura de ramas ayudan a validar todas las ramas en el código y asegurarse de que ninguna ramificación dé lugar a un comportamiento anormal de la aplicación.

Pruebas de seguridad

Las pruebas de seguridad se llevan a cabo con el fin de averiguar cómo de bien el sistema puede protegerse frente a accesos no autorizados, piratería, cualquier daño en el código, etc.. Este tipo de test requiere de técnicas sofisticadas.

Pruebas de cambio

Un tipo de test en el que se prueba la aplicación en busca del código que se modificó después de corregir un error o defecto en particular. También ayuda a descubrir qué código y qué estrategia de codificación pueden ayudar a desarrollar la funcionalidad de manera efectiva.

Ventajas de los test de caja blanca

Como el conocimiento de la estructura de código interna es un requisito previo, resulta muy fácil descubrir qué tipo de entrada / datos pueden ayudar a probar la aplicación de manera eficaz. La otra ventaja de las pruebas de caja blanca es que ayuda a optimizar el código. Ayuda a eliminar las líneas adicionales de código, que pueden provocar defectos ocultos.

Desventajas de los test de caja blanca

Como el conocimiento del código y la estructura interna es un requisito previo, se necesita un evaluador capacitado para llevar a cabo este tipo de pruebas, lo que aumenta el coste. Y es casi imposible examinar cada fragmento de código para descubrir errores ocultos, que pueden crear problemas y provocar fallas en la aplicación.

Imagen ornamental, una caja de color negro intenso sobre fondo negro, por an_vision, CC0 en Unsplash

¿Qué es el test de la caja negra?

En las pruebas de la caja negra, el evaluador prueba una aplicación sin conocer el funcionamiento interno de la misma.

Debido a que las pruebas de caja negra no se relacionan con el código subyacente, las técnicas pueden derivarse de los documentos de requisitos o especificaciones de diseño y, por lo tanto, pueden comenzar tan pronto como se escriban los requisitos.

Técnica de prueba de análisis de valor límite

El análisis de valor límite (BVA – boundary value analysis), prueba el comportamiento de un programa en los límites. Al verificar un rango de valores, después de seleccionar el conjunto de datos que se encuentran en las particiones válidas, lo siguiente es verificar cómo se comporta el programa en los valores límite de las particiones válidas. El análisis de valor límite es más común cuando se verifica un rango de números.

Técnica de transición de estado

La técnica de prueba de transición de estado se utiliza cuando algún aspecto del sistema puede describirse en lo que se denomina una “máquina de estados finitos”. Esto simplemente significa que el sistema puede estar en un número (finito) de estados diferentes, y las transiciones de un estado a otro están determinadas por las reglas de la “máquina”.

En este modelo se basan el sistema y los test. Cualquier sistema en el que obtenga una salida diferente para la misma entrada, dependiendo de lo que haya sucedido antes, es un sistema de estado finito.

Técnica de prueba de partición de equivalencia

La idea detrás de la técnica de prueba de partición de equivalencia es eliminar el conjunto de datos de entrada que hacen que el sistema se comporte de la misma manera y produzca el mismo resultado al probar un programa.

El proceso de la técnica de partición de equivalencia implica identificar el conjunto de datos como una condición de entrada que dan el mismo resultado al ejecutar un programa y clasificarlos como un conjunto de datos equivalentes (porque hacen que el programa se comporte de la misma manera y genere la misma salida) y particionándolos de otro conjunto equivalente de datos.

Ventajas de los test de caja negra

  • La prueba es imparcial porque el diseñador y el evaluador son independientes entre sí.
  • El evaluador no necesita tener conocimientos de ningún lenguaje de programación específico.
  • El test se realiza desde el punto de vista del usuario, no del diseñador.
  • Los casos de prueba se pueden diseñar tan pronto como se completen las especificaciones.

Desventajas de los test de caja negra

  • La prueba puede ser redundante si el diseñador de software ya ha ejecutado un caso de prueba.
  • Los casos de prueba son difíciles de diseñar.
  • Probar cada flujo de entrada posible no es realista porque llevaría una cantidad de tiempo excesiva; por lo tanto, muchas rutas de programas no se verificarán.

 

30 cursos gratis que puedes comenzar en noviembre para aprender una nueva habilidad este otoño

11/11/2020
Artículo original

30 cursos gratis que puedes comenzar en noviembre para aprender una nueva habilidad este otoño

El mundo de los cursos online gratuitos siempre tiene montones de opciones para cualquiera que esté buscando aprender algo nuevo. Las plataformas más grandes y que ofrecen cursos de universidades e instituciones prestigiosas de todo el mundo constantemente están iniciando nuevos programas.

Si quieres usar este otoño para estudiar sobre temas relacionados con ciencias de la computación, programación y ciencias de datos, en Genbeta hemos recopilado una amplia selección de cursos gratis que comienzan en noviembre o que tienen fechas flexibles para que puedes iniciar desde ya o durante este mes.

Programación

Pakata Goh Ejmtkcz00i0 Unsplash
  • Introducción a la programación en Python I: Aprendiendo a programar con Python: un curso de la Pontificia Universidad Católica de Chile en el que aprenderás a desarrollar tus propios programas en Python y de seguir explorando para construir nuevos programas y cada vez más complejos.

  • Android: Introducción a la Programación: un curso de la Universitat Politècnica de Valencia en el que aprenderás los fundamentos del desarrollo de aplicaciones en Android y podrás realizar sencillas aplicaciones, que incluyan los aspectos más importantes y novedosos de esta plataforma.

  • Introducción al desarrollo de videojuegos con Unity: un curso de la Universitat Politècnica de Valencia en el que aprenderás a a desarrollar videojuegos multiplataforma utilizando una de las herramientas más populares del mercado, el motor de juegos de Unity.

  • Introducción a la Ingeniería del Software: un curso de la Universidad Autónoma de Madrid en el que conocerás las distintas fases de desarrollo por las que pasa un proyecto informático, así como las actividades de gestión necesarias para lograr finalizar el proyecto con éxito.

  • Introducción a la programación orientada a objetos en Java: un curso de la Universidad de los Andes en el que te presentarán un ambiente interactivo orientado para aprender sobre el lenguaje de programación Java en la creación y manipulación de objetos.

  • Diagramas UML estructurales para la Ingeniería del Software: un curso de la Universitat Politècnica de Valencia en el que aprenderás sobre el "Lenguaje de Modelado Unificado" (UML, en inglés "Unified Modeling Language"), un estándar que permite abordar el problema del modelado de software en todos sus niveles desde una perspectiva integral.

  • Aprendiendo Python con circuitos digitales: un curso de Coursera Project Network en el que aprenderás a crear programas en Python para modelar y simular circuitos digitales, y explorarás objetos, sentencias, funciones y clases de Python para procesar valores lógicos y números enteros y binarios.

  • Desarrollo de Aplicaciones Web: Conceptos Básicos: un curso de la Universidad de Nuevo México en el que aprenderás la terminología y los conceptos fundamentales que son necesarios para construir aplicaciones web integradas modernas.

  • Diseñando páginas web con Bootstrap 4: un curso de la Universidad Austral en el que aprenderás conceptos generales de desarrollo web del lado cliente, metodologías de trabajo y herramientas. Aprenderás sobre diseño responsive, grillas, y componentes CSS y Javascript de Bootstrap.

  • Desarrollo de páginas con Angular: un curso de la Universidad Austral en el que aprenderás a utilizar Angular, uno de los frameworks líderes del mercado para desarrollo de aplicaciones de una única página, y también se hará una introducción gradual al lenguaje NodeJS y al desarrollo de APIs.

Ciencias de datos

Annie Spratt Xmpxzzwrj6g Unsplash
  • Aprendizaje automático y ciencia de datos: un curso de la Universitat Politècnica de València en el que aprenderás a valorizar y extraer conocimiento a partir de los datos, usando técnicas y herramientas de análisis de datos genéricas, y aprendizaje automático en particular.

  • Introducción a la Ciencia de Datos con Python: un curso de la Red de Universidades Anáhuac en el que aprenderás los conceptos generales de la ciencia de datos utilizando el lenguaje de programación Python. Serás capaz de recolectar contenido en la web, limpiar los datos y prepararlos para su visualización y gestión.

  • Introducción a Data Science: Programación Estadística con R: un curso de la Universidad Nacional Autónoma de México en el que aprenderás las bases del lenguaje de programación estadística R, la lengua franca de la estadística, el cual te permitirá escribir programas que lean, manipulen y analicen datos cuantitativos.

  • Introducción a los algoritmos de regresión: un curso de Coursera Project Network en el que entenderás y podrás desarrollar tus propios modelos de regresión (lineal y logístico) a partir de un conjunto de datos definidos, y optimizar los algoritmos de forma automática para encontrar los mejores parámetros para tus modelos.

  • Análisis de datos con Python: un curso de IBM en el que aprenderás a analizar datos con Python. Este curso lo llevará desde los conceptos básicos de Python hasta la exploración de muchos tipos diferentes de datos.

  • Mejores prácticas para el procesamiento de datos en Big Data: un curso de Coursera Project Network en el que aprenderás a aplicar buenas prácticas bajo el contexto de procesamiento Big Data, utilizando una de las plataformas más importantes en la actualidad, Databricks.

Ciencias de la computación

Fernando Hernandez Efzwcmrm6j4 Unsplash
  • Razonamiento artificial: un curso de la Universidad Nacional Autónoma de México en el que recibirás una introducción a la lógica y a la teoría de la probabilidad a través de tres modelos gráficos probabilísticos y tres lógicas.

  • Cognición encarnada: un curso de la Universidad Nacional Autónoma de México en el que aprenderás brevemente sobre la historia y conceptos más relevantes de ciencias cognitivas.

  • Launching into Machine Learning en Español: un curso de Google Cloud Training en el que aprenderás por qué las redes neuronales, en la actualidad, ofrecen un alto rendimiento ante una variedad de problemas.

  • Aspectos básicos de la asistencia técnica: un curso de Google en el que aprenderás cómo prepararte para un rol como especialista de soporte de TI de nivel inicial.

  • Arduino y algunas aplicaciones: un curso de la Universidad Nacional Autónoma de México en el que aprenderás qué es Arduino y para qué sirve, y crearás dos prototipos que muestran el funcionamiento de dispositivos, como un chaleco para ciclista y un pastillero.

  • Clasificación de imágenes: ¿Cómo reconocer el contenido de una imagen?: un curso de la Universitat Autònoma de Barcelona en el que aprenderás diferentes métodos de representación y clasificación de imágenes.

  • Resolución de problemas por búsqueda: un curso de la Universidad Nacional Autónoma de México en el que aprenderás, por medio de algoritmo de búsqueda, a abstraer un problema como un grafo de estados-acciones y a dimensionar su complejidad por medio de la identificación de parámetros.

  • Introducción a La Inteligencia Artificial (IA): un curso de IBM en el que aprenderás qué es la Inteligencia Artificial (IA), explorará casos de uso y aplicaciones de IA, comprenderá conceptos y términos de IA como aprendizaje automático, aprendizaje profundo y redes neuronales.

  • Getting Started with Google Kubernetes Engine en Español: un curso de Google Cloud Training en el que aprenderás a crear contenedores de Docker para cargas de trabajo, implementarlos en clústeres de Kubernetes proporcionados por Google Kubernetes Engine y escalar esas cargas de trabajo para hacer frente al aumento de tráfico.

  • Deep Learning: un curso de la Red de Universidades Anáhuac en el que aprenderás qué es una red neuronal, como crear una red neuronal, entrenar una red neuronal con un conjunto de imágenes.

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Ya podemos descargarnos el framework .NET 5.0, disponible por primera vez para Windows ARM64 y WebAssembly

11/11/2020
Artículo original

Ya podemos descargarnos el framework .NET 5.0, disponible por primera vez para Windows ARM64 y WebAssembly

Hace año y medio, Microsoft hizo público que se disponía a lanzar la versión 5.0 de su framework .NET, uno de los componentes básicos en el funcionamiento y desarrollo de numerosas aplicaciones Windows, y uno de los entornos de programación más usados.

En este tiempo ha estado siendo usado en labores de producción por Microsoft (por ejemplo en Bing.com) con el din de depurar su SDK, y desde ayer, por fin, está disponible para todos los usuarios.

Fue durante su evento online .NET Conf 2020 cuando la compañía confirmó la disponibilidad de los binarios de esta plataforma unificada para entornos Windows, macOS y Linux (tanto en arquitecturas x86 y x64 como en Arm32 y Arm64), que permitirán desarrollar software tanto para dichos sistemas como para iOS, Android y (por primera vez) WebAssembly.

Novedades de la nueva versión

La disponibilidad para Windows sobre la arquitectura ARM64 es una de las novedades de la versión 5.0, y tiene mucho que ver con la importancia que Microsoft le concede al lanzamiento de Windows 10X.

Para Microsoft esta versión 5 es un paso de transición entre la 4.x y los planes que tienen para la 6.0, que pasan por ofrecer una experiencia unificada al usuario, en la que éste no tenga que estar descargando componentes individuales sino que pueda elegir en bloque cuáles necesita.

Otras novedades de la nueva versión son la inclusión de la versión 9 C# y la 5 de F#, así como mejoras de rendimiento de las librerías, especialmente en arquitectura ARM y en campos como el uso de expresiones regulares, la serialización Json y las conexiones HTTP, así como la inclusión del soporte para la distribución de software contenido en un único ejecutable.

Aquellos que quieran empezar a programar usando .NET 5.0 deberán asegurarse de tener instalada una versión actualizada de Visual Studio (a partir de la 16.8 en el caso de entornos Windows).

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Python sobrepasa a Java como lenguaje de programación más popular por primera vez en los 20 años del indice TIOBE

06/11/2020
Artículo original

Python sobrepasa a Java como lenguaje de programación más popular por primera vez en los 20 años del indice TIOBE

Por primera vez desde se inició el índice TIOBE hace casi 20 años, Java y C no ocupan las dos primeras posiciones. Así abren el anuncio en la web con los resultados del ranking para el mes de noviembre de 2020.

TIOBE lleva casi dos décadas calculando la popularidad de los lenguajes de programación a partir del número de resultados en diferentes motores de búsqueda para las consultas sobre cada lenguaje. Si bien no es un dato sin sus críticas, puede medir relativamente el grado de interés online sobre los lenguajes en el tiempo.

Python lleva años escalando posiciones y ya está a solo un escalón del líder

Tiobe Noviembre 2020 TIOBE Noviembre 2020

Casi en cualquier tipo de encuesta o índice de medición actual, vas a encontrarte que el trío Java, C, Python suelen estar a la cabeza en popularidad. Y aunque el índice TIOBE es uno que se publica con diferentes variaciones todos los meses del año, es significativo y digno de mencionar que por primera vez en su historia tenga a Python en el segundo lugar.

Si bien en el ranking de noviembre C sigue a la cabeza con 16.21% y aun aumento de 0.17% en comparación con octubre, Python ha escalado a la segunda posición con 12.12% (un cambio del 2.27%), mientras que Java bajó al tercer puesto perdiendo más del 4.5% de popularidad.

En algo como la lista de IEE Spectrum de este año, Python ya está a la cabeza por encima de Java y C. En la última encuesta de JetBrains todos querían aprender Python, y el año pasado Python superó a Java por primera vez en la lista de lenguajes de programación más populares en GitHub.

Python

Si bien muchos desarrolladores citan la versatilidad de Python y las facilidades que ofrece para aprender a manejarlo como sus puntos más fuertes, también se relaciona su creciente popularidad con el surgimiento de campos como el minado de datos, la inteligencia artificial y la computación numérica.

En TIOBE tienen su propia teoría: "Creo que la popularidad de Python tiene que ver con la demanda general. En el pasado, la mayoría de las actividades de programación eran realizadas por ingenieros de software. Pero hoy en día se necesitan conocimientos de programación en todas partes y hay una falta de buenos desarrolladores de software. Como consecuencia, necesitamos algo simple que pueda ser manejado por no ingenieros de software, algo fácil de aprender con ciclos de edición rápidos y un despliegue sin problemas. Python satisface todas estas necesidades."

Probablemente una combinación de todas las anteriores. La realidad es que Python es uno de los lenguajes más demandados, usados y accesibles incluso para que aprendan los principiantes, por lo que muy posiblemente lo sigamos viendo al tipo de las listas de popularidad por muchos años más.

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Las 'stories' ya han llegado incluso a Visual Studio Code: una extensión nos permite mostrar nuestro código al resto de usuarios

05/11/2020
Artículo original

Las 'stories' ya han llegado incluso a Visual Studio Code: una extensión nos permite mostrar nuestro código al resto de usuarios

Seguro que alguna vez, mientras estabas usando Visual Studio Code, te has preguntado "¿Qué estarán codificando otros usuarios al otro lado del mundo?". Bueno, posiblemente no... pero alguien sí lo ha hecho. Y ha decidido proporcionarnos una herramienta para poder saberlo.

El editor de código multiplataforma de Microsoft posee múltiples virtudes que lo han convertido en uno de los programas mejor valorados por los desarrolladores; y entre ellas destaca su amplia y variado catálogo de plugins y extensiones que amplían su funcionalidad y enriquecen su experiencia de uso.

Pero una de las últimas adiciones al Visual Studio Marketplace está cosechando una notable popularidad: se trata de 'Stories for Visual Studio Code', una extensión que trata de sumar Visual Studio a la fiebre por las 'stories' desatada por Snapchat y a la que ya se han sumado plataformas como Linkedin.

Aunque, claro está, su autor ha buscado dar una vuelta de tuerca al concepto de 'story' apropiado al contexto: se trata de poder exhibir ante los demás usuarios nuestros fragmentos de código.

Así podemos usarlo

Una vez hayamos instalado la extensión desde la Marketplace, aparecerá un nuevo icono en la barra de herramientas del editor, una 'S' dentro de un círculo, que al ser clicado hará aparecer una sidebar llena de los avatares de los últimos usuarios que hayan hecho uso de la extensión (y no escasean: ya se la han instalado más de 20.000).

Vsc1 Instalando la extensión.

Haciendo clic en cualquiera de ellos, podremos visualizar un fragmento de código, que -dependiendo cómo haya sido grabado por su autor- en algunos casos incluso mostrará el texto siendo escrito en tiempo real.

Sin embargo, no estaremos ante un vídeo o archivo GIF: una vez termina de 'reproducirse' la story, podemos manipular el código que contiene como si de un archivo local se tratase, y así reusarlo para alguno de nuestros proyectos.

Screenshot 4

De hecho, el editor incluso nos mostrará avisos en el caso de que necesitemos configurar algún aspecto de la aplicación o instalar alguna extensión extra para que el código pueda compilar en nuestro equipo.

Screenshot 5

Por otro lado, si queremos publicar nuestra propia 'story', sólo tendremos que hacer clic en "Record Story (beta)", a la derecha de la barra de herramientas inferior de la interfaz: la extensión nos avisará de que necesitamos loguearnos previamente en GitHub para ello (de hecho, los avatares que se muestran en las stories serán los que estemos usando en dicha paltaforma).

En definitiva, un experimento curioso que ha sido bastante bien recibido, y que hace que nos preguntemos si en algún momento podremos elegir a qué usuarios de Visual Studio Code seguimos, para no perdernos entre el maremágnum de usuarios de la extensión.

Algunos usuarios van incluso un paso más allá, y proponen que el siguiente paso sea una plataforma de citas para desarrolladores. Todo se andará.

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Cómo solucionar la pantalla negra al grabar o hacer streaming con OBS Studio

02/11/2020
Artículo original

OBS Studio es el software más popular para hacer streaming de vídeo a sitios como YouTube, Twitch, Facebook, etc. Permite también grabar tan solo, por lo que mucha gente lo usa también para hacer grabaciones de pantalla (screencasts). Ofrece multitud de fuentes para añadir a la imagen final y enriquecer la grabación (puedes usar fondos, webcams, imágenes, textos, páginas web....) y también filtros de audio y vídeo, transformaciones, animaciones...

Pero a veces te puede dar algún problema, aunque no tiene por qué ser problemas suyo realmente. Como en este caso...

Si vas a OBS Studio y añades como fuente para tu streaming o grabación una de tus pantallas:

Añadir la captura de una pantalla a tu escena de OBS

puede que te aparezca totalmente en negro. Es decir, no se ve en OBS nada de lo que aparece en pantalla, que es el objetivo.

En concreto esto es habitual si tu equipo tiene más de una tarjeta gráfica y lo que quieres mostrar en OBS hace uso de la GPU de la tarjeta "potente" que tengas (por ejemplo, en el caso de un juego).

Por ejemplo, mi portátil, aparte de la tarjeta gráfica Intel integrada dispone también de una tarjeta NVIDIA MX330 para gráficos, que si bien no es una maravilla, me sobra para lo que yo la utilizo. Pero debido a esto, OBS presenta este problema.

El problema se produce porque OBS está "leyendo" la información de pantalla de una de las tarjetas, pero la que estás usando tú es la otra.

Así que tenemos dos posibles maneras de arreglarlo.

Primera opción: cambiar los ajustes en el panel de control de NVIDIA

Si lo que quieres grabar o mostrar por streaming es un juego o un programa que haga uso intensivo de la GPU, pero OBS no es capaz de mostrarlo, lo más seguro es que esté obteniendo la información desde la otra tarjeta, la tarjeta gráfica integrada.

En el caso de NVIDIA, disponemos de un panel de control específico que, entre otras cosas, nos permite controlar qué tarjeta queremos que utilice cada uno de los programas instalados.

Para abrir el panel de control vete al área de notificación de Windows (los iconitos pequeños al lado del reloj) y busca el icono de NVIDIA. Pulsando sobre él con el botón derecho verás la opción del panel de control:

Acceder al panel de control de NVIDIA

Dentro del panel vete a la opción Manage 3D settings y ahí a la pestaña Program Settings. En la lista desplegable debería aparecerte ya OBS Studio, ya que lo has instalado. Si no fuese así dale al botón Add y busca el ejecutable de OBS en C:\Archivos de programa.

En el segundo desplegable elige qué tarjeta quieres utilizar con OBS Studio. En este caso, al ser un programa que hace uso de la GPU deberías elegir High Performance NVIDIA Processor,  en lugar de la opción por defecto que es que el sistema elija por su cuenta. Luego aplicas y reinicias OBS:

Ajustes en el panel de control de NVIDIA

De este modo el juego o programa que usa la GPU debería verse en OBS.

Si no es así... prueba con la segunda opción que te cuento a continuación...

Segunda opción: cambiar los ajustes gráficos

Si lo anterior no te arregla el problema (¡no te olvides de cerrar y volver a ejecutar OBS!) puedes intentar lo siguiente.

Abre la configuración del sistema pulsando WINDOWS+I y vete al apartado Sistema y dentro de él a Pantalla (en mi equipo lo tengo en inglés, de ahí las capturas). Haz scroll hasta que te encuentres en la parte inferior tres enlaces con las opciones avanzadas, y pulsa en Ajustes gráficos:

Configuración de pantalla en Windows 10

Dentro de la nueva pantalla que se abre hay un único apartado que te permite establecer las preferencias de rendimiento de gráficos de cualquier programa que te interese. en la lista desplegable elige Aplicación de escritorio y con el botón de buscar localiza el .exe de OBS (generalmente en "C:\Program Files\obs-studio\bin\64bit\obs64.exe").

Al añadirlo se te mostrará un botón de Opciones. En las opciones te dará a elegir entre que decida Windows qué tarjeta utilizar, y luego entre las tarjetas gráficas que tengas. O sea, algo muy parecido a lo que teníamos en el panel de control de NVIDIA:

Configuración para OBS en el rendimiento gráfico

Aunque lo pone en términos del consumo de energía (la GPU de la tarjeta gráfica consumirá más que el tarjeta integrada simple que tiene mi equipo), en realidad sirve para decir qué tarjeta va a utilizar OBS para renderizar las escenas. en mi caso yo quería grabar la pantalla en programas "normales" que no tiran de GPU, así que elijo la tarjeta integrada.

Reinicias OBS y ¡tachán!: problema resuelto:

OBS mostrando la pantalla actual (con el típico efecto de espejo infinito que provoca al grabarse a sí  mismo)

¡Espero que te resulte útil!

Google apuesta por el movimiento No Code con AppSheet, una plataforma para crear apps sin escribir ni una línea de código

22/10/2020
Artículo original

Google apuesta por el movimiento No Code con AppSheet, una plataforma para crear apps sin escribir ni una línea de código

Actualmente no es nada raro escuchar hablar de diferentes plataformas para crear aplicaciones sin saber programar, opciones para principiantes que funcionan simplemente con arrastrar y soltar elementos.

Es lo que se ha llamado la "nueva era del No Code" y ahora es Google la que está también apostando por ello. La empresa acaba de anunciar AppSheet, su nueva plataforma de desarrollo no-code que forma parte de Google Cloud.

Una nueva opción dentro de Google Workspace

AppSheet estará directamente integrada con Google Workspace, el nuevo espacio de trabajo que sustituye a G Suite e integra Gmail, Calendar, Meet, y pronto Google Chat. AppSheet está diseñada para dejar que "cualquiera pueda crear una app poderosa sin tener que escribir ni una sola línea de código".

AppSheet dejará crear una aplicación directamente desde Google Sheets (las hojas de cálculo de Google). Básicamente, al abrir una hoja de cálculo verás una opción dentro de las herramientas que permite "abrir en AppSheet", si creas una cuenta, AppSheet se encargará de analizar la estructura de datos de la hoja de cálculo para programar un prototipo de app por ti.

Google dice que son muchas las posibilidades que se abren con esta plataforma, puesto que AppSheet también se integra con otras herramientas como Calendar, Maps, Drive y más. Puedes probarla de forma gratuita desde ya con Google Workspace y empezar con las plantillas gratis que se ofrecen.

También puedes navegar por la galería de aplicaciones demo de AppSheet para echar un vistazo a las posibilidades que ofrece la plataforma, tienes la opción de personalizar esas muestras.

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Lecciones aprendidas tras migrar más de 25 proyectos a .NET Core

21/10/2020
Artículo original

Este artículo es una traducción de "Lessons learned after migrating 25+ projects to .NET Core" de Thomas Ardal, CEO de elmah.io, con su permiso expreso. elmah.io es el principal servicio del mercado para monitorización y logging de aplicaciones .NET.

Hace poco terminamos una de las mayores tareas de refactorización que hemos hecho en elmah.io: migrar todo a .NET Core. elmah.io consta actualmente de 5 aplicaciones web y 57 funciones de Azure repartidas en aproximadamente 25 Function Apps. En este post, compartiré algunas de las lecciones que hemos aprendido mientras llevábamos a cabo esta tarea.

Imagen ornamental

Vamos al grano. He dividido este post en tres categorías. Una sobre los problemas de migración de .NET Framework a .NET Core en general. Otra específicamente sobre la migración de ASP.NET a ASP.NET Core. Y la tercera sobre la migración de las Azure Functions a la versión más reciente. Siéntete libre de sumergirte en el tema que más te interese. Algunos de los contenidos están divididos en temas más específicos que nos fuimos encontrando, mientras que otros son más bien una descripción textual de dónde nos encontramos actualmente.

.NET Core

Para empezar con buenas noticias, esperaba muchos más problemas al migrar el código de .NET Framework a .NET Core. Cuando empezamos a experimentar con la migración, .NET Core estaba en la versión 1.x y faltaban aún muchas características de .NET Framework "clásico". Desde la versión 2.2 en adelante, no recuerdo haber echado de menos nada. Si saltas directamente a la última versión estable de .NET Core (no veo motivos por lo que no debieses hacerlo), hay muchas probabilidades de que tu código se compile y funcione sin necesidad de realizar ningún cambio.

Hay que estar atento a los niveles de soporte

Una cosa que debes tener en cuenta cuando saltes de .NET "clásico" a .NET Core, es un despliegue más rápido de las nuevas versiones. Eso incluye también intervalos de soporte más cortos. Con .NET "clásico", 10 años de soporte eran lo más normal, cuando ahora los 3 años de soporte de .NET Core son el periodo que se ofrece. Además, cuando se elige la versión de .NET Core con la que quieres compilar, hay que mirar el nivel de soporte que te proporciona cada versión. Microsoft marca ciertas versiones con soporte de largo plazo (LTS) que es alrededor de 3 años, mientras que otras son versiones intermedias. Estables, pero aún así versiones con un período de soporte más corto. En general, estos cambios requieren que actualices la versión .NET Core más a menudo de lo que estás acostumbrado o asumir que vas a ejecutar tus aplicaciones en una versión del framework ya no soportada.

Aquí tienes una buena visión general de las diferentes versiones y sus niveles de soporte: Política de soporte de .NET Core.

ASP.NET Core

Migrar nuestros sitios web ASP.NET MVC a ASP.NET Core ha sido la mayor tarea de todas. No quiero asustarte para que no migres y, de hecho, la mayor parte del tiempo lo pasamos migrando algunos viejos frameworks de autenticación y haciendo tareas similares no relacionadas con .NET Core. La parte MVC en ASP.NET Core funciona de manera muy parecida a la antigua y se llega muy lejos haciendo buscar y reemplazar global con algunos patrones. En las siguientes secciones, he enumerado varios problemas con los que nos encontramos durante la migración.

Cómo hacer la actualización

La ruta de actualización no es exactamente directa. Puede que existan algunas herramientas que te ayudan con ello, pero al final acabé migrando todo a mano. Para cada sitio web, hice una copia de todo su repositorio. Después borré todos los archivos de la carpeta de trabajo y creé un proyecto ASP.NET Core MVC nuevo. Luego porté cada cosa una por una. Empezando por copiar los controladores, vistas y modelos y haciendo uso de algunos patrones globales de búsqueda-reemplazo para lograr que compilase. Casi todo fue distinto a partir de ahí. Estábamos usando un viejo marco de trabajo de autenticación, y lo portamos a la característica de autenticación que trae de serie .NET Core (no a Identity). Lo mismo con Swagger, que requiere un nuevo paquete NuGet para .NET Core. etc. Nos llevó mucho tiempo migrar con seguridad el sitio web principal.

Entendiendo el middleware

Como seguramente ya sabrás, muchas de las características de ASP.NET Core están construidas sobre middlewares. El concepto de middleware no existe en ASP.NET y por lo tanto es algo que debes aprender. La forma en que configuras los middlewares y especialmente el orden en el que los instalas es algo que nos ha causado un cierto dolor de cabeza. Mi recomendación sería que estudies muy a fondo la documentación de Microsoft para este caso. Además, Andrew Lock escribió una larga serie de artículos de alta calidad sobre middleware en los que recomiendo a todo el mundo que se sumerja: https://andrewlock.net/tag/middleware/

Newtonsoft.Json vs System.Text.Json

Hasta ASP.NET Core 3.0, la serialización y deserialización de JSON se llevaba a cabo con el extremadamente popular paquete Newtonsoft.Json. Microsoft decidió lanzar su propio paquete para lo mismo en ASP.NET Core 3.0 y versiones posteriores, lo que causó algunos problemas al actualizar de la versión 2.2. a la 3.1.

System.Text.Json parece que ya es una buena implementación y, después de algunas pruebas, decidimos ir adelante con ello (es la opción por defecto en cualquier caso). Rápidamente descubrimos que Newtonsoft.Json y System.Text.Json no son compatibles en la manera en la que serializan y deserializan los objetos C#. Como nuestro cliente usa Newtonsoft.Json para serializar JSON, experimentamos algunos escenarios en los que el cliente generaba JSON que no podía ser deserializado a C# en el servidor. Mi recomendación, en caso de que estés usando Newtonsoft.Json en el cliente, es usar también Newtonsoft.Json en el servidor:

services
    .AddControllersWithViews()
    .AddNewtonsoftJson();

Después de llamar a AddControllersWithViews o cualquier otro método que llames para configurar los endpoints, puedes llamar al método AddNewtonsoftJson para que ASP.NET Core utilice ese paquete.

El cambio necesita de un paquete NuGet adicional:

Install-Package Microsoft.AspNetCore.Mvc.NewtonsoftJson

Mayúsculas y minúsculas en JSON

Un problema al que nos enfrentamos en nuestra aplicación principal fue el uso de mayúsculas y minúsculas al serializar JSON. Cuando la acción de un controlador de ASP.NET Web API devuelve JSON:

return Json(new { Hello = "World" });

El JSON devuelto usa "pascal case" (o sea, todas las primeras letras de las palabras en mayúsculas):

{"Hello":"World"}

Pero cuando se devuelve lo mismo desde ASP.NET Core, el JSON devuelto usa "camel case" (la primera letra de la primera palabra en minúsculas, el resto en mayúsculas):

{"hello":"World"}

Si tú, al igual que nosotros, ya tienes un cliente basado en JavaScript que espera que "pascal case" para los objetos serializados desde C#, puede cambiar el "casing" con esta opción:

services
    .AddControllersWithViews()
    .AddJsonOptions(options =>
    {
        options.JsonSerializerOptions.PropertyNamingPolicy = null;
    });

Compilación en tiempo de ejecución de Razor

Aunque portar las vistas de Razor de ASP.NET MVC a ASP.NET Core no requirió mucho trabajo, no tenía claro que las vistas Razor no se compilaban en tiempo de ejecución en el caso de ASP.NET Core. Escribí un artículo en el blog sobre ello: Agregar compilación en tiempo de ejecución para Razor al desarrollar con ASP.NET Core. En resumen: es necesario marcar la opción "Habilitar la compilación en tiempo de ejecución" de Razor al crear el proyecto, o bien instalar el paquete NuGet Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation y habilitar la compilación en tiempo de ejecución en Startup.cs:

services
    .AddControllersWithViews()
    .AddRazorRuntimeCompilation();

Los archivos Web.config siguen siendo válidos

La mayoría de los documentos y blogs mencionan que el archivo web.config se sustituyó por el archivo appsettings.json en ASP.NET Core. Aunque esto es cierto, todavía necesitamos el archivo web.config para implementar en IIS algunos de los encabezados de seguridad como se describe en este post: Guía de cabeceras de seguridad de ASP.NET Core.

Aquí hay un ejemplo del archivo web.config que utilizamos para eliminar las cabeceras Server y X-Powered-By que se ponen automáticamente en las respuestas HTTP cuando la aplicación se hospeda en IIS:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Soporte de Azure

Si tu aplicación se ejecuta en Azure (como las nuestras) debes averiguar qué versiones de .NET Core soporta cada región de Azure. Cuando se lanzan nuevas versiones de .NET Core, las regiones de Azure se actualizan en un período que puede llevar de semanas a incluso meses. Antes de actualizar, debes comprobar si tu región es compatible con la versión a la que te estás actualizando. La mejor forma de averiguarlo la tienes en el .NET Core en App Service Dashboard.

Bundling y minificación

El bundling y la minificación era una de las cosas que, creo que funcionaban muy bien en ASP.NET MVC. En ASP.NET Core tienes bastantes opciones diferentes para hacer lo mismo, lo cual es bueno, pero también un poco confuso cuando vienes directamente de ASP.NET MVC. Microsoft tiene un buen documento sobre el tema aquí: Agrupar y minimizar los activos estáticos en ASP.NET Core.

Al final acabamos utilizando la extensión Bundler & Minifier de Mads Kristensen, sobre la que quizás escriba una entrada específica en el blog. En resumen, especificamos los archivos de entrada y salida en un archivo bundleconfig.json:

[
  {
    "outputFileName": "wwwroot/bundles/style.min.css",
    "inputFiles": [
      "wwwroot/css/style1.css",
      "wwwroot/css/style2.css"
    ]
  }
]

Este archivo se procesa con Gulp y se hace el bundling y la minificación con los paquetes gulp-cssmin, gulp-concat, y otros paquetes npm similares (tenemos un curso fenomenal de herramientas Front-End aquí). Esto hace posible ejecutarlo tanto localmente (conectando las tareas de Gulp al build de Visual Studio si lo deseas), como en nuestro servidor de Azure DevOps.

Mira mamá, no más peticiones potencialmente peligrosas

Si has estado ejecutando ASP.NET MVC y registrando peticiones fallidas, probablemente ya has visto este error muchas veces:

Se ha detectado un valor potencialmente peligroso en Request.Form

ASP.NET MVC no permitía etiquetas <script> y similares como parte de las peticiones POST a los controladores de MVC. ASP.NET Core cambió eso y acepta entradas como esa. Si para ti es importante securizar la aplicación contra contenidos como ese, necesitarás añadir un filtro o algo similar que los compruebe. En nuestro caso, "escapeamos" todo usando Knockout.js, por lo que hacer peticiones en las que haya fallos de marcado no tiene importancia. Pero es algo que sin duda hay que tener en cuenta.

Funciones de Azure

Migrar a la versión más reciente de las Funciones de Azure (actualmente la v3) ha sido un proceso largo. Muchas de las características de elmah.io se basan en tareas programadas y servicios que están en ejecución mucho tiempo, como por ejemplo consumir mensajes desde el Azure Service Bus, enviar un correo electrónico de resumen diario, etc. Hace unos años, todos estos "trabajos" se ejecutaban como tareas programadas de Windows y servicios de Windows en una máquina virtual en Azure. Migramos todos estos servicios menos uno a Azure Functions v1 ejecutándose en .NET Framework.

Cuando salió Azure Functions v2, comenzamos a migrar una aplicación de funciones a v2 ejecutándose en .NET Core con resultados pobres. Existían todo tipo de problemas y el conjunto disponible de clases de la biblioteca base no era lo suficientemente bueno. Cuando salió .NET Core 2.2 finalmente dimos el salto y portamos todas las funciones.

Como parte de la reciente tarea de migración, migramos todas las aplicaciones de funciones a Azure Functions v3 ejecutándose en .NET Core 3.1. El código se ha estado ejecutando extremadamente estable desde que lo hicimos, y yo recomendaría esta configuración para su uso en producción.

Cómo hacer la actualización

La actualización fue mucho más rápida que la de ASP.NET Core. Las versiones v1, v2 y v3 siguen más o menos la misma estructura de archivos y la mayor parte del conjunto de características. Para actualizar, simplemente actualicé el marco de trabajo de cada proyecto así como todos los paquetes NuGet.

Usar Microsoft.Azure.Functions.Extensions

Si tú, como nosotros, comenzaste a crear Funciones de Azure con la versión 1 del runtime y .NET "clásico", probablemente te habrás preguntado cómo hacer la inyección de dependencias o la inicialización de las funciones. Al actualizar a la v2 y .NET Core 2.2 comenzamos a usar el paquete NuGet de Microsoft.Azure.Functions.Extensions. Una vez instalado, puedes especificar un archivo Startup.cs en la app de tu Function, tal como lo habrías hecho en ASP.NET Core. Allí, puedes abrir las conexiones de la base de datos, configurar el registro, etc:

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(My.Function.Startup))]

namespace My.Function
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddHttpClient(...);

            var config = new ConfigurationBuilder()
                .AddJsonFile("local.settings.json")
                .Build();

            builder.Services.AddLogging(logging =>
            {
                logging.AddSerilog(dispose:true);
            });

            builder.Services.AddSingleton<IFunctionFilter, PerformanceFilter>();
        }
    }
}

El código anterior es tan solo un conjunto aleatorio de líneas de configuración que he elegido de una de nuestras funciones. Aunque debería resultar familiar para los desarrolladores de ASP.NET Core.

No uses los bindings de salida

Una de las cosas buenas de las Azure Functions es un catálogo cada vez mayor de bindings de entrada y salida. ¿Quieres ejecutar la función cuando se escribe un nuevo blob en el almacenamiento de blobs? Añade un binding de entrada a blobs. ¿Escribir un mensaje en una cola una vez que la función se ha completado? Añade un binding de salida al bus de servicio... Teníamos un viejo código portado de Servicios de Windows, que hacía toda esta comunicación manualmente y me interesaba empezar a utilizar los bindings de salida de las Azure Functions cuando lo portásemos a v3.

Al final acabé echando para atrás la mayoría de estos cambios y evitando los bindings de salida por completo. Aunque están muy bien pensados, pierdes el control de lo que sucede en esos bindings. Además, cada binding se implementa de forma diferente. Algunos con reintentos, otros sin ello. Esta respuesta de Stephen Cleary lo explica bastante bien. En la iteración de código más reciente, he creado todos los clientes de la base de datos, clientes de temas, etc. en el archivo Startup.cs y los inyecto en el constructor de cada función. Así tengo el control total de cuándo hacer peticiones, cuántos reintentos quiero ejecutar, etc. Otra ventaja es que el código de la función ahora se parece mucho al código de los sitios web de ASP.NET Core, que inicializa e inyecta las dependencias de la misma manera.

Herramientas

Antes de terminar, quiero decir unas palabras sobre las herramientas de migración automática. Cuando comenzamos el proyecto de migración existían algunas opciones. Y desde entonces han aparecido aún más. No he probado ninguna de ellas, pero ahora hay tantas opciones disponibles que, si empezase hoy con la migración probablemente lo haría. Échales un vistazo:

Conclusión

Migrar ha sido, en conjunto, una gran decisión para nosotros. Ya le estamos viendo cantidad de ventajas. Un framework más simple. Tiempos de build más rápidos. La compilación de Razor es mucho más rápida. Más fácil trabajar en código para los que prefieren hacerlo así. Mejor rendimiento en Azure y menos consumo de recursos (principalmente memoria). La posibilidad de mover el hosting a Linux. Y mucho más. Dicho esto, la migración llevó mucho tiempo.

Las secciones de antes las he ido escrito de lo que recordaba mientras escribía el post. Puede que quiera incluir más secciones cuando recuerde algo o encuentre nuevos temas. Si tienes algún tema específico sobre el que quieras aprender más o preguntas concretas sobre la migración, no dudes en contactar con nosotros en elmah.io.

CVE-2020-25613: WEBrick potencialmente vulnerable a contrabando de solicitudes HTTP

16/10/2020
Artículo original

Se reportó una potencial vulnerabilidad en WEBrick a contrabando de solicitudes HTTP. A esta vulnerabilidad se le ha asignado el identificador CVE CVE-2020-25613. Recomendamos enfáticamente actualizar la gema webrick.

Detalles

WEBrick era demasiado tolerante a encabezados Transfer-Encoding inválidos. Esto puede conducir a interpretaciones inconsistentes entre WEBrick y algunos servidores proxy HTTP, que podría permitir a un atacante “contrabandear” una solicitud. Ver en detalle CWE-444.

Por favor actualice la gema webrick a la versión 1.6.1 o posterior. Puede usar gem update webrick para actualizarla. Si está usando bunler, por favor añada o actualice gem "webrick", ">= 1.6.1" a su Gemfile.

Versiones afectadas

  • gema webrick 1.6.0 o anteriores
  • versiones incorporadas de webrick en ruby 2.7.1 o anteriores
  • versiones incorporadas de webrick en ruby 2.6.6 o anteriores
  • versiones incorporadas de webrick en ruby 2.5.8 o anteriores

Créditos

Agradecemos a piao por descubrir este problema.

Historia

  • Publicado originalmente el 2020-09-29 06:30:00 (UTC)

Publicado por mame el 2020-09-29
Traducción de vtamara

Página Anterior Página Siguiente