lunes, 21 de septiembre de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- Parsing Microsoft Word document using C#
Ipinder Suri - C#6: Support for .NET Framework 2.0 to 4.5
Jeff Yates - Local Machine Interprocess Communication with .NET
Ricardo Peres - Regular Expression Character Classes
Richard Carr - Supporting Options and Arguments in Your dnx Commands
James Chambers - Top 15 Underutilized Features of .NET part I & part II
Anton Angelov
Publicado por José M. Aguilar a las 9:15 a. m.
Nadie ha comentado la entrada, ¿quieres ser el primero?
Etiquetas: enlaces
martes, 15 de septiembre de 2015
Seguimos hablando de ASP.NET Core y los cambios que traerá para los desarrolladores que ya llevamos tiempo utilizando ASP.NET y MVC, porque esta nueva versión viene cargada de cambios y algunos son realmente rompedores. Hoy nos centraremos en un cambio simple, pero bastante importante, que afecta a la estructura de nuestros proyectos: el raíz del sitio web.
Desde siempre el directorio raíz de un proyecto ASP.NET, ya fuera Web Forms, MVC, Web API o cualquier otro, coincidía con la raíz del sitio web en el servidor, es decir, en nuestros equipos se mezclaban los archivos propios del desarrollo con los contenidos estáticos que se subían posteriormente a los entornos de prueba o producción.
Esto creaba un poco de lío a la hora de publicar los proyectos, porque era fácil que nos dejáramos algo por detrás a la hora de subir las aplicaciones al servidor, o que enviáramos más archivos de la cuenta, como archivos .JS sin compactar/empaquetar, fuentes Typescript, estilos Less o Sass, mapas de símbolos, etc. Obviamente esto podía causar problemas de seguridad, puesto que podíamos dejar al descubierto aspectos sensibles de la aplicación y era necesario establecer configuraciones que evitaran la descarga de dichos archivos (por ejemplo, evitar el acceso a archivos .config).
A partir de ASP.NET Core esto deja de ser así, y la carpeta raíz del proyecto contendrá exclusivamente archivos relativos al desarrollo del mismo: fuentes C#, Javascript, Typescript, Less, Sass, archivos de configuración, etc.
En cambio, los archivos estrictamente necesarios en runtime (imágenes, bundles de scripts y CSS, HTML, etc.) deberán encontrarse en la carpeta “wwwroot” que cuelga del raíz y que podemos observar en la captura de pantalla adjunta con un icono circular.
En otras palabras, una vez despleguemos la carpeta “wwwroot” al servidor, ésta será la raíz del sitio web, por lo que sólo los archivos contenidos en ella serán accesibles.
Esto presenta varios cambios interesantes. En primer lugar, el hecho de separar los archivos útiles en tiempo de desarrollo de los que van a explotación, hace que podamos despreocuparnos de problemas de seguridad citados anteriormente, porque es más difícil que queden expuestos ficheros con información sensible.
En segundo lugar, ahora podremos tener el raíz de nuestro proyecto mejor organizado porque ya no tenemos necesidad de hacer coincidir la estructura del código fuente con la del sitio en funcionamiento. Estructuraremos nuestro código fuente de la forma que más nos convenga para facilitar su creación y mantenimiento, e idearemos una estructura para explotación más acorde con las necesidades en tiempo de ejecución.
Y por último, este nuevo enfoque hace que encajen a la perfección herramientas como Gulp o Grunt, que nos permitirán automatizar tareas como la copia, comprobación, transformación o empaquetado de archivos. Por ejemplo, podemos utilizar Gulp en cada compilación para que se tomen los archivos Javascript de una carpeta determinada del código fuente del proyecto, combinarlos, minimizarlos y copiarlos posteriormente a su ubicación final dentro de “wwwroot”.
¿Y cómo se ve esto en un servidor donde se esté ejecutando el proyecto? Pues la siguiente captura de pantalla muestra el resultado de desplegar una aplicación ASP.NET Core a un servidor, de Azure en este caso.
En la carpeta “Files”, que es donde Azure muestra el contenido físico del espacio donde se guardan los archivos que hemos subido, observamos dos carpetas “approot” y “wwwroot”.
La primera de ellas, “approot”, contiene los paquetes Nuget de componentes usados por la aplicación, los runtimes (DNX, distribuidos también como paquetes Nuget) y algunos archivos de configuración. Adicionalmente, así lo hemos indicado al publicar el proyecto, podemos incluso encontrar el código fuente de la aplicación.
La carpeta “wwwroot”, que es la que actúa como raíz del sitio web, es donde encontramos los archivos estáticos requeridos por el sitio web. No es posible, por tanto, acceder a través de la web a ninguno de los archivos usados en tiempo de diseño.
Es importante tener en cuenta que este comportamiento se aplica también a la ejecución local. Ya sea desde Visual Studio pulsando F5 o Ctrl-F5, o bien desde línea de comandos (por ejemplo, usando el comando “dnx web”), siempre que ejecutemos la aplicación lo estaremos haciendo sobre la carpeta raíz “wwwroot”.
En estos casos lo primero es renombrar físicamente la carpeta “wwwroot” y ponerle el nombre que más nos guste. Tras ello, basta indicar a ASP.NET Core dónde puede encontrar la raíz de la aplicación, que, como otros muchos aspectos de la configuración, se define en el archivo de configuración project.json.
Así, basta con modificar con cualquier editor el valor de la propiedad “webroot” en el archivo project.json y hacerlo coincidir con el nombre que hemos elegido para la carpeta. Si usamos Visual Studio, en pocos segundos veremos el proyecto actualizado:
Publicado en Variable not found.
Desde siempre el directorio raíz de un proyecto ASP.NET, ya fuera Web Forms, MVC, Web API o cualquier otro, coincidía con la raíz del sitio web en el servidor, es decir, en nuestros equipos se mezclaban los archivos propios del desarrollo con los contenidos estáticos que se subían posteriormente a los entornos de prueba o producción.
Esto creaba un poco de lío a la hora de publicar los proyectos, porque era fácil que nos dejáramos algo por detrás a la hora de subir las aplicaciones al servidor, o que enviáramos más archivos de la cuenta, como archivos .JS sin compactar/empaquetar, fuentes Typescript, estilos Less o Sass, mapas de símbolos, etc. Obviamente esto podía causar problemas de seguridad, puesto que podíamos dejar al descubierto aspectos sensibles de la aplicación y era necesario establecer configuraciones que evitaran la descarga de dichos archivos (por ejemplo, evitar el acceso a archivos .config).
A partir de ASP.NET Core esto deja de ser así, y la carpeta raíz del proyecto contendrá exclusivamente archivos relativos al desarrollo del mismo: fuentes C#, Javascript, Typescript, Less, Sass, archivos de configuración, etc.
En cambio, los archivos estrictamente necesarios en runtime (imágenes, bundles de scripts y CSS, HTML, etc.) deberán encontrarse en la carpeta “wwwroot” que cuelga del raíz y que podemos observar en la captura de pantalla adjunta con un icono circular.
En otras palabras, una vez despleguemos la carpeta “wwwroot” al servidor, ésta será la raíz del sitio web, por lo que sólo los archivos contenidos en ella serán accesibles.
Esto presenta varios cambios interesantes. En primer lugar, el hecho de separar los archivos útiles en tiempo de desarrollo de los que van a explotación, hace que podamos despreocuparnos de problemas de seguridad citados anteriormente, porque es más difícil que queden expuestos ficheros con información sensible.
En segundo lugar, ahora podremos tener el raíz de nuestro proyecto mejor organizado porque ya no tenemos necesidad de hacer coincidir la estructura del código fuente con la del sitio en funcionamiento. Estructuraremos nuestro código fuente de la forma que más nos convenga para facilitar su creación y mantenimiento, e idearemos una estructura para explotación más acorde con las necesidades en tiempo de ejecución.
Y por último, este nuevo enfoque hace que encajen a la perfección herramientas como Gulp o Grunt, que nos permitirán automatizar tareas como la copia, comprobación, transformación o empaquetado de archivos. Por ejemplo, podemos utilizar Gulp en cada compilación para que se tomen los archivos Javascript de una carpeta determinada del código fuente del proyecto, combinarlos, minimizarlos y copiarlos posteriormente a su ubicación final dentro de “wwwroot”.
¿Y cómo se ve esto en un servidor donde se esté ejecutando el proyecto? Pues la siguiente captura de pantalla muestra el resultado de desplegar una aplicación ASP.NET Core a un servidor, de Azure en este caso.
En la carpeta “Files”, que es donde Azure muestra el contenido físico del espacio donde se guardan los archivos que hemos subido, observamos dos carpetas “approot” y “wwwroot”.
La primera de ellas, “approot”, contiene los paquetes Nuget de componentes usados por la aplicación, los runtimes (DNX, distribuidos también como paquetes Nuget) y algunos archivos de configuración. Adicionalmente, así lo hemos indicado al publicar el proyecto, podemos incluso encontrar el código fuente de la aplicación.
La carpeta “wwwroot”, que es la que actúa como raíz del sitio web, es donde encontramos los archivos estáticos requeridos por el sitio web. No es posible, por tanto, acceder a través de la web a ninguno de los archivos usados en tiempo de diseño.
Es importante tener en cuenta que este comportamiento se aplica también a la ejecución local. Ya sea desde Visual Studio pulsando F5 o Ctrl-F5, o bien desde línea de comandos (por ejemplo, usando el comando “dnx web”), siempre que ejecutemos la aplicación lo estaremos haciendo sobre la carpeta raíz “wwwroot”.
Cómo cambiar el nombre a la carpeta wwwroot
Si no os gusta el nombre “wwwroot” y preferís algo más castizo, sin problema, está previsto ;)
Nota 26/01/2016: todo lo que se cuenta en este apartado ha cambiado en las versiones finales. Hay un post más actualizado aquí.
En estos casos lo primero es renombrar físicamente la carpeta “wwwroot” y ponerle el nombre que más nos guste. Tras ello, basta indicar a ASP.NET Core dónde puede encontrar la raíz de la aplicación, que, como otros muchos aspectos de la configuración, se define en el archivo de configuración project.json.
Así, basta con modificar con cualquier editor el valor de la propiedad “webroot” en el archivo project.json y hacerlo coincidir con el nombre que hemos elegido para la carpeta. Si usamos Visual Studio, en pocos segundos veremos el proyecto actualizado:
Publicado en Variable not found.
lunes, 14 de septiembre de 2015
Tras el parón vacacional, ya estamos de vuelta totalmente recargados y listos para afrontar con energías la nueva temporada, que va teniendo pinta de ser muy intensa en todos los sentidos.
Y para celebrarlo como se merece, ahí va la primera colección de enlaces recopilados durante las últimas semanas, que como siempre espero que os resulten interesantes :-)
.Net
- Regular Expression Character Escapes
Richard Carr - Distributed Concurrent Actor Models with Akka.NET
Jason Roberts - Top 15 Hidden Features of C# Part 2
Anton Angelov - Nullable comparisons are weird
Eric Lippert - What's New in C# 6.0
Fiyaz Hasan - C# Proposal: Nullable reference types and nullability checking
Mads Torgersen
miércoles, 29 de julio de 2015
Y de nuevo llegó la mejor época del año, una de las escasas ocasiones en las que podemos separarnos un poco de de las pantallas y dedicarnos a disfrutar de lo que hay fuera, eso que algunos llaman mundo real :) Toca desconectar un poco, oxigenarse y recargar pilas, que ya va siendo hora.
Variable not found quedará a la deriva hasta septiembre, cuando volveremos listos para afrontar la nueva temporada, que promete ser intensa :)
Felices vacaciones, nos vemos a la vuelta!!
Variable not found quedará a la deriva hasta septiembre, cuando volveremos listos para afrontar la nueva temporada, que promete ser intensa :)
Felices vacaciones, nos vemos a la vuelta!!
martes, 28 de julio de 2015
Junto con la gran oleada de novedades y lanzamientos a los que asistimos la semana pasada, se publicaron también los planes oficiales que hay para los futuros lanzamientos ASP.NET Core y Core MVC.
Aunque algunos miembros del equipo habían ido adelantando pistas bastante clarificadoras, e incluso el amigo José Manuel Alarcón ya había publicado al respecto, hasta ahora no podíamos decir que tuviéramos información pública, casi totalmente precisa y de primera mano. Pero por fin ha llegado, y como era de esperar, a través del repositorio oficial del proyecto en Github.
Resumidamente, así está la planificación a día de hoy para ASP.NET Core y MVC:
Publicado en Variable not found.
Aunque algunos miembros del equipo habían ido adelantando pistas bastante clarificadoras, e incluso el amigo José Manuel Alarcón ya había publicado al respecto, hasta ahora no podíamos decir que tuviéramos información pública, casi totalmente precisa y de primera mano. Pero por fin ha llegado, y como era de esperar, a través del repositorio oficial del proyecto en Github.
Resumidamente, así está la planificación a día de hoy para ASP.NET Core y MVC:
- La Beta 6 estaba prevista para ayer, 27 de julio de 2015, aunque por temas de última hora este lanzamiento se ha pospuesto un día; de hecho, es posible que en el momento en que estéis leyendo esto haya sido ya publicada o estén a punto de hacerlo. Sus principales novedades serán el soporte para localización, la posibilidad de targeting para .NET 4.6, buffering y caching de resultados, caché distribuido a través de SQL Server, y algunas otras características.
- La Beta 7, prevista para el 24 de agosto, estará centrada en el desarrollo multiplataforma sobre .NET Core. Se lanzarán los entornos de ejecución para Mac y Linux, facilitando los workflows básicos del desarrollador y la descarga e instalación de los componentes.
- La Beta 8 se lanzará el 21 de septiembre y será la última en la que se añadan features. Se centrará también en la integración con VS y VS Code.
- A partir de este momento, el producto entrará en una fase de estabilización y mejora de fiabilidad y rendimiento. La primera versión candidata, ASP.NET Core RC 1 se lanzará en noviembre de 2015, siendo la primera distribución production-ready y cross-platform completa. Dependiendo del feedback, ya se verá si se lanzan RC posteriores hasta llegar a la RTM.
- La versión RTM de ASP.NET Core/MVC no verá la luz hasta el primer trimestre de 2016. Esto quiere decir que, si la cosa no se retrasa, podríamos tener estas tecnologías disponibles a finales de marzo.
- Tras ello, se espera la llegada de otros temas que no podrán ser incluidos en la RTM, como el soporte para Visual Basic, SignalR o Web Pages. En el roadmap estiman que estos temas se retrasarán hasta el Q3, es decir, que no habrá novedades al respecto hasta verano de 2016.
Publicado en Variable not found.
lunes, 27 de julio de 2015
Ahí van los enlaces recopilados durante la semana pasada, algo escasos por el espíritu vacacional que me tiene ya poseído ;D y muy protagonizados por los lanzamientos de nuevos productos y plataformas de la semana pasada.
Espero que os resulten interesantes :-)
Espero que os resulten interesantes :-)
.Net
- Roslyn and Mono
Miguel de Icaza - .NET Strings are immutable … except that they’re not
Rick Brewster - StructureMap in 2015/16
Jeremy Miller - Is that image a photo?
Robin Osborne - Tasks, IDisposables and async/await
Mark Rendle - Announcing the RTM of Visual F# 4.0
Visual FSharp Team - Nueva versión de .NET Framework 4.6
Luis Guerrero - Announcing .NET Framework 4.6
Rich Lander
martes, 21 de julio de 2015
En versiones anteriores de ASP.NET, podíamos utilizar la expresión
El valor de esa propiedad estaba directamente relacionado con el de la propiedad
Como sabemos, en ASP.NET Core esto no sería posible por tres motivos:
HttpContext.Current.IsDebuggingEnabled
para determinar si una aplicación web está ejecutándose en modo depuración o no, lo cual podía ser útil a la hora de introducir porciones de código específicas para cada caso. El valor de esa propiedad estaba directamente relacionado con el de la propiedad
debug
del tag <compilation>
presente en el archivo de configuración web.config.Como sabemos, en ASP.NET Core esto no sería posible por tres motivos:
- Primero, por la archiconocida desaparición del web.config.
- Segundo, porque al eliminar la dependencia con System.Web, ya no existen ni
HttpContext.Current
ni la propia clase estáticaHttpContext
. - Y tercero, porque no existe un modo “debug” como tal, sino distintos entornos de ejecución (development, staging, production, etc.) que pueden establecerse mediante línea de comandos o variables de entorno del sistema operativo
lunes, 20 de julio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- Expressmapper - The New .NET Mapper!
Yuriy Anisimov - FakeHttp
Don Kackman - Getting More LINQ-y
Jeremy Bytes - C# Succinctly (free ebook)
Joe Mayo
martes, 14 de julio de 2015
Desde luego, Stackoverflow, además de salvarnos la vida en numerosas ocasiones, es una fuente infinita de curiosidades, y hoy vamos a ver una que me ha llamado la atención últimamente, aunque sea un tema que lleva circulando por la red muchos años.
El asunto era que un usuario que quería saber cuál era el nombre del operador “-->” existente en muchísimos lenguajes, como podéis comprobar en un código perfectamente válido y compilable en C# como el siguiente:
¿Y cómo se llama ese operador? No puedo negar que al principio me quedé un poco descolocado, como probablemente os haya ocurrido a algún despistado más, pero al leer las respuestas el tema quedaba bien claro que es sólo una cuestión de legibilidad de código, o mejor dicho, de falta de ella, acompañado de un comentario algo desafortunado que incita a la confusión. Complejidad innecesaria en cualquier caso.
En realidad, se trata de dos operadores seguidos, autodecremento y comparación, utilizados de forma consecutiva y abusando de las reglas de precendencia. Sin duda habría quedado mucho más claro de cualquiera de estas formas:
En fin, lo que me resultó curioso y quería mostraros en este post es cómo unos simples espacios pueden hacernos ver operadores donde no los hay, introducirnos dudas incluso en algo tan conocido como son los operadores de nuestro lenguaje de programación favorito, y hacer que de un vistazo no entendamos el código que tenemos delante.
Pero ya sabéis: si queréis parecer muy inteligentes y aumentar vuestro ratio de WTFs/minuto en la próxima revisión de código, no dudéis en usarlo ;)
Y si queréis ser ya los reyes de vuestro equipo, tampoco dudéis en usar el operador inverso “<--" que sube un peldaño adicional en el nivel de absurdo:
Publicado en Variable not found.
El asunto era que un usuario que quería saber cuál era el nombre del operador “-->” existente en muchísimos lenguajes, como podéis comprobar en un código perfectamente válido y compilable en C# como el siguiente:
static void Main(string[] args) { int x = 10; while (x --> 0) // while x goes to 0 { Console.Write(x); } // Shows: 9876543210 }
¿Y cómo se llama ese operador? No puedo negar que al principio me quedé un poco descolocado, como probablemente os haya ocurrido a algún despistado más, pero al leer las respuestas el tema quedaba bien claro que es sólo una cuestión de legibilidad de código, o mejor dicho, de falta de ella, acompañado de un comentario algo desafortunado que incita a la confusión. Complejidad innecesaria en cualquier caso.
En realidad, se trata de dos operadores seguidos, autodecremento y comparación, utilizados de forma consecutiva y abusando de las reglas de precendencia. Sin duda habría quedado mucho más claro de cualquiera de estas formas:
// Mejor: usar los espacios apropiadamente while (x-- > 0) { Console.Write(x); } // Mucho mejor: usar paréntesis para dejar explícitas las precendencias while ((x--) > 0) { Console.Write(x); } // Lo más claro: no liarse con expresiones complejas while (x > 0) { x--; Console.Write(x); }Este tema lo publicó también Eric Lippert hace algunos años como broma del fool’s day, anunciando un operador que habían añadido a última hora a C# 4.0, aunque al parecer es algo que ya circulaba antes por la red.
En fin, lo que me resultó curioso y quería mostraros en este post es cómo unos simples espacios pueden hacernos ver operadores donde no los hay, introducirnos dudas incluso en algo tan conocido como son los operadores de nuestro lenguaje de programación favorito, y hacer que de un vistazo no entendamos el código que tenemos delante.
Pero ya sabéis: si queréis parecer muy inteligentes y aumentar vuestro ratio de WTFs/minuto en la próxima revisión de código, no dudéis en usarlo ;)
Y si queréis ser ya los reyes de vuestro equipo, tampoco dudéis en usar el operador inverso “<--" que sube un peldaño adicional en el nivel de absurdo:
static void Main(string[] args) { int x = 10; while (0 <-- x) // while 0 is approached by x { Console.Write(x); } // Shows: 987654321 }
Publicado en Variable not found.
lunes, 13 de julio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- String Interpolation and the Conditional Operators
Bill Wagner - Functional C#: Fluent Interfaces and Functional Method Chaining
Dave Fancher - A Complete List of .NET Open Source Developer Projects
Scott Ge - Using HtmlAgilityPack To Strip All HTML Attributes
Khalid Abuhakmeh - App.Config Transforms Outside Of Web Project
Sacha Barber - Create test data with NBuilder and Faker
Jerrie Pelser
martes, 7 de julio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
Oportunidades
- Becas Microsoft DPE 2015-2016
José Bonnin (Microsoft)
.Net
- Unleashing C# Generic Constraints with Extension Methods
Jeff Walker - How to debug a windows service without installing ?
Shashank Bisen - 4 Ways to check the given Integer is Even or Odd
Ulasalasreenath - Rant: Procedural text generation has never been this easy
Nicholas Fleck - A short identifier using base 36 in C#
Paul C. Smith
lunes, 6 de julio de 2015
Estimados amigos:
Tengo la inmensa satisfacción de informaros de que, de nuevo este año, he sido distinguido como MVP (Most Valuable Professional) de Microsoft por las contribuciones realizadas a la comunidad técnica durante el pasado año en temas relacionados con ASP.NET/IIS.
Cinco años consecutivos recibiendo este galardón, y sintiéndome cada vez más afortunado y feliz por seguir perteneciendo a este grupo en el que, además de unas personas maravillosas, podemos encontrar auténticos gurús de las tecnologías de Microsoft que se esfuerzan día a día en compartir sus conocimientos con la comunidad.
Muchas gracias a todos los que seguís haciendo este sueño posible, comenzando por vosotros, queridos amigos de Variable not found. Muchas gracias también a Cristina González y el equipo del programa MVP en Microsoft, y a todos los compañeros con los que he tenido la fortuna de coincidir en esta aventura y con los disfruto aprendiendo cada vez que tenemos oportunidad de vernos, muchas veces en la otra parte del mundo ;)
Ah, y por supuesto aprovecho para enviar un abrazo y muchas felicidades a los recién nombrados MVP de julio, tanto nuevos como reincidentes, entre los que puedo presumir de tener muy buenos amigos :)
Nos seguimos viendo por aquí ;)
martes, 30 de junio de 2015
Desde la versión 3 de ASP.NET MVC, los filtros globales nos han solucionado con facilidad la anteriormente ardua labor de definir filtros en todos los controladores y acciones de nuestra aplicación sin tener que introducirlos uno a uno o crear controladores base.
Por convención, los registrábamos en una clase llamada FilterConfig, habitualmente ubicada en la carpeta /App_Start del proyecto, y cuya pinta era más o menos la siguiente:
Este código era llamado durante la inicialización de la aplicación desde el evento
Por convención, los registrábamos en una clase llamada FilterConfig, habitualmente ubicada en la carpeta /App_Start del proyecto, y cuya pinta era más o menos la siguiente:
Este código era llamado durante la inicialización de la aplicación desde el evento
Application_Start()
del archivo Global.asax:
lunes, 29 de junio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- .NET versioning and multi-targeting on C# application and component
Southmountain - Exception filters in C# 6: their biggest advantage is not what you think
Thomas Levesque - TwinsOrNot.net Source Code Download
Scott Ge - ¿Qué son y en qué se diferencian .NET Full Framework y .NET Core Framework?
Vídeo de Unai Zorrilla - Debugging a Start of a Windows Service
Sebastian Solnica - What is ASP.NET console application?
Gunnar Peipman - Message Queuing with RabbitMQ Succinctly (free e-book)
Stephen Haunts - Using AutoMapper in your application for translating source object to destination object
Adarsh Chaurasia - Which Uri Encoding method should i use in C#/.net?
Leon Bambrick - [.NET] Qué son los Generics y su implementación en C# (I)
Sergio Parra
martes, 23 de junio de 2015
Los filtros de MVC, o action filters, han sido potenciados en la versión 6 del framework añadiéndoles características que en versiones anteriores no estaban disponibles de serie en la plataforma pero que han sido muy solicitadas por los desarrolladores. Hace algún tiempo vimos una de ellas, los filtros asíncronos, y hoy veremos que la inyección de dependencias en filtros también es ya una realidad.
El problema con la inyección de dependencias en los filtros es la instanciación de éstos, pues al definirse en forma de atributos de .NET no puede realizarse de forma controlada, o al menos lo suficientemente controlada como para poder inyectarles parámetros en el constructor o cargar sus propiedades desde un contenedor de inversión de control. Y aunque los filter providers aportaron alguna solución vía los contenedores IoC más populares, aún no eran una solución todo lo limpia que debería ser.
Pero como decía David Wheeler, “Cualquier problema en ciencias de la computación puede ser solucionado con otro nivel de indirección”… y eso mismo han debido pensar la gente del equipo de ASP.NET en Microsoft, cuando la solución que han dado consiste, básicamente, en crear un filtro capaz de instanciar otros filtros usando el contenedor de servicios integrado :)
El problema con la inyección de dependencias en los filtros es la instanciación de éstos, pues al definirse en forma de atributos de .NET no puede realizarse de forma controlada, o al menos lo suficientemente controlada como para poder inyectarles parámetros en el constructor o cargar sus propiedades desde un contenedor de inversión de control. Y aunque los filter providers aportaron alguna solución vía los contenedores IoC más populares, aún no eran una solución todo lo limpia que debería ser.
Pero como decía David Wheeler, “Cualquier problema en ciencias de la computación puede ser solucionado con otro nivel de indirección”… y eso mismo han debido pensar la gente del equipo de ASP.NET en Microsoft, cuando la solución que han dado consiste, básicamente, en crear un filtro capaz de instanciar otros filtros usando el contenedor de servicios integrado :)
lunes, 22 de junio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- A couple of notes about .NET Framework 4.6 setup behaviors
Aaron Stebner - [C#] ¿Cómo ha evolucionado nuestro lenguaje favorito?
Sergio Parra - .NET JavaScript Engine Performance Results
Rush Frisby - Run Executable from Resources in C#
Ahmed E Osama - xUnit.net 2 Cheat Sheet
Jason Roberts - C# 6: Expression Bodied Members Simplify Your Code
Bill Wagner
martes, 16 de junio de 2015
Me complace informaros de que, por fin, tenemos disponible en nuestro idioma mi libro sobre SignalR 2.0 que ya lleva algún tiempo en el mercado publicado en inglés por Microsoft Press, como libro “oficial” de esta tecnología.
Tras las traducciones al japonés y al chino, finalmente lo tenemos en español gracias al interés que desde un principio habéis mostrado todos, y al equipo de CampusMVP/Krasis Press, que han sido los encargados de sacarlo adelante. Un gran periplo desde su creación hasta devolverlo a su idioma original, que explica fantásticamente José Manuel Alarcón en su entrada "SignalR: la vuelta al mundo de un libro", y que os recomiendo que no os perdáis para conocer cómo empezó esta aventura y las cosas increíbles que han ocurrido desde entonces :)
lunes, 15 de junio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
- The difference between & and && operators
Colin Angus Mackay - Concurrency, part 6: Easier asynchrony in C# with await
Schabse Laks - How to Concatenate strings inside a List using Lambda Expression in C# ?
Senthil Kumar - Writing a simple Decompiler for .NET - Part 1
Karl - Visual Basic 14 Inline Comments & IsNot Works with TypeOf
Peter Vogel - Fluent Assertions
Rahul Sahay - LEADTOOLS Recognition Imaging SDK- Create Imaging Apps Easily
Dirk Strauss - Expresiones regulares en .NET
Sergio León
martes, 9 de junio de 2015
La verdad es que el nuevo sistema de configuración de ASP.NET Core tiene bastante buena pinta. Es potente, muy flexible y es bastante fácil de extender si tuviéramos necesidad de hacerlo.
Independientemente del proveedor que elijamos para almacenar los settings (un archivo JSON, un .INI, o el que sea), el acceso a la información siempre se realiza utilizando una cadena de caracteres hasta llegar al valor deseado de la configuración, como podemos observar en el siguiente ejemplo:
Sin embargo, esto puede ser una fuente de problemas, pues obviamente estas cadenas no son sometidas a ningún tipo de control en compilación y cualquier cambio de estructura o nombre de setting en el archivo de configuración podría provocar comportamientos incorrectos en nuestra aplicación.
Independientemente del proveedor que elijamos para almacenar los settings (un archivo JSON, un .INI, o el que sea), el acceso a la información siempre se realiza utilizando una cadena de caracteres hasta llegar al valor deseado de la configuración, como podemos observar en el siguiente ejemplo:
Sin embargo, esto puede ser una fuente de problemas, pues obviamente estas cadenas no son sometidas a ningún tipo de control en compilación y cualquier cambio de estructura o nombre de setting en el archivo de configuración podría provocar comportamientos incorrectos en nuestra aplicación.
lunes, 8 de junio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
Eventos
- [Evento] Windows 10 Developer Readiness Powered by MVPs
Javier Suárez
.Net
- C#/.NET Little Wonders: Null Conditional Operator in C# 6
James Michael Hare - Understand how bitwise operators work (C# and VB.NET examples)
ProgramFOX - C# Futures: Immutable Classes
Jonathan Allen - C#- How to Record What Gets Written to or Read From a Stream
Mike Hadlow - Backwards compatibility is (still) hard
John Skeet - Creating a Knockout-Style Variable in C#
Chris Eagle - Using Reflection to Get Enum Description and Value
Bruno Leonardo Michels
lunes, 1 de junio de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)
.Net
martes, 26 de mayo de 2015
Decía Larry Wall, creador de Perl, que una de las cualidades más destacables de un desarrollador es su orgullo desmedido. En su justa medida es una virtud interesante, pues permite asumir retos, enfrentarse a problemas complejos y crear software increíble, pero llevada al extremo puede ser peligrosa si se deja campar a sus anchas en un equipo de trabajo o proyecto.
Y ya se dieron cuenta de esto los padres de la informática, aquellos pioneros que hace cincuenta años andaban sentando las bases sobre las que se sustentan las tecnologías, herramientas y lenguajes que utilizamos hoy.
La programación sin ego, o egoless programming, es una forma de programar basada en el aprendizaje continuo y colaboración entre personas, dejando de lado los aspectos puramente personales y comportamientos ególatras que podemos tener algunas veces. La idea fue acuñada por Jerry Weinberg en su libro The Psychology of Computer Programming, publicado publicado en 1971.
En este libro aparecieron por primera vez los Diez Mandamientos del Egoless Programming, que creo que deberían ser unas normas de lectura y aplicación obligatoria en nuestra profesión.
La cuestión es encontrarlos pronto, antes de que lleguen a producción. Afortunadamente, salvo para los pocos que desarrollan software de guiado de misiles, los fallos tienen raramente consecuencias fatales en nuestra industria, así que podemos, y deberíamos, aprender, reírnos, y seguir adelante.
2. Tú no eres tu código.
Recuerda que el objetivo de una revisión es encontrar problemas, y se encontrarán problemas. No te lo tomes personalmente cuando un error tuyo se descubra.
3. No importa cuánto “karate” sepas, siempre alguien sabrá más.
Esa persona puede enseñarte algunos movimientos nuevos si se lo pides. Busca y acepta información de otros, especialmente cuando piensas que no es necesario.
4. No reescribas código sin consultarlo antes.
Hay una fina línea de separación entre “corregir código” y “reescribir código”. Conoce la diferencia y realiza los cambios en el marco de una revisión de código, y no actuando como un justiciero solitario.
5. Trata a los que saben menos que tú con respeto, educación y paciencia.
La gente no técnica que trata con desarrolladores de forma frecuente casi siempre tienen la opinión de que en el mejor de los casos somos divas, y en el peor, llorones. No refuerces este estereotipo con ira e impaciencia.
6. La única constante en el mundo es el cambio.
Permanece abierto a ello y acéptalo con una sonrisa. Mira cada cambio a tus requisitos, plataforma o herramientas como un reto, no como un inconveniente contra el que hay que luchar.
7. La única autoridad real deriva del conocimiento, no de la posición.
El conocimiento genera autoridad, y la autoridad engendra respeto. Así que si quieres ser respetado en un entorno egoless, cultiva el conocimiento.
8. Lucha por lo que crees, pero acepta la derrota con deportividad.
Entiende que a veces tus ideas serán ignoradas. Incluso si resulta que estabas en lo cierto, no seas vengativo o digas “te lo dije” más de un par de veces, ni hagas de tu difunta idea una mártir o un grito de guerra.
9. No seas “ese tío de la habitación”.
No seas ese tío programando en una oficina oscura que emerge sólo para comprar coca-cola. Ese tío está fuera de la vista, del tacto, fuera de control y no tiene cabida en un entorno abierto y colaborativo.
10. Critica el código y no a la gente.
Sé amable con el desarrollador pero no con el código. Haz comentarios relacionados con los estándares locales, especificaciones de la aplicación, incrementos de rendimiento, etc.
Publicado en Variable not found.
Y ya se dieron cuenta de esto los padres de la informática, aquellos pioneros que hace cincuenta años andaban sentando las bases sobre las que se sustentan las tecnologías, herramientas y lenguajes que utilizamos hoy.
La programación sin ego, o egoless programming, es una forma de programar basada en el aprendizaje continuo y colaboración entre personas, dejando de lado los aspectos puramente personales y comportamientos ególatras que podemos tener algunas veces. La idea fue acuñada por Jerry Weinberg en su libro The Psychology of Computer Programming, publicado publicado en 1971.
En este libro aparecieron por primera vez los Diez Mandamientos del Egoless Programming, que creo que deberían ser unas normas de lectura y aplicación obligatoria en nuestra profesión.
Los Diez Mandamientos del egoless programming
1. Entiende y acepta que cometerás errores.La cuestión es encontrarlos pronto, antes de que lleguen a producción. Afortunadamente, salvo para los pocos que desarrollan software de guiado de misiles, los fallos tienen raramente consecuencias fatales en nuestra industria, así que podemos, y deberíamos, aprender, reírnos, y seguir adelante.
2. Tú no eres tu código.
Recuerda que el objetivo de una revisión es encontrar problemas, y se encontrarán problemas. No te lo tomes personalmente cuando un error tuyo se descubra.
3. No importa cuánto “karate” sepas, siempre alguien sabrá más.
Esa persona puede enseñarte algunos movimientos nuevos si se lo pides. Busca y acepta información de otros, especialmente cuando piensas que no es necesario.
4. No reescribas código sin consultarlo antes.
Hay una fina línea de separación entre “corregir código” y “reescribir código”. Conoce la diferencia y realiza los cambios en el marco de una revisión de código, y no actuando como un justiciero solitario.
5. Trata a los que saben menos que tú con respeto, educación y paciencia.
La gente no técnica que trata con desarrolladores de forma frecuente casi siempre tienen la opinión de que en el mejor de los casos somos divas, y en el peor, llorones. No refuerces este estereotipo con ira e impaciencia.
6. La única constante en el mundo es el cambio.
Permanece abierto a ello y acéptalo con una sonrisa. Mira cada cambio a tus requisitos, plataforma o herramientas como un reto, no como un inconveniente contra el que hay que luchar.
7. La única autoridad real deriva del conocimiento, no de la posición.
El conocimiento genera autoridad, y la autoridad engendra respeto. Así que si quieres ser respetado en un entorno egoless, cultiva el conocimiento.
8. Lucha por lo que crees, pero acepta la derrota con deportividad.
Entiende que a veces tus ideas serán ignoradas. Incluso si resulta que estabas en lo cierto, no seas vengativo o digas “te lo dije” más de un par de veces, ni hagas de tu difunta idea una mártir o un grito de guerra.
9. No seas “ese tío de la habitación”.
No seas ese tío programando en una oficina oscura que emerge sólo para comprar coca-cola. Ese tío está fuera de la vista, del tacto, fuera de control y no tiene cabida en un entorno abierto y colaborativo.
10. Critica el código y no a la gente.
Sé amable con el desarrollador pero no con el código. Haz comentarios relacionados con los estándares locales, especificaciones de la aplicación, incrementos de rendimiento, etc.
Publicado en Variable not found.
lunes, 25 de mayo de 2015
Seguimos de fiesta, esto es un no parar :) Si la semana pasada celebrábamos el noveno aniversario del blog, hoy celebramos el post número 200 de estas recopilaciones de enlaces, que muchos de vosotros seguís y me habéis comentado que de verdad os resultan interesantes.
De nuevo, muchas gracias a todos por estar ahí :)
Y dicho esto, vamos al turrón…
De nuevo, muchas gracias a todos por estar ahí :)
Y dicho esto, vamos al turrón…
.Net
- A Look at the Open Source JustDecompile Engine
Michael Cramp - WCF Client is Open Source
Ron Cain - When everything you know is wrong, part one
Eric Lippert
martes, 19 de mayo de 2015
Pues sí, parece mentira, pero han pasado ya nueve años desde Variable not found comenzó tímidamente su andadura intentando hacerse un pequeño hueco en este océano de información en que se había convertido internet.
Sinceramente, y ya lo he comentado en alguna otra retrospectiva anual, nunca pensé que esta aventura duraría tanto tiempo y me traería tantas satisfacciones. Y aunque he de reconocer que no es una tarea sencilla, el hecho de estar todavía aquí con ganas de seguir aprendiendo y compartiendo todo lo que puedo es para mí una compensación más que suficiente a la dedicación que esto requiere :)
Como manda la tradición, voy a comentar algunos detalles objetivos sobre la salud blog y sus visitantes, porque alguna vez me habéis comentado que os resultan interesantes estos datos.
Sinceramente, y ya lo he comentado en alguna otra retrospectiva anual, nunca pensé que esta aventura duraría tanto tiempo y me traería tantas satisfacciones. Y aunque he de reconocer que no es una tarea sencilla, el hecho de estar todavía aquí con ganas de seguir aprendiendo y compartiendo todo lo que puedo es para mí una compensación más que suficiente a la dedicación que esto requiere :)
Como manda la tradición, voy a comentar algunos detalles objetivos sobre la salud blog y sus visitantes, porque alguna vez me habéis comentado que os resultan interesantes estos datos.