Últimamente TheAlphasite está un poco parada (más de lo habitual), quizá os hayais dado cuenta.

No es que haya perdido impulso, es que estoy preparando a su sucesora.

Stackframe.net (que así se llamará) será muy parecida a esta página pero estará en inglés y en español. Tendréis todos los artículos que hay disponibles aquí también allí, y otros nuevos.

El objetivo es convertir esa página en lo que esta tenía que haber sido y permitirme dedicarle más tiempo, más recursos y más ganas para publicar tanto noticias como cualquier cosa que se me vaya ocurriendo, así como permmitir que preguntéis cualquier duda que tengáis para obtener aclaraciones o un artículo completo explicando algún concepto o duda que no tengáis claro.

Aún le queda un tiempo para estar lista, pero espero que este arriba antes del verano (o a la vuelta como muy muy tarde)... En cuanto esté lista os avisaré (y poco después redirigiré todo el tráfico de este sitio hacia stackframe.net

Está disponible para descarga la herramienta Microsoft Source Analysis para C# que permite el análisis de nuestro código fuente para adaptarlo a los estándares de calidad que rigen dentro de la propia Microsoft.

La herramienta es similar a FxCop pero aplicada directamente al código fuente (mientras que FxCop afecta a ensamblados directamente).

Microsoft Source Analysis viene configurada con unas 200 reglas (que no se pueden editar) y que afectan cosas como la disposición de los elementos del código (corchetes, espacios, etc), la presencia o no de documentación, el espaciado de lineas, el nombrado de los elementos así como algunas otras cosas. Su objetivo primordial es mejorar la estructura y presentación del código para mantener unas regla que lo hagan lo más legible posible.

Personalmente FxCop me parece mucho más completo y además utilizan reglas distintas que en algunos casos pueden llevar a conflicto. No obstante son herramientas distintas con propositos distintos y algunas de las cosas de este Source Analysis estriba en cuestiones de layout (por ejemplo te recomiendo que un comentario de código debería estar precedido de una linea en blanco (para mejorar la legilibilidad del código), te avisa de la falta de documentación de los métodos o te avisa de las secciones de código que son poco "legibles", por lo que su ámbito es distinto y FxCop, q trabaja con ensamblados, nunca podrá dar información de ese estilo.

Podéis descargarlo aquí.

De un tiempo a esta parte se ha oye el concepto de "programación colaborativa" entre varios programadores de forma que varios programadores trabajen simultaneamente sobre el mismo fragmento (o fragmentos) de código.

La idea detrás del paradigma consiste en que dos pares de ojos ven mucho más que uno y por tanto, aunque la productitividad de dos programadores trabajando será siempre mucho menor que la productividad de ambos por separado, la calidad del código producido será muchisimo mayor, lo cual debería llevar a un código más mantenible, más organizado, más elegante y más seguro.

En los últimos tiempos parece que los movimientos de las grandes compañías, especialmente Microsoft y Google tienden a intentar acercarse cada vez más a la tecnología web de una forma o de otra.

No es para menos, el mercado potencial de internet es muy superior a cualquier otro mercado que se haya dado hasta ahora, basta con mirar a Google, cuyo negocio es únicamente internet para darse cuenta de eso. Cada vez nos encontramos con más acercamientos por parte de montones de empresas para ofrecer diversos servicios alrededor de la web, muchas de ellas con un enorme éxito. Ahí tenemos Twitter, Facebook, Blogspot...

Sin embargo, últimamente parece que se empieza a hablar de un "universo web", Google Docs, Microsoft Office Live, Piccasa, etc ... y empieza a implantarse por aquí y por allá la idea de "sistemas operativos web", a saber donde llegaremos. La absurdez del asunto asusta, que uno pueda hacer algo no quiere decir que lo que haga este bien hecho y tenga sentido, no porque el correo electrónico online sea algo extremadamente útil va a pasar lo mismo con una suite ofimática en linea.

He estado leyendo una entrada en el blog de Sasha Goldshtein titulada "Design for Performance Up-Front" que hace una reflexión muy interesante. Pego y traduzco:

If a user clicks a button and the application crashes, it's a problem. If a user clicks a button and the application takes 5 seconds to respond when it should be unnoticeable, it's a problem. It's the same problem.

Si un usuario hace click en un botón y la aplicación da error, es un problema. Si un usuario hace click en un botón y la aplicación tarda 5 segundos en responder cuando ese tiempo no debería notarse, es un problema. Es el mismo problema.

Parallel Extensions es un framework de Microsoft, aún en desarrollo para facilitar el desarrollo de aplicaciones concurrentes. Recientemente acaban de sacar la primera CTP (comunity tecnology preview) que está disponible para descarga y han solicitado feedback y comentarios en sus foros.

El funcionamiento es el común de una biblioteca, pero la implementación incorpora optimizaciones para mejorar el rendimiento de las aplicaciones multihilo liberando al programador de la tarea. Internamente se encarga de "decidir" si un trabajo debe ser ejecutado en un hilo separado o si se debe ejecutar en el propio hilo que invoca la llamada. Internamente está organizado en una serie de hilos, parecido al thread pool de .NET pero con ciertas optimizaciones, ya que existen una serie de colas internas en las que se insertan los trabajos (es algo más complicado que eso pero baste la simplificación), permitiendo que determinados hilos se "roben" las tareas entre ellos para mejorar la ocupación general de la CPU y por tanto el rendimiento del programa.

Hace bien poco he leido un interesante artículo (en inglés) llamado "The empty try block mystery" que describe algunas secciones de código presentes en el código fuente del .NET Framework y que son similares a lo siguiente:

y que responde a la pregunta ¿porque diablos iba alguien a declarar un bloque try finally estando el try vacío? Pues vamos a explicarlo, en español ;)

La técnica de ataque de SQL Injectión (Inyección de SQL) explota una vulnerabilidad de la capa de acceso a datos de la aplicación. Es genérica a cualquier aplicación, no solo, como mucha gente cree, a aplicaciones web aunque debido al mayor acceso a través de internet así como al "descuido" de los desarrolladores web en muchas ocasiones a la hora de tratar los parametros GET ha hecho que este tipo de ataque se popularice en la web.

Seguimos con un repaso a las características nuevas de C# 3.0, en la primera parte vimos el uso de de propiedades automáticas e inicializadores de objetos y colecciones. En la segunda parte vimos una introducción al uso de extensiones, que nos proporionan una forma no intrusiva de ampliar la funcionalidad de una clase.

En esta última parte vamos a ver la expresiones lambda y su integración con Linq así como algunas de las funciones que nos proporciona este último.

Acabo de leer un artículo bastante interesante sobre el rendimiento del uso de excepciones en .NET (aunque en general el concepto es aplicable a prácticamente cualquier lenguaje que las soporte).

El manejado de una excepción, especialmente la parte correspondiente a su resolución implica un gran consumo de recursos y tiempo. Para los que no vayan muy bien con el inglés (o sean demasiado vagos para leer el artículo :P) lo que viene a demostrar es la diferencia entre estos dos segmentos de código

observando que el código de la derecha tarda medio segundo frente a los nada más y nada menos que 50 segundos del código de la izquierada.

No obstante, aunque la comparación así hecha parezca nefasta, no debemos olvidar que la prueba lanza un total de un millon de excepciones consecutivas, algo que no es muy probable que pasé en la vida real, no obstante, si podemos comprobar que una llamada sea correcta antes de realizar, siempre será mucho mejor que capturar la excepción. En ese sentido es importante recalcar que lo importante es evitar la excepción en la medida de lo posible, no suprimir el bloque try catch, que en si mismo no genera ningún overhead, solo perdemos rendimiento cuando la excepción sucede, si no salta ninguna excepción la presencia o no de dicho bloque no afecta prácticamente al rendimiento.