Blog

La mayor parte de los problemas que nos podemos encontrar al usar patrones de diseño vienen de no ser capaces de reconocer en qué contextos hay que aplicarlos.

Se han escrito muchas líneas acerca de la seguridad de las aplicaciones que realizamos en .Net. Se dice que son muy fáciles de hackear, que aun usando herramientas de ofuscación, la seguridad de los empaquetados que se distribuyen es nula.

Cuando hablamos de un patrón de diseño nos referimos a una solución a un problema concreto en el desarrollo de software. Pero no cualquier solución, sólo aquellas que se ha desmostrado que son eficientes en diferentes escenarios y reutilizables en gran cantidad de contextos de aplicaciones. Por lo tanto, aunque los ejemplos que podamos dar estén en un lenguaje de programación concreto, la idea será extrapolable a diferentes lenguajes de programación orientada a objetos.

¿Qué desarrollador de software nunca ha estado una semana programando a toda velocidad, casi sin saber que hace, ya que la fecha de entrega está cerca y todo tiene que estar terminado “para ayer”? ¿Quién no se ha encontrado en la situación de saber que está programando una chapuza, pensando que otro día lo mejorará, y ese día nunca llega? ¿Quién alguna vez, al ver una porción de código fuente no ha exclamado indignado: ¡qué narices hace este código! o ¡quién leches lo ha programado!?

Hace unos días en los foros de Windows Communication Foundation de MSDN un usuario preguntaba por la diferencia entre Faults y Exceptions dentro de esta plataforma. La respuesta me llevó a escribir una pequeña introducción a la gestión de excepciones para los servicios WCF que me gustaría ampliar en este artículo. Para los más experimentados resultará un texto algo básico. Para los demás sin embargo, les puede ayudar a programar siguiendo las buenas prácticas en el desarrollo de sus servicios.

El pasado fin de semana @quiqu3 y @fernandoescolar estuvieron en Madrid, en la codemotion, en representación de programando en .net. Además tuvieron el placer de impartir una pequeña charla de 45 minutos acerca de las reactive extensions. Aprovechando este hecho, nos gustaría cerrar de una forma más o menos elegante la serie de artículos sobre rx, aportando un índice de los artículos, un breve resumen basado en la charla y varios programas de ejemplo (incluida la red social de moda: BeerToBeer).

Hoy os vamos a proponer el último artículo teórico acerca de las reactive extensions. Una vez hemos definido las rx, sabemos qué son los sujetos y las operaciónes de creación y Linq, ya podemos hablar de el último parámetro de la fórmula que definimos en su día: los Schedulers.

Hemos llegado al cuarto artículo sobre reactive extensions en el que vamos a hablar de operaciones que se pueden realizar con observables. Pero, como hace unos días que no publicábamos nada al respecto, vamos a hacer primero una pequeña retrospectiva. Hasta ahora hemos tratado de explicar rx como una fórmula matemática:

Creo que este es el primer artículo que vamos a ver en programandonet a modo editorial. Esto es el resultado de una conversación en el grupo de arquitectos .net de LinkedIn, en la que se hablaba sobre usar POCOs de entity framework como DTO para servicios WCF, que se inició hace unos días. Y es que, no me hubiera gustado que algunas conclusiones y escritos se perdieran en este grupo y por eso hemos creído interesante publicarlas aquí, para tenerlas a mano.

Año nuevo artículo nuevo. Después de dos artículos cargados de conceptos teóricos y pruebas, ha llegado el momento de empezar a sacarle partido de verdad a la reactive framework. Hasta ahora hemos visto cuales son los principios en los que se fundamenta Rx, los objetos que vamos a tener que utilizar (los sujetos) e incluso introdujimos el uso de una clase llamada Observable que contiene métodos y extensiones para que todo esto sea más sencillo.