Motivos de un ensamblado

Modeling in Text: Serie de screencasts sobre el lenguaje M

2010-02-18T05:13:00Z

Durante las últimas semanas he tenido la oportunidad de grabar una serie de cinco screencasts sobre el lenguaje M para nuestra web en MSDN.

La serie está dividida en cinco capítulos, en los cuales partimos de un conocimiento previo sobre M prácticamente nulo para posteriormente incrementar la funcionalidad de nuestro ejemplo a medida que introducimos nuevos conceptos del lenguaje. El contenido de cada uno de los capítulos es el siguiente:

“Modeling a Language”: En este capítulo explico de qué forma podemos modelar nuestros propios lenguajes, comenzando por la creación de un lenguaje sencillo que reconozca una única sentencia (“Chris is 24 years old”) para posteriormente incorporar nuevos conceptos y funcionalidades del lenguaje y poder generalizar dicho lenguaje, así como modificar la estructura del AST / proyección resultante.
“Data”: Esta segunda parte de la serie se centra en explicar cómo consumir el resultado obtenido en el capítulo anterior (estructuras de datos en M generadas a partir de la “compilación” de un archivo de texto escrito en nuestro propio DSL), de modo que podamos importar dichos datos a SQL Server, vía herramientas de línea de comandos (M.exe y Mx.exe), así como visualizar dichos datos en Quadrant una vez forman parte de nuestro repositorio en SQL Server.
“Transformation”: En este vídeo veremos la estructura general de la transformación de M a sentencias T-SQL, así como diferentes alternativas para escribir funciones de manipulación sobre dichos datos en M, que posteriormente serán transformadas en vistas de SQL.
“Constraints”: Este capítulo muestra de qué forma podemos imponer restricciones sobre nuestros datos (definir el tipo de datos de cada atributo, etc.), y analizamos cómo su traducción a T-SQL resulta diferente en función de dichos cambios.
“Identity and relationships”: En la última parte de la serie, describimos cómo crear relaciones entre distintas entidades, mediante el uso de IDs, etiquetas y colecciones que referencian a dichos elementos.

Aprovecho para recomendar a aquellos interesados en SQL Server Modeling (M, Quadrant, Repositorio) que visiten nuestra sección de videos en la cual no sólo podréis encontrar esta serie sino también vídeos de las sesiones del PDC de Don Box, Chris Anderson, Chris Sells, etc., así como bastantes más screencasts sobre las tecnologías que estamos construyendo.

Enjoy!

He leído: “CLR Via C#”, 3ª Edición

2010-02-09T22:00:03Z

Este fin de semana he tenido la ocasión de leer la última edición del libro “CLR via C#”, que saldrá a la venta próximamente.

No descubro nada diciendo que este es uno de los libros de imprescindible lectura para todo aquel programador de .Net que se precie… Sin embargo, me gustaría destacar algunas de las novedades incluídas en esta nueva edición, que constituyen un motivo más que suficiente para que aquellos que han leído alguna de las ediciones anteriores se animen a volver a leerlo… En realidad, creo que quien haya leído este libro con anterioridad, no necesita motivos que le animen a volver a leerlo, más allá de la noticia de que una nueva edición ha sido publicada…

En esta edición, la principal novedad es la inclusión de una nueva sección (unas 200 páginas extra) dedicadas a Threading, mecanismos de gestión concurrente en Windows y su correspondencia en el “nuevo” CLR 4.0, operaciones asíncronas y políticas de sincronización entre hilos.

Otra sección totalmente nueva que ha sido incorporada al libro está dedicada a serialización en tiempo de ejecución.

En el resto de secciones, se han añadido o modificado conceptos para adaptarlos a las nuevas versiones del CLR y del propio lenguaje C#.

En cuanto a C# 4.0, algunos de los conceptos incorporados al libro son: tipo dynamic, parametros opcionales, variables locales implícitamente tipadas, propiedades implementadas automáticamente, tipos anónimos, inicializadores de objetos y de colecciones, uso de expresiones lambda para delegados, etc.

Respecto al CLR 4.0, se ha reescrito completamente el capítulo dedicado al manejo de excepciones en el framework, así como modificaciones notables en cuanto a la gestión automática de memoria (novedades en el garbage collector), soporte para múltiples CLRs cargados en un mismo proceso, novedades en el manejo de AppDomain, etc.

Sin duda, una lectura más que recomendable…

Disfrutadlo!

Pongamos que hablo de MSN Entretenimiento

2010-02-04T02:26:00Z

Me cuenta un pajarito que el próximo jueves 4 de Febrero, a partir de las 23:30h (GMT+1) podremos disfrutar a través de MSN Entretenimiento en primicia mundial del nuevo videoclip del Maestro Sabina: “Viudita de Clicqcuot”.

MSN Entretenimiento es un servicio de MSN que pone a nuestra disposición una gran variedad (y cantidad) de contenidos multimedia online, de forma gratuita: Series de TV, música, videoclips, juegos, etc. Todo en Español…

A disfrutarlo compañer@s!!

Por qué no me gusta la métrica LOC (Lines Of Code)

2009-12-21T19:15:03Z

[ Aprovechando las vacaciones navideñas ~~y las 15 horas de vuelos desde Seattle~~ hasta España para redactar unos cuantos posts que tenía en mente desde hace tiempo… ]

Hoy os hablaré sobre por qué considero que LOC no es una métrica de código demasiado útil (por decirlo eufemísticamente), algo sobre lo que estoy seguro de que habréis leído ya en bastantes ocasiones pero me gustaría aportar mi visión particular.

De vez en cuando me he encontrado con gente que me realiza preguntas del tipo: “¿Cuántas líneas de código tiene el proyecto ~~Oslo~~ SQL Server Modeling Services?" (cambiad esta última parte por Windows 7, o Visual Studio 2010, o SQL Server 2008, etc), o también “Miguel, ¿cuantas líneas de código escribes al día?”…

En el caso de la segunda pregunta, mi respuesta suele ser: “En algunos de los mejores días de mi vida como desarrollador, mi LOC ha sido un valor negativo. Afortunadamente, LOC no es directamente proporcional a mi productividad”. : )

Hay dos matices que considero bastante descriptivos en cuanto a LOC:

Para lo único que LOC es una medida válida es para medir el tamaño de la base de código de un proyecto.
Un valor de LOC enorme en nuestra codebase no resulta ser, en muchas ocasiones, algo bueno.

Mi opinión personal es que LOC es prácticamente inútil para gestión de proyectos, para lo único que nos sirve es para hacer análisis del tipo:

El módulo A es el doble de grande que el módulo B. (considerando que ambos están escritos en el mismo lenguaje (aunque esto sería también discutible, hay estudios que afirman que LOC es independiente del lenguaje empleado, pero no estoy de acuerdo en la mayoría de casos), que las coding guidelines son las mismas para ambos, etc… En cualquier otro caso, ni siquiera serían comparables)
El módulo C ha crecido un 25% en los últimos 6 meses.
Podemos ver cómo el módulo D tiene un elevado número de bugs, debido a su gran tamaño.

Para cuestiones relacionadas con el análisis del crecimiento/progreso en un determinado proyecto, es claramente mejor fijarse en otras métricas diferentes a LOC, como por ejemplo el número de features completadas/pendientes, etc. Si empleáramos LOC, el análisis sería incorrecto ya que alguien podría añadir 1.000 líneas de código a un proyecto sin completar una feature concreta, de igual forma que alguien podría eliminar 1.000 líneas de código y ser capaz de completar tres features.

Respecto a este último ejemplo, comentar que un índice LOC negativo es en bastantes casos el resultado de un trabajo de refactorización de código realizado como parte de la implementación de una nueva feature y puede tener un impacto significativo en el tamaño global de nuestra base de código.

Ahora que ya os he dado mi opinión personal, veamos qué dicen otras fuentes más documentadas que yo al respecto. Por ejemplo, la siguiente tabla (extraída del libro “Code Complete”) nos muestra la relación entre el tamaño del proyecto y el LOC por persona/año:

Tamaño del proyecto (LOC)	LOC por persona/año
1.000	2.5K - 25K
10.000	2K - 25K
100.000	1K - 20K
1.000.000	0.7K - 10K
10.000.000	0.3K - 5K

El aspecto a destacar en esta tabla es que la cantidad de líneas de código que un desarrollador es capaz de escribir disminuye a medida que el proyecto aumenta de tamaño. Esto se debe a diversos factores, como son el hecho de que la complejidad aumenta, el impacto de las modificaciones realizadas es mucho mayor en otras partes del proyecto, el esfuerzo de testing necesario aumenta, el número de bugs aumenta, etc.

Por tanto, idealmente, un buen desarrollador no es aquel con mayor LOC, sino con mayor ratio Feature/LOC ya que eso significaría que el desarrollador está implementando nuevas funcionalidades (y por tanto aportando valor añadido para el cliente) a la vez que mantiene el tamaño de code base en unos límites razonables, lo cual permite incrementar la productividad de él mismo y del resto de compañeros en el equipo de desarrollo del proyecto.

Otros factores negativos sobre LOC los podemos encontrar en el libro “Applied Software Measurement” de Capers Jones, entre los que destacaré los siguientes:

Las métricas LOC penalizan a los lenguajes de programación de alto nivel.
Análisis comparativos de proyectos en los que se ha empleado más de un lenguaje de programación y que se fundamenten en LOC deberán ser considerados una mala práctica profesional.
Las métricas de “Coste por bug” penalizan la calidad y hacen que un software lleno de bugs pueda parecer mejor de lo que en realidad es, a juzgar por los resultados de un estudio basado en LOC. Para este tipo de estudios, es mejor emplear métricas de Puntos de Función.

Por último, me gustaría recomendar otro libro bastante interesante “Measuring and Managing Performance in Organizations”, de Robert Austin. En este libro, Austin entrevista a varios expertos de la industria del software que aportan su opinión acerca de qué cosas conviene (o no) medir. Al final, casi todos ellos coinciden en que medir todo aquello que convendría medir en el desarrollo software es prácticamente imposible…

Merry Christmas!

De Oslo a SQL Server Modeling: Anunciando nuestra nueva CTP de Noviembre de 2009

2009-11-19T08:58:00Z

Una característica común a todos los grupos de producto en Microsoft es su trabajo constante para mejorar y refinar sus tecnologías. Este hecho se cumple aún cuando hay que afrontar diversos cambios tales como cambios en la organización o también el renombrado de dichos productos, así como encontrar para ellos una vía que los conduzca a un lanzamiento exitoso.

En este caso, ha llegado la hora de anunciar el cambio de nombre de lo que hasta ahora conocíamos con el nombre de OSLO. Nuestro nuevo nombre es: SQL Server Modeling. Este cambio, del cual ya os hablé hace unos meses, no debería coger por sorpresa a nadie puesto que algunas de las tecnologías incluídas en OSLO, como por ejemplo Quadrant, han estado siempre ligadas a SQL Server y otras, como el repositorio de modelos, directamente implementadas sobre SQL Server. Incluso en el caso de una tecnología como el lenguaje M, a priori agnóstico en cuanto al motor de bases de datos subyacente, tiene una sinergia natural con SQL Server.

Por supuesto, hay una serie de dudas y cuestiones que afloran como consecuencia de este cambio de nombre del proyecto, de las cuales probablemente estéis ya al tanto… No obstante, la respuesta más clara, concisa y sonora que os puedo dar es: independientemente del nombre bajo el que se aglutinen estas tecnologías, el compromiso por parte del equipo de producto sigue siendo absoluto con todas y cada una de ellas. Ahora, las respuestas largas para cada una de estas preguntas las podéis encontrar en esta página de Q&A.

Al margen de esta reflexión, la gran noticia en torno a Oslo SQL Server Modeling esta semana ha sido el lanzamiento de una nueva CTP: SQL Server Modeling November 2009 CTP. Esta CTP contiene nuevas versiones del lenguaje M, el diseñador Quadrant, y de SQL Server Modeling Services (previamente conocidos como “el repositorio de modelos de Oslo”).

Los aspectos generales acerca de estas novedades en nuestras tecnologías los podéis encontrar en las Release Notes, así como en nuevos artículos publicados en MSDN Library.

Sin embargo, me gustaría destacar aquellos que, a priori, considero más relevantes….

Cambios Generales

El primer cambio que notaréis al instalar esta nueva CTP es que el nombre de Oslo ha desaparecido (sniff sniff), tanto en el proceso de instalación, como en el menú de inicio. Sin embargo, aún encontraréis el nombre de Oslo en la carpeta de Archivos de Programa, y también veréis instalada en SQL Server una base de datos llamada “Repository”, al igual que en anteriores CTPs…. no nos dio tiempo de cambiar el nombre en todas partes, jeje… Resumiendo, a pesar de que el nombre de la CTP haya cambiado, estructuralmente veremos lo mismo que en previas CTPs.

El segundo cambio importante, lo encontraréis en los requerimientos de esta CTP: Visual Studio 2010 y .Net 4.0 Beta 2. Si aún no habéis instalado dichas maravillas tecnológicas, ¡éste es el momento perfecto! : )

Como os decía, no hemos tenido tiempo de modificar el nombre en la parte estructural del proyecto, en buena parte debido a que hemos estado ocupados añadiendo funcionalidades al proyecto… Entre ellas, las siguientes…

Cambios en SQL Server Modeling Services

En primer lugar, el dominio UML incluido en CTPs anteriores (System.UML2) ha sufrido cambios significativos. Estos cambios suponen que aquellos ejemplos creados en CTPs anteriores sobre este dominio no funcionen tal cual, deben ser readaptados. Pero… a cambio, ahora es posible exportar estos modelos en UML para interoperar con otras herramientas de modelado UML.

Por otra parte, el modelo correspondiente al CLR (que nos permitía realizar queries acerca del uso de nuestros assemblies, entre otras cosas) también ha sufrido algunos cambios, especialmente en el modo de funcionamiento de la herramienta LoadAssembly.exe, la cual nos permite cargar assemblies en nuestro repositorio. Si os gusta, como a mí, el Algebra y estáis familiarizados con la teoría de conjuntos, la forma más precisa de definir estos cambios es: En la versión actual, LoadAssembly ya no calcula y carga en el repositorio la clausura transitiva de todos los ensamblados referenciados por ensamblados especificados en la línea de comandos”. Este cambio en la lógica de LoadAssembly.exe nos permite evitar cargas duplicadas de metadatos de ensamblados de .Net fx, lo cual, considerando el ahorro espacio-temporal y las mejoras en el rendimiento de LoadAssembly.exe, es una ventaja considerable.

El último aspecto a destacar en cuanto a las novedades en SQL Server Modeling Services es la creación de un nuevo ejemplo, denominado PatternApplication, el cual nos permite aplicar los patrones del repositorio a un conjunto de modelos, algo que hasta ahora se debía realizar para cada modelo de forma independiente. Podéis encontrar este ejemplo aquí.

Para más información sobre SQL Server Modeling Services, aquí tenéis la nueva página en MSDN (algo de lo que os hablaré un poco más abajo…)

Cambios en Quadrant

Quizá el cambio más obvio en esta nueva versión de Quadrant sea el esquema de colores de la UI. Hasta el momento, predominaba el color gris y plateado, y éste ha sido sustituido por el azul…

Pasando a cambios más profundos dentro de Quadrant, ya que para nosotros lo que cuenta es el interior, encontramos como rasgo general el hecho de que la presencia del lenguaje M integrado en Quadrant es notablemente mayor que en la CTP anterior. Algunos lugares donde esta integración se pone de manifiesto son:

Es posible escribir código en M directamente en una hoja de trabajo (File – New – M File) y desplegar una base de datos desde aquí.
Si disponemos de una BD ya existente, a pesar de no haber sido creada con M, podemos inferir su modelo y obtener el código en M necesario para representarla completamente (esquema y datos instanciados). A partir de este punto, y siempre desde dentro de Quadrant, podremos modificar dicho código en M y actualizar la base de datos posteriormente con estos cambios.
Una de las características principales de Quadrant tradicionalmente ha sido su alta capacidad de configuración y personalización de las vistas sobre nuestros datos/modelos. En la CTP actual, además podemos visualizar estas configuraciones (modelos!!) como código en M, modificarlo y actualizarlo en el repositorio de Quadrant, pudiendo aplicar dichos cambios al instante en nuestras vistas (probad la opción del menú Workpad – View Source).
El lenguaje M es ahora el lenguaje predeterminado para la barra de consultas de Quadrant, que además incluye validación sintáctica para queries en M, a medida que las escribimos.

Al margen de estos cambios, ha habido otros tantos refinamientos a nivel de UI en Quadrant: auto-ajuste en el tamaño de nuestro panel de diseño, control de cambios en nuestros esquemas, resolución de conflictos entre versiones y manejo de errores.

Una de las características con la que os recomiendo jugar en esta nueva versión de Quadrant es el concepto de comandos y visores personalizados. Un ejemplo que ilustra esta nueva funcionalidad es el de “Media Library for Quadrant”, disponible aquí.

Otros cambios dignos de mención en esta versión de Quadrant:

Nueva consola para T-SQL.
Mejoras de rendimiento, incluyendo virtualización de tablas.
Soporte para autenticación en SQL Server.

Por si esto fuera poco, coincidiendo con el lanzamiento de esta CTP, nuestros compañeros PMs de Quadrant han publicado una serie de videos explicando algunos de los escenarios principales de Quadrant. Uno de mis favoritos es Quadrant UI Overview, el cual muestra cómo personalizar la visualización de datos en Quadrant de formas que ninguna otra herramienta actual es capaz de hacer. WOW!!

Para más información sobre Quadrant, podéis acceder a la nueva página de Quadrant en MSDN.

El lenguaje M y herramientas relacionadas

Bueno, llegamos a la parte de mi querido M… Esta vez, he procurado dejarlo para el final y trataré de ser breve, para posteriormente ampliar información en futuros posts… ; )

¿Qué hay de nuevo en M en esta CTP? Al margen de la integración con Quadrant de la que hablaba previamente (y que bastantes horas de trabajo ha supuesto…) podemos destacar las siguientes novedades:

Las entidades y colecciones ahora soportan evaluaciones de igualdad.
Nuevos operadores lógicos añadidos al lenguaje.
Concatenación de strings con el operador “+”.
Acceso a miembros en expresiones.
Proyecciones.
Soporte para el operador .Count
Conversiones de tipos.
Expresiones en la parte derecha de nuestras gramáticas (para los puristas del mundo de las gramáticas, expresiones en RHS).
Capacidad para referenciar instancias etiquetadas de entidades en expresiones, y también en sucesivos episodios de compilación (entre módulos importados/exportados, imágenes, etc.)

Resumiendo: Ha sido necesario reponer varias veces al día las máquinas de café en zonas cercanas a nuestros pasillos…!!

Al margen de estas novedades, hay una serie de “breaking changes” en algunas sentencias del lenguaje, azúcar sintáctico fundamentalmente, en lo referido a la creación de colecciones ( T* ahora es {T*}, T#n ahora es {T#n}, etc.). Podéis encontrar más información al respecto en las Release Notes.

Más allá de los cambios en el lenguaje, ha habido cambios interesantes en las herramientas que rodean a M, como por ejemplo en Intellipad: capacidad para comentar bloques completos de código, coloreado de sintaxis, y la capacidad de realizar ingeniería inversa sobre cualquier base de datos en SQL Server y obtener el correspondiente código en M, tal cual comentaba previamente.

Por último, hay novedades importantes en los tipos de proyectos en M dentro de Visual Studio 2010 Beta 2, pero eso os dejo que lo descubráis vosotros mismos… ;-)

MSDN: It’s All About Data

Este es el lema de las camisetas que hemos creado con motivo del PDC 2009 en nuestro equipo, y en cierto modo, es el perfecto resumen para hablar de los cambios en nuestra web de MSDN también. Como consecuencia de los cambios organizacionales, fusiones con otros equipos, asociaciones, etc. nuestro MSDN Oslo Developer Center ha pasado a ser más amplio y a cambiar de ubicación. Ahora, nos referiremos a él como Data Developer Center, y engloba tecnologías como ADO.Net EF, Astoria, XML, LINQ2SQL y, por supuesto, SQL Server Modeling!

Para terminar el post, no me queda más que recordaros la existencia de nuestro SQL Server Modeling Forum y sitio web de connect SQL Server Modeling Connect (previamente, M Spec Community).

HAPPY MODELING!!

Ya disponible Microsoft SDK for Facebook Platform… por fin!!

2009-11-11T00:04:48Z

Ya está disponible para descarga gratuita la SDK de Microsoft para desarrollo de aplicaciones en Facebook. Esta SDK proporciona un conjunto de librerías cuyas funcionalidades son capaces de competir con las de las SDKs ya existentes para Facebook desarrolladas en PHP y JavaScript.

Entre las posibilidades que se abren, se encuentra la capacidad para incorporar aplicaciones web desarrolladas en ASP.Net o Silverlight a Facebook, haciendo uso de las características sociales de Facebook (listas de amigos, informacion de nuestro perfil, etc.). Tambien es posible emplear estas librerías en nuestras aplicaciones de escritorio WPF y WinForms, para dotarlas de servicios de Facebook….

Más información, ejemplos, tutoriales, descargas… aquí:

http://www.infoworld.com/d/developer-world/microsoft-brings-silverlight-facebook-592

Saludos,

Channel 9 Expert-to-Expert: Don Box y Erik Meijer reflexionan sobre la historia de SOAP, la programación/modelado de datos, cómo no, el lenguaje M.

2009-10-31T09:40:00Z

Desde sus inicios, he sido un gran seguidor de la serie Expert-To-Expert de Channel 9, en la que el gran Erik Meijer realiza entrevistas profundamente técnicas sobre alguna tecnología concreta a sus respectivos creadores. Entre los capítulos de la serie que recuerdo con mayor cariño/admiración, debo destacar el capítulo sobre el futuro del lenguaje C# con Anders Hejlsberg, el de perspectivas sobre Paralelismo y Programación Concurrente con Joe Duffy, la importancia de los DSLs con “los grandes” Martin Fowler y Chris Sells, y los fundamentos del lenguaje Small Basic con su creador el amigo Vijaye Raji.

En esta ocasión, le ha tocado el turno a Don Box, quien se sienta un rato en nuestra antigua sala de Scrum (snif snif) a dialogar con Erik Meijer acerca de la historia de SOAP, las principales decisiones que motivaron su diseño allá por finales de los 90, y posteriormente hablan sobre los conceptos que hoy en día ocupan a Don: las tecnologías de programación/modelado de datos, y concretamente, el lenguaje M.

Enlace alternativo por si no se ve el video

¡Disfrutadla!

System.Collections.Concurrent: Estructuras de datos para computación paralela en .Net 4.0

2009-10-31T09:05:00Z

Una de las principales novedades introducidas en .net 4.0 y Visual Studio 2010 es la inclusión de mecanismos para la resolución de problemas de computación paralela. Este soporte se ha incorporado de muy diversas formas a nuestro querido framework, mediante la adición de nuevas instrucciones con capacidades de multiprocesamiento tales como los bucles paralelos (Parallel.Foreach, etc), operadores de consultas LINQ paralelos (PLINQ), invocaciones paralelas (Parallel_Invoke), encadenamiento de operaciones (Continuations), entre otras…

Tradicionalmente, los problemas fundamentales de la Programación Concurrente han sido la implementación de mecanismos efectivos para la comunicación y sincronización. Por una parte, perseguimos el objetivo de la compartición de información entre procesos (por ejemplo, el uso de los resultados de un proceso como valores de entrada para el otro), y por otra parte, buscamos que dicha comunicación a nivel de datos sea sincronizada (de modo que un proceso “espere” datos tan sólo en el momento adecuado, cuando estos estén disponibles, ya que de lo contrario se producirían situaciones como la espera ocupada (implementada habitualmente del modo: while(true) { TryToRead(buffer); }, que degradarían el rendimiento de nuestro programa).

Estas situaciones se han tratado de resolver mediante el uso de memoria compartida entre los distintos agentes/procesos/hilos de nuestra aplicación concurrente (escoged alguna de esas tres palabras dependiendo del nivel de granularidad de nuestro paralelismo, o del patrón de concurrencia que vayamos a emplear). Para controlar el acceso a esta memoria compartida, se han implementado mecanismos cuya función principal consiste en aislar en nuestro código aquellas instrucciones que acceden a esta memoria compartida, bien sea para modificarla o simplemente consultar su contenido (a estos conjuntos de instrucciones en nuestro código se les suele conocer también con el nombre de secciones críticas). Dentro de estos mecanismos de control para el acceso a la sección crítica, podemos encontrar diversas aproximaciones, como los semáforos, monitores o procedimientos para el paso de mensajes (que a su vez pueden ser de tipo bloqueante o no bloqueante).

El uso de estos mecanismos básicos ha sido a menudo una dificultad añadida a la tarea del programador, que ha sumado una complejidad excesiva al proceso de abstracción del problema concurrente y su implementación posterior.

Un enfoque alternativo a este problema consiste en el uso de abstracciones que nos proporcionen una implementación de estos mecanismos de control de acceso a las zonas de memoria compartida de forma totalmente transparente al desarrollador. De este modo, resultará más sencillo centrarse en la resolución del problema concreto que le ocupa, y abstraer los mecanismos de control de operaciones básicas de memoria sobre las cuales deberá apoyarse para alcanzar su solución pero que, por otra parte, resultan comunes a cualquier problema de tipo concurrente.

Es sobre este último grupo, estructuras de datos para computación paralela, sobre el que me gustaría hablaros en este post: las nuevas estructuras de datos con soporte para concurrencia introducidas en el .Net framework 4.0, concretamente en el namespace: System.Collections.Concurrent.

Dentro de este espacio de nombres, podremos encontrar las siguientes estructuras de datos:

BlockingCollection<T>: Se trata de una estructura que nos proporciona acceso a una colección de elementos. El acceso a esta colección se puede bloquear/desbloquear y también es posible acotar su capacidad.
ConcurrentBag<T>: Colección no ordenada de objetos.
ConcurrentDictionary<TKey, Value>: Colección de tuplas key-value a la que se puede acceder concurrentemente.
OrderablePartitioner(TSource): Permite configurar la forma en que prentendemos dividir los datos procedentes de un determinado origen en un conjunto de particiones. Idealmente, es la colección inicial a emplear ante problemas del tipo “divide y vencerás”
Partitioner(TSource): Similar al anterior, pero en esta ocasión dispondremos de una serie de métodos de particionado predefinidos, que podremos aplicar sobre arrays, listas y otros objetos enumerables.

Seguidamente, mostraremos un ejemplo del uso de estas estructuras de datos en un problema clásico de la Programación Concurrente: el problema del productor-consumidor.

Solución al problema del Productor-Consumidor empleando BlockingCollection<T>

Resumiendo a grandes rasgos este problema, trataremos de resolver una situación en la que dos tipos de procesos diferentes se comunican a través de un buffer de forma concurrente. Mientras uno de los dos procesos (el productor) escribe bloques de información en dicho buffer a medida que dispone de ellos, el otro (consumidor) se encarga de leerlos.

Existen diferentes variantes del problema: cambiando el número de productores o de consumidores presentes, modificando las características del buffer de forma que éste pueda tener un tamaño limitado o infinito, o también alterando la persistencia de los contenidos del buffer (por ejemplo, si un bloque de datos es borrado del buffer tras haber sido leído por un consumidor).

Vamos a ver cómo implementar algunos de estos patrones concurrentes mediante el uso de BlockingCollection<T>, proporcionada por el espacio de nombres de .Net 4.0: System.Collections.Concurrent, tal cual comentábamos antes.

1) Productor-Consumidor (1:1) con buffer ilimitado e información no persistente:

En este caso, crearemos dos nuevas tareas Producer y Consumer, haciendo uso del objeto Task (Task.Factory.StartNew). El Producer generará valores aleatorios que escribirá en el buffer mediante el uso del método Add() del mismo. Será necesario realizar una llamada al método CompleteAdding() para indicar que la actual operación de escritura sobre el buffer se ha completado.

Por su parte, el consumidor leerá los elementos presentes en el buffer iterando sobre el mismo. El método GetConsumingEnumerable() nos permite obtener nuestra BlockingCollection<int> como IEnumerable<int>. Por último, el consumidor se quedará a la espera de nuevos valores añadidos al buffer por parte del productor (consumer.Wait()).

using System;

using System.Collections.Concurrent;

using System.Threading.Tasks;

using System.Threading;

namespace ProducerConsumer

    class Program

        static void Main(string[] args)

            BlockingCollection<int> buffer = new BlockingCollection<int>();

            var producer = Task.Factory.StartNew(() =>

                    Random rand = new Random();

                    for (int i = 0; i < 3; i++)

                        Thread.Sleep(1000);

                        int item = rand.Next();

                        buffer.Add(item);

                        Console.WriteLine("Productor escribe {0} , item);

                                            en el buffer"

                    buffer.CompleteAdding();

});

            var consumer = Task.Factory.StartNew(() =>

                foreach (var item in buffer.GetConsumingEnumerable())

                    Console.WriteLine("Consumidor lee {0} , item);

                                            del buffer"

});

            consumer.Wait();

            Console.ReadLine();

El resultado podemos verlo a continuación, el productor genera tres valores aleatorios y los escribe en el buffer, mientras que el lector leerá cada uno de ellos del buffer y los muestra.

2) Productor-Consumidor (1:1) con buffer ilimitado e información persistente:

En este segundo escenario, las restricciones del problema serán las mismas que en el caso anterior, con la única diferencia de que la información escrita en el buffer no será eliminada después de que el consumidor la haya utilizado.

Para ello, tan sólo deberemos cambiar una línea en el código mostrado anteriormente, en lugar de acceder en el consumidor al buffer mediante el metódo buffer.GetConsumingEnumerable() accederemos de la siguiente forma: foreach(var item in buffer)

3) Productores – Consumidores (N:N) con buffer ilimitado e información no persistente.

En este caso, la única diferencia con respecto a los escenarios anteriores es que deberemos “envolver” la creación del productor y del consumidor en sendos bucles, para generar el número deseado de productores y de consumidores.

4) Productores-Consumidores (N:N) con buffer limitado e información no persistente.

La última variante que veremos hoy sobre el problema del Productor-Consumidor es la relacionada con la limitación del tamaño de nuestro buffer. En este caso, limitaremos el número de elementos de nuestra BlockingCollection<int>.

Para ello, únicamente deberemos emplear una de las sobrecargas del constructor de esta clase, indicando el número de elementos tope de la colección:

BlockingCollection<int> buffer = new BlockingCollection<int>(3);

De este modo, hemos limitado a 3 el número de elementos que nuestra colección puede contener. Por tanto, si el productor desea escribir en este buffer y el número de elementos ha alcanzado el máximo, el propio productor se bloqueará, dejando paso al consumidor para que consuma un valor, y posteriormente retomando el control sobre el buffer para escribir el valor que tenía preparado.

La elección de un tamaño apropiado para nuestro buffer, así como el uso de una cadencia de lectura/escritura (número de items afectados por cada operación de acceso al buffer) serán dos decisiones importantes a tomar en este caso. Teniendo en cuenta que, generalmente, las situaciones de bloqueo tienen un efecto positivo y otro negativo. En el lado positivo de la balanza, un bloqueo supone una resolución a un conflicto coherente con la lógica de nuestra solución, pero por otra parte, supone cierta degradación en el rendimiento de nuestra aplicación concurrente.

Happy Coding!

Calentando motores para el PDC 09

2009-10-06T01:00:00Z

Queda menos de un mes y medio para la próxima edición del PDC, a celebrarse en Los Angeles (California) entre el 17 y el 19 de Noviembre, y a pesar de que son muchas las novedades que veremos allí, me gustaría anunciaros las sesiones relativas a Oslo nuestra plataforma de modelado: lenguaje M, Quadrant y Repositorio.

Por el momento, tenemos confirmadas las siguientes sesiones (a falta de alguna más, todavía en proceso)…

Data Programming and Modeling for the Microsoft .Net Developer: En esta charla eminentemente práctica, los amigos Don Box y Chris Anderson mostrarán las mejoras introducidas en forma de herramientas, lenguajes y frameworks para simplificar la forma de modelar, consumir o producir datos. Imprescindible asistir a esta charla si quieres estar informado acerca del futuro en el ámbito del modelado y programación sobre datos utilizando productos y servicios de Microsoft.
Microsoft project code name “M”, the Data and Modeling Language: Esta sesión servirá para repasar los conceptos fundamentales del lenguaje de modelado M, cómo crear DSLs y esquemas de datos, y también explorará el futuro del lenguaje M, en el cual ambos conceptos convergerán en un único lenguaje, así como otro conjunto bastante interesante de características. La sesión será presentada por Don Box y Jeff Pinkston (a.k.a. Pinky)
Building Data-Driven applications using Microsoft code name Quadrant and code name M: “El gran” Chris Sells nos contará, junto al no menos grande Doug Purdy, cómo podemos emplear el diseñador Quadrant y el propio lenguaje M para interactuar con SQL Server con el fin de crear aplicaciones dirigidas por datos, involucrando funcionalidades como el uso de vistas dinámicas y capacidades de edición en aplicaciones multi-usuario. Además podremos aprender cómo el uso combinado de ambas herramientas permite acelerar y simplificar el ciclo de desarrollo de las capas de datos en nuestras aplicaciones SOA desarrolladas en plataforma .net. Por último, veremos cómo personalizar Quadrant y M para proporcionar experiencias de desarrollo/usuario que sean domain-specific.
Microsoft project code name “Repository”, using metadata to drive application design, development and management: El repositorio es probablemente la tecnología perteneciente a Oslo de la que menos se ha hablado en los últimos meses y, sin embargo, se trata tal vez de la que tendrá potencialmente un mayor impacto en la arquitectura de nuestras aplicaciones. Mediante el uso de un repositorio central de gestión de metadatos (modelos, configuraciones, etc.), podremos incrementar el control sobre nuestras operaciones de desarrollo, despliegue, mantenimiento y gestión de aplicaciones empresariales. Algunas de las funciones que el uso de este repositorio nos proporciona son: capacidad para realizar análisis de impacto, validación de la arquitectura de nuestro sistema, gestionar el despliegue y configuración de nuestras aplicaciones empleando UML, CLR, Identity, etc. Esta sesión correrá a cargo de Shoshanna Budzianowsky y Keith Short.

Podéis encontrar la información completa sobre estas y otras sesiones en la web oficial del evento: http://www.microsoftpdc.com

Por último, adelantaros que en próximos posts (pre y post PDC) os hablaré largo y tendido de todos estos conceptos, incluyendo presentaciones, demos, vídeos y algunas cosas más ;)

Have fun!

Update: ¿Qué hay de nuevo por Oslo?

2009-08-19T11:06:00Z

Hace ya más de un mes desde mi último post, concretamente cinco semanas… Para cumplir con mi promesa de “al menos un post al mes” (espero que este mes pueda escribir al menos dos más que guardo en la recámara desde hace varias semanas pero para los que no he encontrado el momento oportuno todavía), vuelvo a la carga para actualizar con las últimas novedades en torno a Oslo. `

[Aviso de antemano: Es un post bastante largo y denso, aún así te agradeceré que lo leas y aportes el feedback que te parezca oportuno, será bien recibido.]

Hablando desde la “línea de combate” del proyecto, hace unos días que terminamos una etapa de desarrollo bastante sustancial en nuestro calendario. Esto incluye nuevas características tanto en el lenguaje M como en Quadrant y nuestro repositorio relacional de modelos, de las cuales os hablaré próximamente. En este momento, dedicamos nuestros esfuerzos a estabilizar todas estas nuevas funcionalidades que apenas acaban de aterrizar en el proyecto, cerrar algunos “asuntillos” pendientes y, básicamente, realizar una parada en boxes para repostar y prepararnos para volver a acelerar en el desarrollo, con una meta parcial en la mente de todos nosotros: PDC 2009.

En otro orden de cosas y hablando desde una perspectiva puramente organizativa del proyecto, la novedad principal es la asociación del equipo de Oslo con el equipo de Data Programmability (responsables de algunas tecnologías de acceso programático a datos como son ADO.Net, Astoria, EDM y Entity Framework).

Este movimiento nos aporta una serie de ventajas que repercuten en una mayor especialización y mejor posicionamiento de nuestras tecnologías, que finalmente resultarán en un beneficio global en el ecosistema de desarrollo en .Net framework.

Para comprender mejor el alcance de dichas mejoras, conviene repasar la evolución de Oslo, sus líneas generales y, por supuesto, también la experiencia adquirida a través del feedback recibido desde la comunidad.

Hace ya casi dos años desde el primer anuncio oficial sobre Oslo, realizado en la SOA & BP Conference, en Octubre de 2007 en Redmond. En aquel momento, nos referimos a Oslo como un conjunto de esfuerzos combinados a través de diferentes tecnologías y productos, para simplificar el ciclo de desarrollo de aplicaciones. Dichos esfuerzos se verían reflejados en diferentes tecnologías existentes: Visual Studio, .Net framework, BizTalk y SQL Server.

Acercándonos un poco más en la línea cronológica al momento actual, el siguiente punto de inflexión tuvo lugar hace casi un año, en el PDC 2008. En dicho evento, realizamos una serie de sesiones presentando las diversas tecnologías de modelado que formaban parte de Oslo, así como publicamos nuestra primera CTP. Al aproximarnos a este hito, nos dimos cuenta de algunos aspectos reseñables, principalmente en la forma de canalizar nuestro discurso para que llegara de forma clara y unívoca al público: en primer lugar, el hecho de englobar bajo el codename Oslo diferentes tecnologías como BizTalk, Workflow Foundation, herramientas de modelado (M & Quadrant), etc, generaba cierto grado de confusión en la audiencia. De modo que, para evitar dicho efecto, optamos por canalizar diferentes tecnologías de Oslo en nuevas versiones de productos ya existentes, en lugar de crear una nueva generación de herramientas bajo el nombre de Oslo.

Debido a esto último, algunas de las tecnologías integrantes del proyecto en su origen ya han sido liberadas. Cuando hablamos de algunas partes de .Net framework 4.0, como las nuevas versiones de Workflow Foundation y WCF, BizTalk Server 2009, el servidor de aplicaciones Dublin, MEF o la pila unificada de XAML; debemos tener en cuenta que dichas tecnologías formaron parte del proyecto Oslo en su momento, y por tanto, la motivación con la que fueron desarrolladas, el objetivo común subyacente, se encuentra totalmente alineado con las metas de Oslo.

Realizando un poco de autocrítica sobre este proceso, encontramos aspectos positivos y negativos. En el lado positivo, la habilidad del equipo para liberar partes del proyecto consolidadas (WCF 4.0, WF 4.0, etc) que fueran introduciendo en el ecosistema de desarrollo algunas de las metas transversales de Oslo, mientras que otras partes del proyecto aún en fase temprana han ido evolucionando de forma apropiada (M, Quadrant). En el lado negativo de la balanza, quizá sería reprochable el hecho de haber mantenido el codename Oslo activo durante mucho tiempo, y por ello haber contribuido a la confusión de la que os hablaba un par de párrafos más arriba… En el momento actual, emplearemos el codename Oslo para referirnos única y exclusivamente a la plataforma de modelado: M, Quadrant, repositorio.

La piedra angular de Oslo fue desde sus orígenes la evolución hacia la creciente utilización de contenidos declarativos en plataforma .Net (XAML), que fueran dinámicos y, al mismo tiempo, que pudieran ser empleados para dirigir nuestras aplicaciones y entornos de ejecución (MDD/MDA). Si pensamos en el repositorio de modelos de Oslo, concretamente, siempre hemos hablado de un repositorio relacional de modelos, implementado sobre SQL Server. Dicho repositorio contiene (meta)datos, hablando sobre datos que contienen información sobre nuestras aplicaciones y empleo el término “meta” entre paréntesis puesto que a menudo también induce a confusión el uso de dicho prefijo. Dichos metadatos son fácilmente maleables mediante nuestras tecnologías de modelado: M y Quadrant. (podéis encontrar una explicación profunda sobre esto en este artículo, y en estas dos presentaciones: 1 y 2)

Continuando con este análisis desde una perspectiva evolutiva del proyecto, cabe destacar que, especialmente en este último año, existe un hecho que se ha puesto notablemente de manifiesto para nosotros. Este hecho es la estrecha vinculación entre nuestra plataforma de modelado y la pila de programación de acceso a datos (ADO.Net, EF/EDM, Astoria, etc.).

Tal es así, que consideramos necesaria una alineación consistente entre ambos “mundos”, y es por ello que decidimos realizar esta asociación a nivel organizativo.

Por tanto, y después de una reflexión que espero no os haya aburrido demasiado…

¿Qué significa este cambio para los mortales desarrolladores en plataforma .Net?

Significa que, de ahora en adelante, vais a escuchar hablar sobre el lenguaje M de una forma mucho más ligada a EDM y Entity Framework; de la herramienta de modelado Quadrant asociada a diferentes herramientas de Visual Studio y, por último, podréis apreciar cómo el concepto un tanto abstracto de MDD/MDA (quizá rayando lo esotérico en algunos casos, jeje) evoluciona de la mano de los avances que se produzcan en las versiones futuras de .Net framework.

Y para terminar, hablando del futuro y puesto que ya he citado el PDC 2009 (por ahí comenzó el post y por ahí va a terminar), os anuncio una excelente sesión en la cual hablaremos largo y tendido sobre el estado actual del proyecto (Data Programming and Modeling for the Microsoft .Net Developer), que será impartida por los señores Don Box y Chris Anderson.

Esperamos veros por allí!!

PD.: Para aquellos ávidos de más información al respecto de estas novedades, podéis echar un vistazo a este post de Doug Purdy, “The Man” :), quien además de dominar mejor que yo la lengua de Shakespeare, explica todo ello en una mejor prosa.

Teleriks crea su propia implementación de “LINQ to M”

2009-07-13T06:03:00Z

Uno de los aspectos que más me apasionan de la comunidad de desarrolladores que se han animado a probar Oslo hasta el momento es la cantidad de herramientas y tecnologías que, haciendo uso de Oslo, lo complementan en escenarios concretos o proporcionan funcionalidades adicionales bastante interesantes.

Buena muestra de ello es la implementación de LINQ to M, creada por Teleriks y lanzada la semana pasada, que nos permite realizar consultas sobre datos estructurados en M (MGraph) con un estilo muy similar al de LINQ to XML. Veamoslo con algo más de detalle…

El formato de datos “MGraph”

Como ya hemos comentado en posts previos, el lenguaje M, que en un futuro no muy lejano será un único lenguaje, está hoy por hoy dividido en tres “dialectos”: MSchema, MGrammar y MGraph.

M es un lenguaje cuya principal función es la de definir datos y restricciones sobre dichos datos, todo ello en forma de texto. Existe una conexión “emocional” entre la gran mayoría de desarrolladores y el formato de tipo texto, ya desde tiempos remotos los desarrolladores hemos vivido en entornos de tipo texto (consola, MS-DOS, etc), y además hemos representado nuestras ideas y algoritmos en forma de texto, mediante el uso de lenguajes de programación de propósito general (C, C++, C#, Java, etc.), o lenguajes de etiquetas/marcado para un dominio específico como por ejemplo HTML, XML o XAML. Adicionalmente, podemos pensar en un texto redactado en lengua castellana como otra representación de datos de forma textual, si bien, esta representación en lenguaje natural sigue unas reglas gramaticales algo menos estrictas que los lenguajes de programación y de marcado, así como una estructura textual (párrafos, signos de puntuación, etc) bastante más flexible que en los lenguajes citados con anterioridad.

Considerando todos estos lenguajes, el elemento diferenciador entre cada uno de ellos no es ni más ni menos que el conjunto de reglas que nos permiten expresar una serie de información en dicho lenguaje y también estructurar dichas ideas de forma más o menos “mecánica”. Esta forma mecánica de representación de información textual se lleva al extremo en un lenguaje como XML, el cual sigue una sintaxis muy estricta que lo convierte además en un lenguaje complejo de entender para una persona.

No obstante, todos ellos comparten una característica común, bastante obvia, pero conviene tenerla siempre presente: todos estos lenguajes nos permiten representar información en formato de texto.

Si pensamos en la relación entre texto y datos, el lenguaje M vive en dicha intersección. Por una parte, nos permite representar información en una serie de lenguajes proporcionados “de serie” y, por otra parte, nos permite crear fácilmente nuestras propias reglas gramaticales para transformar un conjunto de información textual poco estructurada (por ejemplo, un texto en castellano) en otro conjunto de información textual organizada de la forma que a nosotros nos resulte más cómoda: traducida a scripts T-SQL como en el caso de MSchema, a una representación en forma de grafo acíclico que conocemos con el nombre de AST y que constituye el “dialecto” MGraph, o a cualquier otra representación que definamos nosotros mismos mediante nuestras gramáticas creadas con MGrammar.

Una vez tengamos la información en un formato optimizado para su procesamiento, disponemos de diversas opciones para consumir dicha información desde nuestros entornos de ejecución y aplicaciones. En esta ocasión, nos vamos a centrar en la implementación de LINQ to M (MGraph) creada por Teleriks.

A continuación podemos ver un fragmento válido de información representada en formato MGraph, en la cual estamos describiendo un conjunto de vuelos e información sobre cada uno de ellos (código de vuelo, operador del vuelo, origen y destino).

{
      {Id=1,Origen=""Alicante"",Destino=""Madrid"",Operador=""Iberia""},
      {Id=2,Origen=""Oslo"",Destino=""Barcelona"",Operador=""SAS""},
      {Id=3,Origen=""Seattle"",Destino=""New York"",Operador=""Delta""},
      {Id=4,Origen=""Paris"",Destino=""Amsterdam"",Operador=""Air France""},
      {Id=5,Origen=""Londres"",Destino=""Vancouver"",Operador=""British Airways""},
      {Id=6,Origen=""Tokyo"",Destino=""Shanghai"",Operador=""Air China""},
      {Id=7,Origen=""Alicante"",Destino=""Madrid"",Operador=""Vueling""},
      {Id=8,Origen=""Alicante"",Destino=""Madrid"",Operador=""Spanair""}
}

Para este ejemplo, en el cual vamos a consumir la información directamente en tiempo de ejecución desde nuestro código C#, lo que vamos a hacer es almacenar este fragmento de código M en un const string.

Además, deberemos agregar en nuestro proyecto una referencia a Telerik.M.Core.dll y añadir una sentencia using Telerik.M.Core; en nuestro código, a fin de poder emplear estas funcionalidades. (esta dll forma parte de la descarga de LINQ to M).

Para consumir nuestro código M en forma de sentencias LINQ, deberemos en primer lugar cargar nuestro origen de datos, mediante el uso del objeto QueryContext, tal cual se muestra a continuación.

Con esto simplemente ya podríamos hacer uso de nuestra variable vueloM como origen de datos, por ejemplo para asignarlo a dicha propiedad DataSource en un objeto de tipo Grid, y visualizar nuestros registros de vuelos.

No obstante, si deseamos obtener Intellisense, coloreado de sintaxis, y demás servicios adicionales del lenguaje, deberemos crear una clase en C# que tenga la misma estructura que la información definida en M, para lo cual realizaremos algo parecido al siguiente código.

Gracias a esta definición, ya podemos hacer uso de características avanzadas del IDE, como por ejemplo Intellisense. En la siguiente captura podemos observar cómo realizar consultas LINQ sobre nuestra colección de datos en M, obteniendo información contextual en VS. (click sobre la imagen para una vista ampliada).

Terminaremos la consulta para visualizar los vuelos Alicante – Madrid ordenados de forma ascendente por nombre de Operador, y mostraremos dicha información en nuestra consola…

Para más información, podéis acceder al blog de Stephen Forte, CEO de Telerik, quien nos describe otra aplicación similar al ejemplo que os he mostrado aquí, y también nos cuenta sus experiencias con la SDK de Oslo durante los últimos meses.

También puedes descargar la implementación de LINQ to M en este enlace. Y el código completo de mi ejemplo aquí.

Saludos,

Materiales de la presentación sobre Oslo en MS Iberica

2009-07-02T10:35:00Z

Tal cual comentaba hace unos días en una entrada previa, este martes tuve la oportunidad de realizar un workshop sobre Oslo en las oficinas de MS Iberica en Madrid. En la siguiente carpeta de skydrive os dejo los materiales de la misma, presentación y archivos de código M empleados durante la demo.

Gracias a todos aquellos que asistieron a la sesión por el interés mostrado y especialmente a César De la Torre, por su colaboración y organización del evento, así como al resto de compañeros de Madrid por su gran acogida, "as always".

Saludos @Madrid :)

Small Basic v0.5: Ahora con localización en Español... y más!!

2009-06-18T08:06:00Z

Hoy se ha liberado una nueva versión del lenguaje Small Basic. Entre las novedades más destacadas está que ahora está localizado para Español, además de Inglés. Además, las siguientes características han sido añadidas al lenguaje, en base al feedback recibido por la comunidad:

Mejoras en el IDE: Función "Buscar", indicador de línea y columna, botón para "Guardar como...", etc.
Mejoras en el lenguaje: Al margen del nuevo soporte para Español, quizá la más destacada sea el soporte de arrays... multidimensionales! :)

Para aquellos que no hayan escuchado hablar de Small Basic todavía, comentar que se trata de un lenguaje bastante simple (apenas 15 keywords), cuyas ideas base derivan de Visual Basic, pero su propósito es eminentemente pedagógico. Podéis encontrar un excelente vídeo en Channel 9, de la serie Expert-to-Expert en la que su creador, Vijaye Raji y Chris Anderson (compañeros en el equipo de Oslo), nos explican en detalle las características del lenguaje junto al gran Erik Meijer.

También dispone de una página en MSDN y un grupo en Facebook a través del cual se anuncian las novedades en torno a este proyecto.

Keep up the great work, Vijaye!

[Workshop en Madrid] Introducción a “Oslo”: El Futuro en el Modelado de Aplicaciones

2009-06-12T01:16:00Z

El verano siempre es una buena época para visitar Alicante durante unos días. Como Madrid está de paso, aprovecharemos para hablar un rato sobre Oslo. Aquí están los detalles del evento:

En este Workshop revisaremos los conceptos de MDD (Model Driven Development) y derivados (Model Driven SOA, etc.) y presentaremos la propuesta de futuro de Microsoft: "Oslo" (codename, actualmente en estado Beta), recorriendo las diferentes tecnologías que nos ofrecerá (lenguaje de modelado textual M, herramienta visual Quadrant y repositorio relacional de modelos). Al terminar la sesión, los asistentes serán capaces de responder a las siguientes dos preguntas: ¿Qué es Oslo? Y… ¿Por qué debería prestarle atención de ahora en adelante?.

FECHA: 30 de Junio

LUGAR: Oficinas Microsoft Madrid – Sala Marie Curie.

AGENDA
9:00 - 9:30 - Registro
9:30-10:45 - Model Driven Application, MDD y la propuesta de futuro de Microsoft: "Oslo". (César De La Torre, Architect Evangelist, MS Iberica)
10:45-11:15 - Cafe
11:15-14:00 - "Oslo" en detalle, Lenguaje M, Quadrant, Repositorio. (Miguel Llopis, SDET Team Oslo, MS Corp)

Link de registro: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032417769&%3bCulture=es-ES

Esperamos veros por allí, :)

Publicada la CTP de Mayo de Oslo: Quadrant, mejoras en el lenguaje M, modelos para UML 2.1 y CLR... y más!

2009-05-27T04:52:00Z

Los lectores habituales de este blog probablemente hayan notado durante las últimas semanas un considerable descenso de la actividad en el mismo (apenas un post al mes durante los últimos 2 meses). Una de las causas que más ha influido en ello es el intenso trabajo que los miembros del equipo de Oslo hemos llevado a cabo, con el objetivo de llegar a este “hito”.

Hoy, 26 de Mayo, hemos alcanzado una “meta parcial” en nuestro camino, hemos publicado nuestra tercera CTP: la CTP de Mayo de Oslo. Se trata de una “major release” CTP que incluye mejoras bastante considerables respecto a las anteriores. Entre estas mejoras, cabe destacar al menos las siguientes:

Instalador unificado para todos los elementos que componen nuestra CTP: IntelliPad, Lenguaje M, herramientas de línea de comandos, repositorio de modelos…

Un único compilador para el Front-End del lenguaje M (a.k.a. One M to rule them all!). Hasta el momento, disponíamos de dos compiladores diferentes para MSchema (m.exe) y para MGrammar (mg.exe), ahora ambos son sólo uno: m.exe
Primera versión pública de Quadrant: Esta es nuestra primera release en la cual incluímos Quadrant, nuestra herramienta gráfica para consultar y modificar datos del repositorio. Podéis encontrar información al respecto en la nueva sección de Quadrant en nuestra web de MSDN.
Primera versión pública de los modelos de dominio para UML 2.1 y CLR.
Nuevas funcionalidades en el lenguaje M y redefinición de algunas ya existentes, en base al feedback recibido por parte de la comunidad y a través de la M Specification Community.

En próximos posts explicaré detalladamente cada una de estas novedades, ya que sin duda suponen cambios significativos y que esperamos que sean de vuestro agrado. Por el momento, os animamos a que descarguéis e instaléis la nueva CTP y nos contéis a través de nuestros foros vuestras impresiones.

Enjoy!

Cliente de Facebook para Windows Mobile… por fin!! :)

2009-05-10T13:06:00Z

Desde hace unos dias disponemos de un nuevo cliente de Facebook para Windows Mobile 6. Descargadlo y enviad vuestro feedback a traves de esta pagina de Facebook y podreis ganar un HTC Touch Pro!!

Algunas capturas… :)

Enjoy!!

El Profesor Stephen Hawking evoluciona favorablemente...

2009-04-22T07:31:00Z

Durante las primeras horas de la mañana de este Lunes, apareció en Internet la noticia de la hospitalización inmediata de Stephen Hawking, en el Addenbrooke's Hospital de la Universidad de Cambridge (Inglaterra), debido a complicaciones en su estado de salud.

El Dr. Hawking, que el pasado mes de Enero cumplió 67 años, sufre esclerosis lateral amiotrófica desde los 21 años. Este hecho ha reducido progresivamente su capacidad motora pero no ha sido capaz de frenar en ningún modo a una de las mentes más poderosas de nuestro planeta; hasta el punto de ser considerado por muchos como el físico teórico de mayor importancia en la Historia. Para aquellos que no hayan disfrutado de sus obras, recomiendo la lectura de "The Illustrated Brief Story of Time" y "The Universe in a Nutshell" (el Universo en un vistazo), dos de esos libros que uno no puede soltar de las manos hasta que los termina de leer.

La nota informática de este post radica en el hecho de que, a raíz de la aparición de esta noticia, el tráfico en Internet relacionado con este gran hombre ha sufrido un gran incremento y, como consecuencia de ello, los administradores de su sitio web oficial (habitualmente repleto de artículos, anuncios sobre sus próximas conferencias, enlaces a sus obras, biografía, etc.) han decidido sustituir este contenido por una única página en HTML en la cual, diariamente, añaden una breve actualización sobre su estado de salud, a fin de evitar problemas de saturación en su servidor... Es curioso ver bajo qué inescrutables circunstancias salen a relucir posibles deficiencias en los planes de pruebas de una aplicación informática, como en este caso las pruebas de Stress sobre un sitio web...

Me gustaría para cerrar el post mandar un fuerte abrazo al Profesor, y mis mejores deseos de pronta recuperación para él, su esposa y sus tres hijos: Keep fighting, Mr Hawking!

Mis pensamientos sobre cocina, Office, Windows 7, Internet Explorer 8 y la gestión de grandes proyectos en Microsoft

2009-03-23T07:35:00Z

Me encanta cocinar. Es un hecho. Y desde que abandoné la casa de mis padres para retomar la aventura de construir Oslo con unos cuantos amigos, hace algo más de 6 meses, y vivo independizado en Vancouver, este hecho se ha convertido además en clara necesidad vital. Sin embargo, en este post, no voy a hablaros sobre Oslo como últimamente acostumbro a hacer, no voy a hablar de ningún gran proyecto software concreto; o, tal vez, hable un poco sobre todos ellos.

Retomando mis aficiones culinarias, hay algo en el proceso de preparación de una buena Paella Alicantina que se asemeja mucho a la ingeniería de procesos en grandes proyectos software. Desde el momento en el que captamos los requerimientos de nuestro proyecto (hora a la que queremos comer, cantidad de raciones a preparar, etc.), hasta que realizamos las estimaciones del proyecto (cantidades de cada uno de los ingredientes, tiempo de cocción, etc.) el razonamiento no difiere demasiado del que llevamos a cabo para construir software. Existen además una gran cantidad de técnicas que el tiempo y la experiencia previa nos aportan, de forma que podamos medir con una mayor precisión los riesgos de cada fase del proceso. De este modo, seremos capaces de determinar aquellas tareas críticas a las que deberemos dedicarnos de manera exclusiva, así como aquellas que podamos pararelizar y por tanto ser capaces de realizar de forma simultánea (tales como pelar una cabeza de ajos mientras freímos ñora picada, e incluso calentar agua para cocer el arroz mientras el resto de ingredientes ya están en la paella…). Eventualmente, también seremos capaces de cocinar al mismo tiempo que buscamos en los armarios de la cocina algunos de los ingredientes para añadir al proceso, e incluso nos sentiremos cómodos y consideraremos esta capacidad como algo natural, proporcionado por la experiencia. Por último, cuando cocinemos varios platos al mismo tiempo, deberemos hacerlo al ritmo adecuado para que todos ellos estén preparados en el momento preciso: la hora de comer. Este proceso, ya de por sí algo complejo, tiende a incrementar su nivel de dificultad cuando cada una de estas tareas o platos son elaborados por personas diferentes, incluso por equipos de personas diferentes.

De igual forma sucede en el mundo del desarrollo software. Existen diferentes formas de organizar y coordinar a esas personas, a esos equipos, con el fin de convertir el lanzamiento de un gran producto en un auténtico homenaje a la cooperación, sincronización y coordinación transversal. Analizando globalmente la estructura de los equipos de producto en Microsoft, encontraremos dos modelos principales de organización, a través de los cuales un proyecto evoluciona desde su fase de incubación hasta alcanzar su madurez.

Pensemos en un gran proyecto como Office, compuesto actualmente por más de una veintena de proyectos (yo ya he perdido la cuenta). Si recordamos los orígenes de este producto, veremos que “en la noche de los tiempos”, no existía Office… Existía Word, y Excel, y Access, y más adelante PowerPoint y OneNote, y… (paremos aquí de contar, ya que quiero acabar algún día este post). Office es uno de los grandes proyectos de Microsoft, junto con Windows, Visual Studio y unos cuantos más, que han experimentado una transición entre estos dos modelos, visiones, filosofías, enfoques para gestionar un gran proyecto software.

El primero de estos modelos es el conocido como Product Unit Management (PUM). Este modelo es probablemente el más habitual entre todos los equipos en Microsoft, y se basa en la definición de una unidad de producto (conjunto de arquitectos, desarrolladores, testers, program managers y otros roles implicados) como órgano independiente y hegemónico en la planificación de todas las fases del proyecto, desde su incubación hasta su lanzamiento. Generalmente, estas unidades de producto no dependen de otras, a menos que exista una tecnología concreta empleada por esta PUM que se encuentre próxima a su fecha de lanzamiento. Este independencia convierte al modelo PUM en el modelo óptimo en términos de agilidad, de “time-to-ship” (tiempo hasta el lanzamiento) y capacidad de respuesta ante la competencia. Sin embargo, es deficiente en términos de colaboración entre proyectos, estandarización de infraestructuras tales como automatización de builds, o ejecución de pruebas automatizadas. Esto genera un aumento de los costes para estas tareas, que si bien se llevan siempre acabo, en estos casos resultan más laboriosas para el grupo de producto al tener que duplicar esfuerzos de otros grupos. A menudo, encontramos este modelo organizativo en pequeños equipos, como el equipo de Surface, de Zune, de Live Mesh… También en proyectos más grandes como es el caso de Oslo (donde disponemos de distintas organizaciones PUM, para el lenguaje M, para Quadrant, etc.), e incluso en proyectos monstruosos (en volumen, se entiende) como es el caso de Windows u Office. En este último tipo de proyectos, generalmente el modelo de independencia a nivel de PUM se adopta para nuevas características del producto que se encuentran todavía en fase de incubación…

A medida que un producto madura, los equipos habitualmente crecen de tamaño y la centralización de algunas tareas e infraestructuras para mejorar la eficiencia y reducir costes sucede de forma natural. Este modelo recibe muchos nombres, pero tal vez el nombre más apropiado sea el de “modelo de equipos coordinados/compartidos” (en Inglés lo conocemos como “Shared Team”). Con este enfoque, muchas tareas y características del producto se asignan a un equipo compartido central y el resto de equipos que participan en el proyecto deben sincronizarse con este equipo central, o por el contrario no serán capaces de finalizar el proyecto y lanzar un producto con todas las características previstas.

Office es un gran ejemplo de adopción de este modelo, tal cual comentábamos unas cuantas líneas más arriba. Desde el día en que alguien tuvo la gran idea de que todas las aplicaciones de productividad deberían empaquetarse juntas y vender el producto como una suite ofimática, la jerarquía dentro del equipo de Office ha evolucionado hacia este segundo modelo. De hecho, este equipo compartido recibe el nombre de Office Shared Services Team (OSS).

Dentro de la división de Office, existen diferentes grupos de producto (como Word, Excel, Sharepoint, etc.) cuya labor es centrarse en el desarrollo de cada una de estas aplicaciones y ofrecer un producto de gran calidad, capaz de satisfacer a los clientes. Y frente a este tipo de grupos, encontramos otros grupos transversales encargados de una serie de características del producto comunes a todas las aplicaciones de la suite (Interfaz de Usuario, Infraestructura de Builds, Documentación, Internacionalización, etc.). Combinando los esfuerzos de ambos tipos de grupos, se consigue por una parte innovar en cada aplicación y mejorarla de una a otra versión, a la vez que mantener una coherencia a nivel de producto en toda la suite, y también alinear fechas de lanzamiento del producto. De igual modo, la creación de estos grupos transversales nos proporciona una mejor visión a la hora de implementar estrategias de diseño, desarrollo y pruebas en el conjunto de la suite de Office.

Existen muchas variaciones y modelos intermedios entre ambos enfoques de organización. Siendo sinceros, probablemente no seamos capaces de encontrar dos grupos en Microsoft con una estructura idéntica entre sí. Sin embargo, las filosofías y buenas prácticas de estos dos modelos son la base ideológica sobre la que todos los equipos se apoyan.

A menudo, desde fuera de Microsoft, esto puede parecer una batalla, un cierto grado de rivalidad entre equipos. Pensemos en equipos de desarrollo como el equipo de C# y el equipo de Visual Basic, la forma en que alternativamente van añadiendo características nuevas a su lenguaje respectivo y la consiguiente “respuesta” del otro grupo. Afortunadamente, la colaboración entre estos dos grupos (y entre otros muchos!) es cada vez mayor a nivel global dentro de Microsoft, y en lugar de ser transatlánticos independientes luchando por llegar primeros a la otra costa, son auténticas flotas navales avanzando de forma coordinada con un mismo rumbo…

Una estructura muy similar a la explicada para Office sería la existente en la división de Windows. Espero y deseo que a estas alturas todos conozcais y sigais de manera habitual el blog Engineering Windows 7, en el que nuestros amigos de Windows 7 encabezados por Steven Sinofsky (Senior VP de Windows, de hecho), nos cuentan muchas de las decisiones de diseño (y también de ingeniería de procesos), que se toman a lo largo del desarrollo de un proyecto de semejantes dimensiones.

Valga el párrafo previo para darme la oportunidad de mencionar el reciente lanzamiento de Internet Explorer 8 (Release Candidate). Si acudís a la web de descargas, observaréis que la versión para Windows 7 no está disponible para descarga, debido a que deben llevarse a cabo una serie de pruebas adicionales sobre ciertas características exclusivas de Windows 7 (tales como interfaz de usuario táctil, etc. podéis leerlo en la propia web de descarga)… como podréis adivinar, este tipo de característica pertenece a uno de esos “grupos transversales” de los que os hablaba arriba… y antes de que nadie se escandalice por el hecho de no disponer aún de una versión RC de IE8 en Windows 7, podréis leer entre líneas en este post la explicación razonada y metodológica de este hecho… Es “inminente” la aparición de una versión RC de Windows 7 que incluya IE8, así como otras características excepcionales en las que están trabajando.

Comensales, ocupen sus asientos, y dispónganse a degustar esta suculenta paella llamada Windows 7. :)

Disponibles los vídeos de todas las sesiones del Mix ‘09

2009-03-22T23:39:27Z

Tras la finalización del Mix’09, se ha publicado los vídeos de todas las sesiones en la web oficial del evento.

Tan sólo debemos seleccionar la sesión en el horario y pinchar en el título de la sesión en la ficha de la parte inferior de la página para cargar el player de Silverlight con los contenidos de la misma.

https://content.visitmix.com/2009/Sessions/

Enjoy!!

Lo mejor del Mix’09: Vídeo sobre la Historia de Internet

2009-03-20T21:53:42Z

A juzgar por la opinión de mucha gente, estos han sido los mejores 5 minutos del Mix’09. Con motivo del lanzamiento de Internet Explorer 8, Microsoft ha creado un video recogiendo los hitos más destacables en la historia de la World Wide Web. Sí, ya sé que eso es algo que puedes encontrar en la Wikipedia… Bueno, realmente no. Lo que la Wikipedia nos cuenta al respecto es la versión aburrida de la historia de Internet. En este video podrás encontrar a esos célebres personajes que has ido conociendo a lo largo de los últimos años, desde el dancing hamster hasta el Ninja de “Ask a Ninja”, pasando por grandes fenómenos sociales como el “Update Status” o el “Poke a Friend”.

Si Internet es de los usuarios, la Historia de Internet debería guiarse por aquello que a los usuarios más les ha impactado, ¿no? Pues aquí lo tenemos…