Las primeras fases de Imagine Cup 2009 entran en su recta final

Un año más, la competición sobre tecnología con mayor número de participantes a nivel mundial se acerca a sus rondas finales. En esta edición, existen nuevas categorías muy interesantes (Mashups, Robótica, etc) que se unen a las categorías clásicas (Desarrollo Software, Project Hoshimi, Fotografía, etc).

Otra de las novedades principales de este año es que la temática es mucho más abierta: “Imagina un Mundo en el que la Tecnología ayude a resolver los problemas más complejos a los que nos enfrentamos en la actualidad”.

Personalmente, me parece un acierto por parte de la organización del evento haber abierto la competición a un abanico de posibilidades mayor, no sólo por la cantidad de problemas que se pueden abordar por separado sino porque la posibilidad de integrar diferentes soluciones para problemas de diversa índole (educación, sanidad, pobreza, medioambiente…) es una opción más que interesante, y perfectamente viable gracias a las tecnologías que Microsoft pone al alcance de nuestra mano.

Estoy deseando ver qué soluciones e ideas nos proponen las nuevas generaciones de talentos… Pronostico que éste será el año de la “Cloud Imagine Cup”, con tecnologías como Azure, Live Mesh y .Net Services entre otras, que posibilitan llevar a cabo una gran cantidad de proyectos ambiciosos con “relativo” poco esfuerzo. 🙂

Recordad que para participar deberéis pasaros por la web internacional de Imagine Cup, y también por la web española para los participantes en la categoría de Desarrollo Software (daros prisa porque la fecha límite para esta categoría es el 21 de Marzo!!)

Por último, os dejo un vídeo bastante currado de Channel 8 que recoge los momentos más destacados de la última fase final, celebrada en París en el mes de Julio de 2008… ¡qué recuerdos!

8 minutos en Channel 8 sobre Oslo, con Chris Sells

Durante la pasada conferencia VSOne en Munich, Chris tuvo la oportunidad de conversar con los amiguetes de Channel 8. Si aún no te has enterado de qué va Oslo, no debes perderte esta explicación clara, concisa y divertida por parte de uno de nuestros más ilustres PMs.

Si no puedes ver el vídeo, accede al post original aquí

Más ejemplos usando Oslo: Galería de ejemplos de MGrammar

Una de las preguntas más frecuentes con la que me he encontrado en estos últimos meses al respecto de Oslo es la de si Microsoft desarrollará alguna aplicación de ejemplo que muestre todo su potencial.

En mi opinión, la respuesta a esta pregunta es No. Antes de que nadie me crucifique, me explico: Con esta respuesta no quiero decir que desde Microsoft no vayamos a esforzarnos por ofrecer ejemplos y escenarios concretos en los que se demuestren los beneficios del uso de las diferentes tecnologías que forman parte de Oslo (algo que ya estamos haciendo), sino que por la propia concepción y naturaleza de la plataforma, es imposible abarcar “todo” el potencial que Oslo nos puede ofrecer.

Entre estos beneficios, se encuentra la productividad en nuestros desarrollos. Dentro del equipo, tenemos para la primera versión de Oslo (v1) un objetivo bastante ambicioso, al cual denominamos “10X”. Es decir, conseguir igual o más que hasta ahora, con la décima parte de esfuerzo. Al hablar de “esfuerzo”, nos estamos refiriendo a algunas métricas bastante tradicionales en el mundo del desarrollo software, como por ejemplo “LOC”, tiempo de desarrollo, etc.

Sin embargo, no sólo de productividad vive el desarrollador, ¿verdad? Por ello, en nuestro equipo también tenemos en cuenta otros beneficios deseables para nuestros desarrollos. Por ejemplo, la mantenibilidad del código, la agilidad para responder a cambios en la lógica o en los requerimientos de nuestras aplicaciones, etc.

Pensemos en metodologías de desarrollo ágiles, tan de moda hoy en día, aplicadas en proyectos cuyos requerimientos están sujetos a cambios frecuentes, metodologías en las que es imprescindible que “la voz” de nuestros clientes llegue de forma inmediata y unívoca, libre de ambigüedad, al equipo de desarrollo del proyecto… ¿No sería ideal que dicho cliente fuera capaz de expresarse en un lenguaje específico de su dominio, y que dicho lenguaje fuera también perfectamente entendible por los desarrolladores? Existen gran cantidad de mecanismos y diagramas para captar estos modelos, sin embargo, tradicionalmente hemos empleado estos modelos en las primeras fases de nuestros desarrollos y, eventualmente, en las últimas fases de los mismos, pero… ¿qué sucede con las fases intermedias? (generalmente, las de mayores costes y riesgos en nuestros proyectos…). Como ya hemos comentado en otras ocasiones, uno de los objetivos de Oslo es convertir los modelos en un elemento central de todas y cada una de las fases de nuestros desarrollos.

Efectivamente, se trata de una apuesta bastante ambiciosa y, al mismo tiempo, muy amplia. Existe una gran cantidad de dominios en los cuales Oslo puede ser aplicable y, por ello, a todos y cada uno de los miembros del equipo nos encanta la posibilidad de que vosotros, desarrolladores, arquitectos, jefes de proyecto…, en general, miembros de la comunidad técnica, nos ayudéis a explorar estas posibilidades.

Para poder ir de la mano en esta “aventura”, nuestra intención es tener un contacto directo y continuo con la comunidad, compartir nuestra visión, escuchar vuestras opiniones y ver hasta qué punto sois capaces de elevar el potencial de Oslo en diferentes dominios, para conseguir alcanzar nuestra meta: 10X.

En estos casi cuatro meses transcurridos desde el PDC 2008, hemos publicado dos CTPs (Octubre 2008 y Enero 2009), que incluyen una gran cantidad de ejemplos, estamos actualizando diariamente nuestro MSDN Oslo Developer Center, con artículos y ejemplos creados por miembros del equipo, así como por miembros de la comunidad, etc.

En esta línea, hemos querido recopilar una galería de gramáticas, para describir DSLs, creadas con MGrammar, y aplicadas a diferentes dominios, desarrolladas por nuestro propio equipo y también por miembros de la comunidad ténica. Echando un vistazo a la lista de gramáticas incluidas en esta colección, podréis haceros una idea del gran abanico de posibilidades que Oslo nos ofrece:

  • “A”: Un lenguaje sintácticamente similar a VB que nos permite componer aplicaciones creadas bajo el uso del patrón MVC. Forma parte de la CTP de Enero.
  • XLANG: Gramática que nos permite trabajar con XLANG, el lenguaje de orquestaciones empleado en BizTalk.
  • MisBehave: Gramática para reconocer historias y escenarios empleadas en el paradigma BDD (Behavior-Driven Development).
  • bdUnit: Otra DSL creada con MGrammar que nos permite traducir “user stories” a pruebas unitarias en lenguaje C#.
  • WatiN Browser Automation Library: DSL para trabajar con esta librería de automatización.
  • State Machine: DSL para la definición de máquinas de estados.
  • Natural Language Dates: DSL que nos permite trabajar con fechas empleando lenguaje natural (“today”, “tomorrow”, “two weeks ago”, etc.)

Estos son tan sólo mis ejemplos favoritos de gramáticas desarrolladas hasta el momento, además de aquellas que podéis encontrar en la CTP de Enero y el resto de las publicadas en la colección que hemos recopilado.

¿Alguien se anima a explorar nuevas posibilidades? 🙂

How-To: Creando una aplicación completa utilizando Oslo

image

La semana pasada, Stephen Forte (CTO de Telerik), comenzó una serie de posts sobre cómo utilizar Oslo en el ciclo de desarrollo de una aplicación completa, desde las primeras fases del diseño, la creación de “user stories”, etc.

Modeling an Application in Oslo

Telerik está desarrollando una serie de herramientas basadas en Oslo y, al mismo tiempo, Stephen nos cuenta sus impresiones, dudas y avances en cuanto a la forma de adoptar el enfoque MDD propuesto en Oslo.

Sin duda, una serie de posts muy interesante y práctica, para todos aquellos que aún no sepan cómo encajar algunas de las piezas de este puzzle 🙂

Introducción a MGrammar: Crear una gramática para reconocer “Menús del día” (parte 1 de 2)

Sirva este post para poner de manifiesto mi devoción por la cocina española, algo que como podéis imaginar, no abunda demasiado por tierras canadienses. Al mismo tiempo, me gustaría introducir una serie de conceptos básicos acerca de MGrammar, uno de los dialectos del lenguaje M que nos permite definir gramáticas para nuestras propias DSLs. Para aquellos de vosotros con conocimientos en el ámbito de las gramáticas y lenguajes, comentar que con MGrammar somos capaces de crear gramáticas independientes de contexto (GIC), que tienen la potencia expresiva suficiente para describir cualquiera de los lenguajes de programación empleados en la actualidad.

Quien más y quien menos se habrá encontrado en alguna ocasión con el siguiente modelo de datos, el cual representa una abstracción de nuestro dominio específico.

A pesar de que el camarero que escribió este texto en la pizarra a primera hora de la mañana jamás ha utilizado Visual Studio, ni conoce las diferentes categorías de lenguajes establecidas por el OMG, podemos apreciar cómo claramente está empleando su propio lenguaje específico de dominio, el cual se rige por unas normas fácilmente formalizables mediante el uso de una gramática.

Nosotros, en un intento de convertir a cualquier persona en desarrollador, a pesar de que ellos no lo sepan, vamos a aportarles una potente herramienta que permitirá traducir automáticamente lo que hay escrito en esta pizarra en una representación intermedia en forma de grafo (MGraph) que posteriormente podremos proyectar sobre una base de datos o consumir directamente desde .Net Framework (WPF, WCF/WF, ASP.Net…). De la generación de proyecciones nos encargaremos en la segunda parte de esta serie, en este primer capítulo nos centraremos en crear la gramática que define las reglas de nuestro lenguaje.

Para estandarizar un poco el lenguaje, supongamos que el contenido de nuestra pizarra es el siguiente:

Primeros
* Gazpacho Andaluz.
* Ensalada Mediterránea.
* Consomé de Pollo.
Segundos
* Solomillo a la Plancha.
* Merluza a la Romana.
* Macarrones Bolognesa.
* Paella Alicantina.
Postres
* Flan.
* Arroz con leche.
* Macedonia de frutas.
* Tarta de queso.
Vino

En el caso de la última línea, el camarero podría elegir entre incluir Vino o Café en el menú.

Una vez tenemos clara la estructura de nuestro lenguaje, vamos a definir sus reglas gramaticales. Para ello, emplearemos Intellipad. Intellipad es un IDE textual que viene incluído con la SDK de Oslo. Algunos de vosotros lo conoceréis por su nombre anterior: Emacs.Net

image

Lo primero que haremos será crear el archivo para describir nuestra gramática: MenuDSL.mg, que constará de las siguientes reglas:

   1:  module MLanguage
   2:  {
   3:      language Menu
   4:      {
   5:          // Keywords
   6:          token kwPrimeros = "Primeros";
   7:          token kwSegundos = "Segundos";
   8:          token kwPostres = "Postres";    
   9:          token kwVino = "Vino";
  10:          token kwCafe = "Cafe";
  11:          
  12:          token EntryStart = "*" " "*;
  13:          token EntryText = ^"."+;
  14:          token EntryEnd = ".";
  15:          nest syntax Entry = EntryStart EntryText EntryEnd;
  16:          
  17:          syntax Primeros = kwPrimeros Entry+;
  18:          syntax Segundos = kwSegundos Entry+;
  19:          syntax Postres = kwPostres Entry+;
  20:          syntax Extras = kwVino | kwCafe;
  21:          
  22:          syntax Main = Primeros Segundos Postres Extras;
  23:          
  24:          interleave Skippable = " " | "r" | "n";
  25:      }
  26:  }

Acabamos de escribir nuestro primer módulo en MGrammar. Un módulo no es ni más ni menos que la forma que tenemos en MGrammar de crear un ámbito, dentro del cual escribiremos una serie de reglas para nuestro lenguaje. Pasemos a analizar la sintaxis del mismo detenidamente.

Dentro de nuestro módulo MLanguage, hemos creado un lenguaje denominado Menu. Este lenguaje contiene un conjunto de reglas y de tokens. Un token es un elemento terminal de nuestra gramática, es decir, un elemento cuya derivación no involucra el uso de reglas adicionales. Por el contrario, syntax se emplea para definir reglas que derivan en otras reglas, como sucede por ejemplo con la siguiente:

syntax Primeros = kwPrimeros Entry+;

 

En esta regla además hacemos uso de un signo de repetición en nuestra gramática. Disponemos de 3 símbolos para representar repeticiones en MGrammar: + (1 o más repeticiones), * (0 o más repeticiones) y ? (0 o 1 repetición).

Por otra parte, también hacemos uso de la siguiente instrucción para definir aquellas secuencias de caracteres que pueden ser ignoradas a la hora de procesar nuestra entrada (en este caso, espacios, retornos de carro y saltos de línea).

interleave Skippable = " " | "r" | "n";

 

Guardaremos nuestra gramática con el nombre MenuDSL.mg y crearemos un fichero input.txt conteniendo nuestro menú del día expresado tal cual hacíamos al principio del post:

Primeros
* Gazpacho Andaluz.
* Ensalada Mediterránea.
* Consomé de Pollo.
Segundos
* Solomillo a la Plancha.
* Merluza a la Romana.
* Macarrones Bolognesa.
* Paella Alicantina.
Postres
* Flan.
* Arroz con leche.
* Macedonia de frutas.
* Tarta de queso.
Vino

Una vez tenemos definida nuestra gramática y nuestra entrada, vamos a hacer uso de un Modo especial de Intellipad, denominado MGrammar Mode, el cual nos permitirá visualizar cuatro paneles al mismo tiempo en nuestro IDE.

image

Al seleccionar MGrammar Mode, observaremos que aparece una nueva pestaña en nuestro IDE, denominada MGrammar Mode. Si pinchamos en ella podremos seleccionar la opción Tree Preview, que nos permitirá visualizar el grafo generado por nuestra gramática tras procesar el archivo de entrada.

image

Intellipad abrirá una ventana de selección de archivo de entrada para nuestra gramática. Seleccionaremos nuestro archivo input.txt y, si hemos hecho todo bien, obtendremos la siguiente vista.

image

Esta vista se actualiza de forma instantánea, de modo que podemos modificar en el panel de la izquierda la entrada (crear nuevos platos, etc) o incluso nuestras reglas gramaticales, y observaríamos automáticamente el resultado generado en forma de árbol en el panel de la derecha. Eventualmente, si introducimos algún elemento no soportado por nuestra gramática, el panel inferior nos ofrecerá una descripción del error, tal cual vemos en la siguiente captura en el supuesto de que introduzcamos una serie de “Aperitivos” al principio de nuestro menú.

image

Si añadimos un nuevo Token y una nueva regla a nuestra gramática para soportar la inclusión de aperitivos en nuestro menú, los errores desaparecerían y la representación en forma de grafo sería generada sin necesidad de guardar o refrescar ninguno de los paneles.

Estas serían las dos líneas a añadir:

token kwAperitivos = "Aperitivos";
syntax Aperitivos = kwAperitivos Entry+;

Por último, deberemos añadir a nuestra regla principal el elemento Aperitivos al comienzo de la misma, para indicar que el elemento inicial del Menú pertenece a este grupo.

syntax Main = Aperitivos Primeros Segundos Postres Extras;

De este modo, hemos creado una gramática que nos permite procesar el menú del día escrito por nuestro querido camarero (quien jamás en su vida ha picado una línea de código) en una representación en forma de grafo, generada en base a una serie de reglas definidas mediante el uso de MGrammar. Para todos aquellos que lo estén pensando ahora mismo: la creación de gramáticas no es algo nuevo ni mucho menos. Sin embargo, Oslo proporciona una serie de valores añadidos al proceso para la creación de gramáticas implementado por otras tecnologías hasta ahora:

  1. IDE Textual que facilita significativamente la tarea para la creación y procesamiento de gramáticas: Intellipad.
  2. Una traducción automática a MGraph de nuestro resultado, que puede ser fácilmente empleada desde diferentes entornos de ejecución.
  3. Una API para .Net que nos permite incorporar nuestras gramáticas a entornos de ejecución .Net, tal cual veremos en el próximo capítulo de esta serie.
  4. Una herramienta gráfica para la creación de modelos (Quadrant).

¡Y todo ello en menos de 30 líneas de código!