martes, 29 de diciembre de 2015
Ahí van los enlaces recopilados durante la semana pasada, la última colección del año. Espero que os resulten interesantes :-) .Net
- Optimizing memory allocations in .NET applications
Dmitry Orzhevsky - The week in .NET - 12/22/2015
Bertrand Le Roy - JIT optimization: static readonly to const
Alexandr Nikitin - Using AutoMapper with Attributes
Spencer Schneidenbach - .NET Framework setup verification tool, cleanup tool and detection sample code now support .NET Framework 4.6.1
Aaron Stebner - Turing Machine Simulation in C#
Hideous Humpback Freak - Regular Expression Options
Richard Carr - Creating a Search Engine using Lucene.NET - PART 1 : Understanding Lucene & PART 2 : Sample search engine in ASP.NET MVC application using Lucene.NET
Omar Nasri - Web Scraping in C#
Ivan Lukianchuk
lunes, 28 de diciembre de 2015
Como seguro sabréis, uno de los problemas abiertos más importantes del mundo de la informática era el problema de la parada. En el año 1936, el gran Alan Turing demostró de forma teórica que no existía ni podía existir un algoritmo mediante el cual una máquina de Turing pudiera determinar de forma automática si un programa cualquiera finalizaría su ejecución ante unos determinados datos de entrada, o bien si quedaría sumergido para siempre en un bucle o ciclo infinito.
Pues bien, tras algunos días de investigación, Aitor Agirreazkuenaga, paisano de Bilbao, ha encontrado una solución al problema, contradiciendo así a los teóricos más sesudos y haciéndose merecedor del millón de dólares que ofrecía el Clay Mathematics Institute para los científicos capaces de solucionar alguno de los problemas del milenio.
Los que estaban cerca de Aitor, que es también bastante conocido por su afición al Harrijasotzea, o levantamiento de piedras, dicen que realizó su descubrimiento al grito de “Verás tú si se para, ostias…”
Están por ver las repercusiones que su descubrimiento tendrá en el mundo del desarrollo, pero sin duda se trata de una gran aportación a la calidad del software, pues por fin podremos saber, antes de ejecutarlas, si nuestras aplicaciones son computacionalmente finitas y seguras.
De momento se sabe que Microsoft ya ha reaccionado al respecto, y los descubrimientos de Aitor estarán presentes en el próximo Visual Studio, alias "Codewalker", donde la estrella será un asistente inteligente de última generación que nos ayudará en todo momento durante el proceso de desarrollo, y cuya imagen ha trascendido recientemente en el blog oficial de la empresa.
Seguiremos informando, porque esto promete…
Publicado en Variable not found.
Pues bien, tras algunos días de investigación, Aitor Agirreazkuenaga, paisano de Bilbao, ha encontrado una solución al problema, contradiciendo así a los teóricos más sesudos y haciéndose merecedor del millón de dólares que ofrecía el Clay Mathematics Institute para los científicos capaces de solucionar alguno de los problemas del milenio.Los que estaban cerca de Aitor, que es también bastante conocido por su afición al Harrijasotzea, o levantamiento de piedras, dicen que realizó su descubrimiento al grito de “Verás tú si se para, ostias…”
Están por ver las repercusiones que su descubrimiento tendrá en el mundo del desarrollo, pero sin duda se trata de una gran aportación a la calidad del software, pues por fin podremos saber, antes de ejecutarlas, si nuestras aplicaciones son computacionalmente finitas y seguras.
De momento se sabe que Microsoft ya ha reaccionado al respecto, y los descubrimientos de Aitor estarán presentes en el próximo Visual Studio, alias "Codewalker", donde la estrella será un asistente inteligente de última generación que nos ayudará en todo momento durante el proceso de desarrollo, y cuya imagen ha trascendido recientemente en el blog oficial de la empresa.Seguiremos informando, porque esto promete…
Publicado en Variable not found.
martes, 22 de diciembre de 2015
A veces, en nuestras aplicaciones ASP.NET Core y MVC puede ser interesante manipular los encabezados retornados desde el servidor al cliente en todas las peticiones, ya sea añadiendo información personalizada o eliminando encabezados generados por otros componentes o middlewares que participan en el proceso de la petición.Un ejemplo muy típico puede ser la eliminación del header "Server" para no dar pistas sobre el software usado en el servidor, que, como se comentaba en la propia RFC del protocolo, "podría hacer nuestro servidor más vulnerable a ataques".
Obviamente, el tratarse de una tarea absolutamente transversal e independiente de las aplicaciones en las que vayamos a aplicar esta técnica, es la misión ideal para un middleware personalizado. Así pues, crearemos un componente de este tipo y lo insertaremos al principio del pipeline, capturando todas las respuestas enviadas al cliente y aprovechando ese momento para manipular los encabezados a nuestro antojo.
miércoles, 16 de diciembre de 2015
El pasado jueves, el grupo de usuarios Cartuja.NET organizamos en Sevilla el evento Reconnect(), una mañana completa durante la cual vimos las últimas novedades de tecnologías y herramientas relacionadas con .NET. Lo primero, agradecer a los numerosos asistentes que aparcaron sus quehaceres diarios para pasar la jornada con nosotros; espero que os haya resultado interesante. Muchas gracias también a los amigos de Plain Concepts por patrocinar el evento, y a mi inigualable compañero de escenario, Javier Suárez, por gestionarlo todo tan bien y, por supuesto, por sus interesantes presentaciones.
martes, 15 de diciembre de 2015
El concepto de proceso de peticiones basado en el pipeline no es algo nuevo, pero ciertamente es en ASP.NET Core donde se hace más explícito y visible a los desarrolladores.Y aunque anteriormente también hemos trabajado con middlewares (en ASP.NET 4.x los módulos y handlers podían ejercer funciones similares, y más recientemente, en OWIN ya existía el mismo concepto), es ahora cuando debemos conocerlos bien si queremos llegar a comprender y dominar la nueva plataforma ASP.NET Core.
Este este post vamos a profundizar un poco en el proceso de peticiones en ASP.NET Core, y veremos lo sencillo que resulta crear middlewares personalizados que participen en dicho proceso.
jueves, 3 de diciembre de 2015
Hace un par de semanas se celebró en Nueva York "Connect(); // 2015", un evento donde, como sabéis, se presentaron las novedades más recientes en herramientas y servicios de Microsoft.Tomando el relevo, "Reconnect(); // 2015" es un evento organizado por el grupo de usuarios .NET de Sevilla (Cartuja.NET) en el que veremos los aspectos más destacables de esas novedades.
Será el próximo jueves 10 de diciembre, una mañana completa cuya agenda es la siguiente:
9:15 - 9:30 Registro.
9:30 - 10:30 Keynote. Javier Suárez, Josué Yeray y Marcos Cobeña.
10:30 - 11:30 ASP.NET 5 & MVC 6 (RC 1). Jose María Aguilar.
11:30 - 12:00 Descanso & Networking.
12:00 - 13:00 Universal Windows Platform. Javier Suárez y Josué Yeray.
13:00 - 14:00 Desarrollo móvil con Xamarin. Javier Suárez, Josué Yeray y Marcos Cobeña.
14:00 - 14:15 Cierre.
El lugar: WorkINCompany - Calle Rioja, 13, 41001 Sevilla.
Podéis registraros siguiendo este enlace; no tardéis, que las plazas son limitadas :)
¡Nos vemos por allí!
Publicado en Variable not found.
martes, 1 de diciembre de 2015
Pues no parecía que esto de la gestión de errores fuera a dar para tanto, pero este es ya el tercer post dedicado a este tema, que por otro lado debemos controlar totalmente cuando comencemos a crear aplicaciones reales con ASP.NET Core y MVC.Hasta ahora hemos visto cómo gestionar las excepciones producidas desde nuestras aplicaciones utilizando el middleware
ExceptionHandlerMiddleware, y cómo obtener información sobre dichas excepciones desde su código manejador. Esto nos permitía un buen grado de control sobre los errores HTTP 500, pero el amigo Juan, muy atento a lo que íbamos viendo, preguntaba:"Siguiendo con la captura de excepciones, esta vez en mvc6 como se podría capturar los códigos de estado como por ejemplo 404"Obviamente el resto de errores HTTP entre el 400 (errores en cliente) y el 599 (errores en servidor) no son capturados por
ExceptionHandlerMiddleware porque en realidad no se deben a excepciones generadas desde nuestra aplicación sino a otros problemas que han podido surgir durante el proceso de la petición. Por ello, requieren un tratamiento distinto que de nuevo viene en forma de middleware.
lunes, 30 de noviembre de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-) .Net
- Multicast Delegates in C#
Abhi Jain - How to create a “Hello World” console application using .NET Core without Visual Studio?
Manjunath Gururaja - The road to DNX part I, part II & part III
Marc Gravell - Using JavaScript Frameworks inside C# with ChakraBridge
David Catuhe - Hoisting in .NET Explained
Alexandr Nikitin - Re-throwing Exceptions and the Call Stack
Richard Carr - Memory allocation in .Net – Value type, Reference type, Stack, Heap, Boxing, Unboxing, Ref, Out and Volatile
Sameemy2ks - Embedding Chrome in your C# App using CefSharp
H. Gupta - Código abierto, ecosistema cerrado
Juan María Hernández
martes, 24 de noviembre de 2015
Hace unos días comentábamos la desaparición de la sección <customErrors> en ASP.NET Core, y la forma de implementar páginas de error personalizadas en esta nueva versión del framework.Sin embargo, hay una cosa que dejé en el tintero y que el amigo Max resaltó en los comentarios del post:
"[…] Cuando se hace la petición interna a la acción HomeController.Error ¿como puedo saber exactamente el error que se ha producido si quiero mostrar un mensaje de error concreto para cada caso? Por ejemplo imagínate que quiero mostrar vistas diferentes para cada tipo de excepción o que aparezca sólo el texto de la excepción pero sin mostrar más datos"En otras palabras, cuando el middleware
ExceptionHandlerMiddleware pasa el control a la acción que procesará el error, ¿cómo podemos obtener información sobre la excepción que se produjo, por ejemplo para poder mostrar vistas o mensajes de error un poco más específicos?Qué pregunta tan interesante, ¿verdad?
lunes, 23 de noviembre de 2015
Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-) .Net
- Announcing .NET Framework 4.6.1 RC
.NET Fundamentals team - Announcing .NET Core and ASP.NET 5 RC
Rich Lander - Monitor madness, part two
Eric Lippert - async/await - What You Should Know!
Amir Dashti - Building a Code Analyzer for the Roslyn Analyzer Project
Josh Varty - Understanding the Benefits and Proper Usage of Extension Methods
Michael S. Post - The hidden costs of allocations
Ayende Rahien - Realistic Sample Data with GenFu
Dave Paquette - Monitor madness, part one
Eric Lippert - Regular Expression Conditional Matching
Richard Carr
martes, 17 de noviembre de 2015
Seguro que ya conocéis la respuesta: no está. Desapareció. Kaput. Es simplemente otro de los efectos colaterales derivados de los cambios en ASP.NET Core, y más concretamente, de la sustitución del archivo web.config por otros mecanismos de configuración.Sin embargo, seguro que también estaréis de acuerdo en que era una característica sumamente interesante porque nos permitía configurar el comportamiento de nuestra aplicación cuando se producía un error inesperado. Jugando un poco con la configuración podíamos optar por mostrar valiosa información de depuración, como datos sobre la excepción lanzada, el punto exacto donde se produjo o la pila de ejecución, o bien páginas de error personalizadas con mensajes aptos para todos los públicos (como la ballenita voladora de Twitter u otras creativas páginas "oops!" que inundan la red).
lunes, 16 de noviembre de 2015
Pues tras el fantástico viaje a Redmond, ya estamos de vuelta listos para continuar con las tradiciones, como el post de enlaces que he ido recopilando durante la semana entre bostezo y bostezo provocado por el también tradicional jetlag ;) .Net
- Our plans for Nancy 1.X and beyond
Andreas Håkansson - Peasy: An easy to use middle tier framework for .net
Aaron Hanusa - Reactive Extensions (Rx)
Gautham Prabhu K - Migrating an ASP.NET MVC 5 App to ASP.NET 5
Paul Litwin - When would you use & on a bool?
Eric Lippert
