<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>.net on Lo Crestià</title><link>https://www.eiximenis.dev/categories/.net/</link><description>Recent content in .net on Lo Crestià</description><generator>Hugo -- gohugo.io</generator><language>es</language><copyright>{}</copyright><lastBuildDate>Thu, 27 Jun 2019 09:22:03 +0000</lastBuildDate><atom:link href="https://www.eiximenis.dev/categories/.net/index.xml" rel="self" type="application/rss+xml"/><item><title>gRPC y "no gRPC" todo junto en el mismo proyecto</title><link>https://www.eiximenis.dev/posts/2019-06-27-grpc-y-no-grpc-todo-junto-en-el-mismo-proyecto/</link><pubDate>Thu, 27 Jun 2019 09:22:03 +0000</pubDate><atom:modified>Thu, 27 Jun 2019 09:22:03 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2019-06-27-grpc-y-no-grpc-todo-junto-en-el-mismo-proyecto/</guid><description>&lt;p>Una de las novedades que incluye Net Core 3 es el soporte para gRPC. ¿No conoces gRPC? Bueno, pues básicamente se trata del RPC de toda la vida, pero vestido a la moda, duchado y perfumado. Vamos, si te lees los puntos principales de la &lt;a href="https://grpc.io/">página oficial de gRPC&lt;/a> (definición de servicio independiente del lenguaje, soporte de muchos lenguajes, streaming bi-direccionales) es como si volvieses unos cuantos años atrás y &lt;a href="https://blog.mattmags.com/2011/05/19/don-box-the-bathtub-lecture/">Don Box estuviese en la bañera&lt;/a> vendiéndote SOAP. Y de todos modos, cuando hablábamos de &lt;a href="https://es.wikipedia.org/wiki/Simple_Object_Access_Protocol">SOAP&lt;/a> ya era difícil no acordarse de CORBA (ya fuese &lt;a href="https://es.wikipedia.org/wiki/CORBA">el estándard&lt;/a> o &lt;a href="https://es.wikipedia.org/wiki/Modelo_de_Objetos_de_Componentes_Distribuidos">el de Microsoft&lt;/a> xD).&lt;/p></description><dc:creator>eiximenis</dc:creator><category>grpc</category><category>.net</category><category>asp.net core</category></item><item><title>Terminales y millones de colores: una historia complicada</title><link>https://www.eiximenis.dev/posts/2019-04-05-terminales-y-millones-de-colores-una-historia-complicada/</link><pubDate>Fri, 05 Apr 2019 17:28:27 +0000</pubDate><atom:modified>Fri, 05 Apr 2019 17:28:27 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2019-04-05-terminales-y-millones-de-colores-una-historia-complicada/</guid><description>&lt;p>Los que más o menos me seguís por &lt;a href="https://twitter.com/eiximenis">Twitter&lt;/a>, quizá os habréis enterado de que estoy escribiendo una &lt;a href="https://github.com/eiximenis/tvision2">librería &lt;em>cross-platform&lt;/em> (netstandard2) para desarrollar aplicaciones de consola&lt;/a>. Evidentemente &lt;a href="https://github.com/migueldeicaza/gui.cs">no es la única&lt;/a>, es simplemente otra más y puedo asegurar que me lo paso genial desarrollándola.&lt;/p>
&lt;p>Uno de los objetivos principales cuando empecé &lt;strong>era permitir usar true color&lt;/strong> (es decir 16 millones de colores) en aquellos terminales que lo soportan y la verdad es que la historia del soporte de colores en terminales da para un post&amp;hellip; y aquí estamos 😉&lt;/p></description><dc:creator>eiximenis</dc:creator><category>.net</category><category>consola</category><category>netcore</category></item><item><title>Comparaciones en C#</title><link>https://www.eiximenis.dev/posts/2018-12-17-comparaciones-en-c/</link><pubDate>Mon, 17 Dec 2018 07:00:28 +0000</pubDate><atom:modified>Mon, 17 Dec 2018 07:00:28 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2018-12-17-comparaciones-en-c/</guid><description>&lt;p>¡Buenas!&lt;/p>
&lt;p>Este &lt;em>post&lt;/em> pertenece al “&lt;a href="https://aspnetcoremaster.com/c%23/advientocsharp/2018/11/16/Calendario-adviento-csharp.html">calendario de adviento de C#&lt;/a>“, y me gustaría hablaros de un tema que parece sencillo pero que bueno, esconde sus cosillas. En concreto sobre &lt;strong>comparaciones en C#&lt;/strong>.&lt;/p></description><dc:creator>eiximenis</dc:creator><category>.net</category><category>C#</category></item><item><title>C#: Structs de un solo campo como typedefs</title><link>https://www.eiximenis.dev/posts/2018-11-16-c-structs-de-un-solo-campo-como-typedefs/</link><pubDate>Fri, 16 Nov 2018 09:21:26 +0000</pubDate><atom:modified>Fri, 16 Nov 2018 09:21:26 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2018-11-16-c-structs-de-un-solo-campo-como-typedefs/</guid><description>No hace mucho me preguntaba si usar structs de un solo campo tenía alguna penalización respecto a usar, simplemente, una variable del tipo del campo. Es decir, me preguntaba si tener:
struct Sint { public int value; } Tenía alguna penalización al respecto de usar, simplemente, una variable int.
A nivel de memoria sospechaba que no: una struct ocupa lo mismo que la suma de todos sus campos, más los paddings que se agregan para que los campos estén alineados, más el padding final que se agrega para que, en el caso de un array, los elementos estén alineados.</description><dc:creator>eiximenis</dc:creator><category>.net</category><category>C#</category></item><item><title>Unicode y encodings</title><link>https://www.eiximenis.dev/posts/2018-10-01-unicode-y-encodings/</link><pubDate>Mon, 01 Oct 2018 09:40:40 +0000</pubDate><atom:modified>Mon, 01 Oct 2018 09:40:40 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2018-10-01-unicode-y-encodings/</guid><description>&lt;p>Uno de los conceptos que hoy en día siguen causando más confusión es el de Unicode y sus distintos tipos de codificación. Pero&amp;hellip; ¿qué es realmente Unicode? Para ello, déjame que remonte unos cuantos años atrás&amp;hellip;&lt;/p>
&lt;p>&lt;strong>El inicio: ASCII&lt;/strong>&lt;/p>
&lt;p>Los ordenadores los inventaron los americanos y como suele ocurrir se preocuparon de lo suyo: que un ordenador pudiese presentar textos en su idioma. Tampoco hay tantos caracteres en el inglés: las veinte y poco letras (en mayúsculas y minúsculas), los símbolos de puntuación, paréntesis, operaciones matemáticas y poco más. En total eran menos de 128 carácteres. Genial, porque esos espacios que sobraban se podían aprovechar para colocar otros caracteres que no tienen representación gráfica pero que eran (y son) necesarios para controlar el teletipo: retornos de carro, saltos de línea y similares. Había nacido el &lt;a href="https://en.wikipedia.org/wiki/ASCII">código ASCII&lt;/a>.&lt;/p></description><dc:creator>eiximenis</dc:creator><category>unicode</category><category>.net</category></item><item><title>Azure Functions y SignalR: serverless push</title><link>https://www.eiximenis.dev/posts/2018-09-06-azure-functions-y-signalr-serverless-push/</link><pubDate>Thu, 06 Sep 2018 09:11:46 +0000</pubDate><atom:modified>Thu, 06 Sep 2018 09:11:46 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2018-09-06-azure-functions-y-signalr-serverless-push/</guid><description>&lt;p>El hecho de ofrecer SignalR como servicio PaaS en Azure y su integración con Azure Functions nos abre un escenario interesante: ahora es facilísimo hacer notificaciones &lt;em>push&lt;/em> desde una Azure Function (AF) a un cliente SignalR (p. ej. una Web).&lt;/p></description><dc:creator>eiximenis</dc:creator><category>af</category><category>azure functions</category><category>signalr</category><category>.net</category><category>serverless</category></item><item><title>Novedades .NET Core 2.1: Generic host</title><link>https://www.eiximenis.dev/posts/2018-06-07-novedades-net-core-2-1-generic-host/</link><pubDate>Thu, 07 Jun 2018 11:04:55 +0000</pubDate><atom:modified>Thu, 07 Jun 2018 11:04:55 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2018-06-07-novedades-net-core-2-1-generic-host/</guid><description>&lt;p>Ahora que .NET Core 2.1 ya es oficial ya podemos desgranar algunas de sus novedades más interesantes. La verdad es que, por fin, se vislumbra una madurez en la plataforma. Realmente a no ser que haya algún motivo de fuerza mayor (librería no disponible), .NET Core 2.1 debería ser la opción &lt;em>por defecto&lt;/em> a la hora de empezar cualquier proyecto nuevo.&lt;/p></description><dc:creator>eiximenis</dc:creator><category>.net</category><category>asp.net 5</category></item><item><title>Sobre NuGet y versiones…</title><link>https://www.eiximenis.dev/posts/2017-06-28-sobre-nuget-y-versiones/</link><pubDate>Wed, 28 Jun 2017 11:51:21 +0000</pubDate><atom:modified>Wed, 28 Jun 2017 11:51:21 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2017-06-28-sobre-nuget-y-versiones/</guid><description>&lt;p>Que NuGet ha supuesto una revolución en .NET es más que evidente. Lejos han quedado aquellos tiempos en que gestionábamos las dependencias como podíamos. Poco a poco el modelo de desarrollo está migrando de estar basado en “dependencias a ensamblados” a “dependencias a paquetes”, y a medida que netcore vaya teniendo una mayor relevancia esto irá a más.&lt;/p>
&lt;p>Pero esta gestión semi-automatizada de las dependencias también trae sus propios quebraderos de cabeza…&lt;/p>
&lt;p>En nodejs es muy común hablar del “&lt;em>npm hell&lt;/em>” o el infierno que puede suponer la gestión de paquetes usando npm. Que al cabo de un tiempo alguien se baje el código de tu repositorio y que no le funcione o bien que actualices un paquete y se terminen rompiendo 400 más, es algo muy (demasiado) habitual. ¿Tenemos en .NET un &lt;em>nuget hell&lt;/em>?&lt;/p></description><dc:creator>eiximenis</dc:creator><category>.net</category></item><item><title>Algunas consideraciones sobre las structs</title><link>https://www.eiximenis.dev/posts/2016-07-27-algunas-consideraciones-sobre-las-structs/</link><pubDate>Wed, 27 Jul 2016 19:48:11 +0000</pubDate><atom:modified>Wed, 27 Jul 2016 19:48:11 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2016-07-27-algunas-consideraciones-sobre-las-structs/</guid><description>&lt;p>El otro día un tweet de &lt;a href="https://twitter.com/jc_quijano" target="_blank" rel="noopener noreferrer">Juan Quijano&lt;/a>, animó una pequeña discusión sobre la diferencia entre clases y estructuras en .NET. Este no es el primer post que escribo al respecto, pero bueno, aprovechando la coyuntura vamos a comentar algunas de las cosas que se mencionaron en el pequeño debate que generó &lt;a href="https://twitter.com/jc_quijano/status/757967853970722817" target="_blank" rel="noopener noreferrer">el tweet de Juan&lt;/a>.&lt;/p></description><dc:creator>eiximenis</dc:creator><category>.net</category><category>C#</category></item><item><title>netstandard–El “estándar” que viene</title><link>https://www.eiximenis.dev/posts/2016-04-25-netstandardel-estndar-que-viene/</link><pubDate>Mon, 25 Apr 2016 10:00:59 +0000</pubDate><atom:modified>Mon, 25 Apr 2016 10:00:59 +0000</atom:modified><guid>https://www.eiximenis.dev/posts/2016-04-25-netstandardel-estndar-que-viene/</guid><description>&lt;p>Cuando .NET salió, las cosas eran muy sencillas: había una sola versión de .NET, el .NET Framework, así que como mucho debíamos saber para que versión de .NET era una determinada librería. “Oh, la librería es solo para .NET 2.0 y yo uso .NET 1.1, que mala suerte”. Al margen de eso no había mucho más, todos teníamos claro que significaba .NET.&lt;/p></description><dc:creator>eiximenis</dc:creator><category>.net</category></item></channel></rss>