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

Publicado Ruby 2.7.2

16/10/2020
Artículo original

Ruby 2.7.2 ha sido publicado.

Esta versión contiene incompatibilidades intencionales. Las advertencias de obsolescencia están apagadas por omisión en 2.7.2 y posteriores. Puede encender las advertencias de obsolescencia especificando la opción -w o -W:deprecated en la línea de ordenes. Por favor revise detalles en los temas siguientes.

Esta versión contiene la nueva versión de webrick con una corrección de seguridad descrita en el artículo

Ver otros cambios en la bitácora de contribuciones.

Descargas

  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.2.tar.bz2

    SIZE: 14708724
    SHA1: 7e30ca324464eab2f4c2a56d8ab4a37174998062
    SHA256: 65a590313d244d48dc2ef9a9ad015dd8bc6faf821621bbb269aa7462829c75ed
    SHA512: f07592cce4de3532c0fa1c84d53a134527d28ba95e310cd3487ac321c49ee680faeace285de544ee6db432a90aa7538a1d49ff10c72b235968ca362ef9be621d
    
  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.2.tar.gz

    SIZE: 16836767
    SHA1: cb9731a17487e0ad84037490a6baf8bfa31a09e8
    SHA256: 6e5706d0d4ee4e1e2f883db9d768586b4d06567debea353c796ec45e8321c3d4
    SHA512: e80dc16b60149d0d6fedf0ba7b556ae460ff328ee63e9d9e41f5021f67addcc98159cb27bddccaebd6e4b1cddf29266f1c01c32d9ec8bb665aed63c0a2295f2f
    
  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.2.tar.xz

    SIZE: 12037052
    SHA1: 82a1fe683460caa8edb6199707f2905634e5ffcc
    SHA256: 1b95ab193cc8f5b5e59d2686cb3d5dcf1ddf2a86cb6950e0b4bdaae5040ec0d6
    SHA512: 7972278b096aa768c7adf2befd26003e18781a29ca317640317d30d93d6e963ded197724c8e2f1dfe1e838c5647176d414a74732a62e931fb50d6f2e0f777349
    
  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.2.zip

    SIZE: 20618242
    SHA1: 9acee3d4e9399c3a2ddc2dd078dd2ee26327cc8f
    SHA256: c6b8597e5414f2b01a7cb25095319f2b0e780c95a98fee1ccf1ef022acf93dcc
    SHA512: 5f3a8d78bbd3d9700e5f0434d0cec2072816c02f5d5b55f24d4f9f0621c0c89f796e9ada32ed65f052a321845dd29709a1b76170c7dd0250bea6f8c18953a366
    

Comentario de la versión

Agradecemos a los muchos contribuyentes, desarrolladores y usuarios que suministraron reportes de fallas y contribuciones que hicieron posible esta versión.

Publicado por nagachika el 2020-10-02
Traducción de vtamara

Sega celebra 60 años con una promoción especial en Steam y 60 días de contenido

15/10/2020
Artículo original

2020 marca el aniversario N° 60 de SEGA, una de las compañías de videojuegos más importantes de la historia. Sega West lo celebra con 60 días de contenidos. La semana de festejos empezó ayer miércoles 14 de octubre en Steam. En la página de la promoción de Steam podemos encontrar descuentos en varios títulos. Particularmente interesante también varios minijuegos nuevos con inspiración retro, gratuitos, creados por los estudios SEGA específicamente para el 60° aniversario: Armor of Heroes – Relic Entertainment™ – Un título multijugador de tanques para hasta 4 jugadores en combate versus y cooperativo offline. Disponible desde el 15 al 19 de Octubre. Endless Zone – Amplitude Studios™ – El universo Endless y la Fantasy Zone™chocan en este shoot ’em up de scroll lateral. Disponible desde el 16 al 19 de Octubre. Streets of Kamurocho – SEGA® – Kiryu y Majima de la premiada serie Yakuza™de SEGA pelean en las calles de Kamurocho en un formato nuevo pero familiar. Disponible desde el 17 al 19 de Octubre. Golden Axed – SEGA® – Una versión sin finalizar y nunca antes vista de un proyecto cancelado llamado Golden Axe™: Reborn. Disponible desde el 18 al 19 de Octubre. Sí, solamente un […]

The post Sega celebra 60 años con una promoción especial en Steam y 60 días de contenido first appeared on Picando Código.

Cómo garantizar el soporte a largo plazo de tu aplicación .NET

15/10/2020
Artículo original

Con la aparición de versión 5 de .NET es un buen momento para reunir en un solo artículo toda la información sobre las versiones de .NET, la cadencia con la que aparecerán y las políticas de soporte que ofrece Microsoft para cada versión.

El sistema de versiones de .NET Core tiene una manera muy diferente de funcionar respecto a lo que era .NET Framework, así que si vienes del desarrollo de aplicaciones con .NET "clásico" o si estás empezando con .NET Core o .NET, te resultará de mucha ayuda comprender la periodicidad de los lanzamientos del framework, los tipos de soporte que existen y su ciclo de vida, para poder tomar las decisiones correctas sobre qué versión utilizar en cada caso, sobre todo si trabajas en una empresa u organización donde la estabilidad de soporte es importante.

Si necesitamos soporte técnico con .NET, tenemos dos opciones:

  • Soporte de la comunidad: básicamente documentación, foros, Stack Overflow, etc... El búscate la vida de siempre en el que nadie te garantiza una solución ni tampoco una respuesta, pero que la realidad es que es, el que utiliza casi todo el mundo.
  • El soporte oficial de Microsoft: Microsoft pone a tu disposición todo su poder de recursos humanos técnicos para ayudarte a solucionar el problema, con garantía de respuesta. Generalmente este es el que escogen las empresas y las corporaciones cuando el anterior no les da una solución.

Aunque solo vayas a utilizar el soporte de la comunidad, te interesa conocer los ciclos de vida de soporte de .NET, a pesar de pienses que no va contigo. El motivo es que no sólo se regula el soporte técnico directo que recibes de Microsoft, sino también el soporte que obtiene la propia plataforma para recibir actualizaciones y parches de seguridad.

En la propia página de descargas de .NET te indican siempre qué nivel de soporte tiene cada versión y hasta qué fecha dura, pero conviene conocer bien qué significa cada caso:

La página de descargas de .NET

Vamos a verlo...

Tipos de versiones de .NET y su soporte técnico

Las versiones de .NET "tradicional" han utilizado lo que Microsoft denomina ciclo de vida fijo que, como su nombre lo indica, proporcionan un período fijo de soporte, que suele ser largo. Por ejemplo, 5 años de soporte estándar (incluidas las revisiones de seguridad y las que no están relacionadas con la seguridad) y otros 5 años de soporte extendido (solo correcciones de seguridad).

.NET Core y .NET adoptan lo que Microsoft llama ciclo de vida moderno , que es muy diferente ya que adoptan un modelo de soporte más corto y más frecuente.

Así, .NET Core / .NET incluye versiones principales (major), versiones secundarias (minor) y actualizaciones de servicio (parches/patches). Así, por ejemplo:

  • .NET Core 3.0 es una versión principal del producto.
  • .NET Core 3.1 es la primera versión secundaria después de la versión principal de .NET Core 3.0.
  • .NET Core 3.1.7 tiene una versión principal de 3, una versión secundaria de 1 y una versión de parche de 7, es decir, es el séptimo parche para .NET Core 3.1.

Desde una perspectiva del soporte oficial que da Microsoft al framework, existen 2 "pistas" de soporte para las versiones de .NET Core.

  • Las versiones "actuales" (current): estas versiones de .NET Core y de .NET tienen soporte oficial tan solo durante un período de 3 meses tras haberse lanzado la siguiente versión principal o secundaria.
  • Las versiones LTS (Soporte a largo plazo): a estas se les da soporte durante un mínimo de 3 años, o 1 año después de que se envíe la próxima versión LTS (lo que sea más tarde).

Vamos a verlo con ejemplos concretos:

Cuando salió .NET Core 3.0 en septiembre de 2019, se trataba de una versión "current". En diciembre de ese mismo año salió .NET Core 3.1, una versión secundaria de la anterior, así que el soporte de .NET Core 3.0 dura hasta marzo de 2020, o sea, 3 meses después y se supone que deberías migrar a 3.1 lo antes posible para tener soporte, lo cual, al no ser una versión que rompa la compatibilidad, no debería suponer problema alguno.

Un ejemplo de LTS sería .NET Core 2.0, que se designó como LTS en agosto de 2018, así que se soporta durante 3 años como mínimo, es decir, hasta agosto de 2021. La siguiente versión LTS que apareció fue .NET Core 3.1, en diciembre de 2019 y se garantiza el soporte hasta al menos un año después, o sea, diciembre de 2020. Así que como agosto de 2021 es más tarde que diciembre de 2020, la fecha efectiva de fin de soporte de .NET Core 2.0 será agosto de 2021.

La finalización del soporte significa que, después de la fecha oficial de fin, Microsoft ya no lanzará más actualizaciones, parches ni dará asistencia técnica oficial para esa versión de .NET. Así que hay que tenerlas presentes porque antes de esta fecha tenemos que haber pasado nuestra aplicación a una versión que esté soportada.

Si continúas usando una app compilada para una versión que no está soportada, no recibirás las actualizaciones de seguridad que sean necesarias y tus usuarios podrían estar en peligro.

Frecuencia de versiones en .NET Core/.NET

Las versiones de .NET Core y de .NET siempre alternan entre las versiones LTS y Current, por lo tanto, .NET Core 3.1 es una versión LTS, pero la siguiente versión .NET 5 es una versión "current" y su soporte oficial durará menos tiempo que el de .NET Core 3.1.

La siguiente versión LTS será .NET 6 en noviembre de 2021, y así sucesivamente: .NET 7 será current, .NET 8 será LTS...

El lanzamiento de las próximas versiones de .NET y su nivel de soporte

Las actualizaciones de mantenimiento, que se envían (casi siempre) cada mes, incluyen correcciones de seguridad, estabilidad, confiabilidad y compatibilidad y se adhieren a la versión menor anterior. Es decir, .NET Core 3.1.7 es a efectos de soporte lo mismo que .NET Core 3.1, por poner un ejemplo.

Así que, si vas a crear una aplicación nueva que quieres que esté varios años soportada en cuanto a problemas de seguridad, estabilidad, etc.., es mejor hacerla con .NET 3.1 que con .NET 5 si quieres tener ese soporte oficial y conseguir este tipo de actualizaciones.

¿Qué versión utilizan las aplicaciones cuando hay una versión nueva del runtime de .NET?

Las actualizaciones principales y secundarias se instalan en paralelo a las versiones anteriores. Las aplicaciones siempre quedan atadas a una combinación de versión mayor/menor específica, la utilizada durante el desarrollo. Es decir, si instalamos una versión nueva del runtime que, entre otras cosas, soluciona un bug o mejora una característica, no quiere decir que nuestra aplicación la empiece a usar automáticamente. O sea, la aplicación no usa automáticamente la versión principal/secundaria más reciente.

Por ejemplo, una aplicación que se compiló para .NET Core 3.0 no comienza a ejecutarse automáticamente en .NET Core 3.1 cuando lo instalamos, a pesar de que estén dentro de la misma versión principal. Lo que tendrías que hacer es volver a compilar la aplicación contra la nueva versión para asegurarte de que todo funciona correctamente. Una vez recompilada, entonces sí que usará la nueva versión.

Sin embargo, las actualizaciones de "parche", sí que se tratan de manera diferente a las versiones principales y secundarias. Una aplicación creada para .NET Core 3.1 se dirige al tiempo de ejecución 3.1.0 de forma predeterminada, pero avanza automáticamente para usar una versión 3.1 más reciente. De esta manera tendremos un entorno de ejecución más seguro porque esas versiones de "parche" incluyen siempre correcciones de problemas de seguridad y de estabilidad, como ya hemos dicho.

Cómo funcionan las versiones del SDK de .NET

Ahora vamos a ver otro pequeño giro de tuerca...

Una cosa es el runtime de .NET, lo que se usa para ejecutar las aplicaciones, y otra diferente pero relacionada es el SDK de .NET, que es lo que se utiliza para crear las aplicaciones. Lo que comentábamos en el apartado anterior se refiere al runtime.

El control de versiones para el SDK de .NET (o sea, el Kit de desarrollo de software) funciona de manera algo diferente al del runtime de .NET.

Las actualizaciones del SDK de .NET a veces incluyen nuevas características o nuevas versiones de componentes como MSBuild o NuGet para alinearse con las nuevas versiones de Visual Studio. Estas nuevas funciones o componentes pueden ser incompatibles con las versiones que se envían en actualizaciones anteriores del SDK para el mismo valor de versión principal/secundario.

Así que, para versionar los SDK, existen lo que se llaman bandas de características, como una forma de diferenciar entre las actualizaciones de SDK. Las bandas de características se definen en el tercer número de sección y siempre van en alguna centena.

Por ejemplo, el primer SDK de .NET Core 3.1 fue 3.1.100. Esta versión corresponde a la banda de características 3.1.1xx. Así, las versiones 3.1.101 y 3.1.201 del SDK tienen dos bandas de características diferentes, mientras que 3.1.101 y 3.1.199 están en la misma banda de características.

Cuando tenemos instalado en la nuestra máquina el primer SDK de .NET Core 3.1, que es el 3.1.100, cuando sale la siguiente versión dentro de esa banda, la 3.1.101, la versión anterior de la misma banda se elimina automáticamente de la máquina porque son totalmente compatibles. Sin embargo, cuando sale el SDK 3.1.200, que es de otra banda diferente y por lo tanto incompatible, el anterior no se quita y coexisten los dos para poder crear aplicaciones para cada una de las bandas.

¿Y qué pasa con .NET "clásico"?

Como ya sabrás si sigues el blog de campusMVP, .NET 4.8 es la última versión importante que va a salir de la plataforma .NET "clásica".

Si tiene aplicaciones creadas con .NET "clásico", salvo que quieras sacar partido a alguna característica específica de .NET (como el hecho de que es multiplataforma) no merece la pena en general que intentes migrarla a .NET Core/.NET y te garantizas que va a funcionar durante muchos años en Windows ya que Microsoft la va a incluir con el sistema operativo en el futuro previsible, y por lo tanto seguirá dando soporte, correcciones y actualizaciones de seguridad. Así que su funcionamiento está garantizado.

Microsoft ya ha manifestado oficialmente que .NET 4.x está tan entremezclado con Windows que, por razones de compatibilidad, no existen planes de eliminar .NET Framework 4.8 de Windows.

 

Publicado Ruby 3.0.0 versión previa 1

14/10/2020
Artículo original

Nos complace anunciar la publicación de Ruby 3.0.0-preview1.

Introduce una serie de características nuevas y mejoras en desempeño.

RBS

RBS es un lenguaje para describir los tipos de los programas Ruby. Los verificadores de tipos, incluyendo perfiladores de tipos, y otras herramientas que soporten RBS entenderán mejor los programas Ruby con definiciones RBS.

Usted puede escribir la definición de clases y módulos: métodos que se definen en la clase, variables de instancia y sus tipos, y relaciones herencia/mix-in. El objetivo de RBS es soportar los patrones que comúnmente se ven en programas en Ruby y permitir escribir tipos avanzados incluyendo tipos unión, sobrecarga de métodos y genéricos. También soporta tipado pato (duck typing) con tipos de interfaz.

Ruby 3.0 se distribuye con la gema rbs, que permite analizar y procesar definiciones de tipos escritas en RBS.

El siguiente es un pequeño ejemplo de RBS.

module AplicacionMensajeria
  VERSION: String

  class Channel
    attr_reader nombre: String
    attr_reader mensajes: Array[Mensaje]
    attr_reader usaurios: Array[Usuario | Robot]           # `|` significa tipos unión, `Usuario` or `Robot`.

    def initialize: (String) -> void

    def publicar: (String, de: Usuario | Robot) -> Mensaje # Se soporta sobrecarga de métodos.
            | (File, de: Usuaurio | Robot) -> Mensaje
  end
end

Ver más detalles en el archivo README de la gema rbs.

Ractor (experimental)

Un Ractor es una abstracción de concurrencia al estilo Actor-modelo, diseñada para brindar una forma de ejecución en paralelo sin preocuparse por la seguridad de los hilos de ejecución.

Puede crear múltiples ractors y puede ejecutarlos en paralelo. Un Ractor permite hacer programas paralelos con seguridad en los hilos de ejecución porque los ractors no comparten objetos normales. La comunicación entre ractors se soporta mediante envío de mensajes.

Para limitar los objetos que se comparten, Ractor introduce diversas restricciones a la sintaxis de Ruby (no hay cambio cuando no hay múltiples Ractors).

La especificación e implementación no es madura y podría cambiar a futuro, por eso esta característica se señala como experimental y cuando se crea un Ractor se presenta una advertencia de característica experimental.

El siguiente pequeño programa calcula prime? en paralelo con dos ractores y es casi 2 veces más rápido con dos o más núcleos que el programa secuencial.

require 'prime'

# n.prime? con enteros enviados en r1, r2 que corren en paralelo
r1, r2 = *(1..2).map do
  Ractor.new do
    n = Ractor.recv
    n.prime?
  end
end

# send parameters
r1.send 2**61 - 1
r2.send 2**61 + 15

# wait for the results of expr1, expr2
p r1.take #=> true
p r2.take #=> true

Ver más detalles en doc/ractor.md.

Planificador (Scheduler Experimental)

Se introduce Thread#scheduler para interceptar operaciones que bloquean. Esto permite una concurrencia liviana sin cambiar el código existente.

Los métodos y clases que se soportan en el momento son:

  • Mutex#lock, Mutex#unlock, Mutex#sleep
  • ConditionVariable#wait
  • Queue#pop, SizedQueue#push
  • Thread#join
  • Kernel#sleep
  • IO#wait, IO#read, IO#write y métodos relacionados (e.g. #wait_readable, #gets, #puts y así sucesivamente).
  • IO#select no es soportado.

El actual punto de entrada para la concurrencia es Fiber.schedule{...} sin embargo está sujeto a cambios para cuando se publique Ruby 3.

En el momento, hay disponible un planificador de prueba en Async::Scheduler. Ver más detalles en doc/scheduler.md. [Feature #16786]

ADVERTENCIA: Esta característica es altamente experimental. Tanto el nombre como sus características cambiarán en la siguiente versión prevía.

Otras características notables

  • Se agrega una asignación al lado derecho.
  fib(10) => x
  p x #=> 55
  
  • Se agrega una definición de métodos que no requiere end.
  def cuadrado(x) = x * x
  
  • Se agrega un patrón Encontrar (Find).
  case ["a", 1, "b", "c", 2, "d", "e", "f", 3]
  in [*pre, String => x, String => y, *post]
    p pre  #=> ["a", 1]
    p x    #=> "b"
    p y    #=> "c"
    p post #=> [2, "d", "e", "f", 3]
  end
  
  • Hash#except ahora es un método incorporado.
  h = { a: 1, b: 2, c: 3 }
  p h.except(:a) #=> {:b=>2, :c=>3}
  
  • Se agrega como característica experimental Memory view

    • Este es un nuevo conjunto de llamados en la API de C para intercambiar áreas de memoria puras entre las librerías que son extensiones, por ejemplo para intercambiar un arreglo numérico con un mapa de bits. Las librerías que son extensiones pueden compartir también los metadatos del área de memoria que constan de la forma, el formato del elemento y así sucesivamente. Usando esta clase de metadatos, las librerías que son extensiones pueden compartir apropiadamente incluso un rreglo multidimensional. Esta nueva característica se diseñó empleando como referencia el protocolo de colchón (buffer ) de Python.

Mejoras en desempeño

  • Se implemetaron muchas mejoras en MJIT. Ver detalles en el archivo NEWS.

Otros cambios notables desde 2.7

  • Los argumentos de palabra clave se separan de otros argumentos.
    • En principio, el código que presente una advertencia en Ruby 2.7 no funcionará. Ver detalles en la documentación.
    • Por cierto, el re-envío de argumentos ahora soporta argumentos principales.
    def method_missing(meth, ...)
      send(:"do_#{ meth }", ...)
    end
    
  • La característica $SAFE se eliminó por completo; ahora es una variable global normal.

  • El orden de la traza de llamados (backtrace) se había revertido para ser como en Ruby 2.5, pero esto se ha cancelado. Ahora se comporta como Ruby 2.4; se imprime primero un mensaje de error y el número de línea donde ocurrió la excepción; las funciones que había hecho la llamada se imprimen después.

  • Se actualizaron algunas librerías estándar.
    • RubyGems 3.2.0.rc.1
    • Bundler 2.2.0.rc.1
    • IRB 1.2.6
    • Reline 0.1.5
  • Las siguientes librerías ya no son gemas distribuidas con Ruby. Instale las gemas correspondientes para usar sus funcionalidades.
    • net-telnet
    • xmlrpc
  • Las siguientes gemas por omisión se volvieron gemas distribuidas con Ruby.
    • rexml
    • rss
  • stdlib se volvió gema por omisión. Las siguientes gemas por omisión se publicaron en rubygems.org
    • abbrev
    • base64
    • English
    • erb
    • find
    • io-nonblock
    • io-wait
    • net-ftp
    • net-http
    • net-imap
    • net-protocol
    • nkf
    • open-uri
    • optparse
    • resolv
    • resolv-replace
    • rinda
    • securerandom
    • set
    • shellwords
    • tempfile
    • time
    • tmpdir
    • tsort
    • weakref

Ver más detalles en el archivo NEWS o en la bitácora de contribuciones.

Con estos cambios, 3385 archivos cambiados, 150159 inserciones(+), 124949 eliminaciones(-) desde Ruby 2.7.0!

¡Por favor pruebe Ruby 3.0.0-preview1, y denos cualquier retroalimentación!

Descargas

  • https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.0-preview1.tar.bz2

    SIZE: 15538340
    SHA1: 032697f3ace0a697cd72f68bac0032c31a8328d4
    SHA256: 013bdc6e859d76d67a6fcd990d401ed57e6e25896bab96d1d0648a877f556dbb
    SHA512: 3a6a6458d9c5f06555ab8705160f6b071f4dbe9d2a91cd7848852633657b495c480d74e4b2ff2cebddda556118d26bbb271160c989bc970bb1b5cb234e868d2f
    
  • https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.0-preview1.tar.gz

    SIZE: 17747808
    SHA1: 2842d2af2568d74c8d4071f5f536889a6b149202
    SHA256: ce8bd7534e7ec2a870b24d2145ea20e9bbe5b2d76b7dfa1102dbee5785253105
    SHA512: b94892951f842a1538f4b99022606ac2c0b5031f1ede7eef3833a8caa9ed63e9b22868509173bfefb406f263c65211db75597b152b61f49e5ba2a875fce63a27
    
  • https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.0-preview1.tar.xz

    SIZE: 12703060
    SHA1: 91d9fbe87504924148deeec90199d6ff4d7dcf56
    SHA256: aa7cce0c99f4ea2145fef9b78d74a44857754396790cd23bad75d759811e7a2a
    SHA512: dca5dcc965c434371947c100864090e29e649e19ae24b8bb2e88a534ebd8220c5a086035a999b1e8b1cd5ec154a6985a8d8dfea56095d712d62aeea7a2054f7d
    
  • https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.0-preview1.zip

    SIZE: 22002645
    SHA1: 4b5b61066373daf0a947d3fafe2645788504a164
    SHA256: a39a48ed9a8ca2c83d65d225a1bb3db331c6587a77ba156c20e630c1b4bfc23b
    SHA512: 10f6f28715a52093d7d9da82d1678147091b45e2f279e463626adea8efbf181485daa42565e5086057ffb45a097ffb8ff395c572b247b6b5da27d85933cf58a8
    

Avance de 3.0.0-preview2

Planeamos incluir “type-profiler” que es un analizador de tipos estáticos. ¡Esté pendiente!

Qué es Ruby

Ruby fue desarrollado inicialmente por Matz (Yukihiro Matsumoto) en 1993, y ahora es desarrollado como código abierto. Corre en muchas plataformas y se usa en todas partes del mundo especialmente para desarrollos web.

Publicado por naruse el 2020-09-25
Traducción de vtamara

Aclarando conceptos: Inteligencia Artificial, Machine Learning, Deep Learning, Big Data y Ciencia de Datos

13/10/2020
Artículo original

El mundo de la tecnología, como cualquier otro, no es inmune a las modas. Y estas modas hacen que ciertas palabras y conceptos se utilicen de manera arbitraria, como simples palabras huecas de marketing, que al final acaban perdiendo la sustancia y la validez de tanto usarlas mal. Así que cada vez que hay una tecnología en ascenso se generan ciertas buzzwords que todo el mundo utiliza y que no puedes dejar de escuchar y leer por todas partes.

Sin duda la tendencia tecnológica más puntera de los últimos años es todo lo relacionado con la inteligencia artificial y el análisis de datos. Y es que de manera relativamente reciente se han dado grandes avances en este campo, que unidos a la disponibilidad de enormes cantidades de datos y cada vez mayor potencia de cómputo están dando lugar a todo tipo de aplicaciones prácticas muy interesantes.

El problema viene cuando los términos relacionados con el campo se convierten en palabras vacías de marketing que en muchos casos son directamente mentira. Es muy habitual hablar de que tal o cual producto usa la inteligencia artificial para lograr algo y, en ocasiones, son algoritmos convencionales tomando decisiones predecibles. Como dice el famoso Tweet de I Am Devloper:

Tú dices: "Hemos añadido IA a nuestro producto" Yo escucho: "Hemos añadido un montón de IFs extra a nuestro código"

O como la siempre estupenda tira cómica de CommitStrip en la que se ve a un comercial presentando a un maravilloso robot que usa IA pero que, al romperlo, dentro solo tiene miles de condicionales:

La tira cómica sobre AI e Ifs de CommitStrip

Pero incluso cuando se usan con toda la buena intención, a veces resulta complicado discernir qué es cada cosa cuando se habla de tantos términos relacionados que no todo el mundo conoce bien.

En este artículo trataré de explicarte de manera concisa y clara qué significan cada uno de los términos más comunes relacionados con la ciencia de datos y la inteligencia artificial.

¡Allá vamos!

¿Qué es la Inteligencia Artificial?

La inteligencia artificial (IA o AI) nació como ciencia hace ya muchos años, cuando las posibilidades de las computadoras eran realmente limitadas, y se refiere a lograr que las máquinas simulen las funciones del cerebro humano.

La IA se clasifica en dos categorías según sus capacidades:

  • IA general (o fuerte): que intenta lograr máquinas/software capaces de tener inteligencia en el sentido más amplio de la palabra, en actividades que implican entender, pensar y razonar en cuestiones de carácter general, en cosas que cualquier ser humano puede hacer.
  • IA estrecha (o débil): que se centra en dotar de inteligencia a una máquina/software dentro de un ámbito muy concreto y cerrado o para una tarea muy específica.

Así, por ejemplo, una IA fuerte sería capaz de aprender por sí misma y sin intervención externa a jugar a cualquier juego de mesa que le "pongamos delante", mientras que una IA débil aprendería a jugar a un juego concreto como el ajedrez o el Go. Es más, una hipotética IA fuerte entendería qué es el juego, cuál es el objetivo y cómo se juega, mientras que la IA débil, aunque juegue mejor que nadie al Go (un juego tremendamente complicado) no tendrá ni idea realmente de qué está haciendo.

Una de las cuestiones cruciales a la hora de distinguir un sistema de inteligencia artificial de un mero software tradicional (por complejo que sea, lo cual nos lleva a los chistes de arriba) es que la IA se "programa" sola. Es decir, no consiste en una serie de secuencias lógicas predecibles, sino que tienen la capacidad de generar por su cuenta razonamientos lógicos, aprendizaje y autocorrección.

El campo ha avanzado mucho en estos años y tenemos IAs débiles capaces de hacer cosas increíbles. Las IAs fuertes siguen siendo un sueño de investigadores, y la base del guion de muchas novelas y películas de ciencia-ficción.

¿Qué es Machine Learning?

El Machine Learning (ML) o aprendizaje automático se considera un subconjunto de la inteligencia artificial. Se trata de una de las maneras de las que disponemos para lograr que las máquinas aprendan y "piensen" como los humanos. Como su propio nombre indica, las técnicas de ML se utilizan cuando queremos que las máquinas aprendan de la información que les proporcionamos. Es algo análogo a cómo aprenden los bebés humanos: a base observación, prueba y error. Se les proporcionan datos suficientes para que puedan aprender una tarea determinada y limitada (recuerda: IA débil), y luego son capaces de aplicar ese conocimiento a nuevos datos, corrigiéndose y aprendiendo más con el tiempo.

Existen muchas maneras de enseñar a una máquina a "aprender": técnicas de aprendizaje supervisado, no supervisado, semisupervisado y por refuerzo, en función de si se le da la solución correcta al algoritmo mientras aprende, no se le da la solución, se le da a veces o sólo se le puntúa en función de lo bien o mal que lo haga, respectivamente. Y existen multitud de algoritmos que se pueden utilizar para diferentes tipos de problemas: predicción, clasificación, regresión, etc...

Puede que hayas oído hablar de algoritmos como regresión lineal simple o polinómica, máquinas de vectores soporte, árboles de decisión, Random Forest, K vecinos más cercanos.... Estos son solo algunos de los algoritmos comunes utilizados en ML. Pero existen muchos más.

Pero conocer estos algoritmos y para qué sirven (para entrenar al modelo) es solo una de las cosas que se necesitan conocer. Antes es también muy importante aprender a obtener y cargar los datos, hacer análisis exploratorio de los mismos, limpiar la información... De la calidad de los datos depende la calidad del aprendizaje, o como suele decirse en ML: "Basura entra, basura sale".

En la actualidad las bibliotecas de Machine Learning para Python y R han evolucionado mucho, por lo que incluso un desarrollador sin conocimientos de matemáticas o estadística más allá de las del instituto, puede construir, entrenar, probar, desplegar y usar modelos de ML para aplicaciones del mundo real. Aunque es muy importante conocer bien todos los procesos y entender cómo funcionan todos estos algoritmos para tomar buenas decisiones a la hora de seleccionar el más apropiado para cada problema.

¿Qué es Deep Learning?

Dentro de Machine Learning existe una rama denominada Deep Learning (DL) que tiene un enfoque diferente a la hora de crear aprendizaje automático. Sus técnicas se basan en el uso de lo que se llaman redes neuronales artificiales. Lo de "deep" (profundo) se refiere a que las actuales técnicas son capaces de crear redes de muchas capas neuronales de profundidad, consiguiendo resultados impensables hace poco más de una década, ya que se han creado grandes avances desde el año 2010, unidos a las grandes mejoras en capacidad de cálculo.

En los últimos años se ha aplicado Deep Learning con un éxito apabullante a actividades relacionadas con el reconocimiento de voz, procesado del lenguaje, visión artificial, traducción automática, filtrado de contenidos, análisis de imágenes médicas, bioinformática, diseño de fármacos... obteniendo resultados iguales o mejores que los de humanos expertos en el campo de aplicación. Aunque no hace falta irse a cosas tan especializadas para verla en acción: desde las recomendaciones de Netflix a tus interacciones con tu asistente de voz (Alexa, Siri o el asistente de Google) pasando por las aplicaciones del móvil que te cambian la cara... todas ellas usan Deep Learning para funcionar.

En general, se suele decir (cójase con pinzas) que si la información de la que dispones es relativamente poca y el número de variables que entran en juego relativamente pequeño, las técnicas generales de ML son las más indicadas para resolver el problema. Pero si tienes enormes cantidades de datos para entrenar a la red y hay miles de variables involucradas, entonces el Deep Learning es el camino a seguir. Ahora bien, debes tener en cuenta que el DL es más difícil de implementar, lleva más tiempo entrenar a los modelos y necesita mucha más potencia de cálculo (normalmente "tiran" de GPUs, procesadores gráficos optimizados para esta tarea), pero es que los problemas normalmente son más complejos también. Para que te hagas una idea, el mítico GPT-3 utiliza 175.000 millones de parámetros entrenables.

Pero no todo son modelos gigantes. Existen redes que pueden resolver problemas avanzados (detección de objetos, atributos faciales, clasificación precisa) ejecutándose en dispositivos móviles y sistemas empotrados, como las MobileNet que pueden tener menos de 1 millón de parámetros.

¿Qué es el Big Data?

El concepto de Big data es mucho más sencillo de entender. Dicho en palabras sencillas, esta disciplina agrupa las técnicas necesarias para capturar, almacenar, homogeneizar, transferir, consultar, visualizar y analizar datos a gran escala y de manera sistemática.

Piensa por ejemplo en los datos de miles de sensores de la red eléctrica de un país que envían datos cada segundo para ser analizados, o la información generada por una red social como Facebook o Twitter con centenares (o miles) de millones de usuarios. Estamos hablando de volúmenes enormes y continuos que no son apropiados para usar con sistemas tradicionales de procesamiento de datos, como bases de datos SQL o paquetes de estadística estilo SPSS.

El Big Data se caracteriza tradicionalmente por las 3 V:

  • Volumen elevado de información. Por ejemplo, Facebook tiene 2 000 millones de usuarios y Twitter cerca de 400 millones, que están constantemente dotando de información a esas redes sociales en volúmenes elevadísimos, y es necesario almacenarla y gestionarla.
  • Velocidad: siguiendo con el ejemplo de las redes sociales, cada día Facebook recoge del orden de 1000 millones de fotos y Twitter gestiona más de 500 millones de tweets, eso sin contar likes, y muchos otros datos. El Big Data lidia con esa velocidad de recepción de datos y su procesamiento de modo que pueda fluir y ser procesada adecuadamente y sin cuellos de botella.
  • Variedad: se pueden recibir infinidad de datos de diferente naturaleza, algunos estructurados (como la lectura de un sensor, o un like) y otros desestructurados (como una imagen, el contenido de un tweet o una grabación de voz). Las técnicas de Big Data deben lidiar con todos ellos, gestionarlos, clasificarlos y homogeneizarlos.

Otro de los grandes retos asociados a la recogida de este tipo de información masiva tiene que ver con la privacidad y la seguridad de dicha información, así como la calidad de los datos para evitar sesgos de todo tipo.

Como ves, las técnicas y conocimientos necesarios para hacer Big Data no tienen nada que ver con las que se requieren para AI, ML o DL, aunque muchas veces se use el término muy a la ligera.

Estos datos pueden nutrir a los algoritmos utilizados en las técnicas anteriores, es decir, pueden ser la fuente de información de la que se nutran modelos especializados de Machine Learning o de Deep Learning. Pero también pueden ser utilizados de otras maneras, lo cual nos lleva a...

¿Qué es la ciencia de datos?

Al hablar de ciencia de datos nos referimos en muchos casos a la extracción de información relevante de los conjuntos de datos, denominado también KDD (Knowledge Discovery in Databases, descubrimiento de conocimiento en bases de datos). Utiliza diversas técnicas de muchos campos: matemáticas, programación, modelado estadístico, visualización de datos, reconocimiento y aprendizaje de patrones, modelado de incertidumbre, almacenamiento de datos y computación en la nube.

Ciencia de datos se puede referir también, de forma más amplia a los métodos, procesos y sistemas que involucran tratamiento de datos para esa extracción de conocimiento. Puede englobar desde técnicas estadísticas y de análisis de datos, hasta los modelos inteligentes que aprenden "por sí mismos" (no supervisados), lo que tocaría parte de Machine Learning también. De hecho, este término se puede confundir con minería de datos (más de moda hace unos años) o con el propio Machine Learning.

Los expertos en ciencia de datos (llamados muchas veces científicos de datos) se enfocan en la resolución de problemas que involucran datos complejos, y buscan patrones en la información, correlaciones relevantes y, en definitiva, obtener conocimientos a partir de los datos. Suelen ser expertos en matemáticas, estadística y programación (aunque no tienen que ser expertos en las tres cosas).

Al contrario que los expertos en Inteligencia Artificial (o Machine Learning o Deep Learning), que buscan la manera de generalizar la solución a problemas mediante el aprendizaje automático, los científicos de datos generan conocimientos particulares y específicos a partir de los datos de los que parten. Lo cual es una diferencia sustancial del enfoque, y de los conocimientos y de las técnicas necesarias para cada especialización.

En resumen

Como has visto en este repaso, todos estos términos tan comunes en la actualidad y muchas veces usados a la ligera, están relacionados entre sí, a veces de manera íntima, pero no son lo mismo y es necesario distinguirlos y utilizarlos con precisión.

El siguiente diagrama, que he hecho yo mismo a mano alzada a partir de las sugerencias de David Charte (que también ha revisado el artículo como experto en la materia), creo que es un buen resumen visual de todo lo que he explicado en el texto del artículo y ayuda a situar cada especialidad en relación a las demás:

Diagrama que muestra el solapamiento entre las diferentes disciplinas del artículo - Autor José M. Alarcón

Espero que estas explicaciones te hayan ayudado a aclarar conceptos y, si tienes interés en dedicarte a este mundo, a decidirte por una u otra en función de tus intereses y capacidades.

Seis aplicaciones gratuitas para aprender robótica y programación

12/10/2020
Artículo original

Seis aplicaciones gratuitas para aprender robótica y programación

Cuando uno se inicia en el mundillo de la programación, que de buenas a primeras te sitúen frente a un árido IDE, puede echar para atrás a más de uno. Eso por no mencionar lo difícil que puede resultarnos comprender algunos conceptos, para lo que en algunos casos puede resultar interesante motivarnos recurriendo a la gamificación.

En Genbeta hemos querido realizar una breve recopilación de algunas aplicaciones completamente gratuitas (bueno, se nos ha colado una freemium) que nos pueden ayudar en nuestra formación como futuros programadores:

Scratch

Scratch 3 0 Gui

Scratch es, posiblemente, el software más usado para iniciar a los niños en la programación. Se basa en un lenguaje de bloques, desarrollado por expertos del MIT, que se van combinando para formar programas.

Pese a lo que pudiera parecer por este enfoque, tan visual, y por su interfaz sencilla y colorista, Scratch es un lenguaje de programación potente que ha permitido desarrollar proyectos complejos.

Está disponible en formato plataforma web y como software de escritorio para Windows y Mac. No nos obliga a registrarnos, aunque este paso será útil si queremos ir guardando nuestros proyectos.

Snap!

Snap!

En base al código de Scratch, investigadores de la Universidad de Berkley crearon Snap!, un 'fork' de ese lenguaje con el objetivo de que fuera de ayuda para iniciar en la programación a usuarios algo más mayores (de instituto y niveles universitarios).

Usando una interfaz y un lenguaje visual tremendamente similares a los de su antecesor, Snap implementa nuevas funcionalidades, como la opción de crear nuevos bloques de instrucciones o de usar listas avanzadas capaces de almacenar casi cualquier tipo de dato (incluyendo otras listas o instrucciones listas para ser ejecutadas).

PSeInt

Pseint

PSeInt es un intérprete de pseudocódigo, un falso lenguaje que nos permite aprender conceptos básicos de programación aplicable a varios lenguajes y, además, recurriendo para ellos a la lengua materna del estudiante.

PSeInt es el recurso favorito (por falta de alternativas, también es verdad) para que los hispanohablantes podamos recurrir al pseudocódigo en nuestro idioma, y usando un programa que imita los IDE profesionales, con sus funciones de coloreado de sintáxis, detección de errores e, incluso, de ejecución del código.

Uno de sus mayores atractivos es que nos da la opción de convertir determinados algoritmos de pseucódigo al código equivalente en varios lenguajes de programación populares (C, C++, C#, Java, JavaScript, PHP, Python o Visual Basic entre ellos).

Robocode

Robocode

Robocode es un videojuego multiplataforma (Windows, Mac, Linux, BSD) que se lanzó al mercado hace ya 20 años, con un objetivo muy claro: crear un tanque que nos permita machacar a los de nuestros adversarios. Pero, ¿cómo nos ayuda esto a aprender programación o robótica?

Muy sencillo: nosotros no manejamos a nuestro tanque durante la partida, sino que debemos haber realizado el trabajo duro previamente, codificando el 'comportamiento' del mismo para que sepa cuándo moverse, cuándo disparar y cómo detectar y evitar al resto de tanques. Para ello podremos programar por separado el cuerpo del robot, su cañón y su radar.

Para esta labor de programación, deberemos recurrir a lenguajes como Java, C# y Scala, pudiendo empezar con códigos tremendamente simples y avanzar hasta dominar técnicas de inteligencia artificial. Robocode es en sí mismo un IDE completo, con editor de código, editor de robots u compilador.

CodeCombat

CodeCombat

CodeCombat es, como Robocode, un videojuego al que se juega a base de programar códdigo usando lenguajes informáticos reales (como Python, JavaScript y HTML).

Se trata de una plataforma online freemium (cuyos primeros 110 niveles son gratuitos) y que se dirige a niños a partir de 9 años, sin necesidad de que cuenten con conocimientos de programación previos.

Bajo la forma de un juego de rol/estrategia de ambientación fantástica y estética cartoon, deberemos controlar a un mago cuyos hechizos se componen de código de programación.

Colobot: Gold Edition

Colobot

'Colobot: Gold Edition' es un videojuego, disponible para Windows y Linux, lanzado después de que los desarrolladores originales de 'Colobot' (lanzado en 2001) liberasen su código.

En este juego 3D de estrategia en tiempo real encarnamos un astronauta que debe realizar misiones en diversos planetas auxiliado por robots. Dichos robots deberán ser programados por nosotros utilizando un lenguaje propio, CBOT, que es, sin embargo, muy similar a Java y C++.

Imagen | EU2017EE Estonian Presidency

6 consejos para mejorar el plan de formación de un programador

09/10/2020
Artículo original

Para retener y maximizar el potencial creativo de los buenos desarrolladores, es necesario implementar programas de formación exhaustivos, orientados a la especificidad y adaptados a las necesidades de cada profesional.

Los departamentos de recursos humanos que trabajan con desarrolladores de software se enfrentan a un enorme desafío repleto de oportunidades, pero también de dificultades. Los programadores de software son competitivos y creativos por naturaleza.

Llegan a los nuevos puestos de trabajo decididos a arrasar con el mundo y si se aprovecha el gran potencial que poseen, las empresas se pueden beneficiar enormemente de ello. Pero si no se les capacita en la medida apropiada, es posible que se vayan a buscar horizontes más prometedores.

La importancia de un buen plan formativo

Los desarrolladores de software poseen habilidades extraordinariamente rentables. Pero son perfiles muy demandados y si no les das la oportunidad de desarrollar sus aptitudes, encontrarán a otro que sí lo haga.

Esto puede suponer un gran problema para la empresa, ya que los costes de reclutamiento y formación de los sustitutos de los desarrolladores de software que se han ido pueden ser muy elevados, especialmente si este ciclo se repite mucho en el tiempo y hay mucha rotación de personas.

Los programas de formación, además de ser útiles y eficaces, también tienen que causar una buena impresión en las personas a las que estás formando.

Cualquier cosa que se haga en nombre de la empresa tiene que hacer que los empleados se sientan valorados. Si la formación que se les ofrece es mediocre, es mejor no ofrecerla, ya que los empleados sentirán que no son importantes o que se les infravalora.

A continuación presentamos algunos consejos que pueden servir para perfeccionar los programas de formación para programadores existentes y aumentar su eficacia y relevancia:

1. No usar enfoques de formación estándar

Imagen ornamental por Neven Krcmarek, CC0 en Unsplash

Las personas tienen personalidades diferentes, y eso es algo que debe ser respetado. Los introvertidos son un grupo muy bien representado entre los desarrolladores de software, pero también existen perfiles extrovertidos, y perfiles de todo tipo. Algunas personas manejan bien la crítica constructiva, mientras que otras se ven profundamente afectadas por la más leve regañina. Unos prefieren los cursos online y otros la formación en formato bootcamp o mediante cursos presenciales.

Puede que no sea evidente de inmediato en qué lugar del espectro de características de la personalidad se encuentran los desarrolladores a los que se tiene que formar. Pero si se presta una atención detenida a lo largo del tiempo, se obtienen pistas, y es prudente ajustar tanto el enfoque como las expectativas de cada individuo en función de las observaciones que se hagan. Además, lo mejor siempre es explicar la visión de la empresa y luego preguntar y escuchar sus preferencias.

Desde campusMVP pensamos que la formación online tutorizada es la mejor forma de aprender a programar y la mejor forma de tener un plan de formación continua para el 80% de los desarrolladores. Pero evidentemente entendemos que hay perfiles para todo y que hay personas que prefieren la formación presencial, aún siendo menos eficiente y productiva. salvo para cursos muy cortos y especializados.

2. Incluir estrategias de seguimiento y motivación

Aunque la personalidad de cada persona es diferente, la necesidad humana de refuerzo positivo es casi universal. Puede que no sea aparente a primera vista, pero muchos desarrolladores de software carecen de confianza en sí mismos y se sienten algo intimidados por los compañeros de trabajo a los que temen que sean más innovadores y creativos que ellos.

Por esta razón, es importante dar reconocimiento a los progresos de los programadores formados a medida que se van produciendo, para mejorar la imagen que tienen de sí mismos y que adquieran una mayor seguridad cuando se les pide que completen tareas cada vez más complicadas.

Por supuesto, es posible que haya algunos alumnos que estén sumamente seguros de sí mismos y que no necesiten elogios ni estímulos para rendir mejor. No obstante, apreciarán ser reconocidos por su nivel de excelencia y tendrán una mejor opinión la empresa cuando se les otorgue el reconocimiento adecuado.

Para ello, los cursos online de campusMVP ofrecen unas herramientas de seguimiento y de evaluación que sirven para que los responsables de recursos humanos estén al tanto, incluso en tiempo real, de los avances de los programadores que se forman. Esto en un curso intensivo presencial es casi imposible de monitorizar.

3. Dar a los desarrolladores de software la oportunidad de aprender más acerca de la ingeniería y la arquitectura de software

Los buenos desarrolladores de software sienten una profunda curiosidad por su profesión, y muchos esperan algún día hacer la transición a ingeniería o a arquitectura de software.

A las empresas les conviene satisfacer este deseo y ayudar a sus desarrolladores a saciar su necesidad de ampliar su base de conocimientos, ya que los programadores comprometidos son los más centrados y los que están más centrados son los que tienen un mejor rendimiento y una mayor productividad.

Los desarrolladores de software más versátiles y completos son un activo para la organización en el futuro: cuando se necesite contratar a nuevos ingenieros o arquitectos, se podrán promocionar desde dentro, ahorrando a la empresa mucho dinero en el proceso, y todo será mérito del departamento de recursos humanos.

4. Encuestas internas sobre formación

Se deberían realizar encuestas internas a los desarrolladores de software para obtener información sobre los programas de formación actuales y para saber cómo se pueden ampliar o modificar.

La encuesta podría ser anónima o basarse en conversaciones privadas y cara a cara, dependiendo de las preferencias de los empleados y del afán por generar una mayor confianza por parte de la empresa.

Los resultados de las encuestas se deben tener en cuenta a la hora de planificar la formación de los programadores, pero no debe ser el único criterio que debe tenerse en cuenta. Los intereses de la empresa, como por ejemplo poder implementar un plan sostenible en el tiempo, también se deben tener en cuenta.

En campusMVP manejamos también encuestas de satisfacción de los alumnos de nuestros cursos, con miles de datos recibidos, que también nos dan una información muy valiosa para saber qué funciona y qué no. Somos las propias empresas de formación especializadas en programadores las más indicadas para ofrecer asesoramiento en todo este proceso, ya que trabajamos con muchas empresas de desarrollo y podemos trasladar todo este conocimiento en temas de formación continua a tu empresa.

5. Ceñirse a formación dirigida por un tutor, ya que es más efectiva y de mejor calidad que los cursos enlatados en vídeo

El mayor problema de los cursos enlatados y la formación online en general es que se vuelven muy impersonales, por muy bueno que sea el profesor que haya hecho el curso.

La única forma de subsanar este inconveniente es contando con un tutor que te guíe y te ayude a avanzar. Por no cualquier tutor. Lo óptimo es que dicho tutor sea la misma persona que ha diseñado y elaborado el curso de programación en cuestión, alguien con experiencia en la tecnología y en formación online, y no un tutor anónimo de los de 9 a 3 y 4 a 7 que lo mismo tutelan un curso de Excel que uno de programación avanzada.

Nadie mejor que un verdadero experto podrá resolver tus dudas. La información directa y en tiempo real que los estudiantes reciben de los instructores es sumamente útil, personalizada y un elemento vital en el proceso de aprendizaje.

6. Las sesiones formativas deberían ser periódicas y relevantes

Los desarrolladores dan por hecho que se tienen que formar constantemente. Como empresa se debe fomentar este hábito y no dejar pasar ni un solo año sin ofrecerle formación a sus programadores planes formativos.

Dados los rápidos cambios en el desarrollo de software, ¿cómo se puede esperar que los desarrolladores se mantengan al día con la tecnología si sus empleadores no son lo suficientemente proactivos para facilitar el proceso?

Los desarrolladores de software tienden a pasar mucho tiempo leyendo y actualizándose sobre los cambios en la industria por su cuenta, pero si se pone toda la carga sobre sus hombros, los programadores insatisfechos verán comprometida su capacidad de mejorar su rendimiento por su incapacidad de estar al día de los cambios en su profesión.

Conclusión

Si como empresa se va a buscar un curso online de programación, se debe buscar uno que compense el esfuerzo y la dedicación y que te garantice un aprendizaje profundo de la materia en un tiempo concreto. Se trata de encontrar un socio que ayude a formar a los programadores de la empresa durante sus trayectorias profesionales.

 

Página Siguiente